Você está na página 1de 153

Walter de Tarso

Material de referncia

TI ICMS

Walter de Tarso

Verso 1.4

2012

Curso de TI

Sumrio
1

Gerncia de Projetos .................................................................................................................................. 1


1.1

Conceitos bsicos ............................................................................................................................... 1

1.2

Processos do PMBOK ......................................................................................................................... 2

1.2.1
1.2.2
1.2.3

1.3

Planejamento e controle de mtricas de projeto ................................................................................ 8

1.4

Mtodos de gerenciamento do tempo do projeto .............................................................................. 9

1.5

Exerccios........................................................................................................................................... 10

Gesto de Processos de Negcio (BPM) ................................................................................................. 14


2.1

Tcnicas de anlise de processos .................................................................................................... 14

2.1.1
2.1.2
2.1.3
2.1.4
2.1.5
2.1.6
2.1.7
2.1.8
2.1.9

BPMN - Modelagem de processos ............................................................................................................... 14


Elementos ................................................................................................................................................... 16
Fluxograma ................................................................................................................................................. 17
Service blueprint .......................................................................................................................................... 17
Mapa do servio .......................................................................................................................................... 18
IDEF............................................................................................................................................................ 18
Estrutura de processamento de clientes ....................................................................................................... 19
Walk-through-audit....................................................................................................................................... 19
Anlise da transao de servio (STA Service Transaction Analysis).......................................................... 20

2.2

Portais corporativos e colaborativos ................................................................................................ 20

2.3

GED - Gerenciamento Eletrnico de Documentos .......................................................................... 22

2.4

Workflow ............................................................................................................................................ 23

2.5

Exerccios........................................................................................................................................... 23

Governana de TI ...................................................................................................................................... 26
3.1

Princpios de governana de TI......................................................................................................... 26

3.2

Alinhamento estratgico ................................................................................................................... 27

3.3

Qualidade de software ....................................................................................................................... 27

3.3.1
3.3.2
3.3.3

CMMI .......................................................................................................................................................... 28
MPS-BR - Melhoria de Processos do Software Brasileiro .............................................................................. 30
Exerccios.................................................................................................................................................... 30

3.4

Gerenciamento de servios............................................................................................................... 32

3.5

Conceitos e definies ...................................................................................................................... 32

3.6

Fundamentos da ITIL V2 .................................................................................................................... 33

3.6.1
3.6.2

3.7

Suporte a servios ....................................................................................................................................... 33


Entrega de Servio ...................................................................................................................................... 34

Fundamentos de ITIL V3 ................................................................................................................... 35

3.7.1
3.7.2
3.7.3
3.7.4
3.7.5

Estratgia do servio (Service Strategy) ....................................................................................................... 36


Desenho de servio (Service Design) ........................................................................................................... 36
Transio do servio (Service Transition) ..................................................................................................... 36
Operao do servio (Service Operation) ..................................................................................................... 36
Melhoria de servio continuada (Continual Service Improvement) ................................................................. 36

3.8

ITIL V2 x V3 ........................................................................................................................................ 37

3.9

Fundamentos de COBIT .................................................................................................................... 38

3.9.1
3.9.2
3.9.3
3.9.4

Diferenas entre a edio 3 e 4 do PMBOK .................................................................................................... 3


reas de conhecimento do PMBOK................................................................................................................ 4
Processos, ferramentas e tcnicas ................................................................................................................. 5

Planejar e Organizar .................................................................................................................................... 39


Adquirir e Implementar ................................................................................................................................. 40
Entregar e Dar Suporte ................................................................................................................................ 40
Monitorar e Avaliar ....................................................................................................................................... 40

3.10

Comparao ITIL V3 x COBIT ........................................................................................................ 41

3.11

Exerccios ....................................................................................................................................... 41

Segurana da informao ........................................................................................................................ 46


4.1

Conceitos bsicos ............................................................................................................................. 46

Pg. 2 de 153

Walter de Tarso

4.2

Plano de Continuidade de Negcio................................................................................................... 47

4.3

Vulnerabilidade .................................................................................................................................. 48

4.4

Auditoria e conformidade .................................................................................................................. 49

4.5

Conhecimento sobre norma ISO 27001 ............................................................................................ 50

4.6

Exerccios........................................................................................................................................... 52

Arquitetura de Software............................................................................................................................ 56
5.1

UML .................................................................................................................................................... 57

5.2

Arquitetura Orientada a Servio (SOA) ............................................................................................. 58

5.2.1
5.2.2
5.2.3
5.2.4
5.2.5
5.2.6
5.2.7
5.2.8

5.3
6

Exerccios........................................................................................................................................... 64

Gerncia de Requisitos de Software ........................................................................................................ 68


6.1

Conceitos de Requisitos ................................................................................................................... 68

6.1.1

Requisitos Funcionais e No-Funcionais ......................................................................................... 70

6.3

Exerccios........................................................................................................................................... 71

6.4

Tcnicas de avaliao de software ................................................................................................... 72

Conceitos de Gerncia de Configurao e Mudana de software ................................................... 76

7.1.1
7.1.2
7.1.3
7.1.4

Configurao de software............................................................................................................................. 76
Item de configurao de software ................................................................................................................. 76
Controle de verses ..................................................................................................................................... 77
Papis ......................................................................................................................................................... 77

7.2

Solicitaes de Mudana................................................................................................................... 77

7.3

Exerccios........................................................................................................................................... 79

Engenharia de Software ........................................................................................................................... 81


8.1

Software ............................................................................................................................................. 81

8.2

Ciclo de vida do software .................................................................................................................. 82

8.2.1
8.2.2
8.2.3
8.2.4

8.3

Fase de Definio ........................................................................................................................................ 82


Fase de Desenvolvimento ............................................................................................................................ 82
Fase de Operao ....................................................................................................................................... 83
Fase de retirada........................................................................................................................................... 84

Metodologias de desenvolvimento de software. .............................................................................. 84

8.3.1
8.3.2

Modelo catico ............................................................................................................................................ 84


Modelo Cascata........................................................................................................................................... 84

8.4

Desenvolvimento gil ........................................................................................................................ 85

8.5

Planejamento e avaliao de iteraes............................................................................................. 87

8.6

Testes Software ................................................................................................................................. 88

8.6.1

8.7
9

Mtodo COCOMO ....................................................................................................................................... 72


Anlise por Pontos de Funo...................................................................................................................... 73

Gerncia de Configurao e Mudana ..................................................................................................... 76


7.1

Levantamento de requisitos ......................................................................................................................... 69

6.2

6.4.1
6.4.2

Servio ........................................................................................................................................................ 59
Processos ................................................................................................................................................... 59
Definies de SOA....................................................................................................................................... 59
Web Services .............................................................................................................................................. 59
SOAP .......................................................................................................................................................... 61
WSDL.......................................................................................................................................................... 62
UDDI ........................................................................................................................................................... 63
Segurana ................................................................................................................................................... 63

Documentos de Teste .................................................................................................................................. 89

Exerccios........................................................................................................................................... 90

Banco de Dados........................................................................................................................................ 92
9.1

Conceitos bsicos ............................................................................................................................. 92

9.2

Modelagem de Dados Relacional ...................................................................................................... 92

9.2.1
9.2.2

Normalizao............................................................................................................................................... 92
Etapas de modelagem ................................................................................................................................. 94

Curso de TI

9.2.3
9.2.4

Relacionamentos ......................................................................................................................................... 94
Transao ................................................................................................................................................... 94

9.3

Modelo Entidade Relacionamento .................................................................................................... 95

9.4

Modelagem de Dados Multidimensional ........................................................................................... 95

9.4.1

9.5

Sistemas Transacionais X Sistemas Analticos ............................................................................................. 96

Conceitos de Datawarehouse e ETL ................................................................................................. 97

9.5.1

9.6

ETL ............................................................................................................................................................. 98

Conceitos de desenvolvimento em banco de dados SQL Server e Oracle ..................................... 98

9.6.1
9.6.2
9.6.3

9.7
10

SQL............................................................................................................................................................. 98
Arquitetura de um Servidor Oracle.............................................................................................................. 100
Arquitetura de um Servidor SQL Server ...................................................................................................... 101

Exerccios......................................................................................................................................... 102
Programao de Sistemas .................................................................................................................. 108

10.1

Lgica de Programao ............................................................................................................... 108

10.1.1

10.2

Tipos de dados e variveis ......................................................................................................................... 109

Programao orientada a objetos ............................................................................................... 110

10.2.1
10.2.2
10.2.3
10.2.4
10.2.5
10.2.6
10.2.7
10.2.8
10.2.9
10.2.10
10.2.11

10.3

Programao na WEB .................................................................................................................. 113

10.3.1
10.3.2
10.3.3

10.4

Linguagem HTML ...................................................................................................................................... 114


Linguagens web de servidor ....................................................................................................................... 115
XML .......................................................................................................................................................... 115

Conceitos de linguagem de programao Microsoft .NET ......................................................... 116

10.4.1
10.4.2
10.4.3
10.4.4
10.4.5
10.4.6
10.4.7
10.4.8
10.4.9
10.4.10
10.4.11
10.4.12

10.5
11

Objetos...................................................................................................................................................... 110
Classe ....................................................................................................................................................... 111
Persistncia ............................................................................................................................................... 111
Mtodos .................................................................................................................................................... 111
Atributos .................................................................................................................................................... 111
Mensagens ................................................................................................................................................ 112
Herana .................................................................................................................................................... 112
Polimorfismo.............................................................................................................................................. 112
Sobrecarga................................................................................................................................................ 112
Interfaces .................................................................................................................................................. 113
Pacotes ..................................................................................................................................................... 113

arquitetura da .Net ..................................................................................................................................... 117


Linguagens de programao ...................................................................................................................... 117
Common Language Specification (CLS) ..................................................................................................... 117
Common Type System (CTS)..................................................................................................................... 117
Framework Class Library (FCL) .................................................................................................................. 118
Camada de apresentao .......................................................................................................................... 118
ADO.Net .................................................................................................................................................... 118
.Net Remoting............................................................................................................................................ 118
Common Language Runtime (CLR) ............................................................................................................ 119
Common Language Infrastructure (CLI) ...................................................................................................... 119
Operating System (OS) .............................................................................................................................. 119
Outros detalhes da .Net ............................................................................................................................. 119

Exerccios ..................................................................................................................................... 120


Sistemas Operacionais ....................................................................................................................... 124

11.1

Conceitos de administrao de servidores em plataforma Windows ........................................ 124

11.2

Conceitos de administrao de servidores em plataforma Linux .............................................. 124

11.2.1
11.2.2
11.2.3
11.2.4
11.2.5
11.2.6
11.2.7
11.2.8
11.2.9
11.2.10

Alguns comandos no Linux ........................................................................................................................ 124


Gerenciando a iniciao do Linux ............................................................................................................... 125
Fazendo Backups ...................................................................................................................................... 126
Recompilando e Adaptando o Kernel .......................................................................................................... 126
Agendando Processos ............................................................................................................................... 126
Syslogd - A Caixa Preta do Linux ............................................................................................................... 126
Tcnicas Bsicas para Trabalhar com Redes (ifconfig, route) ...................................................................... 127
Gerenciando os Servios - inetd ................................................................................................................. 127
Utilizando Ferramentas de Busca ............................................................................................................... 127
Instalando SSh / SShD.............................................................................................................................. 127

11.3

Conceitos de Virtualizao .......................................................................................................... 127

11.4

Active Directory ............................................................................................................................ 130

Pg. 4 de 153

Walter de Tarso

11.5
12

Exerccios ..................................................................................................................................... 131


Redes ................................................................................................................................................... 133

12.1

Conceito de rede .......................................................................................................................... 133

12.1.1

12.2

Configurao de redes TCP-IP................................................................................................................... 133

Arquitetura de Rede ..................................................................................................................... 135

12.2.1
12.2.2
12.2.3
12.2.4
12.2.5
12.2.6
12.2.7

Camada Fsica .......................................................................................................................................... 135


Camada de Enlace ou Ligao de Dados ................................................................................................... 136
Camada de Rede....................................................................................................................................... 136
Camada de Transporte .............................................................................................................................. 136
Camada de Sesso ................................................................................................................................... 137
Camada de Apresentao .......................................................................................................................... 137
Camada de Aplicao ................................................................................................................................ 137

12.3

Noes de administrao de redes ............................................................................................. 137

12.4

Acesso Remoto ............................................................................................................................ 138

12.5

Rede Wireless ............................................................................................................................... 138

12.6

Exerccios ..................................................................................................................................... 138

13

Informtica Bsica............................................................................................................................... 143


13.1.1

Questes de informtica do concurso ICMS-SP 2009 ................................................................................. 143

14

Referncias .......................................................................................................................................... 145

15

Sobre o autor ....................................................................................................................................... 146

16

Gabarito ............................................................................................................................................... 147

Sumrio de imagens
Ilustrao 1 Mtricas ............................................................................................................................................ 8
Ilustrao 2 Smbolos BMPN ............................................................................................................................. 16
Ilustrao 3 Exemplo de Fluxo utilizando pool, lanes, evento de incio e fim, tarefas e gateway ......................... 17
Ilustrao 4 Portal Corporativo ........................................................................................................................... 21
Ilustrao 5 Governana de TI ........................................................................................................................... 26
Ilustrao 6 Ciclo de vida do servio - Ncleo do ITIL V3 ................................................................................... 35
Ilustrao 7 Cobit ............................................................................................................................................... 38
Ilustrao 8 Comparao COBIT x ITIL V3......................................................................................................... 41
Ilustrao 9 Modelo PDCA aplicado aos processos do SGSI.............................................................................. 51
Ilustrao 10 Componentes bsicos da arquitetura do Web Service ................................................................... 60
Ilustrao 11 Ciclo de vida do web service ......................................................................................................... 61
Ilustrao 12 Protocolos de comunicao de Web services ................................................................................ 61
Ilustrao 13 Descrio WSDL........................................................................................................................... 62

TI para concursos

Gerncia de Projetos

1.1

Conceitos bsicos
1

Um projeto um esforo temporrio empreendido para criar um produto, no necessariamente


temporrio, servio ou resultado exclusivo. Os projetos e as operaes diferem, principalmente, no fato
de que os projetos so temporrios e exclusivos, enquanto as operaes so contnuas e repetitivas.
Um programa definido como um grupo de projetos relacionados gerenciados de modo coordenado
para a obteno de benefcios e controle que no estariam disponveis se eles fossem gerenciados
individualmente. Os programas podem incluir elementos de trabalho relacionado fora do escopo de
projetos distintos no programa. Um projeto pode ou no fazer parte de um programa, mas um programa
sempre ter projetos.
Um portflio refere-se a um conjunto de projetos ou programas e outros trabalhos, agrupados para
facilitar o gerenciamento eficaz desse trabalho a fim de atingir os objetivos de negcios estratgicos.
Os projetos so normalmente autorizados como resultado de uma ou mais consideraes estratgicas.
Estas podem ser uma demanda de mercado, necessidade organizacional, solicitao de um cliente,
avano tecnolgico ou requisito legal.
As principais caractersticas dos projetos so:
temporrios, possuem um incio e um fim definidos.
planejados, executado e controlado.
entregam produtos, servios ou resultados exclusivos.
desenvolvidos em etapas e continuam por incremento com uma elaborao progressiva.
realizados por pessoas.
com recursos limitados.
Esse um resumo da definio de projeto feita pelo Guia PMBOK, um guia que identifica o
subconjunto do conjunto de conhecimentos em gerenciamento de projetos, amplamente reconhecido
como boa prtica na maioria dos projetos na maior parte do tempo e utilizado como base pelo Project
Management Institute ( PMI).
Gerncia de projetos a disciplina de manter os riscos de fracasso em um nvel to baixo quanto
necessrio durante o ciclo de vida do projeto. Sua funo definir e alcanar objetivos ao mesmo tempo
em que se otimiza o uso de recursos (tempo, dinheiro, pessoas, espao etc).2
Define-se fase do projeto um conjunto de atividades do projeto relacionadas de forma lgica que
geralmente culminam com o trmino de uma entrega importante. Na maioria dos casos, as fases do
projeto so terminadas seqencialmente, mas podem se sobrepor em algumas situaes do projeto. As
fases podem ser subdivididas em subfases e depois em componentes; se o projeto ou parte do projeto
estiverem divididos em fases, essa hierarquia far parte da estrutura analtica do projeto. Uma fase do
projeto um componente do ciclo de vida do projeto.
Em um modelo de ciclo de vida de quatro fases, na primeira fase esto os processos que definem e
autorizam o incio de um projeto ou de uma fase, assegurando o comprometimento necessrio para
execuo. Na segunda fase esto os processos que planejam e mantm um esquema de trabalho vivel
para se atingir os objetivos do projeto. A terceira fase envolve o planejamento detalhado do projeto. A
quarta fase a concluso do projeto.
De acordo com o PMBOK, todos os projetos podem ser mapeados para a estrutura de ciclo de vida:
Incio do projeto
Organizao e preparao
Execuo do trabalho do projeto
Encerramento do projeto.
Esta estrutura genrica de ciclo de vida frequentemente referenciada na comunicao com a alta
administrao ou outras entidades menos familiarizadas com os detalhes do projeto. Esta viso de alto
nvel pode oferecer um quadro de referncia comum para comparao de projetos, mesmo que, em sua
natureza, eles no sejam semelhantes.
Na abordagem tradicional, distinguimos cinco grupos de processos no desenvolvimento de um projeto:
iniciao autorizao do projeto ou fase
planejamento so processos iterativos de definio e refinamento de objetivos e seleo dos
melhores caminhos para atingir os objetivos.
execuo realizao dos planos do projeto: coordenao de pessoas e outros recursos para
executar o plano
http://pt.wikipedia.org/wiki/Projeto
http://pt.wikipedia.org/wiki/Gerncia_de_projetos
1
1
2

TI para concursos

controle medio e monitoramento do desempenho do projeto. Garantem que os objetivos do


projeto so alcanados atravs do monitoramento e medio regular do progresso, de modo que
aes corretivas possam ser tomadas quando necessrio.
encerramento aceitao formal do projeto (com verificao de escopo) ou fase para a sua
finalizao.
Repetir os processos de iniciao antes da execuo de cada fase uma maneira de se avaliar se o
projeto continua cumprindo as necessidades de negcio. Envolver as partes interessadas no projeto em
cada uma das fases uma maneira de aumentar as probabilidades de satisfao dos requisitos do
cliente.
O gerente de projetos precisa monitorar e comunicar o desempenho do projeto. Os resultados do
trabalho que estiverem abaixo de um nvel de desempenho aceitvel precisam ser ajustados com aes
corretivas para que o projeto volte a estar em conformidade com as linhas de base de custo, prazo e
escopo. A comunicao do desempenho do projeto um dos principais elementos para o gerenciamento
de projetos bem sucedido.
Um escritrio de projetos (Project Management Office, PMO) um corpo ou entidade organizacional
qual so atribudas vrias responsabilidades relacionadas ao gerenciamento centralizado e coordenado
dos projetos sob seu domnio.
O projeto ou empreendimento visa a satisfao de uma necessidade ou oportunidade, definida no texto
acima como fase inicial na qual existem muitas reas e/ou pessoas envolvidas.
Em geral, existe mais do que uma soluo ou alternativas para atender s mesmas necessidades. A
tcnica usada para definir a soluo final passa pelo desenvolvimento de alternativas extremas. A
primeira, de baixo custo, que atende as necessidades mnimas para ser funcional. A segunda tenta
atender a maior parte das as exigncias das diversas reas envolvidas no escopo, que resulta num
projeto com custo muito maior e pouco competitivo. A partir de ambas as alternativas desenvolvida
uma soluo intermediria entre as mesmas, que atende a uma boa parte das exigncias com um custo
competitivo.
O gerenciamento de projetos tenta adquirir controle sobre as variveis
tempo - influencia o prazo at o termino do projeto. Uma restrio de tempo pode significar custos
aumentados e/ou escopo reduzido.
custo - informa o valor monetrio includo no oramento disponvel para o projeto. Um oramento
apertado pode significar tempo aumentado e/ou escopo reduzido.
escopo - designa o que deve ser feito para produzir o resultado de fim do projeto. O escopo
aumentado pode significar o tempo aumentado e/ou o custo aumentado.
Na verso atual do PMBOK, trplice restrio foi eliminada, passando a existir restries do projeto que
so elas: Escopo, Qualidade, Cronograma, Oramento, Recursos e Riscos. Portanto, qualquer alterao
em um desses itens certamente haver restries em um ou mais dos demais itens.
Para manter o controle sobre o projeto do incio ao fim, um gerente de projetos utiliza vrias tcnicas,
dentre as quais se destacam:
Planejamento de projeto
Anlise de valor agregado
Gerenciamento de riscos de projeto
Cronograma
Melhoria de processo

1.2

Processos do PMBOK
3

O Guia PMBOK identifica um subconjunto do conjunto de conhecimentos em gerenciamento de


projetos, que amplamente reconhecido como boa prtica, sendo em razo disso, utilizado como base
pelo Project Management Institute (PMI). Uma boa prtica no significa que o conhecimento e as
prticas devem ser aplicadas uniformemente a todos os projetos, sem considerar se so ou no
apropriados.
O Guia PMBOK tambm fornece e promove um vocabulrio comum para se discutir, escrever e aplicar o
gerenciamento de projetos possibilitando o intercmbio eficiente de informaes entre os profissionais de
gerncia 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.
A verso 2008 do guia, cita 42 processos agrupados em cinco grupos e nove reas de conhecimento.
O conhecimento de gerenciamento de projetos, descrito no Guia PMBOK consiste em:
http://pt.wikipedia.org/wiki/PMBOK
2
3

TI para concursos

Definio do ciclo de vida e da organizao de um projeto


Descrio dos cinco grupos de processos de gerenciamento de projetos
Grupo de processos de iniciao
Grupo de processos de planejamento
Grupo de processos de execuo
Grupo de processos de monitoramento e controle
Grupo de processos de encerramento
Descrio das nove reas de conhecimento
Existem trs documentos principais descritos no Guia PMBOK e cada um deles possui um objetivo
especfico:
Termo de abertura do projeto. Autoriza formalmente o projeto.
Declarao do escopo do projeto. Determina qual trabalho dever ser realizado e quais entregas
precisam ser produzidas.
Plano de gerenciamento do projeto. Determina como o trabalho ser realizado.

1.2.1

Diferenas entre a edio 3 e 4 do PMBOK


Todos os nomes de processos esto no formato verbo-substantivo.
Foi empregada uma abordagem padro discusso de fatores ambientais da empresa e de ativos de
processos organizacionais.
Foi empregada uma abordagem padro discusso de mudanas, aes preventivas e corretivas e
reparos de defeitos.
O nmero de processos foi reduzido de 44 para 42. Dois processos foram excludos, dois foram
adicionados e seis foram reconfigurados em quatro processos na rea de conhecimento em
gerenciamento de aquisies do projeto.
A fim de proporcionar clareza, uma distino foi feita entre o plano de gerenciamento do projeto e os
documentos de projeto usados para gerenci-lo.
A distino entre as informaes no Termo de abertura do projeto e na Declarao do escopo do
projeto foi esclarecida.
Os diagramas de fluxo do processo no incio dos Captulos 4 a 12 foram excludos.
Um diagrama de fluxo de dados foi criado para cada processo para mostrar os processos
relacionados s suas entradas e sadas.
Um novo apndice foi adicionado para abordar as principais habilidades interpessoais usadas por um
gerente de projetos durante o gerenciamento

TI para concursos

1.2.2

reas de conhecimento do PMBOK


Os quarenta e dois processos dos cinco grupos definidos pelo PMBOK podem ser classificados em nove
chamadas reas de conhecimento.

4 - Integrao

Iniciao
Desenvolver o
termo de
abertura do
projeto

5 - Escopo

6 - Tempo

7 - Custo
8 - Qualidade

Planejamento
Desenvolver o plano de
gerenciamento de projeto

Verificao do escopo
Controle do escopo

Estimativa de custos
Oramentao
Planejamento da qualidade

Controle de custos

9 - RH

10 - Comunicao

11 - Riscos

12 - Aquisies

Monitoramento e controle
Monitorar e controlar o
trabalho do projeto
Controle integrado de
mudanas

Coletar requisitos
Definio do escopo
Criar EAP
Definio das atividades
Sequenciamento de atividades
Estimativa de recursos das atividades
Estimativa de durao das atividades
Desenvolvimento do cronograma

Desenvolver o plano de recursos


humanos

Identificar as
partes
interessadas

Execuo
Orientar e gerenciar
a execuo do
projeto

Planejamento das comunicaes

Planejamento de gerenciamento de
riscos
Identificao dos riscos
Anlise qualitativa dos riscos
Anlise quantitativa dos riscos
Planejamento de respostas a riscos
Planejar as aquisies

Encerramento
Encerrar o projeto

Controle do cronograma

Realizar a garantia
da qualidade
Mobilizar a equipe
do projeto
Desenvolver a
equipe do projeto
Gerenciar a equipe
do projeto
Distribuio das
informaes
Gerenciar as
expectativas das
partes interessadas

Realizar o controle da
qualidade

Relatrio de desempenho

Monitoramento e controle
de riscos

Realizar aquisies

Administrao de
aquisies

Encerramentos de
aquisies

Os processos descritos se relacionam e interagem durante a conduo do trabalho e a descrio de


cada um deles feita em termos de Entradas documentos, planos, desenhos etc., Ferramentas e
tcnicas 145 ferramentas que se aplicam as entradas, e Saidas que podem ser entradas de outros
processos
A transio de uma fase para a outra dentro do ciclo de vida de um projeto normalmente definida por
alguma forma de transferncia tcnica ou entrega. As entregas de uma fase geralmente so revisadas,
para garantir que estejam completas e exatas, e aprovadas antes que o trabalho seja iniciado na prxima
fase. No entanto, no incomum que uma fase seja iniciada antes da aprovao das entregas da fase
anterior, quando os riscos envolvidos so considerados aceitveis. Essa prtica de sobreposio de
fases, normalmente feita em seqncia, um exemplo da aplicao da tcnica de compresso do
cronograma denominada paralelismo.

De acordo com o PMBOK, a estrutura genrica do ciclo de vida tem por caractersticas:
nveis baixos de custo no incio, atingindo seu mximo na execuo e diminuindo ao final
4

TI para concursos

riscos e incertezas altos no incio


maior capacidade de modificao sem aumento significativo de custos no incio

1.2.3

Processos, ferramentas e tcnicas

4 Integrao
Processos e as atividades necessrias para identificar, definir, combinar, unificar
grupos de processos de gerenciamento
Desenvolver o termo de
Autorizar formalmente um projeto

abertura do projeto

e coordenar os vrios processos e atividades dos


Mtodos de seleo de projetos
Metodologia de gerenciamento de projetos
Sistema de informaes do gerenciamento de projetos
Opinio especializada

Desenvolver o plano de
gerenciamento de projeto

Definir, coordenar e integrar todos os planos


auxiliares

Metodologia de gerenciamento de projetos


Sistema de informaes do gerenciamento de projetos
Opinio especializada

Orientar e gerenciar a
execuo do projeto

Aes para que seja realizado o trabalho


definido na declarao do escopo do projeto

Metodologia de gerenciamento de projetos


Sistema de informaes do gerenciamento de projetos

Monitorar e controlar o
trabalho do projeto

Aes preventivas ou corretivas para controlar


o desempenho do projeto

Realizar o controle
integrado de mudanas

reviso de todas as solicitaes, aprovao e


gerenciamento de mudanas nas entregas,
ativos de processos organizacionais,
documentos de projeto e plano de
gerenciamento do projeto.
Documentar as entregas do projeto, formalizar
a aceitao pelo cliente e investigar e
documentar as razes se um projeto for
abortado.

Metodologia de gerenciamento de projetos


Sistema de informaes do gerenciamento de projetos
Tcnica do valor agregado
Opinio especializada
Metodologia de gerenciamento de projetos
Sistema de informaes do gerenciamento de projetos
Opinio especializada

Metodologia de gerenciamento de projetos


Sistema de informaes do gerenciamento de projetos
Opinio especializada

Encerrar o projeto

5 Escopo
Processos necessrios para assegurar que o projeto inclui todo o trabalho necessrio, e apenas o necessrio, para terminar o projeto
com sucesso.
Coletar os requisitos
Definio e documentao das
Opinio especializada
necessidades das partes interessadas para
Modelos, formulrios, normas
alcanar os objetivos do projeto
Definio do escopo

Desenvolvimento de uma declarao do


escopo detalhada do projeto como a base
para futuras decises do projeto.

Anlise de produtos
Identificao de alternativas
Opinio especializada
Anlise das partes interessadas

Criar EAP

Subdiviso das principais entregas do


projeto e do trabalho do projeto em
componentes menores e mais facilmente
gerenciveis.
Formalizao da aceitao das entregas do
projeto terminadas.
Controle das mudanas no escopo do
projeto.

Modelos da estrutura analtica do projeto


Decomposio

Inspeo

Sistema de controle de mudanas


Anlise da variao
Replanejamento
Sistema de gerenciamento de configurao

Verificao do escopo
Controle do escopo

TI para concursos

6 Tempo
Processos necessrios para gerenciar o trmino pontual do projeto
Definio das atividades
Identificao das atividades especficas do
cronograma que precisam ser realizadas
para produzir as vrias entregas do projeto.

Decomposio
Modelos
Planejamento em ondas sucessivas
Opinio especializada
Componente do planejamento

Sequenciamento de
atividades

Identificao e documentao das


dependncias entre as atividades do
cronograma

Mtodo do diagrama de precedncia (MDP)


Mtodo do diagrama de setas (MDS)
Modelos de rede do cronograma
Determinao da dependncia

Estimativa de recursos das


atividades

Estimativa do tipo e das quantidades de


recursos necessrios para realizar cada
atividade do cronograma.

Opinio especializada
Anlise de alternativas
Dados publicados para auxlio a estimativas
Software de gerenciamento de projetos
Estimativa bottom-up

Estimativa de durao das


atividades

Estimativa do nmero de perodos de


trabalho que sero necessrios para
terminar as atividades individuais do
cronograma.

Opinio especializada
Estimativa anloga
Estimativa paramtrica
Estimativas de trs pontos
Anlise das reservas

Desenvolvimento do
cronograma

Anlise dos recursos necessrios,


restries do cronograma, duraes e
seqncias de atividades para criar o
cronograma do projeto.

Anlise de rede do cronograma


Mtodo do caminho crtico
Compresso do cronograma
Anlise de cenrio do tipo "e se?"
Nivelamento de recursos
Mtodo da cadeia crtica
Software de gerenciamento de projetos
Aplicao de calendrios
Ajuste de antecipaes e atrasos
Modelo de cronograma

Controle do cronograma

Controle das mudanas no cronograma do


projeto.

Relatrio de progresso
Sistema de controle de mudanas no cronograma
Medio de desempenho
Software de gerenciamento de projetos
Anlise da variao
Grficos de barras de comparao do cronograma

7 Custo
Processos envolvidos em estimativas, oramentos e controle dos custos, de modo que o projeto possa ser terminado dentro do
oramento aprovado.
Estimativa de custos
Desenvolvimento de uma estimativa dos
Estimativa anloga
custos dos recursos necessrios para
Determinar os valores de custo de recursos
terminar as atividades do projeto.
Estimativa bottom-up
Estimativa paramtrica
Software de gerenciamento de projetos
Anlise de proposta de fornecedor
Anlise das reservas
Custo da qualidade

Oramentao

Agregao dos custos estimados de


atividades individuais ou pacotes de
trabalho para estabelecer uma linha de
base dos custos.

Agregao de custos
Anlise das reservas
Estimativa paramtrica
Reconciliao dos limites de financiamento

Controle de custos

Controle dos fatores que criam as


variaes de custos e controle das
mudanas no oramento do projeto

Sistema de controle de mudanas nos custos


Anlise de medio de desempenho
Previso
Anlises de desempenho do projeto

TI para concursos

8 Qualidade
Processos e as atividades da organizao executora que determinam as polticas de qualidade, os objetivos e as responsabilidades, de
modo que o projeto satisfaa s necessidades para as quais foi empreendido.
Planejamento da qualidade Identificao dos padres de qualidade
Anlise de custo-benefcio
relevantes para o projeto e determinao
Benchmarking
de como satisfaz-los.
Projeto de experimentos
Custo da qualidade (CDQ)
Ferramentas adicionais de planejamento da qualidade
Realizar a garantia da
qualidade

Aplicao das atividades de qualidade


planejadas e sistemticas para garantir que
o projeto emprega todos os processos
necessrios para atender aos requisitos.

Ferramentas e tcnicas de planejamento da qualidade


Auditorias de qualidade
Anlise do processo
Ferramentas e tcnicas de controle da qualidade

Realizar o controle da
qualidade

Monitoramento de resultados especficos


do projeto a fim de determinar se eles
esto de acordo com os padres relevantes
de qualidade e identificao de maneiras
de eliminar as causas de um desempenho
insatisfatrio.

Diagrama de causa e efeito (Ishikawa ou diagramas


espinha de peixe)
Grficos de controle
Elaborao de fluxogramas
Histograma
Diagrama de Pareto
Grfico de execuo
Diagrama de disperso
Amostragem estatstica
Inspeo
Reviso de reparo de defeito

9 - RH
Processos que organizam e gerenciam a equipe do projeto. A equipe do projeto consiste nas pessoas com papis e responsabilida des
designadas para a concluso do projeto.
Desenvolver o plano de
Identificao e documentao de funes,
Organogramas e descries de cargos
recursos humanos
responsabilidades e relaes hierrquicas
Networking
do projeto, alm da criao do plano de
Teoria organizacional
gerenciamento de pessoal.
Mobilizar a equipe do
Obteno dos recursos humanos
Pr-designao
projeto
necessrios para terminar o projeto.
Negociao
Contratao ou mobilizao
Equipes virtuais
Desenvolver a equipe do
projeto

Melhoria de competncias e interao de


membros da equipe para aprimorar o
desempenho do projeto.

Habilidades de gerenciamento geral


Treinamento
Atividades de formao da equipe
Regras bsicas
Agrupamento
Reconhecimento e premiaes

Gerenciar a equipe do
projeto

Acompanhamento do desempenho de
membros da equipe, fornecimento de
feedback, resoluo de problemas e
coordenao de mudanas para melhorar o
desempenho do projeto.

Observao e conversas
Avaliaes de desempenho do projeto
Gerenciamento de conflitos
Registro de problemas

10 Comunicao
Processos relativos gerao, coleta, disseminao, armazenamento e destinao final das informaes do projeto de forma oportuna e
apropriada.
Identificar as partes
identificao de todas as pessoas ou
Anlise das partes interessadas
interessadas
organizaes que podem ser afetadas pelo
Opinio especializada
projeto e de documentao das
informaes relevantes relacionadas aos
seus interesses, envolvimento e impacto no
sucesso do projeto
Planejamento das
Determinao das necessidades de
Anlise dos requisitos das comunicaes
comunicaes
informaes e comunicaes das partes
Tecnologia das comunicaes
interessadas no projeto.
Distribuio das
informaes

Colocao das informaes necessrias


disposio das partes interessadas no
projeto no momento adequado.

Habilidades de comunicao
Sistemas de coleta e recuperao de informaes
Mtodos de distribuio das informaes
Processo de lies aprendidas

Gerenciar as expectativas
das partes interessadas

processo de comunicao e interao com


as partes interessadas para atender s
suas necessidades e solucionar as
questes medida que ocorrerem
Coleta e distribuio das informaes sobre
o desempenho. Isso inclui o relatrio de
andamento, medio do progresso e
previso.

Mtodos de comunicao
Registros de problemas

Ferramentas de apresentao de informaes


Coleta e compilao das informaes sobre o
desempenho
Reunies de avaliao do andamento
Sistemas de relatrios de horas

Relatrio de desempenho

TI para concursos

Sistemas de relatrios de custos

11 Riscos
Processos envolvidos em identificao, anlise e controle dos riscos do projeto.
Planejamento de
Deciso de como abordar, planejar e
Anlise e reunies de planejamento
gerenciamento de riscos
executar as atividades de gerenciamento
de riscos de um projeto.
Identificao dos riscos
Determinao dos riscos que podem afetar
Revises da documentao
o projeto e documentao de suas
Tcnicas de coleta de informaes
caractersticas.
Anlise da lista de verificao
Anlise das premissas
Tcnicas com diagramas
Anlise qualitativa dos
riscos

Priorizao dos riscos para anlise ou ao


adicional subseqente atravs de avaliao
e combinao de sua probabilidade de
ocorrncia e impacto.

Avaliao de probabilidade e impacto de riscos


Matriz de probabilidade e impacto
Avaliao da qualidade dos dados sobre riscos
Categorizao de riscos
Avaliao da urgncia do risco

Anlise quantitativa dos


riscos

Anlise numrica do efeito dos riscos


identificados nos objetivos gerais do
projeto.
Desenvolvimento de opes e aes para
aumentar as oportunidades e reduzir as
ameaas aos objetivos do projeto.

Tcnicas de representao e coleta de dados


Anlise quantitativa de riscos e tcnicas de modelagem

Estratgias para riscos negativos ou ameaas


Estratgias para riscos positivos ou oportunidades
Estratgia para ameaas e oportunidades
Estratgia para respostas contingenciadas

Acompanhamento dos riscos identificados,


monitoramento dos riscos residuais,
identificao dos novos riscos, execuo
de planos de respostas a riscos e avaliao
da sua eficcia durante todo o ciclo de vida
do projeto.

Reavaliao de riscos
Auditorias de riscos
Anlise das tendncias e da variao
Medio do desempenho tcnico
Anlise das reservas
Reunies de andamento

Planejamento de respostas
a riscos

Monitoramento e controle
de riscos

12 Aquisies
Processos envolvidos na compra ou aquisio de produtos, servios ou resultados para o projeto.
Planejar aquisies
Documentao das decises de compras
Anlise de fazer ou comprar
do projeto, especificando a abordagem e
Opinio especializada
identificando fornecedores em potencial
Tipos de contratos
Realizar as aquisies

Obteno de respostas de fornecedores,


seleo de um fornecedor e adjudicao de
um contrato

Administrao de
aquisies

gerenciamento das relaes de


aquisio, monitorando o desempenho do
contrato e realizao de mudanas e
correes conforme necessrio

Encerramentos de
aquisies

Terminar e liquidar cada contrato, inclusive


a resoluo de quaisquer itens em aberto,
e encerrar cada contrato aplicvel ao
projeto ou a uma fase do projeto.

1.3

Reunies com licitantes


Tcnicas de avaliao de propostas
Estimativas independentes
Opinio especializada
Publicidade
Pesquisa na internet
Negociaes das aquisies
Sistema de controle de mudanas no contrato
Anlise de desempenho conduzida pelo comprador
Inspees e auditorias
Relatrio de desempenho
Sistema de pagamentos
Administrao de reclamaes
Sistema de gerenciamento de registros
Tecnologia da informao
Auditorias de aquisio
Sistema de gerenciamento de registros

Planejamento e controle de mtricas de projeto


Mtricas so medidas quantitativas que podem produzir
informaes usadas para minimizar atrasos e riscos, e para
avaliar a qualidade durante o desenvolvimento.
Definies:
Medida - fornece uma indicao quantitativa da extenso,
quantidade, dimenso, capacidade ou tamanho de algum
atributo de um produto ou processo.
Ilustrao 1 Mtricas
Medio - ato de determinao de uma medida.
Mtrica - medida quantitativa do grau em que um sistema se encontra em relao a um determinado
atributo.

TI para concursos

Indicadores - mtrica ou combinao de mtricas que fornece uma compreenso de um processo,


projeto ou produto.
Tipos de mtricas:
Diretas - custo, esforo, linhas de cdigo (LOC), velocidade de execuo, memria utilizada,
defeitos reportados etc.
Indiretas - qualidade, funcionalidade, complexidade, eficincia, confiabilidade, manutebilidade etc.
O planejamento de mtricas pode ser feito em etapas.
Fase 1 caracterizao dos indicadores
Fase 2 medio
Fase 3 tratamento estatstico
Fase 4 monitoramento e anlise
Fase 5 gesto do processo
As tendncias so mais importantes de serem monitoradas do que qualquer valor absoluto no tempo. As
mtricas para determinados aspectos do projeto incluem:
Mtrica

Finalidade

Andamento em termos
de tamanho e
complexidade

Planejamento de iterao
Abrangncia

Exemplos de medidas/perspectivas
Nmero de classes
SLOC
Pontos de funo
Cenrios
Casos de teste
Essas medidas tambm podem ser coletadas por classe e por pacote
Quantidade de retrabalho por iterao (nmero de classes)

Estabilidade em termos Convergncia


de taxa de mudana
nos requisitos ou
implementao,
tamanho ou
complexidade

Adaptabilidade

Convergncia
"Retrabalho" de software

Nmero e tipo de mudanas (erro versus melhoria; interface versus implementao)


Essa medida tambm pode ser coletada por iterao e por pacote
Quantidade de retrabalho por iterao

Mdia de pessoa-horas/mudana
Essa medida tambm pode ser coletada por iterao e por pacote

Modularidade em
termos do escopo de
mudana

Convergncia
"Retalhamento" de software

Qualidade em termos
da quantidade e do tipo
de erros

Planejamento de iterao
Indicador de retrabalho
Critrio de release

Nmero de classes/categorias modificadas por mudana


Essa medida tambm pode ser coletada por iterao
Nmero de erros
Taxa de deteco de defeitos
Densidade de defeitos
Profundidade da herana
Acoplamento de classes
Tamanho da interface (nmero de operaes)
Nmero de mtodos substitudos
Tamanho do mtodo
Essas medidas tambm podem ser coletadas por classe e por pacote

1.4

Maturidade em termos
da freqncia de erros

Adequao/cobertura de
teste
Resistncia para uso

Perfil de despesas do
projeto versus
despesas planejadas

Viso financeira
Planejado versus real

Falha/horas de teste e tipo de falha


Essa medida tambm pode ser coletada por iterao e por pacote
Pessoa-dias/classe
Equipe em tempo integral por ms
Porcentagem do oramento j gasta

Mtodos de gerenciamento do tempo do projeto


Existem mtodos que objetivam formas de comprimir as duraes das atividades sem alterao no
escopo do projeto.
Crashing usado para diminuir a durao total do cronograma do projeto pelo menor custo adicional,
como reduo das duraes ou aumento da atribuio de recursos nas atividades do cronograma.

TI para concursos

Paralelismo ou fast tracking usado para tentar programar atividades em paralelo (simultneas), mas
costuma gerar retrabalho e aumenta os riscos. uma tcnica de compresso do cronograma de um
projeto especfico que altera a lgica de rede para sobrepor fases que normalmente seriam realizadas
em seqncia, como a fase de projeto e a fase de construo, ou para realizar atividades do cronograma
em paralelo.
Uma simulao do projeto utiliza um modelo que traduz as incertezas especificadas em um nvel
detalhado do projeto para seu impacto potencial nos objetivos do projeto. As simulaes so
normalmente realizadas usando a tcnica de Monte Carlo. Em uma simulao, o modelo do projeto
calculado muitas vezes (iterado), sendo os valores das entradas randomizados a partir de uma funo de
distribuio de probabilidades (por exemplo, custo dos elementos do projeto ou durao das atividades
do cronograma) escolhida para cada iterao a partir das distribuies de probabilidades de cada
varivel. Uma distribuio de probabilidades (por exemplo, custo total ou data de trmino) calculada.

1.5

10

Exerccios
1.

(ICMS-SP 2009) A respeito dos conceitos aplicados aos Projetos, segundo o PMBOK, INCORRETO afirmar:1
(a) A equipe do projeto, como uma unidade de trabalho, raramente sobrevive ao projeto.
(b) Um projeto um esforo contnuo que visa manter um servio em funcionamento. xx
(c) Geralmente, o termo "temporrio" no se aplica ao produto, servio ou resultado criado pelo projeto.
(d) Pode ser classificado como projeto aquele que do tipo de pesquisa que desenvolve um conhecimento.
(e) Os projetos podem criar uma capacidade de realizar um servio.

2.

(ICMS-SP 2009) So entradas para o processo de Planejamento da Qualidade (PMBOK):


(a) Fatores ambientais da empresa, Ativos de processos organizacionais e Declarao do escopo do
xx
projeto.
(b) Anlise de custo-benefcio, Projeto de experimentos e Mtricas de qualidade.
(c) Plano de melhorias no processo, Linha de base da qualidade e Mtricas de qualidade.
(d) Plano de melhorias no processo, Fatores ambientais da empresa e Listas de verificao da qualidade.
(e) Plano de gerenciamento da qualidade, Fatores ambientais da empresa e Anlise de custo-benefcio.

3.

(ICMS-SP 2009) No PMBOK, a tcnica que compara as realizaes tcnicas durante a execuo do projeto
com as do cronograma do plano de gerenciamento do projeto, podendo usar parmetros tcnicos importantes
do produto desenvolvido pelo projeto como uma mtrica de qualidade, sendo que os valores medidos fazem
parte das informaes sobre o desempenho do trabalho, denominada3
(a) Critical Chain Method.
(b) Probability and Impact Matrix.
(c) Work Performance Information.
(d) Performance Measurement Baseline.
(e) Technical Performance Measurement. xx

4.

(ICMS-SP 2009) Planos mais exatos e completos, resultantes de sucessivas iteraes do processo de
planejamento e estimativas mais exatas, elaboradas medida que o projeto se desenvolve, so produtos da
tcnica aplicada para melhoria e detalhamento contnuos dos planos. Essa tcnica, no PMBOK,
denominada4
(a) Loop de rede.
xx
(b) Elaborao progressiva.
(c) Estrutura Analtica dos Recursos.
(d) Gerenciamento de Portflios.
(e) Estimativa paramtrica.

5.

Segundo o PMBOK, as etapas de iniciao, planejamento, execuo, monitorao/controle e encerramento


representam apenas o 5
(a) ciclo de vida dos projetos ou ciclo de gerenciamento de projetos.
(b) grupo de processos dos projetos ou ciclo de gerenciamento de projetos.
(c) grupo de processos dos projetos ou ciclo de vida dos projetos.
(d) grupo de processos do gerenciamento de projetos ou ciclo de vida dos projetos.
(e) grupo de processos do gerenciamento de projetos ou ciclo de gerenciamento de projetos. xx

6.

Os processos do PMBOK: criao da estrutura analtica do projeto (EAP) e verificao do escopo do projeto
devem ser realizados, respectivamente, nas etapas de 6
(a) planejamento e execuo.
xx
(b) planejamento e monitorao/controle.
(c) iniciao e execuo.
(d) iniciao e monitorao/controle.
(e) iniciao e encerramento.

TI para concursos

11

7.

Considere a seguinte definio com respeito gerncia de projetos: Ferramenta de decomposio do trabalho
do projeto em partes manejveis. uma estrutura em forma de rvore exaustiva, hierrquica (de mais geral
para mais especfica ) de deliverables e tarefas que precisam ser feitas para completar um projeto. Tal a
7
definio de
(a) Histogram.
(b) Workflow.
(c) Timesheet.
(d) Work Breakdown Structure.xx
(e) Flowchart.

8.

Um instrumento facilitador do planejamento de projeto que o desmembra em atividades menores que podem
8
ser mais facilmente dimensionadas em relao a tempo de execuo, recursos e custos, o
(a) Flowchart.
(b) Organization Chart.
(c) Workflow.
(d) Histogram.
xx
(e) Work Breakdown Structure.

9.

De acordo com o corpo de conhecimento da gerncia de projetos, as simulaes para anlise de risco de
prazos so possveis utilizando 9
(a) o Arrow Diagramming Method.
xx
(b) a tcnica Monte Carlo.
(c) o modelo WBS.
(d) a anlise de custo/benefcio.
(e) o Project Charter.

10.

O WBS, Word Breakdown Structure, a principal ferramenta de gerenciamento de


(a) escopo do projeto.xx
(b) integrao dos elementos do projeto.
(c) pessoal envolvido com o projeto.
(d) comunicao das informaes do projeto.
(e) qualidade do projeto.

11.

Considere a seguinte figura:


No contexto da gerncia de projetos de software, o
diagrama parcialmente mostrado na figura representa,
tipicamente, 11
(a) um PERT.
(b) um grfico de Gantt.
(c) uma Work Breakdown Structure.xx
(d) um Project Charter.
(e) um Flowchart.

12.

De acordo com o corpo de conhecimento da gerncia de


projeto, a necessidade de traduzir as necessidades
implcitas em necessidades declaradas, atravs da gerncia
12
do escopo do projeto,
(a) um aspecto crtico da gerncia da qualidade, no contexto do projeto.xx
(b) objeto de avaliao da gerncia do custo do projeto.
(c) dispensada se for elaborado um planejamento de respostas aos riscos.
(d) destacada durante a medio de desempenho.
(e) um aspecto crtico da anlise de precedncia de tarefas.

13.

De acordo com o corpo de conhecimento da gerncia de projeto, para estimar os custos totais, quando ainda
existe uma quantidade limitada de informaes detalhadas sobre o projeto (por exemplo, nas fases iniciais),
freqentemente 13
(a) elaborado um modelo paramtrico.
xx
(b) usada uma estimativa por analogia.
(c) usada uma estimativa bottom-up.
(d) elaborada uma anlise de precedncia.
(e) elaborada uma anlise da variao.

14.

Existem mtodos que objetivam formas de comprimir as duraes das atividades sem alterao no escopo do
projeto. Um deles usado para quando existem negociaes de agenda e custos para determinar como (e se)
fazer a maior compresso para o menor custo. Outro usado para tentar programar atividades em paralelo
(simultneas), mas costuma gerar retrabalho e aumenta os riscos. So usual e respectivamente denominados
14
de mtodos
(a) crashing e what-if.
(b) de Monte Carlo e what-if.
(c) fast tracking e de Monte Carlo.
(d) crashing e fast tracking.xx
(e) what-if e crashing.

10

TI para concursos

15.

Para um gerenciamento de projeto de informtica bem sucedido, a ordem de execuo das atividades deve ser
15

(a)
(b)
(c)
(d)
(e)

12

planejamento, integrao, organizao, medio e reviso.


xx
planejamento, organizao, integrao, medio e reviso.
organizao, planejamento, integrao, medio e reviso.
organizao, planejamento, medio, integrao e reviso.
planejamento, organizao, medio, reviso e integrao.

16.

(ARCE FCC 2006) O fator de mximo desempenho de um projeto est diretamente relacionado ao fator de 16
(a) escopo limitado.
(b) escopo genrico.
(c) tempo reduzido.
xx
(d) custo alto.
(e) tempo excessivo.

17.

(CVM FCC 2006) Dentre os fatores que afetam os projetos, o fator performance se aproxima do mximo, ou
ponto timo, quando relacionado ao fator 17
xx
(a) custo alto.
(b) tempo reduzido.
(c) tempo excessivo.
(d) escopo limitado.
(e) escopo genrico.

18.

Duas atividades de um projeto podem ocorrer simultaneamente quando o inter-relacionamento das mesmas
do tipo 18
(a) incio para incio (SS) ou trmino para incio (FS).
(b) trmino para trmino (FF) ou trmino para incio (FS).
(c) incio para incio (SS) ou trmino para trmino (FF).xx
(d) incio para trmino (SF) ou trmino para trmino (FF).
(e) trmino para incio (FS) ou incio para trmino (SF).

19.

Os produtos a serem entregues no mais baixo nvel da estrutura do projeto (WBS) geralmente so
(a) pacotes de trabalho.xx
(b) planos do projeto.
(c) fases do projeto.
(d) recursos disponveis.
(e) cronogramas do projeto.

20.

Segundo o uso universal dos conceitos de gerenciamento de projetos, um programa 20


(a) um empreendimento no repetitivo de eventos numa seqncia clara e lgica, com incio, meio e fim.
(b) parte de um projeto ou subdiviso ttica de fcil gerenciamento e controle.
(c) um subprojeto, desvinculado de um projeto, que pode ser terceirizado.
(d) um conjunto integrado de projetos que tem misses e objetivos comuns. xx
(e) um conjunto de subprojetos, que podem ter vidas prprias isoladamente.

21.

No ciclo da vida de um projeto, so aplicveis todos os nove processos componentes da rea de


gerenciamento de projetos somente na fase de 21
(a) iniciao.
(b) finalizao.
(c) planejamento.xx
(d) execuo.
(e) controle.

22.

Na determinao de cronogramas utilizando os modelos PERT e CPM, o caminho crtico representa 22


(a) a estimativa de tempo mais provvel para o conjunto de tarefas do projeto.
(b) o trmino mais breve da cada tarefa do projeto.
(c) os limites de tempo que definem o incio e o trmino da cada tarefa.
(d) uma cadeia de tarefas que determina a durao do projeto.xx
(e) uma rede de todas as tarefas desde o comeo at o final de um projeto.

23.

(ISS SP 2012) Segundo o PMBOK, quando os projetos tm vrias fases, estas so parte, em geral, de um
processo sequencial projetado para garantir um controle adequado do projeto e obter o produto, servio ou
resultado desejado. Existem trs tipos bsicos de relao entre estas fases: iterativa, sequencial e 23
xx
(a) sobreposta.
(b) randmica.
(c) indexada.
(d) modular.
(e) unilateral.

19

TI para concursos

13

24.

(ISS SP 2012) Segundo o PMBOK, projetos variam em tamanho e complexidade, porm,


independentemente de seu tamanho ou complexidade, todos podem ser mapeados para uma estrutura de
ciclo de vida contendo quatro fases. A segunda fase desse ciclo de vida chamada de24
(a) modelagem.
xx
(b) organizao e preparao.
(c) execuo do trabalho do projeto.
(d) elicitao de requisitos.
(e) anlise de riscos.

25.

(TCE-RJ 2012) De acordo com o PMBOK 4 ed, um projeto pode ser dividido em fases, sendo que:
xx
(a) o nvel de incerteza do projeto maior nas fases iniciais;
(b) a capacidade das partes interessadas de influenciarem as caractersticas finais do produto vai
aumentando medida que o projeto vai se desenvolvendo nas diversas fases;
(c) os custos do projeto so mais altos na fase final;
(d) so geralmente definidas por critrios subjetivos do solicitante do projeto;
(e) o custo de promover mudanas no projeto maior na fase inicial, dadas as indefinies ainda existentes.

26.

(TCE-RJ 2012) O PMBOK define reas de conhecimento para gesto de projetos. Os processos de estimativa
de durao das atividades, do envio de relatrios de desempenho aos patrocinadores e do encerramento de
contratos pertencem, respectivamente, s reas de gerenciamento:26
(a) do tempo, de comunicaes e de aquisies;xx
(b) de integrao, de escopo e de custo;
(c) do tempo, de aquisies e de custo;
(d) do tempo, da qualidade e de aquisies;
(e) de risco, de comunicaes e de custo.

27.

(RFB Analista Tributrio 2012) Com relao ao Escritrio de Projetos (Project Management Office, PMO), a
verso 4 do Guia PMBOK informa que ele um corpo ou entidade organizacional a que so atribudas varias
responsabilidades relacionadas ao gerenciamento27
(a) descentralizado e coordenado dos projetos sob seu domnio.
(b) descentralizado e independente dos projetos sob seu domnio.
(c) descentralizado e autnomo dos projetos sob seu domnio.
(d) centralizado e autnomo dos projetos sob seu domnio.
(e) centralizado e coordenado dos projetos sob seu domnio. xx

28.

(RFB Analista Tributrio 2012) Na verso 4 do Guia PMBOK, o grupo de processos de planejamento inclui
o processo 28
(a) Identificar as partes interessadas.
(b) Coletar os requisitos.xx
(c) Mobilizar a equipe do projeto.
(d) Distribuir informaes.
(e) Verificar o escopo.

29.

(RFB Analista Tributrio 2012) O Guia PMBOK na sua verso 4 apresenta as reas de conhecimento. Uma
delas a de gerenciamento da integrao do projeto. So processos desta rea: 29
(a) Desenvolver o termo de abertura do projeto; Encerrar o projeto ou fase. xx
(b) Orientar e gerenciar a execuo do projeto; Coletar os requisitos.
(c) Sequenciar as atividades; Realizar o controle integrado de mudanas.
(d) Desenvolver o plano de gerenciamento do projeto; Desenvolver o cronograma.
(e) Realizar o controle integrado de mudanas; Controlar os custos.

25

TI para concursos

Gesto de Processos de Negcio (BPM)


A administrao cientfica de Taylor pode ser interpretada como sendo a primeira onda da gesto de
processos. Muitos dos conceitos de Taylor servem como base para os princpios de modelagem de
processos, e quase um sculo depois, continuam vivos e fortes nos pressupostos das organizaes
(DAVENPORT, 1994).
A segunda onda, veio com a reengenharia de Michael Hammer (1994), baseada na idia central de que
era possvel melhorar drasticamente o desempenho das empresas por meio de mudanas radicais nas
operaes. A popularizao do conceito disseminou-se durante a dcada de 90, assim como outras
tcnicas de melhorias de processos e workflows centrados em documentos (HAMMER, 2001).
Smith e Fingar (2007) descrevem Business Process Management (BPM) como sendo a terceira onda da
gesto e processos de negcio. Trata-se de um modelo que possibilita que empresas e colaboradores
criem e otimizem processos de negcio em tempo real. Atravs de processos geis, cadeias de valor
poderiam ser monitoradas e continuamente melhoradas. Essa onda no reengenharia de processos de
negcio, integrao de aplicaes ou gesto de workflow uma sntese e tambm uma extenso
4
destas tcnicas em um modelo unificado (SMITH; FINGAR, 2007).
O Business Process Management (BPM) ou Gerenciamento de Processos de Negcio um conceito
que une gesto de negcios e tecnologia da informao com foco na otimizao dos resultados das
organizaes atravs da melhoria dos processos de negcio. So utilizados mtodos, tcnicas e
ferramentas para analisar, modelar, publicar, otimizar e controlar processos envolvendo recursos
5
humanos, aplicaes, documentos e outras fontes de informao.
Um processo de negcio uma sequncia de tarefas que, ao serem executadas, transforma insumos em
um resultado com valor agregado.
Distingue-se do conceito de BI (business intelligence), pois este monitora as informaes que do
suporte ao negcio, enquanto aquele monitora os processos que o compe. O BI uma ferramenta til
gesto de processos de negcios.

2.1

Tcnicas de anlise de processos


Desenvolveram-se linguagens voltadas para a e especificacao de modelos, selecionadas por seus
potenciais ou por serem padroes bem estabelecidos de pesquisa ou de mercado.
Business Process Modeling Notation (BPMN): A BPMN foi criada para projetar e modelar processos
de negocio e suas transformacoes na linguagem de execucao Process Modeling Language (BPML).
Business Process Definition Metamodel (BPDM): A BPDM foi desenvolvida pelo Object Management
Group (OMG) e oferece um meta-modelo generico para processos de negocio. A BPDM nao prove
uma notacao grafica propria, sua intencao e apenas definir um meta-modelo generico com o objetivo
de apoiar o mapeamento entre diferentes ferramentas e linguagens.
UML 2.0 Activity Diagram (AD): O AD da UML foi projetado para modelar processos de negocio e
fluxos em sistemas de software. Sua origem esta embasada no desenvolvimento de software.
Event Driven Process Chain (EPC): O EPC foi desenvolvido para modelar processos de negocio que
sejam facilmente entendidos e utilizados pelo pessoal de negocios. Seus elementos basicos sao
funcoes e eventos.
Integrated DEFinition Method 3 (IDEF3): IDEF3 foi projetado para modelar processos de negocio e
sequencias de um sistema, provendo duas perspectivas, o esquema do processo e o esquema de
objetos.
Petri Net: A rede de Petri foi projetada para modelagem, analise e simulacao de sistemas dinamicos,
atraves de procedimentos concorrentes e nao deterministicos. Redes de Petri sao utilizadas para
modelar workflows, atraves de grafos.
Role Activity Diagram (RAD): O RAD tem sua origem na modelagem e coordenacao, sendo usado
para modelar processos de negocio com enfase nos papeis, atividades e interacoes com eventos
externos.
Descrevemos em seguida algumas tcnicas.

2.1.1

BPMN - Modelagem de processos


Realizada pelos BPMS, divide-se em modelagem, simulao, execuo, controle e otimizao.
Um aplicativo do tipo BPMS, tipicamente, inclui o mapeamento dos processos de negcio ponta-a-ponta,
desenho dos fluxos e formulrios eletrnicos, definio de workflow, regras de negcio, integradores,
monitorao em tempo real das atividades e alertas. uma poderosa ferramenta de gesto, para

http://tede.ucs.br/tde_arquivos/5/TDE-2009-11-30T151910Z-318/Publico/Dissertacao%20Rogerio%20Tessari.pdf
http://pt.wikipedia.org/wiki/Business_Process_Management
14
4
5

TI para concursos

garantir que os processos esto sendo efetivamente executados como modelados, contribuindo para os
objetivos da organizao.
A modelagem de processos feita no prprio BPMS. Alguns destes seguem a notao mais usada
atualmente, o BPMN (Business Process Modeling Notation). Esta notao trata-se de uma srie de
cones padres para o desenho de processos, o que facilita o entendimento do usurio. A modelagem
uma etapa importante da automao pois nela que os processos so descobertos e desenhados.
nela tambm que pode ser feita alguma alterao no percurso do processo visando a sua otimizao.
Aps o desenho e o estabelecimento dos usurios responsveis pela concluso de cada tarefa, pode ser
feita uma simulao, onde se pode testar se as regras pr-estabelecidas esto de acordo com o objetivo
da empresa e se as tarefas esto sendo encaminhadas para as pessoas corretas.
A execuo do processo ocorre aps as etapas anteriores j terem sido realizadas. O BPMS utilizado faz
com que as tarefas sejam enviadas para os seus devidos responsveis, controlando o seu tempo de
execuo por pessoa e pelo processo em geral. Podem ser utilizadas tambm regras de negcio
(Business Rules) pr-estabelecidas.
O controle ideal de BPM aquele que est presente durante todas as etapas do processo: antes,
durante e depois. Desde o incio da modelagem at a anlise ps-concluso da execuo, o controle
deve ser realizado. Um tipo de controle que existe em alguns BPMS so relatrios 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
concludo. H tambm relatrios de fluxos concludos, onde se pode ter uma noo geral de como se
desenvolveu o processo. Alguns softwares apresentam grficos e relatrios com bastantes detalhes dos
processos.
A otimizao tem crucial importncia quando se trata de BPM. essencial para que sejam feitas
melhorias nos processos de modo a alcanar resultados positivos mais rapidamente, melhorando o
servio aos clientes e, possivelmente, com menores custos. Depende, obviamente, das etapas
anteriores, principalmente do controle, onde deve haver uma busca pela perfeio.6
O Business Process Modeling Notation, em portugus Notao de Modelagem de Processos de
Negcio, uma notao da metodologia de gerenciamento de processos de negcio e trata-se de uma
srie de cones padres para o desenho de processos, o que facilita o entendimento do usurio.
A modelagem uma etapa importante da automao, pois nela que os processos so descobertos e
desenhados. nela tambm que pode ser feita alguma alterao no percurso do processo visando a sua
otimizao.
A notao tambm pode ser utilizada para a modelagem de Arquitetura de Processos.
O objetivo do BPMN de apoiar a gesto de processos de negcios tanto para usurios tcnicos e
usurios de negcios, fornecendo uma notao que intuitiva para os usurios corporativos ainda capaz
de representar a semntica complexa do processo.

http://pt.wikipedia.org/wiki/Gest%C3%A3o_de_processos_de_neg%C3%B3cio
15
6

TI para concursos

Ilustrao 2 Smbolos BMPN

2.1.2

Elementos
A modelagem em BPMN feita atravs de diagramas simples, com um pequeno conjunto de elementos
grficos. Isto facilita que os usurios de negcio, bem como os desenvolvedores, entendam o fluxo e o
processo. As quatro categorias bsicas de elementos so as seguintes:
Objetos de Fluxo definem o comportamento do fluxo. Fazem a movimentao das informaes
atravs de aes.
Eventos Qualquer coisa que acontece durante o fluxo. Aes (trigger) que interferem no fluxo
(result), tipicamente prazos, tambm podendo ser uma chamada de um sistema externo (web
service) ou alguma alterao no banco de dados (watching). Representado por um crculo. H trs
tipos de eventos: incio, intermedirio e fim.
Atividades Aes (sub-processos ou tarefas) realizadas pelos usurios, chamados de atores,
normalmente por tela de algum programa de computador. Representada por um retngulo
arredondado.
Gateways Controla a convergncia e divergncia da sequncia de fluxos e atividades no fluxo.
Determina ramificaes (branch), bifurcaes (forking), mistura (merging) e junes (join) de
caminhos. Representado por um losango.
Objetos de Conexo
Fluxo de Sequncia seta em linha contnua ligando dois objetos, indica a ordem de execuo
dos objetos.
Fluxo de Mensagem seta em linha tracejada indicando o fluxo de mensagens entre participantes
Associao linha ou seta em linha pontilhada indicando uma ligao entre uma informao,
normalmente uma anotao, e um artefato.
Swim lane uma rea de agrupamento de objetos de fluxo representado por uma faixa que vai da
esquerda direita da pgina, com um nome para a faixa em seu lado esquerdo.
Pool indica um participante, setor, departamento ou qualquer lugar onde se encontram os atores.
Um pool pode apresentar detalhes internos do processo (white box) ou pode ter nenhum processo
(black box). A interao entre pools feita atravs de fluxos de mensagens. Nenhum fluxo de
sequncia pode ser associado a black boxes, mas os fluxos de mensagem podem lig-los.
Lane subdiviso de uma pool.
Dados possuem informaes que os objetos de fluxo necessitam para serem realizadas

16

TI para concursos

Objetos de dados informaes armazenadas


Dados de entrada informaes solicitadas
Dados de sada informaes produzidas em uma atividade ou evento
Armazenamento gravao dos dados
Artefatos informaes adicionais sobre o fluxo
Grupo agrupamento de elementos de uma mesma categoria para fins de entendimento, sem
efeito sobre o fluxo. Representado por um retngulo arredondado tracejado.
Anotao uma observao para facilitar o entendimento do fluxo para o leitor. Representado por
uma linha de associao terminada por um colchete e o texto.
Mensagem informao enviada entre dois participantes. Representado por cone de uma carta.
Estas quatro categorias de elementos nos do a oportunidade de fazer um diagrama de processos de
negcio simples (BPD).

Ilustrao 3 Exemplo de Fluxo utilizando pool, lanes, evento de incio e fim, tarefas e gateway

2.1.3

Fluxograma
Diagrama que descreve a sequncia de atividades de um processo empresarial atravs de uma
simbologia padronizada, utilizando retngulos para representar atividades, losangos para pontos de
deciso e setas para indicar o fluxo. Estes simbolos vm acompanhado de textos explicativos.
Fcil de utilizar, mas pouco apropriado para representar processos de grande complexidade e
divergncias.
O fluxograma considera o processo do ponto de vista da empresa.

2.1.4

Service blueprint
Tcnica de mapeamenteo de servios derivado do fluxograma que considera o aspecto de interao com
o cliente.
um mapa de todas as transaes que constituem o processo de entrega do servio.
Divide-se em duas regies separadas por uma linha, chamada de linha de visibilidade.
Na parte de cima da linha, a rea de evidncias fsicas percebida pelo cliente, as suas aes e
interaes com os empregados. Na parte de baixo, encontram-se as aes dos empregados e os
processos de suporte que so invisveis para o cliente.

http://blog.iprocess.com.br/2012/05/bpmn-modelando-corretamente-o-fluxo-de-sequencia-de-atividades/ por Kelly Sganderla


17
7

TI para concursos

As evidncias fsicas, mostradas na parte de cima, identificam elementos que o cliente pode usar como
indicador da qualidade do servio. Cada conexo vertical atravs da linha de interao indica um ponto
de contato. Estes pontos funcionam como o momento da verdade de cada servio e podem ser usados
como pontos de potencial falhas no sistema de servio.

Fonte: http://www.lgti.ufsc.br/public/luciano.pdf
Apesar de ser mais evoluido do que os fluxogramas, tambm no consegue representar uma descrio
completa da experincia com o cliente. O foco est na tarefa e no no cliente.

2.1.5

Mapa do servio
Forma visual de trs elementos crticos de servios: processso de entrega de servio, os papis dos
clientes e empregados e elementos visveis de servio. A criao do mapa requer a identificao de
evidncias fsicas do servio, indicadores de qualidade, as pessoas envolvidas e o fluxo operacional de
atividades de entrega de servios. Foca os servios do ponto de vista do consumidor.
uma evoluo do service blueprint.
Logo acima da linha de visibilidade, h uma linha horizontal que indica o contato do cliente com os
empregados de atendimento. Abaixo da linha de visibilidade h outra que indica a relao entre o
suporte e o processso de entrega de servio. Mais abaixo, outra linha separa a gerncia do suporte.

O mapa pode ser lido horizontalmente para entender as aes ou passos realizados pelos clientes e
empregados, ou lido verticalmente para compreender as aes de suporte, os processos e estruturas.

2.1.6

IDEF
Famlia de mtodos de estruturar e analisar uma empresa. Utilizam-se de diagramas para representar os
processos.

18

TI para concursos

Cada tarefa representada por um retngulo. Cada lado representa uma informao de entrada, sada
de produtos e/ou informaes, recursos disponveis e condies para ativao.
A nfase no est na sequncia, mas no contedo das atividades e nos recursos envolvidos no
processo. Exemplo:
Controle

Entradas

Processo

Sadas

Mecanismo

2.1.6.1

IDEF0
Mtodo de modelagem funcional usado para processos associados a decises, aes e atividades.

2.1.6.2

IDEF1
Mtodo de modelagem de informao, para expresso dos requisitos de um sistema.

2.1.6.3

IDEF3
Mtodo de captura da descrio do processo, que relaciona causa e efeito entre processos.

2.1.6.4

IDEF4
Mtodo de desenho orientado a objeto, que auxilia no projeto de sistemas orientados a objetos.

2.1.6.5

IDEF5
Mtodo de identificao de ontologias associadas aos processos e informaes.

2.1.6.6

IDEF9
Mtodo para auxiliar na identificao de restries associadas a um sistema ou processo.

2.1.7

Estrutura de processamento de clientes


Modelo genrico de atividades-chave que so comuns
maioria dos processos de servios. Visa especificamente o
fluxo de clientes, indicando apenas atividades com eles.
So identificadas sete atividades-chave:
seleo, cliente decide a escolha
ponto de entrada, contato com a operao escolhida
tempo de resposta, tempo de espera para que o sistema
responda
ponto de impacto, cliente atendido
prestao de servio, o servio prestado
ponto de partida, o cliente sai do processo
acompanhamento, atividades sobre o cliente aps a
concluso do servio

2.1.8

Walk-through-audit
Mtodo de auditoria, que consiste em uma srie de questes
dirigidas aos clientes, e gerentes de servios, para avaliao sistemtica da viso do cliente sobre o
servio prestado.
Utilizam-se questes estruturadas que avaliam cada etapa do processo em uma escala de um a cinco,
respondidas durante ou imediatamente aps o servio, ou aplicadas em clientes da concorrncia.
Alm de avaliar a percepo do cliente, tambm permite analisar a lacuna entre a opinio do cliente e da
gerncia e entre a empresa e a concorrncia.
Funciona em conjunto com alguma outra tcnica grfica.

19

TI para concursos

2.1.9

Anlise da transao de servio (STA Service Transaction Analysis)


Mtodo de avaliao do processo do ponto de vista do cliente, combinando quatro elementos: o conceito
do servio, o processo do servio, a avaliao da qualidade em cada transao e a interpretao do
servio pelo cliente. Utiliza um formulrio denominado folha de anlise da transao de servio.
Pessoas fazendo papel de clientes caminham ao longo do processo para analisar como o cliente poderia
avaliar cada transao, usando uma mensagem curta e uma escala de trs pontos: (-) insatisfeito, (0)
satisfeito ou (+) muito satisfeito.

2.2

Portais corporativos e colaborativos


Um portal um site na internet que funciona como centro aglomerador e distribuidor de contedo para
uma srie de outros sites ou subsites dentro, e tambm fora, do domnio ou subdomnio da empresa
gestora do portal.8
Na sua estrutura mais comum, os portais constam de um motor de busca, um conjunto, por vezes
considervel, de reas subordinadas com contedos prprios, uma rea de notcias, um ou mais fruns
e outros servios de gerao de comunidades e um diretrio, podendo incluir ainda outros tipos de
contedos.
Para construir um portal aconselhvel utilizar ferramentas de gesto de contedo (CMS) em vez de
tradicionais editores de HTML. Estes recursos ajudam a concentrar o trabalho num nvel mais abstrato,
na medida em que alguns aspectos tecnolgicos j so automatizados. Uma das vantagens no uso
dessas ferramentas o fato de, na maior parte dos casos, possibilitar a troca do modelo de pgina sem
que o contedo e a sua disposio no site sejam alterados; apenas a aparncia modificada.
Os Portais Corporativos tm entre suas caractersticas, a funcionalidade de oferecer acesso simplificado
s informaes e s aplicaes, por utilizar o ambiente Web como sua camada de apresentao. Desta
forma, a interao com o usurio se torna mais amigvel e as informaes apresentadas de forma mais
simples e compreensvel.

http://pt.wikipedia.org/wiki/Portal_(internet)
20
8

TI para concursos

Os Portais podem oferecer acesso a um grande nmero de colaboradores s informaes estruturadas


(informaes armazenadas em sistemas e bases de dados, como por exemplo, datawarehouses e
sistemas legados), assim como s informaes no estruturadas (informaes armazenadas em
arquivos de texto, planilhas eletrnicas, arquivos de e-mail, dentre outros). O acesso a estas informaes
estruturadas ou no estruturadas se d na maioria das vezes atravs do uso de APIs (Application
Program Interfaces), tambm chamadas de applets, portlets, adaptadores ou conectores, sendo o
acesso s informaes estruturadas mais facilitado, pois atravs das linguagens de programao podese utilizar de APIs que facilitem ao colaborador acessar as informaes atravs de interfaces intuitivas e
amigveis. J para acessar as informaes no estruturadas, necessrio utilizar, em conjunto com as
APIs, mtodos de categorizao e taxonomia, mecanismos de busca.
Os mtodos de categorizao e taxonomia visam organizar as informaes, criando informaes sobre
as informaes (metadados) para assim, os mecanismos de busca retornarem as informaes que o
usurio deseja de forma mais precisa.
Existem quatro tipos de portais:
Portais Informativos - Portais que levam informaes ao usurios;
Portais Colaborativos - Portais que habilitam as equipes de trabalho estabelecerem reas de projetos
virtuais ou comunidades atravs de ferramentas de colaborao;
Portais Especialistas - Portais que conectam pessoas com base em suas experincias, interesses e
informaes que precisam;
Portais do Conhecimento - Portais que combinam todas as caractersticas dos anteriores para prover
contedo personalizado com base no que cada usurio faz.
Em linhas gerais, os Portais Corporativos (como ambiente de integrao de informaes e sistemas)
facilitam a busca por informaes nas diversas fontes disponveis, agiliza a tomada de deciso e pode
gerar mais produtividade com a reduo no tempo dispendido na procura pelas informaes.
O termo Portal Corporativo, em relao internet, comeou a ser utilizado para definir os Portais de
pesquisa, como Google e Yahoo. Depois de um certo tempo, os provedores de acesso internet
passaram a oferecer contedo para seus assinantes, na tentativa de ter algum diferencial, j que o
acesso discado era commodity.9
Os Portais Corporativos so o resultado de uma fuso de aplicaes de software que consolidam,
gerenciam, analisam e distribuem a informao dentro e fora da organizao. (FIRESTONE, 2008)10
Um Portal Corporativo ou um Enterprise Information Portal um conceito para um website que serve
como interface ou canal nico para a informao de uma companhia e sua base de conhecimento para
seus colaboradores e, possivelmente, para clientes, parceiros de negcios e tambm para o pblico em
geral.

Ilustrao 4 Portal Corporativo

Os Portais Corporativos proporcionam uma plataforma de e-business integradora de variadas fontes de


informao. Com a evoluo do Portal, parte do conhecimento pode ser transferido para o ambiente
externo (clientes, fornecedores e parceiros).
http://www.portalcolaborativo.com.br/midias-sociais/home/comunidades-em-portais.html
http://kmol.online.pt/artigos/2008/11/06/portais-corporativos-e-sua-importancia-estrategica-na-gestao-do-conhecimento-das-organizacoes
21
9

10

TI para concursos

Para se classificar um software como Portal Corporativo necessrio ter:

Access/search (poderosos sistemas de busca e indexao);


Categorization (categorizao do conhecimento);
Collaboration (aplicaes para colaborao);
Personalization (cada usurio um usurio diferente);
Expertise and profiling (perfis de acordo com competncias);
Application integration (integrao com demais aplicaes);
Security (segurana para todas as aplicaes e login nico).

Outra caracterstica muito comum em um Portal Corporativo, so os Portlets ou Gadgets, que so


utilizados para integrao de aplicaes ou para personalizao. Cada Portlet pode ser um pedao de
pgina e nele possvel aplicar configuraes de segurana, personalizao, etc. Colaborao a
palavra de ordem em Intranets e Portais Corporativos.
Um Portal Colaborativo um portal corporativo com forte explorao de recursos colaborativos, ou seja,
de recursos que permitem a colaborao entre funcionrios de uma ou mais empresas. Um ambiente de
colaborao deve permitir que pessoas que no se conheam e que mesmo vivam em pases diferentes
possam trabalhar de forma colaborativa usufruindo de recursos do portal colaborativo.
Portlets de Colaborao geralmente esto disponveis em boas ferramentas de gerenciamento de
Intranets e Portais Corporativos. Os mais comuns so: enquetes, forums, chats, workplaces, wikis,
dentre outros. Tambm softwares sociais e comunidades virtuais contribuem para a colaborao
corporativa.
Os softwares de portais corporativos devem fornecer solues colaborativas e permitir a integrao de
aplicativos corporativos que promovam e construam a colaborao corporativa. Um portal corporativo
pode ser considerado um portal colaborativo quando o uso de seus recursos colaborativos supera o uso
do contedo e pginas de contedo. O mdulo de gerenciamento de contedo ou mesmo o gerenciador
de contedo pode contribuir na produo de contedo colaborativo ou pelo menos suportar a
colaborao atravs do gerenciamento de contedo aliado aos portlets (componentes) colaborativos.
A partir da metade de dcada de 90, com o surgimento dos portais de Internet para navegao/mdia,
houve uma rpida evoluo com a utilizao da Internet no suporte aos negcios. Desta forma,
comeam a surgir, no final de dcada de 90, os portais de Internet chamados B2C (business to
consumer), que suportam o comrcio eletrnico entre varejistas e consumidores da Web, e os portais
corporativos B2B (business to business - extranet) e B2E (business to employee) (Figura 1). Os portais
B2B suportam as transaes eletrnicas entre as empresas; os participantes so parceiros comerciais e
possuem uma relao de negcios pr-estabelecida. J atravs do portal B2E, os funcionrios obtm
informaes e servios de carter profissional e pessoal que lhes interessam.11

2.3

GED - Gerenciamento Eletrnico de Documentos 12


GED definido como a "tecnologia que facilita o armazenamento, localizao e recuperao de
informaes estruturadas ou no, em formato digital, durante todo o seu ciclo de vida". De forma geral,
essas solues so compostas pelos mdulos de Document Imaging, COLD/ERM e Document
Management.
Document Imaging (DI) Gerenciamento de Imagens: esse mdulo responsvel pela transformao do
documento papel em uma imagem digital, permitindo a sua manipulao nesse ambiente. Esse processo
abrange trs etapas: a digitalizao do documento por meio de um scanner, seu armazenamento
(gravao em CD-ROM, DVD, Disco ptico ou Disk Array) e o gerenciamento (consultas, pesquisas etc.)
das informaes em meio digital.
COLD/Enterprise Report Management - Gerenciamento de Relatrios Corporativos: COLD (Computer
Output to Laser Disk) substitui a tecnologia COM (Computer Output to Microfilm) como forma de
armazenar grandes volumes de dados provenientes de sistemas computadorizados (arquivos spool). Em
vez de serem impressos, os relatrios so gravados em mdia magntica/ptica e disponibilizados aos
usurios, para consulta, no vdeo, por meio de um visualizador prprio.
Document Management (DM) Gerenciamento de Documentos: tem por objetivo o controle e
armazenamento de documentos produzidos por programas de computador, tais como: Word, Excel,
PowerPoint etc. Uma funcionalidade interessante de mdulos desse tipo a utilizao de servios de
biblioteca que possibilitam o controle das diversas verses de um documento.
Com o crescimento da Internet, surgiu o termo Web Content Management (WCM), que trata do
gerenciamento do contedo de informaes e o que o diferencia do DM, da publicao desse contedo
na Web.

http://www.contabeis.ufba.br/materialprofessores/sonia/Artigo%20CONVIBRA.pdf
http://www.serpro.gov.br/imprensa/publicacoes/tematec/2001/ttec57
22
11
12

TI para concursos

2.4

Workflow
Uma vez organizada a informao na empresa, precisamos conhecer o fluxo do processo do negcio,
em outras palavras, o seu Workflow. Este um conceito antigo que sempre existiu nas organizaes. A
novidade est na automao do controle do fluxo dos processos e o Workflow funciona como elemento
aglutinador das aes pontuais de cada uma das etapas dos processos.
O foco principal reside em saber quem fez que parte do trabalho, em que ordem e sob quais condies
(os 3Rs do Workflow Routes /Rotas, Roles/Papis e Rules/ Regras). Para sua utilizao primordial
que o trmite de documentos, com as etapas e atividades envolvidas, esteja completamente
sistematizado.
Podemos conceituar Workflow como o elemento responsvel por gerenciar o fluxo dos processos da
empresa permitindo um controle automtico de tarefas, eventos e prazos, com o intuito de atingir os
objetivos do negcio. As diversas solues de Workflow podem ser grupadas nas seguintes classes:
Produo: processos de misso crtica de relevante valor agregado, com alto grau de estruturao
nas regras de roteamento, controle e acompanhamento e com volume significativo de ocorrncias
repetitivas.
Colaborativo: coordenao das atividades de um grupo de pessoas, trabalhando juntas para a
execuo de um projeto, porm com regras e fluxos de baixo grau de estruturao.
Administrativo: processos administrativos com baixo valor agregado ao negcio e orientados para o
roteamento de formulrios e de documentos com baixo grau de estruturao.
Ad-hoc: processos eventuais com regras e fluxos com baixo grau de estruturao.
Enquanto em um sistema tradicional o trmite do processo necessita de interveno humana, ou seja,
passivo, em um sistema de Workflow isso realizado de forma automtica. Para tal, os sistemas de
Workflow, independente de sua classe, abrangem diversas funes, dentre as quais podemos destacar:
Seqenciamento: controle da seqncia de execuo das diversas atividades do processo;
Controle de Tempo: estabelecimento de limites de tempo para a realizao das tarefas;
Roteamento: caminhos alternativos de execuo das tarefas (seqencial, paralelo e condicional);
Atribuio de Papis: capacidade de rotear uma ao para um papel/perfil de usurio quando uma
condio for satisfeita ou um prazo se esgotar;
Monitoramento: facilidade de acompanhar a situao das tarefas e o trmite das aes tomadas no
processo.
Os principais pontos positivos do uso dessas solues so: o aumento de produtividade, a reduo de
custo com papel, o aumento da segurana devido eliminao do trmite de documentos originais, a
reduo do espao de armazenamento, a mobilidade dos arquivos (contingncia), a reduo do tempo
de respostas para acesso s informaes e a agilidade no tratamento de excees (Workflow).
No que diz respeito s dificuldades encontradas, elas so referentes a barreiras culturais, exigncia de
mudana comportamental dos usurios que no dispem mais do papel, falta de sistematizao e
padronizao dos procedimentos da corporao e ao receio do desemprego, principalmente com a
implantao de aplicaes de Workflow.
A utilizao da tecnologia de Workflow deve ser considerada na implantao de sistemas tipicamente
processuais, cujo trmite do processo possa ser automatizado, onde haja necessidade de controle do
tempo de execuo das tarefas e com diversas pessoas participando do processo.
O Workflow evoluiu de sistemas que implementavam fluxos de documentos, para funcionar tambm
como integrador. Alm disso, existe uma tendncia crescente em se utilizar a Web para a entrada de
formulrios, a distribuio de documentos e o envio de mensagens de alerta por e-mails. Na Internet,
onde mecanismos adicionais de segurana so preponderantes, surge a necessidade do uso de
criptografia e certificao digital para a execuo de determinadas funes do fluxo do processo.
O Gerenciamento Eletrnico de Documentos est convergindo para Gerenciamento de Contedo
Corporativo (Enterprise Content Management), devendo gerir no apenas os documentos da empresa
como tambm os contedos provenientes de sistemas legados, bancos de dados, sistemas de imagem,
COLD, DM e qualquer outro arquivo digital, atravs de uma interface nica baseada em browser.

2.5

Exerccios
30.

23

(ICMS-SP 2009) No diagrama de fluxos de negcio (BPMN), para estabelecer "quem faz o que" devem ser
representados os fluxos de negcio agrupados em 30
(a) processes e tasks.
(b) events e gateways.
(c) pools e lanes.xx
(d) pools e processes.
(e) lanes e tasks.

TI para concursos

24

31.

(ICMS-SP 2009) Na modelagem de processos de negcio (BPMN), NO se aplica um End Event no tipo de
31
trigger
(a) Exception.
(b) Link.
(c) Message.
(d) Multiple.
(e) Timer.xx

32.

(ICMS-SP 2009) Na modelagem de processos de negcio (BPMN), os Fluxos de Mensagem devem ser
32
desenhados
(a) entre white boxes.
xx
(b) entre black boxes.
(c) entre tasks.
(d) dentro de tasks.
(e) dentro de black boxes.

33.

(ICMS-PR 2012) O BPM - Business Process Modeling evoluiu a partir de origens temporais denominadas
ondas.
33
Sobre as ondas evolutivas do BPM, assinale a alternativa correta.
(a) A primeira onda caracteriza-se pelo gerenciamento cientfico, na qual a diviso entre patres e
empregados era bem definida.xx
(b) A segunda onda caracteriza-se pelo estudo de Smith e Fingar, publicado em 2002.
(c) A terceira onda caracteriza-se pela reimplementao das caractersticas da primeira onda.
(d) A quarta onda caracteriza-se pela implementao do programa de melhoria contnua conhecido como 5S.
(e) A quinta onda caracteriza-se pela implementao da automao de workflows.

34.

(CVM 2010) So mtodos para modelagem de processos:


(a) Arquitetura de Sistemas de Informaes Integrados (ARIS). Business Process Execution Language
(BPEL). Mtodos Integrados de Definio (IDEF).xx
(b) Projeto de Sistemas de Informaes Integrados (PRIS). Business Process Modeling Notation (BPMN).
Mtodos Diretivos de Interface (IDM).
(c) Arquitetura de Sistemas de Comunicao Integrados (ARCS). Business Decision and Execution
Processes (BDEP). Mtodos Integrados de Definio (IDEF).
(d) Arquitetura de Sistemas de Informaes Integrados (ARIS). Power Level Enterprise Allowances (PLEA).
Mtodos Simuladores de Processos Estticos (MSPE).
(e) Automao de Processos Integrados (API). Business Decision and Execution Processes (BDEP).
Mtodos Integrados de Auditoria e Controle (MIAC).

35.

(ICMS-SP 2009) A tecnologia de armazenamento de relatrios em discos ticos (COLD) envolvida no GED
tratada como sinnimo de 35
(a) DI Document Imaging.
(b) DM Document Management.
(c) FP Forms Management.
(d) ERM Enterprise Report Management.xx
(e) RIM Records and Information Management.

36.

(ICMS-SP 2009) Workflow uma tecnologia aplicada no GED que est diretamente envolvida com 36
(a) KM.
(b) BPM.xx
(c) ERP.
(d) CRM.
(e) SCM.

37.

(ICMS-SP 2009) No bloco de back-office da arquitetura de sistema encontram-se os pacotes integrados de


gesto empresarial, cujos dados so armazenados nas formas transacionais, com nfase na integrao de
37
processos, identificados pela sigla
(a) CRM.
(b) SAF.
(c) PRM.
(d) SCM.
(e) ERP.xx

38.

(ICMS-SP 2009) A rea de BI Business Intelligence est diretamente envolvida com os projetos de
38
implementao das aplicaes de
(a) B2B, B2C e BSC.
(b) EAI, B2B e B2C.
(c) EAI, CRM e ERP.
(d) CI, KMS e BSC.xx
(e) CRM, PRM e ERP.

34

TI para concursos

25

39.

(ICMS-SP 2009) A utilizao de ferramentas de groupware e de workflow, cujas informaes gerais so


apresentadas sob a forma de textos, memorandos, grficos, e-mails, boletins informativos, pginas Web e
arquivos multimdia, caracterizam o tipo de portal de 39
(a) informaes empresariais.
(b) suporte deciso.
(c) especialista.
(d) conhecimento.
(e) cooperao.xx

40.

(ICMS-SP 2009) As empresas que implementam portais corporativos por meio dos quais estabelecem
relacionamentos de negcios, com um certo nvel de acoplamento eletrnico entre os seus sistemas de
40
compras, vendas, logstica, distribuio e outros, adotam uma forma de e-Business conhecida por
(a) B2C.
(b) B2G.
(c) B2B.xx
(d) C2B.
(e) C2C.

TI para concursos

Governana de TI

Governana deriva do termo governo. Segundo o Banco Mundial, a maneira pela qual o poder exercido, a
administrao dos recursos sociais e econmicos de um pas visando o desenvolvimento. Representa a
capacidade dos governo de planejar, formular e programar polticas e cumprir funes. Governana o jeito de
governar ou uma medida de governabilidade.
A administrao moderna de tecnologia de informao busca fundamentos em boas prticas de gerenciamento
alinhadas com objetivos do negcio.
Prtica uma maneira de trabalhar. Melhores prticas so atividades ou processos que tenham sido utilizados
com sucesso.
O conceito de Governana Tecnolgica, do termo em ingls IT Governance, define que a TI um fator essencial
para a gesto financeira e estratgica de uma organizao. Governana Tecnolgica a metodologia (e seus
13
processos integrados) de gesto corporativa dos recursos de TI.

Ilustrao 5 Governana de TI

A governana de TI trata da integrao e uso de processos corporativos suportados pelos pacotes de gesto, por
exemplo: BI (Business Intelligence), CRM (Customer Relationship Management), ERP (Enterprise Resource
Planning) e SCM (Supply Chain Management).
Neste texto, vamos estudar uma metodoloia de qualidade e avaliao de maturidade de desenvolvimento de
software e duas metodologias de governana de TI.
CMMI um modelo de referncia que contm prticas (Genricas ou Especficas) necessrias maturidade em
disciplinas especficas (Systems Engineering (SE), Software Engineering (SW), Integrated Product and Process
Development (IPPD), Supplier Sourcing (SS)).
ITIL um framework, ou uma estrutura de gerncia de servios de TI. Em sua verso 2, o foco era a prpria
prestao de servios. Na verso 3, o ITIL mudou seu foco para a o alinhamento dos objetivos de servios de TI
com os do negcio, mudando da abordagem operacional para uma viso mais estratgica do uso da tecnologia.
O COBIT um guia de boas prticas para a gesto de tecnologia, no apenas servios.

3.1

Princpios de governana de TI
14

De acordo com a ISO/IEC 38500, so seis princpios para governana de TI:


Responsabilidade papis e responsabilidades bem definidos na entrega de TI aos clientes e na
sua aquisio, e garantia de autoridade compatvel para o exerccio desses papis.
Estratgia O desenvolvimento da estratgia de negcio considera a as capacidades atuais e
futuras de TI e o planejamento de TI busca atender s necessidades atuais e continuadas do
negcio da organizao (alinhamento).

http://www.trainning.com.br/download/Apostila_ITIL_Cobit.pdf
http://www.geraldoloureiro.com/wiki/images/9/98/WGov_Palestra_ClaudioCruz.pdf
26
13
14

TI para concursos

Aquisies As aquisies de TI so adequadamente motivadas por meio de anlises


apropriadas e continuadas e de decises claras e transparentes, de modo a garantir o alcance de
equilbrio adequado entre benefcios, oportunidades, custos e riscos, tanto no curto como no longo
prazo.
Desempenho A TI estruturada para suportar adequadamente a organizao e dispor servios
com os nveis e com a qualidade necessrios para responder aos requisitos atuais e futuros do
negcio.
Conformidade A TI est em conformidade com a legislao e regulamentos aplicveis. As
polticas e as prticas esto claramente definidas, encontram-se implementadas e so aplicadas.
Comportamento Humano As polticas, prticas e decises relativas ao uso e gesto da TI
consideram e respeitam o comportamento humano e incluem as necessidades atuais e a evoluo
das necessidades de todas as pessoas envolvidas no processo.

3.2

Alinhamento estratgico
O alinhamento estratgico entre o negcio e a TI definido por Duffy (2002) como o processo e o
objetivo de conseguir vantagem competitiva desenvolvendo e sustentando um relacionamento simbitico
entre o negcio e a TI.15
Uma governana deve proporcionar manuteno de um alinhamento estratgico e eficaz, sob a
definio de trs modalidades preliminares de governana de TI:
Centralizada: deciso delimitada a pequena quantidade de funes com capacidade para tal.
Descentralizada: nmero maior de configuraes, mas descentraliza o poder e dificulta o
alinhamento; tpica da organizao divisional e/ou de gerentes de linha.
Federativa: suas vrias configuraes se relacionam com os aspectos da deciso, balanceado
entre a alta gerncia e a estrutura divisional e/ou de gerncia de linha.
WEILL e ROSS (2006) expandiram estes conceitos e estabeleceram uma combinao de cinco decises
necessrias, que inter-relacionadas com seis possibilidades de quem deve ter a atribuio de decidir,
constituem uma matriz de arranjos ajustada atividade de cada empresa.
So cinco as decises-chave:
Princpios de TI, que esclarecem o papel de negcio de TI;
Arquitetura de TI, que define os requisitos de integrao e padronizao;
Infra-estrutura de TI, que determina os servios compartilhados e de suporte;
Necessidade de aplicaes de negcio, que especifica a necessidade comercial de aplicaes de
TI, comprada ou desenvolvida internamente;
Investimentos e priorizao de TI, que priorizam quais iniciativas financiar e quanto gastar.
Os direitos decisrios so listados em seis arqutipos, ou tipo de pessoa envolvida em tomar uma
deciso de TI:
Monarquia de negcio, representada pelos altos gerentes;
Monarquia de TI, representada pelos especialistas em TI;
Feudalismo, onde cada unidade de negcio toma decises independentes;
Federalismo, caracterizando uma combinao entre o centro corporativo e as unidades de
negcio, com ou sem o envolvimento do pessoal de TI;
Duoplio de TI, com o envolvimento do grupo de TI e de algum outro grupo Tal como a alta
gerncia ou os lderes das unidades de negcio;
Anarquia, onde as tomadas de deciso so individuais ou por pequenos grupos de modo isolado.

3.3

Qualidade de software
rea de conhecimento da engenharia de software que objetiva garantir a qualidade do software atravs
da definio e normatizao de processos de desenvolvimento. Apesar dos modelos aplicados na
garantia da qualidade de software atuarem principalmente no processo, o principal objetivo garantir um
produto final que satisfaa s expectativas do cliente, dentro daquilo que foi acordado inicialmente.
A qualidade o grau em que um conjunto de caractersticas inerentes a um produto, processo ou
sistema cumpre os requisitos inicialmente estipulados.16
A engenharia de software objetiva garantir a qualidade atravs da definio e normatizao de
processos de desenvolvimento, com um produto final que satisfaa s expectativas do cliente.
Os atributos qualitativos previstos na norma ISO 9126 so:
funcionalidade
confiabilidade
usabilidade

http://www.aedb.br/seget/artigos06/747_ARTIGO%20SEGET.pdf
http://pt.wikipedia.org/wiki/Qualidade_de_software
27
15
16

TI para concursos

eficincia
manutenibilidade
portabilidade.

Mensurar o bom funcionamento de um software envolve compar-lo com elementos como


especificaes, outros softwares da mesma linha, verses anteriores do mesmo produto, inferncias
pessoais, expectativas do cliente, normas relevantes, leis aplicveis, entre outros.
A verificao compara o software com a especificao, enquanto que a validao compara com a
expectativa do cliente.
A melhoria de processos tem base em modelos tidos como eficientes, como por exemplo os SW -CMM,
SE-CMM, ISO 15504 e o mais conhecido CMMI.

3.3.1

CMMI
O "CMMI - Capability Maturity Model Integration/SEI" uma
estrutura (framework), que descreve os principais elementos
de um processo de desenvolvimento de software.
Organizaes de software evoluem o seu ciclo de
desenvolvimento de software atravs de sua avaliao
contnua, identificao e aes corretivas dentro de uma
estratgia de melhoria dos processos. Este caminho de
melhoria definido por cinco nveis de maturidade:
inicial, ad hoc, sem ambiente estvel de desenvolvimento
ou processos estruturados, que excedem prazos e
oramentos.
repetitivo, um minimo de disciplina nos processos para repetir sucessos anteriores, podendo utilizar
ferramentas de gerncia de projetos para administrar custos e prazos, e status do projeto visveis
(marcos e trmino).
definido, um conjunto de processos padro estabelecidos e melhorados periodicamente
gerenciado, com utilizao de indicadores de qualidade
otimizado, com a procura constante de inovao e a realizao de um processo controlado e
mensurado para melhoria contnua
O CMMI possui duas representaes: "contnua" ou "por estgios". Estas representaes permitem a
organizao utilizar diferentes caminhos para a melhoria de acordo com seu interesse.
Representao Continua, que possibilita organizao utilizar a ordem de melhoria que melhor atende
os objetivos de negcio da empresa. caracterizado por Nveis de Capacidade (Capability Levels) das
reas de processo:

Nvel
Nvel
Nvel
Nvel
Nvel
Nvel

0: Incompleto (Ad-hoc)
1: Executado (Definido)
2: Gerenciado
3: Definido
4: Quantitativamente gerenciado
5: Em otimizao

Representao Por Estgios, que oferece uma seqncia pr-determinada para melhoria baseada em
estgios que no deve ser desconsiderada, pois cada estgio serve de base para o prximo.
caracterizado por Nveis de Maturidade (Maturity Levels) da organizao:

3.3.1.1

28

Nvel
Nvel
Nvel
Nvel
Nvel

1: Inicial (Ad-hoc)
2: Gerenciado
3: Definido
4: Quantitativamente gerenciado
5: Em otimizao

reas de Processo
O modelo CMMI v1.2 (CMMI-DEV) contm 22 reas de processo. Em sua representao por estgios,
as reas so divididas da seguinte forma:
Nvel 1: Inicial (Ad-hoc)
No possui reas de processo.
Nvel 2: Gerenciado / Gerido
Gerenciamento de Requisitos - REQM (Requirements Management)
Planejamento de Projeto - PP (Project Planning)
Acompanhamento e Controle de Projeto - PMC (Project Monitoring and Control)
Gerenciamento de Acordo com Fornecedor - SAM (Supplier Agreement Management)
Medio e Anlise - MA (Measurement and Analysis)

TI para concursos

Garantia da Qualidade de Processo e Produto - PPQA (Process and Product Quality Assurance)
Gerncia de Configurao - CM (Configuration Management)
Nvel 3: Definido
Desenvolvimento de Requisitos - RD (Requirements Development)
Soluo Tcnica - TS (Technical Solution)
Integrao de Produto - PI (Product Integration)
Verificao - VER (Verification)
Validao - VAL (Validation)
Foco de Processo Organizacional - OPF (Organizational Process Focus)
Definio de Processo Organizacional - OPD (Organizational Process Definition)
Treinamento Organizacional - OT (Organizational Training)
Gerenciamento Integrado de Projeto - IPM (Integrated Project Management)
Gerenciamento de Riscos - RSKM (Risk Management)
Anlise de Deciso e Resoluo - DAR (Decision Analysis and Resolution
Nvel 4: Quantitativamente gerenciado / Gerido quantitativamente
Desempenho de Processo Organizacional - OPP (Organizational Process Performance)
Gerenciamento Quantitativo de Projeto - QPM (Quantitative Project Management)
Nvel 5: Em otimizao
Gesto de Processo Organizacional - OPM (Organizational Process Management)
Anlise Causal e Resoluo - CAR (Causal Analysis and Resolution)
3.3.1.2

CMMI para o COBIT


Para o CobIT, estudado mais frente, a escala de maturidade recebe um nvel a mais, em relao ao
CMMI.
0 - Inexistente
Completa falta de um processo reconhecido. A empresa nem mesmo reconheceu que existe uma
questo a ser trabalhada.
1 - Inicial / Ad hoc
Existem evidncias que a empresa reconheceu que existem questes e que precisam ser
trabalhadas. No entanto, no existe processo padronizado; ao contrrio, existem enfoques Ad Hoc
que tendem a ser aplicados individualmente ou caso-a-caso. O enfoque geral de gerenciamento
desorganizado.
2 - Repetvel, porm Intuitivo
Os processos evoluram para um estgio onde procedimentos similares so seguidos por diferentes
pessoas fazendo a mesma tarefa. No existe um treinamento formal ou uma comunicao dos
procedimentos padronizados e a responsabilidade deixado com o indivduo. H um alto grau de
confiana no conhecimento dos indivduos e conseqentemente erros podem ocorrer.
3 - Processo Definido
Procedimentos foram padronizados, documentados e comunicados atravs de treinamento.
mandatrio que esses processos sejam seguidos; no entanto, possivelmente desvios no sero
detectados. Os procedimentos no so sofisticados mas existe a formalizao das prticas
existentes.
4 - Gerenciado e Mensurvel
A gerencia monitora e mede a aderncia aos procedimentos e adota aes onde os processos
parecem no estar funcionando muito bem. Os processos esto debaixo de um constante
aprimoramento e fornecem boas prticas. Automao e ferramentas so utilizadas de uma maneira
limitada ou fragmentada.
5 - Otimizado
Os processos foram refinados a um nvel de boas prticas, baseado no resultado de um contnuo
aprimoramento e modelagem da maturidade como outras organizaes. TI utilizada como um
caminho integrado para automatizar o fluxo de trabalho, provendo ferramentas para aprimorar a
qualidade e efetividade, tornando a organizao rpida em adaptar-se.

3.3.1.3

Garantia de qualidade de software


A Garantia da Qualidade de Software (GQS) a rea-chave de processo do CMM cujo objetivo
fornecer aos vrios nveis de gerncia a adequada visibilidade dos projetos, dos processos de
desenvolvimento e dos produtos gerados. A GQS atua como guardi, fornecendo um retrato do uso do
17
Processo e no responsvel por executar testes de software ou inspeo em artefatos.
Obtendo a visibilidade desejada, a gerncia pode atuar de forma pontual no sentido de atingir os quatro
grandes objetivos de um projeto de desenvolvimento de software, quais sejam, desenvolver software de

http://pt.wikipedia.org/wiki/Qualidade_de_software
29
17

TI para concursos

alta qualidade, ter alta produtividade da equipe de desenvolvimento, cumprir o cronograma estabelecido
junto ao cliente e no necessitar de recursos adicionais no previstos.
Para conseguir esses objetivos a rea-chave de processo GQS estimula a atuao das equipes
responsveis pelo desenvolvimento de software em diversas frentes objetivando internalizar
comportamentos e aes, podendo-se destacar:
o planejamento do projeto e o acompanhamento de resultados;
o uso dos mtodos e ferramentas padronizadas na organizao;
a adoo de Revises Tcnicas Formais;
o estabelecimento e a monitorao de estratgias de testes;
a reviso dos artefatos produzidos pelo processo de desenvolvimento;
a busca de conformidade com os padres de desenvolvimento de software;
a implantao de medies associadas a projeto, processo e produto;
a utilizao de mecanismos adequados de armazenamento e recuperao de dados relativos a
projetos, processos e produtos;
a busca de uma melhoria contnua no processo de desenvolvimento de software.

3.3.2

MPS-BR - Melhoria de Processos do Software Brasileiro


O MPS.BR ou Melhoria de Processos do Software Brasileiro simultaneamente um movimento para a
melhoria da qualidade (Programa MPS.BR) e um modelo de qualidade de processo (Modelo MPS).
Voltado para a realidade do mercado de pequenas e mdias empresas de desenvolvimento de software
no Brasil, ele baseado nas normas ISO/IEC 12207 e ISO/IEC 15504 e compatvel com o CMMI.
O projeto tem apoio do Ministrio da Cincia e Tecnologia, da FINEP e do Banco Interamericano de
Desenvolvimento. No Brasil o projeto desenvolvido pela Softex, interagindo com as universidades e
com o Governo Federal. Uma das principais vantagens do modelo seu custo reduzido de certificao
em relao as normas estrangeiras, sendo ideal para micro, pequenas e mdias empresas que so a
grande maioria no Brasil.
Um dos objetivos do projeto replicar o modelo na Amrica Latina, incluindo o Chile, Argentina, Costa
Rica, Peru e Uruguai.18
O MPS.Br dividido em 3 partes:
MR-MPS modelo de referncia. Apresenta 7 nveis de maturidade (o que um diferencial em
relao aos outros padres de processo) que so:

A - Em Otimizao;
B - Gerenciado quantitativamente;
C - Definido;
D - Largamente Definido;
E - Parcialmente Definido;
F - Gerenciado;
G - Parcialmente Gerenciado.

MA-MPS modelo de avaliao em conformidade com a norma ISO/IEC 15504

Planejar e preparar avaliao


Conduzir Avaliao
Relatar resultados
Registrar e publicar resultados

MN-MPS modelo de negcio

3.3.3

Exerccios
41.

Segundo o modelo CMM, migrar do nvel 3 de maturidade para o nvel 4 representa uma melhoria da
qualidade de processos 41
(a) otimizados para processos gerenciados.
(b) definidos para processos repetveis.
xx
(c) definidos para processos gerenciados.
(d) gerenciados para processos otimizados.
(e) repetveis para processos definidos.

42.

O metamodelo CMMI contnuo define que cada rea de processo avaliada formalmente, com base em metas
e prticas especficas, e classificada de acordo com seis nveis de capacitao. O nvel 3 o 42
(a) Quantitativamente gerido.
(b) Realizado.
xx
(c) Definido.
(d) Gerido.
(e) Otimizado.

http://pt.wikipedia.org/wiki/Melhoria_de_Processos_do_Software_Brasileiro
30
18

TI para concursos

31

43

43.

(SUSEP 2010) So reas de Processo da Categoria Engenharia no CMMI:


(a) Atualizao de Requisitos, Otimizao de Requisitos, Soluo Tcnica, Integrao do Produto,
Verificao e Auditoria.
(b) Desenvolvimento de Requisitos, Gesto de Requisitos, Mtodos e Tcnicas, Integrao do Produto,
Anlise de Decises e Resoluo.
(c) Atualizao de Requisitos, Gesto de Requisitos, Deciso Tcnica, Integrao do Produto, Segurana e
Auditoria.
(d) Desenvolvimento de Requisitos, Gesto de Requisitos, Soluo Tcnica, Integrao do Produto,
xx
Verificao e Validao.
(e) Desenvolvimento de Requisitos, Composio de Requisitos, Mtodos e Tcnicas, Integrao do Produto,
Verificao e Manuteno.

44.

(SUSEP 2010) As abordagens para implementao do CMMI so:


(a) Abordagem por Sistemas e Abordagem Sequencial.
(b) Abordagem por Estgios e Abordagem Contnua.xx
(c) Abordagem por Gestores e Abordagem em Degraus.
(d) Abordagem por Estrutura e Abordagem por Processos.
(e) Abordagem por Simulao e Abordagem por Pontos de Funo.

45.

(SUSEP 2010) As abordagens do CMMI envolvem a45


(a) avaliao da maturidade da informatizao da organizao ou a capacitao das suas reas de projeto, o
estabelecimento de requisitos e a aquisio de recursos computacionais.
(b) implementao da maturidade da organizao ou a capacitao das suas reas de racionalizao, o
estabelecimento de requisitos e a modificao da estrutura.
(c) avaliao da maturidade das interfaces da organizao e a vinculao das suas reas de processo ao
estabelecimento de prioridades para a capacitao de pessoal.
(d) avaliao da mentalidade estratgica da organizao para capacitao das suas reas de risco,
estabelecimento de aes emergenciais e implementao de aes de melhoria.
(e) avaliao da maturidade da organizao ou a capacitao das suas reas de processo, o
xx
estabelecimento de prioridades e a implementao de aes de melhoria.

46.

(SUSEP 2010) Assinale a opo correta.46


(a) A estratgia de outsourcing decide como gerenciar o desempenho dos equipamentos.
(b) O objetivo principal da Governana de TI gerenciar outsourcing.
(c) A estratgia de outsourcing decide como gerenciar os negcios internos dos fornecedores ou prestadores
de servios.
(d) O objetivo principal da Governana de TI escolher a melhor alternativa de programao.
(e) O objetivo principal da Governana de TI alinhar TI aos requisitos do negcio. xx

47.

(ICMS PR 2012) Sobre o modelo CMMI, atribua V (verdadeiro) ou F (falso) s afirmativas a seguir.
( ) O principal propsito do CMMI fornecer diretrizes baseadas em melhores prticas para a melhoria dos
processos e habilidades organizacionais, cobrindo o ciclo de vida de produtos e servios completos, nas fases
de concepo, desenvolvimento, aquisio, entrega e manuteno.
( ) O CMMI para Servios (CMMI-SVC) prov diretrizes para monitorar, mensurar e gerenciar processos de
desenvolvimento, podendo ser estendida atravs da adio para o Desenvolvimento Integrado de Produto e
Processo (IPPD).
( ) Uma constelao uma coleo de componentes gerada a partir do framework CMMI, que engloba um
modelo fundamental, seus materiais de treinamento e a documentao relacionada a avaliaes, abrangendo
uma rea de interesse especfica.
( ) Dentre os componentes da estrutura do CMMI, as Metas Especficas correspondem s metas relacionadas
a uma determinada rea de processo, que descrevem o que deve ser realizado para assegurar que esteja
efetivamente implementada.
( ) Dentre as constelaes desse modelo, o CMMI para Aquisies (CMMI-ACQ) prov diretrizes para entrega
de servios dentro das organizaes e para clientes externos.
Assinale a alternativa que contm, de cima para baixo, a sequncia correta.47
(a) V, V, F, F, V.
xx
(b) V, F, V, V, F.
(c) V, F, F, V, V.
(d) F, V, V, F, F.
(e) F, F, F, V, V.

48.

(ICMS PR 2012) O Modelo de Referncia MR-MPS define nveis de maturidade que so uma combinao
entre processos e sua capacidade. Sobre esses nveis, considere as afirmativas a seguir.
I. O nvel B corresponde a Gerenciado Quantitativamente.
II. O nvel A corresponde a Definido.
III. O nvel C corresponde a Em Otimizao.
IV. O nvel G corresponde a Parcialmente Gerenciado.
Assinale a alternativa correta.48
(a) Somente as afirmativas I e II so corretas.
xx
(b) Somente as afirmativas I e IV so corretas.
(c) Somente as afirmativas III e IV so corretas.
(d) Somente as afirmativas I, II e III so corretas.
(e) Somente as afirmativas II, III e IV so corretas.

44

TI para concursos

3.4

49.

(ICMS PR 2012) Sobre a Implantao da Funo de Qualidade (IFQ), atribua V (verdadeiro) ou F (falso) s
afirmativas a seguir.
( ) Concentra-se em maximizar a satisfao do cliente a partir do processo de Engenharia de Software.
( ) Os Requisitos Normais esto implcitos no produto ou sistema e podem ser to fundamentais que o cliente
no se refere a eles explicitamente.
( ) uma tcnica que traduz as necessidades do cliente para requisitos tcnicos do software.
( ) Enfatiza o entendimento do que tem valor para o cliente e depois implanta esses valores por meio do
processo de engenharia.
( ) Os Requisitos Esperados refletem caractersticas que vo alm das expectativas do cliente e mostram ser
muito satisfatrias quando presentes.
49
Assinale a alternativa que contm, de cima para baixo, a sequncia correta.
(a) V, V, F, F, V.
xx
(b) V, F, V, V, F.
(c) V, F, F, V, V.
(d) F, V, V, F, F.
(e) F, F, F, V, V.

50.

(CVM 2010) Com base no CMMI, assinale a opo correta que apresenta Categoria e algumas de suas reas
de Processo.50
(a) Suporte: Gesto de Componentes, Medio e Reviso, Anlise e Resoluo de Consequncias.
(b) Gesto de Processo: Foco no Planejamento, Definio do Processo Organizacional, Desempenho do
Processo Organizacional.
(c) Suporte: Gesto da Configurao, Garantia da Operacionalidade do Processo e do Produto, Anlise de
Planejamento e Decises.
(d) Gesto de Processo: Foco no Processo Organizacional, Definio do Processo Operacional, Inovao e
Disseminao Estrutural.
(e) Gesto de Processo: Foco no Processo Organizacional, Definio do Processo Organizacional, Inovao
xx
e Disseminao Organizacional.

Gerenciamento de servios
Gerenciamento de servios um conjunto de habilidades organizacionais especializadas para prover
valor aos clientes na forma servio.
Estas habilidades assumem a forma de funes e processos de gerenciamento dos servios ao longo de
um ciclo de vida.
Prestao de servios oferece produtos de natureza intangvel e processos, difceis de medir, controlar
ou validar.
Uma organizao, do ponto de vista de gerenciamento, pode ser vista como um conjunto de funes,
definidas, neste contexto, como unidades especializadas em executar determinados tipos de trabalho e
responsveis por resultados especficos. So auto-suficientes, com habilidades e recursos necessrios
para o seu desempenho.
A coordenao entre funes tipicamente realizada atravs de processos.
Processo um conjunto estruturado de atividades com uma finalidade, que proporciona a transformao
em direo de uma meta. Ele recebe entradas (input) definidas e as transforma em resultados (sadas)
definidos (output).
Um processo apresenta quatro caractersticas:
Mensurvel
Entrega resultados especficos, identificveis e calculveis
Entrega para um cliente ou parte interessada
Responde a eventos especficos
H diversas metodologias, tcnicas ou frameworks de gerenciamento de servios utilizadas nas
organizaes. De acordo com uma pesquisa da Dimension Data, em 2008, o ITIL era utilizado por 66%
das pesquisadas, MOF por 47%, Six Sigma 41%, TQM 34 %, Cobit e ASL por 33%, Prince 2 por 28%,
entre outras.
Neste texto, concentraremos a ateno em ITIL e COBIT, por sua incidncia em concursos pblicos.

3.5

Conceitos e definies
Funo
Unidade especializada em executar determinados tipos de trabalho e responsvel por resultados
especficos.
So auto-suficientes, com habilidades e recursos necessrios para o seu desempenho.
A coordenao entre funes tipicamente realizada atravs de processos

32

TI para concursos

Processo
Conjunto estruturado de atividades com uma finalidade
Proporciona a transformao em direo de uma meta
Recebe entradas (input) definidas e as transforma em resultados (sadas) definidos (output).
Um processo apresenta quatro caractersticas:

Mensurvel
Entrega resultados especficos, identificveis e calculveis
Entrega para um cliente ou parte interessada
Responde a eventos especficos

Evento
Qualquer fato identificvel
Tipicamente, alerta ou notificao criada por uma ferramenta de monitorao
Alerta
Aviso de que
Um limite foi atingido
Algo foi modificado
Ocorreu uma falha

Incidente
Interrupo no planejada
Reduo de qualidade
Falha de um item de configurao
Problema
Causa desconhecida de um ou mais incidentes
Soluo de contorno
Soluo temporria para superar uma dificuldade
Reduz impacto de um incidente ou problema
No fecha o registro de problema

3.6

Fundamentos da ITIL V2
Verso anterior do framework, preocupava-se especificamente com a prestao de servios.
Estrutura abstrata (framework) de servios de TI. Orienta o como fazer das funes do gerente de
tecnologia, dividindo estes servios em dois grandes grupos suporte a servios e entrega de servios
unidos por uma central de atendimento (service desk).

3.6.1

Suporte a servios
O suporte a servios tem foco nos usurios da instituio, administrando incidentes, suas origens
(problema) e definindo formas de tratamento e de alteraes necessrias para resoluo.

33

TI para concursos

3.6.1.1

Central de servios (service desk)


Suporte de primeiro nvel. Atendimento ao usurio.

3.6.1.2

Gerenciamento de incidentes (apaga incndio)


Restaurar o servio o mais rpido possvel, para minimizar o impacto nos negcios e para garantir o
melhor nvel de servio, no tocante qualidade e disponibilidade.
Um incidente um evento que no faz parte da operao padro do servio e que causa, ou poder
causar uma interrupo, ou uma reduo na qualidade do servio.

3.6.1.3

Gerenciamento de problemas (desenvolvimento de solues)


Buscar a causa raiz do incidente e sua conseqente soluo e preveno.
Um Problema um erro de causa desconhecida que pode causar um ou mais incidentes.
Um Problema poder ser um Erro Conhecido (Known Error) quando a causa raiz (root cause) tornar
conhecida e uma Soluo de Contorno (work-around) ou permanente for identificada e aplicada.
As solues so registradas na gerncia de configurao e as mudanas necessrias so requisitadas
gerncia de mudanas.

3.6.1.4

Gerenciamento de mudanas (implementao)


A partir de requisies de mudanas dos usurios ou do gerenciamento de problemas, implementa
mudanas aprovadas, de maneira eficiente, em um custo efetivo, com um mnimo risco infra-estrutura
de TI existente e nova.

3.6.1.5

Gerenciamento de liberao (implantao)


Libera e distribui a alterao autorizada. Implanta.

3.6.1.6

Gerenciamento de configurao (controle da infra-estrutura)


Gerenciar o banco de dados de todos os componentes necessrios para fornecer servios

3.6.2

Entrega de Servio
A entrega de servios volta-se para o cliente, preocupando-se em garantir uma qualidade tima em
funo da estratgia do negcio, alm da efetividade do servio prestado como resultado de uma gesto
de recursos tecnolgicos (ativos) e financeiros.

3.6.2.1

Gerenciamento de nivel de servio


A partir de um acordo do nvel de servio entre a TI e os usurios, contendo os requisitos do usurio,
gerencia a qualidade dos servios oferecidos, procurando a maior qualidade em consonncia com o
negcio da empresa.

3.6.2.2

Gerenciamento financeiro
Como justificar o oramento? Necessidades da TI para o negcio planejados a partir dos processos
(Mudana, Nvel, Capacidade e Disponibilidade) compe o oramento e acompanhamento financeiro.

3.6.2.3

Gerenciamento de disponibilidade
Anlise de riscos, oportunidades, satisfao, produtividade e tempo de manuteno e indisponibilidade.

3.6.2.4

Gerenciamento de capacidade
Confronto entre capacidade, demanda e satisfao do cliente. Taxa de utilizao de recursos humanos
e sistemas.

3.6.2.5

Gerenciamento de continuidade de servios de TI


Todo o esforo possvel para evitar interrupes. Implementao de medidas preventivas, testes para
operar em ambientes de crise, reduo do impacto dos incidentes, seguros.

34

TI para concursos

3.7

Fundamentos de ITIL V3

19

O ITIL em sua verso 3, muda a abordagem de gerenciamento de servios de TI, em busca de


alinhamento com os objetivos do negcio e reforo na capacidade de inovao, mais em concordncia
com os conceitos de governana em TI. Construir uma ponte entre os objetivos de neggio e de
tecnologia est no cerne das estruturas de melhores prticas de Gerenciamento de Servios de TI
(GSTI/ITSM).
O ITIL oferece qualificao em dois caminhos, um baseado no ciclo de vida de servios, em cinco
volumes, e outro em quatro mdulos de habilidades.
Pelo caminho de habilidades, o ITIL oferece quatro grupos:
Oferta de servios e contratos
Estratgia de servio
Processos de desenho
Portflio, nvel de servio, Catlogo de servio, Demanda, Fornecedores e Gerenciamento financeiro

Liberao, controle e validao


Transio de servios
Processos de operao
Mudana, Liberao e implantao, Teste e validao de servio, Gerenciamento da configurao e
ativos de servio, Conhecimento, Gerenciamento de requisoes e Avaliao do servio

Suporte e anlise operacional


Operao de servio
Processos de Melhoria de servio continuada
Eventos, Incidentes, Requisies, Problemas, Acesso, Central de servios, Gerenciamento Tcnico,
Operaes de TI e Gerenciamento de aplicativos

Planejamento, proteo e otimizao


Desenho de servio
Processos de Capacidade, Disponibilidade, Continuidade, Segurana, Demanda e Gerenciamento de
riscos

Pelo caminho ciclo de vida dos servios, os processos so distribudos em cinco grupos:
Estratgia do servio (Service Strategy)
Projeto de servio ou Desenho de servio (Service Design)
Transio do servio (Service Transition)
Operao do servio (Service Operation)
Melhoria contnua do servio (Continual Service Improvement)

Ilustrao 6 Ciclo de vida do servio - Ncleo do ITIL V3

http://pt.wikipedia.org/wiki/ITILv3
35
19

TI para concursos

3.7.1

Estratgia do servio (Service Strategy)


Como ponto de origem do ciclo de vida de servio ITIL, estratgia do servio orienta sobre como tornar
mais claro e priorizar investimentos sobre provimento de servios, desenhar, desenvolver e implementar
o gerenciamento de servios.
Processos:
gerao de estratgia,
gerenciamento de portflio de servios,
gerenciamento de demandas,
gerenciamento financeiro de TI.

3.7.2

Desenho de servio (Service Design)


O desenho de servio fornece orientaes para o desenvolvimento de servios e processos de
gerenciamento de servios, incluindo mudanas e melhorias para aumentar ou manter o valor, para a
continuidade dos servios, para o atingimento de nveis de servio e para a conformidade s normas.
O trabalho de projetar um servio de TI agregado em pacote de projeto de servios (Service Design
Package - SDP).
Processos de gerenciamento de:
nvel de servio (Service Level Management - SLM)
disponibilidade
capacidade
continuidade de servios
segurana da informao
fornecedores
catlogo de servios.

3.7.3

Transio do servio (Service Transition)


Este volume direcionado entrega dos servios necessrios ao negcio no uso operacional, e
geralmente englobam o "projeto".
Processos:
Planejamento de transio e suporte
Avaliao
Teste e validao
Gerenciamento de configuraes e ativos de servio
Gerenciamento de liberao e implantao (release and deployment)
Gerenciamento de mudana (Change Management)
Gerenciamento de conhecimento

3.7.4

Operao do servio (Service Operation)


Parte do ciclo de vida onde servios e valor so entregues diretamente. Assim, monitoramento de
problema e balanceamento entre disponibilidade de servio e custo so considerados.
Processos:
Cumprimento de requisio.
Gerenciamento de eventos.
Gerenciamento de incidentes.
Gerenciamento de problemas.
Gerenciamento de acesso, (service desk).
Funes:
Central de servios
Gerenciamento tcnico
Gerenciamento de aplicativos
Gerenciamento de operaes de TI

3.7.5

Melhoria de servio continuada (Continual Service Improvement)


A meta do CSI ajustar e reajustar servios de TI s mudanas contnuas do negcio atravs da
identificao e implementao de melhorias aos servios de TI que apoiam processos negociais.
Utiliza um sistema cclico de reviso baseado no modelo PDCA (Plan Do, Check and Act).
Processos:
Medio de servio
Relato de servio

36

TI para concursos

Sete passos de melhoria

3.8

ITIL V2 x V3
O ITIL apresenta os mesmo processos da verso 2 e acrescenta 16 novos.
ITIL V3

ITIL V3

Estratgia do servio

Desenho de servio

Transio do
servio

Operao do
servio

Melhoria contnua
do servio

Gerenciamento de
portflio

Segurana da
informao

Planejamento de
transio e suporte

Cumprimento de
requisio

Medio de servio

Gerao de
estratgia

Fornecedores

Avaliao

Gerenciamento de
eventos

Relato de servio

Gerenciamento de
demandas

Catlogo de
servios.

Teste e validao

Gerenciamento de
acesso

Sete passos de
melhoria

Gerenciamento de
conhecimento

Entrega

Gerenciamento
financeiro

Disponibilidade
Capacidade
Continuidade de
servios

Suporte

ITIL V2
37

Nvel de servio
(SLM)

Gerenciamento de
liberao e
implantao

Gerenciamento de
incidentes

Gerenciamento de
configuraes e
ativos de servio

Gerenciamento de
problemas

Gerenciamento de
mudana

Service desk

TI para concursos

3.9

Fundamentos de COBIT
O COBIT Control Objectives for Information and Related Technology, tem por misso explcita
pesquisar, desenvolver, publicar e promover um conjunto atualizado de padres internacionais de boas
prticas referentes ao uso corporativo da TI para os gerentes e auditores de tecnologia.
A metodologia COBIT foi criada pelo ISACA Information Systems Audit and Control Association atravs
do IT Governance Institute, organizao independente que desenvolveu a metodologia considerada a
base da governana tecnolgica. O COBIT funciona como uma entidade de padronizao e estabelece
mtodos documentados para nortear a rea de tecnologia das empresas, incluindo qualidade de
software, nveis de maturidade e segurana da informao.
Os documentos do COBIT definem Governana Tecnolgica como sendo uma estrutura de
relacionamentos entre processos para direcionar e controlar uma empresa de modo a atingir objetivos
corporativos, atravs da agregao de valor e risco controlado pelo uso da tecnologia da informao e
de seus processos.

Ilustrao 7 Cobit

38

TI para concursos

COBIT um guia de boas prticas, que podem servir como um modelo de referncia para gesto da TI.
Inclui um sumrio executivo, um "framework", controle de objetivos, mapas de auditoria, ferramentas
para a sua implementao e um guia com tcnicas de gerenciamento.
Para definio e monitoramento dos controles e nvel de performance de TI, o CobiT define:
Benchmarking da performance e capacidade dos processos de TI, expressos em modelos de
maturidade, derivados do Capability Maturity Model (CMM) do Software Engineering Institute.
Objetivos e mtricas dos processos de TI para definir e avaliar os seus resultados e performance
baseados nos princpios do balanced business scorecard publicado por Robert Kaplan e David
Norton.
Objetivos das atividades para controlar esses processos com base nos objetivos de controle do
CobiT.
O CobIT define cinco reas de foco em governana de TI como tpicos que os executivos precisam
atentar para direcionar a rea de TI:
Alinhamento estratgico: foca em garantir a ligao entre os planos de negcios e de TI, definindo,
mantendo e validando a proposta de valor de TI, alinhando as operaes de TI com as operaes
da organizao.
Entrega de valor: a execuo da proposta de valor de IT atravs do ciclo de entrega, garantindo
que TI entrega os prometidos benefcios previstos na estratgia da organizao, concentrado-se
em otimizar custos e provendo o valor intrnseco de TI.
Gesto de recursos: refere-se melhor utilizao possvel dos investimentos e o apropriado
gerenciamento dos recursos crticos de TI: aplicativos, informaes, infraestrutura e pessoas.
Questes relevantes referem-se otimizao do conhecimento e infraestrutura.
Gesto de risco: requer a preocupao com riscos pelos funcionrios mais experientes da
corporao, um entendimento claro do apetite de risco da empresa e dos requerimentos de
conformidade, transparncia sobre os riscos significantes para a organizao e insero do
gerenciamento de riscos nas atividades da companhia.
Mensurao de desempenho: acompanha e monitora a implementao da estratgia, trmino do
projeto, uso dos recursos, processo de performance e entrega dos servios, usando, por exemplo,
balanced scorecards que traduzem as estratgia em aes para atingir os objetivos, medidos
atravs de processos contbeis convencionais.
Os domnios do COBIT so integrados da seguinte forma:
A informao de uma empresa gerada/modificada pelas atividades de TI.
Esta informao requisito para o domnio de Planejamento e Organizao (PO).
Os requisitos de sada do PO so requisitos de entrada de informao para o domnio de
Aquisio e Implementao (AI),
As sadas de AI definem os requisitos de entrada para o domnio de Entrega e Suporte (DS).
O domnio de Monitorao (M) utiliza as informaes do DS nos seus processos e atividades
relacionadas.
Os requisitos da informao so dados por: efetividade, eficincia, confidencialidade, integridade,
disponibilidade, conformidade e confiabilidade.
Os recursos de TI so classificados como: pessoas, sistemas aplicativos, tecnologia, infraestrutura e
dados.
COBIT cobre os quatro domnios, os quais possuem 34 processos (dois objetivos de controle para cada
processo).

3.9.1

Planejar e Organizar
Uso de informao e tecnologia e como isso pode ser usado para que a empresa atinja seus objetivos e
metas. A forma organizacional e a infra-estrutura da TI deve ser considerada.
PO1
Definir um Plano Estratgico de TI e Orientaes
PO2
Definir a Arquitetura de Informao
PO3
Determinar as Diretrizes de Tecnologia
PO4
Definir os Processos de TI, Organizao e Relacionamentos
PO5
Gerenciar o Investimento em TI
PO6
Comunicar os Objetivos de Gerenciamento e Orientar
PO7
Gerenciar os Recusos Humanos de TI
PO8
Gerenciar a Qualidade
PO9
Estimar e Gerenciar os Riscos de TI
PO10
Gerenciar Projetos

39

TI para concursos

3.9.2

Adquirir e Implementar
Requisitos de TI, aquisio de tecnologia e implementao dentro dos processos de negcios da
companhia.
Desenvolvimento do plano de manuteno que a companhia adota para prolongar a vida do sistema de
TI e seus componentes.
AI1
Identificar Solues Automatizadas
AI2
Adquirir e Manter Software de Aplicao
AI3
Adquirir e Manter Infraestrutura de Tecnologia
AI4
Habilitar Operao e Uso
AI5
Obter Recursos de TI
AI6
Gerenciar Mudanas
AI7
Instalar e Homologar Solues e Mudanas

3.9.3

Entregar e Dar Suporte


Entrega de tecnologia da informao. Cobre a execuo de aplicaes dentro do sistema de TI e seus
resultados, assim como o suporte dos processos, que incluem questes de segurana e treinamento e
habilitam a execuo.
DS1
Definir e Gerenciar Nveis de Servio
DS2
Gerenciar Servios de Terceiros
DS3
Gerenciar o Desempenhoe Capacidade
DS4
Assegurar Servio Contnuo
DS5
Assegurar Segurana de Sistema
DS6
Identificar e Alocar Recursos
DS7
Treinar Usurios
DS8
Gerenciar a Central de Servio e os Incidentes
DS9
Gerenciar a Configurao
DS10
Gerenciar Problemas
DS11
Gerenciar Dados
DS12
Gerenciar o Ambiente Fsico
DS13
Gerenciar Operaes

3.9.4

Monitorar e Avaliar
Estimativa estratgica das necessidades da companhia. Avalia se o atual sistema de TI atinge os
objetivos para o qual ele foi especificado e controla os requisitos para atender objetivos regulatrios.
Estimativa e capacidade de atingir os objetivos de negcio, controlando os processos internos da
companhia atravs de auditores internos e externos.
M1 Monitorar os processos
M2 Assegurar avaliao dos controles internos
M3 Obter avaliao independente
M4 Prover auditoria independente

40

TI para concursos

3.10

Comparao ITIL V3 x COBIT

Ilustrao 8 Comparao COBIT x ITIL V3

3.11

Exerccios
51.

41

(ICMS-SP 2009) NO se trata de elemento que deve ser considerado como parte do controle de mudanas no
51
gerenciamento de configurao:
(a) revises e auditoria das mudanas.xx
(b) confiabilidade das instalaes das modificaes.
(c) anlise de impacto de mudanas.
(d) conjunto de modificaes.
(e) pedido de modificaes.

TI para concursos

42

52.

(ICMS-SP 2009) A rastreabilidade ou a histria das mudanas de cada software, incluindo quem fez o que, por
que e quando, pode ser realizada no gerenciamento de configurao de software por meio do seu
componente:52
(a) Acordo de nvel de servio.
(b) Configurao da construo.
(c) Identificao do item de software.
(d) Controle de verso.xx
(e) Controle de mudanas.

53.

(ICMS-SP 2009) Os objetivos de controle detalhados do COBIT esto diretamente associados


(a) aos domnios de governana.
(b) aos processos de TI.
xx
(c) s atividades de TI.
(d) aos recursos de TI.
(e) aos critrios de informao.

54.

(ICMS-SP 2009) O processo Gerenciamento de Configuraes est definido no COBIT dentro do domnio
(a) Monitorao & Avaliao.
(b) Verificao & Controle.
(c) Aquisio & Implementao.
(d) Planejamento & Organizao.
xx
(e) Entrega & Suporte.

55.

(ICMS-SP 2009) NO se trata de um princpio de governana de TI:


(a) Responsabilidade corporativa.
xx
(b) Objetivos do negcio.
(c) Prestao de contas.
(d) Transparncia.
(e) Equidade.

56.

Gerenciar Projetos, segundo o COBIT, um processo de TI pertencente ao domnio de 56


xx
(a) Planejamento e Organizao.
(b) Planejamento e Controle.
(c) Aquisio e Implementao.
(d) Entrega e Suporte.
(e) Monitorao e Controle.

57.

(ICMS-SP 2009) No gerenciamento de servios de TI, segundo o ITIL v.2, tem foco operacional o processo: 57
(a) configuration management.xx
(b) capacity management.
(c) availability management.
(d) service level management.
(e) customer relationship management.

58.

(ICMS-SP 2009) No gerenciamento de servios de TI, segundo o ITIL v.2, tem foco ttico ou estratgico o
58
processo:
(a) problem management.
(b) incident management.
(c) release management.
(d) continuity management.xx
(e) change management.

59.

(ICMS-SP 2009) O processo de gerenciamento de servios Service Desk, segundo o ITIL v.2, NO gerencia
(a) os contatos entre o provedor de servios e os usurios.
(b) a comunicao com os usurios.
(c) os incidentes nos servios.
xx
(d) os acordos de servios.
(e) as requisies de servios.

60.

O processo de Gerenciamento de Problemas, segundo o ITIL, deve ser executado no estgio do ciclo de vida
60
de servios denominado
(a) estratgia de servios.
(b) projeto de servios.
(c) transio de servios.
xx
(d) operao de servios.
(e) melhoria contnua de servios.

53

54

55

59

TI para concursos

43

61

61.

(SUSEP 2010) So publicaes do ncleo do ITIL:


(a) Estratgia de Servio, Ttica de Servio, Plano de Servio, Operao de Servio e Aplicao de Servio.
(b) Proposta de Servio, Aceitao de Servio, Transio de Servio, Aplicao de Servio e Melhoria de
Servio Continuada.
(c) Domnio de Servio, Desenho de Servio, Transio de Servio, Abordagem de Servio e Melhoria de
Servio Continuada.
(d) Estratgia de Servio, Desenho de Servio, Transio de Servio, Operao de Servio e Melhoria de
Servio Continuada.xx
(e) Estratgia de Servio, Desenho de Servio, Transposio de Servio, Operao de Servio e Melhoria de
Servio Externo.

62.

(CVM 2010) Assinale a opo correta mostrando publicao e processos da ITIL.


(a) Estratgia de servio: gerenciamento temporal de TI, gerenciamento de portflio de fornecedores e
gerenciamento de demanda de servios.
(b) Mudana de servio continuada: relatrio de produtos e medio de desempenho.
(c) Melhoria de servio aprovada: relatrio de aes e mediao de servio.
xx
(d) Melhoria de servio continuada: relatrio de servio e medio de servio.
(e) Ttica de servio: gerenciamento ttico de TI, ampliao de portflio de servios e gerenciamento de
demanda reprimida.

63.

(ICMS-PR 2012) A Governana de TI pode ser considerada como uma ramificao da Governana
Corporativa.
Sobre a Gesto e a Governana de TI, assinale a alternativa correta.63
(a) papel da Administrao determinar quem tem o direito de decidir sobre quanto uma empresa investir
em TI, enquanto a Governana determina a quantia a ser efetivamente investida num dado ano e as
reas que recebero investimento.
(b) O lado comportamental define mecanismos, formalizando os relacionamentos e estabelecendo regras e
procedimentos operacionais para assegurar que os objetivos sejam atingidos.
(c) O lado normativo define os relacionamentos formais e informais e confere direitos decisrios a indivduos
ou grupos de indivduos especficos.
(d) Segundo o Center for Information Systems Research (CISR) do MIT, Ativos Humanos so representados
por relacionamentos dentro da empresa, bem como relacionamentos, marca e reputao junto a clientes
e fornecedores.
(e) Uma Matriz de Arranjos lista cinco decises de TI inter-relacionadas: Princpios de TI, Arquitetura de TI,
Infraestrutura de TI, Necessidade de aplicaes de negcio, Investimentos e Priorizao de TI. xx

64.

(ICMS-PR 2012) A Governana de TI , em geral, motivada por vrios fatores, sendo um dos mais importantes
o Ambiente de Negcios, que, no Brasil, vem sendo caracterizado por64
(a) barganha decrescente entre fornecedores e clientes.
(b) ciclo de vida cada vez mais longo para os produtos e servios.
(c) menor dinamismo dos requerimentos dos negcios para TI.
(d) novas ameaas devidas maior internacionalizao da economia.xx
(e) uniformidade dos acionistas envolvidos no processo.

65.

(ICMS-PR 2012) Sobre as caracterizaes das Integraes Tecnolgicas no Brasil, atribua V (verdadeiro) ou F
(falso) s afirmativas a seguir.
( ) Integrao da Gesto Estratgica com os processos de manufatura, atravs de aplicaes de Product Life
Cycle Management e de Product Data Management.
( ) Integrao das cadeias de suprimentos, atravs de aplicaes de supply-chain e da infraestrutura de
comunicao e Internet.
( ) Integrao dos processos de desenvolvimentos de produtos com os processos de gesto de clientes
altamente sofisticados, atravs de aplicativos de Customer Resource Management.
( ) Integrao entre a gesto da empresa e o seu cho de fbrica, atravs de aplicaes de Enterprise
Resource Planning - ERP e Manufacturing Execution System - MES.
( ) Integrao entre as funes administrativas e padronizao dos aplicativos de back-office no contexto da
empresa, de suas divises e filiais, atravs de Enterprise Resource Planning - ERP.
65
Assinale a alternativa que contm, de cima para baixo, a sequncia correta.
(a) V, F, V, F, F.
(b) V, F, F, F, V.
(c) F, V, V, F, F.
xx
(d) F, V, F, V, V.
(e) F, F, F, V, V.

62

TI para concursos

44

66

66.

(ICMS-PR 2012) Sobre o planejamento do Programa de Governana de TI, assinale a alternativa correta.
(a) A construo do CobiT requer intensa colaborao entre o pessoal de negcios e o de TI. Comparando
com a avaliao com base no Balanced Scorecard, diz-se que o CobiT emprega uma abordagem
dedutiva.
(b) No Balanced Scorecard, o escopo do Programa de Governana de TI ser uma lista de processos que
necessitam ser melhorados, ou seja, devem evoluir para um patamar de maturidade maior ou realizar a
implantao de um processo inexistente.
(c) O modelo Balanced Scorecard fornece todo o instrumental para a avaliao da maturidade dos
processos, para o estabelecimento de metas de maturidade e dos atributos de maturidade do processo
nos quais se deve interferir para a melhoria de desempenho.
(d) Para a concepo de um modelo de Governana de TI, o emprego do CobiT mais focado, mas ainda
pouco empregado na rea de TI, entretanto com ele possvel ter maior liberdade para usar o Balanced
Scorecard e outros modelos, conforme for mais apropriado.
(e) Segundo o padro para o Gerenciamento de Programas do PMI, o ciclo de vida de um programa
constitudo por: Set-up do Pr-Programa ! Set-up do Programa ! Infraestrutura do Programa ! Entrega dos
xx
Benefcios ! Encerramento do Programa.

67.

(CVM 2010) Assinale a opo correta.


(a) A estratgia de outsourcing decide como gerenciar o desempenho dos equipamentos.
(b) O objetivo principal da Governana de TI gerenciar outsourcing.
(c) A estratgia de outsourcing decide como gerenciar os negcios internos dos fornecedores ou prestadores
de servios.
(d) O objetivo principal da Governana de TI escolher a melhor alternativa de programao.
xx
(e) O objetivo principal da Governana de TI alinhar TI aos requisitos do negcio.

68.

(SUSEP 2010) Um dos fatores motivadores da Governana de TI


xx
(a) a dependncia do negcio em relao TI.
(b) o ambiente de trabalho.
(c) a integrao organizacional.
(d) a TI como provedora de servios.
(e) o valor da informao.

69.

(SUSEP 2010) Em relao ao COBIT, correto afirmar que o mesmo69


(a) estabelece posicionamentos com os registros do negcio.
(b) identifica os principais recursos de WFD, nos quais deve haver menos requisitos.
xx
(c) organiza as atividades de TI em um modelo de processos genrico.
(d) estabelece prioridades entre os responsveis pelo negcio.
(e) define as mtricas sem controle que devem ser sequenciadas no desenvolvimento.

70.

(SUSEP 2010) Entre as aplicaes do COBIT em uma organizao, situam-se70


(a) auditoria de riscos operacionais de concorrentes e qualificao de armazenadores de TI.
(b) implantao modular da Governana de TI e realizao de benchmarking. xx
(c) avaliao dos topservers de TI e desenvolvimento dos riscos situacionais de TI.
(d) desmembramento de riscos e benefcios da TI e realizao de branch and bound.
(e) atualizao de casual failures e implantao exgena da Governana de TI.

71.

(SUSEP 2010) As reas foco da Governana de TI na viso do COBIT so:71


(a) Alinhamento Estratgico, Agregao de Valor, Gerenciamento de Riscos, Gerenciamento de Recursos e
Medies de Desempenho.xx
(b) Alinhamento Estratgico, Medies de Perdas, Gerenciamento de Riscos, Gerenciamento de Requisitos e
Condies de Mercado.
(c) Planejamento Estratgico, Valores de Ativos, Gerenciamento de Pessoas, Agregao de Componentes e
Medies de Custos.
(d) Aquisies Estratgicas, Composio de Valor, Gerenciamento de Benefcios, Gerenciamento de
Recursos e Modificaes de Desempenho.
(e) Alinhamento de Desempenho, Associao de Valores e Benefcios, Gerenciamento de Decises,
Gerenciamento de Perda de Recursos e Medies de Riscos.

72.

(SUSEP 2010) A cobertura CMMI completa quanto ao COBIT 4.0 em


(a) monitorar e avaliar os controles internos.
(b) determinar a direo tecnolgica.
(c) garantir a segurana dos sistemas.
(d) gerenciar desempenho e capacidade.
(e) gerenciar mudanas.xx

67

68

72

TI para concursos

45

73

73.

(CVM 2010) Os nveis dos modelos de maturidade do COBIT so:


(a) Insipiente (0). Inicial / Ad hoc (1). Repetitivo mas intuitivo (2). Programado (3). Gerenciado e qualitativo
(4). Finalizado (5).
(b) Inexistente (0). Programado (1). Repetitivo mas dedutivo (2). Definido (3). Gerenciado e mensurvel (4).
Repetitivo (5).
(c) Inexistente (0). Em definio (1). Restritivo mas intuitivo (2). Otimizado (3). Gerenciado e mensurvel (4).
Disponibilizado (5).
(d) A definir (0). Inicial / Ad hoc (1). Repetitivo e redundante (2). Definido (3). Orientado para mensurao (4).
Maximizado (5).
(e) Inexistente (0). Inicial / Ad hoc (1). Repetitivo mas intuitivo (2). Definido (3). Gerenciado e mensurvel (4).
xx
Otimizado (5).

74.

(TER ES 2011) Julgue os itens, a respeito de COBIT e ITIL 3.


I - O gerente de determinada organizao foi incumbido de definir nvel de servios (SLA) relacionados
tecnologia da informao (TI) nessa organizao, com base no ITIL e no COBIT. Nessa situao, por se tratar
de servio, deve o gerente utilizar o ITIL como nica referncia, visto que o COBIT no trata de SLA,
abordando nveis de servio apenas da perspectiva de auditoria e alinhamento desses nveis estratgia do
negcio.
II - Um gestor de TI que deseje monitorar e avaliar os controles internos, a fim de assegurar a conformidade
dos processos com as leis e os regulamentos de TI, deve pautar-se especialmente pelo COBIT, visto que, no
xx
ITIL, no so abordados gerenciamentos relacionados a avaliao e monitorao de controles internos.
III - Tanto no COBIT quanto no ITIL, h gerenciamento de configurao, que possibilita criar e manter um
repositrio central de dados sobre os itens de configurao da organizao. No COBIT, essa gerncia
xx
pertence ao domnio Entrega e Suporte; no ITIL, est descrita na Transio do Servio.
IV - Comparando-se, no nvel macro, os processos do COBIT e as gerncias do ITIL, correto afirmar que h
maior correlao das gerncias do ITIL com os processos do domnio Entrega e Suporte do COBIT que com
xx
os do domnio Planejamento e Organizao.
Esto corretos os itens:
(a) I, II e IV apenas
(b) II e III apenas
(c) II, III e IV apenas xx
(d) I e II apenas
(e) I e IV apenas.

75.

(TER ES 2011) Julgue os itens, a respeito de COBIT e ITIL 3.75


I - O gerenciamento de mudanas referenciado na Transio de Servios do ITIL e no domnio Entrega e
Suporte do COBIT.
II - O foco do ITIL o gerenciamento de servios, o do COBIT, o negcio, do que se conclui que aspectos
relacionados gerncia financeira e de investimentos de TI so tratados pelo COBIT, mas no pelo ITIL.
III - Diferentemente do ITIL, que no prev gerncia para tratar diretamente da arquitetura da informao, no
COBIT h um processo que visa estabelecer um modelo de dados de negcio, no qual se incluem esquemas
de classificao de dados, com o objetivo de asseverar consistncia e integridade e consistncia dos dados. xx
Esto corretos os itens:
(a) I, II e III
(b) I, III apenas
(c) I apenas
(d) II apenas
xx
(e) III apenas.

74

TI para concursos

Segurana da informao

4.1

Conceitos bsicos
Segurana da Informao a proteo de um conjunto de dados, no sentido de preservar o valor que
possuem para um indivduo ou uma organizao.
O conceito de Segurana Informtica ou Segurana de Computadores inclui a segurana dos
dados/informao e a dos sistemas em si.20
Entende-se por informao todo e qualquer contedo ou dado que tenha valor para alguma organizao
ou pessoa. Ela pode estar guardada para uso restrito ou exposta ao pblico para consulta ou aquisio.
Podem ser estabelecidas mtricas para a definio do nvel de segurana existente e, com isto, serem
estabelecidas as bases para anlise da situao. A segurana de uma determinada informao pode ser
afetada por fatores comportamentais e de uso de quem se utiliza dela, pelo ambiente ou infra-estrutura.
Os atributos bsicos da segurana:
Confidencialidade - propriedade que limita o acesso a informao s entidades legtimas, ou seja,
quelas autorizadas pelo proprietrio da informao.
Integridade - propriedade que garante que a informao mantenha todas as caractersticas originais
estabelecidas pelo proprietrio da informao, incluindo controle de mudanas e garantia do seu ciclo
de vida (nascimento, manuteno e destruio).
Disponibilidade - propriedade que garante que a informao esteja sempre disponvel para o uso
legtimo, ou seja, por aqueles usurios autorizados pelo proprietrio da informao.
O nvel de segurana desejado, pode se consubstanciar em uma "poltica de segurana" que seguida
pela organizao ou pessoa, para garantir que, uma vez estabelecidos os princpios, aquele nvel
desejado seja perseguido e mantido. Para a montagem desta poltica, deve-se levar em conta:
Riscos associados falta de segurana;
Benefcios;
Custos de implementao dos mecanismos.
O suporte para as recomendaes de segurana pode ser encontrado em:
Controles fsicos: so barreiras que limitam o contato ou acesso direto a informao ou a infraestrutura que a suporta, como portas, trancas, paredes, blindagem, guardas etc.
Controles lgicos: so barreiras que impedem ou limitam o acesso a informao, que est em
ambiente controlado, geralmente eletrnico.
Mecanismos de criptografia. Permitem a transformao reversvel da informao de forma a torn-la
ininteligvel a terceiros. Utiliza-se para tal, algoritmos determinados e uma chave secreta para, a partir de
um conjunto de dados no criptografados, produzir uma sequncia de dados criptografados. A operao
inversa a decifrao. Os algoritmos com chave dupla, ou chaves assimtricas, podem usar uma chave
pblica para criptografar e uma chave diferente, privada, secreta, para decifrar.
Assinatura digital. Um conjunto de dados criptografados, associados a um documento do qual so funo,
garantindo a integridade do documento associado, mas no a sua confidencialidade.
Mecanismos de garantia da integridade da informao. Usando funes de "Hashing" ou de checagem,
consistindo na adio.
Mecanismos de controle de acesso. Palavras-chave, sistemas biomtricos, firewalls, cartes inteligentes.
Mecanismos de certificao. Atesta a validade de um documento.
Integridade. Medida em que um servio/informao genuno, isto , est protegido contra a
personificao por intrusos.
Honeypot: o nome dado a um software, cuja funo detectar ou de impedir a ao de um cracker, de
um spammer, ou de qualquer agente externo estranho ao sistema, enganando-o, fazendo-o pensar que
esteja de fato explorando uma vulnerabilidade daquele sistema.
Protocolos seguros: uso de protocolos que garantem um grau de segurana.

Existe hoje em dia um elevado nmero de ferramentas e sistemas que pretendem fornecer segurana.
Alguns exemplos so os detectores de intruses, os anti-vrus, firewalls, firewalls locais, filtros anti-spam,
fuzzers, analisadores de cdigo, etc.
As ameaas segurana da informao so relacionadas diretamente perda de uma de suas trs
caractersticas principais, quais sejam:
Perda de Confidencialidade: quebra de sigilo de uma determinada informao (ex: a senha de um
usurio ou administrador de sistema) permitindo com que sejam expostas informaes restritas as
quais seriam acessveis apenas por um determinado grupo de usurios.

http://pt.wikipedia.org/wiki/Seguran%C3%A7a_da_informa%C3%A7%C3%A3o
46
20

TI para concursos

Perda de Integridade: determinada informao fica exposta a manuseio por uma pessoa no
autorizada, que efetua alteraes que no foram aprovadas e no esto sob o controle do proprietrio
(corporativo ou privado) da informao.
Perda de Disponibilidade: a informao deixa de estar acessvel por quem necessita dela.
No caso de ameaas rede de computadores ou a um sistema, estas podem vir de agentes maliciosos,
muitas vezes conhecidos como crackers (hackers no so agentes maliciosos, pois tentam ajudar a
encontrar possiveis falhas). Estas pessoas so motivadas para fazer esta ilegalidade por vrios motivos.
Os principais so: notoriedade, auto-estima, vingana e o dinheiro. De acordo com pesquisa elaborada
pelo Computer Security Institute, mais de 70% dos ataques partem de usurios legtimos de sistemas de
informao (Insiders) -- o que motiva corporaes a investir largamente em controles de segurana para
seus ambientes corporativos (intranet).
Depois de identificado o potencial de ataque, as organizaes tm que decidir o nvel de segurana a
estabelecer para uma rede ou sistema os recursos fsicos e lgicos a necessitar de proteo. No nvel de
segurana devem ser quantificados os custos associados aos ataques e os associados implementao
de mecanismos de proteo para minimizar a probabilidade de ocorrncia de um ataque.
Segurana fsica - Considera as ameaas fsicas como incndios, desabamentos, relmpagos,
alagamento, acesso indevido de pessoas, forma inadequada de tratamento e manuseamento do
material.
Segurana lgica - Atenta contra ameaas ocasionadas por vrus, acessos remotos rede, backup
desatualizados, violao de senhas etc.
De acordo com o RFC 2196 (The Site Security Handbook), uma poltica de segurana consiste num
conjunto formal de regras que devem ser seguidas pelos utilizadores dos recursos de uma organizao.
As polticas de segurana devem ter implementao realista, e definir claramente as reas de
responsabilidade dos utilizadores, do pessoal de gesto de sistemas e redes e da direo. Deve tambm
adaptar-se a alteraes na organizao. As polticas de segurana fornecem um enquadramento para a
implementao de mecanismos de segurana, definem procedimentos de segurana adequados,
processos de auditoria segurana e estabelecem uma base para procedimentos legais na sequncia
de ataques.
O documento que define a poltica de segurana deve deixar de fora todos os aspectos tcnicos de
implementao dos mecanismos de segurana, pois essa implementao pode variar ao longo do
tempo. Deve ser tambm um documento de fcil leitura e compreenso, alm de resumido.
Algumas normas definem aspectos que devem ser levados em considerao ao elaborar polticas de
segurana. Entre essas normas esto a BS 7799 (elaborada pela British Standards Institution) e a NBR
ISO/IEC 17799 (a verso brasileira desta primeira). A ISO publicou a srie de normas 27000, em
substituio ISO 17799 (e por conseguinte BS 7799), das quais a primeira, ISO 27001, foi publicada
em 2005.
Existem duas filosofias por trs de qualquer poltica de segurana: a proibitiva (tudo que no
expressamente permitido proibido) e a permissiva (tudo que no proibido permitido).
Os elementos da poltica de segurana devem ser considerados:
Disponibilidade: o sistema deve estar disponvel de forma que quando o usurio necessitar possa
usar. Dados crticos devem estar disponveis ininterruptamente.
Utilizao: o sistema deve ser utilizado apenas para os determinados objetivos.
Integridade: o sistema deve estar sempre ntegro e em condies de ser usado.
Autenticidade: o sistema deve ter condies de verificar a identidade dos usurios, e este ter
condies de analisar a identidade do sistema.
Confidencialidade: dados privados devem ser apresentados somente aos donos dos dados ou ao
grupo por ele liberado.

4.2

Plano de Continuidade de Negcio


Business Continuity Plan (BCP) o desenvolvimento preventivo de um conjunto de estratgias e planos
de ao de maneira a garantir que os servios essenciais sejam devidamente identificados e
preservados aps a ocorrncia de um desastre e at o retorno situao normal de funcionamento da
empresa dentro do contexto do negcio do qual ela faz parte. Alm disso, sob o ponto de vista do PCN,
o funcionamento de uma empresa deve-se a duas variveis: os componentes e os processos.21
Os componentes so todas as variveis utilizadas para realizao dos processos: energia, pessoas,
telecomunicaes, informtica, infra-estrutura. Todas elas podem ser substitudas ou restauradas, de
acordo com suas caractersticas.

http://pt.wikipedia.org/wiki/Plano_de_continuidade_de_neg%C3%B3cios
47
21

TI para concursos

J os processos so as atividades realizadas para operar os negcios da empresa.


O Plano de Continuidade de Negcios constitudo pelos seguintes planos:
Plano de Administrao de Crises (PAC)
Plano de Recuperao de Desastres (PRD)
Plano de Continuidade Operacional (PCO)
Todos estes planos tm como objetivo principal a formalizao de aes a serem tomadas para que, em
momentos de crise, a recuperao, a continuidade e a retomada possam ser efetivas, evitando que os
processos crticos de negcio da organizao sejam afetados, o que pode acarretar em perdas
financeiras.
A norma ISO 27002 estabelece uma estrutura de planejamento com diversos procedimentos:
Emergncia
Aes a serem tomadas aps a ocorrncia de um incidente que coloque em risco as operaes do
negcio;
Recuperao
Aes necessrias para a transferncia das atividades essenciais do negcio ou os servios de infraestrutura para localidades alternativas temporrias e para a reativao dos processos do negcio no
prazo necessrio;
Aes a serem adotadas quando do restabelecimento das operaes;
Operacionais temporrios
Para seguir durante a concluso de recuperao e restaurao;
A norma no define o que restaurao. Para a Microsoft, restaurao o procedimento de retornar um
sistema a um estado anterior. Para o dicionrio de portugus, sinnimo de recuperar..
No que diz respeito necessidade de atualizaes, o Plano de Continuidade de Negcios deve ser
revisado periodicamente, pois mudanas significativas em componentes, atividades ou processos
crticos de negcio podem fazer com que novas estratgias e planos de ao sejam previstos, evitando
assim com que eventuais desastres desestabilizem profundamente o andamento regular do negcio da
empresa.
Desastre pode ser entendido como qualquer situao que afete os processos crticos do negcio de uma
organizao. Conseqentemente, algumas ocorrncias podem ser caracterizadas como sendo desastres
para uma determinada empresa, mas podem no ser caracterizadas como um desastre para outra
empresa.
As principais etapas de um plano de continuidade so:
Analise de riscos - Analisa-se o grau de exposio a que o negcio pode estar exposto. Sejam
exposies de ao natural (vendaval, inundao, fogo) ou aquelas da ao do homem (sabotagem,
erro ou falha humana).
Analise dos impactos no negcio - anlise dos impactos da perda no negcio da organizao. Neste
estudo devem-se identificar as aplicaes mais criticas para o negcio e seu tempo de recuperao
necessrio para a continuidade.
Estratgia de recuperao - planejamento do maior nmero de possibilidades e formas de
recuperao, que seja rpida, eficiente e com baixo custo.

4.3

Vulnerabilidade
A vulnerabilidade na computao significa ter brecha em um sistema computacional, tambm conhecida
como bug. Esta mesma pode ser explorada em um determinado sistema ou servio vulnervel que
esteja rodando na mquina.
As vulnerabilidades mais exploradas nos dias de hoje, so as do tipo buffer overflow, que muitas vezes
pode dar privilgios de administrador para o invasor, rodar cdigos maliciosos remotamente, burlar
particularidades de cada sistema, ataques de Negao de Servios (DDoS), e acesso irestrito ao
sistema.
Existem ferramentas especficas 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 so chamadas de exploits.
Um exploit, em segurana da informao, um programa de computador, uma poro de dados ou uma
sequncia de comandos que se aproveita das vulnerabilidades de um sistema computacional como o
prprio sistema operacional ou servios de interao de protocolos (ex: servidores Web). So
geralmente elaborados por hackers como programas de demonstrao das vulnerabilidades, a fim de
que as falhas sejam corrigidas, ou por crackers a fim de ganhar acesso no autorizado a sistemas. Por
isso muitos crackers no publicam seus exploits, conhecidos como 0days, e o seu uso massificado devese aos script kiddies.

48

TI para concursos

At meados dos anos 90, acreditava-se que os exploits exploravam exclusivamente problemas em
aplicaes e servios para plataformas Unix. A partir do final da dcada, especialistas demonstraram a
capacidade de explorar vulnerabilidades em plataformas de uso massivo, por exemplo, sistemas
operacionais Win32 (Windows 9x, NT, 2000 e XP). Como exemplo temos o CodeRed, o MyDoom, o
Sasser em 2004 e o Zotob em 2005.
Para um exploit atacar, o sistema precisa ter uma vulnerabilidade, ou seja, um meio de comunicao
com a rede que possa ser usado para entrar, uma porta ou uma consola.
Um exploit muito usado no sistema RPC do Windows:
o usurio localiza a porta e envia porta RPC uma sequncia de bytes, que so interpretados como
dados pelo servidor
quando so recebidos, estes dados deixam propositadamente o sistema em pane
o sistema passa o controle a estes prprios dados que ento so uma sequncia de ordem para dominar
a CPU.

Desta forma esta sequncia de informaes toma conta do PC e abre-o para o hacker que aguarda na
outra ponta.
Ameaas segurana das redes que fazem com que os micros infectados por esses tipos de vrus
formem redes de computadores "zumbis" que so comandados simultaneamente por seus invasores
para enviar mensagens indesejadas (spam), colocar sites fora do ar e promover fraudes so
categorizadas como botnet (robs).
Keylogger um programa capaz de capturar e armazenar as teclas digitadas pelo usurio no teclado de
um computador.
No sistema Linux, quando existem vulnerabilidades, sempre so publicadas, como j houve no sistema
Apache, Samba ou MySQL, que tambm apresentam vulnerabilidades e possibilita o controle do PC por
um hacker remoto. Com isso um hacker pode ter acesso a todos seus arquivos pessoais, Usando o
proprio CMD do windows.

4.4

Auditoria e conformidade
A Auditoria da TI uma auditoria operacional, analisa a gesto de recursos, com o foco nos aspectos de
eficincia, eficcia, economia e efetividade. A abrangncia desse tipo de auditoria pode ser o ambiente
de informtica como um todo ou a organizao do departamento de informtica:22
Ambiente de informtica:

Segurana dos outros controles;


Segurana fsica;
Segurana lgica;
Planejamento de contingncias;
Operao do centro de processamento de dados.

Organizao do departamento de informtica:


Aspectos administrativos da organizao;
Polticas, padres, procedimentos, responsabilidades organizacionais, gerncia pessoal e planejamento
de capacidade;
Banco de dados;
Redes de comunicao e computadores;
Controle sobre aplicativos:
Desenvolvimento,
Entradas, processamento e sadas.

Auditoria da tecnologia da informao abrangente, engloba todos os controles que podem influenciar a
segurana de informao e o correto funcionamento dos sistemas de toda a organizao:
Controles organizacionais;
De mudana;
De operao de sistemas;
Sobre Banco de Dados;
Sobre microcomputadores;
Sobre ambiente cliente-servidor.
Auditoria da segurana de informaes determina a postura da organizao com relao segurana.
Avalia a poltica de segurana e controles relacionados com aspectos de segurana institucional mais
globais, faz parte da auditoria da TI. Seu escopo envolve:
Avaliao da poltica de segurana;
Controles de acesso lgico;
Controles de acesso fsicos;
http://pucrs.campus2.br/~annes/sas_audit.doc
49
22

TI para concursos

Controles ambientais;
Planos de contingncia e continuidade de servios.
Auditoria de aplicativos verifica a segurana e o controle de aplicativos especficos, incluindo aspectos
intrnsecos rea a que o aplicativo atende:
Controles sobre o desenvolvimento de sistemas aplicativos;
Controles de entradas, processamento e sada de dados;
Controle sobre contedo e funcionamento do aplicativo, com relao rea por ele atendida.
A natureza especializada da auditoria de sistemas de informao (SI) e a capacidade necessria para
realizar essas auditorias requerem o estabelecimento de normas que se apliquem especificamente
auditoria de SI. 23
A Associao de Auditoria e Controle de Sistemas de Informao, ISACA, desenvolve normas aplicveis
globalmente, de forma a suportar essa viso. A estrutura das Normas de Auditoria de SI apresenta
diversos nveis de orientao:
Normas: definem requisitos obrigatrios para auditorias e relatrios de SI. Informam:
Os auditores de SI sobre o nvel mnimo de desempenho aceitvel exigido para cumprir as
responsabilidades profissionais estabelecidas no Cdigo de tica Profissional
A gesto e outras partes interessadas sobre as expectativas da profisso no que se refere s atividades
daqueles que a exercem

Diretrizes: fornecem orientao para a aplicao das normas de auditoria de SI. O auditor de SI deve
lev-las em considerao para determinar como alcanar a implementao das normas, utilizar a
avaliao profissional na sua aplicao e estar preparado para justificar qualquer divergncia. O
objetivo das Directrizes de Auditoria de SI fornecer informaes adicionais sobre como cumprir as
Normas de Auditoria de SI.
Procedimentos: fornecem exemplos de procedimentos que um auditor de SI pode seguir durante a
realizao de uma auditoria. Os documentos de procedimentos fornecem informaes sobre como
cumprir as normas ao realizar a auditoria de SI, mas no estabelecem requisitos. O objetivo dos
Procedimentos de Auditoria de SI fornecer informaes adicionais sobre como cumprir as Normas
de Auditoria de SI.
As normas da ISACA contm princpios bsicos e procedimentos essenciais que so obrigatrios,
juntamente com orientaes relacionadas com os mesmos, com o objetivo de estabelecer e fornecer
orientaes sobre reas de governana de TI que o auditor de SI deve considerar durante o processo de
auditoria.
O auditor de SI deve analisar e avaliar:
ambiente de controle da organizao.
conformidade com a organizao: misso, viso, valores, qualidade de informaes, objetivos e
estratgias.
conformidade com as leis: ambientais, trabalhistas, fiducirias e de segurana.
eficincia e eficcia de SI, as suas realizaes e os processos de gesto de desempenho.
riscos que podem causar efeitos adversos no ambiente de SI.

Diretrizes de auditoria de SI:

4.5

Carta de auditoria
Conceitos de materialidade para auditoria de sistemas de informaes
Relacionamento e independncia organizacionais
Uso da avaliao de riscos no planeamento de auditoria
Planeamento - lista detalhada das tarefas
Impacto de terceiros em controles de TI de uma organizao
Impacto de funo de no auditoria na independncia do auditor de SI

Conhecimento sobre norma ISO 27001


ISO/IEC 27001 um padro para sistema de gerncia da segurana da informao (ISMS - Information
Security Management System) publicado em outubro de 2005 pelo International Organization for
Standardization e pelo International Electrotechnical Commision. Seu nome completo ISO/IEC
27001:2005 - Tecnologia da informao - tcnicas de segurana - sistemas de gerncia da segurana da
24
informao - requisitos mas conhecido como "ISO 27001".
Esta Norma foi preparada para prover um modelo para estabelecer, implementar, operar, monitorar,
analisar criticamente, manter e melhorar um Sistema de Gesto de Segurana da Informao
(SGSI/ISMS).
Seu objetivo ser usado em conjunto com ISO/IEC 17799, renomeada para ISO 27002, o cdigo de
prticas para gerncia da segurana da informao, o qual lista objetivos do controle de segurana e
recomenda um conjunto de especificaes de controles de segurana. Organizaes que implementam

http://www.isaca.org/Template.cfm?Section=Home&Template=/ContentManagement/ContentDisplay.cfm&ContentFileID=10775
http://pt.wikipedia.org/wiki/ISO_27001
50
23
24

TI para concursos

um ISMS de acordo com as melhores prticas da ISO 17799 esto simultaneamente em acordo com os
requisitos da ISO 27001, mas uma certificao totalmente opcional.
Este padro o primeiro da famlia de segurana da informao relacionado aos padres ISO que
espera-se sejam agrupados srie 27000.
ISO 27000 - Vocabulrio de Gesto da Segurana da Informao;
ISO 27001 - Publicada em Outubro de 2005 e substituiu a norma BS 7799-2 para certificao de
sistema de gesto de segurana da informao;
ISO 27002 - Cdigo de Boas Prticas. Substituiu em 2006/2007 o ISO 17799:2005;
ISO 27003 - Esta norma aborda a gesto de risco, contendo recomendaes para a definio e
implementao de um sistema de gesto de segurana da informao.
ISO 27004 - Esta norma incide sobre os mecanismos de mediao e de relatrio de um sistema de
gesto de segurana da informao.
ISO 27005 - Esta norma ser constituda por indicaes para implementao, monitoramento e
melhoria contnua do sistema de controles. Contedo idntico ao da norma BS 7799-3:2005
Information Security Management Systems - Guidelines for Information Security Risk Management;
ISO 27006 - Referente recuperao e continuidade de negcio.
ISO 27001 foi baseado e substitui o BS 7799 parte 2.
A srie ISO 27000 est de acordo com outros padres de sistemas de gerncia ISO, como ISO 9001
(sistemas de gerncia da qualidade) e ISO 14001 (sistemas de gerncia ambiental), ambos em acordo
com suas estruturas gerais e de natureza a combinar as melhores prticas com padres de certificao.
Certificaes de organizao com ISMS ISO/IEC 27001 um meio de garantir que a organizao
certificada implementou um sistema para gerncia da segurana da informao de acordo com os
padres. Credibilidade a chave de ser certificado por uma terceira parte que respeitada,
independente e competente. Esta garantia d confiana gerncia, parceiros de negcios, clientes e
auditores que uma organizao sria sobre gerncia de segurana da informao - no perfeita,
necessariamente, mas est rigorosamente no caminho certo de melhora contnua.
Esta Norma adota o modelo conhecido como "Plan-Do-Check-Act (PDCA), que aplicado para
estruturar todos os processos do SGSI. Esta figura ilustra como um SGSI considera as entradas de
requisitos de segurana de informao e as expectativas das partes interessadas, e como as aes
necessrias e processos de segurana da informao produzidos resultam no atendimento a estes
requisitos e expectativas.

Ilustrao 9 Modelo PDCA aplicado aos processos do SGSI

Esta norma apresenta alguma definies:


Ativo
Qualquer coisa que tenha valor para a organizao
Disponibilidade
Propriedade de estar acessvel e utilizvel sob demanda por uma entidade autorizada
Confidencialidade
Propriedade de que a informao no esteja disponvel ou revelada a indivduos, entidades ou
processos no autorizados
Segurana da informao
Preservao da confidencialidade, integridade e disponibilidade da informao; adicionalmente,
outras propriedades, tais como autenticidade, responsabilidade, no repdio e confiabilidade, podem
tambm estar envolvidas
51

TI para concursos

Evento de segurana da informao


Uma ocorrncia identificada de um estado de sistema, servio ou rede, indicando uma possvel
violao da poltica de segurana da informao ou falha de controles, ou uma situao previamente
desconhecida, que possa ser relevante para a segurana da informao
Incidente de segurana da informao
Um simples ou uma srie de eventos de segurana da informao indesejados ou inesperados, que
tenham uma grande probabilidade de comprometer as operaes do negcio e ameaar a segurana
da informao
Sistema de gesto da segurana da informao - SGSI
A parte do sistema de gesto global, baseado na abordagem de riscos do negcio, para estabelecer,
implementar, operar, monitorar, analisar criticamente, manter e melhorar a segurana da informao
O sistema de gesto inclui estrutura organizacional, polticas, atividades de planejamento,
responsabilidades, prticas, procedimentos, processos e recursos.
Integridade
Propriedade de salvaguarda da exatido e completeza de ativos
Risco residual
Risco remanescente aps o tratamento de riscos
Aceitao do risco
Deciso de aceitar um risco
Anlise de riscos
Uso sistemtico de informaes para identificar fontes e estimar o risco
Anlise/avaliao de riscos
Processo completo de anlise e avaliao de riscos
Avaliao de riscos
Processo de comparar o risco estimado com critrios de risco predefinidos para determinar a
importncia do risco
Gesto de riscos
Atividades coordenadas para direcionar e controlar uma organizao no que se refere a riscos
A gesto de riscos geralmente inclui a anlise/avaliao de riscos, o tratamento de riscos, a aceitao
de riscos e a comunicao de riscos.
Um dos procedimentos previstos na norma identificar os riscos.
Identificar os ativos dentro do escopo do SGSI e os proprietrios destes ativos.
Identificar as ameaas a esses ativos.
Identificar as vulnerabilidades que podem ser exploradas pelas ameaas.
Identificar os impactos que as perdas de confidencialidade, integridade e disponibilidade podem
causar aos ativos.
Um SGSI deve identificar e avaliar as opes para o tratamento de riscos. Possveis aes incluem:
aplicar os controles apropriados;
aceitar os riscos consciente e objetivamente, desde que satisfaam claramente s polticas da
organizao e aos critrios de aceitao de riscos;
evitar riscos;
transferir os riscos associados ao negcio a outras partes, por exemplo, seguradoras e fornecedores.
A norma ISO 27002, consolida procedimentos de segurana de informao em um cdigo de prticas
para a gesto da segurana da informao.
A ISO trata tambm de conformidade com requisitos legais, para evitar violao de qualquer lei criminal
ou civil, estatutos, regulamentaes ou obrigaes contratuais e de quaisquer requisitos de segurana
da informao. O projeto, a operao, o uso e a gesto de sistemas de informao podem estar sujeitos
a requisitos de segurana contratuais, regulamentares ou estatutrios.

4.6

Exerccios
76.

52

(ICMS-SP 2009) Segundo as normas ABNT sobre segurana da informao, o tratamento de risco est
inserido no processo de76
xx
(a) gesto de riscos.
(b) aceitao do risco.
(c) anlise de riscos.
(d) avaliao de riscos.
(e) anlise/avaliao de riscos.

TI para concursos

53

77.

(ICMS-SP 2009) As aes a serem tomadas imediatamente aps a ocorrncia de um incidente que coloque
em risco as operaes do negcio devem estar descritas no plano de continuidade de negcios como
procedimentos77
(a) operacionais temporrios.
(b) de ensaio geral.
(c) de recuperao.
(d) de restaurao.
(e) de emergncia.xx

78.

(ICMS-SP 2009) Se qualquer no-conformidade for encontrada como um resultado da anlise crtica nas reas
78
sobre o cumprimento das polticas e normas de segurana da informao, NO convm que os gestores
(a) determinem as causas da no-conformidade.
(b) determinem e implementem ao corretiva apropriada.
(c) analisem criticamente a ao corretiva tomada.
(d) avaliem a necessidade de aes para assegurar que a conformidade no se repita. xx
(e) registrem os resultados das anlises e das aes corretivas e que esses registros sejam mantidos.

79.

(ICMS-SP 2009) No modelo PDCA adotado para estruturar todos os processos do SGSI Sistema de Gesto
de Segurana da Informao, os resultados das atividades da auditoria interna do SGSI esto vinculados ao
ciclo PDCA como entrada dos processos na etapa79
(a) Plan (Planejar): estabelecer o SGSI.
(b) Do (Fazer): implementar e operar o SGSI.
(c) Check (Verificar): monitorar o SGSI.
(d) Control (Controlar): analisar criticamente o SGSI.
xx
(e) Act (Agir): manter e melhorar o SGSI.

80.

No Brasil, a NBR ISO17799 constitui um padro de recomendaes para prticas na gesto de Segurana da
Informao. De acordo com o estabelecido nesse padro, trs termos assumem papel de importncia capital:
confidencialidade, integridade e disponibilidade.
Nesse contexto, a confidencialidade tem por objetivo:80
(a) salvaguardar a exatido e a inteireza das informaes e mtodos de processamento.
(b) salvaguardar os dados gravados no backup por meio de software que utilize assinatura digital.
(c) permitir que os usurios tenham acesso aos arquivos de backup e aos mtodos de criptografia
empregados.
(d) permitir que os usurios autorizados tenham acesso s informaes e aos ativos associados, quando
necessrio.
(e) garantir que as informaes sejam acessveis apenas para aqueles que estejam autorizados a acesslas.xx

81.

Para garantir a segurana da informao em uma rede de computadores, um sistema de autenticao tpico
composto apenas do cdigo do usurio, uma senha e um 81
(a) processo de certificao.
(b) mtodo de criptografia.
(c) sistema de deteco de intruso.
(d) plano de recuperao.
(e) firewall.xx

82.

NO um algoritmo de chave simtrica o sistema de criptografia de chave 82


(a) nica.
xx
(b) pblica.
(c) secreta.
(d) simtrica.
(e) compartilhada.

83.

Um conjunto de dados de computador, em observncia Recomendao Internacional ITUT X.509, que se


destina a registrar, de forma nica, exclusiva e intransfervel, a relao existente entre uma chave de
criptografia e uma pessoa fsica, jurdica, mquina ou aplicao 83
(a) uma autoridade certificadora.
(b) uma trilha de auditoria.
(c) uma chave assimtrica.
(d) uma assinatura digital.
(e) um certificado digital.xx

TI para concursos

54

84.

Considere a seguinte definio: "Evitar violao de qualquer lei criminal ou civil, estatutos, regulamentao ou
obrigaes contratuais; evitar a violao de direitos autorais dos software - manter mecanismos de controle
dos softwares legalmente adquiridos". De acordo com as especificaes das normas brasileiras de segurana
84
da informao, esta definio se inclui corretamente em
(a) Gesto de Incidentes e Segurana da Informao.
xx
(b) Conformidade.
(c) Controle de Acesso.
(d) Gesto da Continuidade do Negcio.
(e) Gesto de Ativos.

85.

um elemento biomtrico de identificao


xx
(a) a impresso digital.
(b) o carto bancrio.
(c) a senha da internet.
(d) o certificado digital.
(e) a assinatura eletrnica.

86.

Ameaas segurana das redes que fazem com que os micros infectados por esses tipos de vrus formem
redes de computadores "zumbis" que so comandados simultaneamente por seus invasores para enviar
mensagens indesejadas (spam), colocar sites fora do ar e promover fraudes so categorizadas como. 86
(a) Advance Fee Fraud.
xx
(b) Botnet.
(c) Hoax.
(d) Phishing.
(e) Rootkit.

87.

Programa capaz de capturar e armazenar as teclas digitadas pelo usurio no teclado de um computador o
(a) Worm.
(b) Spyware.
(c) Backdoor.
xx
(d) Keylogger.
(e) Cavalo de Tria.

88.

Por meio da anlise dos procedimentos para estabelecer e finalizar uma conexo utilizada para troca de
informaes entre dois hosts, obtm-se informaes que permitem uma prospeco sobre os servios por eles
oferecidos. Essa tcnica, utilizada para descobrir um possvel ataque do tipo DoS, denominada88
(a) network security.
(b) file scan.
(c) packet sniffer.
(d) network scan.xx
(e) scan vrus.

89.

A integridade de software medida89


(a) em defeitos por KLOC (milhares de linhas de cdigo).
(b) por sua usabilidade.
(c) pelo mean-time-to-change - MTTC.
(d) por sua conectividade.
(e) pela capacidade do sistema resistir a ataques sua segurana. xx

90.

Em relao aos conceitos de segurana, correto afirmar:90


(a) Confidencialidade a propriedade que se refere ao fato de determinada informao no poder ser
alterada ou destruda de maneira no autorizada.
(b) Medidas fsicas e organizacionais de proteo relacionam-se no apenas proteo de hardware, mas
tambm a elementos lgicos de um sistema. xx
(c) Umidade e temperatura no podem ser consideradas ameaas a uma rede de SI.
(d) Negao de uso um ataque que visa atingir a integridade de um sistema computacional.
(e) Um firewall de rede tornou-se, em dias atuais, um equipamento desnecessrio, desde que todos os
computadores da rede sejam dotados de antivrus ativos e atualizados.

91.

A Disponibilidade do sistema, a Integridade dos dados e a Confidencialidade dos dados so objetivos de


segurana dos sistemas, respectivamente, sujeitos s ameaas de91
(a) Adulterao dos dados, Recusa de servio e Exposio aos dados.
(b) Recusa de servio, Exposio aos dados e Adulterao dos dados.
(c) Exposio aos dados, Recusa de servio e Adulterao dos dados.
(d) Recusa de servio, Adulterao dos dados e Exposio aos dados. xx
(e) Exposio aos dados, Adulterao dos dados e Recusa de servio.

92.

Na disciplina de segurana de redes e criptografia, a propriedade que traduz a confiana em que a mensagem
no tenha sido alterada desde o momento de criao :92
(a) autenticidade.
(b) criptologia.
(c) no-repdio.
xx
(d) integridade.
(e) confidencialidade.

85

87

TI para concursos

55

93.

Os mecanismos de segurana para autenticao efetiva de um usurio devem ser baseados em:
I. Conhecimento individual.
II. Posse de alguma coisa.
III. Caracterstica pessoal.
IV. Local em que se encontra.
93
correto o que se afirma em
(a) I, II e III, apenas.
(b) I, II e IV, apenas.
(c) I, III e IV, apenas.
(d) II, III e IV, apenas.
xx
(e) I, II, III e IV.

94.

Receber as solicitaes de servios, oriundas de clientes internos, e envi-las para a rede externa como se
94
fosse o cliente de origem uma funo do
(a) criptgrafo.
(b) firewall.
xx
(c) proxy.
(d) soquete.
(e) broadcast.

95.

Sobre segurana da informao, correto afirmar que95


(a) vulnerabilidades determinam controles de segurana.
(b) riscos so determinados pelas vulnerabilidades.
(c) controles de segurana eliminam os riscos.
xx
(d) ameaas exploram vulnerabilidades.
(e) vulnerabilidades provocam ameaas.

96.

O controle de acesso lgico pode utilizar, para proteo aos arquivos de dados e de programas, uma senha
pessoal como recurso de96
(a) permisso de acesso.
(b) direito de acesso.
(c) monitorao de acesso.
(d) autenticao do usurio.xx
(e) identificao do usurio.

97.

Com relao estrutura, objetivos e conceitos gerais da NBR ISO/IEC 17799:2005 correto afirmar: 97
(a) Estabelece diretrizes e princpios gerais para iniciar, implementar, manter e melhorar a gesto de
segurana da informao em uma organizao. Os objetivos definidos nesta Norma provem diretrizes
gerais sobre as metas geralmente aceitas para a gesto da segurana da informao.xx
(b) Os objetivos de controle e os controles desta Norma tm como finalidade ser implementados para atender
aos requisitos identificados exclusivamente por meio da classificao das informaes.
(c) Um incidente de segurana da informao indicado por um evento de segurana da informao
esperado, que tenha uma grande probabilidade de comprometer as operaes do negcio e ameaar a
segurana da informao.
(d) A gesto de riscos consiste no processo de seleo e implementao de medidas para modificar um
risco. Inclui a anlise, o tratamento e a comunicao de riscos e exclui a aceitao de riscos.
(e) Contm 9 sees de controles de segurana da informao, que juntas totalizam 59 categorias principais
de segurana e uma seo introdutria que aborda a questes de contingncia.

98.

(TCE AM 2012) Com relao ao Plano de Continuidade de Negcio INCORRETO afirmar


(a) Deve ser elaborado um Plano de Continuidade de Negcio que possibilite que a organizao funcione em
um nvel aceitvel para sua sobrevivncia e absorva possveis impactos financeiros, operacionais e de
imagem.
(b) O desenvolvimento do Plano de Continuidade de Negcio deve ser especfico para cada organizao,
pois deve ser baseado em uma anlise de impacto no negcio caso ocorra uma indisponibilidade dos
recursos de informao.
(c) A alta administrao e os acionistas da organizao no precisam conhecer e aprovar as ameaas e
riscos que esto fora de cada verso do Plano de Continuidade de Negcio, pois esses aspectos so
definidos e homologados pela gerncia de TI. xx
(d) O Plano de Continuidade de Negcio deve ser eficiente/ eficaz, mantido atualizado e testado
periodicamente com a participao de todos os envolvidos.
(e) Seu objetivo o planejamento de aes para serem executadas quando da ocorrncia de uma situao
de contingncia, de maneira a garantir que a organizao mantenha suas atividades crticas em um nvel
previamente definido pela rea de negcio e direo como aceitvel.

98

TI para concursos

Arquitetura de Software

O aumento da competitividade e das exigncias impostas s empresas e organizaes leva estas a adotar
modelos organizacionais e processos de negcio cada vez mais complexos e interdependentes. A definio, a
execuo, o controle e a evoluo de tais processos s possvel devido aos avanos nas estruturas
organizacionais e no projeto e uso de sistemas de informao.
Estes sistemas so frequentemente construdos a partir da compreenso e captura dos processos organizacionais
e so cada vez mais compostos a partir da integrao de dezenas de servios eletrnicos heterogneos,
potencialmente distribudos em diversas organizaes e apoiados por uma complexa infra-estrutura de Tecnologia
de Informao (TI).
Neste contexto, a complexidade dos ambientes organizacionais e dos sistemas de informao justificou o
surgimento do termo Arquitetura Organizacional de TI ou, simplesmente, Arquitetura Organizacional (Enterprise
Architecture), ou ainda Arquitetura Corporativa, para denotar o conjunto coeso de princpios, mtodos e modelos
que so usados na definio e implementao de estruturas organizacionais, processos de negcio, sistemas de
informao e infra-estrutura tcnica de TI no contexto de uma organizao.
A importncia do conceito de Arquitetura Organizacional est refletida nos diversos frameworks para estruturao
de arquiteturas. Exemplos destes frameworks incluem o framework de arquitetura TOGAF (The Open Group
Architecture Framework), o framework de arquitetura do Departamento de Defesa Norte-Americano DoDAF
(Department of Defense Architectural Framework) , o modelo de refrencia RM-ODP da ISO (Reference Model for
Open Distributed Processing), e ainda a arquitetura ARIS (Architecture of Integrated Information Systems)
considerada um padro de fato em diversos segmentos produtivos.
A grande maioria destes frameworks considera uma organizao como um sistema cujos elementos incluem:

as estruturas organizacionais (como os atores, papis e unidades de uma organizao);


as atividades organizacionais estruturadas em servios e processos de negcio;
os servios eletrnicos e sistemas de informao que apiam as atividades organizacionais,
os modelos conceituais de informao
a infra-estrutura tcnica de suporte aos sistemas de informao.

Desta forma, uma Arquitetura Organizacional deve abranger elementos em domnios de discurso diversos que so
relevantes para diferentes interessados (stakeholders), devendo ainda relacionar estes elementos para formar
uma viso coesa da organizao e seus sistemas.
Um dos principais desafios enfrentados na aplicao do conceito de Arquitetura Organizacional encontrado na
captura e formalizao de uma descrio para que esta sirva como um veculo para documentao, visualizao,
anlise, manipulao e evoluo de uma organizao e seus sistemas.25
Assim como no caso das arquiteturas de software, os primeiros esforos para capturar arquiteturas
organizacionais foram baseados em conjuntos de diagramas informais. Diagramas informais envolvem o uso de
elementos grficos de forma intuitiva, porm imprecisa e desestruturada. Tcnicas para descrio de arquiteturas
organizacionais permitiram aumentar o rigor da atividade de captura de arquiteturas organizacionais com a
definio de linguagens para modelagem de arquiteturas organizacionais.
Um domnio particularmente maduro no escopo da modelagem de arquiteturas organizacionais o domnio de
modelagem de processos de negcio (Business Process Modelling). H diversas linguagens de modelagem de
processos de negcio de ampla relevncia como o subconjunto eEPC do ARIS Method, a linguagem AMBER
suportada pelas ferramentas da BizzDesign, e mais recentemente, o padro Business Process Modelling Notation
(BPMN) do Object Management Group (OMG).
A proliferao das metodologias levou ao aparecimento de diversas notaes e tcnicas de modelao, que
muitas vezes so partilhadas entre vrias delas. Os recentes esforos de unificao permitiram que algumas
dessas tcnicas se tenham destacado.
Apesar dos benefcios que se reconhecem na utilizao de metodologias (independentemente do paradigma
utilizado), elas no esto isentas de crticas e de aspectos menos positivos:

Complexidade nos conceitos, tcnicas e aplicao.


Desconhecimento global da metodologia e falta de competncias dos informticos para a sua execuo com qualidade.
Ferramentas que suportam a metodologia difceis de utilizar.
Constatao da ausncia de melhorias significativas no processo e produto final.
Concentrao na anlise da situao actual, menor importncia aos objectivos futuros.
Tempo que decorre at disponibilizao dos resultados finais.
Rigidez na aplicao dos mtodos e conceitos.

Independentemente da evoluo das linguagens para modelagem de arquiteturas organizacionais, a evoluo das
linguagens de modelagem de sistemas de software (das quais o exemplo mais proeminente a Unified Modeling
Language (UML)), resultou na ampla adoo de tcnicas de modelagem para a especificao de sistemas de
informao. Mais recentemente, a UML tem sido empregada tambm na descrio de arquiteturas
ALMEIDA, Joo Paulo A. Modelagem de Arquiteturas Organizacionais de TI Orientadas a Servios
56
25

TI para concursos

organizacionais, com desenvolvimentos do perfil da UML para o modelo de referncia RM-ODP (UML Profile for
RM-ODP), os perfis de UML para descries arquiteturais de acordo com o framework DoDAF e a combinao da
UML com a linguagem do ARIS Method.
A arquitetura de software de um sistema consiste dos componentes de software, suas propriedades externas e
seus relacionamentos com outros softwares. O termo tambm se refere documentao da arquitetura de
software do sistema. A documentao da arquitetura do software facilita a comunicao entre os stakeholders,
registra as decises iniciais acerca do projeto de alto nvel e permite o reuso do projeto dos componentes e
26
padres entre projetos.
A arquitetura de software organizada em vises, que descrevem a arquitetura na perspectiva de um conjunto de
pessoas interessadas, como:

Viso funcional/lgica
Viso de cdigo
Viso de desenvolvimento/estrutural
Viso de concorrncia/processo/thread
Viso fsica/evolutiva
Viso de ao do usurio/feedback

Vrias linguagens para descrio da arquitetura de software foram inventadas, mas nenhum consenso foi ainda
alcanado em relao a qual conjunto de smbolos ou sistema representao deve ser adotado. Alguns acreditam
que a UML ir estabelecer um padro para representao de arquitetura de software. Outros acreditam que os
desenvolvimentos efetivos de software devem contar com a compreenso nica das restries de cada problema,
e notaes to universais so condenadas a um final infeliz porque cada uma prov um notao diferenciada que
necessariamente torna a notao intil ou perigosa para alguns conjuntos de tarefas. Eles apontam a proliferao
de linguagens de programao e a sucesso de tentativas falhas para impor uma simples 'linguagem universal' na
programao, como uma prova da tendncia do software para a diversidade e no para padres.

5.1

UML
A UML (Unified Modeling Language) uma linguagem de modelagem no proprietria de terceira
gerao para especificao, construo, visualizao e documentao de artefatos de um sistema de
software.
A UML surgiu em 1997 na sequncia de um esforo de unificao de trs das principais linguagens de
modelao orientadas por objetos (OMT, Booch e OOSE). Em seguida, adquiriu o estatuto de norma no
mbito da OMG e da ISO, sendo adotado progressivamente em todo o mundo.
Promovida pelo Object Management Group (OMG), com contribuies e direitos de autoria das seguintes
empresas: Hewlett-Packard, IBM, ICON Computing, i-Logix, IntelliCorp, Electronic Data Services,
Microsoft, ObjecTime, Oracle, Platinum, Ptech, Rational, Reich, Softeam, Sterling, Taskon A/S e Unisys.
Basicamente, a UML permite que desenvolvedores visualizem os produtos de seu trabalho em
diagramas padronizados. Junto com uma notao grfica, a UML tambm especifica significados
(semntica).
Os objetivos da UML so: especificao, documentao, e estruturao para sub-visualizao e maior
visualizao lgica do desenvolvimento completo de um sistema de informao. A UML um modo de
padronizar as formas de modelagem.
O UML se compe de diversos diagramas, cada um para um tipo diferente de viso.
Diagramas Comportamentais
Diagrama de Caso de Uso - descreve a funcionalidade proposta para o novo sistema. Um desenho com
representao de um ator, humano ou entidade mquina, que interage (relao) com o sistema (casos de
uso) para executar um trabalho. Estes relacionamentos podem ser:
associaes entre atores e casos de uso. Define uma funcionalidade do sistema do ponto de vista do
usurio.
generalizaes entre os atores. Os casos de uso de um ator so tambm casos de uso do outro, que
tem seus prprios casos de uso.
generalizaes entre os casos de uso. O caso de uso B um caso de uso A (A uma generalizao
de B, ou B uma especializao de A). Um relacionamento entre um caso de uso genrico para um
mais especfico, que herda todas as caractersticas de seu pai.
extenses entre os casos de uso. Um relacionamento extend de um caso de uso B para um caso de
uso A indica que o caso de uso B pode ser acrescentado para descrever o comportamento de A (no
essencial). A extenso inserida em um ponto de extenso do caso de uso A.
incluses entre os casos de uso. Um relacionamento include de um caso de uso A para um caso de
uso B indica que B essencial para o comportamento de A. Pode ser dito tambm que B is_part_of A
ou que A depende de B.
Diagrama de transio de estados - representao do estado ou situao em que um objeto pode se
encontrar no decorrer da execuo de processos de um sistema.
Diagrama de atividade - mostra o fluxo de controle de uma atividade para outra.

http://pt.wikipedia.org/wiki/Arquitetura_de_software
57
26

TI para concursos

Diagramas Estruturais
Diagrama de classes - representao da estrutura e relaes das classes que servem de modelo para
objetos. Uma propriedade, atributo ou operao representada no diagrama de classes, que poder ser
vista e usada apenas pela classe na qual foi declarada, bem como pelas suas classes descendentes,
deve ser definida com visibilidade descrita por meio da palavra-chave protected.
Diagrama de objetos - mostra os objetos que foram instanciados das classes. Exibe um nico conjunto de
objetos relacionados uns com os outros em um determinado momento
Diagrama de componentes - utilizado para modelar os componentes do cdigo fonte do software.
Diagrama de instalao - descreve os componentes de hardware e software e sua interao com outros
elementos de suporte ao processamento.
Diagrama de pacotes - descreve grupos de classes, de outros elementos ou pedaos do sistema divididos
em agrupamentos lgicos mostrando as dependncias entre estes.
Diagrama de estrutura - descreve a colaborao interna de classes, interfaces ou componentes para
especificar uma funcionalidade.

Diagramas de Interao
Diagrama de sequncia - representa a sequncia de mensagens passadas entre objetos num programa
27
de computador. Utiliza-se tambm o termo cenrio associado com diagramas de seqncia.
Diagrama de Interatividade descreve o fluxo de atividades mostrando como elas trabalham em uma
sequncia de eventos.
Diagrama de colaborao ou comunicao - exibe uma interao, consistindo de um conjunto de objetos
e seus relacionamentos, incluindo as mensagens que podem ser trocadas entre eles.
Diagrama de tempo - apresenta o comportamento dos objetos e sua interao em uma escala de tempo,
focalizando as condies que mudam no decorrer desse perodo.

Tambm se utiliza de elementos para sua representao:


De estrutura:

Classe
Classe ativa
Interface
Componente
Colaborao
N (cubo) - objeto fsico em tempo de execuo que representa um recurso computacional, possuindo,
geralmente, pelo menos uma memria, bem como, uma capacidade de processo. Objetos em tempo de
execuo e componentes podem residir em n. Graficamente, um N representado pelo desenho de um
Cubo.

De comportamento:
Casos de uso
Iterao
Mquina de estados

De agrupamento:

Pacote
Modelo
Subsistema
Framework

De anotao:
Notas

De relacionamentos
Associao (bidirecional ou unidirecional)
Generalizao
Composio

5.2

Arquitetura Orientada a Servio (SOA)


Service-oriented architecture (SOA) um estilo de arquitetura de software cujo princpio fundamental
preconiza que as funcionalidades implementadas pelas aplicaes devem ser disponibilizadas na forma
de servios. Freqentemente estes servios so organizados atravs de um "barramento de servios"
(enterprise service bus, em ingls) que disponibiliza interfaces, ou contratos, acessveis atravs de web
services ou outra forma de comunicao entre aplicaes. A arquitetura SOA baseada nos princpios
da computao distribuda e utiliza o paradigma request/reply para estabelecer a comunicao entre os
sistemas clientes e os sistemas que implementam os servios.28
Alm da perspectiva estritamente tcnica, a arquitetura orientada a servios tambm se relaciona com
determinadas polticas e conjuntos de "boas prticas" que pretendem criar um processo para facilitar a
tarefa de encontrar, definir e gerenciar os servios disponibilizados.
A arquitetura orientada a servios tambm se insere em um processo de reorganizao dos
departamentos de tecnologia da informao das organizaes, permitindo um melhor relacionamento
entre as reas que do suporte tecnolgico empresa e as reas responsveis pelo negcio

http://www.macoratti.net/vb_uml2.htm
http://pt.wikipedia.org/wiki/Service-oriented_architecture
58
27
28

TI para concursos

propriamente dito, graas a maior agilidade na implementao de novos servios e reutilizao dos
ativos existentes.

5.2.1

Servio
Um servio, do ponto de vista da arquitetura SOA, uma funo de um sistema computacional que
disponibilizado para outro sistema. Um servio deve funcionar de forma independente do estado de
outros servios, exceto nos casos de servios compostos (composite services), e deve possuir uma
interface bem definida. Normalmente, a comunicao entre o sistema cliente e aquele que disponibiliza o
servio realizada atravs de web services.

5.2.2

Processos
A Arquitetura Orientada a Servios pode ser bem representada a partir do seguinte processo, chamado
de "find-bind-execute paradigm" o que significa aproximadamente paradigma de "procura-consolidaexecuta". Tal conceito anlogo a "Ciclo de Deming" aplicado aos servios, que define o ciclo que
envolve o planejamento, a execuo, o monitoramento e a tomada de ao pr-ativa para a melhoria da
qualidade.
Esquema adaptado do paradigma "find-bind-execute", tecnicamente falando, o processo preconiza que
os provedores de servios registrem informaes em um registro central, com suas caractersticas,
indicadores, e aspectos relevantes s tomadas de decises. O registro utilizado pelo cliente para
determinar as caractersticas dos servios necessrios, e se o mesmo estiver disponvel no registro
central, como por exemplo por um catlogo de servios, o cliente poder utiliz-lo, sendo este
oficializado atravs de um contrato que enderece este servio.

5.2.3

Definies de SOA
O termo "Service-Oriented Architecture" (SOA) ou Arquitetura Orientada a Servios expressa um
conceito no qual aplicativos ou rotinas so disponibilizadas como servios em uma rede de
computadores (Internet ou Intranets) de forma independente e se comunicando atravs de padres
abertos. A maior parte das implementaes de SOA se utilizam de Web services (SOAP , REST e
WSDL). Entretanto, uma implementao de SOA pode se utilizar de qualquer tecnologia padronizada
baseada em web.
O SOA coloca a prestao de servio como eixo de todo o negcio, dando destaque gesto de
servios e ao cliente.
Servio - uma funo independente, sem estado (stateless) que aceita uma ou mais requisies e
devolve uma ou mais respostas atravs de uma interface padronizada e bem definida. Servios
podem tambm realizar partes discretas de um processo tal como editar ou processar uma transao.
Servios no devem depender do estado de outras funes ou processos. A tecnologia utilizada para
prover o servio, tal como uma linguagem de programao, no pode fazer parte da definio do
servio.
Orquestrao - Processo de sequenciar servios e prover uma lgica adicional para processar dados.
No inclui uma representao de dados.
Stateless - No depende de nenhuma condio pr-existente. Os servios no devem depender de
condies de outros servios. Eles recebem todas as informaes necessrias para prover uma
resposta consistente. O objetivo de buscar a caracterstica de stateless dos servios possibilitar que
o consumidor do servio possa sequenci-lo, ou seja, orquestr-los em vrios fluxos (algumas vezes
chamados de pipelines) para executar a lgica de uma aplicao.
Provedor - O recurso que executa o servio em resposta a uma requisio de um consumidor.
Consumidor - quem consome ou pede o resultado de um servio fornecido por um provedor.
Descoberta - SOA se baseia na capacidade de identificar servios e suas caractersticas.
Conseqentemente, esta arquitetura depende de um diretrio que descreva quais os servios
disponveis dentro de um domnio.
Binding - A relao entre os servios do provedor e do consumidor deve ser idealmente dinmica; ela
estabelecida em tempo de execuo atravs de um mecanismo de binding.

5.2.4

Web Services
Web Service um componente de software identificado por uma URI Identificador de Recursos
Uniforme, uma cadeia de caracteres compacta usada para identificar ou denominar um recurso na
Internet que independe de implementao ou de plataforma e pode ser descrito, publicado e invocado
sobre uma rede por meio de mensagens padro XML. As mensagens XML so transportadas usando
protocolos padres da Internet. Com web service possvel realizar a integrao entre sistemas
desenvolvidos em diferentes linguagens e plataforma, e disponibilizar servios interativos na Web. uma
tecnologia de padro aberto e padronizada pelo W3C.

59

TI para concursos

A arquitetura do Web Service constituda por trs componentes bsicos:


o servidor de registro (broker server ou service registry)
o provedor de servios (service provider)
o solicitante de servios (service requestor). As interaes entre esses componentes so de
busca, publicao e interao de operaes.
Na operao de publicao o provedor publica a descrio do servio de tal forma que um solicitante
possa localiz-la. Na operao de busca o solicitante obtm a descrio do servio diretamente ou
consulta o servidor de registro procurando pelo tipo de servio desejado. Essa operao pode ser
executada em duas fases distintas: desenvolvimento ou execuo. Na operao de interao o
solicitante chama ou inicia uma interao com o provedor, em tempo de execuo, utilizando os detalhes
contidos na descrio do servio para localizar, contactar e chamar o servio.
O provedor de servios representa a plataforma que hospeda o web service permitindo que os clientes
acessem o servio. O provedor de servios fornece o servio e responsvel por publicar a descrio do
servio que prov. O solicitante de servios a aplicao que est procurando, invocando uma interao
com o web service, ou seja, requisita a execuo de um servio. O solicitante de servio pode ser uma
pessoa acessando por meio do browser ou uma aplicao realizando uma invocao aos mtodos
descritos na interface do web service. O servidor de registro um repositrio central que contm a
descrio (informao) de um web service, e por meio do servidor de registro que essas descries
so publicadas e disponibilizadas para localizao.

Ilustrao 10 Componentes bsicos da arquitetura do Web Service

Os clientes buscam por servios no servidor de registro e recuperam informaes referentes interface
de comunicao para os web service durante a fase de desenvolvimento ou durante a execuo do
cliente, denominadas interao esttica (static bind) e interao dinmica (dinamic bind),
respectivamente. Na interao esttica, o cliente recupera a assinatura do servio, necessria
codificao. Na interao dinmica, o cliente recupera os valores de parmetros e a localizao do
servio.
O ciclo de vida de um web service compreende quatro estados distintos:
Publicao processo, opcional, por meio do qual o fornecedor do web services d a conhecer a
existncia do seu servio, efetuando o registro do mesmo no repositrio do web service;
Descoberta processo, opcional, por meio do qual uma aplicao cliente toma conhecimento da
existncia do web services pretendido pesquisando num repositrio UDDI;
Descrio processo pelo qual o web service expe a sua API (documento WSDL). Desta maneira a
aplicao cliente tem acesso a toda a interface do web service, onde encontram descritas todas as
funcionalidades por ele disponibilizadas;
Invocao (Mensagens) processo pelo qual o cliente e o servidor interagem, por meio do envio de
mensagens;
O fornecedor constri o servio:
Utilizando a linguagem de programao que entender;
Em seguida, especifica a interface/assinatura do servio que definiu em WSDL;
Aps a concluso dos dois primeiros passos, o fornecedor registra o servio no UDDI;
O utilizador (aplicao cliente) pesquisa num repositrio UDDI e encontra o servio;
A aplicao cliente estabelece a ligao com o web service e estabelece um dilogo com este, via
mensagens SOAP.

60

TI para concursos

Ilustrao 11 Ciclo de vida do web service

A interao entre os web services se d sob vrios protocolos abertos, em diferentes nveis de
abstrao. Os protocolos utilizados para realizar a comunicao so o: UDDI (Universal Description
Discovery and Integration), WSDL (Web Services Description Language), XML, SOAP (Simple Object
Access Protocol) e o HTTP.

Ilustrao 12 Protocolos de comunicao de Web services

As mensagens trocadas so formatadas no protocolo SOAP, o que permite a interoperabilidade entre


diferentes plataformas, em um processo denominado serializao XML. Porm, antes que as mensagens
SOAP sejam trocadas, suas caractersticas so explicitadas por meio de documentos WSDL, que
descrevem quais dados estaro sendo trocados, e como estes dados estaro organizados nas
mensagens SOAP. Adicionalmente, os servios dos web services podem ser publicados atravs de
UDDI, que um formato utilizado para seu armazenamento em repositrios disponveis na Internet.
Assim, se um desenvolvedor precisar resolver uma determinada tarefa, pode encontrar o web service
que mais se adequar sua necessidade.
Como os firewalls convencionais e proxies no bloqueiam a porta utilizada pelo protocolo HTTP, no
existem grandes restries para o uso deste tipo de aplicao em redes de longa distncia.
Um servio pode ser chamado de forma sncrona, o que significa que quem chamou a funo deve
esperar o retorno antes de prosseguir. Esta a maneira mais comum de chamar qualquer funo. Em
uma chamada assncrona, no esperamos que a funo chamada retorne antes de continuar, mantendo
mais de uma "linha de execuo" no cdigo. Esta maneira no muito usada, pois mais complexa e,
na maioria dos casos, ou a funo retorna rapidamente ou, mesmo que demore, no temos o que fazer
antes da funo retornar. No entanto, em uma chamada a WebService, comum que a sua chamada
demore um pouco e tambm tenhamos o que fazer antes de um WebService voltar, por exemplo,
chamar outro WebService.
Pode-se definir, resumidamente, o web service como sendo um servio de software disponibilizado na
Internet, descrito com um arquivo WSDL, registrado via UDDI, acessado utilizando SOAP e com dados
representados em XML sendo transmitidos via HTTP.
A disseminao no uso de web services incentivou o mercado a oferecer uma grande variedade de
ferramentas e aplicaes para prover suporte a essa tecnologia. Atualmente, as principais plataformas
para web services so: Sun Microsystems, IBM, BEA, Apache, Systinet e Microsoft.

5.2.5

SOAP
Simple Object Access Protocol um protocolo leve para troca de informaes em
um ambiente descentralizado e distribudo que permite comunicao entre
aplicaes de forma simples e completamente independente de sistema
operacional, linguagem de programao ou plataforma. o protocolo de
comunicao para os Web Services.
A comunicao realizada por meio de trocas de mensagens, transmitidas em
formato XML, incluindo os parmetros usados nas chamadas, bem como os
dados de resultados. Tambm pode ser utilizado para invocar, publicar e localizar
Ilustrao 13 Estrutura
web services no registro UDDI.
SOAP
Parte da sua especificao composta por um conjunto de regras de como
utilizar o XML para representar os dados. Outra parte define o formato de mensagens, convenes para

61

TI para concursos

representar as chamadas de procedimento remoto (RPC Remote Procedure Calls) utilizando o SOAP,
e associaes ao protocolo HTTP. O protocolo HTTP o nico protocolo padronizado pelo SOAP, mas
existem algumas implementaes que suportam outros protocolos como SMTP, TCP/IP, FTP e etc.
Uma mensagem SOAP um fragmento XML bem formado, encapsulado por um par de elementos
SOAP. A mensagem SOAP consiste dos seguintes elementos:
Envelope toda mensagem SOAP deve cont-lo. o elemento raiz do do cumento XML. Define o incio
e o fim das mensagens;
Header um cabealho opcional. Ele carrega informaes adicionais, como exemplo, se a
mensagem deve ser processada por um n intermedirio. Quando utilizado, o Header deve ser o
primeiro elemento do envelope;
Body obrigatrio e contm o payload, os dados em XML a serem transportados. O elemento Body
possui um campo opcional Fault, usado para carregar mensagens de status e erros retornadas pelos
nsao pro cessarem a mensagem;
RPCs ou chamadas remotas de procedimento so chamadas locais a mtodos de objetos (ou servios)
remotos. Portanto, pode-se acessar os servios de um objeto localizado em outro ponto da rede, atravs
de uma chamada local a este objeto. Cada chamada ou requisio exige uma resposta.
O processo de uma chamada RPC: Antes de serem enviadas pela rede, as chamadas de RPC (emitidas
pela aplicao cliente) so encapsuladas (ou serializadas) segundo o padro SOAP. O servio remoto,
ao receber a mensagem faz o processo contrrio, desencapsulando-a e extraindo as chamadas de
mtodo. A aplicao servidora ento processa esta chamada, e envia uma resposta ao cliente. O
processo ento se repete: a resposta tambm serializada e enviada pela rede. Na mquina cliente,
esta resposta desencapsulada e repassada para a aplicao cliente.
A especificao SOAP define as seguintes informaes, como necessrias em toda chamada de RPC:
A URI do objeto alvo;
O nome do mtodo;
Os parmetros do mtodo (requisio ou resposta);
Uma assinatura do mtodo opcional;
Um cabealho (header) opcional.

5.2.6

WSDL
O WSDL (Web Services Description Language) uma linguagem baseada em XML, utilizada para
descrever um web service. Um web service deve definir todas as suas interfaces, operaes, esquemas
de codificao, o contedo das mensagens, onde o servio est disponvel e quais os protocolos de
comunicao so usados para conversar com o servio e entre outros neste documento. Um documento
WSDL define um XML Schema para descrever um web service.
A descrio de um servio consiste de duas partes: definio de implementao do servio e definio
da interface do servio. A separao entre as duas camadas permite que elas sejam utilizadas
separadamente.

Ilustrao 14 Descrio WSDL

A parte de definio de interface do servio descreve o web service, incluindo mtodos que so
invocados e parmetros que so enviados. A parte de definio de implementao de servios descreve
como uma interface de servio im-plementada por um provedor: onde o servio est instalado e como
pode ser acessado. As descries dos elementos das duas partes:
Binding descreve protocolos, formato de data, segurana e outros atributos para uma interface
(portType) em particular;
Porttype informa elementos de operaes do web service;
Message define entrada e sada de dados referentes a operaes;
Type define tipos de dados complexos em uma mensagem;
Service contm uma coleo de elementos port com elementos binding;
62

TI para concursos

Port a combinao de um binding com endereo de rede, fornecendo o endereo alvo para a
comunicao dos servios.
To logo o cliente tenha acesso descrio do servio a ser utilizado, a implementao do Web Service
pode ser feita em qualquer linguagem de programao. Normalmente so utilizadas linguagem
construdas para interao com a Web, como exemplo Java Servlets ou ASP, que, em seguida, chamam
um outro programa ou objeto.
Basicamente, quando o cliente deseja enviar uma mensagem para um determinado web service, ele
obtm a descrio do servio (atravs da localizao do respectivo documento WSDL), e em seguida
constri a mensagem, passando os tipos de dados corretos (parmetros, etc) de acordo com a definio
encontrada no documento. As duas partes envolvidas em uma interao web service precisam ter
acesso mesma descrio WSDL para conseguirem entender uma outra. Em seguida, a mensagem
enviada para o endereo onde o servio est localizado, a fim de que possa ser processada. O web
service, quando recebe esta mensagem valida-a conforme as informaes contidas no documento
WSDL. A partir de ento, o servio remoto sabe como tratar a mensagem, sabe como process-la
(possivelmente enviando-a para outro programa) e como montar a resposta ao cliente.

5.2.7

UDDI
Para que um servio seja utilizado necessrio que o cliente consiga localiz-lo, e essa localizao
pode ser feita por meio do UDDI (Universal Description, Discovery and Integration), que uma
especificao tcnica para descrever, descobrir e publicar web services.
Uma implementao de UDDI corresponde a um registro web service, que prov um mecanismo para
busca e publicao de web services. Um registro UDDI contm informaes categorizadas sobre os
servios e as funcionalidades que eles oferecem, e permite a associao desses servios com suas
informaes tcnicas, geralmente definidas usando WSDL.
O UDDI possui um componente central chamado UDDI Project, que ma-nipula um registro global e
pblico chamado business registry. A informao oferecida pelo bussines registry consiste de trs
componentes: white pages, yel-low pages e green pages.
A informao fornecida por um registro UDDI pode ser comparada uma lista telefnica. As pginas
brancas (white pages), fornecem informaes tais como nome da organizao, contato e identificadores.
As pginas amarelas (yellow pages) so compostas por um ndice de servios e produtos e as pginas
verdes (green pages) contm informaes a respeito de transaes, descries de servio e invocao
de aplicaes.
As informaes contidas em arquivos de descrio de servio (WSDL) completam aquelas que esto no
registro. No entanto, UDDI no fornece suporte a vrios tipos de descrio de servio, mas no suporta a
criao de descries WSDL de forma direta.
Uma descrio WSDL completa consiste da combinao dos documentos de interface e de
implementao de servio. A primeira publicada no registro UDDI como businessservice e a segunda
como tmodel.

5.2.8

Segurana
A segurana no envio de mensagens SOAP um tpico importante. Em um nvel mais baixo,
mensagens SOAP podem ser trocadas pela rede utilizando HTTPS ao invs de HTTP. Como HTTPS
utiliza SSL no seu transporte, fica garantida a proteo contra possveis intervenes. Alm disso, o
cliente e servidor podem verificar cada um suas respectivas identidades.
Embora HTTPS resolva o problema de proteo das mensagens contra possveis invasores, este no
ajuda muito quando se necessita da segurana necessria para a autenticao de usurios de web
services especficos. Estes servios iro fornecer algum tipo de combinao de usurio/senha durante a
fase inicial de registro no servio e ento esta ser utilizada para acessos futuros. No h ainda um
padro de autenticao para Web services, mas pode utilizar os firewalls, VPNs, NTFS, produtos de
single-in para oferecer a autenticao e autorizao de usurios.

63

TI para concursos

5.3

Exerccios
99.

(ICMS-SP 2009) Uma vantagem que o Web Service oferece


I. em relao empresa que desenvolve uma DLL que no precisa distribu-lo para todos os clientes, pois
estar armazenado em um nico lugar de onde ser acessado.
II. o acesso a ele, sempre por meio de http, mas internamente existe uma string XML que est empacotada
em um protocolo SOAP (Simple Object Access Protocol).
III. ser transparente para o Firewall de uma empresa, pois, como uma string XML, interpretado como
um arquivo "texto", no precisando pedir autorizao do Firewall para entrar.
Est correto o que consta em 99
(a) I, II e III.xx
(b) I e II, apenas.
(c) I e III, apenas.
(d) II e III, apenas.
(e) II, apenas.
100

100. (ICMS-SP 2009) Para uma Web Service sncrona, quem chamou a funo
(a) deve esperar o retorno para prosseguir e, para uma Web Service assncrona, no precisa esperar o
retorno, podendo manter mais uma linha de execuo no cdigo. xx
(b) deve esperar o retorno para prosseguir e, para uma Web Service assncrona, no precisa esperar o
retorno, no podendo manter mais uma linha de execuo no cdigo.
(c) no precisa esperar o retorno, podendo manter mais uma linha de execuo no cdigo e, para uma Web
Service assncrona, deve esperar o retorno para prosseguir.
(d) no precisa esperar o retorno, no podendo manter mais uma linha de execuo no cdigo e, para uma
Web Service assncrona, deve esperar o retorno para prosseguir.
(e) no precisa esperar o retorno, tal qual para uma Web Service assncrona, porm, para a forma sncrona
pode manter mais uma linha de execuo no cdigo e para a forma assncrona no pode.
101. (FCC TRT 2012) Segundo o Web Services for Remote Portlets Specification v2.0 (WSRP), em um fluxo tpico
de interao entre os atores, a fase que deve ocorrer primeiro, na ordem cronolgica, aquela em que 101
(a) se estabelece uma relao entre o consumidor e o usurio final.
(b) o consumidor aprende as capacidades totais e servios do produtor.
(c) se estabelece a relao entre o consumidor e o produtor. xx
(d) pginas agregadas so produzidas pelo produtor.
(e) uma pgina requisitada pelo consumidor.
102. (ICMS-SP 2009) A Service-Oriented Architecture SOA trata-se de
I. um conjunto de produtos para implementar aplicativos dinmicos e geis, do tipo loosely couple.
II. uma meta a ser alcanada, ou seja, disponibilizar uma metodologia de implementao que usa padres e
protocolos de linguagem especficos para execuo de aplicativos.
III. solues que no requerem uma renovao completa de tecnologia e de processo de negcios, que devem
ser incrementais e baseadas nos investimentos atuais.
IV. uma abordagem de design de sistemas que orientam como os recursos do TI sero integrados e quais
servios sero expostos para o uso.
Est correto o que consta APENAS em 102
(a) I e II.
(b) I e IV.
(c) III e IV.xx
(d) II e III.
(e) II e IV.
103. (ICMS-SP 2009) O Service-Oriented Architecture SOA tem foco tanto nos negcios quanto em tecnologia da
103
informao, sendo que o SOA com foco em negcios normalmente inclui
(a) pessoas, processo e conectividade.
(b) pessoas, processos e informaes.xx
(c) reusabilidade, pessoas e processos.
(d) conectividade, processos e informaes.
(e) conectividade, reusabilidade e informaes.
104. (ICMS-SP 2009) As ferramentas de modelagem de anlise, que utilizam a notao UML, fornecem
104
capacidade de desenvolver modelos baseados em
(a) cenrios, fluxos e dados.
(b) cenrios, classes e dados.
xx
(c) cenrios, classes e objetos.
(d) classes, fluxos e objetos.
(e) classes, fluxos e dados.
105. (TRF 2007) No mbito dos Web Services, as chamadas de RPC - emitidas pela aplicao cliente so105
(a) convertidas na linguagem Unique Resource Identifier, quando da entrega ao protocolo IP.
(b) espacializadas pela Cascade Style Sheet, to logo recebidas pelo Server.
(c) encapsuladas segundo o padro SOAP, antes de serem enviadas pela rede. xx
(d) convertidas para o padro WSDL, no retorno do Server.
(e) adaptadas eXtended Style Language, quando formatadas pela DTD/DOM.

64

TI para concursos

106. Considere as seguintes assertivas sobre uma arquitetura orientada a servios (SOA):
I. SOA apenas uma implementao de Servios Web, possuindo ambas as mesmas caractersticas.
II. As mensagens so o principal meio de comunicao entre os provedores e os consumidores de servios.
III. SOA no prescreve como projetar ou construir a implementao do servio.
IV. Quando os servios so disponibilizados na web, eles so identificados por uma URI.
106
As assertivas corretas so:
(a) somente I, II e III.
(b) somente II, III e IV.xx
(c) somente I, III e IV.
(d) somente I, II e IV.
(e) todas.
107. (FCC AP ACE 2012) Considere o seguinte diagrama UML:

O nmero 1 e smbolo 1..* que aparecem ao lado das classes Nota Fiscal e Itens se referem restrio de 107
(a) herana.
(b) agregao.
(c) identidade.
(d) Multiplicidade.xx
(e) polimorfismo.
108. (FCC TRT SP/2008 - Analista) Na UML, a multiplicidade 108
(a) aplicada aos atributos, somente.
xx
(b) aplicada a uma classe o nmero de instncias que esta pode ter.
(c) indica a quantidade de atributos herdados por uma classe-filha em uma hierarquia de classes.
(d) aplicada nas associaes entre classes indica o nmero de atributos comuns s classes envolvidas.
(e) aplicada a uma classe concreta o nmero de operaes que esta pode ter.
109. Dos diagramas definidos na UML 2.0, aplicado na modelagem do comportamento de uma interface, classe
ou colaborao, o Diagrama de 109
(a) Componente.
(b) Objeto.
(c) Estrutura Composta.
(d) Pacote.
(e) Estado de Mquina.xx
110. (FCC TRT 2012) Considere o seguinte diagrama em UML:

Uma representao vlida deste diagrama obtida substituindo-se as classes representadas pelas letras A, B,
C, D e E, respectivamente, por110
(a) Desenho, Cor, Tipo, Azul, Retngulo.
(b) Computador, Notebook, Desktop, Impressora, Monitor.
xx
(c) Pedido, Compra, Venda, Item, Cliente.
(d) Livro, ndice, Capa, Romance, Aventura.
(e) Internet, Navegadores, Correio Eletrnico, Firefox, Outlook.
111. Em
(a)
(b)
(c)
(d)
(e)

65

um diagrama de Caso de Uso so admitidos os relacionamentos


dependncia, somente.
dependncia e generalizao, somente.
dependncia, generalizao e associao.xx
associao, somente.
dependncia e associao, somente.

111

TI para concursos

112. Em
(a)
(b)
(c)
(d)
(e)

um Caso de Uso, um relacionamento de incluso a estereotipao


dos Casos de Uso aos quais se relaciona.
de uma Generalizao.
de uma Extenso.
de uma Agregao.
xx
de um relacionamento de dependncia.

112

113. No diagrama de casos de uso da UML, o relacionamento de generalizao acontece entre 113
(a) atores, somente.
(b) casos de uso, somente.
xx
(c) casos de uso e entre atores.
(d) casos de uso e atores, somente.
(e) casos de uso includos e estendidos, somente.
114

114. Um diagrama de objetos


(a) tem a mesma funo que um diagrama de atividades diferenciando deste apenas na representao
grfica.
(b) capta um conjunto de abstraes como um grupo de interesse e em tal contexto expe sua semntica e
seus relacionamentos com outras abstraes existentes nesse grupo da mesma forma que em um
diagrama de classes
(c) exibe um nico conjunto de objetos relacionados uns com os outros em um determinado momento. xx
(d) mostra a seqncia de execuo de atividades entre objetos relacionados, no tempo, e a durao de
cada objeto por meio de linhas de vida.
(e) exibe diversos conjuntos de objetos relacionados uns com os outros em um determinado momento.
115. Uma propriedade, atributo ou operao representada no diagrama de classes da UML, que poder ser vista e
usada apenas pela classe na qual foi declarada, bem como pelas suas classes descendentes, deve ser
definida com visibilidade descrita por meio da palavra-chave 115
(a) package.
(b) public.
(c) private.
(d) protected.xx
(e) local.
116. A representao grfica de um diagrama de seqncias da UML baseada em
I. uma dimenso horizontal que representa as mensagens trocadas no decorrer de um tempo de vida.
II. uma dimenso vertical que representa os objetos participantes das interaes.
III. mensagens que correspondem a chamadas de servios ou de operaes dos objetos.
IV. objetos representados por retngulos alinhados no topo do diagrama, dos quais partem as linhas de vida
destes objetos.
Est correto o que consta em 116
(a) I, II, III e IV.
(b) I, II e IV, apenas.
(c) I, II e III, apenas.
xx
(d) III e IV, apenas.
(e) I e II, apenas.
117. Um cubo, graficamente na UML, um elemento fsico existente em tempo de execuo que representa um
recurso computacional com pelo menos alguma memria, e, freqentemente, com capacidade de
117
processamento. Trata-se de
(a) pacote.
(b) n.xx
(c) interface.
(d) objeto.
(e) nota.
118. Na UML um n um elemento fsico que existe em tempo de execuo e representa um recurso
118
computacional. Graficamente, ele representado por
(a) um losango.
(b) um cubo.xx
(c) um quadrado.
(d) uma seta vasada (tringulo).
(e) uma elipse.

66

TI para concursos
119

119. (TRT FCC 2012) Sobre o diagrama de classe da UML correto afirmar:
(a) Quando se utiliza diagramas de classe deve-se focar exclusivamente na estrutura do software e ignorar
seu comportamento.
(b) Dependncia com classes no so adequadas para ilustrar um relacionamento transitrio, como quando
um objeto passado para outro como parmetro.
(c) A UML permite representar dependncia apenas de classes. Utilizam-se dependncias quando se deseja
mostrar que as mudanas em uma classe no afetam a outra classe.
(d) Suporta quatro abreviaes de visibilidade: + (pblico), (privado), (pacote) e # (protegido).xx
(e) Uma classe abstrata uma classe que pode ser instanciada diretamente. A maneira mais comum de
identificar uma classe abstrata na UML colocar o nome em negrito.
120. A identificao do documento XML, como uma mensagem SOAP, est contida no elemento da estrutura SOAP
120
denominado
(a) root.
(b) body.
xx
(c) envelope.
(d) fault.
(e) header.
121. NO uma informao requerida para invocar um servio de Web e encapsulada pelo WSDL na forma de um
121
documento XML:
(a) O local do servio.
(b) As operaes que o servio apoia.
(c) Os parmetros que o servio espera.
(d) Os detalhes das mensagens do servio.
(e) Os meios para publicar e localizar o servio. xx

67

TI para concursos

Gerncia de Requisitos de Software


A engenharia de requisitos29 um processo que engloba todas as atividades que contribuem para a
produo de um documento de requisitos e sua manuteno ao longo do tempo.
O processo de engenharia de requisitos composto por quatro atividades de alto nvel:
Identificao.
Anlise e negociao.
Especificao e documentao.
Validao.
A gesto dos requisitos faz parte deste processo, se incluirmos a fase de manuteno, sendo que as
alteraes podem ser causadas pelos mais diversos fatores desde inovaes tecnolgicas a mudanas
na natureza do negcio.
O gerenciamento de requisitos um modelo sistemtico para encontrar, documentar, organizar e
rastrear os requisitos variveis de um sistema.30
A implementao de boas prticas de gerncia de requisitos de software constitui uma das prioridades
na implantao de melhoria do processo de software.
O principal risco, que atinge 80% dos projetos de software, o da Evoluo de Requisitos. Os
indicadores de desempenho so formas de representao quantificveis de caractersticas de produtos e
processos, sendo utilizados para acompanhar e melhorar os resultados ao longo do tempo.

6.1

Conceitos de Requisitos
Um requisito definido como "uma condio ou uma capacidade com a qual o sistema deve estar de
acordo".31
Os requisitos expressam as caractersticas e restries do produto de software do ponto de vista de
satisfao das necessidades do usurio. Em geral, independem da tecnologia empregada na construo
da soluo, sendo uma das partes mais crticas e propensas a erros no desenvolvimento de software
Os requisitos do utilizador destinam-se aos vrios nveis hierrquicos da organizao e so descritos
usando apenas linguagem natural, formulrios e diagramas muito simples. Neste nvel de especificao,
surgem algumas dificuldades:
Ambiguidade: torna-se difcil descrever os requisitos de uma forma inequvoca sem tornar a sua
descrio muito longa ou de difcil compreenso.
Confuso: ainda que possa no ser to relevante do ponto de vista do cliente, a distino entre
requisitos funcionais/no-funcionais e objetivos do sistema torna-se difcil.
Agrupamento de requisitos: ao descrever as funcionalidades de um sistema, pode ser difcil
separar claramente os requisitos, o que leva a que vrios requisitos sejam expressos como sendo
apenas um.
Algumas consideraes:
Usar o mesmo formato em todos os requisitos para evitar omisses e facilitar a verificao dos
requisitos.
Distinguir claramente, atravs do uso de expresses, entre comportamentos esperados "O sistema
permitir criar (...)" ou desejveis "Dever ser possvel criar (...)". importante deixar claro o que o
sistema tem de fazer e sugestes de como o deve fazer e, acima de tudo, usar este tipo de
expresses de forma consistente ao longo de todo o documento.
Usar formatao de texto para salientar determinados aspectos do documento (negrito,
sublinhado, itlico).
Evitar usar termos demasiado tcnicos ou fora do mbito do sistema, identificando e definindo de
uma forma clara quando for absolutamente necessrio us-los.
Os requisitos do sistema tm um carcter mais tcnico, consistindo numa descrio detalhada dos
requisitos do utilizador recorrendo ao uso de linguagens estruturadas e notaes grficas. Estes
requisitos destinam-se aos utilizadores do sistema, s equipes de especificao de arquitetura do
sistema e de desenvolvimento.
O uso de linguagem natural levanta problemas:
As mesmas palavras podem, de acordo com a interpretao de cada pessoa, designar conceitos
diferentes.

http://pt.wikipedia.org/wiki/Requisitos_de_Software
http://www.wthreex.com/rup/process/workflow/requirem/co_rm.htm
31 http://www.wthreex.com/rup/portugues/process/workflow/requirem/co_req.htm
68
29
30

TI para concursos

O mesmo requisito pode ser descrito de formas diferentes, o que leva a que cada pessoa tenha de
saber quando que descries diferentes se referem ou no a requisitos diferentes.

6.1.1

Levantamento de requisitos
Sommerville (2003) prope um processo genrico de levantamento e anlise que contm as seguintes
32
atividades:
Compreenso do domnio: Os analistas devem desenvolver sua compreenso do domnio da
aplicao;
Coleta de requisitos: o processo de interagir com os stakeholders do sistema para descobrir seus
requisitos. A compreenso do domnio se desenvolve mais durante essa atividade;
Elicitao o nome dado qualquer tcnica de obteno de dados junto aos usurios
detententores das informaes, principalmente para a construo de um sistema ou um produto
ou, ainda para melhorar um processo de trabalho. Algumas tcnicas so:

Entrevistas
Documentos do sistema existente
Anlise do domnio do problema
Estudos do mercado

Classificao: Essa atividade considera o conjunto no estruturado dos requisitos e os organiza em


grupos coerentes;
Resoluo de conflitos: Quando mltiplos stakeholders esto envolvidos, os requisitos apresentaro
conflitos. Essa atividade tem por objetivo solucionar esses conflitos;
Definio das prioridades: Em qualquer conjunto de requisitos, alguns sero mais importantes do que
outros. Esse estgio envolve interao com os stakeholders para a definio dos requisitos mais
importantes;
Verificao de requisitos: Os requisitos so verificados para descobrir se esto completos e
consistentes e se esto em concordncia com o que os stakeholders desejam do sistema.
O levantamento e anlise de requisitos um processo iterativo, com uma contnua validao de uma
atividade para outra.

Ilustrao 15 Processo de levantamento e anlise de requisitos

6.1.1.1

Joint Application Development (JAD)33


Tcnica para levantamento de requisitos desenvolvido pela IBM nos anos 70, que organiza reunies que
discutem o processo de levantamento de requisitos no gerenciamento do projeto.
Os princpios bsicos:
Ningum melhor para explicar um determinado processo do que as pessoas que trabalham com
ele.
Os profissionais de TI so os mais preparados para identificar as possibilidades que a tecnologia
oferece, assim como suas limitaes.
Sistemas de informao e processos do negcio no so isolados.
Os melhores sistemas de informao so resultado do trabalho conjunto de todas as pessoas
envolvidas: profissionais de TI, usurios, gestores, analistas de negcio etc.

http://www.devmedia.com.br/artigo-engenharia-de-software-2-tecnicas-para-levantamento-de-requisitos/9151
http://www.cos.ufrj.br/~targino/engsoft/JAD.pdf
69
32
33

TI para concursos

O JAD orienta a conduo das sesses a partir de alguns papis.


O facilitador neutro: ele no opina nos assuntos discutidos, mas pode direcionar os assuntos
conforme o planejamento inicial. Cabe a ele tambm evitar que determinados indivduos dominem
reunio.
O anotador est dedicado a registrar os assuntos discutidos e decises tomadas, liberando assim os
outros membros a participar das discusses sem perder tempo com anotaes.
O gerenciador de tempo vai evitar que determinadas discusses demorem demasiadamente,
evitando assim que outros assuntos no sejam abordados.
O quadro do projeto serve para lembrar os assuntos em foco e os que esto fora do foco, impedindo
assim discusses infrutferas.
34

6.1.1.2

Estudo etnogrfico
Estudo etnogrfico uma tcnica, proveniente das disciplinas de Antropologia Social, que consiste no
estudo de um objeto por vivncia direta da realidade onde este se insere, permitindo analisar a
componente social das tarefas desempenhadas numa dada organizao tornam-se, no mbito da
Engenharia de Requisitos, extremamente uteis para ultrapassar a dificuldade que existe na coleta dos
requisitos derivados de formas rotineiras e tcitas de trabalhar:
modo como realmente as pessoas executam as suas funes que muitas vezes difere da forma
como as definies dos processos sugerem que elas devem fazer;
cooperao e conhecimento das atividades de outras pessoas.
Para isso, um socilogo, externo organizao em causa, passa algum tempo observando e analisando
as atividades das pessoas sem que estas necessitem explicar o seu trabalho (interaes implcitas),
extraindo da concluses importantes acerca de fatores sociais e organizacionais. Desta forma,
necessrio assumir que as pessoas em estudo so competentes na realizao do seu trabalho.
Estes estudos tm mostrado que o trabalho das pessoas , normalmente, mais rico e complexo do que o
descrito pelas definies dos processos e pelos modelos dos sistemas.
O principal problema da aplicao deste mtodo fruto da dificuldade na generalizao dos resultados.
um mtodo qualitativo que se insere na corrente filosfica do Interpretivismo.

6.2

Requisitos Funcionais e No-Funcionais


Os requisitos funcionais especificam aes que um sistema deve ser capaz de executar, sem levar em
considerao restries fsicas. Geralmente, isso melhor descrito em um modelo de casos de uso. Os
requisitos funcionais especificam o comportamento de entrada e sada de um sistema. aquilo que o
utilizador espera que o sistema oferea, atendendo aos propsitos para qual o sistema ser
desenvolvido.
conjuntos de recursos
habilidades
segurana
Requisitos no-funcionais so restries nas quais o sistema deve operar ou propriedades emergentes
do sistema. Vrios requisitos no so funcionais e descrevem apenas atributos ou ambiente do sistema.
Alguns deles podem ser capturados em casos de uso, outros em Especificaes Suplementares.
Usabilidade

fatores humanos
esttica
consistncia na interface do usurio
ajuda online e contextual
assistentes e agentes
documentao do usurio
materiais de treinamento

Confiabilidade

freqncia e gravidade de falha


possibilidade de recuperao
possibilidade de previso
exatido
tempo mdio entre falhas (MTBF)

Desempenho

velocidade
eficincia
disponibilidade
exatido
taxa de transferncia

http://pt.wikipedia.org/wiki/Estudo_etnogr%C3%A1fico
70
34

TI para concursos

tempo de resposta
tempo de recuperao
uso de recurso

Suportabilidade

possibilidade de teste
extensibilidade
adaptabilidade
manutenibilidade
compatibilidade
possibilidade de configurao
possibilidade de servio
possibilidade de instalao
possibilidade de localizao (internacionalizao)

Restries de design
especifica ou restringe o design de um sistema

Requisitos de implementao

padres obrigatrios
linguagens de implementao
polticas de integridade de banco de dados
limites de recursos
ambientes operacionais

Requisitos de interface
um item externo com o qual o sistema deve interagir
restries de formatos, tempos ou outros fatores usados por tal interao

Requisitos fsicos

6.3

material
forma
tamanho
peso

Exerccios
122. (ICMS-SP 2009) Quanto aos requisitos de software, considere:
I. importante que se estabeleam prticas para encontrar, documentar, organizar e rastrear os requisitos
variveis de um sistema.
II. Etnografia (observao e anlise dos fluxos de trabalho) e sesses de JAD so prticas que podem ser
aplicadas na elicitao.
III. Elicitar significa descobrir os requisitos de um sistema por meio de entrevistas, de documentos do sistema
existente, de anlise do domnio do problema ou de estudos do mercado.
Est correto o que se afirma em 122
(a) I, apenas.
(b) I e II, apenas.
(c) I, II e III.xx
(d) II e III, apenas.
(e) III, apenas.
123. (ICMS-SP 2009) Considere:
"Os requisitos expressam as caractersticas e restries do produto de software do ponto de vista de satisfao
das necessidades do usurio. Em geral, independem da tecnologia empregada na construo da soluo,
sendo uma das partes mais crticas e propensas a erros no desenvolvimento de software.
123
Quanto aos requisitos de software, a descrio acima est
(a) incoerente ao afirmar que expressam restries.
(b) incoerente ao afirmar que independem da tecnologia.
(c) incoerente ao afirmar que expressam caractersticas do ponto de vista de satisfao das necessidades do
usurio.
(d) totalmente coerente.xx
(e) incoerente ao afirmar que os requisitos so uma das partes mais crticas e propensas a erros.
124. (FCC 2008 - TRT) A frase "o tempo mdio de resposta do sistema no deve ultrapassar 5 segundos" indica
(a) uma funcionalidade do sistema.
(b) uma atividade do cronograma do sistema.
(c) uma funo executada pelo usurio do sistema.
(d) uma possvel definio de requisito no funcional.xx
(e) um ponto de controle nas etapas de desenvolvimento do sistema.

124

125. (FCC - 2008 TCE AL) Em um sistema cujo objetivo principal seja emitir guias de cobrana de impostos e
fazer o controle de contribuintes, NO um produto inerente ao trabalho de levantamento de requisitos125
xx
(a) uma descrio da relao possvel entre as linhas de cdigo com os pontos de funo.
(b) uma declarao da necessidade e da viabilidade.
(c) uma descrio do ambiente tcnico do sistema.
(d) uma afirmao limitada do escopo do sistema.
(e) um conjunto de cenrios que fornecem informaes sobre o uso do sistema sob diferentes condies de
operao.
71

TI para concursos
126

126. correto afirmar que


(a) um relatrio no um artefato de sistema.
(b) segurana no um requisito no funcional de sistema.
xx
(c) um executvel um artefato de sistema.
(d) os atributos de uma classe UML so especificaes dos seus mtodos.
(e) confiabilidade um requisito funcional de sistema.

(ICMS-SP 2009) Instrues: Para responder s duas prximas questes, considere:


necessrio que o software calcule os salrios dos diaristas e mensalistas e emita relatrios mensais
sumariados por tipo de salrio. Entretanto, a base de dados deve estar protegida e com acesso restrito aos
usurios autorizados. De qualquer forma, o tempo de resposta das consultas no deve superar os quinze
segundos, pois inviabilizaria todo o investimento nesse sistema. Devo lembrar que os relatrios individuais dos
departamentos, nos quais constam os salrios dos funcionrios, devem ser emitidos quinzenalmente em razo
dos adiantamentos e vales que recebem. fundamental que o software seja operacionalizado usando cdigo
aberto. Necessito, ainda, forte gerenciamento de risco, prazo e custo, porque a entrega do produto final no
pode ultrapassar o prazo de oito meses a contar da data de incio do projeto. A frase acima, expressa por um
funcionrio do cliente, aborda alguns requisitos de software especificados para um sistema de gesto de
pessoal.
127. (ICMS-SP 2009) No texto, so requisitos no-funcionais:127
(a) no pode ultrapassar o prazo de oito meses e necessrio que o software calcule os salrios dos diaristas
e mensalistas.
(b) os relatrios individuais dos departamentos, nos quais constam os salrios dos funcionrios, devem ser
emitidos quinzenalmente e em razo dos adiantamentos e vales que recebem.
(c) fundamental que o software seja operacionalizado usando cdigo aberto e os relatrios individuais dos
departamentos, nos quais constam os salrios dos funcionrios, devem ser emitidos quinzenalmente.
(d) tempo de resposta das consultas no deve superar os quinze segundos e entrega do produto final no
xx
pode ultrapassar o prazo de oito meses.
(e) pois inviabilizaria todo o investimento nesse sistema e em razo dos adiantamentos e vales que recebem.
128. (ICMS-SP 2009) No texto, so requisitos funcionais:128
(a) calcule os salrios dos diaristas e mensalistas e os relatrios individuais dos departamentos, nos quais
constam os salrios dos funcionrios, devem ser emitidos quinzenalmente. xx
(b) Necessito, ainda, forte gerenciamento de risco, prazo e custo e a base de dados deve estar protegida e
com acesso restrito aos usurios autorizados.
(c) fundamental que o software seja operacionalizado usando cdigo aberto e emita relatrios mensais
sumariados por tipo de salrio.
(d) emita relatrios mensais sumariados por tipo de salrio e necessito, ainda, forte gerenciamento de risco,
prazo e custo.
(e) a base de dados deve estar protegida e com acesso restrito aos usurios autorizados e entrega do
produto final no pode ultrapassar o prazo de oito meses.
129. (ICMS-SP 2009) O processo de confirmao que um software vai ao encontro das especificaes de software
se trata de um conceito-chave de qualidade denominado 129
(a) Validao.
(b) Verificao.xx
(c) Preciso.
(d) Acurcia.
(e) Confiabilidade.

6.4

Tcnicas de avaliao de software


Em funo de seus requisitos funcionais e no funcionais, um grande desafio em desenvolvimento de
sistemas a estimativa do tamanho e do esforo do produto desejado ou entregue, assim como de
eventuais melhorias.
Entre as diversas metodologias de estimativa de tamanho de software, temos o COCOMO, que avalia
esforo e custo de projeto, e a Anlise de Ponto de Funo, que estima tamanho relativo apenas de
requisitos funcionais.

6.4.1

Mtodo COCOMO
O mtodo COCOMO (ou COnstructive COst MOdel) um modelo de estimativa do tempo de
desenvolvimento de um produto. Criado por Barry Boehm. baseado no estudo de sessenta e trs
projetos. Os programas examinaram de 2.000 a 100.000 linhas de cdigo em linguagens de
programao de Assembly a PL/I.35
A partir de um conjunto de atributos, premissas e modos de desenvolvimento o COCOMO estima os
prazos, custos e recursos necessrios para cada etapa do ciclo de vida do produto.
COCOMO consiste em trs implementaes:

http://pt.wikipedia.org/wiki/M%C3%A9todo_COCOMO
72
35

TI para concursos

Bsico - um modelo esttico que calcula o esforo de desenvolvimento de software e seu custo, em
funo do tamanho de linhas de cdigos desenvolvidas.
Cocomo bsico bom por ser rpido em estimativas e custos de software, mas sua exatido
limitada por causa de sua falta de fatores para explicar as diferenas entre ferramentas, qualidade de
pessoal e experincia, uso de ferramentas modernas e tcnicas, e outros atributos de projeto que
influenciam nos custos de software.
Intermedirio - Calcula o esforo de desenvolvimento de software em funo do tamanho do
programa, que inclui custo, avaliao subjetiva do produto, hardware, pessoal e atributos de projeto.
O mtodo intermedirio uma extenso do mtodo bsico, mas com mais categorias de controle
como: atributos do produto, atributos de hardware, atributos pessoais, atributos do projeto.
Avanado - So incorporadas caractersticas da verso intermediria com uma avaliao de impacto
de custo em cada passo de todo o projeto.

6.4.2

Anlise por Pontos de Funo


Anlise de Pontos de Funo (APF) uma tcnica para a medio de projetos de desenvolvimento de
software, visando estabelecer uma medida de tamanho, em Pontos de Funo (PF), considerando a
funcionalidade implementada, sob o ponto de vista do usurio. A medida independente da linguagem
de programao ou da tecnologia que ser usada para implementao.36
Seus objetivos so:
medir a funcionalidade solicitada pelo usurio, antes
do projeto de software, de forma a estimar seu
tamanho
medir projetos de desenvolvimento de software,
independentemente da tecnologia utilizada na
implementao, de forma a acompanhar sua
evoluo
medir a funcionalidade recebida pelo usurio, aps o
projeto de software, de forma verificar seu tamanho
As organizaes podem aplicar a Anlise de Pontos por
Funo como:
uma ferramenta para determinar o tamanho de pacotes de software adquiridos, atravs da
contagem de todos os Pontos por Funo includos no pacote
uma ferramenta para apoiar a anlise de produtividade
um fator de normalizao para comparao de software
O procedimento para contagem de PFs compreende:37
Determinar o Tipo de Contagem
projeto de desenvolvimento
aplicaes instaladas
projetos de melhoria

Identificar o Escopo de Contagem e Fronteira da Aplicao


definir a parte do sistema (funcionalidades) a ser contada

Determinar os PFs no ajustados


Contagem das Funes
dados - arquivos lgicos internos (ALI) e arquivos de interface externa (AIE)
transacionais entradas (EE), sadas (SE) e consultas (CE) externas

Determinar o Fator de Ajuste


o fator de ajuste baseado em quatorze caractersticas gerais de sistemas, que avaliam a funcionalidade
geral da aplicao que est sendo contada, e seus nveis de influncia. O nvel de influncia de uma
caracterstica determinado com base em uma escala de 0 (nenhuma influncia) a 5 (forte influncia).

Calcular os PFs Ajustados


6.4.2.1

Contagem das Funes de Dados


O primeiro passo para a contagem das funes de dados consiste em identificar arquivos lgicos
internos (ALIs) e arquivos de interface externa (AIEs). Cada uma dessas funes de dados deve ser
classificada segundo sua complexidade funcional. Essa complexidade definida com base nos conceitos
de registros lgicos e itens de dados.
Registros Lgicos so subconjuntos de dados dentro de um ALI/AIE, que foram reconhecidos pelo
usurio. Se o usurio no reconhecer subconjuntos de dados em um ALI/AIE, ento se deve contar o
ALI/AIE como um registro lgico.

http://pt.wikipedia.org/wiki/An%C3%A1lise_de_pontos_de_fun%C3%A7%C3%A3o
http://www.inf.ufes.br/~falbo/download/aulas/es-g/2005-1/APF.pdf
73
36
37

TI para concursos

Um Item de Dados, por sua vez, um campo reconhecido pelo usurio como nico e no repetido. Vale
destacar que s devem ser contados os itens de dados utilizados pela aplicao em contagem.
Contando-se os registros lgicos e os itens de dados de um ALI/AIE, pode-se chegar sua
complexidade, utilizando a tabela 1:

6.4.2.2

Nmero de Itens de Dados Referenciados

Nmero de Registros
Lgicos

1 a 19

20 a 50

51 ou mais

Apenas 1

Simples

Simples

Mdia

2a5

Simples

Mdia

Complexa

6 ou mais

Mdia

Complexa

Complexa

Contagem das Funes Transacionais


De maneira anloga contagem das funes de dados, a contagem das funes transacionais envolve a
identificao de funes transacionais (entradas externas, sadas externas e consultas externas) e sua
classificao de acordo com a complexidade funcional envolvida (simples, mdia ou complexa). A
definio da complexidade funcional feita com base no nmero de arquivos referenciados e dos itens
de dados manipulados pela funo, utilizando as tabelas 2 para entradas externas e 3 para sadas e
consultas externas.
Nessas tabelas, um arquivo referenciado pode ser um ALI lido ou mantido pela funo transacional, ou
um AIE lido pela funo transacional. J o nmero de itens de dados referenciados calculado
considerando apenas os itens de dados efetivamente referenciados pela funo transacional em
questo.
Tabela 2 para entradas externas:
Nmero de Itens de Dados Referenciados

Nmero de arquivos
referenciados

1a4

5 a 15

16 ou mais

0 ou 1

Simples

Simples

Mdia

Simples

Mdia

Complexa

3 ou mais

Mdia

Complexa

Complexa

Tabela 3 para sadas e consultas externas:

6.4.2.3

Nmero de Itens de Dados Referenciados

Nmero de arquivos
referenciados

1a5

6 a 19

20 ou mais

0 ou 1

Simples

Simples

Mdia

2 ou 3

Simples

Mdia

Complexa

4 ou mais

Mdia

Complexa

Complexa

Clculo dos Pontos de Funo No Ajustados


Uma vez contadas as funes de dados e as funes transacionais, possvel calcular os PFs no
ajustados de uma aplicao. Esse clculo feito da seguinte forma:
1. Para cada um dos cinco tipos de funo (ALI, AIE, EE, SE e CE), so computados os totais de pontos
de funo (NPFi), segundo a seguinte expresso:

onde
NCi,j
=
nmero funes do tipo i (i variando de 1 a 5, segundo os tipos de funo
existentes: ALI, AIE, EE, SE e CE) que foram classificados na complexidade j (j variando de 1 a 3,
segundo os valores de complexidade: simples, mdia e complexa).
Ci,j =
valor da contribuio da complexidade j no clculo dos pontos da funo i, dado pela
tabela a seguir.

74

TI para concursos

Funo

Complexidade
Simples

Mdia

Complexa

arquivos lgicos internos


- ALI

10

16

arquivos de interface
externa - AIE

10

entradas externas - SE

sadas externas - EE

consultas externas - CE

Tabela 1 Contribuio das Funes na Contagem de PFs No Ajustados

2. O total de pontos de funo no ajustados (PFNA) dado pelo somatrio dos pontos das tabelas de
funo:

sendo que i varia de 1 a 5, segundo os tipos de funo existentes (AIL, AIE, EE, SE e CE).
6.4.2.4

Determinao do Fator de Ajuste


O fator de ajuste influencia os pontos de funo no ajustados em +/- 35%, obtendo-se o nmero de PFs
ajustados. Para se calcular o fator de ajuste, so usadas 14 caractersticas gerais dos sistemas, a saber:

Comunicao de Dados
Processamento de Dados Distribudo
Desempenho
Utilizao do Equipamento (Restries de Recursos Computacionais)
Volume de Transaes
Entrada de Dados On-line
Eficincia do Usurio Final (Usabilidade)
Atualizao On-line
Processamento Complexo
Reusabilidade
Facilidade de Implantao
Facilidade Operacional (Processos Operacionais, tais como Inicializao, Cpia de Segurana,
Recuperao etc)
Mltiplos Locais e Organizaes do Usurio
Facilidade de Mudanas (Manutenibilidade)

Para cada uma dessas 14 caractersticas deve-se atribuir um valor de 0 (nenhuma influncia) a 5 (forte
influncia), dito grau ou nvel de influncia, que indica o quanto determinada caracterstica tem influncia
no sistema. Os 14 graus de influncia (GIs) informados so somados, resultando no nvel de influncia
total (NIT):

Finalmente, o valor do fator de ajuste (VFA) determinado, ento, pela frmula:


Considerando que o valor mximo do NIT 14x5=70 e o mnimo zero, ento, o valor do VFA varia de
0,65 a 1,35.
6.4.2.5

Clculo dos Pontos de Funo Ajustados


Uma vez calculados os PF no ajustados e o fator de ajuste, possvel calcular os PFs ajustados. Esse
clculo feito de formas diferentes para cada tipo de contagem (projeto de desenvolvimento, projeto de
manuteno ou aplicaes instaladas). Para projetos de desenvolvimento, o clculo dado por:
PF = PFNA * VFA
onde
PFNA = Nmero de PFs no ajustados
VFA = valor do fator de ajuste

75

TI para concursos

Gerncia de Configurao e Mudana

7.1

Conceitos de Gerncia de Configurao e Mudana de software


Gerncia de Configurao de Software uma rea da engenharia de software responsvel por fornecer
o apoio para o desenvolvimento de software. Suas principais atribuies so o controle de verso, o
38
controle de mudana e a auditoria das configuraes.
Conjunto de atividades projetadas para controlar as mudanas pela identificao dos produtos do
trabalho que sero alterados, estabelecendo um relacionamento entre eles, definindo o mecanismo para
o gerenciamento de diferentes verses destes produtos, controlando as mudanas impostas, e auditando
e relatando as mudanas realizadas.
A Gerncia de Configurao e Software definida por quatro funes bsicas:
Identificao dos itens de configurao
Documentao
Controle
Auditoria das mudanas

7.1.1

Configurao de software
Configurao o estado em que um sistema se encontra em um determinado momento. Este sistema
pode ser composto de todo tipo de elementos, como peas de hardware, artefatos eletrnicos ou no
(i.e. documentos em papel), etc. A Configurao de Software trata apenas dos elementos que se
encontram em formato eletrnico e fazem parte dessa configurao. Isso inclui todos os arquivos fontes,
todos os documentos eletrnicos, as ferramentas de software utilizadas para construir ou mesmo ler
estes arquivos, o sistema operacional utilizado, as bibliotecas de software, etc.
Essa configurao varia com o tempo, pois novos arquivos so includos, e arquivos existentes so
alterados ou removidos. O objetivo da Gerncia de Configurao como um todo organizar todos estes
elementos de forma a saber em qual estado o sistema se encontrava nos momentos chave do
desenvolvimento (por exemplo, quando o sistema foi entregue ao cliente, quando o sistema passou por
uma mudana de verso, quando o sistema foi enviado para auditoria, etc). A Gerncia de Configurao
como um todo trata dos elementos, incluindo hardware, necessrios para a manuteno apropriada do
sistema. A Gerncia de Configurao de Software trata especificamente dos elementos necessrios a
construo de sistemas de software, e em geral, controla apenas os elementos em formato
computadorizado.
Em Sistemas de controle de verso as configuraes especficas so geralmente identificadas pelo uso
de tags ou labels (placas ou etiquetas, em ingls).

7.1.2

Item de configurao de software


Durante o desenvolvimento de software, uma grande quantidade de informaes produzida e cada um
desses documentos produzidos que precisam sofrer controle de verses e de mudanas chamado de
item de configurao de software O Item de configurao um elemento unitrio que ser gerenciado:
um arquivo de cdigo fonte, um documento de texto, um projeto de uma placa eletrnica, uma planta
feita em papel, um CD-ROM de instalao de um sistema operacional, etc. A configurao de um
sistema basicamente a lista de todos os itens de configurao necessrios para reproduzir um
determinado estado de um sistema. Em geral nmeros de verso so associados aos itens de
configurao de forma a podermos identificar tambm a evoluo destes itens.
Exemplos de itens de configurao podem ser:
Item A: CD de instalao do sistema operacional, verso 1.0
Item B: Documento de ajuda do sistema em formato eletrnico, verso 2.0
Item C: Processador de texto usado para imprimir o documento de ajuda, verso 5.0
Segundo Pressman os seguintes SCIs tornam-se alvos das tcnicas de GCS e formam um conjunto de
linhas bsicas (Baselines):
1.Especificao do Sistema.
2.Plano de Projeto do Software.
3.Requisitos
1.Especificao dos Requisitos de Software;
2.Prottipo executvel ou "em papel".
4.Manual Preliminar do Usurio.
5.Especificao de Projeto:

http://pt.wikipedia.org/wiki/Ger%C3%AAncia_de_Configura%C3%A7%C3%A3o_de_Software
76
38

TI para concursos

7.1.3

1.Descrio do projeto de dados;


2.Descries do projeto arquitetural;
3.Descries do projeto modular;
4.Descries do projeto de interfaces;
5.Descries de objetos (no caso do uso da metodologia OO).
6.Listagem do cdigo-fonte.
7.Teste de Software/Sistema:
1.Plano e Procedimentos de Testes;
2.Casos de teste e resultados registrados.
8.Manuais Operacionais e de Instalao.
9.Programa Executvel:
1.Mdulos;
2.Mdulos interligados.
10.Descrio do Banco de Dados:
1.Esquema e estrutura de arquivo;
2.Contedo inicial.
11.Manual Feito de Acordo com o Usurio.
12.Documentos de Manuteno:
1.Relatrios de problemas de software;
2.Solicitaes de manuteno;
3.Pedidos de mudana de engenharia.
13.Padres e procedimentos para engenharia de software.

Controle de verses
O Controle de verso rastreia e controla todos os artefatos do projeto (cdigo-fonte, arquivos de
configurao, documentao etc.) e assim consegue coordenar o trabalho paralelo de desenvolvedores
atravs das seguintes funcionalidades:
Mantm e disponibiliza cada verso j produzida de cada item do projeto
Possui mecanismos para gerenciar diferentes ramos de desenvolvimento, possibilitando a existncia
de diferentes verses ao mesmo tempo (concorrncia)
Estabelece uma poltica de sincronizao de mudanas que evita a sobreposio de mudanas
Fornece um histrico completo de alteraes sobre cada item do projeto
Controle de Verso resolve diversos problemas bsicos de desenvolvimento tais como uso de diferentes
verses de cdigo, sincronizao do trabalho paralelo de desenvolvedores no mesmo projeto,
recuperao de verses anteriores e registro do histrico de alteraes.

7.1.4

Papis
Uma das principais definies da poltica de Gerncia de Configurao de Software so os papeis a
serem desempenhados. A poltica no determina quais pessoas desempenharo quais papeis, cabendo
isso a gerncia de projeto. Alguns papeis necessrios numa poltica so:
Gestor de configurao do projeto. Ele o responsvel por acompanhar as alteraes dos itens de
configuraes de um determinado projeto. Em geral este papel cabe ao integrador.
Gestor de ferramentas de Gerncia de configurao. Ele o responsvel pela manuteno da
infraestrutura necessria para o bom funcionamento da Gerncia de configurao no conjunto dos
projetos da organizao, ou no contexto do projeto, se for o caso. Em geral uma pessoa da rea de
infraestrutura com bons conhecimentos da plataforma operacional e das ferramentas usadas.
Gestor de Configurao de Software, ou Responsvel de Gerncia de Configurao de Software. Ele
o responsvel por aprovar e gerenciar as atividades relativas a Gerncia de Configurao de
Software, coordenar a equipe de Gerncia de Configurao de Software e algumas vezes, coordenar
o trabalho de integrao de sistemas.
Auditor de Configurao de Software. Ele o responsvel pela realizao das auditorias de
configurao nos projetos.
Desenvolvedor. Ele o principal usurio da Gerncia de configurao de software, sendo quem
produz os itens de configurao que sero gerenciados.

7.2

Solicitaes de Mudana
As mudanas nos artefatos de desenvolvimento so propostas atravs de Solicitaes de Mudana (CRs
ou Change Requests), que so usadas para documentar e controlar defeitos, solicitaes de melhorias e
qualquer outro tipo de solicitao de mudana no produto.

77

TI para concursos

A vantagem das CRs que elas fornecem um registro das decises e, devido a seu processo de
avaliao, garantem que os impactos das mudanas sejam entendidos no projeto.39
A necessidade de mudana parece ser inerente aos sistemas de software existentes e em
desenvolvimento. O Gerente de Controle de Mudana responsvel pela definio dos procedimentos
de Gerenciamento de Solicitaes de Mudana e pela manuteno de CRs, garantindo que as
mudanas em um sistema sejam efetuadas de maneira controlada, para que seu efeito no sistema possa
ser previsto. As CRs podem ser usadas para documentar e controlar todos os tipos de solicitaes de
mudanas no sistema, inclusive defeitos e solicitaes de melhoria.
As solicitaes de melhoria so usadas pelo Analista de Sistemas para determinar futuros recursos a
serem includos no produto. Sero usadas como base durante a coleta de solicitaes dos principais
envolvidos (stakeholders) para que se possa compreender as necessidades dos investidores.
Um defeito uma anomalia ou falha em um produto de trabalho liberado. Alguns exemplos so omisses
e imperfeies localizadas durante as fases iniciais do ciclo de vida e sintomas (falhas) de erros contidos
em softwares maduros o suficiente para teste e operao. Os defeitos tambm podem incluir desvios das
expectativas ou qualquer questo que precise ser controlada e resolvida.
A finalidade de um defeito comunicar os detalhes da questo, permitindo a ao corretiva, a soluo e
o acompanhamento.
As seguintes pessoas usam as CRs:
O Analista de Sistemas usa as CRs identificadas como Solicitaes de Melhoria para determinar
novos recursos do produto.
O Gerente de Projetos usa CRs para atribuir trabalho.
Os Testadores usam CRs para identificar e descrever os defeitos localizados no teste.
O Implementador usa CRs para analisar o defeito e localizar os erros ou causas das CRs.
O Designer de Teste usa CRs a fim de planejar o teste para verificar as CRs solucionadas e analisar
um conjunto de defeitos para medir a qualidade do software e do processo.
Os seguintes atributos so teis para tomar uma deciso sobre qualquer CR enviada:
Tamanho
Que volume de trabalho existente precisar ser alterado?
Que volume de trabalho extra precisar ser adicionado?
Alternativas
Existe alguma?
Complexidade
A mudana proposta fcil de ser efetuada?
Quais so as possveis ramificaes provenientes dessa mudana?
Gravidade
Qual o impacto da no implementao desta solicitao?
H alguma perda de trabalho ou de dados envolvida?
Esta uma solicitao de melhoria?
um problema secundrio?
Cronograma
Quando a mudana necessria?
Ela vivel?
Impacto
Quais as conseqncias de efetuar a mudana?
Quais as conseqncias de no efetuar a mudana?
Custo
Qual a economia proveniente desta mudana?
Relacionamento com Outras Mudanas
Outras mudanas substituiro ou invalidaro esta ou isso depende de outras mudanas?
Teste
H algum requisito especial de teste?
As prticas de Gerenciamento de Mudanas normalmente so institucionalizadas ou estabelecidas no
incio do ciclo de vida do projeto. Desse modo, as CRs, que integram o processo de mudana, podem
surgir a qualquer momento durante o curso do projeto.
A principal origem de defeitos consiste nos resultados da execuo dos testes integrao, sistema e
desempenho. Contudo, os defeitos podem aparecer em qualquer ponto do ciclo de vida de
http://www.wthreex.com/rup/process/artifact/ar_crqst.htm
78
39

TI para concursos

desenvolvimento do software e abranger a identificao de documentao, casos de teste ou casos de


uso ausentes ou incompletos.
Qualquer pessoa da equipe de projeto deve ser capaz de efetuar uma CR. No entanto, a CR precisa ser
revisada e aprovada pelo supervisor da pessoa que a efetuou. A arbitragem final sobre uma Solicitao
de Mudana realizada por uma Equipe de Reviso ou um Comit de Controle de Mudana (CCB).
O Gerente de Controle de Mudana responsvel pela integridade do defeito, garantindo que:
Sejam exatas todas as informaes que identificam e descrevem o defeito e indicam como ele foi
descoberto.
O defeito seja exclusivo ou que no seja outra ocorrncia de um defeito j identificado.
Os campos e os dados reais necessrios para identificar, descrever e controlar defeitos com preciso
so variados e dependem do sistema de controle de mudanas, das diretrizes e dos padres
implementados.

7.3

Exerccios
(ICMS-SP 2009) Instrues: Para responder s trs prximas questes, considere a tabela e os dados de
referncia para os clculos de pontos de funo.

Pontuao por complexidade de funo


Tipos

Simples

Mdio

Complexo

EE

SE

CE

ALI

10

15

AIE

10

Nveis de Influncia:
0 Nenhuma influncia.
1 Influncia mnima.
2 Influncia moderada.
3 Influncia mdia.
4 Influncia significante.
5 Influncia forte.
Caractersticas Gerais de Sistema:
1. Comunicao de Dados.
2. Processamento de Dados Distribudo (Funes Distribudas).
3. Performance.
4. Configurao do equipamento.
5. Volume de Transaes.
6. Entrada de Dados On line.
7. Interface com o usurio.
8. Atualizao On line.
9. Processamento Complexo.
10. Reusabilidade.
11. Facilidade de Implantao.
12. Facilidade Operacional.
13. Mltiplos Locais.
14. Facilidade de mudanas.
130. (ICMS-SP 2009) Durante o levantamento de requisitos de um sistema, foram apuradas as seguintes
informaes, base para o clculo de pontos de funo: 130
Complexidade de:
Entrada: 2 complexas , 4 mdias e 5 simples.
Sada: 10 mdias e 3 simples.
Arquivo mantido dentro da fronteira do sistema: 1 complexo e 2 mdios.
Sem nenhuma influncia, o resultado apurado foi
(a) 133
(b) 138
(c) 140xx
(d) 149
(e) 161

79

TI para concursos

131. (ICMS-SP 2009) Mantida a pontuao bruta obtida na questo de nmero 22 e considerando que as
influncias por caractersticas gerais do sistema foram estimadas como:
Forte em performance.
Significante em entrada de dados on line e em processamento distribudo.
Demais caractersticas sem influncia.
131
O resultado final mais aproximado, aps o ajuste, foi
(a) 98,0
(b) 107,8
(c) 110,6
xx
(d) 109,2
(e) 116,0
132. (ICMS-SP 2009) Aps um levantamento mais apurado do sistema referido, funes foram modificadas,
adicionadas ou excludas e, em razo das modificaes sugeridas, chegou-se s seguintes e novas
informaes:
Complexidade de:
Consulta: 5 complexas, 10 mdias e 11 simples.
Arquivo mantido fora da fronteira do sistema: 1 complexo e 1 mdio.
Entrada: 2 complexas, 4 mdias e 5 simples.
Sada: 5 complexas, 10 mdias e 3 simples.
Arquivo mantido dentro da fronteira do sistema: 3 complexos, 1 mdio e 4 simples.
As novas influncias por caractersticas gerais do sistema foram estimadas como:
Forte em performance.
Significante em entrada de dados on line, em processamento distribudo, em facilidade de mudanas e em
interface com o usurio.
Mnima em volume de transaes.
Moderada em comunicao de dados.
Demais caractersticas sem influncia.
132
Com base nessas novas informaes levantadas, o resultado final mais aproximado, aps o ajuste, foi
(a) 263,7
(b) 298,9
(c) 300,5
(d) 305,3xx
(e) 432,8
133. NO uma das nove caractersticas em um tratamento detalhado das mtricas de software (Whitmire) para o
modelo de projeto orientado a objeto: 133
(a) o custo.xx
(b) o tamanho.
(c) a complexidade.
(d) o acoplamento.
(e) a coeso.
134. O mtodo que busca medir esforo, prazo, tamanho de equipe e custo necessrio para o desenvolvimento do
software, desde que se tenha a dimenso do mesmo, por meio de um modelo de estimativa de tamanho de
software (Boehm) o 134
(a) Function Point Analysis.
xx
(b) CoCoMo.
(c) Work Breakdown Structure.
(d) Benchmarking.
(e) Flowcharting.
135. Considere 1952 pontos por funo brutos e a aplicao do valor 3 a todos os fatores de ajuste. Os pontos por
funo ajustados so 135
(a) 1268,80.
(b) 1542,08.
(c) 1815,36.
(d) 2088,64.xx
(e) 2635,00.
136. Durante a medio do grau de complexidade de um sistema foram apurados 550 pontos de funo brutos.
Considerando que o somatrio dos graus atribudos aos fatores de ajuste foi 30, a medida final em pontos de
funo foi 136
(a) 520
xx
(b) 522,5
(c) 552,5
(d) 580
(e) 585,5

80

TI para concursos

Engenharia de Software
Engenharias da sistemas um campo interdisciplinar da engenharia que foca no desenvolvimento e
organizao de sistemas artificiais complexos. As tcnicas de Engenharia de Sistemas podem ser
utilizadas em desenvolvimento de softwares.
Engenharia de produo o ramo da engenharia que dedica-se concepo, melhoria e implementao
de sistemas que envolvem pessoas, materiais, informaes, equipamentos, energia e maior de
conhecimentos e habilidades, para especificar, prever e avaliar os resultados obtidos por tais sistemas.
A Engenharia de processos um ramo da engenharia que se preocupa, entre outras coisas, em elaborar
e executar projetos e estudos de formas de aproveitamento de mo-de-obra, mquinas e equipamentos,
para melhorar processos, para o aumento da qualidade do produto, reduo de perdas e maior
produtividade.
Neste contexto, a engenharia de software aproveita diversas tcnicas de engenharia de sistemas, de
produto e de processos para a produo de aplicativos com maior eficincia e eficcia.
Nos anos 40, grande parte dos esforos e custos era concentrada no desenvolvimento do hardware.
medida que a tecnologia de hardware foi sendo dominada, as preocupaes se voltaram, no incio dos
anos 50, para o desenvolvimento dos sistemas operacionais e de linguagens de programao de alto
nvel, como FORTRAN e COBOL.
No incio dos anos 60, com o surgimento dos sistemas operacionais com caractersticas de
multiprogramao, a eficincia e utilidade dos sistemas computacionais tiveram um considervel
crescimento, surgindo a necessidade de desenvolver grandes sistemas de software em substituio aos
pequenos programas aplicativos utilizados at ento.
Desta necessidade, surgiu um problema chamado de crise do software, que permitiu o nascimento do
termo Engenharia de Software.
Atualmente, o custo de desenvolvimento de software corresponde a uma percentagem cada vez maior
no custo global de um sistema informatizado.
A principal razo para isto que a tecnologia de desenvolvimento de software implica em grande carga
de trabalho, envolvendo muitas pessoas num prazo relativamente longo de desenvolvimento.

8.1

Software40
Software um conjunto de instrues, estruturas de dados e documentao destinados a resolver um
problema.
Em Engenharia de Software, o software deve ser visto como um produto a ser vendido.
Em sistemas simples, onde o usurio o prprio autor, a documentao pequena ou inexistente e a
preocupao com a existncia de erros de execuo no um fator muito relevante, pode no haver
grandes dificuldades na deteco e correo de falhas, nem preocupao como a portabilidade, a
flexibilidade e a possibilidade de reutilizao.
Um produto de software destinado ao uso por pessoas outras que os seus programadores, a sua
interface importante, reforada com uma documentao rica em informaes para que todos os
recursos oferecidos possam ser explorados de forma eficiente.
Produtos de software devem passar normalmente por uma exaustiva bateria de testes, dado que os
usurios no estaro de detectar e corrigir os eventuais erros de execuo.
o software concebido e desenvolvido como resultado de um trabalho de engenharia e no
manufaturado no sentido clssico;
o software no se desgasta, no aumenta a possibilidade de falhas medida que o tempo passa;
a maioria dos produtos de software concebida inteiramente sob medida, sem a utilizao de
componentes pr-existentes.
Em funo destas caractersticas diferenciais, o processo de desenvolvimento de software pode
desembocar um conjunto de problemas, os quais tero influncia direta na qualidade do produto.
O processo de desenvolvimento de software procura responder:
por que o software demora tanto para ser concludo?
por que os custos de produo tm sido to elevados?
por que no possvel detectar todos os erros antes que o software seja entregue ao cliente?
por que to difcil medir o progresso durante o processo de desenvolvimento de software?

http://jalvesnicacio.files.wordpress.com/2010/03/engenharia-de-software.pdf
81
40

TI para concursos

8.2

Ciclo de vida do software


O ciclo de vida de um software descreve as fases pelas quais o software passa desde a sua concepo
41
at ficar sem uso algum.
Quatro fases que so delimitadas por eventos tpicos em diversos ciclos de vida. Cada fase inclui um
conjunto de atividades ou disciplinas que devem ser realizadas pelas partes envolvidas.
Definio
Desenvolvimento
Operao
Retirada

8.2.1

Fase de Definio
A fase de definio do software ocorre em conjunto com outras atividades como a modelagem de
processos de negcios e anlise de sistemas. Nesta atividade, diversos profissionais buscam o
conhecimento da situao atual e a identificao de problemas para que possam elaborar propostas de
soluo de sistemas computacionais que resolvam tais problemas. Dentre as propostas apresentadas,
deve-se fazer um estudo de viabilidade, incluindo anlise custo-benefcio, para se decidir qual soluo
ser a escolhida.
O resultado desta atividade deve incluir a deciso da aquisio ou desenvolvimento do sistema,
indicando informaes sobre hardware, software, pessoal, procedimentos, informao e documentao.
Caso seja decidido pelo desenvolvimento do sistema, no escopo da engenharia de software,
necessrio elaborar o documento de proposta de desenvolvimento de software. Esse documento pode
ser a base de um contrato de desenvolvimento.
Profissionais de engenharia de software atuam nesta atividade com o objetivo de identificar os requisitos
de software e modelos de domnio que sero utilizados na fase de desenvolvimento. Os requisitos so
tambm fundamentais para que o engenheiro possa elaborar um plano de desenvolvimento de software,
indicando em detalhes os recursos necessrios (humanos e materiais), bem como as estimativas de
prazos e custos (cronograma e oramento).
No existe um consenso sobre o que caracteriza o final da fase de definio. Isto varia de acordo com o
modelo de processo adotado. Em algumas propostas, a fase de definio considerada concluda com a
apresentao da proposta de desenvolvimento apenas. Outros modelos de processo, considera que o
software apenas est completamente definido com a especificao de requisitos e com a elaborao do
plano de desenvolvimento de software.
De acordo com o modelo de processo adotado, pode-se iniciar atividades da fase de desenvolvimento
mesmo que a fase de definio no esteja completamente concluda.

8.2.2

Fase de Desenvolvimento
A fase de desenvolvimento ou de produo do software inclui todas as atividades que tem por objetivo a
construo do produto. Ela inclui principalmente o design, a implementao e a verificao e validao
do software.

8.2.2.1

Design
A atividade de design compreende todo o esforo de concepo e modelagem que tm por objetivo
descrever como o software ser implementado. O design inclui:
Design conceitual
Design da interface de usurio
Design da arquitetura do software
Design dos algoritmos e estruturas de dados
O design conceitual envolve a elaborao das idias e conceitos bsicos que determinam os elementos
fundamentais do software em questo. Por exemplo, um software de correio eletrnico tradicional inclui
os conceitos: mensagem, caixa de entrada, caixa de sada, etc. A mensagem, por sua vez, inclui os
conceitos de para, cc, bcc, assunto, corpo, etc. Embora seja um design adotado pela maioria dos
software, novos modelos conceituais podem vir a ser adotados. O conceito de conversao do Gmail
um exemplo.
O design conceitual exerce influncia na interface de usurio e na arquitetura do software.
O design da interface de usurio envolve a elaborao da maneira como o usurio pode interagir para
realizar suas tarefas, a escolha dos objetos de interfaces (botes, menus, caixas de texto, etc.), o layout
de janelas e telas, etc. A interface deve garantir a boa usabilidade do software e um fundamental fator
de sucesso do software.

http://engenhariadesoftware.blogspot.com/2007/02/ciclo-de-vida-do-software-parte-1.html
82
41

TI para concursos

O design de arquitetura de software deve elaborar uma viso macroscpica do software em termos de
componentes que interagem entre si. O conceito de componente em arquitetura varia de acordo com a
viso arquitetnica adotada. So exemplos de vises arquitetnicas, a viso conceitual, viso de
mdulos, viso de cdigo e viso de execuo.
Na viso conceitual, os componentes de software so derivados do design conceitual. Estes
componentes so abstraes que devem definir outros elementos menos abstratos. Exemplos so
arquiteturas cliente-servidor e arquitetura em camadas. Na viso de cdigo, deve-se determinar como as
classes e/ou funes esto organizadas e interagindo entre si. Estas classes implementam os
componentes abstratos ou conceituais. Na viso de mdulos, deve-se determinar quais so os mdulos
que sero utilizados na implementao e como eles organizam as classes e/ou funes. Na viso de
execuo, a arquitetura deve descrever os diferentes processos que so ativados durante a execuo do
software e como eles interagem entre si. Enquanto as anteriores oferecem uma viso esttica, esta
uma viso dinmica do software.
O design de algoritmos e estrutura de dados, tambm conhecido como design detalhado, visa
determinar, de maneira independente da linguagem de programao adotada, as solues algortmicas e
as estruturas de dados associados. Deve-se decidir, por exemplo, como as informaes podem ser
ordenadas (algoritmo de bolha ou quicksort) e em qual tipo de estrutura de dados (array, lista
encadeada) elas vo ser armazenados.
8.2.2.2

Implementao
A implementao envolve as atividades de codificao, compilao, integrao e testes. A codificao
visa traduzir o design num programa, utilizando linguagens e ferramentas adequadas. A codificao deve
refletir a estrutura e o comportamento descrito no design. Os componentes arquiteturais devem ser
codificados de forma independente e depois integrados. Os testes podem ser iniciados durante a fase de
implementao. A depurao de erros ocorre durante a programao utilizando algumas tcnicas e
ferramentas. fundamental um controle e gerenciamento de verses para que se tenha um controle
correto de tudo o que est sendo codificado.

8.2.2.3

Verificao e validao
Verificao e validao destinam-se a mostrar que o sistema est de acordo com a especificao e que
ele atende s expectativas de clientes e usurios. A validao visa assegurar se o programa est
fazendo aquilo que foi definido na sua especificao (fazendo a coisa certa). A verificao visa verificar
se o programa est correto, isto , no possui erros de execuo (fazendo certo a coisa). Existem
diferentes formas de verificao e validao. Inspeo analtica e reviso de modelos, documentos e
cdigo fonte so formas que podem ser usadas antes mesmo que o programa seja completamente
codificado. Os testes de correo, desempenho, confiabilidade, robustez, usabilidade, dentre outros,
visam avaliar diversos fatores de qualidade a partir da execuo do software. Diferentes tcnicas de
testes podem ser aplicadas para cada um destes fatores.

8.2.3

Fase de Operao
A fase de operao envolve diferentes tipos de atividades:
Distribuio e entrega
Instalao e configurao
Utilizao
Manuteno
A distribuio e entrega pode ser feita diretamente pelo desenvolvedor (em caso de software
personalizado), ou em um pacote a ser vendido em prateleiras de lojas ou para ser baixado pela Internet
(em caso de software genricos).
O processo de instalao e configurao, normalmente, pode ser feito com a ajuda de software de
instalao disponibilizados pelos fabricantes dos ambientes operacionais.
A atividade de utilizao o objeto do desenvolvimento do software. A qualidade da utilizao a
usabilidade do software.
A manuteno normalmente ocorre de duas formas: corretiva e evolutiva. A manuteno corretiva visa a
resoluo de problemas referentes a qualidade do software (falhas, baixo desempenho, baixa
usabilidade, falta de confiabilidade etc.). A manuteno evolutiva ou adaptativa visa a produo de novas
verses do software de forma a atender a novos requisitos dos clientes, ou adaptar-se s novas
tecnologias que surgem (hardware, plataformas operacionais, linguagens, etc). Mudanas no domnio de
aplicao implicam em novos requisitos e incorporao de novas funcionalidades. Surgimento de novas
tecnologias de software e hardware e mudanas para uma plataforma mais avanada tambm requerem
evoluo.

83

TI para concursos

8.2.4

Fase de retirada
A fase retirada um grande desafio para os tempos atuais. Diversos software que esto em
funcionamento em empresas possuem excelente nveis de confiabilidade e de correo. No entanto, eles
precisam evoluir para novas plataformas operacionais ou para a incorporao de novos requisitos. A
retirada desses software legados em uma empresa sempre uma deciso difcil: como abrir mo daquilo
que confivel e ao qual os funcionrios esto acostumados, aps anos de treinamento e utilizao?
Processos de reengenharia podem ser aplicados para viabilizar a transio ou migrao de um software
legado para um novo software de forma a proporcionar uma retirada mais suave.

8.3

Metodologias de desenvolvimento de software.

8.3.1

Modelo catico42
O produto construdo sem qualquer especificao ou projeto. O
produto retrabalhado quantas vezes forem necessrias para
satisfazer o cliente. Este modelo pode funcionar razoavelmente
para micro projetos (at 400 homens.hora). No entanto para
projetos maiores ele inadequado.

8.3.2

Modelo Cascata
Recomendado para sistemas onde a segurana e a confiabilidade tem grande importncia.
Orientado para documentao, que abrange representaes grficas e simulaes, e com uma
abordagem disciplinada, a cada fase so feitos procedimentos de verificao e validao (incluindo
testes), so liberadas definies da documentao e todos produtos so formalmente revisados.
Uma vez definido o modelo de ciclo de desenvolvimento, existem trs abordagens para implement-lo
Cascata Pura
Incremental
Evolucionria

8.3.2.1

Abordagem Cascata Pura


Todas as fases do ciclo de desenvolvimento so executadas em sequncia. As fases anteriores so
revisitadas para correes de erros ou para adaptaes. Esta abordagem adequada quando :
existe um conjunto de Requisitos do Usurio estveis e de alta qualidade
a durao do projeto pequena
o sistema completo deve estar disponvel de um nica vez

8.3.2.2

Abordagem Incremental
Nesta abordagem o desenvolvedor executa mltiplas fases de PD, TR e OM. Dentro desta abordagem
est a abordagem cascata.
A abordagem incremental adequada quando:
a liberao do software deve estar de acordo com um conjunto de prioridades definidas nos
Requisitos do Usurio
necessrio melhorar a eficincia da integrao do software com outra partes de um sistema
maior
so requeridas antecipadamente evidncias de que o produto ser aceito
RU Requisitos do
usurio
RS Requisitos do
software
PA Projeto da
arquitetura
PD Projeto detalhado
TR Treinamento
OM Operao e
Manuteno

8.3.2.3

Abordagem Evolucionria
Nesta abordagem, o desenvolvimento formado por mltiplos ciclos da
abordagem cascata pura, ocorrendo sobreposio das fases da

http://www2.dem.inpe.br/ijar/CicoloVidaSoftPrado.html
84
42

TI para concursos

operao e manuteno do sistema anterior com o novo desenvolvimento. Esta abordagem adequada
quando:
necessrio alguma experincia do usurio para refinar e completar requisitos
algumas partes da implementao podem depender da existncia de tecnologia ainda no
disponvel
existem requisitos do usurio no bem conhecidos
alguns requisitos so muito mais difceis de serem implementados do que outros, decidindo-se
no implement-lo para no atrasar o projeto
8.3.2.4

Modelo Espiral
Modelo em cascata onde cada fase precedida
por uma anlise de risco e sua execuo feita
evolucionariamente (ou incrementalmente).
A dimenso radial representa o custo acumulado
atualizado e a dimenso angular representa o
progresso atravs da espiral. Cada setor da espiral
corresponde
a
uma
tarefa
(fase)do
desenvolvimento.
Um ciclo se inicia com a tarefa "Determinao de
objetivos, alternativas e restries", onde ocorre o
comprometimento
dos
envolvidos
e
o
estabelecimento de uma estratgia para alcanar
os objetivos.
Na tarefa "Avaliao de alternativas, identificao e
soluo de riscos", executa-se uma anlise de risco. Prototipao uma boa ferramenta para tratar
riscos. Se o risco for considerado inaceitvel, pode parar o projeto.
Na terceira tarefa ocorre o desenvolvimento do produto. Neste quadrante pode-se considerar o modelo
cascata.
Na quarta tarefa o produto avaliado e se prepara para iniciar um novo ciclo.
Variaes do modelo espiral consideram entre trs e seis tarefas ou setores da espiral. Por exemplo, as
regies:
comunicao com o cliente
planejamento
anlise de risco
engenharia
construo e liberao
avaliao do cliente

8.4

Desenvolvimento gil43
Desenvolvimento gil de software (do ingls Agile software development) ou Mtodo gil um conjunto
de metodologias de desenvolvimento de software. O desenvolvimento gil, tal como qualquer
metodologia de software, providencia uma estrutura conceitual para reger projetos de engenharia de
software.
Existem inmeros frameworks de processos para desenvolvimento de software. A maioria dos mtodos
geis tenta minimizar o risco pelo desenvolvimento do software em curtos perodos, chamados de
iterao, os quais gastam tipicamente menos de uma semana a at quatro. Cada iterao como um
projecto de software em miniatura de seu prprio, e inclui todas as tarefas necessrias para implantar o
mini-incremento da nova funcionalidade: planejamento, anlise de requisitos, projeto, codificao, teste e
documentao. Enquanto em um processo convencional, cada iterao no est necessariamente
focada em adicionar um novo conjunto significativo de funcionalidades, um projecto de software gil
busca a capacidade de implantar uma nova verso do software ao fim de cada iterao, etapa a qual a
equipe responsvel reavalia as prioridades do projecto.
Mtodos geis enfatizam comunicaes em tempo real, preferencialmente face a face, a documentos
escritos. A maioria dos componentes de um grupo gil deve estar agrupada em uma sala. Isso inclui
todas as pessoas necessrias para terminar o software: no mnimo, os programadores e seus clientes
(clientes so as pessoas que definem o produto, eles podem ser os gerentes, analistas de negcio, ou
realmente os clientes). Nesta sala devem tambm se encontrar os testadores, projectistas de iterao,
redactores tcnicos e gerentes.

http://pt.wikipedia.org/wiki/Desenvolvimento_gil_de_software
85
43

TI para concursos

Mtodos geis tambm enfatizam trabalho no software como uma medida primria de progresso.
Combinado com a comunicao face-a-face, mtodos geis produzem pouca documentao em relao
a outros mtodos, sendo este um dos pontos que podem ser considerados negativos. recomendada a
produo de documentao que realmente ser til.
Os princpios do desenvolvimento gil valorizam:
Garantir a satisfao do consumidor entregando rapidamente e continuamente softwares
funcionais;
Softwares funcionais so entregues frequentemente (semanas, ao invs de meses);
Softwares funcionais so a principal medida de progresso do projecto;
At mesmo mudanas tardias de escopo no projecto so bem-vindas.
Cooperao constante entre pessoas que entendem do negcio e desenvolvedores;
Projetos surgem atravs de indivduos motivados, entre os quais existe relao de confiana.
Design do software deve prezar pela excelncia tcnica;
Simplicidade;
Rpida adaptao s mudanas;
Indivduos e interaes mais do que processos e ferramentas;
Software funcional mais do que documentao extensa;
Colaborao com clientes mais do que negociao de contratos;
Responder a mudanas mais do que seguir um plano.
A maioria dos mtodos geis compartilha a nfase no Desenvolvimento iterativo e incremental para a
construo de verses implantadas do software em curtos perodos de tempo. Mtodos geis diferem
dos mtodos iterativos porque seus perodos de tempo so medidos em semanas, ao invs de meses, e
a realizao efetuada de uma maneira altamente colaborativa. estendendo-se a tudo.
Algumas equipes geis usam o modelo em cascata em pequena escala, repetindo o ciclo de cascata
inteiro em cada iterao. Outras equipes, mais especificamente as equipes de Programao extrema,
trabalham com atividades simultaneamente.
A codificao cowboy, tambm chamada de Modelo Balbrdia, a ausncia de metodologias de
desenvolvimento de Software: os membros da equipe fazem o que eles sentem que correto. Como os
desenvolvedores que utilizam mtodos geis freqentemente reavaliam os planos, enfatizam a
comunicao face a face e fazem o uso relativamente esparso de documentos, ocasionalmente levam as
pessoas a confundirem isto com codificao cowboy. Equipes geis, contudo, seguem o processo
definido (e freqentemente de forma disciplinada e rigorosa).
Como em todas as metodologias, o conhecimento e a experincia dos usurios definem o grau de
sucesso e/ou fracasso de cada atividade. Os controles mais rgidos e sistematizados aplicados em um
processo implicam altos nveis de responsabilidade para os usurios. A degradao de procedimentos
bem-intencionados e organizados pode levar as atividades a serem caracterizadas como codificao
cowboy.
De uma perspectiva organizacional, a aplicabilidade pode ser expressa examinando trs dimenses
chaves da organizao: cultura, pessoal e comunicao. Em relao a estas reas inmeros fatores
chave do sucesso podem ser identificados (Cohen et al., 2004):[2]
A cultura da organizao deve apoiar a negociao.
As pessoas devem ser confiantes.
Poucas pessoas, mas competentes.
A organizao deve promover as decises que os desenvolvedores tomam.
A Organizao necessita ter um ambiente que facilite a rpida comunicao entre os membros.
O fator mais importante provavelmente o tamanho do projeto. Com o aumento do tamanho, a
comunicao face a face se torna mais difcil. Portanto, mtodos geis so mais adequados para
projetos com pequenos times, com no mximo de 20 a 40 pessoas.
Ambiente ideal para o desenvolvimento gil:
Baixa criticidade
Desenvolvedores senior
Mudanas freqente de requisitos
Pequeno nmero de desenvolvedores
Cultura que tem sucesso no caos.
Ambiente ideal para o desenvolvimento direcionado ao planejamento:
Alta criticidade
Desenvolvedores Junior
Baixa mudana nos requisitos
Grande nmero de desenvolvedores
Cultura que procura a ordem.
86

TI para concursos

8.5

Planejamento e avaliao de iteraes


Uma iterao um perodo de tempo definido dentro de um projeto em que voc produz uma verso
estvel e executvel do produto, junto com toda a documentao de apoio, scripts de instalao e
similares, necessrios para usar a liberao. tambm conhecida como ciclo ou tempo definido.
A finalidade das iteraes produzir um executvel que possa ser avaliado de forma que voc possa
obter feedback e fazer correes de rumo. Este executvel lhe coloca uma etapa mais perto do produto
final. As fases fornecem um foco para a equipe chegar a um determinado objetivo da gerncia. O
OpenUP tem quatro fases, cada uma terminando com respostas a perguntas especficas:
Concepo - Ns concordamos com o problema que estamos tentando resolver?
Elaborao - Ns concordamos com toda a soluo, e compreendemos os riscos, custos e
cronograma razoavelmente bem?
Construo - Ns concordamos que temos um sistema que atende s principais necessidades dos
stakeholders?
Transio - Ns concordamos que podemos liberar o sistema e terminar o projeto?
Em cada fase, voc pode ter uma ou vrias iteraes, onde cada uma visa produzir os resultados
necessrios para responder a estas perguntas. Por exemplo, para responder pergunta da Elaborao,
ns necessitamos implementar e testar alguns aspectos chaves do sistema de modo que possamos
compreender qual arquitetura necessria, que componentes comerciais (COTS) necessitaremos, quais
os principais riscos que enfrentamos e como direcion-los, qual a eficcia da equipe etc. Estas
necessidades iro orientar a atribuio das prioridades ao que deve ser feito em uma iterao de
Elaborao.
Uma das principais vantagens da abordagem iterativa em relao abordagem em cascata o fato de
as iteraes fornecerem marcos naturais para avaliar o progresso e os riscos provveis. Na iterao, a
avaliao do progresso e do risco dever continuar (se realizada informalmente) para garantir que as
dificuldades no desviem o projeto.
A Avaliao de Iterao captura o resultado de uma iterao, at que ponto os critrios de avaliao
foram respeitados e as mudanas que devem ser feitas.
Cada iterao concluda por uma Avaliao de Iterao, na qual a organizao de desenvolvimento
para para refletir sobre o que aconteceu, o que foi ou no alcanado e por qu, e as lies aprendidas.
Essa avaliao uma etapa decisiva em uma iterao e no deve ser ignorada. Se a Avaliao de
Iterao no for feita corretamente, muitos dos benefcios oferecidos por uma abordagem iterativa
podero se perder.
Algumas vezes, o procedimento correto nesta etapa rever os critrios de avaliao, em vez de
retrabalhar o sistema. s vezes, a vantagem da Avaliao de Iterao est em revelar que um
determinado requisito no importante, muito caro para ser implementado ou cria uma arquitetura que
no pode ser mantida. Nesses casos, uma anlise de custo e benefcio deve ser feita e uma deciso de
negcios deve ser tomada.
A mtrica deve ser usada como base dessa avaliao.
Quase no final de cada iterao, a equipe central do projeto dever se reunir para avaliar a iterao,
enfatizando o seguinte:
A iterao obteve xito no cumprimento de suas metas?
Os riscos foram reduzidos ou eliminados?
O release cumpriu suas metas de funcionalidade, qualidade, desempenho e capacidade?
So necessrias mudanas no projeto e nos planos de iterao futuros?
Alguma das descobertas capturadas no artefato, na avaliao da organizao de desenvolvimento,
foi invalidada pelas mudanas durante a iterao e, como conseqncia, exige mudanas em outros
artefatos?
Houve alguma dificuldade no processo de desenvolvimento durante a iterao?
Que parte do release atual servir como baseline? Sofrer retrabalho?
Novos riscos foram identificados?
Houve mudanas externas (mudanas no mercado, na comunidade de usurios ou nos requisitos)?
Avalie os resultados da iterao com relao aos critrios de avaliao que foram estabelecidos para o
plano de iterao: funcionalidade, desempenho, capacidade, medidas de qualidade.
Use as mtricas obtidas nas atividades de teste e no passo coletar mtricas como a base da avaliao,
quando disponveis, para quantific-la. As medidas qualitativas so adequadas para a fase de iniciao e
talvez para a iterao inicial, enquanto as fases posteriores de elaborao, construo e transio
devem depender de medies de teste especficas para avaliar a qualidade, o desempenho, a
capacidade etc. Aborde outros problemas pendentes que foram capturados nas avaliaes de status
durante a iterao e quaisquer outros problemas na lista de problemas do gerente de projeto.

87

TI para concursos

Se todos os riscos tiverem sido reduzidos a nveis aceitveis, toda a funcionalidade tiver sido
implementada e todos os objetivos de qualidade tiverem sido atingidos, o produto estar concludo. O
planejamento e a execuo eficientes so vitais para isso ocorrer no final da fase de Transio.

8.6

Testes Software
O teste do software a investigao do software a fim de fornecer informaes sobre sua qualidade em
relao ao contexto em que ele deve operar. Isso inclui o processo de utilizar o produto para encontrar
seus defeitos.
O teste um processo realizado pelo testador de software, que permeia outros processos da engenharia
de software, e que envolve aes que vo do levantamento de requisitos at a execuo do teste
propriamente dito.
No se pode garantir que todo software funcione corretamente, sem a presena de erros, visto que os
mesmos muitas vezes possuem um grande nmero de estados com frmulas, atividades e algoritmos
complexos. O tamanho do projeto a ser desenvolvido e a quantidade de pessoas envolvidas no processo
aumentam ainda mais a complexidade. Idealmente, toda permutao possvel do software deveria ser
testada. Entretanto, isso se torna impossvel para a ampla maioria dos casos devido quantidade
impraticvel de possibilidades. A qualidade do teste acaba se relacionando qualidade dos profissionais
envolvidos em filtrar as permutaes relevantes.
Falhas podem ser originadas por diversos motivos. Por exemplo, a especificao pode estar errada ou
incompleta, ou pode conter requisitos impossveis de serem implementados, devido limitaes de
hardware ou software. A implementao tambm pode estar errada ou incompleta, como um erro de um
algoritmo. Portanto, uma falha o resultado de um ou mais defeitos em algum aspecto do sistema.
Todas as metodologias de desenvolvimento de software tm uma disciplina dedicada aos testes.
Atualmente esta uma tarefa indispensvel, porm muitas vezes efetuada de maneira ineficiente, seja
pelo subestimar dos que desenvolvem, pela falta de tempo ou mesmo pela falta de recursos humanos e
financeiros.
O gerenciamento de projetos define alguns princpios em relao aos testes: 44

Testar um exerccio de gerncia de risco


Treinamento em teste reduz custos a longo prazo
As estimativas de teste devem ser baseadas no risco do negcio
A estratgia de teste deve ser elaborada atravs de um trabalho conjunto entre as reas envolvidas
melhor encontrar um defeito nas primeiras fases do que em produo

Um plano de testes deve passar por alguns estgios:


Planejamento

Estratgia de Teste
Cronograma bsico
Plano de Teste
Cronograma final
Anlise de Risco
Anlise de Pontos deTeste

Elaborao

Elaborar Cenrio de Teste


Elaborar Caso de Teste
Procedimento de Teste
Implementar Teste

Execuo
Casos de Teste
Roteiros de Teste

Controle
Relatrios de Defeitos
Relatrios de Progresso

As pessoas envolvidas nos testes podem assumir os papis de:


Lder ou Gerente de teste, responsvel pela liderana de um projeto de teste especfico
Arquiteto de Teste, responsvel pela montagem do ambiente de teste (infra-estrutura) e escolha das
ferramentas
Analista de Teste, responsvel pela modelagem e elaborao dos casos de testes e scripts de teste
Testador, responsvel pela execuo dos casos de teste e scripts de teste

A definio de quem ir executar os testes depender do nvel ou estgio do teste:

Teste Unitrio - Desenvolvedores


Teste de Integrao - Analistas de Sistemas
Teste de Sistema - Analistas de Teste
Teste de Aceitao - Usurios e Analistas de Teste

http://www.iteste.com.br/Portals/0/Palestra%20Gerencia%20de%20Teste_1%20hora.pdf
88
44

TI para concursos

Existem tcnicas de testes chamadas de funcionais, que verificam se o sistema faz o que deveria:45
Teste de caixa-branca - Tambm chamado de teste estrutural ou orientado lgica, avalia o
comportamento interno do componente de software. Essa tcnica trabalha diretamente sobre o cdigo
fonte do componente de software para avaliar aspectos tais como: teste de condio, teste de fluxo de
dados, teste de ciclos, teste de caminhos lgicos, cdigos nunca executados.
Teste de caixa-preta - Tambm chamado de teste funcional, orientado a dado ou orientado a entrada e
sada, avalia o comportamento externo do componente de software. Dados de entrada so fornecidos, o
teste executado e o resultado obtido comparado a um resultado esperado previamente conhecido.

H, por outro lado, as tcnicas no funcionais, que testam como a operao correta do sistema se
comporta em situaes anormais, como casos de entradas invlidas ou inesperadas.
teste de desempenho com teste de carga, verifica se o software consegue processar grandes
quantidades de dados nas especificaes de tempo de processamento exigidas, o que determina a
escalabilidade do software.
teste de usabilidade, necessrio para verificar se a interface de usurio fcil de se aprender e utilizar.
teste de confiabilidade, usado para verificar se o software pode assegurar o sigilo dos dados
armazenados e processados.
teste de recuperao, usado para verificar a robustez do software em retornar a um estado estvel de
execuo aps estar em um estado de falha.

8.6.1

Documentos de Teste
IEEE 829-1998, tambm conhecido como o Padro 829 para Documentao de Teste de Software, um
padro IEEE que especifica a forma de uso de um conjunto de documentos em oito estgios definidos de
teste de software, cada estgio potencialmente produzindo seu prprio tipo de documento. O padro
especifica o formato desses documentos mas no estipula se todos eles devem ser produzidos, nem
inclui qualquer critrio de contedo para esses documentos.46
Documentao de Teste consiste em um conjunto de documentos relacionados ao teste das diversas
classes e seus relacionamentos no sistema. Dentre eles pdemos ter:47
Plano de Teste, que prescreve o escopo, a abordagem, os recursos e o cronograma de testes. No
mnimo os seguintes tpicos devem ser tratados:
Descrio do programa a ser testado: o que faz; estrutura
Objetivo dos testes: por exemplo, se so testes caixa branca ou caixa preta, se so testes de integrao
ou de unidade
Escopo dos testes: que itens sero testados, quais no sero

Projetos de Teste, que detalha o planejamento de testes e identifica os elementos a serem testados.
No caso de testes de unidades, cada unidade um item. Defino das estruturas provisrias (drivers,
stubs, arquivos ou bancos de dados criados para os testes, entre outros) que sero usadas nos
testes.
Casos de Teste especificados no projeto. A descrio de cada caso de teste deve conter os seguintes
tpicos:

Identificao do caso de teste


Itens a testar
Entradas: valores dos campos de entrada
Sadas esperadas: valores dos campos de sada
Ambiente: necessidade de hw, sw, ferramentas e estruturas provisrias que sejam especficas desse caso
de teste
Procedimentos: identificao do procedimento de teste (dentre os j listados na seo anterior) que ser
usado para executar o caso de teste
Dependncias: condies prvias para a execuo do caso de teste, inclusive outros casos de teste que
devam ser executados obrigatoriamente antes deste
Sadas observadas: resultados fornecidos pelo item em teste ou anomalias ocorridas durante a execuo
Impacto: consequncias do incidente de teste (evento indesejvel que tenha ocorrido durante os testes).
Como para a inspeo, classific-los em categorias:
MA: maior. Causa resultados errados/anomalia na execuo do programa
ME: menor. Causa outro tipo de problema que no afeta a execuo do programa

Procedimentos de Teste, que especifica os passos para execuo. Definio dos procedimentos
associados ao conjunto de testes:

Uma identificao do procedimento .


O objetivo do procedimento.
Os requisitos especiais para a execuo do procedimento (por exemplo, usar o arquivo DadosTeste)
O fluxo passo a passo do procedimento detalhado o suficiente para que possa ser executado
manualmente por um operador ou convertido em um script de teste.
Descrio de cada um dos casos de teste gerado.

Resultados do teste, contendo os registros dos testes realizados em ordem cronolgica.


45
46
47

http://pt.wikipedia.org/wiki/Teste_de_software
http://se.inf.ethz.ch/teaching/ss2005/0050/exercises/REMOVED/IEEE%20Std%20829-1998%20test.pdf
http://www.ic.unicamp.br/~eliane/Cursos/Planos_Testes/Documentos/plantestes.doc.

89

TI para concursos

Relatrio de incidentes, contendo o registro dos problemas encontrados durante os testes que
meream ser investigados.
Relatrio de resumo dos teste, contendo um resumo dos resultados das atividades projetadas e
fornecendo avalies baseadas nestes resultados. O relatrio fecha a etapa de testes realizada,
permitindo uma avaliao da eficcia dos mesmos, indicao do nvel de qualidade do produto, se h
necessidade de testes adicionais ou a reconstruo de alguns itens sob teste. O relatrio de resumo
pode conter:
Identificador do relatrio resumido
Contexto: quais os itens testados, com respectivos nmeros de verso e reviso
Variaes: descrever as possveis variaes dos testes realizados em relao ao previsto na
especificao, justifiando o motivo de tais variaes
Abrangncia: avaliar se a cobertura foi suficiente, conforme o planejado. Indicar possveis deficincias nos
testes, caso existam.
Sumrio dos resultados: resumir os incidentes ocorridos
Avaliao: fornecer uma avaliao global da eficcia dos testes; uma base para isso pode ser o nmero
de defeitos classificados como MA que foram encontrados.
Sumrio das atividades: para cada item testado, indicar o tempo previsto e os efetivamente gastos para
as tarefas de teste
Aprovaes: indicar se o item testado foi considerado aprovado ou no.

8.7

Exerccios
137. (ICMS-SP 2009) Garantir que um ou mais componentes de um sistema combinados funcionam corretamente
o objetivo do tipo de teste 137
(a) de sistema.
(b) de integrao.xx
(c) de configurao.
(d) operacional.
(e) funcional.
138. (ICMS-SP 2009) O teste de ameaa normalmente deve ser aplicado dentro de um projeto de software nas
138
etapas de
(a) desenvolvimento inicial e desenvolvimento intermedirio.
(b) desenvolvimento intermedirio e teste de aceitao.
(c) desenvolvimento intermedirio e teste de sistema.
(d) teste de integrao e teste de aceitao.
(e) teste de integrao e teste de sistema. xx
139. (ICMS-SP 2009) Na prtica de garantia de qualidade de software, contrapondo com o controle de qualidade de
139
software, se aplica a atividade:
(a) executar teste de software.
(b) desenvolver casos de testes.
xx
(c) definir mtricas e medio.
(d) definir estratgias de testes.
(e) definir planos de desenvolvimento de teste.
140. (ICMS-SP 2009) O processo de engenharia de software denominado ciclo de vida clssico refere-se ao
140
modelo
xx
(a) em cascata.
(b) incremental.
(c) evolucionrio.
(d) prototipagem.
(e) de processo unificado
141. (ICMS-SP 2009) O conceito de sprint aplica-se ao modelo gil do processo de engenharia de software
141
denominado
(a) XP.
(b) DAS.
(c) DSDM.
xx
(d) Scrum.
(e) Crystal.
142. (ICMS-SP 2009) A engenharia de software est inserida no contexto 142
(a) da engenharia de sistemas, apenas.
(b) das engenharias de processo e de produto, apenas.
(c) das engenharias de sistemas e de processo, apenas.
(d) das engenharias de sistemas e de produto, apenas.
(e) das engenharias de sistemas, de processo e de produto.xx

90

TI para concursos
143

143. Na metodologia Scrum, NO faz parte de uma reviso do sprint (sprint review) o seguinte procedimento:
(a) Todo o time colabora no que deve ser feito em seguida, de modo que esta reviso contribua para
reunies de planejamento subsequentes.
(b) O proprietrio do produto identifica o que est pronto e o que ainda est por fazer.
(c) O time de desenvolvimento discute quais fatores positivos e negativos ocorreram durante o sprint e como
os problemas foram resolvidos.
(d) O time de desenvolvimento apresenta o trabalho que foi desenvolvido e responde questes sobre o
incremento.
xx
(e) Todo o time cria um plano para implementar melhorias no modo como o time efetua seu trabalho.
144. O modelo FURPS, para melhoria de qualidade de software, representa as dimenses, que so mais relevantes
144
para os clientes:
xx
(a) Funcionalidade, Usabilidade, Confiabilidade, Desempenho e Suportabilidade.
(b) Funcionalidade, Usabilidade, Reusabilidade, Pontualidade e Suportabilidade.
(c) Flexibilidade, Usabilidade, Conformidade, Desempenho e Atendimento.
(d) Flexibilidade, Usabilidade, Reusabilidade, Performance e Suportabilidade.
(e) Integridade, Usabilidade, Conformidade, Portabilidade e Atendimento.
145. NO um dos sete princpios (David Hooker) da Engenharia de Software:
(a) manter a coisa simples.
(b) no especificar requisitos detalhadamente.xx
(c) estar aberto para o futuro.
(d) planejar o reso com antecedncia.
(e) manter a viso.

145

146. Se em uma seqncia de atividades de um projeto todas elas tiverem retardo de zero dias em relao s suas
146
predecessoras
(a) o projeto invivel.
(b) isso indica a ausncia de caminho crtico.
(c) essa seqncia o caminho crtico.xx
(d) a seqncia est errada.
(e) o projeto deve ser desmembrado.
147. Um Plano de Projeto de Software um documento gerencial que se destina a um pblico diverso e NO deve
conter 147
(a) a comunicao do escopo e dos recursos administrao, aos clientes e equipe tcnica.
(b) a definio dos principais requisitos e dos riscos com sugestes tcnicas para, respectivamente,
atendlos ou evit-los.
(c) o desenho dos componentes do software para planejar a sua instalao e operacionalizao.
(d) a definio dos custos e dos prazos para as revises administrativas do projeto.xx
(e) a apresentao de uma abordagem global do desenvolvimento do software para todas as pessoas
envolvidas no projeto.

91

TI para concursos

Banco de Dados

9.1

Conceitos bsicos
Dentre diversas definies, dado tudo que pode ser processado e as informaes so dados que
descrevem um domnio fsico ou abstrato. Registros so informaes produzidas como subprodutos de
48
atividades comerciais ou transaes e retidas em virtude do seu valor.
Entidade qualquer coisa do mundo real, abstrata ou concreta, na qual se deseja guardar informaes.
Atributo tudo o que se pode relacionar como propriedade da entidade. Domnio o conjunto de valores
possveis do atributo. Em banco de dados, fisicamente, entidades so tabelas, atributos so as colunas e
domnio o tipo de dado contido na coluna.
Um atributo dito obrigatrio quando no puder ter seu valor omitido. Ele identificador quando for
capaz de identificar uma linha nica da tabela, caso em que chamado de chave candidata. Uma tabela
deve possuir pelo menos uma chave candidata para poder ser gerenciada, caso em que a coluna ser
chamada de chave primria. Se houver mais do que uma chave candidata, uma dever ser escolhida
para se a chave primria, enquanto que as outras sero chamadas de chaves alternativas.
Bancos de dados (ou bases de dados) so conjuntos de registros dispostos em estrutura regular que
possibilita a reorganizao dos mesmos e produo de informao, usualmente mantido e acessado por
meio de um software conhecido como Sistema Gerenciador de Banco de Dados (SGBD). 49
Modelo de dados forma como os dados so armazenados, que pode determinar a forma como as
informaes podem ser processadas.
O modelo plano ou tabular consiste de tabelas, que so matrizes simples, bidimensionais, compostas por
elementos de dados: caracteres, nmeros inteiros, reais etc. Este modelo plano a base das planilhas
eletrnicas.
O modelo em rede permite que vrias tabelas sejam usadas simultaneamente atravs do uso de
apontadores (ou referncias). Algumas colunas contm apontadores para outras tabelas ao invs de
dados. Assim, as tabelas so ligadas por referncias, o que pode ser visto como uma rede. Uma
variao particular deste modelo em rede, o modelo hierrquico, limita as relaes a uma estrutura
semelhante a uma rvore (hierarquia - tronco, galhos), ao invs do modelo mais geral direcionado por
grafos.

9.2

Modelagem de Dados Relacional


No modelo relacional, todos os dados esto guardados em tabelas. Toda sua definio terica e
baseada na lgica de predicados e na teoria dos conjuntos. Consiste, principalmente, de trs
componentes:
uma coleo de estruturas de dados, nomeadamente relaes ou tabelas;
uma coleo dos operadores, a lgebra e o clculo relacionais;
uma coleo de restries da integridade, definindo o conjunto consistente de estados de base de
dados e de alteraes de estados. As restries de integridade podem ser dos tipos:
domnio indica os valores possveis para os dados
nulo ou atributo vazio determina se o valor do dado pode ser indeterminado
chave define uma coluna ou grupo de colunas que caracterizam uma linha nica de uma tabela
chave primria chave que identifica uma linha da prpria tabela e no pode ter valor repetido nesta
chave estrangeira chave que identifica uma linha de outra tabela, que pode ser repetida nesta, mas
deve existir o que se chama de integridade referencial e no pode se repetir na outra tabela

Toda informao tem de ser representada como dados e qualquer tipo de atributo (coluna) representa
relaes entre conjuntos de dados (linhas).
As bases de dados relacionais permitem aos utilizadores (incluindo programadores) escreverem
consultas (queries) que no foram antecipadas por quem projetou a base de dados. Como resultado,
bases de dados relacionais podem ser utilizadas por vrias aplicaes em formas que os projetistas
originais no previram, o que especialmente importante em bases de dados que podem ser utilizadas
durante dcadas. Isto tem tornado as bases de dados relacionais muito populares no meio empresarial.

9.2.1

Normalizao
A normalizao de dados uma srie de passos que se segue no projeto de um banco de dados que
permite um armazenamento consistente e um eficiente acesso aos dados em um banco de dados

http://pt.wikipedia.org/wiki/Informa%C3%A7%C3%A3o
http://pt.wikipedia.org/wiki/Banco_de_dados
92
48
49

TI para concursos

relacional. Esses passos reduzem a redundncia de dados e as chances dos dados se tornarem
inconsistentes. 50
No entanto, muitos SGBDs relacionais no tm separao suficiente entre o projeto lgico da base de
dados e a implementao fsica do banco de dados, e isso tem como conseqncia que as consultas
feitas a um banco de dados totalmente normalizado tm um mau desempenho. Nestes casos, usa-se por
vezes a desnormalizao para melhorar o desempenho, com o custo de menores garantias de
consistncia.
Dizemos que duas colunas de uma tabela tm dependncia funcional quando a valor de uma determina
o valor da outra. Por exemplo, uma coluna com o nmero de matrcula e outra com o nome de um aluno.
Um nmero de matrcula s pode corresponder a uma aluno, portanto h dependncia funcional entre
estas duas colunas.
Chamamos de chave a um conjunto de colunas que identifica unicamente cada linha da tabela. No
exemplo anterior, o nmero de matrcula do aluno campo chave da tabela, supondo no poder haver
uma pessoa com dois nmeros de matrcula. Em uma tabela contendo o nmero de matrcula do aluno,
o cdigo da disciplina, a nota e frequncia do aluno, as duas primeiras colunas formam uma chave da
tabela.
Se nossa tabela de exemplo contiver a coluna CPF e RG do aluno, teremos trs nmeros que identificam
de forma nica nosso aluno, trs chaves. Dizemos que o nmero de matrcula, o RG e o CPF so
chaves candidatas. Se escolhermos uma delas para identificar o aluno, esta ser chamada de chave
primria.
Tirando as chaves, os demais campos so chamados de descritores.
Ao imprimir a lista de notas finais dos alunos, podemos ter:
Nm Matrcula

Nome

Nm Disc

Disciplina

Prova 1

Prova 2

Mdia

Frequncia

123456

Funalo de Tal

12

Matemtica

5,0

7,0

6,0

95%

123456

Funalo de Tal

13

Portugus

8,0

9,0

8,5

100%

234567

Cicrano da Silva

12

Matemtica

6,0

9,0

7,5

80%

234567

Cicrano da Silva

13

Portugus

3,0

8,0

5,5

70%

A chave da tabela composta das colunas Nm Matrcula e Nm Disc. Dizemos que h dependncia
parcial entre o nome a uma das colunas chave, entre o cdigo e o nome da disciplina tambm.
Poderamos preferir imprimir a lista sem repetir o nome de cada aluno:
Nm Matrcula Nome
123456
Funalo de Tal

234567

Cicrano da Silva

Nm Disc Disciplina

Prova 1 Prova 2 Mdia Frequncia

12 Matemtica

5,0

7,0

6,0

95%

13 Portugus

8,0

9,0

8,5

100%

12 Matemtica

6,0

9,0

7,5

80%

13 Portugus

3,0

8,0

5,5

70%

Onde, para cada linha de um aluno, teramos uma lista de disciplinas e notas. Dizemos que os campos
nmero de matrcula e nome possuem valores atmicos, um s valor por linha.
Os demais campos so chamados de multivalorados, pois so listas de valores para uma mesma linha
da tabela.
Diz-se que uma tabela num banco de dados relacional est numa certa forma normal se satisfaz certas
condies. Considera-se que as bases de dados esto normalizadas se aderirem terceira forma
normal.
Primeira Forma Normal (ou 1FN) requer que todos os valores de colunas em uma tabela, sejam atmicos
(um nmero um tomo, enquanto uma lista ou um conjunto no o so). A normalizao elimina grupos
repetidos pondo-os cada um em uma tabela separada, conectando-os com uma chave primria ou
estrangeira. Por exemplo, pessoas tm diversos nmeros de telefones. Uma tabela conter as pessoas e
outra tabela os telefones, ligadas pelo cdigo da pessoa.
Segunda Forma Normal (ou 2FN) requer que no haja dependncia funcional no-trivial de um atributo
que no seja a chave, em parte da chave candidata. Por exemplo, uma tabela de pedidos com o cdigo
do pedido, chave primria, cdigo do produto, chave estrangeira, e descrio do produto, campo
dependente funcional do cdigo do produto, que no chave primria. O correto levar a descrio e
cdigo do produto para outra tabela e deixar somente o cdigo do produto na tabela de pedidos.
Terceira Forma Normal (ou 3FN) requer no haver dependncias funcionais no-triviais de atributos que
no sejam chave, em qualquer coisa exceto um superconjunto de uma chave candidata. Por exemplo,
uma coluna preo total, que resultado do produto do valor da coluna quantidade pelo preo unitrio e
no depende do cdigo do pedido, chave primria. A coluna preo total deve ser eliminada, sendo o valor
calculado quando for necessrio em relatrios.
http://pt.wikipedia.org/wiki/Normaliza%C3%A7%C3%A3o_de_dados
93
50

TI para concursos

Forma Normal de Boyce-Codd (ou BCNF) requer que no exista nenhuma dependncia funcional notrivial de atributos em algo mais do que um superconjunto de uma chave candidata. Neste estgio, todos
os atributos so dependentes de uma chave, de uma chave inteira e de nada mais que uma chave
(excluindo dependncias triviais, como A->A).
Quarta Forma Normal (ou 3FN) Uma relao est na 4 forma normal, se est na Boyce-Codd, e se no
existem dependncias multivalor
Forma Normal (ou 3FN) Uma relao est na 5 forma normal, se est na 4 FN, e se no existem
dependncias de juno.

As quarta e quinta formas normais so raras e difceis de detectar.


Frequentemente considera-se que uma relao na 3 forma normal ou Boyce-Codd est num nvel de
normalizao aceitvel.

9.2.2

Etapas de modelagem
A construo de modelos relacionais envolve as etapas:51
Modelo conceitual - Representa as regras de negcio sem limitaes tecnolgicas ou de
implementao:

Viso Geral do negcio


Facilitao do entendimento entre usurios e desenvolvedores
Possui somente as entidades e atributos principais
Pode conter relacionamentos n para m.

Modelo Lgico - Leva em conta limites imposto por algum tipo de tecnologia de banco de dados:

Deriva do modelo conceitual


Possui entidades associativas em lugar de relacionamentos n:m
Define as chaves primrias das entidades
Normalizao at a 3a. forma normal
Adequao ao padro de nomenclatura
Entidades e atributos documentados

Modelo Fsico - Leva em considerao limites imposto pelo SGBD (Sistema Gerenciador de Banco de
dados) e pelos requisitos no funcionais dos programas que acessam os dados. Caractersticas:

9.2.3

Elaborado a partir do modelo lgico


Pode variar segundo o SGBD
Pode ter tabelas fsicas
Pode ter colunas fsicas

Relacionamentos
As tabelas podem ser relacionadas para compor uma consulta de informaes, desde que a chave
primria de uma seja uma coluna da outra, onde ser chamada de chave estrangeira. No modelo lgico,
este relacionamento pode se dar de trs formas:
A chave primria da primeira chave estrangeira na segunda tabela, de forma que podem haver
diversas ocorrncias de registros da primeira tabela na segunda, mas para cada linha da segunda
tabela s existir uma linha correspondente na primeira. Chamamos isto de cardinalidade um para
ene (1:n). Por exemplo, uma tabela de clientes com o cdigo do cliente e o nome, pode ser
relacionada com uma outra tabela de telefones contendo o cdigo do telefone, o cdigo do cliente e o
nmero do telefone.
As chaves primrias de duas tabelas podem formar uma terceira tabela, criando uma nova entidade
chamada de relacionamento. Assim, diversas linhas da primeira tabela podem se relacionar com
outras linhas da segunda, em uma cardinalidade ene para eme (n:m). Por exemplo, uma tabela de
disciplinas, com o cdigo da matria e nome, pode se relacionar com uma tabela de alunos, com
cdigo do aluno e nome, atravs de uma terceira tabela de matrculas com os dois cdigos. Um aluno
pode se matricular em diversas matrias e uma matria pode ter vrios alunos.
A chave primria de uma tabela pode compor duas colunas de uma tabela de relacionamento,
formando uma auto-relacionamento. Por exemplo, uma tabela de empregados pode se relacionar
com ela mesmo atravs de uma tabela de chefia, com o cdigo do empregado na coluna subordinado
e de outro empregado, como chefe do primeiro, na coluna superior.

9.2.4

Transao
Conjunto de procedimentos que executado num banco de dados, que para o usurio visto como uma
nica ao. A integridade de uma transao depende de 4 propriedades, conhecidas como ACID.
Atomicidade - Todas as aes que compem a unidade de trabalho da transao devem ser
concludas com sucesso, para que seja efetivada. Qualquer ao que constitui falha na unidade de
trabalho e a transao deve ser desfeita (rollback). Quando todas as aes so efetuadas com
sucesso, a transao pode ser efetivada (commit).

http://www.macoratti.net/cbmd1.htm
94
51

TI para concursos

Consistncia - Nenhuma operao do banco de dados de uma transao pode ser parcial. O status
de uma transao deve ser implementado na ntegra. Por exemplo, um pagamento de conta no
pode ser efetivado se o processo que debita o valor da conta corrente do usurio no for efetivado
antes, nem vice-versa.
Isolamento - Cada transao funciona completamente parte de outras estaes. Todas as
operaes so parte de uma transao nica. O principio que nenhuma outra transao, operando
no mesmo sistema, pode interferir no funcionamento da transao corrente ( um mecanismo de
controle). Outras transaes no podem visualizar os resultados parciais das operaes de uma
transao em andamento.
Durabilidade - Os resultados de uma transao so permanentes e podem ser desfeitos somente por
uma transao subseqente.
Controle de concorrncia um mtodo usado para garantir que as transaes so executadas de uma
forma segura e segue as regras ACID. Os SGBD devem ser capazes de assegurar que nenhuma ao
de transaes completadas com sucesso (committed transactions) seja perdida ao desfazer transaes
abortadas (rollback). Uma transao uma unidade que preserva consistncia.

9.3

Modelo Entidade Relacionamento


Modelo de Entidades e Relacionamentos um modelo abstrato cuja finalidade descrever, de maneira
conceitual, os dados a serem utilizados em um Sistema de Informaes ou que pertencem a um
domnio. A principal ferramenta do modelo sua representao grfica, o Diagrama Entidade
52
Relacionamento. Normalmente o modelo e o diagrama so conhecidos por suas siglas: MER e DER.
Existem muitas notaes para Diagrama de Entidades e Relacionamentos. A notao original foi
proposta por Chen e composta de entidades (retngulos), relacionamentos (losangos), atributos
(crculos) e linhas de conexo (linhas) que indicam a cardinalidade de uma entidade em um
relacionamento. Chen ainda prope smbolos para entidades fracas e entidades associativas.
Toda a notao moderna tem como caracterstica importante definir a cardinalidade mnima e mxima
em uma relao, no utilizar um smbolo especial para relacionamentos, mas sim a linha, e descrever
atributos dentro do smbolo de entidades.
Diagrama entidade relacionamento um modelo diagramtico que descreve o modelo de dados de um
sistema com alto nvel de abstrao. Ele a principal representao do Modelo de Entidades e
Relacionamentos. usado para representar o modelo conceitual do negcio.
Uma relao entre duas tabelas chamada de binria, trs tabelas de ternria, enquanto que um autorelacionamento, em que uma entidade se relaciona com ela mesma, tambm chamado de relao
unria.
Os tipos de relaes utilizadas neste diagrama so:
Relao 1..1 (l-se relao um para um) - indica que as tabelas tm relao unvoca entre si. Voc
escolhe qual tabela vai receber a chave estrangeira;
Relao 1..n (l-se um para muitos) - a chave primria da tabela que tem o lado 1 vai para a tabela
do lado N. No lado N ela chamada de chave estrangeira;
Relao n..n (l-se muitos para muitos) - quando tabelas tm entre si relao n..n, necessrio criar
uma nova tabela com as chaves primrias das tabelas envolvidas, ficando assim uma chave
composta, ou seja, formada por diversos campos-chave de outras tabelas. A relao ento se reduz
para uma relao 1..n, sendo que o lado n ficar com a nova tabela criada.

9.4

Modelagem de Dados Multidimensional


Na modelagem multidimensional os dados so de-normalizados e estruturados em diversas
53
dimenses.
A finalidade de bases de dados multidimensionais (alguns autores chamam de dimensionais) fornecer
subsdio para realizao de anlises. Para tanto, sua arquitetura e terminologia empregada so distintas
das utilizadas para bancos de dados transacionais. O fato de existirem diversas informaes a serem
cruzadas (dimenses) permite a realizao de pesquisas.
As anlises sobre dados histricos envolvem uma srie de possibilidades de cruzamentos e
agrupamentos de informaes, com o uso dos seguintes termos:
Dimenses: estabelecem a organizao dos dados, determinando possveis consultas/cruzamentos.
Por exemplo: regio, tempo, canal de venda,... Cada dimenso pode ainda ter seus elementos,
chamados membros, organizados em diferentes nveis hierrquicos. A dimenso tempo, por exemplo,
pode possuir duas hierarquias: calendrio gregoriano (com os nveis ano, ms e dia) e calendrio
fiscal (com os nveis ano, semana e dia);

http://pt.wikipedia.org/wiki/Modelo_de_Entidades_e_Relacionamentos
http://pt.wikipedia.org/wiki/Modelagem_multidimensional
95
52
53

TI para concursos

Medidas: so os valores a serem analisados, como mdias, totais e quantidades;


Fatos: so os dados a serem agrupados, contendo os valores de cada medida para cada combinao
das dimenses existentes. O tamanho da tabela que contm os fatos merece ateno especial do
analista;
Agregaes: totalizaes calculadas nos diversos nveis hierrquicos.
Esta forma de armazenamento conhecida como ROLAP, ou Relational OLAP. Uma vez que os dados
j se encontram em um modelo apropriado, chamado multidimensional, basta processar as agregaes.
Com isso obtm-se ganho de espao de armazenamento, uma vez que os dados permanecem apenas
na base de origem (multidimensional), embora a criao de grandes quantidades de agregaes possa
incorrer em exploso de dados.
Outra forma de armazenamento, cujo modelo matemtico denomina-se hipercubos, apresenta a
caracterstica de possuir armazenamento e indexao em estruturas de dados que otimizam consultas
ao invs de atualizaes. Esta forma erroneamente chamada MOLAP, ou Multidimensional OLAP. O
erro est no fato de que bases ROLAP tambm so multidimensionais.
Quando o modelo multidimensional processado, nova base gerada, desta vez contendo tanto os
dados quanto as agregaes em formato prprio, utilizando-se de estruturas apropriadas para
pesquisas.
Aplicaes analticas possuem peculiaridades tais como manipulao de grandes volumes de dados e
baixa taxa de atualizao. Essas caractersticas favorecem este modelo estrutural, mais rpido. Por
exemplo, Business Intelligence (BI) um processo de gerenciamento de informaes que pode ser
obtido por qualquer artefato, seja tecnolgico ou no, que permita a extrao de conhecimento a partir
de anlises do negcio. A efetividade destas anlises ser maior se os dados estiverem disponveis de
modo consistente e, preferencialmente, consolidado. 54
Solues informatizadas de BI geralmente contm sistemas analticos, que podem ser de diversos tipos,
dependendo do objetivo das anlises e do perfil do usurio:
Decision Support Systems (DSS), ou Sistemas de Apoio a Deciso (SAD): so baseados em
relatrios analticos, normalmente utilizados por usurios de nvel operacional;
Management Information Systems (MIS), ou Sistemas de Informaes Gerenciais (SIG): permitem
anlises mais profundas, com a realizao de simulaes de cenrios. So utilizados por analistas de
negcio no nvel ttico;
Executive Information Systems (EIS), ou Sistemas de Informaes Executivas (SIE): so voltados
para profissionais que atuam no nvel estratgico das empresas, como diretores e presidncia.
Oferecem, para tanto, um conjunto de indicadores chave de desempenho (KPI, ou Key Performance
Indicators).
A Microsoft desenvolveu uma ferramenta em SQL Server, o MDX (Multidimensional Expressions),
que permite que voc consulte objetos multidimensionais, como cubos, e retorna conjuntos de clulas
multidimensionais que contm dados do cubo.

9.4.1

Sistemas Transacionais X Sistemas Analticos


Sistemas transacionais, tambm conhecidos como sintticos ou ainda OLTP Online Transactional
Processing - so baseiados em transaes. Por exemplo, Sistemas Contbeis, Aplicaes de Cadastro,
Sistemas de Compra, Estoque, Inventrio, ERPs, CRMs etc.
Os sistemas transacionais se caracterizam pela alta taxa de atualizao, grande volumes de dados e
acessos pontuais, ou seja, pesquisas cujo resultado seja de pequeno volume.
J os sistemas analticos, ou OLAP Online Analytical Processing se caracterizam por fornecer
subsdio para tomadas de deciso, a partir de anlises realizadas sobre bases de dados histricas, por
vezes com milhes de registros a serem totalizados. As atualizaes no precisam ser to freqentes.
As anlises geralmente agrupam informaes, sendo tais agrupamentos mais importantes neste
contexto do que os dados detalhados.
As ferramentas OLAP (do ingls, Online Analytical Processing) so geralmente desenvolvidas para
trabalhar com banco de dados denormalizados, embora existam ferramentas que trabalham com
esquemas especiais de armazenamento, com dados (informaes) normalizados.55
Essas ferramentas so capazes de navegar pelos dados de um Data Warehouse, possuindo uma
estrutura adequada tanto para a realizao de pesquisas como para a apresentao de informaes.
Nas ferramentas de navegao OLAP, possvel navegar entre diferentes nveis de granularidades
(detalhamento) de um cubo de dados. Atravs de um processo chamado Drill o usurio pode aumentar
(Drill down) ou diminuir (Drill up) o nvel de detalhamento dos dados. Por exemplo, se um relatrio estiver
consolidado por pases, fazendo um Drill down, os dados passaro a ser apresentados por Estados,

http://msdn.microsoft.com/pt-br/library/cc518031.aspx
http://pt.wikipedia.org/wiki/OLAP
96
54
55

TI para concursos

cidades, bairros e assim sucessivamente at o menor nvel de detalhamento possvel. O processo


contrrio, o Drill up, faz com que os dados sejam consolidados em nveis superiores de informao.
Outra possibilidade apresentada pela maioria das ferramentas de navegao OLAP o recurso
chamado Slice and dice. Esse recurso usado para criar vises dos dados por meio de sua
reorganizao, de forma que eles possam ser examinados sob diferentes perspectivas.

9.5

Conceitos de Datawarehouse e ETL


Um Data Warehouse uma base de dados, geralmente relacional, que consolida as informaes
empresariais. Sua construo um processo normalmente moroso e complexo, por diversos fatores,
dentre os quais a grande quantidade de dados, diversas fontes de informaes com bases heterogneas
e muitas vezes inconsistentes, envolvimento de vrias reas ou departamentos da empresa. Um dos
maiores desafios na construo do DW a extrao e consolidao dos dados operacionais, pois:

Pode haver vrias fontes;


Os dados precisam ser limpos;
A granularidade precisa ser ajustada;
Pode ser necessrio resumir dados;
Deve haver valores default e tratamento de NULL;
necessrio componente temporal;
Os relacionamentos nos dados de entrada precisam ser claros.

Algumas situaes comuns entre as fontes de dados:

Mesmos dados, nomes diferentes;


Dados diferentes, mesmo nome;
Dados exclusivos de uma aplicao;
Chaves diferentes, mesmos dados.

Como mtodos de construo, existem formalmente dois:


Top-down, no qual realizada a modelagem integral do DW, seguida pelas extraes de dados. A
principal vantagem a criao de um modelo nico. O revs fica por conta do maior tempo de
projeto;
Bottom-up, onde o foco em uma rea por vez, com o crescimento gradual do DW. A vantagem a
obteno de resultados a intervalos mais curtos, garantindo muitas vezes sustentao ao projeto. A
desvantagem a maior dificuldade de se consolidar informaes entre as diversas reas.
Uma alternativa s estratgias acima, denominada Middle-out, aproveitar as vantagens de cada uma
por meio do desenvolvimento iterativo do DW:
O modelo de dados corporativo o primeiro a ser desenvolvido e o responsvel pela integrao dos
demais;
As primeiras tabelas da rea de interesse escolhida so povoadas: primeiras anlises;
Povoamento de mais tabelas com dados histricos;
Alguns dados passam a compor o DW, saindo da base operacional;
Surgimento dos data marts (a seguir nesta seo);
O ciclo se repete at que o DW esteja completo. Bases de produo contm apenas dados operacionais.

Outro fator crtico para o sucesso de um DW o gerenciamento do volume. Embora o conceito de DW


se aplique a grandes quantidades de dados, chegando atualmente a ordem de TB, sua capacidade no
infinita, devendo ser utilizada sabiamente. Apenas dados relevantes deveriam constar do DW. Pode
ser que o horrio de uma determinada transao seja importante quando o foco for o curto prazo, mas
que apenas um contexto de agrupamento seja suficiente para dados de cinco anos atrs. Questes
como essa devem ser consideradas durante o planejamento do DW, pois ajudam a dimension-lo.
A remoo de dados do DW um assunto tratado com receio pelos DBAs e pelos analistas de negcio.
A rigor, to importante quanto saber que dados armazenar, saber quando e quais dados remover do
DW. Algumas estratgias so:
Resumir dados mais antigos;
Armazenar os dados antigos em meio mais barato (fita);
Remover os dados do DW.
Tais estratgias no so excludentes, podendo ser utilizadas em conjunto.
A importncia da remoo de dados est em manter o DW o mais enxuto possvel, embora isso possa
parecer contraditrio ao conceito de DW.
Com relao granularidade, as bases de dados operacionais trabalham com o maior nvel de detalhe
possvel, ou seja, a maior granularidade. J no DW pode haver diversos graus de agregao e resumo
dos dados. Por exemplo, os dados do ano corrente podem ser detalhados por item de pedidos, de um a
cinco anos, por total de cada pedido e, aps isso, por total de pedidos por dia. A correta determinao da
granularidade exerce papel fundamental no planejamento de capacidade e desempenho do DW.
Ao contrrio do que ocorre com as bases operacionais, o DW, por conter dados histricos, no demanda
alta taxa de atualizao. Desse modo, pode ser atualizado a cada 24 horas ou at mesmo uma vez por
97

TI para concursos

semana. Alm disso, por sofrer poucas modificaes, e de forma controlada (por aplicaes especficas
para esse fim), seus relacionamentos podem ser implementados atravs de entidades, embora isso no
seja freqente.
Data Marts (DM), so bancos de dados multidimensionais especficos por rea de negcio para
realizao de anlises. Alguns conceitos sobre Data Marts no esto muito bem claros para o mercado.

Um DW construdo iterativamente possui pores agrupadas por segmento de negcio, regio ou


qualquer outra forma que seja adequada empresa. Essas pores alimentam os Data Marts, que
podem ser ento consultados por ferramentas de anlise.

9.5.1

ETL
Extract, Transform and Load (Extrao, Transformao e Carga) so ferramentas de software cuja
funo a extrao de dados de diversos sistemas, transformao desses dados conforme regras de
negcios e carga dos dados em um data mart ou um data warehouse. considerada uma das fases
mais crticas 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 flat files (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 organizao. Essa pode ser uma tarefa no trivial, e muitas fontes de dados podem
no ser acessadas muito facilmente.
Existem ferramentas ETL, mas ETL no so ferramentas, mas sim uma metodologia.

9.6

Conceitos de desenvolvimento em banco de dados SQL Server e Oracle

9.6.1

SQL
Structured Query Language, ou Linguagem de Consulta Estruturada ou SQL, uma linguagem de
pesquisa declarativa para banco de dados relacional (base de dados relacional). Muitas das
caractersticas originais do SQL foram inspiradas na lgebra relacional.56
Uma consulta SQL especifica a forma do resultado e no o caminho para chegar a ele. Padronizado pela
ANSI e ISO, possui muitas variaes e extenses produzidos pelos diferentes fabricantes de sistemas
gerenciadores de bases de dados. Tipicamente a linguagem pode ser migrada de plataforma para
plataforma sem mudanas estruturais principais.
O padro do SQL (ANSI) utiliza operadores, funes de agregao e comandos, que dividem-se em
cinco subconjuntos. Os comandos podem ser escritos e executados por linhas de comando dentro de
algum aplicativo do prprio gerenciador de banco de dados, por lotes de comandos definidos dentro do
banco de dados (procedures) ou lotes de comandos por qualquer aplicativo com conexo com o banco
de dados.
A Microsoft oferece o MS SQL Server e a Oracle seu gerenciador de banco de dados de mesmo nome
obedecendo aos padres ANSI e adicionando mais recursos para administrao eficiente de dados.

9.6.1.1

DML - Linguagem de Manipulao de Dados


A DML (Data Manipulation Language) um subconjunto da linguagem usada para inserir, atualizar e
apagar dados.
INSERT - insere registros (linhas ou tuplas)

http://pt.wikipedia.org/wiki/SQL
98
56

TI para concursos

UPDATE - altera valores de dados


DELETE - remove linhas (registros ou tuplas)
9.6.1.2

DDL - Linguagem de Definio de Dados


DDL (Data Definition Language) permite definir tabelas e elementos associados.
CREATE - cria um objeto (tabela, index, view etc.) dentro da base de dados.
DROP - apaga um objeto do banco de dados
ALTER TABLE - altera a estrutura de uma tabela, no aceito por todos os gerenciadores de banco
de dados

9.6.1.3

DCL - Linguagem de Controle de Dados


DCL (Data Control Language) controla os usurios e direitos de acesso aos objetos dentro do banco de
dados.
GRANT - autoriza ao usurio executar ou setar operaes.
REVOKE - remove ou restringe a capacidade de um usurio de executar operaes.
ALTER PASSWORD - altera senha
CREATE SYNONYM - cria sinnimos, nomes alternativos para os objetos

9.6.1.4

DTL - Linguagem de Transao de Dados


DTL (Data Transaction Language) define blocos de comandos transaes que podem ser efetivados
ou no.
BEGIN WORK (ou START TRANSACTION) - usado para marcar o comeo de uma transao.
COMMIT - confirma todas as aes, desde o comando begin, permanentemente.
ROLLBACK faz com que os comandos de mudanas nos dados sejam descartados.
COMMIT e ROLLBACK interagem com reas de controle como transao e locao. Ambos terminam
qualquer transao aberta e liberam qualquer bloqueio ligado a dados. Na ausncia de um BEGIN
WORK ou uma declarao semelhante, a semntica de SQL dependente da implementao.

9.6.1.5

DQL - Linguagem de Consulta de Dados


DQL (Data Query Langage) possui apenas um comando, para selecionar dados.
SELECT - especifica uma consulta ("query") como uma descrio do resultado desejado. Esse
comando composto de vrias clusulas e opes, possibilitando elaborar consultas das mais
simples s mais elaboradas.
As clusulas so condies de modificao utilizadas para definir os dados que deseja selecionar ou
modificar em uma consulta.
FROM - Utilizada para especificar a tabela que se vai selecionar os registros.
WHERE Utilizada para criar uma restrio, isto , especificar as condies que devem reunir os
registros que sero selecionados.
GROUP BY Utilizada para separar os registros selecionados em grupos especficos.
HAVING Utilizada para expressar a condio que deve satisfazer cada grupo, criar uma restrio para o
grupo.
ORDER BY Utilizada para ordenar os registros selecionados com uma ordem especifica.
DISTINCT Utilizada para selecionar dados sem repetio.
JOIN utilizada para criar junes entre a tabelas, criando restries ou atendendo a critrios, e
permitindo a seleo de colunas das tabelas envolvidas. O join pode ser definido de diversas formas:
Sem a utilizao da clusula join, colocando os nomes das tabela logo depois da clausula from
separados por vrgulas, e com uma restrio de relacionamento aps a clusula where.

9.6.1.6

Operadores Lgicos
Operadores lgicos relacionam elementos de uma expresso lgica.
AND Avalia os termos e devolve um valor verdadeiro caso ambos sejam corretos.
OR Avalia termos e devolve um valor verdadeiro se algum for correto.
NOT Devolve o valor contrrio da expresso.

9.6.1.7

Operadores Relacionais
Os operadores estabelecem critrios para uma expresso lgica.
<
Menor que
>
Maior que

99

TI para concursos

<>
Diferente de
<=
Menor ou Igual que
>=
Maior ou Igual que
=
Igual a
BETWEEN Utilizado para especificar um intervalo de valores.
LIKE Utilizado na comparao de um modelo e para especificar registros de um banco de
dados."Like" + extenso % vai significar buscar todos resultados com o mesmo incio da extenso.

9.6.1.8

Funes de Agregao
As funes de agregao, dentro de uma clusula SELECT com clusula GROUP BY, devolve valores
agregados de um grupo de registros.
AVG calcular a mdia dos valores de um campo numrico determinado.
COUNT
devolve o nmero de registros da seleo.
SUM devolve a soma de todos os valores de um campo numrico determinado.
MAX devolve o valor mais alto de um campo especificado.
MIN devolve o valor mais baixo de um campo especificado.

9.6.1.9

Conjuntos de dados
Os dados de uma ou mais tabelas podem ser agrupados em um nico conjunto de dados atravs de
operaes de seleo (select) de diversos tipos:
Juno dois conjuntos de dados so concatenados de acordo com uma determinada condio de
relao e seleo.
Restrio condio que limita a seleo das linhas de uma relao.
Projeo uma ou mais colunas de uma relao so selecionadas formando um subconjunto vertical.
Unio so selecionadas todas as linhas que aparecem em ambas as relaes
Interseco so selecionadas apenas aquelas linhas que existem em ambos os conjuntos.

9.6.1.10 Componentes de um banco de dados


Um banco de dados pode apresentar mais do que tabelas e dados em sua estrutura. Pode possuir
mdulos programados e objetos que melhoram a manipulao dos dados.
Tabelas modelo abstrato de armazenamento de dados em forma de registros e campos em banco
de dados relacional. Cada tabela armazena informaes de uma entidade modelada do banco de
dados.
Views - ajuda a encapsular uma consulta em uma entidade relacional e facilita a viso de um dado de
uma ou mais tabelas em um banco de dados.
Restrio - define regras a respeito de valores permitidos em colunas e um mecanismo que executa
a integridade de dados
ndices - oferece rpido acesso ao dado de uma tabela baseado em valores classificados em ordem
crescente ou decrescente. A chave primria de uma tabela automaticamente indexada.
Funes - pedao de cdigo que opera como uma unidade lgica. Uma funo pode retornar tanto
uma tabela quanto um valor escalar. Qualquer cdigo que deve executar a lgica incorporada em
uma funo pode chamar a funo, em vez de repetir a funo lgica.
Procedimento (Procedure) lote (texto) de comandos (cdigo) armazenado no banco de dados.
Gatilho (Trigger) - procedimento que executado quando ocorre um evento qualquer previsto para
um registro, campo ou para a prpria tabela.

9.6.2

Arquitetura de um Servidor Oracle


Um banco de dados Oracle composto por uma ou mais tablespaces. Uma tablespace contm um ou
mais arquivos no nvel de sistema operacional. Cada tablespace pode ter um ou mais segmentos. Um
segmento adicionado na tablespace quando uma tabela ou um ndice criado, ou seja, um segmento
associado a cada objeto de banco de dados. possvel que um objeto seja atribudo a mais de um
segmento, mas, para isso, o usurio dever particionar explicitamente o objeto. Vrias tabelas ou ndices
podem ser includos em um mesmo segmento atravs da criao de um objeto conhecido como cluster.
A medida que um objeto de banco de dados necessita de mais espao, necessrio que o segmento
aloque mais dados. O banco de dados procura, nos arquivos do tablespace, reas contguas de tamanho
pr-determinado para o armazenamento de novos dados. Essa rea contgua conhecida como
extenso (extent), que por sua vez formada por diversos blocos de banco de dados. Cada bloco de
banco de dados possui um tamanho fixo determinado nos parmetros de configurao, esse tamanho

100

TI para concursos

fixo deve ser mltiplo do tamanho de um bloco do nvel do sistema operacional. O tamanho extent
tambm pode ser configurado pelo usurio ou determinado automaticamente pelo Oracle.
A criao de um banco de dados pode ser realizada atravs de uma ferramenta grfica conhecida como
Database Configuration Assistant. Com essa ferramenta tambm possvel configurar opes de um
banco de dados existente, deletar um banco de dados e gerenciar gabaritos de banco de dados.
Os tipos de usurios (papis) variam de acordo com o lugar, mas podem ser divididos em
administadores de banco de dados, responsveis pela segurana, administradores de rede,
desenvolvedores de aplicao, administradores de aplicao e usurios do banco de dados.
PL/SQL (Procedural Language/SQL) uma extenso da linguagem padro SQL para o Oracle. Permite
que a manipulao de dados seja includa em unidades de programas. Blocos de PL/SQL so passados
e processados por uma PL/SQL Engine que pode estar dentro de uma ferramenta Oracle ou do Server.
A PL/SQL Engine filtra os comandos SQL e manda individualmente o comando SQL para o SQL
Statement Executor no Oracle Server, que processa o PL/SQL com os dados retornados do Server. a
linguagem bsica para criar programas complexos e poderosos, no s no banco de dados, mas
57
tambm em diversas ferramentas Oracle.
A unidade bsica em PL/SQL um bloco. Todos os programas em PL/SQL so compostos por blocos,
que podem estar localizados uns dentro dos outros. Geralmente, cada bloco efetua uma ao lgica no
programa. Um bloco tem basicamente a seguinte estrutura:
DECLARE
Seo (opcional) para declarao de variveis,tipos e subprogramas locais.
BEGIN
Seo Executvel, nesta seo ficam as instrues procedurais e SQL. Esta a nica seo do bloco que indispensvel e obrigatria.
EXCEPTION
Seo/Setor (opcional) onde ficam as instrues de tratamento de erro.
END

9.6.3

Arquitetura de um Servidor SQL Server


Um banco de dados no SQL Server 2005 se refere a um grupamento fsico de um conjunto de objetos de
esquema de um banco de dados em um ou mais arquivos fsicos. Os bancos de dados podem ser
classificados como bancos de dados de sistemas e bancos de dados dos usurios. Os banco de dados
de sistema armazenam dados do sistema e tambm controlam o armazenamento temporrio requerido
para os dados de aplicao.
Cada instncia do SQL Server pode suportar vrios bancos de dados. Alm disso, pode haver vrias
instncias em um mesmo computador. Cada banco de dados pode suportar grupos de arquivos
(filegroups), que provem a funcionalidade de distribuir os dados fisicamente. Um banco de dados pode
possuir vrios filegroups, mas o contrrio no possvel. Aps a criao do banco de dados, os
filegroups do banco de dados podem ser adicionados.
O SQL Server utiliza a unidade bsica de IO fixo (pgina) em 8KB. Para organizar melhor os dados,
essas pginas so agrupadas em uma quantidade de oito contguas entre si formando as chamadas
extenses (extents). O espao gerenciado em termos de extenses. Cada pgina pertence a um objeto
de um tipo (dado, ndice etc), mas uma extenso pode pertencer a vrios objetos.
Uma extenso em que as oito pginas pertencem ao mesmo objeto considerada uma extenso
uniforme, caso contrrio, trata-se de uma extenso mista.
O SQL Server utiliza os filegroups para controlar a alocao das tabelas e dos ndices. Os dados
contidos em filegroup so proporcionalmente distribudos entre os arquivos do filegroup. Se os filegroups
no estiverem definidos, os objetos do banco de dados sero armazenados em um filegroup padro que
implicitamente definido durante a criao do banco de dados.
Os segmentos utilizados no Oracle no so necessrios no SQL Server. Em vez disso, o SQL Server
distribui os dados atravs de RAID suportado em hardware ou software (soluo presente no Windows
ou em outro software).

http://pt.wikipedia.org/wiki/PL/SQL
101
57

TI para concursos

9.7

Exerccios
148. (ICMS-SP 2009) A arquitetura ANSI/SPARC aplicada aos bancos de dados divide-os em nveis com as
seguintes caractersticas:
I. O que se ocupa do modo como os dados so fisicamente armazenados.
II. O que se ocupa do modo como os dados so vistos por usurios individuais.
III. Nvel lgico de comunidade ou apenas lgico (mais abstrato que o fsico e diferente da viso do usurio
individual).
148
Em um projeto arquitetural, os itens I, II e III so classificados, respectivamente, como nveis
(a) externo, conceitual e interno.
(b) externo, interno e conceitual.
(c) interno, externo e conceitual.xx
(d) interno, conceitual e externo.
(e) conceitual, externo e interno.
149. (ICMS-SP 2009) A independncia de dados fsica e a independncia de dados lgica so possibilitadas de
forma ideal, respectivamente, por um149
(a) ou mais mapeamentos conceituais/internos e por um ou mais mapeamentos internos/externos.
(b) mapeamento conceitual/interno e por um ou mais mapeamentos externos/conceituais. xx
(c) mapeamento interno/externo e por um mapeamento conceitual/interno.
(d) ou mais mapeamentos internos/externos e por um mapeamento conceitual/interno.
(e) mapeamento conceitual/externo e por um mais mapeamentos conceituais/internos.
150. (ICMS-SP 2009) O procedimento em que se aplicam os ajustes apropriados na organizao do sistema de
banco de dados, principalmente na ocorrncia das mudanas de requisitos, visando manuteno constante
do melhor desempenho para a empresa, denominado150
(a) schema.
(b) dumping.
(c) mapping.
(d) restart.
(e) tuning.xx
151. (ICMS-SP 2009) No ambiente de desenvolvimento com SQL Server, uma sintaxe usada para definir objetos
multidimensionais, bem como para examinar e manipular dados multidimensionais, corresponde
linguagem151
xx
(a) MDX.
(b) RDL.
(c) WQL.
(d) XSL.
(e) SMDL.
152. (ICMS-SP 2009) Uma assinatura criada e administrada pelo Publicador, com SQL Server, trata-se de uma
assinatura152
(a) pull.
xx
(b) push.
(c) annima.
(d) de cliente.
(e) de servidor.

102

TI para concursos

153. (ICMS-SP 2009) No SQL Server, uma nica dimenso de banco de dados unida tabela de fatos em uma
153
chave estrangeira diferente, para produzir vrias dimenses de cubo, denominada dimenso
(a) de fatos.
(b) de referncia.
(c) compartilhada.
xx
(d) com funo mltipla.
(e) muitos para muitos.
154. (ICMS-SP 2009) No formato de um bloco de dados do Oracle, um overhead uma referncia ao154
(a) Header.
(b) Space free.
(c) Table directory.
(d) Space free e Row data, coletivamente.
xx
(e) Header, Table directory e Row directory, coletivamente.
155. (ICMS-SP 2009) NO um conjunto de extenses do Oracle que contm todos os dados para uma estrutura
lgica de armazenamento dentro de uma tablespace:155
(a) Automatic Undo Management.
xx
(b) Automatic Storage Management.
(c) Temporary Segments.
(d) Index Segments.
(e) Data Segments.
156. (ICMS-SP 2009) Um database Oracle constitudo de um ou mais156
(a) datafiles, estruturas fsicas de armazenamento, e cada datafile consiste de um ou mais tablespaces,
unidades lgicas de armazenamento.
(b) datafiles, unidades lgicas de armazenamento, e cada datafile consiste de um ou mais tablespaces,
estruturas fsicas de armazenamento.
(c) tablespaces, unidades lgicas de armazenamento, e cada tablespace consiste de um ou mais datafiles,
estruturas fsicas de armazenamento. xx
(d) tablespaces, estruturas fsicas de armazenamento, e cada tablespace consiste de um ou mais datafiles,
unidades lgicas de armazenamento.
(e) tablespaces, unidades lgicas de armazenamento, e cada tablespace consiste de um ou mais datafiles,
tambm unidades lgicas de armazenamento.
157. (ICMS-SP 2009) Considere a seguinte regra de Codd, aplicada aos bancos de dados relacionais:
A descrio do banco de dados representada no nvel lgico da mesma forma que os dados ordinrios,
permitindo que usurios autorizados utilizem a mesma linguagem relacional aplicada aos dados regulares.
O sentido dessa regra diz respeito 157
(a) formao do catlogo.xx
(b) manipulao, por meio de vises.
(c) independncia fsica.
(d) independncia lgica.
(e) independncia de distribuio.
158. (ICMS-SP 2009) Considere a afirmativa a seguir.
Uma tabela est na I , se e somente se ela estiver na II e os atributos no-chave forem III .
I, II e III podem ser corretamente preenchidos por:158
(a) FNBC, 1FN, totalmente dependentes da totalidade da chave primria
(b) 3FN, 2FN, independentes da chave primria
(c) 3FN, 1FN, totalmente dependentes de parte da chave primria
(d) 2FN, 1FN, totalmente dependentes de parte da chave primria
(e) 2FN, 1FN, totalmente dependentes da totalidade da chave primriaxx
159. (ICMS-SP 2009) Considere a relao 1:N entre cliente e seus pedidos e a necessidade de excluso de um
determinado cliente. A fim de manter informaes histricas sobre pedidos j efetuados, independentemente
da existncia do cliente que os fez, deseja-se que aqueles pedidos j efetuados pelo cliente excludo no
sejam apagados. As chaves primrias de ambas e em cada tabela so definidas como nica. Em um banco de
159
dados relacional normalizado at a 3FN, o atendimento de tal requisito pode ser obtido por meio de
(a) restrio de chave estrangeira on delete set null. xx
(b) colocao de uma constante (ex. 9999) nas chaves primrias dos pedidos do cliente excludo.
(c) colocao de uma constante (ex. 9999) nas chaves primrias de cada cliente excludo.
(d) no limpeza das chaves estrangeiras dos pedidos, existentes na tabela do cliente.
(e) restrio de chave estrangeira on delete cascade.

103

TI para concursos

160. (ICMS-SP 2009) Em um banco de dados multidimensional, considere, por exemplo, que os dados podem ser
representados como um array de trs dimenses, correspondendo a produtos, clientes e perodos de tempo.
Dessa forma, um determinado valor individual em uma clula pode representar a quantidade de um produto
160
vendido a um cliente em um dado momento. De acordo com essa considerao,
(a) produtos e clientes so variveis independentes, e perodos de tempo e quantidade so variveis
dependentes.
(b) produtos, clientes e perodos de tempo so variveis dependentes, e quantidade uma varivel
independente.
(c) produtos, clientes e perodos de tempo so variveis independentes, e quantidade uma varivel
xx
dependente.
(d) produtos so variveis dependentes, e clientes, perodos de tempo e quantidade so variveis
independentes.
(e) produtos so variveis independentes, e clientes, perodos de tempo e quantidade so variveis
dependentes.
161. (ICMS-SP 2009) As variveis dimensionais aplicadas em um MOLAP esto frequentemente relacionadas em
hierarquias, que determinam meios para agregar dados das clulas a elas associados. Nesse contexto, os
operadores do processador que permitem percorrer (para acesso e no para criao) as hierarquias do nvel
de agregao mais baixo para o mais alto executam a funo161
(a) snow flake.
(b) roll back.
(c) drill down.
(d) rolap.
xx
(e) drill up.
162. (ICMS-SP 2009) Se uma empresa de grande porte, com alto volume de transaes e informaes, resolver
iniciar um projeto usando o conceito de Data Mart (DM) em vez de Data Warehouse (DW), independentemente
disso ser ou no a melhor opo, os fatores que a levam a tal deciso podem ser justificados por:
I. Possibilidade de extrair e preparar os dados diretamente de fontes de interesse especficas, fornecendo
acesso mais rpido pela no necessidade de sincronia com dados de outras fontes.
II. Menor risco quanto ao sucesso do projeto.
III. Necessidade imediata de informaes organizacionais integradas.
Est correto o que consta em162
(a) I, apenas.
(b) I e II, apenas.xx
(c) I e III, apenas.
(d) I, II e III.
(e) II e III, apenas.
163. O grande desafio do profissional de TI que gerencia qualquer processo a anlise dos fatos relacionados
funo que exerce em uma organizao. Essa anlise deve ser feita com as ferramentas e os dados
disponveis, permitindo aos executivos e gerentes detectar as tendncias e tomar as decises com eficincia e
eficcia. Devido a essa necessidade, surgiu o conceito de Business Intelligence BI.
Assinale a alternativa que indique duas caractersticas dos atuais sistemas de Business Intelligence.163
(a) procurar relaes de causa e efeito / extrair e integrar dados de mltiplas fontes. xx
(b) evitar a utilizao de ferramentas automatizadas / desprezar dados contextualizados.
(c) extrair e integrar dados de mltiplas fontes / evitar a utilizao de ferramentas automatizadas.
(d) desprezar dados contextualizados / trabalhar exclusivamente com fatos reais e no hipotticos.
(e) trabalhar exclusivamente com fatos reais e no hipotticos / procurar relaes de causa e efeito.
164. (TRT FCC 2008) No mbito do OLAP, grficos de produtos so generalizaes da estrutura de ......
apresentada por HRU (Harinarayan, Rajaraman e Ullman), na qual as dimenses podem ter hierarquias
associadas. Preenche corretamente a lacuna: 164
(a) tabela.
(b) roll-up.
(c) data mart.
xx
(d) hipercubo.
(e) drill-down.
165. Uma das funcionalidades do OLAP, utilizada para realizar operaes de projeo nas dimenses, compreende
a extrao de informaes sumarizadas de um cubo de dados e extrao de um "subcubo", a partir do valor de
165
uma dimenso. Trata-se de
(a) sorting.
(b) pivot and sorting.
(c) drill-up.
(d) selection.
(e) slice and dice.xx
166. Para eliminar a condio de existncia de valores no atmicos em uma coluna de tabela relacional, 166
xx
(a) deve ser aplicada, no mnimo, a primeira Forma Normal.
(b) devem ser aplicadas, no mnimo, as quatorze regras de Codd.
(c) deve ser aplicada, no mnimo, a Forma Normal Boyce-Codd.
(d) deve ser aplicada, no mnimo, a terceira Forma Normal.
(e) devem ser aplicadas, no mnimo, as regras de integridade referencial.
104

TI para concursos

167. Um
(a)
(b)
(c)
(d)
(e)

banco de dados relacional normalizado significa que as relaes que o compe atendem
1FN, no mximo.
3FN, no mnimo.xx
2FN, mas no necessariamente 1FN.
2FN, no mximo.
3FN, mas no necessariamente a 1FN e 2FN.

167

168. Uma relao estar na Segunda Forma Normal (2FN) se ela estiver na 1FN e todos os atributos168
(a) no chave forem dependentes no transitivos da chave primria.
xx
(b) no chave forem totalmente dependentes da chave primria.
(c) chave forem dependentes no transitivos das chaves estrangeiras.
(d) chave forem totalmente dependentes das chaves estrangeiras.
(e) chave forem totalmente dependentes dos atributos no chave.
169. Em
(a)
(b)
(c)
(d)
(e)

169

um modelo E-R, o tipo de associao unria aquela em que


uma entidade se relaciona unicamente com uma outra entidade.
uma entidade se relaciona com ela prpria. xx
uma entidade no se relaciona com qualquer outra entidade, nem com ela prpria.
um relacionamento do tipo 1:1, somente.
um relacionamento do tipo 1:1 ou N:1.

170. Sobre um modelo E-R, considere que uma chave primria


I. simples pode ser constituda de um atributo atmico ou de um atributo composto.
II. simples pode ser constituda de apenas um atributo atmico.
III. composta pode ser constituda de um atributo composto.
IV. composta pode ser constituda de dois ou mais atributos atmicos.
170
Est correto o que consta APENAS em
(a) III e IV.
(b) II e III.
(c) II e IV.
(d) I e II.
(e) I e IV.xx
171. Um sistema de informao que fornece um arquivo para ser tratado pelo sistema objeto da modelagem,
utilizando DFD da anlise estruturada, caracterizado como171
(a) fluxo de dados.
(b) entidade externa.xx
(c) depsito de dados.
(d) processo funcional do sistema.
(e) processo do diagrama de contexto.
172. Na modelagem funcional172
(a) uma entidade externa pode enviar ou receber um fluxo de dados de uma funo.xx
(b) uma funo pode enviar, mas no receber um fluxo de dados de um depsito de dados.
(c) uma entidade externa representa a mesma coisa que uma entidade no modelo entidade relacionamento.
(d) uma entidade externa pode enviar, mas no receber um fluxo de dados de um depsito de dados.
(e) uma entidade externa pode receber, mas no enviar um fluxo de dados a um depsito de dados.
173. Quando dois conjuntos de dados so concatenados de acordo com uma determinada condio, representa o
resultado da operao relacional 173
xx
(a) juno.
(b) unio.
(c) restrio.
(d) projeo.
(e) interseco.
174. Um comando SQL executa uma operao que exibe
I. certas colunas de uma relao, denominada subconjunto vertical.
II. todas as linhas que aparecem em ambas as relaes.
III. apenas aquelas linhas que existem em ambos os conjuntos.
As definies acima correspondem, respectivamente, aos operadores relacionais 174
(a) unio, projeo e interseco.
(b) unio, interseco e projeo.
(c) interseco, projeo e unio.
(d) projeo, unio e interseco.xx
(e) projeo, interseco e unio.
175

175. A linguagem PL/SQL, introduzida nos gerenciadores de banco de dados ORACLE,


(a) aumenta a capacidade no-procedural da SQL, oferecendo e combinando blocos de construtores
xx
procedurais.
(b) constitui uma interface bsica pela qual pode-se entrar e executar comandos SQL para manipulaes
genricas de um banco.
(c) trata-se de uma linguagem que identifica quais as informaes necessrias e no como busc-las.
(d) tem os seus comandos executados pelo executor de SQL do Kernel.
(e) tem os seus comandos enviados para serem processados pelo SGBD um por vez.
105

TI para concursos

176. A linguagem PL/SQL uma estrutura em blocos, compostos basicamente das partes declarativa, executvel e
176
manipulao de excees, as quais so, respectivamente, de uso
(a) opcional, para todas as partes.
(b) obrigatrio, para todas as partes.
(c) opcional, obrigatrio e obrigatrio.
(d) obrigatrio, obrigatrio e opcional.
(e) opcional, obrigatrio e opcional.xx
177. Um
(a)
(b)
(c)
(d)
(e)

bloco PL/SQL que est associado a um evento ocorrido no banco de dados Oracle do tipo177
funo.
xx
gatilho.
annimo.
procedimento.
dinmico.

178. A estrutura lgica de armazenamento nas bases de dados Oracle representada na seqncia hierrquica de
178

(a)
(b)
(c)
(d)
(e)

segmentos, blocos de dados e extenses.


xx
segmentos, extenses e blocos de dados.
extenses, segmentos e blocos de dados.
extenses, blocos de dados e segmentos.
blocos de dados, segmentos e extenses.

179. Na estrutura lgica do Oracle NO esto contidos179


(a) extents.
(b) data blocks.
xx
(c) data files.
(d) schemas.
(e) tablespaces.
180. Todos os dados de uma tabela Oracle so armazenados em extents de um 180
xx
(a) data segment.
(b) index segment.
(c) temporary segment.
(d) rollback segment.
(e) redlog segment.
181. Quando um banco de dados Oracle iniciado, ser alocado para os processos background181
(a) um schema.
(b) um ou mais redo log files.
(c) um ou mais control files.
(d) uma tablespace.
(e) uma rea global de sistema.xx
182. As clusulas do comando de consulta da linguagem SQL devem ser escritas na seqncia 182
(a) SELECT, HAVING, FROM, WHERE, GROUP BY e ORDER BY.
(b) SELECT, HAVING, FROM, WHERE, ORDER BY e GROUP BY.
(c) SELECT, FROM, WHERE, ORDER BY, HAVING e GROUP BY.
(d) SELECT, FROM, WHERE, GROUP BY, HAVING e ORDER BY. xx
(e) SELECT, FROM, WHERE, GROUP BY, ORDER BY e HAVING.
183. Para mostrar a composio de peas e respectivos componentes (peas so compostas de peas), em um
183
DER, usa-se
(a) o grau de relacionamento quaternrio.
(b) a cardinalidade ternria.
(c) a entidade fraca.
(d) a entidade associativa.
(e) o auto-relacionamento.xx
184

184. Um relacionamento pode ser representado graficamente no diagrama de Entidade-Relacionamento por


(a) uma elipse.
(b) um retngulo.
(c) um crculo.
xx
(d) um losango.
(e) nmeros da cardinalidade.

185. Considere, as definies abaixo:


I. Especificao do nmero de ocorrncias de um objeto que pode ser relacionado ao nmero de ocorrncias
de outro objeto.
II. Especificao da participao (ou no) do relacionamento de um objeto em particular.
185
Na modelagem de dados estas definies pertencem, respectivamente, a
(a) grau e cardinalidade.
(b) cardinalidade e grau.
xx
(c) cardinalidade e modalidade.
(d) modalidade e cardinalidade.
(e) modalidade e grau.
106

TI para concursos

186. Em um banco de dados relacional, a operao de excluso sobre a tabela referenciada se propaga para todas
186
as chaves estrangeiras correspondentes quando usada a expresso SQL ANSI on delete
(a) set default.
(b) spread.
(c) propagate.
xx
(d) cascade.
(e) set null.
187. Uma transao executar qualquer operao somente depois que o gerenciador de banco de dados conceder
187
o bloqueio do dado por meio do
(a) gerenciador de arquivos.
(b) seletor de estratgia.
xx
(c) controlador de concorrncia.
(d) gerenciador de recuperao.
(e) gerenciador de buffer.

107

TI para concursos

10

Programao de Sistemas

10.1

Lgica de Programao
O computador, como todo componente eletrnico, s entende sinais de carga eltrica sequenciadas, um
choquinho aps o outro. Dividido em diversos tipos de componentes fsicos que se comportam de forma
diferente ao estmulo eltrico, pode-se determinar a ao de um equipamento eletrnico alterando-se o
sequenciamento destas peas pela ao de chaves (componentes eletrnicos) que desviam o fluxo de
energia. Esta definio da sequncia de chaves, que determina por onde e quando a corrente eltrica vai
passar resultando em um comportamento previsto do sistema eltrico, chamada de programao.
Os primeiros programadores definiam e alteravam estas chaves diretamente com fios em placas. A
evoluo permitiu que a programao pudesse ser feita por sequenciamento lgico de nmeros que
poderiam ser transferidos para os computadores atravs de cartes perfurados ou textos digitados que
alteravam o estado das chaves sem o programador ter que manusear o equipamento diretamente.
Programas pr-concebidos traduziam palavras (em ingls), textos inteligveis, em comandos em
linguagem da mquina (nmeros). Estes programas so os compiladores. Endereos de memria que
contm dados recebem nomes pelo programador (variveis). Programar passou, ento, a ser redigir um
texto obedecendo certas regras de sintaxe, submeter o texto a um compilador que faz a traduo para a
linguagem que a mquina consegue processar.
Por certo tempo, programao consistia em sequenciar comandos e atribuir endereos (nmeros ou
ndices), a eles. Para se repetir uma sequencia de comandos, ou seja, fazer uma iterao, utilizava-se
um comando para desviar o processamento para o endereo do primeiro comando da sequencia. Os
comandos eram basicamente: leia, armazene na varivel, faa a conta, grave (na tela, disco ou
impressora) e desvie para o endereo tal, alm do comando de condio SE (IF - se o valor for tanto,
pule para o endereo tal). Era a programao indexada. Tudo era controlado por nmeros e o
programador tinha que pensar como mquina. Um exemplo, era a linguagem Basic:
10 CLS
20 INPUT DIGITE UM VALOR PARA A: A
30 INPUT DIGITE UM VALOR DIFERENTE PARA B B
40 IF A=B GOTO 30
50 IF A>B GOTO 80
60 PRINT O VALOR A E MENOR DO QUE B
70 GOTO 90
80 PRINT O VALOR A E MAIOR DO QUE B
90 PRINT FIM DE PROCESSAMENTO

Com a criao dos comandos do tipo declarao (statement): enquanto (while), repita-at que (repeat
until), caso (case) e para-faa (for do); o sequenciamento de comandos passou a apresentar o formato
de uma contruo lgica, dispensando a numerao das linhas de programao. Os comandos
passaram a ser agrupados em blocos, chamados de sub-rotinas, ou procedimentos (procedures e
functions), que recebem um nome e podem ser utilizados como novos comandos. Esta era a
programao estruturada, procedural ou procedimental. O prprio programa passa a ser visto como um
grande bloco formado por blocos menores e comandos. Por exemplo, um programa para calcular fatorial
em linguagem turbo pascal.

108

TI para concursos

Program Fatorial;
Var
Numero : integer;
Function Calcula_Fatorial(n: integer) : integer;
Begin
If n>1 then
Calcula_Fatorial := n*Calcula_Fatorial(n-1)
Else
Calcula_Fatorial := 1;
End;
Begin
repeat
Clrscr;
Write(Digite um nmero inteiro positivo (zero para terminar): );
Readln(Numero);
If Numero>=0 then
Writeln(O fatorial de , Numero, , Calcula_Fatorial(Numero))
Else
Writeln(Valor invlido);
Until Numero=0;
Writeln(Fim de processamento.);
End.

A grande revoluo na arte da programao de computadores foi quando algum percebeu que o
homem no deve pensar como mquina para escrever um programa, mas deve fazer o computador
comportar-se como gente e compreender comandos humanos. Criou-se uma tcnica de raciocnio em
que o programa de computador podia ser visto como um objeto que se comporta como aquilo que
conhecemos na vida real.
Tem qualidades, aspectos, caractersticas ou, genericamente, atributos.
Tem comportamento. Pode ser mvel ou no, fazer coisas.
formado por objetos menores (at o tomo, ou menor) que possuem tambm atributos e
comportamentos
Quando esta tcnica se transformou em uma linguagem, criou-se a programao orientada a objetos.
Ela utiliza uma nova forma de fazer programas, no jogou fora todos os aspectos positivos da
programaao procedimental e estruturada, mas evoluiu estes conceitos. Os procedimentos e funes
so chamados de mtodos quando esto dentro de um objeto. As variveis internas ao objeto so
chamadas de propriedades ou atributos.
O conjunto de valores das propriedades formam o estado do objeto. Mensagens so aes de
dispositivos externos (teclado, mouse, placa de rede, scanner, outros programas) ou de outros objetos
que provocam mudanas de estado. Algumas mudanas do estado do objeto podem determinar uma
situao em que algum mtodo deve ser executado (ao). Por exemplo, um clique do mouse sobre um
objeto boto muda a propriedade Clicado de falso para verdadeiro. O seu novo estado pode
desencadear uma sequencia de comandos ou mtodos. Mudanas de estado que fazem uma ao so
chamadas de eventos. Neste exemplo, o clique do mouse aciona um evento chamado OnClick (se
existir).
A partir disto, um programa deixou de ser um simples sequenciamento de comandos para ser uma srie
de aes que provocam mudanas de estado que podem desencadear outras aes.

10.1.1

Tipos de dados e variveis


Durante o seu processamento, um programa deve necessitar de dados para efetuar clculos e
tratamentos e devolver informao ao usurio. Estes dados so introduzidos por qualquer meio, como
digitao, envio de parmetros por outro objeto ou leitura em um arquivo, depois armazenados em reas
da memria do computador chamadas de variveis. Os valores armazenados nas variveis podem ser
utilizados atravs de seu endereo fsico na memria (por apontadores ou pointers) ou, mais comum, por
um nome atribudo varivel.
Da mesma forma que no se somam bananas com mas, o programa no costuma misturar tipos
diferentes de dados em suas operaes. O programador deve ter conhecimento dos tipos possveis de
dados para no provocar erros no processamento. Linguagens de programao so ditas tipadas

109

TI para concursos

quando exigem que as variveis a serem utilizadas sejam pr-definidas como seu nome e tipo, como no
pascal. So no tipadas quando as variveis so definidas no momento de sua utilizao, assumindo um
determinado tipo de acordo com o valor atribudo a ela.
De forma geral, define-se como numrico os valores que sero utilizados para clculos algbricos. So
de tipo lgico as variveis que assumem apenas dois estados, verdadeiro ou falso, ou equivalente (0 ou
1, v ou t, sim ou no etc). So alfanumricas as variveis que no so destinadas a clculos, mas
somente operaes de comparaes, buscas, concatenaes ou simples exibio. So de tipo
apontador, variveis que armazenam endereos de memria.
Dependendo da linguagem de programao, as variveis numricas podem se subdividir em reais ou
inteiras, e tambm em outras variaes destes dois tipos, como inteiro no negativo, monetrio, inteiro
longo etc. O tipo alfanumrico tambm pode receber variaes como memorando (texto), ou texto
formatado.
Existem tambm outros tipos de armazenamento de dados na memria, que so agrupamentos de
variveis:
Vetor conjunto de variveis identificado por um nome e nmeros inteiros positivos (comeando em
zero) para cada elemento. A parte numrica do nome da varivel fica entre parnteses ou colchetes
direita do nome. Para se referir a uma posio do vetor, a parte numrica pode ser resultado de uma
operao matemtica. Um vetor que utiliza mais do que um nmero (dimenses) para identificar cada
uma de suas posies (separados por vrgulas) chamado de matriz.
Registro grupo de variveis de vrios tipos, identificado por um nome. Cada varivel dentro de um
registro chamada de campo.
Lista conjunto de registros ligados por apontadores, usado em conjunto de dados hierrquicos em
que a relao entre os dados no precisa ser representada em forma de matrizes, ou para armazenar
dados de uma tabela na memria para algum tratamento especial.
Fila sequncia de dados ordenados, em que o primeiro dado que entra na fila deve ser o primeiro a
sair (FIFO First in first out ou LILO - Last in last out)
Deque fila em que os elementos podem ser inseridos ou removidos de qualquer extremo.
Pilha sequncia de dados em que o ltimo valor adicionado deve ser o primeiro a sair (LIFO - Last
in first out ou FILO - First in last out)

10.2

Programao orientada a objetos


A anlise e o projeto orientados a objetos tm como meta identificar o melhor conjunto de objetos para
descrever um sistema de software. O funcionamento deste sistema se d por meio do relacionamento e
troca de mensagens entres os objetos.
As linguagens de programao que do suporte a orientao a objetos so:
Smaltalk, Perl, Python, Ruby, PHP, ColdFusion, C++, Object Pascal, Java, JavaScript, ActionScript,
Delphi (object pascal) e C#.
Os conceitos mais importantes na programao orientada a objetos so:
Objetos (instncias) e encapsulamento
Classes
Persistncia
Mtodos e propriedades
Herana e classes hierrquicas
Polimorfismo
Interfaces
Sobrecarga
Para uma linguagem ser considerada verdadeiramente orientada a objetos, a linguagem de programao
deve oferecer, no mnimo, as caractersticas de: encapsulamento, herana e polimorfismo.

10.2.1

Objetos
Objeto uma abstrao do mundo real. Objetos de software so modelados de acordo com os objetos
do mundo real, ou seja, possuem estado e comportamento. Um objeto de software armazena seu estado
em variveis e implementa seu comportamento com mtodos. Estas variveis e mtodos so
formalmente chamados de variveis de instncia e mtodos de instncia a fim de distingui-los de
variveis e mtodos de classe.
As variveis de um objeto fazem parte do seu ncleo (centro). Os mtodos envolvem e escondem
(empacotam) o ncleo do objeto de outros componentes da aplicao. Empacotar as variveis de um
objeto sobre proteo de seus mtodos chamado de encapsulamento. O encapsulamento utilizado

110

TI para concursos

para esconder detalhes de implementao. Este um dos princpios fundamentais da programao


orientada a objetos.
s vezes, por razes de eficincia ou implementao, um objeto deseja expor algumas de suas variveis
ou esconder alguns de seus mtodos. Esta capacidade de controlar quais componentes podem acessar
seus mtodos e suas variveis chamada de Controle de Acesso.
Cada objeto tem sua identidade, o que significa que dois objetos so distintos mesmo que eles
apresentem exatamente as mesmas caractersticas (atributos iguais). Esta identificao de objeto deve
ser nica, uniforme e independente do contedo do objeto.
Em geral, os objetos possuem, pelo menos, dois mtodos:
Construtor: define o comportamento no momento da criao de um objeto de uma classe;
Destrutor: define o comportamento no momento da destruio do objeto de uma classe. Normalmente
utilizado para liberar recurso (memria) do sistema.

10.2.2

Classe
Objetos podem apresentar mtodos e atributos (propriedades) idnticos. Em relao a estes elementos
em comum, dizemos que eles pertencem a uma mesma classe. Na programao orientada a objeto,
classe uma abstrao, enquanto que, neste contexto, objeto considerado um elemento ftico.
Uma classe um modelo, ou prottipo, que define as variveis (estado) e os mtodos (comportamento)
comuns a todos os objetos do mesmo tipo. Na classe so definidas as variveis e implementados os
mtodos. Os objetos so criados a partir de suas classes.
Dois botes na tela pertencem classe boto. Espera-se deles que respondam ao clique do mouse,
costumam ser cinzas, em alto-relevo e ficam em baixo-relevo ao clicar.
Por outro ponto de vista, podemos dizer que uma classe boto, cinza, em alto-relevo, com determinado
comportamento ao clicar, pode ter duas instncias na tela. Definidas as caractersticas de um tipo de
boto, ao criar (instanciar) um objeto, por uma instruo determina-se que ele far parte da classe, e isto
far com que ele herde todas as caractersticas de um boto tpico. Depois de instanciado, aes
podero alterar seu estado, como sua aparncia e comportamento.
Na programao orientada a objetos, implementa-se um conjunto de classes que definem os objetos
presentes no sistema de software. Cada classe determina o comportamento (mtodos e eventos) e os
estados possveis (valores dos atributos) de seus objetos, assim como o relacionamento com outros
objetos.
As classes no so diretamente suportadas em todas as linguagens de objetos, e no so necessrias
para que a linguagem seja orientada a objetos.
A classe define as caractersticas comuns e os objetos so instncias dessa classe, com estado prprio.

10.2.3

Persistncia
Alguns objetos so criados, cumprem sua funo e so destruidos logo em seguida. Outros objetos
continuam por tempo indeterminado e isto chamado de persistncia. No faz sentido falar de
persistncia de classes, somente de instncias (objetos).

10.2.4

Mtodos
Mtodo uma sub-rotina interna a um objeto, que pode ser executado por uma ao externa, isto , ao
receber uma mensagem, ou por uma ao interna de um evento.

10.2.5

Atributos
Os atributos so os elementos que definem a estrutura de uma classe. Os atributos tambm so
conhecidos como variveis de classe, e podem ser divididos em dois tipos bsicos: atributos de instncia
e de classe.

111

TI para concursos

Os valores dos atributos de instncia determinam o estado de cada objeto. Um atributo de classe possui
um estado que compartilhado por todos os objetos de uma classe. Atributos de classe podem ser
chamados tambm de atributos estticos ou constantes.

10.2.6

Mensagens
Objetos modificam seu estado por meio do recebimentos de mensagens. Alguns mtodos de um objeto
que recebe a mensagem precisam de informaes, os parmetros, para saber exatamente o que fazer.
Assim, trs componentes fazem parte de uma mensagem:
o objeto para onde a mensagem endereada;
o nome do mtodo a realizar;
parmetro(s) necessrios para realizar o mtodo;

10.2.7

Herana
A herana um mecanismo que permite criar novas classes a partir de classes j existentes,
aproveitando-se das caractersticas existentes na classe a ser extendida. Com a herana possvel criar
classes derivadas (sub-classes) a partir de classes bases (superclasses).
As subclasses herdam todas as caractersticas de suas superclasses, como suas variveis (estado) e
seus mtodos (comportamento). Entretanto, as subclasses no esto limitadas ao comportamento
herdado de sua super-classe. As subclasses podem adicionar variveis e mtodos a aqueles herdados.
As subclasses, tambm, podem redefinir (override) mtodos herdados e oferecer implementaes
especializadas para estes mtodos. O conceito de herana pode ser aplicado para mais de um nvel. A
rvore de herana, ou hierarquia de classe, pode ser to profunda quanto necessrio. Os mtodos e
variveis so herdados por meio dos nveis. Em geral, quanto mais baixa na hierarquia for a posio da
classe, mais especfico o seu comportamento.
Como benefcios do conceito de herana, podemos citar:
Programadores podem definir classes abstratas que determinam comportamentos genricos.
Subclasses oferecem comportamentos especializados a partir de elementos bsicos comuns,
oferecidos pela superclasse.
A utilizao de herana promove o reuso e reaproveitamento de cdigo existente, tornando a
manuteno do cdigo mais eficiente.
A superclasse define e pode implementar parcialmente o comportamento de uma classe, mas a maioria
das informaes da classe fica indefinida ou no implementada.
A herana mltipla ocorre quando uma classe pode estender caractersticas de vrias outras classes ao
mesmo tempo, ou seja, quando a subclasse possui mais de uma superclasse. Algumas linguagens
evitam utilizar este mecanismo, pois pode levar uma codificao confusa o que dificulta a manuteno do
cdigo. A linguagem Java no suporta herana mltipla, apenas herana simples. J a linguagem C++
oferece suporte herana mltipla.
Uma linguagem ao utilizar herana mltipla est sujeita a dois problemas: coliso de nomes (nomes
idnticos nas classes superiores) e herana repetida (classe herda de uma classe superior que herda de
uma classe comum);

10.2.8

Polimorfismo
Segundo a terminologia de orientao a objetos, polimorfismo significa que uma mesma mensagem
enviada a diferentes objetos resulta em um comportamento que dependente da natureza do objeto que
est recebendo a mensagem. Ou seja, duas ou mais classes derivadas de uma mesma super-classe
podem invocar mtodos que tm a mesma assinatura (nome, lista de parmetros e retorno), mas
comportamentos distintos, especializado para cada classe derivada, usando para tanto uma referncia a
um objeto do tipo superclasse.
A deciso sobre qual mtodo deve ser selecionado, de acordo com o tipo da classe derivada, tomada
em tempo de execuo por meio do mecanismo de ligao tardia. No caso do polimorfismo, necessrio
que os mtodos tenham exatamente a mesma identificao, sendo utilizado o mecanismo de redefinio
de mtodos.
Os benefcios do polimorfismo so: a clareza e manuteno do cdigo, a diviso da complexidade e
aplicaes flexveis. Algumas linguagens promovem o polimorfismo principalmente por meio do uso de
classes abstratas e interfaces, como o caso da linguagem Java.

10.2.9

Sobrecarga
A sobrecarga um tipo de polimorfismo que permite a existncia de vrios mtodos de mesmo nome,
porm com assinaturas levemente diferentes, ou seja, variando no nmero e tipo de argumentos e o

112

TI para concursos

valor de retorno. Ficar a cargo de o compilador escolher de acordo com as listas de argumento os
procedimentos ou mtodos a serem executados. Por exemplo:
public class Soma
{ public int Soma (int x, int y)
{return x+y;}
public String Soma (String x, String y)
{return x+y;}
public double Soma (double x, double y)
{return x+y;}
}

10.2.10 Interfaces
Interface a relao de mtodos, com seus parmetros, das propriedades que podem ser acessados
por outros objetos e tambm pode incluir declaraes de constantes.
Uma interface apresenta somente as definies de mtodos, sem sua implementao. A classe que
implementa a interface deve implementar todos os mtodos definidos na interface.

10.2.11 Pacotes
Para tornar as classes mais fceis de serem encontradas e utilizadas, para evitar conflitos de nomes e
para controlar o acesso, pode-se agrupar classes relacionadas em pacotes (packages). Os pacotes
organizam as classes e as interfaces relacionadas. Cada pacote criado corresponde a um diretrio, ou
seja, as classes e as interfaces de um mesmo pacote devem estar em um mesmo diretrio.
A utilizao de pacotes proporciona as seguintes vantagens:
Fica mais fcil para outros programadores determinar quais classes e interfaces esto relacionadas.
Os nomes das classes de um pacote no iro conflitar com nomes e classes de outros pacotes.
Pode-se permitir que classes dentro de um mesmo pacote tenham acesso irrestrito entre si, e
restringir o acesso por parte de classes definidas fora do pacote.
Apenas os membros (classe, variveis e mtodos) pblicos so acessveis fora do pacote onde foram
definidos.

10.3

Programao na WEB
Visualizar uma pgina web ou outro recurso disponibilizado normalmente inicia ou ao digitar uma URL no
navegador ou seguindo (acessando) uma hiperligao. Primeiramente, a parte da URL referente ao
servidor web separada e transformada em um endereo IP, por um banco de dados da Internet
chamado Domain Name System (DNS). O navegador estabelece ento uma conexo TCP-IP com o
servidor web localizado no endereo IP retornado.58
O prximo passo o navegador enviar uma requisio HTTP ao servidor para obter o recurso indicado
pela parte restante da URL (retirando-se a parte do servidor). No caso de uma pgina web tpica, o texto
HTML recebido e interpretado pelo navegador, que realiza ento requisies adicionais para figuras,
arquivos de formatao, arquivos de script e outros recursos que fazem parte da pgina.
O navegador ento renderiza a pgina na tela do usurio, assim como descrita pelos arquivos que a
compe.
A funcionalidade da Web baseada em trs padres:
URI, um sistema que especifica como cada pgina de informao recebe um "endereo" nico onde
pode ser encontrada.
HTTP, um protocolo que especifica como o navegador e servidor web comunicam entre si.
HTML, uma linguagem de marcao para codificar a informao de modo que possa ser exibida em
uma grande quantidade de dispositivos.
Desta forma, programar para Web escrever pginas em HTML. Para isto, o programador pode
escrever um texto em HTML puro e gravar este arquivo em um servidor web. Estes textos so chamados
de pginas estticas. Elas s mudam quando o programador alterar o arquivo.
Porm, o servidor web utilizado pode ter instalado programas que geram pginas HTML no momento em
que a requisio chega. Neste caso, o texto requisitado no um texto HTML, mas um cdigo em
alguma linguagem de programao que, ao ser processado pelo servidor, gera um texto HTML dentro
das especificaes da requisio. Estes textos so chamados de pginas dinmicas. Estas pginas

http://pt.wikipedia.org/wiki/World_Wide_Web
113
58

TI para concursos

permitem a interao com o usurio e com gerenciadores de bancos de dados, podendo gerar pginas
HTML diferentes a cada instante.
Assim, ao projetar um site, o programador decide se vai usar pginas estticas, dinmicas ou as duas.

10.3.1

Linguagem HTML
HTML (acrnimo para a expresso inglesa HyperText Markup Language, que significa Linguagem de
Marcao de Hipertexto) uma linguagem de marcao utilizada para produzir pginas na Web.
Documentos HTML podem ser interpretados por navegadores. A tecnologia fruto do "casamento" dos
padres HyTime e SGML.59
HyTime um padro para a representao estruturada de hipermdia e contedo baseado em tempo.
Um documento visto como um conjunto de eventos concorrentes dependentes de tempo (como udio,
vdeo, etc.), conectados por hiper-ligaes. O padro independente de outros padres de
processamento de texto em geral.
SGML um padro de formatao de textos. No foi desenvolvido para hipertexto, mas tornou-se
conveniente para transformar documentos em hiper-objetos e para descrever as ligaes.
Todo documento HTML apresenta tags (tags), elementos entre parnteses angulares (sinais de maior e
menor). Esses elementos so os comandos de formatao da linguagem. A maioria das tags tem sua
correspondente de fechamento:
<tag>...</ tag >

Isso necessrio porque as tags servem para definir a formatao de uma poro do documento, e
assim marcamos onde comea e termina o texto com a formatao especificada por ela. Alguns
elementos so chamados vazios, pois no marcam uma regio de texto, apenas inserem algum
elemento no documento:
Uma tag formada por comandos, atributos e valores. Os atributos modificam os resultados padres dos
comandos e os valores caracterizam essa mudana.
A estrutura de um documento HTML apresenta os seguintes componentes:
<html>
<head>
<title>Ttulo do Documento</title>
</head>
<body>
texto,
imagem,
links,
...
</body>
</html>

De uma maneira geral o HTML um poderoso recurso, sendo uma linguagem de marcao muito
simples e acessvel voltada para a produo e compartilhamento de documentos e imagens.
As tags HTML no so sensveis maisculas ou minsculas, portanto tanto faz escrever <HTML>,
<Html>, <html> ou <HtMl>.
As tags bsicas de HTML, cuja presena altamente recomendada nas pginas so:
<html>: define o incio de um documento HTML e indica ao navegador que todo contedo posterior
deve ser tratado como uma srie de cdigos HTML.
<head>: define o cabealho de um documento HTML, que traz informaes sobre o documento que
est sendo aberto.
<body>: define o contedo principal, o corpo do documento. Esta a parte do documento HTML que
exibida no navegador. No corpo podem-se definir propriedades comuns a toda a pgina, como cor
de fundo, margens, e outras formataes.
Dentro do cabealho podemos encontrar os seguintes comandos:
<title>: define o ttulo da pgina, que exibido na barra de ttulo dos navegadores.
<style>: define formatao em CSS (Cascading Style Sheets), uma linguagem de estilo utilizada para
definir a apresentao de documentos escritos em HTML ou XML.
<script>: define programao de certas funes em pgina com scripts (cdigos de programa) em
diversas linguagens web cliente, como Javascrip, Visual Basic Script, DHTML ou CSS.
http://pt.wikipedia.org/wiki/HTML
114
59

TI para concursos

Applets de Java
<link>: define ligaes da pgina com outros arquivos como feeds, CSS, scripts etc.
<meta>: define propriedades da pgina, como codificao de caracteres, descrio da pgina, autor,
etc. So meta informaes sobre documento. Tais campos so muitos usados por mecanismos de
busca (como o Google) para obterem mais informaes sobre o documento, a fim de classific-lo
melhor. Por exemplo, pode-se adicionar o cdigo <meta name="description" content="descrio da
sua pgina" /> no documento HTML para indicar ao motor de busca que texto de descrio
apresentar junto com a ligao para o documento.
As tags <style> e <script> servem tanto para delimitar o espao usados pelos cdigos na pgina quanto
para invocar cdigos existentes em outros arquivos externos.
Dentro do corpo podemos encontrar outras vrias tags, como por exemplo:
<h1>, <h2>,... <h6>: cabealhos e ttulos no documento em diversos tamanhos. (quanto menor for o
nmero, maior sera o tamanho da letra)
<p>: novo pargrafo.
<br>: quebra de linha.
<table>: cria uma tabela (linhas so criadas com <TR> e novas clulas com <TD>. J os cabealhos
de coluna so criados com a tag <TH>.)
<div>: determina uma diviso na pgina a qual pode possuir variadas formataes.
<font>: altera a formatao (fonte, cor e tamanho) de um trecho do texto.
<b>, <i>, <u> e <s>: negrito, itlico, sublinhado e riscado, respectivamente.
<img>: imagem.
<a>: hiper-ligao para um outro local, seja uma pgina, um e-mail ou outro servio.
<textarea>: caixa de texto (com mais de uma linha); estas caixas de texto so muito usadas em
blogs, elas podem ser auto selecionveis e conter outros cdigos a serem distribudos.
<acronym>: acrnimo (sigla)
<cite>: citao
<address>: endereo
Uma propriedade importante dos documentos HTML a possibilidade de fazer hiperligaes. Para isso
usa-se a tag <a> (do ingls, anchor). Esta tem os atributos: href que define o alvo da hiperligao (que
pode ser uma pgina de Internet, uma parte da mesma pgina ou um endereo de email) ou name que
define um alvo nessa pgina (a onde se pode fazer uma hiperligao usando a tag a com o atributo href).
Exemplos:
<a href="ht-tp://pt.wikipedia.org/">Clique aqui para aceder pgina principal da Wikipdia em portugus.</a>
<a name="nome">texto</a>

Os caracteres especiais definem-se usando comandos que comeam com & e terminam com um ;.
Alguns exemplos incluem &aacute; (), &agrave; (), &atilde; (), &acirc; (), &auml; () e &ccedil; ().
Qualquer outra vogal pode ser substituda pelo a destes exemplos, incluindo maisculas.

10.3.2

Linguagens web de servidor


Para a criao de pginas dinmicas, existem diversas linguagens de programao que podem ser
configuradas no servidor, como, por exemplo, CGI (Common Gateway Interface), ASP (Active Server
Pages), PHP (Hypertext Preprocesor) ou JSP (Java Server Pages).

10.3.3

XML
O XML (eXtensible Markup Language) um formato para a criao de documentos com dados
organizados de forma hierrquica, como se v, frequentemente, em documentos de texto formatados,
imagens vetoriais ou bancos de dados.
um subtipo de SGML (Standard Generalized Markup Language) capaz de descrever diversos tipos de
dados. Seu propsito principal a facilidade de compartilhamento de informaes atravs da Internet.60
Pela sua portabilidade, j que um formato que no depende das plataformas de hardware ou de
software, um banco de dados pode, atravs de uma aplicao, escrever em um arquivo XML, e um outro
banco distinto pode ler ento estes mesmos dados.
Este exemplo demonstra a sintaxe flexvel do XML sendo usada para descrever uma receita de po:

http://pt.wikipedia.org/wiki/XML
115
60

TI para concursos

<?xml version="1.0" encoding="ISO-8859-1"?>


<receita nome="po" tempo_de_preparo="5 minutos" tempo_de_cozimento="1 hora">
<titulo>Po simples</titulo>
<ingredientes>
<ingrediente quantidade="3" unidade="xcaras">Farinha</ingrediente>
<ingrediente quantidade="7" unidade="gramas">Fermento</ingrediente>
<ingrediente quantidade="1.5" unidade="xcaras" estado="morna">gua</ingrediente>
<ingrediente quantidade="1" unidade="colheres de ch">Sal</ingrediente>
</ingredientes>
<instrucoes>
<passo>Misture todos os ingredientes, e dissolva bem.</passo>
<passo>Cubra com um pano e deixe por uma hora em um local morno.</passo>
<passo>Misture novamente, coloque numa bandeja e asse num forno.</passo>
</instrucoes>
</receita>

Onde temos na primeira linha:


<Receita nome="po" tempo_de_preparo="5 minutos" tempo_de_cozimento="1 hora">

"Receita" o nome principal para o seu documento. Note que a semelhana entre XML e HTML
grande, na 1 linha abrimos a tag Receita e na ltima linha a fechamos, como em HTML, assim se
estendendo por todo o exemplo.
Assim como em HTML, os contedos so inseridos entre tags (marcadores) de mesmo nome, sendo que
a segunda tag tem uma barra (/) antes do nome.
O XML apresenta algumas regras bsicas:
Letras maisculas e minsculas so diferentes.
<passo> diferente de <Passo>

Nenhuma tag pode ficar aberta. Toda <tag> deve ter uma </tag>.
<passo>Misture todos os ingredientes, e dissolva bem.</passo>

As tags no podem ficar sobrepostas. Uma tag aberta dentro de outra tag deve ser fechada antes.
<instrucoes>
<passo>Misture todos os ingredientes, e dissolva bem.</passo>
</instrucoes>

Os atributos devem estar entre aspas.


<ingrediente quantidade="3" unidade="xcaras">

10.4

Conceitos de linguagem de programao Microsoft .NET


No ano de 2000, a Microsoft apresentou ao mundo a plataforma .Net e seu novo ambiente de
desenvolvimento, o Visual Studio .Net.
A .Net, em sua essncia, muito similar ao J2EE (Java 2 Enterprise Edition).
Um compilador .Net gera um cdigo intermedirio, e quando executado, o compilador JIT (Just in
Time) traduz este cdigo intermedirio para cdigo nativo do processador, com um enorme ganho de
performance.
A .Net tambm oferece independncia de plataforma, hardware e linguagem de programao.

116

TI para concursos

10.4.1

arquitetura da .Net
Existem termos e conceitos que devem ser entendidos para se utilizar a .Net.

10.4.2

Linguagens de programao
Esta a primeira camada da plataforma. Neste nvel ficam as ferramentas de desenvolvimento e os
respectivos compiladores.
A .Net oferece independncia de linguagem. Atualmente existem mais de trinta com suporte para .Net.
Todas as linguagens .Net obrigatoriamente devem seguir os padres da plataforma. Quando dizemos
que uma linguagem compatvel com .Net, entendemos que ela usa o CLR e a FCL.
A Microsoft oferece quatro linguagens com sua plataforma:
C# (leia-se C Sharp), com caractersticas herdadas do C++ e Java, mas muito mais fcil de aprender
e utilizar
VB.Net, a verso do Visual Basic que foi reescrito para a plataforma
C++ Embedded, a verso C++ da .Net, pouqussimo usada
J# (leia-se Jei Sharp), a verso Java da .Net, tambm muito pouco usada, cujo objetivo apenas
facilitar a migrao dos desenvolvedores Java para a .Net.
Oferece total compatibilidade com suas linguagens, onde cdigos escritos numa determinada linguagem
podem ser executadas em outra sem nenhum problema. Ou seja, possvel escrever uma classe em
C#, herd-la em VB.Net e us-la no C++ Embedded (a verso C++ da .Net).

10.4.3

Common Language Specification (CLS)


A Microsoft liberou um conjunto de especificaes que uma linguagem deve possuir para ser
considerada compatvel com .Net. Como a IL (ou o assembly .Net) uma linguagem muito rica, no
necessrio que sejam implementadas todas suas funcionalidades, basta uma parte dela para tornar a
linguagem compatvel. Esta a razo pela qual muitas linguagens, procedurais ou oop, j esto
executando sob o guarda-chuva da .Net. A CLS basicamente determina especificaes de
desenvolvimento e estabelece certos padres. Por exemplo, no pode haver declarao de funes
globais, acesso a ponteiros, herana mltipla e coisas deste tipo. Um detalhe importante que, se seu
cdigo est dentro das fronteiras estabelecidas pela CLS, garantido que ele poder ser utilizado por
qualquer outra linguagem da plataforma.

10.4.4

Common Type System (CTS)


Como a CLS, a Common Type System tambm um conjunto de padres que define os tipos de dados
bsicos que a IL entende. Toda linguagem .Net deve mapear seus tipos primitivos para estes padres.
Isto possibilita que as linguagens se comuniquem passando/recebendo parmetros de uma para a outra.

117

TI para concursos

Por exemplo, a CTS define um tipo Int32 como um inteiro de 32 bits (4 bytes), o qual chamado (ou
mapeado) em C# como int e em VB.Net como integer. Mas pra .Net ambos so iguais, ou seja, um Int32.

10.4.5

Framework Class Library (FCL)


A .Net oferece uma gigantesca biblioteca de classes bsicas para as tarefas mais comuns e usuais. A
FCL contm milhares de classes para acesso a API do Windows e funes em geral, como manipulao
de strings, estrutura de dados, entrada/sada, fluxos, segurana, multi-tarefa, programao em rede,
Web, acesso a dados, etc. Ela simplesmente a maior biblioteca padro j fornecida por qualquer
linguagem de programao ou ambiente de desenvolvimento. A melhor parte da FCL so seus padres
de desenvolvimento totalmente OOP, tornando seu acesso e utilizao muito simples e previsveis. Voc
utiliza estas classes em seus programas como utilizaria qualquer outra, inclusive aplicando herana e
polimorfismo nelas. Esta biblioteca organizada hierarquicamente numa estrutura chamada namespace.
Ao desenvolver qualquer software, ele precisa ser estruturado numa namespace para que possa ser
usado a partir de outro programa externo (veremos namespaces oportunamente).

10.4.6

Camada de apresentao
Este nvel define o tipo de interao do sistema com o usurio, que pode ser atravs de uma aplicao
Web (utilizando o ASP.Net e Web Forms), Windows (utilizando Windows Forms) ou console (utilizando
um prompt de comando, em modo caracter). Na minha opinio, os sistemas para Smart Devices (como
Pockets, celulares, etc) tambm deveriam ser considerados uma camada de apresentao diferente,
mas neste esquema eles foram includos com os Windows Forms.

10.4.7

ADO.Net
Esta camada responsvel pela comunicao das aplicaes com os banco de dados. Basicamente, o
ADO.net trabalha de duas formas:
Modo conectado: utilizando objetos das classes managed provider, que permitem que voc se conecte
ao banco de dados e execute instrues SQL diretamente;
Modo desconectado: neste modo, voc armazena informaes de um banco de dados localmente, na
memria do computador onde a aplicao est executando. Estas informaes so armazenadas em
objetos das classes Dataset, que permitem qualquer operao aceita por um banco de dados, tambm
conhecida pela sigla CRUD (Create, Retrieve, Update, Delete) ou seja, criar, recuperar, atualizar e
excluir linhas (ou registros). Periodicamente, uma conexo feita com o banco e as informaes so
sincronizadas. Deste modo, voc pode criar aplicaes para Web ou dispositivos mveis (tipo Pocket
PC), que no tem uma conexo permanente com o banco, ou mesmo aplicaes Windows rodando
numa rede local ou remota.

10.4.8

.Net Remoting
Remoting o processo no qual programas ou componentes se interagem dentro de certos limites. Estes
contextos normalmente so mquinas ou processos diferentes. Na .NET Framework, esta tecnologia
fornece a base para aplicaes distribudas, ou seja, ela simplesmente substitui o DCOM.
DCOM a abreviatura de Distributed Component Object Model, uma extenso do COM (Component
Object Model) que permite que objetos se comuniquem em uma rede. Componentes COM tradicionais
somente executam esta comunicao entre processos na mquina local. O DCOM usa o mecanismo
RPC para enviar e receber informaes entre componentes COM (clientes e servidores) na mesma rede.
o RPC a abreviatura para Remote Procedure Call, um tipo de protocolo que permite que um programa
num computador execute outro programa num servidor. Com esta tcnica, o desenvolvedor no precisa
criar procedimentos especficos para o servidor. O programa cliente envia uma mensagem ao servidor,
com os argumentos apropriados, e o servidor retorna uma mensagem contendo o resultado do programa
executado.
o A rede a que nos referimos pode ser uma LAN, WAN ou a prpria Internet (que no passa de uma rede
mundial gigantesca).
Implementaes Remoting geralmente fazem distino entre objetos remotos e objetos mveis.
Objetos remotos: Remoting fornece a capacidade de executar mtodos em servidores remotos,
passando parmetros e recebendo valores de retorno. O objeto remoto sempre fica num servidor e as
outras mquinas apenas passam uma referncia a ele.
Objetos mveis: Neste caso os dados enviados so serializados (organizados) num formato que pode
ser binrio ou legvel para ns, como XML, e de-serializados no outro contexto envolvendo o processo.
Ambos, servidor e cliente, mantm cpias do mesmo objeto. Nestas cpias, os mtodos so executados
no contexto local e nenhuma mensagem vai trafegar de volta a mquina que originou o objeto. Na
verdade, aps a serializao e de-serializao os objetos copiados so idnticos aos objetos locais
normais, e no h distino entre um objeto servidor e um objeto cliente.

118

TI para concursos

A .NET expande este conceito para incluir a habilidade de definir contextos adicionais dentro de uma
aplicao em execuo, e o acesso a estes objetos alm dos seus limites tambm passaro pelo .NET
Remoting Framework.

10.4.9

Common Language Runtime (CLR)


O conceito mais importante da .Net Framework a existncia e funcionalidade do Common Language
Runtime (CLR), tambm conhecida como .Net Runtime ou mquina virtual .Net. Ele uma camada do
framework que fica acima do sistema operacional e manipula a execuo de todas as aplicaes .Net.
Nossos programas no se comunicam diretamente com o sistema operacional, apenas atravs do CLR.
Ele o responsvel por chamar o compilador JIT (Just In Time, ou em tempo de execuo) e transformar
o cdigo MSIL (Microsoft Intermediate Language ou assembly), gerado pelos compiladores .Net, em
cdigo nativo da plataforma onde est executando. Ou seja, quando voc compila um programa ou dll
.Net voc obtm um arquivo com a extenso .exe ou .dll mas estes arquivos no executaro se o CLR
no estiver instalado.
O CLR tambm contm o Garbage Collector (GC), ou coletor de lixo, o qual executa como uma tarefa de
baixa prioridade e verifica por espaos de memria no referenciados, alocados dinamicamente. Se ele
encontra algum dado que no mais utilizado por nenhuma varivel/referncia, ele libera esta memria
para o sistema operacional us-lo para outros programas, quando necessrio. A presena do GC libera o
programador da tarefa de administrar estes dados pendendes, e que tanto inferniza a vida dos
desenvolvedores C++.

10.4.10 Common Language Infrastructure (CLI)


A especificao CLI um padro internacional para criar ambientes de desenvolvimento e execuo no
qual linguagens e bibliotecas trabalham juntas. Ela descreve como aplicaes escritas em mltiplas
linguagens de alto nvel podem ser executadas em diferentes ambientes operacionais sem necessidade
de se reescrever a aplicao, para levar em conta as caractersticas destes ambientes. Na plataforma
.Net, a implementao da CLI exatamente a CLR.

10.4.11 Operating System (OS)


No ltimo nvel, temos o sistema operacional (SO), responsvel pela comunicao direta com os
dispositivos (hardware) do computador. Para que uma aplicao .Net funcione em vrios ambientes
operacionais diferentes, deve haver uma CLR especfica para cada um deles. Desta forma, uma vez
escrita e compilada, uma aplicao pode ser transportada de uma ambiente para outro sem nenhum tipo
de modificao (pelo menos, teoricamente).

10.4.12 Outros detalhes da .Net


Assembly: Toda aplicao .Net, aps compilada, armazenada fisicamente numa unidade de cdigos
chamada assembly. Uma aplicao pode ser composta por um ou mais assemblies, os quais aparecem
no sistema operacional como arquivos executveis com a extenso .exe ou como bibliotecas dinmicas
com a extenso .dll.
Metadados: So conjuntos de instrues geradas no processo de compilao de um programa .Net,
junto com o MSIL, e que contm informaes especficas da aplicao, que incluem, entre outras:
o Descrio de tipos: classes, estruturas, tipos enumerados, etc, que so usados no sistema, seja um
executvel ou dll;
o Descrio dos membros: propriedades, mtodos, eventos, etc;
o Descrio de cada assembly: que usado na aplicao e necessrio para sua execuo;
o Verso: permite que aplicaes homnimas, mas com verses diferentes, executem no mesmo
computador sem conflitos.
Com as informaes contidadas nos metadados, podemos dizer que uma aplicao .Net autoexplicativa, dispensando a utilizao do registro do Windows, usado pela maioria dos programas. Desta
forma, a no ser que voc crie chaves especficas no registro para seu uso, a instalao de um
programa .Net se resume em copiar os assemblies da aplicao para a mquina que ir execut-lo.

119

TI para concursos

10.5

Exerccios
(ICMS-SP 2009) Instrues: Para responder s cinco prximas questes, utilize um computador hipottico que
tem um registrador R (valor inicial: R=10) e 5 posies de memria de M1 at M5 (valores iniciais: M1=030,
M2=005, M3=020, M4=015 e M5=010), com capacidade de 3 dgitos cada posio para armazenar valores
inteiros de 999 e +999, e que reconhece os seguintes tipos de instrues (cada instruo tem um endereo
n sequencial e termina com um ponto-e-vrgula):
INI; (= inicia o programa).
FIM; (= termina o programa).
IMP; (= imprime o contedo de R).
LER nnn; (= carrega em R o nmero nnn digitado pelo teclado).
CAR Mx; (= carrega em R o contedo de Mx).
CAR n; (= carrega em R o nmero n).
MOV Mx; (= move para Mx o contedo de R).
SOM Mx; (= soma Mx com R, o resultado fica em R).
SOM n; (= soma n com R, o resultado fica em R).
SUB Mx; (= subtrai Mx de R, o resultado fica em R).
SUB n; (= subtrai n de R, o resultado fica em R).
MUL Mx; (= multiplica Mx por R, o resultado fica em R).
DIV Mx; (= divide Mx por R, o resultado fica em R).
IRP n; (= ir para a instruo de endereo n).
SE condio instrues1 SENAO instrues2; (= se condio =VERDADEIRA executa instrues1, se
=FALSA executa instrues2).
188. (ICMS-SP 2009) Dado o programa:
1.INI; 2.LER 050; 3.SOM M3; 4.MOV M1; 5.SUB M5; 6.FIM;
188
Ao trmino da execuo, os contedos de M1, M3 e M5 so, respectivamente,
xx
(a) 070, 020 e 010.
(b) 070, 070 e 060.
(c) 030, 020 e 010.
(d) 050, 020 e 010.
(e) 050, 070 e 060.
189. (ICMS-SP 2009) Dado o programa:
1.INI; 2.CAR M2; 3.CAR M4; 4.MOV M4; 5.MOV M2; 6.FIM;
Ao trmino da execuo, os contedos de R, M2 e M4 so, respectivamente,189
(a) 015, 005 e 015
(b) 015, 015 e 005
(c) 015, 015 e 015xx
(d) 010, 015 e 005
(e) 010, 005 e 015
190. (ICMS-SP 2009) Dado o programa:
1.INI; 2.MOV M1; 3.SE M1=015 IRP 4 SENAO SOM 1 IRP 5; 4.SOM M1; 5.IMP; 6.FIM;
Ao trmino da execuo, o contedo impresso ser igual a190
(a) 10
(b) 11xx
(c) 15
(d) 25
(e) 30
191. (ICMS-SP 2009) A lgica principal do programa apresentado na questo anterior representa uma estrutura de
191
controle denominada estrutura
(a) sequence.
(b) de repetio do-until.
(c) de repetio do-while.
xx
(d) de seleo if-then-else.
(e) de seleo case.
192. (ICMS-SP 2009) Dado o programa:
1.INI; 2.CAR M1; 3.CAR M2; 4.CAR M3; 5.CAR M4; 6.CAR M5; 7.SUB M5; 8.FIM;
192
O programa que obtm o mesmo resultado final :
(a) 1.INI; 2.SUB M5; 3.CAR M1; 4.CAR M2; 5.CAR M3; 6.CAR M4; 7.CAR M5; 8.FIM;
(b) 1.INI; 2.CAR M5; 3.CAR M4; 4.CAR M3; 5.CAR M2; 6.CAR M1; 7.SUB M5; 8.FIM;
(c) 1.INI; 2.SUB M5; 3.CAR M5; 4.CAR M4; 5.CAR M3; 6.CAR M2; 7.CAR M1; 8.FIM;
(d) 1.INI; 2.SUB M5; 3.CAR M5; 4.FIM;
(e) 1.INI; 2.CAR M5; 3.SUB M5; 4.FIM; xx

120

TI para concursos

193. (ICMS-SP 2009) Os valores das propriedades de um objeto em um determinado instante, que podem mudar
193
ao longo do tempo, representam
(a) a instncia de uma classe.
(b) a identidade de um objeto.
xx
(c) o estado de um objeto.
(d) o comportamento de um objeto.
(e) as operaes de uma classe.
194. (ICMS-SP 2009) Na orientao a objetos, ao nvel de classe, so definidos os194
(a) atributos e os valores dos atributos.
(b) atributos e a invocao das operaes.
xx
(c) atributos e os mtodos.
(d) mtodos e os valores dos atributos.
(e) mtodos e a invocao das operaes.
195. (ICMS-SP 2009) Uma classe uma abstrao que ajuda a lidar com a complexidade e um bom exemplo de
abstrao 195
(a) um aluno e as disciplinas que est cursando.
(b) um professor e os cursos nos quais ministra aulas.
(c) um funcionrio e o departamento em que trabalha.
(d) uma pessoa e o nmero do seu CPF na Receita Federal.xx
(e) uma casa e a empresa que a projetou e construiu.
196. (ICMS-SP 2009) O mtodo utilizado para inicializar objetos de uma classe quando estes so criados
denominado196
(a) void.
(b) interface.
(c) agregao.
(d) composio.
(e) construtor.xx
197. (ICMS-SP 2009) Sobre a visibilidade dos mtodos na orientao a objetos considere:
I. Os mtodos pblicos de uma classe definem a interface da classe.
II. Os mtodos privativos de uma classe no fazem parte da interface da classe.
III. O nome dos mtodos a informao reconhecida como a assinatura dos mtodos.
Est correto o que consta APENAS em197
(a) I e II.xx
(b) I e III.
(c) II e III.
(d) II.
(e) I.
198. (ICMS-SP 2009) A .NET Framework trata-se de uma arquitetura da estratgia Microsoft .NET
I. constituda das partes Common Language Runtime, bibliotecas de classes, ASP.NET e ADO.NET.
II. para construir, implementar e executar aplicaes e webservices.
III. desenvolvida como um componente integral do Windows.
Est correto o que consta em198
(a) I, apenas.
(b) II, apenas.
(c) I e II, apenas.
xx
(d) II e III, apenas.
(e) I, II e III.
199. (ICMS-SP 2009) NO uma linguagem de programao do pacote Visual Studio 2005 que utiliza o mesmo
199
IDE e as funcionalidades da .NET Framework:
(a) Visual Basic.
(b) Visual FoxPro.xx
(c) Visual C++.
(d) Visual C#.
(e) Visual J#.

121

TI para concursos

200. (ICMS-SP 2009) A .NET Framework 3.0 o modelo de programao de cdigo gerenciado da Microsoft, que
200
integra os componentes da .NET Framework 2.0 s novas tecnologias
(a) WPF (Windows Presentation Foundation) e WCF (Windows Communication Foundation), apenas.
(b) WF (Windows Workflow Foundation) e Windows CardSpace, apenas.
(c) WPF, WCF e WF, apenas.
(d) WPF, WCF e Windows CardSpace, apenas.
(e) WPF, WCF, WF e Windows CardSpace.xx
201. (ICMS-SP 2009) O IDE do Visual Studio 2005 fornece suporte completo para publicao de aplicativos e para
201
atualizao de aplicativos implantados por meio diretamente do ClikOnce apenas para projetos criados com
xx
(a) Visual Basic, Visual C# e Visual J#.
(b) Visual Basic, Visual FoxPro e Visual C++.
(c) Visual Basic e Visual FoxPro.
(d) Visual C# e Visual J#.
(e) Visual C# e Visual C++.
202. (ICMS-SP 2009) A opo de escolha no Visual Studio 2005 para usar Web Forms como interface de usurio
202
no desenvolvimento de um aplicativo indica que o aplicativo dever ser implantado no
(a) servidor e que o .NET Framework dever ser executado tanto no servidor quanto no computador cliente.
(b) servidor, que o .NET Framework dever ser executado no servidor e que o computador cliente exigir
apenas um navegador.xx
(c) servidor e que o .NET Framework dever ser executado apenas no computador cliente e no no servidor.
(d) computador cliente e que o .NET Framework dever ser executado apenas no computador cliente e no
no servidor.
(e) computador cliente e que o .NET Framework dever ser executado tanto no servidor quanto no
computador cliente.
203. Uma ou mais instrues so executadas ou no, dependendo do resultado do teste efetuado. Esta afirmao
define uma estrutura de controle de programao do tipo 203
(a) pilha.
xx
(b) seleo.
(c) fila.
(d) repetio.
(e) seqncia.
204. A estrutura de dados de iterao na qual uma ao ser executada pelo menos uma vez, antes da avaliao
da condio, implementada pelo comando bsico204
(a) condicional.
(b) faa enquanto.
(c) seqencial.
(d) de repetio.xx
(e) de seleo.
205. Em uma hierarquia de classes possvel especificar operaes com a mesma assinatura em pontos diferentes
da hierarquia. Portanto, essas operaes presentes nas classes-filha 205
(a) anulam o comportamento das operaes existentes nas classes-me.xx
(b) herdam os atributos existentes nas classes-me.
(c) so composies de alguns atributos existentes nas classes-me.
(d) complementam o comportamento das operaes existentes nas classes-me.
(e) agregam as operaes existentes nas classes-me.
206. As instncias de uma classe so
(a) seus atributos.
(b) suas superclasses.
(c) suas operaes.
xx
(d) seus objetos.
(e) seus relacionamentos.

206

207. A nomenclatura da linguagem C++ para Chamada de Funo e Classe Base corresponde, respectivamente,
207
na programao orientada a objetos a
(a) Mtodo e Subclasse.
(b) Mtodo e Superclasse.
(c) Hereditariedade e Subclasse.
(d) Mensagem e Subclasse.
(e) Mensagem e Superclasse.xx
208. Em um diagrama entidade relacionamento, uma situao de composio tal qual "empregado gerencia
208
empregado", geralmente apresentada como
(a) entidade fraca.
(b) relacionamento associativo.
xx
(c) auto relacionamento.
(d) relacionamento interativo.
(e) relacionamento restritivo.

122

TI para concursos

209. A execuo de uma expresso lgica obedece como prioridade a ordem dos operadores
(a) Or, And e Not.
(b) Not, And e Or.xx
(c) And, Not e Or.
(d) And, Or e Not.
(e) Not, Or e And.

209

210. Respeitando as ordens de insero e de retirada dos dados, uma estrutura de 210
(a) fila tambm denominada LIFO ou LILO.
(b) fila tambm denominada FIFO ou FILO.
(c) fila tambm denominada FIFO ou LIFO.
(d) pilha tambm denominada FIFO ou FILO.
xx
(e) pilha tambm denominada LIFO ou FILO.
211. Uma fila dupla que se trata de uma lista linear na qual os elementos podem ser inseridos ou removidos de
qualquer extremo denomina-se211
(a) hashing.
(b) grafo.
xx
(c) deque.
(d) lista aberta.
(e) lista fechada.
212. Sobre a sintaxe XML, considere:
I. Um elemento <CALCULA> deve ter sempre uma tag de fechamento <FIMCALCULA>.
II. Uma tag <Lista> diferente da tag <lista>.
III. Um elemento <A> aberto no interior do elemento <B> pode ser fechado fora do elemento <B>.
212
Est correto o que consta APENAS em
(a) III.
(b) II.xx
(c) II e III.
(d) I e III.
(e) I e II.
213. Em
(a)
(b)
(c)
(d)
(e)

XML pode-se definir um atributo, como informao adicional ao elemento, conforme o exemplo abaixo:213
<funcionario> <sexo> masculino ...
<funcionario sexo=masculino> ...
<funcionario sexo="masculino">xx...
<funcionario> <sexo> "masculino" ...
<funcionario <sexo>= "masculino"> ...

214. NO um tipo de dados considerado primitivo:214


(a) real.
(b) inteiro.
(c) lgico.
(d) caracter.
(e) matriz.xx

123

TI para concursos

11

Sistemas Operacionais

11.1

Conceitos de administrao de servidores em plataforma Windows


A administrao de servidores Windows feita sobre uma interface grfica, com mouse, janelas e
botes. Nem por isto a tarefa se torna fcil. O usurio precisa saber em que cones clicar e que controles
modificar.
Administrar servidores em plataforma Windows instalar e manter em funcionamento os servios que a
rede necessita. Este servios so acessveis a partir do Painel de Controle e do menu Ferramentas
administrativas.
O primeiro servio que deve funcionar muito bem administrao de usurios, que consiste em criar
contas, que so identificadas por um nome de usurio (login) e atribuir direitos a eles. Para esta funo,
utiliza-se o aplicativo Contas de usurio, no painel de controle. Usurios com direitos de
administradores, conforme a sua configurao, podem fazer tudo, enquanto que usurio comuns s
podem usar recursos definidos pelo administrador.
O Windows administra os recursos da rede dividindo-a em subredes chamadas de domnios. Em cada
domnio h uma lista distinta de usurios e um servidor para controlar.
Um servidor na rede que centraliza a configurao de usurios em um domnio o Primary Domain
Controller (PDC), ou controlador primrio de domnio. Em uma rede pode haver diversos servidores
Windows, mas apenas um servidor primrio de domnio para cada domnio, sendo os demais Backup
Domain Controle (BDC), ou servidores de backup.
Os recursos oferecidos na rede esto, em geral, ligados a um computador. Este computador faz o papel
de servidor deste recurso, como servio de impresso, de conexo internet (proxy e firewall), de
armazenamento de dados etc. Mas a permisso de acesso a todos os servios passa pelo servidor
primrio do domnio.
Dois domnios diferentes podem se comunicar e os usurios de um ser autorizado pelo outro. Para isto o
Windows utiliza o conceito de relao de confiana, que estabelecido entre os dois domnios. Eles
passam a se comportar como um nico domnio, mas com duas lista de usurios.
O Windows utiliza o recurso Active Directory para administrar os domnios como se fossem uma
estrutura de diretrios, agrupando domnios em rvores e estas em florestas.

11.2

Conceitos de administrao de servidores em plataforma Linux


A administrao de servidores Linux feita, em geral, por linhas de comando digitadas em uma tela de
textos. Por isto, o administrador precisa saber os comandos e sua sitaxe. Existem programas que criam
interfaces grficas, chamados de shells, que facilitam a vida de usurios inesperientes.
Os servidores Linux com servios para internet so mais usados do que os demais sistemas por sua
estabilidade e confiabilidade. Assim so os servidores linux:
apache, servidor http, que adminstra pginas de internet,
proftpd, servidor ftp, para administrar transferncias de arquivos
Bind, servio dns, para administrao de nomes de domnios
Squid, servidor proxy, para controlar a entrada da rede e os acessos externos (firewall)

11.2.1

Alguns comandos no Linux


cp copia arquivos.
cp [opes] [origem] [destino]

mv move ou renomeia arquivos e diretrios. O processo semelhante ao do comando cp mas o


arquivo de origem apagado aps o trmino da cpia.
mv [opes] [origem] [destino]

chown muda dono de um arquivo/diretrio. Opcionalmente pode tambm ser usado para mudar o
grupo.
chown [opes] [dono.grupo] [diretrio/arquivo]

chmod usado para alterar permisses de arquivos (ou ficheiros) e diretrios (directrios ou pastas).
Sua sintaxe a seguinte:
chmod [permisses] arquivo
61

11.2.1.1 Gerenciando Usurios


Para adicionar um usurio:
http://apostilas.netsaber.com.br/apostilas/1662.pdf
124
61

TI para concursos

adduser <usurio>

Em seguida necessrio definir uma senha para este usurio, utilizando o comando:
passwd <usurio>

Para remover um usurio e seu diretrio home:


userdel -r usurio

Para obter as permisses de outros usurios:


su <usurio>

Se o campo <usurio> for omitido, o su intender como root. E para simular um login, executando os
scripts de inicializao do usurio acrescenta-se - entre su e o <usurio> , como no exemplo:
su - vinicius

11.2.1.2 Diretrio /etc


O diretrio /etc contm todas as configuraes do servidor, por isso deve-se conhecer todo o seu
contedo e tambm ter uma preocupao especial com as permisses de arquivos nele contidos:
passwd - ficam os usurios cadastrados no sistema. Cada linha corresponde a um usurio e o
caracter : separa os campos. Analisando o exemplo abaixo:
vinic:x:1001:0:Vinicius Schmidt,,,:/home/vinic:/bin/bash
login:Senha:Id:Gid:Nome e Dados:Diretrio:Shell
Login: a identificao do usurio que tambm pode ser usado para identificao do email.
Senha: x informa que a senha est em outro arquivo mais seguro.
Id: cdigo nico para o Linux identificar cada usurio. Nunca deve-se ter dois usurios com o mesmo
cdigo.
Gid: cdigo do grupo primrio que o usurio pertence.
Nome e Dados: usado para armazenar informaes sobre o usurio como nome, telefone, sala, etc..
Esses dados so separados por , e devem obedecer um padro.
Diretrio: informa qual o directrio home, do usurio.
Shell: shell default do usurio. Para usurios que no precisam de shell deve-se colocar /dev/null.

shadow - ficam gravadas todas as senhas (criptografadas) de acesso ao sistema.


group - descreve quais so os grupos do sistema. O primeiro campo corresponde ao nome do grupo,
o segundo campo a senha, o terceiro o chamado GID ou Group ID, e o prximo campo so os
usurios pertencentes a este grupo, observando que os mesmos so separados por ,.
Inittab - arquivo principal de inicializao do Linux, ele quem d inicio aos demais arquivos dentro
do diretrio /etc/rc.d . O modo mais usado o 3 que indica para iniciar todas as tarefas, mas
continuar no console. Existe tambm o modo 5 que entra com a tela de login j em modo grfico.
Veja detalhes no Apndice E, Nveis de Execuo no Red Hat Linux .
Fstab - configura os sistemas de arquivos montados durante o processo de inicializao do Linux.
Estabelece os pontos default de montagem do sistema. O arquivo /etc/fstab permite configurar o
sistema para montar parties, cdroms, disquetes e compartilhamentos de rede durante o boot. Cada
linha responsvel por um ponto de montagem.
login.defs - o arquivo de configuraes do login, possui informaes valiosas para melhorar a
segurana do seu ambiente. um arquivo muito simples de configurar pois baseado em exemplos,
e seus parmetros so simples.
Profile - Toda vez que um usurio loga, este arquivo executado, por isso ele usado para setar as
variveis de ambiente globais, dentre outras coisas.
hosts.deny - Hosts que no tem permisso para acessar a mquina.
hosts.allow - Hosts que tem permisso para acessar a mquina.
Services - Este arquivo descreve a relao entre os servios e as portas mais comuns.
11.2.1.3 Diretrios mais importantes:
/etc/rc.d - arquivos responsveis pela carga dos daemons na inicializao do Linux.
/etc/skel - arquivos que sero copiados para o home de um usurio recm criado.

11.2.2

Gerenciando a iniciao do Linux


O lilo e o grub disputam o posto de gerenciador de boot default entre as distribuies Linux. So os
responsveis pela carga do kernel do Linux na memria. Sem o gerenciador de boot o sistema
simplesmente no inicializa.
Muitas distribuies permitem que voc escolha entre usar o lilo ou o grub durante a instalao. Outras
usam um dos dois por padro. O grub oferece mais opes e inclui um utilitrio, o update-grub que gera
um arquivo de configurao bsico automaticamente. Por outro lado, a sintaxe do arquivo de

125

TI para concursos

configurao do grub mais complexa o que o torna bem mais difcil de editar manualmente que o do
lilo.
O lilo utiliza um nico arquivo de configurao, o /etc/lilo.conf. Ao fazer qualquer alterao neste arquivo
preciso chamar o executvel do lilo, o "/sbin/lilo" para que ele leia o arquivo e salve as alteraes..
O grub usa o arquivo de configurao /boot/grub/menu.lst. Este arquivo lido a cada boot, por isso no
necessrio reinstalar o grub ao fazer alteraes, como no caso do lilo.

11.2.3

Fazendo Backups
Realizar backups do sistema hoje em dia uma tarefa essencial de todo administrador. No Linux podese usar o comando tar para compactar os arquivos.
Sintaxe: tar [opes] [-f arquivo]
Opes:
x : descompactar.
t : lista o contedo de um arquivo.
v : mostra na tela o que est sendo feito.
z : descompacta arquivos que tambm estejam gzipados .
f : especifica o nome do arquivo.
c : cria um novo arquivo.

Exemplos:
tar cvzf meu_backup.tgz ~
tar cvzf backup.tgz /home
tar xvzf /root/backup.tar.gz

11.2.4

(faz o backup de sua rea pessoal)


(faz o backup da rea dos usurios )
(descompacta o backup)

Recompilando e Adaptando o Kernel


Os administradores devem se preocupar em manter a mquina mais enxuta possvel e para isso deve-se
recompilar o kernel apenas com o necessrio. Uma sugesto a separao em mdulos, o que sem
dvida reduzir o peso da mquina. Para recompilar o kernel deve-se baixar o fonte de uma verso
estvel no site http://www.kernel.org ou um mirror confivel.
O fonte deve ser descompactado no diretrio /usr/src. No diretrio /usr/src/linux devem ser feitos alguns
procedimentos:
make menuconfig - Entra no modo de configurao do kernel. Um ambiente amigvel de fcil
compreenso onde se pode marcar os pacotes que sero usados.
make dep - Acerta as dependncias das bibliotecas necessrias para a compilao.
make - Compila o kernel.
make modules - Compila os mdulos.
make install - Instala o kernel.
make modules_install - Instala os mdulos.

11.2.5

Agendando Processos
Para agendar processos muito demorados como o download de um arquivo muito grande, ou qualquer
outro processo que necessite de uma execuo automtica, deve-se usar basicamente dois comandos:
at - agenda a execuo de um comando e logo depois que esse processo ocorre este comando no ser
mais executado
crontab - agenda processos que devem rodar periodicamente.

11.2.6

Syslogd - A Caixa Preta do Linux


Para analisar o que vem ocorrendo ou j ocorreu no sistema, o linux possui o syslogd, que funciona
como uma caixa preta, guardando em arquivos, informaes como: data e hora do boot, login de usurio
e outros dados importantes para analisar o servidor.
O arquivo responsvel pelas configurao do syslogd o /etc/syslog.conf .
Os registros deste arquivo so divididos em facility, priority e destino, podendo haver derivaes como
dois conjuntos facility.priority para um mesmo destino.
As facilities podem ser: auth, auth-priv, cron, daemon, kern, lpr, mail, mark, news, security (mesmo que
auth), syslog, user, uucp e local0.
J as priorities seguem em ordem crescente: debug, info, notice, warning, warn (memo que warning),
err, error (mesmo que err), crit, alert, emerg, panic (mesmo que emerg).
Um arquivo gerado na grande maioria dos sistemas *nix o /var/log/messages, que contm informaes
genricas sobre todo o sistema.
Outro arquivo muito comum o /var/log/debug que contm informaes mais detalhadas.

126

TI para concursos

11.2.7

Tcnicas Bsicas para Trabalhar com Redes (ifconfig, route)


O Linux um sistema operacional totalmente compatvel com redes, dos tipos mais heterogneos.
Para listar as interfaces de rede usa-se o comando:
ifconfig -a

Para atribuir um endereo IP para uma interface usa-se:


ifconfig eth0 <endereo> broadcast <broadcast> netmask <mascara>

Tambm existem as rotas para o pacote IP poder sair para fora da rede local, caso haja um roteador.
Para exibir a tabela de rotas usa-se o comando:
route -n ou netstat -nr

Para adicionar uma rota:


route add default gw <Gateway> netmask 0.0.0.0 metric 1

E caso haja a necessidade de excluir uma rota usa-se:


route del <destino>

11.2.8

Gerenciando os Servios - inetd


O inetd um daemon que pode gerenciar outros daemons, tendo uma funo de supervisor. Este
supervisor executado sempre na carga do sistema, e busca a lista de servios que devem passar pelo
inetd no arquivo /etc/inetd.conf.

11.2.9

Utilizando Ferramentas de Busca


Para deixar o sistema em dia, com pacotes sempre atualizados, sugere-se a pesquisa contnua nos
vrios sites que oferecem tais pacotes.
Ex.: http://www.freshmeat.net

11.2.10 Instalando SSh / SShD


O telnet antigamente era muito usado para obter acesso remoto de um servidor, mas o grande problema
do telnet que os pacotes de dados passam limpos (no criptografados) pela rede possibilitando um
ataque, captura de todos os pacotes que percorrem na rede, inclusive senhas, nmeros de carto de
crdito etc.
A soluo encontrada pelos profissionais de segurana e administradores foi a substituio do telnet
por ssh, que criptografa os dados dos pacotes, impossibilitando a sua fcil compreenso.
Para instalar o SSh deve-se baixar o pacote de algum lugar, tendo o cuidado de se baixar o produto de
instituies com reconhecida credibilidade, pois do contrrio, corre-se um srio risco de baixar trojan
horse. Depois de pegar o pacote:
tar xvzf ssh-1.2.27.tar.gz

Depois, apenas mais trs comandos dentro do diretrio do ssh-1.2.27:


./configure ; make ; make install

O SSh j est instalado agora para colocar seu daemon no /etc/rc.d/rc.local:


echo /usr/local/sbin/sshd >> /etc/rc.d/rc.local

rc.local: Este arquivo executado sempre na hora do boot, como o Autoexec.bat do DOS

11.3

Conceitos de Virtualizao
Virtualizao a tcnica que permite particionar um nico sistema computacional em vrios outros
denominados de mquinas virtuais. Cada mquina virtual oferece um ambiente completo muito similar a
uma mquina fsica. Com isso, cada mquina virtual pode ter seu prprio sistema operacional,
aplicativos e servios de rede (Internet). possvel ainda interconectar (virtualmente) cada uma dessas
mquinas atravs de interfaces de redes, switches, roteadores e firewalls virtuais, alm do uso j
62
bastante difundido de VPN (Virtual Private Networks).
A virtualizao pode auxiliar a se trabalhar em um ambiente onde haja uma diversidade de plataformas
de software (sistemas operacionais) sem ter um aumento no nmero de plataformas de hardware
(mquinas fsicas). Assim, cada aplicao pode executar em uma mquina virtual prpria, possivelmente
incluindo suas bibliotecas e seu sistema operacional que, por sua vez, executam em uma plataforma de
hardware comum.
Ao se executar mltiplas instncias de mquinas virtuais em um mesmo hardware, tambm se est
proporcionando um uso eficiente de seu poder de processamento. Essa situao comumente
denominada de consolidao de servidores e especialmente interessante em data centers devido a

http://www.gta.ufrj.br/ensino/CPE758/artigos-basicos/cap4-v2.pdf
127
62

TI para concursos

heterogeneidade de plataformas inerente ao prprio negcio. Alm disso, em data centers, a diminuio
de mquinas fsicas implica na reduo de custos de infra-estrutura fsica como espao, energia eltrica,
cabeamento, refrigerao, suporte e manuteno a vrios sistemas.
A flexibilidade e a portabilidade das mquinas virtuais tambm tornam interessante o uso da virtualizao
em desktops. possvel imaginar, por exemplo, o desenvolvimento de produtos de software destinados
a vrios sistemas operacionais sem ter a necessidade de uma plataforma fsica para desenvolver e
testar cada um deles. Assim, as mquinas virtuais em desktops podem ser usadas para se definir
ambientes experimentais sem comprometer o sistema operacional original da mquina, ou ainda, para
compor plataformas distribudas como clusters e grades computacionais.
As mquinas virtuais, por emularem um ambiente computacional sobre outro, impem algumas
restries de implementao e de desempenho. aqui que entra o desenvolvimento dos produtos de
software para a virtualizao.
As mquinas virtuais podem ser:
mquina virtual de processo aplicao sobre um sistema operacional
hypervisor ou monitor de mquina virtual camada de software posicionada entre o hardware da
mquina e o sistema operacional por duas tcnicas:
para-virtualizao o sistema hspede modificado para chamar a VMM sempre que for executada uma
instruo ou ao considerada sensvel. Dessa forma, o teste por instruo no necessrio. Os
dispositivos de hardware so acessados por drivers da prpria VMM. A substituio da chamada de uma
instruo sensvel pela chamada a um tratador de interrupo de software (trap) chamado de hypercall.
virtualizao total rplica do hadware subjacente de tal forma que o sistema operacional e as aplicaes
podem executar como se tivessem executando diretamente sobre o hardware original. A grande
vantagem dessa abordagem que o sistema operacional hspede no precisa ser modificado para
executar sobre a VMM.

Sistema operacional a camada de software inserida entre o hardware e as aplicaes que executam
tarefas para os usurios e cujo objetivo tornar a utilizao do computador, ao mesmo tempo, mais
eficiente e conveniente.
A utilizao mais eficiente busca um maior retorno no investimento feito no hardware. Maior eficincia
significa mais trabalho obtido pelo mesmo hardware. Isso obtido atravs da distribuio de seus
recursos (espao em memria principal, processador, espao em disco etc) entre diferentes programas.
Cada programa tem a iluso de estar executando sozinho no computador quando na realidade ele est
compartilhando com os demais. Uma utilizao mais conveniente do computador obtida, escondendose do usurio detalhes de hardware, em especial, dos perifricos de entrada e sada. Tipicamente, isso
feito atravs da criao de recursos de mais alto nvel oferecido atravs de interfaces grficas. Por
exemplo, os usurios usam espao em disco atravs do conceito de arquivos. Arquivos no existem no
hardware. Eles formam um recurso criado a partir do que o hardware oferece. Genericamente, isso
denominado de virtualizao de recursos.
O elemento central de um computador seu processador. Cada processador tem um conjunto de
instrues de mquina que pode seguir um determinado padro. Por exemplo, Intel e AMD, fabricam
processadores que implementam um mesmo padro ISA, o Intel IA-32 (x86). Os projetistas de software
compilam seu programas para obter cdigos binrios para um determinado ISA. Portanto, o conjunto de
instrues (ISA) uma interface entre o hardware e o software.
Tipicamente, um sistema de computao oferece trs tipos de interfaces:
instrues de mquina (privilegiadas) - interface que permite que apenas alguns programas, os com
privilgios especiais, como o sistema operacional, possam executar todas as instrues, entre elas, as de
manipulao de recursos de hardware, como entrada e sada e interrupes.
instrues de mquina (no privilegiadas) e chamadas de sistema - interface que possibilita que um
programa de usurio execute instrues no-privilegiadas diretamente no processador, mas no permite
o acesso aos recursos de hardware (instrues privilegiadas). As chamadas de sistema so uma forma
de permitir que os programas de usurios acessem de forma indireta, e controlada, os recursos de
hardware. Atravs delas, os programas de usurio executam, aps ter sido garantido a autenticidade e a
validade da operao, operaes de acesso a recursos de hardware (tipicamente E/S).
interface aplicativa de programao mais conhecida como API (Application Program Interface), so
funes de biblioteca que fazem com que as chamadas de sistema sejam ocultadas.

Considerando essas interfaces, a implementao de mquinas virtuais pode ser feita de trs modos:
programa de aplicao que fornee um ambiente de execuo para outras aplicaes. Esse ambiente
pode possuir um conjunto de instrues abstratas que so interpretadas para gerar as instrues de
mquinas no-privilegiadas, as chamadas de sistema e de API de bibliotecas que correspondem
ao abstrata desejada. o caso da mquina virtual java (JVM).
programa de aplicao que emula chamadas de sistemas de outro sistema operacional, como ocorre
quando se executa Linux em sistemas Windows com a ferramenta VMware player . Esse tipo de
virtualizao o que se denomina de mquina virtual de processo.
128

TI para concursos

camada de software entre o hardware e o sistema operacional protegendo o acesso direto deste aos
recursos fsicos da mquina. Essa camada oferece como interface ao sistema operacional um
conjunto de instrues de mquina que pode ser o mesmo do processador fsico, ou um outro. O
ponto importante que essa interface deve estar disponvel sempre que o computador estiver ligado
e que ela possa ser usada simultaneamente por diferentes programas. O resultado final que
possvel ter diversos sistemas operacionais (programas) executando independentemente na mesma
plataforma. Genericamente, essa mquina virtual referenciada como monitor de mquina virtual
(Virtual Machine Monitor ou VMM), tambm conhecido como hypervisor, ou ainda, mquina virtual de
sistema.
O processo ou sistema que executa sobre uma mquina virtual denominado de hspede, enquanto o
ambiente sobre o qual ele executa chamado de hospedeiro.
Os fabricantes de processadores, AMD e Intel, desenvolveram extenses para a arquitetura x86 para
suportarem a virtualizao:
Pacfica AMD-V (AMD-Virtualization), se aplica s arquiteturas x86 de 64 bits como o Athon, Turion,
Phenom e as linhas mais recentes. A AMD implementa funes especiais no processador que so
executadas por um hypervisor e que podem controlar, em seu nome, se determinados acessos de um
sistema hspede so permitidos.
Vanderpool IVT (Intel Virtualization Technology) para as arquiteturas x86 de 32 e 64 bits. A Intel
introduziu mecanismos similares (virtual machines extensions) que complementam a idia do
conceito de anis de proteo com dois novos modos: root e no-root. Esses modos so controlados
pelo hypervisor (que executa em modo root) e que pode transferir a execuo de um sistema
operacional hspede para o modo no-root no qual instrues do anel zero so executadas sem risco
para o sistema.
As solues da AMD e da Intel foram desenvolvidas independentemente uma da outra e so
incompatveis, embora sirvam para o mesmo propsito.
Existem diversas solues comerciais, gratuitas, em software livre ou integradas a sistemas
operacionais. Entre as mais conhecidas destacam-se o VMware e o Xen
O VMware uma infra-estrutura de virtualizao completa com produtos abrangendo desde desktops a
data centers organizados em trs categorias:
gesto e automatizao, forma automatizada e centralizada de gerncia de todos os recursos da
infra-estrutura virtual permitindo a monitorao do sistema, auxiliando na converso de sistemas
fsicos em virtuais, na recuperao de desastres, entre outros.
infra-estrutura virtual, monitorao e alocao de recursos entre as mquinas virtuais de forma a
atender requisitos e regras de negcios. Solues para alta disponibilidade, backup, migrao de
mquinas virtuais e atualizao de verses de software.
virtualizao de plataformas, destinado a criar mquinas virtuais.
O Xen um monitor de mquina virtual (hypervisor ou VMM), em software livre, licenciado nos termos da
GNU General Public Licence (GPL), para arquiteturas x86, que permite vrios sistemas operacionais
hspedes serem executados em um mesmo sistema hospedeiro. O Xen originrio de um projeto de
pesquisa da universidade de Cambridge, que resultou em um empresa, a XenSource inc, adquirida pela
CitrixSystem em outubro 2007.
Os dois principais conceitos do Xen so:
domnios - mquinas virtuais do Xen e so de dois tipos:
privilegiada (domnio 0) - mquina virtual nica que executa um ncleo linux modificado e que possu
privilgios especiais para acessar os recursos fsicos de entrada e sada e interagir com as demais
mquinas virtuais (domnios U). Por ser um sistema operacional modificado, possui os drivers de
dispositivos da mquina fsica e dois drivers especiais para tratar as requisies de acesso a rede e ao
disco efetuados pelas mquinas virtuais dos domnios U.
no-privilegiada (domnio U)

hypervisor - controla os recursos de comunicao, de memria e de processamento das mquinas


virtuais e no possui drivers de dispositivos. O hypervisor Xen no capaz de suportar nenhum tipo
de interao com sistemas hspedes, necessrio que exista um sistema inicial para ser invocado
pelo hypervisor. Esse sistema inicial o domnio 0. As outras mquinas virtuais s podem ser
executadas depois que ele for iniciado. As mquinas virtuais de domnio U so criadas, iniciadas e
terminadas atravs do domnio 0.
O Virtual PC 2007 uma mquina virtual para famlia Windows que pode ser configurada para executar
qualquer outro sistema operacional. O Virtual PC oferece mecanismos para interconectar logicamente as
diferentes mquinas virtuais. Cada mquina virtual tem seu prprio endereo MAC e endereo IP. Alm
disso, o Virtual PC oferece um servidor de DHCP, um servidor NAT e switches virtuais. Dessa forma,
possvel construir cenrios de rede usando mquinas virtuais. O virtual PC 2007 disponvel para
download, assim como um white paper que ensina a configurar as mquinas virtuais e um ambiente de
rede.
129

TI para concursos

O Windows 2008 Server Hyper-V explora eficientemente as arquiteturas de 64 bits, processadores


multicore e meios de armazenamento e oferece todo um ambiente integrado de gerenciamento da
virtualizao (monitorao, automatizao de procedimentos, migrao, recuperao de desastres etc).
Entre as principais vantagens do Windows 2008 Server Hyper-V esto vrias ferramentas para
automatizar o processo de virtualizao. Uma delas o Manager Physical-to-virtual (P2V) que auxilia na
converso de servidores fsicos para virtuais. H tambm o Volume Shadow Copy Services que realiza
automaticamente procedimentos de backup e de disponibilidade de forma que o sistema, como um todo,
opere de forma homognea independente de falhas e de picos de carga. Isso feito por tcnicas de
migrao de mquinas virtuais.

11.4

Active Directory
Software da Microsoft utilizado em ambientes Windows, o Active Directory uma implementao de
servio de diretrio no protocolo LDAP que armazena informaes sobre objetos em rede de
63
computadores e disponibiliza essas informaes a usurios e administradores desta rede.
O "diretrio ativo" permite que os administradores atribuam empresa polticas largas, ofeream
programas a muitos computadores, e apliquem updates crticos a uma organizao inteira. Uma
informao ativa e ajustes das lojas do diretrio que relacionam-se a uma organizao em uma central,
base de dados organizada, acessvel.
O Active Directory est relacionado :
Gerenciamento centralizado
GPO Polticas de Grupo
Catlogo Global
Gerenciamento de Desktop Intellimiror
Distribuio de Software Automtica
Interface de acesso ADSI
Compatibilidade com sistemas operacionais MS Legados
Administrao Delegada
Replicao Automtica
O Active Directory (AD) surgiu da necessidade de se ter um nico diretrio um banco de dados que
armazena as informaes dos usurios, grupos, senhas, contas de computadores, relaes de
confiana, informaes sobre o domnio, unidades organizacionais etc onde os usurios podero ter
apenas uma senha para acessar todos os recursos disponveis na rede.
Disponibiliza vrios servios, como: autenticao dos usurios, replicao do seu banco de dados,
pesquisa dos objetos disponveis na rede, administrao centralizada da segurana utilizando GPO,
entre outros servios.
O AD organizado de uma forma hierrquica, com o uso de domnios. Um domnio um limite
administrativo com diferentes administradores e diferentes polticas de segurana.
Domnios baseados no AD pussuem os seguintes recursos:
Logon nico: com esse recurso, o usurio necessita fazer apenas um logon para acessar os recursos
em diversos servidores da rede, inclusive email e banco de dados.
Conta de usurio nica: os usurios possuem apenas um nome de usurio para acessar os recursos
da rede. As contas de usurios ficam armazenadas no banco de dados do AD.
Gerenciamento centralizado: com os domnios baseados no AD, temos uma administrao
centralizada. Todas as informaes sobre contas de usurios, grupos e recursos da rede, podem ser
administradas a partir de um nico local no domnio.
Escalonabilidade: os domnios podem crescer a qualquer momento, sem limite de tamanho. A forma
de administrao a mesma para uma rede pequena ou grande.
Nos domnios baseados no AD, podemos ter dois tipos de servidores:
Controlador de Domnio (DC Domain Controller): o servidor que possui o AD instalado. Em um
mesmo domnio podemos ter mais de um Controlador de Domnio. As alteraes efetuadas em um
DC so replicadas para todos os outros DCs. So os DCs quem fazem a autenticao dos usurios
de um domnio. Um destes DC eleito o controlador primrio do domnio (PDC). Quando ele sai da
rede, um controlador secundrio assume a funo.
Servidor Membro (Member Server) ou estao de trabalho (workstation): um computador que no
possui uma cpia do AD, porm tem acesso aos objetos do AD. No fazem a autenticao dos
usurios.
O AD utiliza o DNS para a nomeao de servidores e recursos, e tambm para resoluo de nomes.

http://pt.wikipedia.org/wiki/Active_Directory
130
63

TI para concursos

Esquema um conjunto de regras que define as classes de objetos e atributos contidos no diretrio, as
restries e os limites das ocorrncias desses objetos e o formato de seus nomes, que est includo no
Active Directory.
Com a utilizao de domnios, a rede pode refletir a estrutura de uma empresa. Diversos domnios
podem se interligar atravs do estabelecimento de relao de confiana, que permite aos usurios de
ambos os domnios acessar seus recursos. No Windows 2000, as relaes de confianas so
bidirecionais e transitivas, ou seja, se o domnio X confia no domnio Y, e Y confia no domnio W, o
domnio X tambm confia no domnio W.
Algumas caractersticas prprias de cada domnio:
Um domnio armazena informaes somente dos objetos do prprio domnio.
Um domnio possui suas prprias diretivas de segurana

11.5

Exerccios
215. (ICMS-SP 2009) Na arquitetura do sistema operacional Windows XP, o Executivo expe servios aos
215
processos usurios por meio
(a) dos Drivers de dispositivo.
(b) das DLL.
xx
(c) da API nativa.
(d) do Gerenciador de objeto.
(e) do Gerenciador de E/S.
216. (ICMS-SP 2009) NO uma caracterstica do Active Directory do Windows XP:216
(a) Um servio de rede que permite aos usurios compartilhar informaes, recursos e objetos por meio de
rede.
(b) Servios de diretrio para objetos compartilhados em uma rede, por exemplo: arquivos, impressoras,
usurios etc.
(c) Um servio de acesso remoto que permite aos usurios se conectarem remotamente com uma LAN.xx
(d) O cliente LDAP Protocolo Leve de Acesso a Diretrio, para pesquisar e modificar diretrios de Internet,
pode acessar o Active Directory.
(e) As localizaes dos objetos so transparentes, ou seja, os usurios no sabem o endereo de um objeto.
217. (ICMS-SP 2009) Os mecanismos IPC disponveis, tais como Sinais, Pipes, Soquetes, Mensagens, Memria
compartilhada e Semforos de System V, so implementados no ncleo do Linux pelo subsistema primrio217
(a) Sistemas de arquivos.
(b) Sistema de comunicao interprocessos.xx
(c) Gerenciador de processo.
(d) Gerenciador de memria.
(e) Gerenciador de E/S.
218. Para configurar e gerenciar o processo de inicializao (boot) de um computador com o sistema operacional
218
Linux, pode-se utilizar o LILO ou o
(a) INIT
(b) BOOT.
(c) LINX.
(d) LOAD
(e) GRUBxx
219. O Windows Server 2003 fornece vrias ferramentas que podem ser usadas para gerenciar arquivos e pastas.
A respeito das prticas recomendadas, quando se trata de pastas compartilhadas, analise as afirmativas a
seguir:
I. A atribuio de permisses a grupos simplifica o gerenciamento dos recursos compartilhados, pois se pode
adicionar ou remover usurios nos grupos sem precisar reatribuir as permisses.
II. As permisses compartilhadas se aplicam somente aos usurios que acessam os recursos compartilhados
na rede e no a usurios que fazem logon localmente.
III. Na implementao das ferramentas, a descentralizao das pastas de dados facilita o backup dos dados e
219
o gerenciamento do compartilhamento.
Assinale:
(a) se somente a afirmativa I estiver correta.
xx
(b) se somente as afirmativas I e II estiverem corretas.
(c) se somente as afirmativas I e III estiverem corretas.
(d) se somente as afirmativas II e III estiverem corretas.
(e) se todas as afirmativas estiverem corretas.
220. Um conjunto de regras que define as classes de objetos e atributos contidos no diretrio, as restries e os
limites das ocorrncias desses objetos e o formato de seus nomes, que est includo no Active Directory,
denomina-se220
(a) floresta.
(b) domnio.
(c) diretiva de grupo.
xx
(d) esquema.
(e) catlogo global.

131

TI para concursos

221. Quando se elimina o n raiz de uma estrutura em rvore, o que dela restar forma
(a) outra rvore.
(b) uma floresta.xx
(c) uma rvore binria.
(d) uma sub-rvore.
(e) um conjunto de sub-rvores.

221

222. Obtidas as permisses de acesso a um arquivo GNU/Linux: rw-r-xr-x Trata-se de um arquivo do tipo222
(a) normal, cuja execuo permitida ao dono, aos usurios do grupo user e aos outros usurios do arquivo.
xx
(b) normal, cujas alterao ou "deleo" so permitidas apenas ao dono do arquivo.
(c) normal, cujas alterao ou "deleo" so permitidas ao dono do arquivo ou aos usurios do grupo user do
arquivo.
(d) diretrio, cujas leitura, gravao e execuo so permitidas apenas ao dono do arquivo.
(e) diretrio, cujas leitura e execuo so permitidas ao dono, aos usurios do grupo user e aos outros
usurios do arquivo.
223. O Kernel do Linux deve ser descompactado no diretrio223
xx
(a) /usr/src, aps login como root.
(b) /root/src, aps login como user.
(c) /sys/src, aps login como root.
(d) /home, aps login como wrapper.
(e) /boot, aps login como kewl.
224. Para diversas partes de um programa serem executadas ao mesmo tempo, um sistema operacional utiliza uma
tecnologia de224
(a) multitarefa.
(b) camadas.
(c) threads.xx
(d) particionamento.
(e) multiprocessamento.

132

TI para concursos

12

Redes

12.1

Conceito de rede
Rede de computadores um conjunto de computadores interligados por qualquer meio e que se
comunicam por uma codificao determinada (protocolo de rede). Existem diversos protocolos de rede,
mas o mais utilizado atualmente o protocolo TCP/IP, transfer control protocol internet protocol.
Computadores que se comunicam em um sistema fechado, esto em uma rede local (LAN). Quando
duas ou mais redes se ligam em um espao mais amplo, diz-se que esto em uma rede WAN. Existem
milhes de computadores no mundo interligados em rede por um protocolo chamado TCP/IP, formando
uma nica rede chamada de internet.
O meio de ligao entre os computadores (estaes de trabalho) e a forma da disposio das conexes
so camados de topologia da rede. Cabos metlicos, fibras ticas ou comunicao sem fios formam os
enlaces entre computadores, ou entre computadores e outros equipamentos que fazem o papel de ns
que recebem e distribuem os sinais na rede.
A topologia de uma rede de comunicao refere-se forma como os enlaces fsicos e os ns esto
organizados, determinando os caminhos fsicos existentes e utilizveis entre quaisquer pares de
estaes conectadas a essa rede. A topologia de uma rede muitas vezes caracteriza o seu tipo,
eficincia e velocidade.
Malha (fully) - A interconexo total garantindo alta confiabilidade, porm a complexidade da
implementao fsica e o custo inviabilizam seu uso comercial;
Estrela (star) - A conexo feita atravs de um n central que exerce controle sobre a comunicao.
Sua confiabilidade limitada confiabilidade do n central, cujo mau funcionamento prejudica toda a
rede;
Barramento (bus) - As estaes so conectadas atravs de um cabo com difuso da informao para
todos os ns. necessria a adoo de um mtodo de acesso para as estaes em rede
compartilharem o meio de comunicao, evitando colises. de fcil expanso, mas de baixa
confiabilidade, pois qualquer problema no barramento impossibilita a comunicao em toda a rede;
Anel (ring) - O barramento toma a forma de um anel, com ligaes unidirecionais ponto a ponto. A
mensagem repetida de estao para estao at retornar estao de origem, sendo ento retirada
do anel. Como o sinal recebido por um circuito e reproduzido por outro h a regenerao do sinal no
meio de comunicao; entretanto h tambm a insero de um atraso a cada estao. O trfego passa
por todas as estaes do anel, sendo que somente a estao destino interpreta a mensagem;
rvore (tree) - a expanso da topologia em barra herdando suas capacidades e limitaes. O
barramento ganha ramificaes que mantm as caractersticas de difuso das mensagens e
compartilhamento de meio entre as estaes;
Mistas (mesh) - Combinam duas ou mais topologias simples. Alguns exemplos so o de estrelas
conectadas em anel e as rvores conectadas em barramento. Procuram explorar as melhores
caractersticas das topologias envolvidas, realizar a conexo em um barramento nico de mdulos
concentradores aos quais so ligadas as estaes em configuraes mais complexas e mais confiveis.

12.1.1

Configurao de redes TCP-IP


Em uma rede de computadores que utiliza o protocolo TCP-IP, existem determinadas prticas de
configurao que permitem que se usufrua da internet sem perder a rede local suas caractersticas e
segurana.
A cada equipamento conectado fisicamente na rede atribui-se um nmero chamado de endereo IP.
Este nmero formado por quatro nmeros de 0 a 255 separados por pontos. Por exemplo,
192.168.1.23 ou 10.10.0.128 so endereos IP vlidos e 175.268.1.0 no vlido, pois contm um
nmero maior do que 255.

133

TI para concursos

Estes nmeros so, na verdade, uma representao decimal, pois a rede enxerga estes endereos como
quatro grupos de oito nmeros binrios (0 ou 1) ou octetos. Para transformar um nmero decimal em
binrio, faz-se a diviso inteira daquele por sete vezes, ento toma-se os restos das divises em ordem
contrria:
Por exemplo, dividindo-se 244 por dois e guardando o resto da diviso:
div 2 sobra
244
0
122
0
61
1
30
0
15
1
7
1
3
1
1
1
temos que o nmero 244 do sistema decimal representado por 11110100 no sistema binrio.

Em uma rede local, sem conexo com outras redes que utilizam o protocolo TCP-IP, qualquer endereo
vlido pode ser atribuda a qualquer computador. Porm, isto pode dificultar a sua manuteno e
prejudicar seu desempenho quando o nmero de computadores na rede aumentar.
O IP, elemento comum encontrado na internet pblica, descrito no documento RFC 791 (Request for
Comments) da IETF (Internet Engineering Task Force), que foi pela primeira vez publicado em Setembro
de 1981. Esta verso do protocolo designada de verso 4, ou IPv4. O IPv6 tem endereamento de
origem e destino de 128 bits, oferecendo mais endereamentos que os 32 bits do IPv4, com previso de
ser padro na internet a partir de 2011.
Originalmente, o espao do endereo IP foi dividido em poucas estruturas de tamanho fixo chamados de
"classes de endereo". As trs principais so a classe A, classe B e classe C. Examinando os primeiros
bits de um endereo, o software do IP consegue determinar rapidamente qual a classe, e logo, a
estrutura do endereo.
Classe A: Primeiro bit 0 (zero)
00000000.00000000.00000000.00000000 at 01111111.11111111.11111111.11111111 ou 0.0.0.0

at 127.255.255.255

Classe B: Primeiros dois bits so 10 (um, zero)


10000000.00000000.00000000.00000000 at 10111111.11111111.11111111.11111111 ou 128.0.0.0

at 191.255.255.255

Classe C: Primeiros trs bits so 110 (um, um, zero)


11000000.00000000.00000000.00000000 at 11011111.11111111.11111111.11111111 ou 192.0.0.0

at 223.255.255.255

Classe D: (endereo multicast): Primeiros quatro bits so: 1110 (um, um, um, zero)
11000000.00000000.00000000.00000000 at 11011111.11111111.11111111.11111111 ou 224.0.0.0 at 239.255.255.255

Classe E: (endereo especial reservado): Primeiros cinco bits so 11110 (um, um, um, um, zero)
11000000.00000000.00000000.00000000 at 11011111.11111111.11111111.11111111 ou 240.0.0.0 at 247.255.255.255

Existem classes especiais na Internet que no so consideradas pblicas, no so consideradas como


endereveis.
So reservados para a comunicao em uma rede privada os endereos que comeam com 10.0.0.0, e
192.168.0.0 e os endereos na faixa 172.16.0.0 at 172.31.255.254.
reservado para representar o computador local ("localhost") a faixa de endereos 127.0.0.0 a
127.255.255.255. Um computador usa qualquer destes endereos para designar a ele mesmo, como o
pronome pessoal eu.
reservado para representar rede corrente o endereo 0.0.0.0. Um computador usa este endereo para
designar a prpria rede.

A utilizao destes endereos torna o computador inacessvel por outros computadores na internet, o
que representa uma segurana. Por outro lado, para acessar a internet, a rede local precisa de pelo
menos um equipamento com um endereo pblico no reservado. Este equipamento pode fazer a
ligao entre a rede e a internet, ou roteamento. Pode ser um roteador ou um computador.
O endereo IP tem a funo de identificar o computador, que chamamos de host, e tambm a rede em
que est conectado. O roteamento dos pacotes enviados na rede TCP/IP feito procurando a rede e
depois o host (equipamento). Os bits esquerda so utilizados para a rede. A quantidade de bits
utilizada definida pelo administrador da rede por um nmero chamado de mscara de rede ou
netmask. O netmask um conjunto de quatro octetos, como um endereo IP, iniciado por um grupo de
uns esquerda e outro grupo com zeros direita.
Uma rede com endereos que comece com 192.168 e netmask 255.255.0.0, por exemplo, pode ter at
255x255=65536 endereos. O primeiro (192.168.0.0) reservado para identificar a prpria rede e o
ltimo (192.168.255.255) usado para distribuir dados para toda a rede (broadcast), os demais 65534
endereos so para os hosts. Todas as informaes de todos os computadores nesta rede vai ser
inviada para todos os computadores, gerando colises que podem tornar a rede muito lenta.
134

TI para concursos

Para minimizar este problema, uma rede pode ser dividida em vrias subredes alterando-se o natmask.
Um netmask 255.255.255.0 vai reduzir o nmero de endereos em cada rede para apenas 256 (254 para
hosts) e aumentar o nmero de redes em 256 vezes. Cada subrede recebe um endereo para ser
identificada e outro para o broadcast a partir de operaes lgicas entre a mscara de rede (netmask) e
cada endereo de cada equipamento.
Por exemplo, uma net mask pode ser 11111111. 11111111. 11111111.00000000, representada por 255.255.255.0.

A identificao de rede de um endereo IP dada pela operao lgica ^ (e/and) entre a mscara e o
endereo. Nesta operao, comparam-se os octetos posio a posio, sendo atribuido o valor zero se
um dos dgitos for zero, ou valor um em caso contrrio.
Um endereo 192.168.1.101 E uma mscara 255.255.255.0 produz o endereo 192.168.1.0, que identifica a rede.

A identificao de rede do broadcast obtido pelo operao lgica v (ou/or) entre a negao da mscara
e o endereo.
Um endereo 192.168.1.101 OU uma mscara 255.255.255.0 produz o endereo 192.168.1.255, que identifica o broadcast.

O netmask no precisa usar somente grupos completos de oito bits. Desde que no haja buracos,
pode-se tomar mais algums bits.
Uma net mask pode ser 11111111. 11111111. 11111111.10000000, representada por 255.255.255.128, e um endereo, por exemplo,
192.168.1.132/25, dentro desta subrede ser representada com o nmero de bits da mscara sua direita, neste caso 25 (8+8+8+1).
Neste exemplo, o nmero de endereos se reduziu para 128 (126 para hosts) e o nmero de redes aumentou em 128 vezes.

Assim, podem ser criadas subredes com 128 endereos (126 hosts), 64, 32, 16, 8, 4 ou 2 endereos
(que no seve para nada). A conta de quantos hosts podem haver em uma subnet dois elevado ao
nmero de zeros na netmask menos dois: hosts=2n-2. O nmero de subredes dois elevado ao nmero
n
de uns do octeto incompleto: redes=2 .
Na nossa net mask 11111111. 11111111. 11111111.10000000, com sete zeros, teremos 27-2=126 endereos para hosts e 21=2 para
subredes.
Em uma net mask 11111111. 11111111. 11111111.11100000, com cinco zeros, teremos 25-2=30 endereos para hosts e 23=8 subredes.

Com isto tudo, o acesso de um equipamento a outro na mesma subrede direta e rpida, enquanto que
computadores em redes distintas s conseguem se comunicar de forma remota.

12.2

Arquitetura de Rede
Arquitetura de rede como se designa um conjunto de camadas e protocolos de rede. A especificao
de uma arquitetura deve conter informaes suficientes para permitir que um implementador desenvolva
programas ou construa o hardware de cada camada, de forma que ela obedea corretamente ao
protocolo adequado.64
ISO foi uma das primeiras organizaes a definir formalmente uma forma comum de conectar
computadores. Sua arquitetura chamada OSI (Open Systems Interconnection), Camadas OSI ou
65
Interconexo de Sistemas Abertos.
Esta arquitetura um modelo que divide as redes de computadores em sete camadas, de forma a se
obter camadas de abstrao. Cada protocolo implementa uma funcionalidade assinalada a uma
determinada camada.
1 Camada fsica
Subcamada MAC
Subcamada LLC

12.2.1

2 Camada de enlace
3 Camada de rede
4 Camada de transporte
5 Camada de sesso
6 Camada de apresentao
7 Camada de aplicao

Camada Fsica
A camada fsica define as caractersticas tcnicas dos dispositivos eltricos (fsicos) do sistema. Ela
contm os equipamentos de cabeamento ou outros canais de comunicao que se comunicam
diretamente com o controlador da interface de rede. Preocupa-se, portanto, em permitir uma
comunicao bastante simples e confivel, na maioria dos casos com controle de erros bsico:
Move bits (ou bytes, conforme a unidade de transmisso) atravs de um meio de transmisso.
Define as caractersticas eltricas e mecnicas do meio, taxa de transferncia dos bits, tenses etc.
Controle de acesso ao meio.

http://pt.wikipedia.org/wiki/Arquitetura_de_rede
http://pt.wikipedia.org/wiki/Modelo_OSI
135
64
65

TI para concursos

Controle da quantidade e velocidade de transmisso de informaes na rede.


Os principais equipamentos relacionados camada fsica so:
Repeater ou repetidor - utilizado para interligao de redes idnticas, amplificam e regeneram
eletricamente os sinais transmitidos no meio fsico. Recebe todos os pacotes de cada uma das redes
que ele interliga e os repete nas demais redes sem realizar qualquer tipo de tratamento sobre os
mesmos.
HUB ou concentrador - concentra a ligao entre diversos computadores que esto em uma rede
local. Trabalha por broadcast, que envia a mesma informao dentro de uma rede para todas as
mquinas interligadas. Possui diversas portas que partilham o mesmo domnio de coliso.

12.2.2

Camada de Enlace ou Ligao de Dados


Detecta e, opcionalmente, corrige erros que possam acontecer no nvel fsico. responsvel pela
transmisso e recepo (delimitao) de quadros e pelo controle de fluxo. Estabelece um protocolo de
comunicao entre sistemas diretamente conectados, como PPP ou NetBios.
Esta camada dividida em outras duas camadas:
Controle de ligao lgica (LLC), que fornece uma interface para camada superior (rede).
Controle de acesso ao meio fsico (MAC), que acessa diretamente o meio fsico e controla a
transmisso de dados.
Os principais equipamentos relacionados camada de enlace so:
Bridge ou ponte - dispositivo que liga redes com quaisquer protocolos ou dois segmentos da mesma
rede que usam o mesmo protocolo. Uma bridge ignora os protocolos utilizados nos dois segmentos
que liga, somente envia dados de acordo com o endereo do pacote. Este endereo no o
endereo IP (internet protocol), mas o MAC (media access control) que nico para cada placa de
rede. Os nicos dados que so permitidos atravessar uma bridge so dados destinados a endereos
vlidos no outro lado da ponte. Desta forma possvel utilizar uma bridge para manter um segmento
da rede livre dos dados que pertencem a outro segmento.
Switch ou comutador dispositivo que reencaminha frames entre os diversos ns e segmenta a rede
internamente. Possui diversas portas, cada uma corresponde um dominio de coliso diferente, no
havendo colises entre pacotes de segmentos diferentes. Com um Switch gerencivel, podemos criar
VLANS, deste modo a rede gerenciada ser divida em menores segmentos.
Protocolos: Ethernet e PPP.

12.2.3

Camada de Rede
A camada de Rede responsvel pelo endereamento dos pacotes, convertendo endereos lgicos (ou
IP) em endereos fsicos, de forma que os pacotes consigam chegar corretamente ao destino. Essa
camada tambm determina a rota que os pacotes iro seguir para atingir o destino, baseada em fatores
como condies de trfego da rede e prioridades.
Essa camada usada quando a rede possui mais de um segmento e, com isso, h mais de um caminho
para um pacote de dados percorrer da origem ao destino.
As funes da camada de rede so encaminhamento, endereamento, interconexo de redes,
tratamento de erros, fragmentao de pacotes, controle de congestionamento e sequenciamento de
pacotes.
Movimenta pacotes a partir de sua fonte original at seu destino atravs de um ou mais enlaces. Define
como dispositivos de rede descobrem uns aos outros e como os pacotes so roteados at seu destino
final.
Dispositivo: Swith L3
Protocolo: IP.

12.2.4

Camada de Transporte
A camada de transporte responsvel por usar os dados enviados pela camada de Sesso e dividi-los
em pacotes que sero transmitidos para a camada de Rede. No receptor, a camada de Transporte
responsvel por pegar os pacotes recebidos da camada de Rede, remontar o dado original e assim
envi-lo camada de Sesso.
Isso inclui controle de fluxo, ordenao dos pacotes e a correo de erros, tipicamente enviando para o
transmissor uma informao de recebimento, informando que o pacote foi recebido com sucesso.
A camada de Transporte separa as camadas de nvel de aplicao (camadas 5 a 7) das camadas de
nvel fsico (camadas de 1 a 3). A camada 4, Transporte, faz a ligao entre esses dois grupos e
determina a classe de servio necessria como orientada a conexo e com controle de erro e servio de
confirmao, sem conexes e nem confiabilidade.

136

TI para concursos

O objetivo final da camada de transporte proporcionar servio eficiente, confivel e de baixo custo. O
hardware e/ou software dentro da camada de transporte e que faz o servio denominado entidade de
transporte.
A ISO define o protocolo de transporte para operar em dois modos:
Orientado a conexo usando o protocolo TCP, mais confivel.
No-Orientado a conexo atravs do protocolo UDP, mais rpido.
Dispositivos: Swith L4.

12.2.5

Camada de Sesso
A camada de Sesso permite que duas aplicaes em computadores diferentes estabeleam uma
sesso de comunicao. Nesta sesso, essas aplicaes definem como ser feita a transmisso de
dados e coloca marcaes nos dados que esto sendo transmitidos. Se porventura a rede falhar, os
computadores reiniciam a transmisso dos dados a partir da ltima marcao recebida pelo computador
receptor.
Disponibiliza servios como pontos de controle peridicos a partir dos quais a comunicao pode ser
restabelecida em caso de pane na rede.
Abre portas (sockets) para que vrias aplicaes possam escalonar o uso da rede e aproveitar melhor o
tempo de uso. Por exemplo, um browser quando for fazer o download de vrias imagens pode requisitlas juntas para que a conexo no fique ociosa em uma s imagem.
Protocolos: NetBIOS, IPX, Appletalk.

12.2.6

Camada de Apresentao
A camada de Apresentao, tambm chamada camada de traduo, converte o formato do dado
recebido pela camada de Aplicao em um formato comum a ser usado na transmisso desse dado, ou
seja, um formato entendido pelo protocolo usado. Um exemplo comum a converso do padro de
caracteres (cdigo de pgina) quando o dispositivo transmissor usa um padro diferente do ASCII. Pode
ter outros usos, como compresso de dados e criptografia.
A compresso de dados pega os dados recebidos da camada sete e os comprime, e a camada 6 do
dispositivo receptor fica responsvel por descompactar esses dados. A transmisso dos dados torna-se
mais rpida, j que haver menos dados a serem transmitidos: os dados recebidos da camada 7 foram
"encolhidos" e enviados camada 5.
Para aumentar a segurana, pode-se usar algum esquema de criptografia neste nvel, sendo que os
dados s sero decodificados na camada 6 do dispositivo receptor.
Ela trabalha transformando os dados em um formato no qual a camada de aplicao possa aceitar.

12.2.7

Camada de Aplicao
A camada de aplicao faz a interface entre o protocolo de comunicao e o aplicativo que pediu ou
receber a informao atravs da rede. Por exemplo, ao solicitar a recepo de e-mails atravs do
aplicativo de e-mail, este entrar em contato com a camada de Aplicao do protocolo de rede efetuando
tal solicitao. Tudo nesta camada direcionado aos aplicativos. Telnet e FTP so exemplos de
aplicativos de rede que existem inteiramente na camada de aplicao.
Protocolos: SMTP, FTP, Telnet, SSH, IRC, http, POP3, VFRAD

12.3

Noes de administrao de redes


O Administrador de Rede tem como atribuio principal o gerenciamento da rede local, bem como dos
recursos computacionais relacionados direta ou indiretamente.66
Suas atribuies so:
Instalao e ampliao da rede local;
Acompanhar o processo de compra do material necessrio para manuteno da rede local junto com o
SAT (Setor de Assistncia Tcnica), orientando o processo de compra e mantendo contato com os
fornecedores de equipamentos e materiais de informtica;
Instalar e configurar a mquina gateway da rede local seguindo as orientaes "Normas de Utilizao do
DIN";
Orientar e/ou auxiliar os administradores das sub-redes na instalao/ampliao da sub-rede; manter em
funcionamento a rede local do DIN, disponibilizando e otimizando os recursos computacionais
disponveis;
Executar servios nas mquinas principais da rede local, tais como: gerenciamento de discos, fitas e
backup's, parametrizao dos sistemas, atualizao de verses dos sistemas operacionais e aplicativos,
aplicao de correes e patches;

http://pt.wikipedia.org/wiki/Administrador_de_rede
137
66

TI para concursos

Realizar abertura, controle e fechamento de contas nas mquinas principais do domnio local, conforme
normas estabelecidas pelo DIN;
Controlar e acompanhar a performance da rede local e sub-redes bem como dos equipamentos e
sistemas operacionais instalados;
Propor a atualizao dos recursos de software e hardware aos seus superiores;
Manter atualizado os dados relativos ao DNS das mquinas da rede local;
Divulgar informaes de forma simples e clara sobre assuntos que afetem os usurios locais, tais como
mudana de servios da rede, novas verses de software, etc.;
Manter-se atualizado tecnicamente atravs de estudos, participao em cursos e treinamentos, listas de
discusso, etc.;
Garantir a integridade e confidenciabilidade das informaes sob seu gerenciamento e verificar
ocorrncias de infraes e/ou segurana;
Comunicar ao DIN qualquer ocorrncia de segurana na rede local que possa afetar a rede local e/ou
Internet;
Promover a utilizao de conexo segura entre os usurios do seu domnio.
Tendo como foco principal os servios de Rede e equipamentos a qual a ele compete.
Colocar em pratica a poltica de segurana de redes, alm de desenvolv-la.

12.4

Acesso Remoto
Acesso remoto utilizao de um computador atravs de outro por algum meio de comunicao.
Usualmente, o acesso remoto funciona como se o teclado e o mouse de um computador estivesse ligado
ao computador controlado e o monitor deste estivesse ligado no primeiro.
Existem diversos aplicativos que fazem este servio, como o VNC, PCAnyWhere, Dameware, Conexo
de rea de trabalho remota do Windows entre outros.
Muito utilizado em data centers para administrar diversos servidores com um s vdeo, teclado e mouse.

12.5

Rede Wireless
Wi-Fi foi uma marca licenciada originalmente pela Wi-Fi Alliance para descrever a tecnologia de redes
sem fios embarcadas (WLAN) baseadas no padro IEEE 802.11. O termo Wi-Fi entendido como uma
tecnologia de interconexo entre dispositivos sem fios, usando o protocolo IEEE 802.11.67
O padro Wi-Fi opera em faixas de freqncias que no necessitam de licena para instalao e/ou
operao. Este fato as tornam atrativas. No entanto, para uso comercial no Brasil necessria licena
da Agncia Nacional de Telecomunicaes (Anatel).
Para se ter acesso internet atravs de rede Wi-Fi deve-se estar no raio de ao ou rea de
abrangncia de um ponto de acesso (normalmente conhecido por hotspot) ou local pblico onde opere
rede sem fios e usar dispositivo mvel, como computador porttil, Tablet PC ou Assistente Pessoal
Digital com capacidade de comunicao sem fio.
Hotspot Wi-Fi existe para estabelecer ponto de acesso para conexo internet. O ponto de acesso
transmite o sinal sem fios numa pequena distncia cerca de 100 metros. Quando um perifrico que
permite "Wi-Fi", como um Pocket PC, encontra um hotspot, o perifrico pode na mesma hora conectar-se
rede sem fio. Muitos hotspots esto localizados em lugares que so acessveis ao pblico, como
aeroportos, cafs, hotis e livrarias. Muitas casas e escritrios tambm tm redes "Wi-Fi". Enquanto
alguns hotspots so gratuitos, a maioria das redes pblicas suportada por Provedores de Servios de
Internet (Internet Service Provider - ISPs) que cobram uma taxa dos usurios para se conectarem.
Atualmente praticamente todos os computadores portteis vm de fbrica com dispositivos para rede
sem fio no padro Wi-Fi (802.11 a, b, g ou n). O que antes era acessrio est se tornando item
obrigatrio, principalmente devido ao fato da reduo do custo de fabricao.

12.6

Exerccios
225. (ICMS-SP 2009) As redes wireless utilizam os padres IEEE 802.11 de conectividade sem fio para redes
locais, que determinam a velocidade, ou taxa de transmisso em Mbps, e a frequncia, ou faixa de operao
em GHz. O padro que tem as caractersticas de velocidade e frequncia corretas corresponde a:225
xx
(a) IEEE 802.11n 128 Mbps 5 GHz
(b) IEEE 802.11g 54 Mbps 5 GHz
(c) IEEE 802.11b 54 Mbps 5 GHz
(d) IEEE 802.11a 11 Mbps 2,4 GHz
(e) IEEE 802.11 11 Mbps 2,4 GHz.

http://pt.wikipedia.org/wiki/Wi-Fi
138
67

TI para concursos

226. (ICMS-SP 2009) A arquitetura OSI de 7 camadas (1. Fsica, 2. Enlace, 3. Rede, 4. Transporte, 5. Sesso, 6.
Apresentao e 7. Aplicao) pode funcionalmente representar um sistema de comunicao dividido em trs
partes: redes (conectividade), transporte (ligao entre redes e aplicao) e aplicao (programas que utilizam
226
a rede). As camadas que representam as trs partes so:
(a) Redes (camadas 1 e 2), Transporte (camadas 3 e 4) e Aplicao (camadas 5, 6 e 7).
xx
(b) Redes (camadas 1, 2 e 3), Transporte (camada 4) e Aplicao (camadas 5, 6 e 7).
(c) Redes (camadas 1 e 2), Transporte (camadas 3, 4 e 5) e Aplicao (camadas 6 e 7).
(d) Redes (camadas 1, 2 e 3), Transporte (camadas 4, 5 e 6) e Aplicao (camada 7).
(e) Redes (camada 1), Transporte (camadas 2, 3, 4 e 5) e Aplicao (camadas 6 e 7).
227. (ICMS-SP 2009) Em um modelo simplificado de gerenciamento de redes SNMP Internet, o programa
227
executado nas entidades a serem gerenciadas (hosts, hubs, roteadores etc.) denominado
(a) MIB.
(b) SMI.
(c) SNMP.
(d) Agente SNMP.xx
(e) Gerenciador SNMP.
228. Switches, Repetidores e Roteadores atuam respectivamente nas camadas
(a) de enlace, fsica e de rede. xx
(b) de rede, de enlace e de transporte.
(c) fsica, de enlace e de rede.
(d) de enlace, de transporte e fsica.
(e) fsica, de rede e de enlace.

228

229. Entre os dispositivos utilizados para implementar fisicamente uma rede de computadores, pode-se citar o
__________ e o __________ , que operam, respectivamente, nas camadas 2 e 3 do modelo OSI. Assinale a
alternativa que completa, correta e respectivamente, as lacunas do texto. 229
(a) HUB ... Switch
(b) Roteador ... HUB
(c) Roteador ... Switch
(d) Switch ... HUB
(e) Switch ... Roteadorxx
230. No modelo de referncia OSI, os pacotes e os quadros so unidades intercambiadas, respectivamente, pelas
camadas de230
(a) enlace e de transporte.
(b) enlace e de rede.
(c) rede e fsica.
(d) rede e de enlace.xx
(e) transporte e de enlace.
231. No modelo de referncia TCP/IP, os protocolos IP, TCP e tambm aquele cujo objetivo organizar mquinas
em domnios e mapear nomes de hosts em ambientes IP, so, respecivamente, partes integrantes das
camadas231
(a) Inter-Redes, de Aplicao e de Transporte.
(b) Host/Rede, Inter-Redes e de Transporte.
(c) Inter-Redes, Host/Rede e de Aplicao.
(d) Inter-Redes, de Transporte e de Aplicao.xx
(e) Host/Rede, de Transporte e de Aplicao.
232. Para testar o funcionamento de uma placa controladora de rede Ethernet, instalada em um computador
pessoal com sistema operacional Windows XP, pode-se, a partir desse computador, aplicar o comando ping
para o endereo IP232
(a) 0.0.0.0
(b) 1.1.1.1
(c) 127.0.0.1xx
(d) 255.0.0.0
(e) 255.255.255.0
233. A Internet utiliza a pilha de protocolos TCP/IP para prover todos os servios. Nesse contexto, o TCP
encarregado de possibilitar o __________ e o IP encarregado do __________ . Assinale a alternativa que
completa, correta e respectivamente, as lacunas do texto. 233
(a) roteamento ... endereamento
(b) roteamento ... transporte
(c) transporte ... empacotamento
xx
(d) transporte ... endereamento
(e) transporte ... sequenciamento

139

TI para concursos

234. O processo de navegao na Internet facilitado pelo uso de endereos de domnio no lugar dos endereos
IPs (mais difceis de memorizar e relacionar com os sites endereados). O servio que faz o relacionamento
entre o domnio e o IP denominado234
(a) DHCP.
xx
(b) DNS.
(c) IMAP.
(d) PPP.
(e) TCP/IP.
235. O equipamento de rede de computador utilizado para armazenar cpias (cache) de pginas mais visitadas e,
235
alm disso, verificar o contedo dessas pginas, denominado
xx
(a) Proxy.
(b) Bridge.
(c) Spyware.
(d) Firewall.
(e) Gateway.
236. TCP/IP (transmission control protocol/Internetprotocol) so os dois protocolos mais importantes de um conjunto
de protocolos que deram seus nomes arquitetura. Deles, surge a Internet, uma rede pblica de comunicao
de dados que, com controle descentralizado, utiliza esse conjunto de protocolos como base para sua estrutura
de comunicao e seus servios de rede. A arquitetura TCP/IP no s fornece os protocolos que habilitam a
comunicao de dados entre redes, mas tambm define uma srie de aplicaes que contribuem para a
eficincia e sucesso da arquitetura. Tendo como referncia inicial as informaes acima, assinale a opo
correta a respeito de Internet, intranet e padres de tecnologia Web.236
(a) Uma intranet a aplicao da tecnologia criada na Internet e do conjunto de protocolos de transporte e de
rede TCP/IP em uma rede semiprivada, interna a uma empresa. Nela, grande quantidade de informaes
e aplicaes disponibilizada por meio dos sistemas Web (protocolo HTTP) e correio-eletrnico, sendo,
comumente, verificadas funcionalidades como informaes dos empregados e dos clientes que a
acessam em busca de informaes sobre andamento de pedidos.
(b) O protocolo OSPF (open shortest path first), que embasado no paradigma de chaveamento de pacotes
(packetswitching), especifica o formato dos pacotes que so enviados e recebidos entre roteadores e
sistemas finais.
(c) Os protocolos UDP e SMTP podem ser utilizados na transferncia de arquivos para um computador
remoto que tambm os execute e em qualquer estrutura de rede, seja ela simples, como uma ligao
ponto-a-ponto, seja ela uma rede de pacotes complexa.
(d) O DNS (domain name system) um sistema de banco de dados distribudo implementado em uma
hierarquia de servidores de nome (servidores DNS) e em um protocolo de camada de aplicao que
permite a hospedeiros consultarem o banco de dados distribudo. xx
(e) O ICMP (Internet control message protocol), que um protocolo de roteamento exterior auxiliar ao IP e
cuja finalidade conectar dois ou mais sistemas autnomos, pode operar em conjunto com os protocolos
EGP (exterior gateway protocol) e BGP (border gateway protocol), o que permite maior confiabilidade
ligao entre dois sistemas autnomos.
237. Para acesso aos recursos da Internet, os browsers possibilitam o uso de endereos de sites na forma de
mnemnicos, como, por exemplo, no portal do Governo do Estado do Rio de Janeiro
http://www.governo.rj.gov.br/, deixando para o sistema automatizado a tarefa de realizar as necessrias
converses para os correspondentes endereos IPs. Esse recurso conhecido pela sigla:237
(a) ARP.
xx
(b) DNS.
(c) ISP.
(d) NAT.
(e) NFS.
238. Dentre os recursos atualmente disponveis no mbito da tecnologia da informao, a Extranet constitui um
termo associado s facilidades de comunicao na busca do aumento da produtividade. Nesse sentido, a
238
Extranet definida como:
(a) uma parte da Intranet que fica disponvel troca de informaes com os funcionrios de uma
organizao, mas inibe todo tipo de acesso ao ambiente externo por meio do firewall.
(b) uma sub-rede sob sistema operacional Windows XP ou Linux que implementa recursos de VPN na sua
segurana, mas libera acesso por meio do firewall.
(c) uma parte da Intranet que fica disponvel na Internet para interao com clientes e fornecedores de uma
xx
organizao, mas com acesso autorizado, controlado e restrito.
(d) uma sub-rede que disponibiliza uma maior quantidade de microcomputadores com acesso Internet por
meio da utilizao do mecanismo NAT, mas restringe a intercomunicao com usurios indesejados
organizao.
(e) uma parte da Intranet que disponibiliza a comunicao com fornecedores e determinados clientes de uma
organizao, mas inibe todo tipo de acesso ao ambiente interno por meio do firewall.

140

TI para concursos

239. A Internet constitui o melhor exemplo de uma WAN operando por meio de uma infraestrutura baseada no
emprego de endereos IPs para o roteamento dos pacotes de informaes. Por definio na RFC 1918,
alguns endereos IP so reservados e no-roteveis externamente, sendo somente usados para redes
internas, significando que nenhum computador conectado em rede local e usando qualquer uma das classes
desses endereos reservados conseguir acessar a internet. A exceo ocorre se os microcomputadores
estiverem em rede e usando NAT (RFC 1631 Network Address Translation). Para Intranets privadas, o
Internet Assigned Numbers Authority (IANA) reservou a faixa de endereos de 10.0.0.0 a 10.255.255.255 para
a classe A e a de 172.16.0.0 a 172.16.255.255 para a classe B. Assinale a alternativa que apresente a faixa de
239
endereos reservada para a classe C.
(a) de 128.192.0.0 a 128.192.255.255
(b) de 128.146.0.0 a 128.146.255.255
(c) de 184.191.0.0 a 184.191.255.255
xx
(d) de 192.168.0.0 a 192.168.255.255
(e) de 198.162.0.0 a 198.162.255.255
240. Dada uma faixa de endereos que utilize a mscara de sub-rede 255.255.255.240, ser possvel atribuir
240
endereos IP para
(a) 2 redes e 62 estaes em cada rede.
(b) 6 redes e 30 estaes em cada rede.
(c) 14 redes e 14 estaes em cada rede. xx
(d) 30 redes e 6 estaes em cada rede.
(e) 62 redes e 2 estaes em cada rede.
241. Conecta segmentos de LAN que utilizam o mesmo protocolo de enlace de dados e de rede. Normalmente,
fornece portas para 4, 8, 16 ou 32 segmentos de LAN separados, permite que todas as portas estejam
simultaneamente em uso e pode conectar os mesmos ou diferentes tipos de cabo. Estas so caractersticas de
241
um
(a) concentrador.
(b) multiplexador.
xx
(c) comutador.
(d) modulador de amplitude.
(e) repetidor.
242. Padro de protocolo da camada de transporte, sem conexo, no confivel, destinado a aplicaes que no
querem controle de fluxo e nem manuteno da seqncia das mensagens enviadas, usado pelo TCP para
242
enviar mensagens curtas. Trata-se de
xx
(a) UDP.
(b) IP.
(c) SMTP.
(d) POP.
(e) Telnet.
243. As mensagens de correio eletrnico, a partir de um microcomputador pessoal, sero enviadas243
(a) pelo protocolo SMTP, conectado pela porta 25, e sero recebidas pelos protocolos POP3 ou IMAP,
xx
conectado respectivamente pelas portas 110 ou 220.
(b) pelo protocolo SMTP, conectado pela porta 110, e sero recebidas pelos protocolos POP3 ou IMAP,
conectado respectivamente pelas portas 25 ou 220.
(c) pelos protocolos SMTP ou IMAP, conectado respectivamente pelas portas 25 ou 220, e sero recebidas
pelo protocolo POP3, conectado pela porta 110.
(d) pelos protocolos SMTP ou IMAP, conectado respectivamente pelas portas 110 ou 220, e sero recebidas
pelo protocolo POP3, conectado pela porta 25.
(e) pelo protocolo SMTP, conectado pela porta 110, sero recebidas pelo protocolo POP3, conectado pela
porta 25, e sero enviadas ou recebidas pelo protocolo IMAP, conectado pela porta 220.
244. O daemon de correio eletrnico que se comunica com o SMTP permanece em escuta na porta
(a) 21
xx
(b) 15
(c) 69
(d) 80
(e) 110

244

245. Controlar o acesso ao canal compartilhado uma questo que as redes de difuso tm a resolver na camada
245
de enlace de dados. Para cuidar desse problema existe
(a) o roteador.
(b) a VPN.
xx
(c) a subcamada MAC.
(d) o protocolo IP.
(e) o protocolo HTTP.

141

TI para concursos

246. Servio que permite ao usurio entrar em outro computador ligado internet, transformando sua mquina local
246
em um terminal do computador remoto o
(a) Telnet.xx
(b) FTP.
(c) Usenet.
(d) Intranet.
(e) IRC.
247. As camadas LLC e MAC da arquitetura de rede IEEE 802 correspondem no modelo OSI camada de247
(a) Rede.
(b) Sesso.
xx
(c) Enlace.
(d) Transporte.
(e) Aplicao.

142

TI para concursos

13

Informtica Bsica

13.1.1

Questes de informtica do concurso ICMS-SP 2009


248. Durante a elaborao de um documento no editor de textos MS-Word, um Agente deparou-se com a
necessidade de criar uma tabela que ocupava mais de uma pgina, onde algumas clulas (interseces de
linhas e colunas) continham valores. Entretanto, esses valores deveriam ser totalizados na vertical (por
coluna), porm, no sentido horizontal, um valor mdio de cada linha era exigido. Nessas circunstncias,
248
visando execuo dos clculos automaticamente, o Agente optou, acertadamente, por elaborar a tabela no
(a) MS-Excel e depois import-la no editor de textos pelo menu Editar, utilizando as funes apropriadas do
MS-Word.
(b) MS-Excel e depois import-la no editor de textos pelo menu Tabela, utilizando as funes apropriadas do
MS-Word.
(c) MS-Excel e depois import-la no editor de textos pelo menu Arquivo, utilizando as funes apropriadas do
MS-Word.
(d) prprio MS-Word, utilizando as funes apropriadas disponveis no menu Ferramentas do editor de
textos.
(e) prprio MS-Word, utilizando as funes apropriadas disponveis no menu Tabela do editor de textos. xx
249. No MS-Word, ao marcar uma parte desejada de um texto e249
(a) optar pela cpia, o objetivo fazer a cpia de formatos de caractere e pargrafo, somente.
(b) optar pelo recorte, o objetivo fazer a cpia de formatos de caractere e pargrafo, somente.
(c) optar pelo recorte, o objetivo fazer a cpia do contedo do texto e/ou marcadores, somente.
xx
(d) pressionar o cone Pincel, o objetivo fazer a cpia de formatos de caractere e/ou pargrafo, somente.
(e) pressionar o cone Pincel, o objetivo fazer a cpia do contedo de texto do pargrafo e/ou marcadores,
somente.
250. Em uma planilha MS-Excel, um Agente digitou o contedo abaixo:
A
B
C
1
2
5 =$A1+B$1
2
3
6
3
4
7
O valor da clula C1 e os valores da clula C2 e C3, aps arrastar a clula C1 pela ala de preenchimento
250
para C2 e C3, sero
(a) 7, 9 e 11
(b) 7, 8 e 9xx
(c) 7, 10 e 11
(d) 9, 10 e 11
(e) 9, 9 e 9
251. Considere a planilha abaixo elaborada no MS-Excel:
A
B
C
1
2
5
10
2
3
6
3
4
7
O contedo da clula C1 foi obtido pela frmula =A$1*$B$1 apresentando, inicialmente, o resultado 10. Caso
todas as clulas, com exceo da C1, tenham seu contedo multiplicado por 8, o resultado da ao de arrastar
251
a clula C1 pela ala de preenchimento para as clulas C2 e C3 ser
(a) valor de C2 maior que C1 e valor de C3 maior que C2.
(b) valor de C2 menor que C1 e valor de C3 menor que C2.
(c) valores e frmulas em C2 e C3 idnticos aos de C1. xx
(d) valores iguais, porm frmulas diferentes nas clulas C1, C2 e C3.
(e) valor de C2 igual ao de C1 porm menor que o de C3.
252

252. No Windows XP (edio domstica), o uso da Lente de aumento da Microsoft objeto de


xx
(a) acessibilidade.
(b) gerenciamento de dispositivos.
(c) gerenciamento de impressoras.
(d) configurao de formatos de dados regionais.
(e) configurao das propriedades de teclado.

253. Pressionando o boto direito (destro) do mouse em um espao vazio do desktop do Windows XP (edio
domstica) e selecionando Propriedades, ser exibida uma janela com abas tais como rea de Trabalho e
253
Configuraes. Entre outras, ser exibida tambm a aba
(a) Ferramentas administrativas.
(b) Opes de pasta.
xx
(c) Propriedades de vdeo.
(d) Painel de controle.
(e) Tarefas agendadas.

143

TI para concursos
254

254. A boa refrigerao de um processador geralmente obtida mediante


(a) a execuo do boot proveniente de uma unidade perifrica.
(b) a instalao de uma placa-me compacta.
(c) a adequada distribuio da memria.
xx
(d) o uso de um cooler.
(e) o aumento do clock.

255. Na Web, a ligao entre conjuntos de informao na forma de documentos, textos, palavras, vdeos, imagens
ou sons por meio de links, uma aplicao das propriedades255
(a) do protocolo TCP.
xx
(b) dos hipertextos.
(c) dos conectores de rede.
(d) dos modems.
(e) das linhas telefnicas.
256. Nos primrdios da Internet, a interao entre os usurios e os contedos virtuais disponibilizados nessa rede
era dificultada pela no existncia de ferramentas prticas que permitissem sua explorao, bem como a
visualizao amigvel das pginas da Web. Com o advento e o aperfeioamento de programas de computador
que basicamente eliminaram essa dificuldade, os servios e as aplicaes que puderam ser colocados
disposio dos usurios, iniciaram uma era revolucionria, popularizando o uso da Internet.
Segundo o texto, a eliminao da dificuldade que auxiliou na popularizao da Internet foi256
xx
(a) o uso de navegadores.
(b) o surgimento de provedores de acesso.
(c) o aumento de linhas da rede.
(d) o surgimento de provedores de contedo.
(e) a disponibilizao de servios de banda larga.
257. Um Agente foi acionado para estudar a respeito dos conceitos de certificao digital. Aps alguma leitura, ele
descobriu que NO tinha relao direta com o assunto o uso de257
(a) chave pblica.
(b) criptografia.
(c) assinatura digital.
(d) chave privada.
(e) assinatura eletrnica.xx

144

TI para concursos

14

Referncias

Alm das referncias anotradas nos rodaps das pginas:


OBJECT Management Group, Inc. (OMG), Business Process Model and Notation (BPMN). Version 2.0 de
03/01/2011. Disponvel em http://www.omg.org/spec/BPMN/2.0.
Acesso em 15/09/2012.
MAZZOLA, Vitrio Bruno. Engenharia de Software. Disponvel em
http://seriesloads.wordpress.com/2010/11/04/engenharia-de-software-vitorio-bruno-mazzola/ .
Acesso em 15/09/2012
PMI, Project Management Institute, Inc. Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos
(Guia PMBOK). Quarta edio. 2008.

145

TI para concursos

15

Sobre o autor

Walter de Tarso Faria Santos de Campos foi aprovado no concurso de AFR ICMS-SP de 2009 e est alocado no
Centro de Desenvolvimento de Sistemas do Departamento de Tecnologia de Informaes (CDS-DTI) da
Secretaria da Fazenda de So Paulo.
Este material foi um resumo de tudo de TI que estudou para esta prova.
Formado em licenciatura em qumica pela Universidade de So Paulo, lecionou informtica bsica para alunos do
ensino fundamental e mdio no Colgio Rio Branco por doze anos.
Exerceu consultoria de informtica e desenvolveu mais de trinta sistemas para diversas intituies pblicas e
privadas por 25 anos, para FIPE, FIA, FIPECAFI, Secretaria do Meio Ambiente, CDHU, Convap Engenharia e
Construes, GMR Arquitetos Associados, Fundao Padre Anchieta, Fundao Osesp, ABEM, Souza Cruz, entre
outras.

146

TI para concursos

16

(b)
(a)
3
(e)
4
(b)
5
(e)
6
(b)
7
(d)
8
(e)
9
(b)
10
(a)
11
(c)
12
(a)
13
(b)
14
(d)
15
(b)
16
(d)
17
(a)
18
(c)
19
(a)
20
(d)
21
(c)
22
(d)
23
(a)
24
(b)
25
(a)
26
(a)
27
(e)
28
(b)
29
(a)
30
(c)
31
(e)
32
(b)
33
(a)
34
(a)
35
(d)
36
(b)
37
(e)
38
(d)
39
(e)
40
(c)
41
(c)
42
(c)
43
(d)
44
(b)
45
(e)
46
(e)
47
(b)
48
(b)
49
(b)
50
(e)
51
(a)
52
(d)
53
(c)
54
(e)
55
(b)
56
(a)
57
(a)
58
(d)
2

147

Gabarito
59

119

179

239

60

120

180

240

(d)
(d)
61
(d)
62
(d)
63
(e)
64
(d)
65
(d)
66
(e)
67
(e)
68
(a)
69
(c)
70
(b)
71
(a)
72
(e)
73
(e)
74
(c)
75
(e)
76
(a)
77
(e)
78
(d)
79
(e)
80
(e)
81
(e)
82
(b)
83
(e)
84
(b)
85
(a)
86
(b)
87
(d)
88
(d)
89
(e)
90
(b)
91
(d)
92
(d)
93
(e)
94
(c)
95
(d)
96
(d)
97
(a)
98
(c)
99
(a)
100
(a)
101
(c)
102
(c)
103
(b)
104
(c)
105
(c)
106
(b)
107
(d)
108
(b)
109
(e)
110
(c)
111
(c)
112
(e)
113
(c)
114
(c)
115
(d)
116
(d)
117
(b)
118
(b)

(d)
(c)
121
(e)
122
(c)
123
(d)
124
(d)
125
(a)
126
(c)
127
(d)
128
(a)
129
(b)
130
(c)
131
(d)
132
(d)
133
(a)
134
(b)
135
(d)
136
(b)
137
(b)
138
(e)
139
(c)
140
(a)
141
(d)
142
(e)
143
(e)
144
(a)
145
(b)
146
(c)
147
(d)
148
(c)
149
(b)
150
(e)
151
(a)
152
(b)
153
(d)
154
(e)
155
(b)
156
(c)
157
(a)
158
(e)
159
(a)
160
(c)
161
(e)
162
(b)
163
(a)
164
(d)
165
(e)
166
(a)
167
(b)
168
(b)
169
(b)
170
(e)
171
(b)
172
(a)
173
(a)
174
(d)
175
(a)
176
(e)
177
(b)
178
(b)

(c)
(a)
181
(e)
182
(d)
183
(e)
184
(d)
185
(c)
186
(d)
187
(c)
188
(a)
189
(c)
190
(b)
191
(d)
192
(e)
193
(c)
194
(c)
195
(d)
196
(e)
197
(a)
198
(d)
199
(b)
200
(e)
201
(a)
202
(b)
203
(b)
204
(d)
205
(a)
206
(d)
207
(e)
208
(c)
209
(b)
210
(e)
211
(c)
212
(b)
213
(c)
214
(e)
215
(c)
216
(c)
217
(b)
218
(e)
219
(b)
220
(d)
221
(b)
222
(b)
223
(a)
224
(c)
225
(a)
226
(b)
227
(d)
228
(a)
229
(e)
230
(d)
231
(d)
232
(c)
233
(d)
234
(b)
235
(a)
236
(d)
237
(b)
238
(c)

(d)
(c)
241
(c)
242
(a)
243
(a)
244
(b)
245
(c)
246
(a)
247
(c)
248
(e)
249
(d)
250
(b)
251
(c)
252
(a)
253
(c)
254
(d)
255
(b)
256
(a)
257
(e)