Walter de Tarso

Material de referência

TI – ICMS

Walter de Tarso

Versão 1.4

2012

Curso de TI

Pág. 2 de 153

Sumário

1 Gerência de Projetos .................................................................................................................................. 1

1.1 Conceitos básicos ............................................................................................................................... 1

1.2 Processos do PMBOK ......................................................................................................................... 2 1.2.1 Diferenças entre a edição 3 e 4 do PMBOK .................................................................................................... 3 1.2.2 Áreas de conhecimento do PMBOK................................................................................................................ 4 1.2.3 Processos, ferramentas e técnicas ................................................................................................................. 5

1.3 Planejamento e controle de métricas de projeto ................................................................................ 8

1.4 Métodos de gerenciamento do tempo do projeto .............................................................................. 9

1.5 Exercícios........................................................................................................................................... 10

2 Gestão de Processos de Negócio (BPM) ................................................................................................. 14

2.1 Técnicas de análise de processos .................................................................................................... 14 2.1.1 BPMN - Modelagem de processos ............................................................................................................... 14 2.1.2 Elementos ................................................................................................................................................... 16 2.1.3 Fluxograma ................................................................................................................................................. 17 2.1.4 Service blueprint .......................................................................................................................................... 17 2.1.5 Mapa do serviço .......................................................................................................................................... 18 2.1.6 IDEF ............................................................................................................................................................ 18 2.1.7 Estrutura de processamento de clientes ....................................................................................................... 19 2.1.8 Walk-through-audit....................................................................................................................................... 19 2.1.9 Análise da transação de serviço (STA – Service Transaction Analysis) .......................................................... 20

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

2.3 GED - Gerenciamento Eletrônico de Documentos .......................................................................... 22

2.4 Workflow ............................................................................................................................................ 23

2.5 Exercícios........................................................................................................................................... 23

3 Governança de TI ...................................................................................................................................... 26

3.1 Princípios de governança de TI......................................................................................................... 26

3.2 Alinhamento estratégico ................................................................................................................... 27

3.3 Qualidade de software ....................................................................................................................... 27 3.3.1 CMMI .......................................................................................................................................................... 28 3.3.2 MPS-BR - Melhoria de Processos do Software Brasileiro .............................................................................. 30 3.3.3 Exercícios .................................................................................................................................................... 30

3.4 Gerenciamento de serviços............................................................................................................... 32

3.5 Conceitos e definições ...................................................................................................................... 32

3.6 Fundamentos da ITIL V2 .................................................................................................................... 33 3.6.1 Suporte a serviços ....................................................................................................................................... 33 3.6.2 Entrega de Serviço ...................................................................................................................................... 34

3.7 Fundamentos de ITIL V3 ................................................................................................................... 35 3.7.1 Estratégia do serviço (Service Strategy) ....................................................................................................... 36 3.7.2 Desenho de serviço (Service Design) ........................................................................................................... 36 3.7.3 Transição do serviço (Service Transition) ..................................................................................................... 36 3.7.4 Operação do serviço (Service Operation) ..................................................................................................... 36 3.7.5 Melhoria de serviço continuada (Continual Service Improvement) ................................................................. 36

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

3.9 Fundamentos de COBIT .................................................................................................................... 38 3.9.1 Planejar e Organizar .................................................................................................................................... 39 3.9.2 Adquirir e Implementar ................................................................................................................................. 40 3.9.3 Entregar e Dar Suporte ................................................................................................................................ 40 3.9.4 Monitorar e Avaliar ....................................................................................................................................... 40

3.10 Comparação ITIL V3 x COBIT ........................................................................................................ 41

3.11 Exercícios ....................................................................................................................................... 41

4 Segurança da informação ........................................................................................................................ 46

4.1 Conceitos básicos ............................................................................................................................. 46

Walter de Tarso

4.2 Plano de Continuidade de Negócio ................................................................................................... 47

4.3 Vulnerabilidade .................................................................................................................................. 48

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

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

4.6 Exercícios........................................................................................................................................... 52

5 Arquitetura de Software............................................................................................................................ 56

5.1 UML .................................................................................................................................................... 57

5.2 Arquitetura Orientada a Serviço (SOA) ............................................................................................. 58 5.2.1 Serviço ........................................................................................................................................................ 59 5.2.2 Processos ................................................................................................................................................... 59 5.2.3 Definições de SOA....................................................................................................................................... 59 5.2.4 Web Services .............................................................................................................................................. 59 5.2.5 SOAP .......................................................................................................................................................... 61 5.2.6 WSDL.......................................................................................................................................................... 62 5.2.7 UDDI ........................................................................................................................................................... 63 5.2.8 Segurança ................................................................................................................................................... 63

5.3 Exercícios........................................................................................................................................... 64

6 Gerência de Requisitos de Software ........................................................................................................ 68

6.1 Conceitos de Requisitos ................................................................................................................... 68 6.1.1 Levantamento de requisitos ......................................................................................................................... 69

6.2 Requisitos Funcionais e Não-Funcionais ......................................................................................... 70

6.3 Exercícios........................................................................................................................................... 71

6.4 Técnicas de avaliação de software ................................................................................................... 72 6.4.1 Método COCOMO ....................................................................................................................................... 72 6.4.2 Análise por Pontos de Função ...................................................................................................................... 73

7 Gerência de Configuração e Mudança ..................................................................................................... 76

7.1 Conceitos de Gerência de Configuração e Mudança de software ................................................... 76 7.1.1 Configuração de software............................................................................................................................. 76 7.1.2 Item de configuração de software ................................................................................................................. 76 7.1.3 Controle de versões ..................................................................................................................................... 77 7.1.4 Papéis ......................................................................................................................................................... 77

7.2 Solicitações de Mudança ................................................................................................................... 77

7.3 Exercícios........................................................................................................................................... 79

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

8.1 Software ............................................................................................................................................. 81

8.2 Ciclo de vida do software .................................................................................................................. 82 8.2.1 Fase de Definição ........................................................................................................................................ 82 8.2.2 Fase de Desenvolvimento ............................................................................................................................ 82 8.2.3 Fase de Operação ....................................................................................................................................... 83 8.2.4 Fase de retirada........................................................................................................................................... 84

8.3 Metodologias de desenvolvimento de software. .............................................................................. 84 8.3.1 Modelo caótico ............................................................................................................................................ 84 8.3.2 Modelo Cascata ........................................................................................................................................... 84

8.4 Desenvolvimento ágil ........................................................................................................................ 85

8.5 Planejamento e avaliação de iterações............................................................................................. 87

8.6 Testes Software ................................................................................................................................. 88 8.6.1 Documentos de Teste .................................................................................................................................. 89

8.7 Exercícios........................................................................................................................................... 90

9 Banco de Dados ........................................................................................................................................ 92

9.1 Conceitos básicos ............................................................................................................................. 92

9.2 Modelagem de Dados Relacional ...................................................................................................... 92 9.2.1 Normalização............................................................................................................................................... 92 9.2.2 Etapas de modelagem ................................................................................................................................. 94

Curso de TI

Pág. 4 de 153

9.2.3 Relacionamentos ......................................................................................................................................... 94 9.2.4 Transação ................................................................................................................................................... 94

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

9.4 Modelagem de Dados Multidimensional ........................................................................................... 95 9.4.1 Sistemas Transacionais X Sistemas Analíticos ............................................................................................. 96

9.5 Conceitos de Datawarehouse e ETL ................................................................................................. 97 9.5.1 ETL ............................................................................................................................................................. 98

9.6 Conceitos de desenvolvimento em banco de dados SQL Server e Oracle ..................................... 98 9.6.1 SQL............................................................................................................................................................. 98 9.6.2 Arquitetura de um Servidor Oracle .............................................................................................................. 100 9.6.3 Arquitetura de um Servidor SQL Server ...................................................................................................... 101

9.7 Exercícios......................................................................................................................................... 102

10 Programação de Sistemas .................................................................................................................. 108

10.1 Lógica de Programação ............................................................................................................... 108 10.1.1 Tipos de dados e variáveis ......................................................................................................................... 109

10.2 Programação orientada a objetos ............................................................................................... 110 10.2.1 Objetos ...................................................................................................................................................... 110 10.2.2 Classe ....................................................................................................................................................... 111 10.2.3 Persistência ............................................................................................................................................... 111 10.2.4 Métodos .................................................................................................................................................... 111 10.2.5 Atributos .................................................................................................................................................... 111 10.2.6 Mensagens ................................................................................................................................................ 112 10.2.7 Herança .................................................................................................................................................... 112 10.2.8 Polimorfismo .............................................................................................................................................. 112 10.2.9 Sobrecarga ................................................................................................................................................ 112 10.2.10 Interfaces .................................................................................................................................................. 113 10.2.11 Pacotes ..................................................................................................................................................... 113

10.3 Programação na WEB .................................................................................................................. 113 10.3.1 Linguagem HTML ...................................................................................................................................... 114 10.3.2 Linguagens web de servidor ....................................................................................................................... 115 10.3.3 XML .......................................................................................................................................................... 115

10.4 Conceitos de linguagem de programação Microsoft .NET ......................................................... 116 10.4.1 arquitetura da .Net ..................................................................................................................................... 117 10.4.2 Linguagens de programação ...................................................................................................................... 117 10.4.3 Common Language Specification (CLS) ..................................................................................................... 117 10.4.4 Common Type System (CTS) ..................................................................................................................... 117 10.4.5 Framework Class Library (FCL) .................................................................................................................. 118 10.4.6 Camada de apresentação .......................................................................................................................... 118 10.4.7 ADO.Net .................................................................................................................................................... 118 10.4.8 .Net Remoting............................................................................................................................................ 118 10.4.9 Common Language Runtime (CLR) ............................................................................................................ 119 10.4.10 Common Language Infrastructure (CLI) ...................................................................................................... 119 10.4.11 Operating System (OS) .............................................................................................................................. 119 10.4.12 Outros detalhes da .Net ............................................................................................................................. 119

10.5 Exercícios ..................................................................................................................................... 120

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

11.1 Conceitos de administração de servidores em plataforma Windows ........................................ 124

11.2 Conceitos de administração de servidores em plataforma Linux .............................................. 124 11.2.1 Alguns comandos no Linux ........................................................................................................................ 124 11.2.2 Gerenciando a iniciação do Linux ............................................................................................................... 125 11.2.3 Fazendo Backups ...................................................................................................................................... 126 11.2.4 Recompilando e Adaptando o Kernel .......................................................................................................... 126 11.2.5 Agendando Processos ............................................................................................................................... 126 11.2.6 Syslogd - A Caixa Preta do Linux ............................................................................................................... 126 11.2.7 Técnicas Básicas para Trabalhar com Redes (ifconfig, route) ...................................................................... 127 11.2.8 Gerenciando os Serviços - inetd ................................................................................................................. 127 11.2.9 Utilizando Ferramentas de Busca ............................................................................................................... 127 11.2.10 Instalando SSh / SShD.............................................................................................................................. 127

11.3 Conceitos de Virtualização .......................................................................................................... 127

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

Walter de Tarso

11.5 Exercícios ..................................................................................................................................... 131

12 Redes ................................................................................................................................................... 133

12.1 Conceito de rede .......................................................................................................................... 133 12.1.1 Configuração de redes TCP-IP ................................................................................................................... 133

12.2 Arquitetura de Rede ..................................................................................................................... 135 12.2.1 Camada Física .......................................................................................................................................... 135 12.2.2 Camada de Enlace ou Ligação de Dados ................................................................................................... 136 12.2.3 Camada de Rede ....................................................................................................................................... 136 12.2.4 Camada de Transporte .............................................................................................................................. 136 12.2.5 Camada de Sessão ................................................................................................................................... 137 12.2.6 Camada de Apresentação .......................................................................................................................... 137 12.2.7 Camada de Aplicação ................................................................................................................................ 137

12.3 Noções de administração de redes ............................................................................................. 137

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

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

12.6 Exercícios ..................................................................................................................................... 138

13 Informática Básica............................................................................................................................... 143 13.1.1 Questões de informática do concurso ICMS-SP 2009 ................................................................................. 143

14 Referências .......................................................................................................................................... 145

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

16 Gabarito ............................................................................................................................................... 147

Sumário de imagens Ilustração 1 Métricas ............................................................................................................................................ 8 Ilustração 2 Símbolos BMPN ............................................................................................................................. 16 Ilustração 3 Exemplo de Fluxo utilizando pool, lanes, evento de início e fim, tarefas e gateway ......................... 17 Ilustração 4 Portal Corporativo ........................................................................................................................... 21 Ilustração 5 Governança de TI ........................................................................................................................... 26 Ilustração 6 Ciclo de vida do serviço - Núcleo do ITIL V3 ................................................................................... 35 Ilustração 7 Cobit ............................................................................................................................................... 38 Ilustração 8 Comparação COBIT x ITIL V3......................................................................................................... 41 Ilustração 9 Modelo PDCA aplicado aos processos do SGSI.............................................................................. 51 Ilustração 10 Componentes básicos da arquitetura do Web Service ................................................................... 60 Ilustração 11 Ciclo de vida do web service ......................................................................................................... 61 Ilustração 12 Protocolos de comunicação de Web services ................................................................................ 61 Ilustração 13 Descrição WSDL........................................................................................................................... 62

TI para concursos

1

1 Gerência de Projetos

1.1 Conceitos básicos

Um projeto1 é um esforço temporário empreendido para criar um produto, não necessariamente

temporário, serviço ou resultado exclusivo. Os projetos e as operações diferem, principalmente, no fato de que os projetos são temporários e exclusivos, enquanto as operações são contínuas e repetitivas.

Um programa é definido como um grupo de projetos relacionados gerenciados de modo coordenado para a obtenção de benefícios e controle que não estariam disponíveis 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 não fazer parte de um programa, mas um programa sempre terá projetos.

Um portfólio 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 negócios estratégicos.

Os projetos são normalmente autorizados como resultado de uma ou mais considerações estratégicas. Estas podem ser uma demanda de mercado, necessidade organizacional, solicitação de um cliente, avanço tecnológico ou requisito legal.

As principais características dos projetos são:

temporários, possuem um início e um fim definidos. planejados, executado e controlado. entregam produtos, serviços ou resultados exclusivos. desenvolvidos em etapas e continuam por incremento com uma elaboração progressiva. realizados por pessoas. com recursos limitados.

Esse é um resumo da definição de projeto feita pelo Guia PMBOK®, um guia que identifica o subconjunto do conjunto de conhecimentos em gerenciamento de projetos, amplamente reconhecido como boa prática na maioria dos projetos na maior parte do tempo e utilizado como base pelo Project Management Institute ( PMI®).

Gerência de projetos é a disciplina de manter os riscos de fracasso em um nível tão baixo quanto necessário durante o ciclo de vida do projeto. Sua função é definir e alcançar objetivos ao mesmo tempo em que se otimiza o uso de recursos (tempo, dinheiro, pessoas, espaço etc).

2

Define-se fase do projeto um conjunto de atividades do projeto relacionadas de forma lógica que geralmente culminam com o término de uma entrega importante. Na maioria dos casos, as fases do projeto são terminadas seqüencialmente, mas podem se sobrepor em algumas situações 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 analítica 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 estão os processos que definem e autorizam o início de um projeto ou de uma fase, assegurando o comprometimento necessário para execução. Na segunda fase estão os processos que planejam e mantêm um esquema de trabalho viável para se atingir os objetivos do projeto. A terceira fase envolve o planejamento detalhado do projeto. A quarta fase é a conclusão do projeto.

De acordo com o PMBOK, todos os projetos podem ser mapeados para a estrutura de ciclo de vida:

Início do projeto Organização e preparação Execução do trabalho do projeto Encerramento do projeto.

Esta estrutura genérica de ciclo de vida é frequentemente referenciada na comunicação com a alta administração ou outras entidades menos familiarizadas com os detalhes do projeto. Esta visão de alto nível pode oferecer um quadro de referência comum para comparação de projetos, mesmo que, em sua natureza, eles não sejam semelhantes.

Na abordagem tradicional, distinguimos cinco grupos de processos no desenvolvimento de um projeto:

iniciação – autorização do projeto ou fase

planejamento – são processos iterativos de definição e refinamento de objetivos e seleção dos melhores caminhos para atingir os objetivos.

execução – realização dos planos do projeto: coordenação de pessoas e outros recursos para executar o plano

1 http://pt.wikipedia.org/wiki/Projeto 2 http://pt.wikipedia.org/wiki/Gerência_de_projetos

TI para concursos

2

controle – medição e monitoramento do desempenho do projeto. Garantem que os objetivos do projeto são alcançados através do monitoramento e medição regular do progresso, de modo que ações corretivas possam ser tomadas quando necessário.

encerramento – aceitação formal do projeto (com verificação de escopo) ou fase para a sua finalização.

Repetir os processos de iniciação antes da execução de cada fase é uma maneira de se avaliar se o projeto continua cumprindo as necessidades de negócio. Envolver as partes interessadas no projeto em cada uma das fases é uma maneira de aumentar as probabilidades de satisfação dos requisitos do cliente.

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

Um escritório de projetos (Project Management Office, PMO) é um corpo ou entidade organizacional à qual são atribuídas várias responsabilidades relacionadas ao gerenciamento centralizado e coordenado dos projetos sob seu domínio.

O projeto ou empreendimento visa a satisfação 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 solução ou alternativas para atender às mesmas necessidades. A técnica usada para definir a solução final passa pelo desenvolvimento de alternativas extremas. A primeira, de baixo custo, que atende as necessidades mínimas para ser funcional. A segunda tenta atender a maior parte das as exigências 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 solução intermediária entre as mesmas, que atende a uma boa parte das exigências com um custo competitivo.

O gerenciamento de projetos tenta adquirir controle sobre as variáveis

tempo - influencia o prazo até o termino do projeto. Uma restrição de tempo pode significar custos aumentados e/ou escopo reduzido.

custo - informa o valor monetário incluído no orçamento disponível para o projeto. Um orçamento 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 versão atual do PMBOK, tríplice restrição foi eliminada, passando a existir restrições do projeto que são elas: Escopo, Qualidade, Cronograma, Orçamento, Recursos e Riscos. Portanto, qualquer alteração em um desses itens certamente haverá restrições em um ou mais dos demais itens.

Para manter o controle sobre o projeto do início ao fim, um gerente de projetos utiliza várias técnicas, dentre as quais se destacam:

Planejamento de projeto

Análise de valor agregado

Gerenciamento de riscos de projeto

Cronograma

Melhoria de processo

1.2 Processos do PMBOK

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

projetos, que é amplamente reconhecido como boa prática, sendo em razão disso, utilizado como base pelo Project Management Institute (PMI). Uma boa prática não significa que o conhecimento e as práticas devem ser aplicadas uniformemente a todos os projetos, sem considerar se são ou não apropriados.

O Guia PMBOK também fornece e promove um vocabulário comum para se discutir, escrever e aplicar o gerenciamento de projetos possibilitando o intercâmbio eficiente de informações entre os profissionais de gerência de projetos.

O guia é baseado em processos e subprocessos para descrever de forma organizada o trabalho a ser realizado durante o projeto. Essa abordagem se assemelha à empregada por outras normas como a ISO 9000 e o Software Engineering Institute's, CMMI.

A versão 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: 3 http://pt.wikipedia.org/wiki/PMBOK

TI para concursos

3

Definição do ciclo de vida e da organização de um projeto

Descrição dos cinco grupos de processos de gerenciamento de projetos

Grupo de processos de iniciação Grupo de processos de planejamento Grupo de processos de execução Grupo de processos de monitoramento e controle Grupo de processos de encerramento

Descrição das nove áreas de conhecimento

Existem três documentos principais descritos no Guia PMBOK® e cada um deles possui um objetivo específico:

Termo de abertura do projeto. Autoriza formalmente o projeto. Declaração 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 Diferenças entre a edição 3 e 4 do PMBOK

Todos os nomes de processos estão no formato verbo-substantivo.

Foi empregada uma abordagem padrão à discussão de fatores ambientais da empresa e de ativos de processos organizacionais.

Foi empregada uma abordagem padrão à discussão de mudanças, ações preventivas e corretivas e reparos de defeitos.

O número de processos foi reduzido de 44 para 42. Dois processos foram excluídos, dois foram adicionados e seis foram reconfigurados em quatro processos na Área de conhecimento em gerenciamento de aquisições do projeto.

A fim de proporcionar clareza, uma distinção foi feita entre o plano de gerenciamento do projeto e os documentos de projeto usados para gerenciá-lo.

A distinção entre as informações no Termo de abertura do projeto e na Declaração do escopo do projeto foi esclarecida.

Os diagramas de fluxo do processo no início dos Capítulos 4 a 12 foram excluídos.

Um diagrama de fluxo de dados foi criado para cada processo para mostrar os processos relacionados às suas entradas e saídas.

Um novo apêndice foi adicionado para abordar as principais habilidades interpessoais usadas por um gerente de projetos durante o gerenciamento

TI para concursos

4

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.

Iniciação Planejamento Execução Monitoramento e controle Encerramento

4 - Integração

Desenvolver o termo de

abertura do projeto

Desenvolver o plano de gerenciamento de projeto

Orientar e gerenciar a execução do

projeto

Monitorar e controlar o trabalho do projeto

Controle integrado de mudanças

Encerrar o projeto

5 - Escopo Coletar requisitos

Definição do escopo Criar EAP

Verificação do escopo Controle do escopo

6 - Tempo

Definição das atividades

Sequenciamento de atividades Estimativa de recursos das atividades Estimativa de duração das atividades Desenvolvimento do cronograma

Controle do cronograma

7 - Custo Estimativa de custos

Orçamentação Controle de custos

8 - Qualidade Planejamento da qualidade Realizar a garantia

da qualidade Realizar o controle da qualidade

9 - RH

Desenvolver o plano de recursos humanos

Mobilizar a equipe do projeto

Desenvolver a equipe do projeto Gerenciar a equipe do projeto

10 - Comunicação

Identificar as partes interessadas

Planejamento das comunicações Distribuição das informações Gerenciar as expectativas das

partes interessadas

Relatório de desempenho

11 - Riscos

Planejamento de gerenciamento de riscos

Identificação dos riscos Análise qualitativa dos riscos Análise quantitativa dos riscos Planejamento de respostas a riscos

Monitoramento e controle de riscos

12 - Aquisições Planejar as aquisições

Realizar aquisições Administração de

aquisições Encerramentos de aquisições

Os processos descritos se relacionam e interagem durante a condução do trabalho e a descrição de cada um deles é feita em termos de Entradas – documentos, planos, desenhos etc., Ferramentas e técnicas – 145 ferramentas que se aplicam as entradas, e Saidas – que podem ser entradas de outros processos

A transição de uma fase para a outra dentro do ciclo de vida de um projeto normalmente é definida por alguma forma de transferência técnica ou entrega. As entregas de uma fase geralmente são revisadas, para garantir que estejam completas e exatas, e aprovadas antes que o trabalho seja iniciado na próxima fase. No entanto, não é incomum que uma fase seja iniciada antes da aprovação das entregas da fase anterior, quando os riscos envolvidos são considerados aceitáveis. Essa prática de sobreposição de fases, normalmente feita em seqüência, é um exemplo da aplicação da técnica de compressão do cronograma denominada paralelismo.

De acordo com o PMBOK, a estrutura genérica do ciclo de vida tem por características:

níveis baixos de custo no início, atingindo seu máximo na execução e diminuindo ao final

TI para concursos

5

riscos e incertezas altos no início maior capacidade de modificação sem aumento significativo de custos no início

1.2.3 Processos, ferramentas e técnicas 4 – Integração

Processos e as atividades necessárias para identificar, definir, combinar, unificar e coordenar os vários processos e atividades dos grupos de processos de gerenciamento

Desenvolver o termo de abertura do projeto

Autorizar formalmente um projeto Métodos de seleção de projetos Metodologia de gerenciamento de projetos Sistema de informações do gerenciamento de projetos

Opinião especializada

Desenvolver o plano de

gerenciamento de projeto

Definir, coordenar e integrar todos os planos

auxiliares

Metodologia de gerenciamento de projetos

Sistema de informações do gerenciamento de projetos Opinião especializada

Orientar e gerenciar a execução do projeto

Ações para que seja realizado o trabalho definido na declaração do escopo do projeto

Metodologia de gerenciamento de projetos Sistema de informações do gerenciamento de projetos

Monitorar e controlar o trabalho do projeto

Ações preventivas ou corretivas para controlar o desempenho do projeto

Metodologia de gerenciamento de projetos Sistema de informações do gerenciamento de projetos Técnica do valor agregado

Opinião especializada

Realizar o controle integrado de mudanças

revisão de todas as solicitações, aprovação e gerenciamento de mudanças nas entregas,

ativos de processos organizacionais, documentos de projeto e plano de gerenciamento do projeto.

Metodologia de gerenciamento de projetos Sistema de informações do gerenciamento de projetos

Opinião especializada

Encerrar o projeto Documentar as entregas do projeto, formalizar a aceitação pelo cliente e investigar e

documentar as razões se um projeto for abortado.

Metodologia de gerenciamento de projetos Sistema de informações do gerenciamento de projetos

Opinião especializada

5 – Escopo Processos necessários para assegurar que o projeto inclui todo o trabalho necessário, e apenas o necessário, para terminar o projeto

com sucesso.

Coletar os requisitos Definição e documentação das

necessidades das partes interessadas para alcançar os objetivos do projeto

Opinião especializada

Modelos, formulários, normas

Definição do escopo Desenvolvimento de uma declaração do escopo detalhada do projeto como a base

para futuras decisões do projeto.

Análise de produtos Identificação de alternativas

Opinião especializada Análise das partes interessadas

Criar EAP Subdivisão das principais entregas do

projeto e do trabalho do projeto em componentes menores e mais facilmente gerenciáveis.

Modelos da estrutura analítica do projeto

Decomposição

Verificação do escopo Formalização da aceitação das entregas do projeto terminadas.

Inspeção

Controle do escopo Controle das mudanças no escopo do

projeto.

Sistema de controle de mudanças

Análise da variação Replanejamento Sistema de gerenciamento de configuração

TI para concursos

6

6 – Tempo Processos necessários para gerenciar o término pontual do projeto

Definição das atividades Identificação das atividades específicas do cronograma que precisam ser realizadas

para produzir as várias entregas do projeto.

Decomposição Modelos

Planejamento em ondas sucessivas Opinião especializada Componente do planejamento

Sequenciamento de

atividades

Identificação e documentação das

dependências entre as atividades do cronograma

Método do diagrama de precedência (MDP)

Método do diagrama de setas (MDS) Modelos de rede do cronograma Determinação da dependência

Estimativa de recursos das atividades

Estimativa do tipo e das quantidades de recursos necessários para realizar cada

atividade do cronograma.

Opinião especializada Análise de alternativas

Dados publicados para auxílio a estimativas Software de gerenciamento de projetos Estimativa “bottom-up”

Estimativa de duração das

atividades

Estimativa do número de períodos de

trabalho que serão necessários para terminar as atividades individuais do cronograma.

Opinião especializada

Estimativa análoga Estimativa paramétrica Estimativas de três pontos

Análise das reservas

Desenvolvimento do cronograma

Análise dos recursos necessários, restrições do cronograma, durações e

seqüências de atividades para criar o cronograma do projeto.

Análise de rede do cronograma Método do caminho crítico

Compressão do cronograma Análise de cenário do tipo "e se?" Nivelamento de recursos

Método da cadeia crítica Software de gerenciamento de projetos Aplicação de calendários

Ajuste de antecipações e atrasos Modelo de cronograma

Controle do cronograma Controle das mudanças no cronograma do projeto.

Relatório de progresso Sistema de controle de mudanças no cronograma Medição de desempenho

Software de gerenciamento de projetos Análise da variação Gráficos de barras de comparação do cronograma

7 – Custo Processos envolvidos em estimativas, orçamentos e controle dos custos, de modo que o projeto possa ser terminado dentro do orçamento aprovado.

Estimativa de custos Desenvolvimento de uma estimativa dos custos dos recursos necessários para

terminar as atividades do projeto.

Estimativa análoga Determinar os valores de custo de recursos

Estimativa “bottom-up” Estimativa paramétrica Software de gerenciamento de projetos

Análise de proposta de fornecedor Análise das reservas Custo da qualidade

Orçamentação Agregação dos custos estimados de atividades individuais ou pacotes de

trabalho para estabelecer uma linha de base dos custos.

Agregação de custos Análise das reservas

Estimativa paramétrica Reconciliação dos limites de financiamento

Controle de custos Controle dos fatores que criam as variações de custos e controle das mudanças no orçamento do projeto

Sistema de controle de mudanças nos custos Análise de medição de desempenho Previsão

Análises de desempenho do projeto

TI para concursos

7

8 – Qualidade Processos e as atividades da organização executora que determinam as políticas de qualidade, os objetivos e as responsabilidades, de

modo que o projeto satisfaça às necessidades para as quais foi empreendido.

Planejamento da qualidade Identificação dos padrões de qualidade

relevantes para o projeto e determinação de como satisfazê-los.

Análise de custo-benefício

Benchmarking Projeto de experimentos Custo da qualidade (CDQ)

Ferramentas adicionais de planejamento da qualidade

Realizar a garantia da qualidade

Aplicação das atividades de qualidade planejadas e sistemáticas para garantir que o projeto emprega todos os processos

necessários para atender aos requisitos.

Ferramentas e técnicas de planejamento da qualidade Auditorias de qualidade Análise do processo

Ferramentas e técnicas de controle da qualidade

Realizar o controle da

qualidade

Monitoramento de resultados específicos

do projeto a fim de determinar se eles estão de acordo com os padrões relevantes de qualidade e identificação de maneiras

de eliminar as causas de um desempenho insatisfatório.

Diagrama de causa e efeito (Ishikawa ou diagramas

espinha de peixe) Gráficos de controle Elaboração de fluxogramas

Histograma Diagrama de Pareto Gráfico de execução

Diagrama de dispersão Amostragem estatística Inspeção

Revisão de reparo de defeito

9 - RH Processos que organizam e gerenciam a equipe do projeto. A equipe do projeto consiste nas pessoas com papéis e responsabilidades

designadas para a conclusão do projeto.

Desenvolver o plano de recursos humanos

Identificação e documentação de funções, responsabilidades e relações hierárquicas

do projeto, além da criação do plano de gerenciamento de pessoal.

Organogramas e descrições de cargos Networking

Teoria organizacional

Mobilizar a equipe do

projeto

Obtenção dos recursos humanos

necessários para terminar o projeto.

Pré-designação

Negociação Contratação ou mobilização Equipes virtuais

Desenvolver a equipe do projeto

Melhoria de competências e interação de membros da equipe para aprimorar o

desempenho do projeto.

Habilidades de gerenciamento geral Treinamento

Atividades de formação da equipe Regras básicas Agrupamento

Reconhecimento e premiações

Gerenciar a equipe do

projeto

Acompanhamento do desempenho de

membros da equipe, fornecimento de feedback, resolução de problemas e coordenação de mudanças para melhorar o

desempenho do projeto.

Observação e conversas

Avaliações de desempenho do projeto Gerenciamento de conflitos Registro de problemas

10 – Comunicação Processos relativos à geração, coleta, disseminação, armazenamento e destinação final das informações do projeto de forma oportuna e apropriada.

Identificar as partes interessadas

identificação de todas as pessoas ou organizações que podem ser afetadas pelo

projeto e de documentação das informações relevantes relacionadas aos seus interesses, envolvimento e impacto no

sucesso do projeto

Análise das partes interessadas Opinião especializada

Planejamento das comunicações

Determinação das necessidades de informações e comunicações das partes

interessadas no projeto.

Análise dos requisitos das comunicações Tecnologia das comunicações

Distribuição das informações

Colocação das informações necessárias à disposição das partes interessadas no projeto no momento adequado.

Habilidades de comunicação Sistemas de coleta e recuperação de informações Métodos de distribuição das informações

Processo de lições aprendidas

Gerenciar as expectativas das partes interessadas

processo de comunicação e interação com as partes interessadas para atender às

suas necessidades e solucionar as questões à medida que ocorrerem

Métodos de comunicação Registros de problemas

Relatório de desempenho Coleta e distribuição das informações sobre

o desempenho. Isso inclui o relatório de andamento, medição do progresso e previsão.

Ferramentas de apresentação de informações

Coleta e compilação das informações sobre o desempenho

Reuniões de avaliação do andamento

Sistemas de relatórios de horas

TI para concursos

8

Sistemas de relatórios de custos

11 – Riscos Processos envolvidos em identificação, análise e controle dos riscos do projeto.

Planejamento de gerenciamento de riscos

Decisão de como abordar, planejar e executar as atividades de gerenciamento de riscos de um projeto.

Análise e reuniões de planejamento

Identificação dos riscos Determinação dos riscos que podem afetar o projeto e documentação de suas características.

Revisões da documentação Técnicas de coleta de informações Análise da lista de verificação

Análise das premissas Técnicas com diagramas

Análise qualitativa dos

riscos

Priorização dos riscos para análise ou ação

adicional subseqüente através de avaliação e combinação de sua probabilidade de ocorrência e impacto.

Avaliação de probabilidade e impacto de riscos

Matriz de probabilidade e impacto Avaliação da qualidade dos dados sobre riscos Categorização de riscos

Avaliação da urgência do risco

Análise quantitativa dos riscos

Análise numérica do efeito dos riscos identificados nos objetivos gerais do projeto.

Técnicas de representação e coleta de dados Análise quantitativa de riscos e técnicas de modelagem

Planejamento de respostas a riscos

Desenvolvimento de opções e ações para aumentar as oportunidades e reduzir as ameaças aos objetivos do projeto.

Estratégias para riscos negativos ou ameaças Estratégias para riscos positivos ou oportunidades Estratégia para ameaças e oportunidades

Estratégia para respostas contingenciadas

Monitoramento e controle

de riscos

Acompanhamento dos riscos identificados,

monitoramento dos riscos residuais, identificação dos novos riscos, execução de planos de respostas a riscos e avaliação

da sua eficácia durante todo o ciclo de vida do projeto.

Reavaliação de riscos

Auditorias de riscos Análise das tendências e da variação Medição do desempenho técnico

Análise das reservas Reuniões de andamento

12 – Aquisições Processos envolvidos na compra ou aquisição de produtos, serviços ou resultados para o projeto.

Planejar aquisições Documentação das decisões de compras

do projeto, especificando a abordagem e identificando fornecedores em potencial

Análise de fazer ou comprar

Opinião especializada Tipos de contratos

Realizar as aquisições Obtenção de respostas de fornecedores, seleção de um fornecedor e adjudicação de

um contrato

Reuniões com licitantes Técnicas de avaliação de propostas

Estimativas independentes Opinião especializada Publicidade

Pesquisa na internet Negociações das aquisições

Administração de

aquisições

gerenciamento das relações de

aquisição, monitorando o desempenho do contrato e realização de mudanças e correções conforme necessário

Sistema de controle de mudanças no contrato

Análise de desempenho conduzida pelo comprador Inspeções e auditorias Relatório de desempenho

Sistema de pagamentos Administração de reclamações Sistema de gerenciamento de registros

Tecnologia da informação

Encerramentos de aquisições

Terminar e liquidar cada contrato, inclusive a resolução de quaisquer itens em aberto,

e encerrar cada contrato aplicável ao projeto ou a uma fase do projeto.

Auditorias de aquisição Sistema de gerenciamento de registros

1.3 Planejamento e controle de métricas de projeto

Métricas são medidas quantitativas que podem produzir informações usadas para minimizar atrasos e riscos, e para avaliar a qualidade durante o desenvolvimento.

Definições:

Medida - fornece uma indicação quantitativa da extensão, quantidade, dimensão, capacidade ou tamanho de algum

atributo de um produto ou processo.

Medição - ato de determinação de uma medida.

Métrica - medida quantitativa do grau em que um sistema se encontra em relação a um determinado atributo.

Ilustração 1 Métricas

TI para concursos

9

Indicadores - métrica ou combinação de métricas que fornece uma compreensão de um processo, projeto ou produto.

Tipos de métricas:

Diretas - custo, esforço, linhas de código (LOC), velocidade de execução, memória utilizada, defeitos reportados etc.

Indiretas - qualidade, funcionalidade, complexidade, eficiência, confiabilidade, manutebilidade etc.

O planejamento de métricas pode ser feito em etapas.

Fase 1 – caracterização dos indicadores

Fase 2 – medição

Fase 3 – tratamento estatístico

Fase 4 – monitoramento e análise

Fase 5 – gestão do processo

As tendências são mais importantes de serem monitoradas do que qualquer valor absoluto no tempo. As métricas para determinados aspectos do projeto incluem:

Métrica Finalidade Exemplos de medidas/perspectivas

Andamento em termos de tamanho e

complexidade

Planejamento de iteração Abrangência

Número de classes

SLOC

Pontos de função

Cenários

Casos de teste

Essas medidas também podem ser coletadas por classe e por pacote

Quantidade de retrabalho por iteração (número de classes)

Estabilidade em termos

de taxa de mudança nos requisitos ou implementação, tamanho ou

complexidade

Convergência Número e tipo de mudanças (erro versus melhoria; interface versus implementação)

Essa medida também pode ser coletada por iteração e por pacote

Quantidade de retrabalho por iteração

Adaptabilidade Convergência

"Retrabalho" de software Média de pessoa-horas/mudança

Essa medida também pode ser coletada por iteração e por pacote

Modularidade em termos do escopo de

mudança

Convergência "Retalhamento" de software

Número de classes/categorias modificadas por mudança

Essa medida também pode ser coletada por iteração

Qualidade em termos da quantidade e do tipo

de erros

Planejamento de iteração Indicador de retrabalho

Critério de release

Número de erros

Taxa de detecção de defeitos

Densidade de defeitos

Profundidade da herança

Acoplamento de classes

Tamanho da interface (número de operações)

Número de métodos substituídos

Tamanho do método

Essas medidas também podem ser coletadas por classe e por pacote

Maturidade em termos

da freqüência de erros

Adequação/cobertura de

teste Resistência para uso

Falha/horas de teste e tipo de falha

Essa medida também pode ser coletada por iteração e por pacote

Perfil de despesas do projeto versus

despesas planejadas

Visão financeira Planejado versus real

Pessoa-dias/classe

Equipe em tempo integral por mês

Porcentagem do orçamento já gasta

1.4 Métodos de gerenciamento do tempo do projeto

Existem métodos que objetivam formas de comprimir as durações das atividades sem alteração no escopo do projeto.

Crashing é usado para diminuir a duração total do cronograma do projeto pelo menor custo adicional, como redução das durações ou aumento da atribuição de recursos nas atividades do cronograma.

TI para concursos

10

Paralelismo ou fast tracking é usado para tentar programar atividades em paralelo (simultâneas), mas costuma gerar retrabalho e aumenta os riscos. É uma técnica de compressão do cronograma de um projeto específico que altera a lógica de rede para sobrepor fases que normalmente seriam realizadas em seqüência, como a fase de projeto e a fase de construção, ou para realizar atividades do cronograma em paralelo.

Uma simulação do projeto utiliza um modelo que traduz as incertezas especificadas em um nível detalhado do projeto para seu impacto potencial nos objetivos do projeto. As simulações são normalmente realizadas usando a técnica de Monte Carlo. Em uma simulação, o modelo do projeto é calculado muitas vezes (iterado), sendo os valores das entradas randomizados a partir de uma função de distribuição de probabilidades (por exemplo, custo dos elementos do projeto ou duração das atividades do cronograma) escolhida para cada iteração a partir das distribuições de probabilidades de cada variável. Uma distribuição de probabilidades (por exemplo, custo total ou data de término) é calculada.

1.5 Exercícios

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 esforço contínuo que visa manter um serviço em funcionamento.

xx

(c) Geralmente, o termo "temporário" não se aplica ao produto, serviço 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 serviço.

2. (ICMS-SP 2009) São entradas para o processo de Planejamento da Qualidade (PMBOK):2

(a) Fatores ambientais da empresa, Ativos de processos organizacionais e Declaração do escopo do projeto.

xx

(b) Análise de custo-benefício, Projeto de experimentos e Métricas de qualidade. (c) Plano de melhorias no processo, Linha de base da qualidade e Métricas de qualidade. (d) Plano de melhorias no processo, Fatores ambientais da empresa e Listas de verificação da qualidade. (e) Plano de gerenciamento da qualidade, Fatores ambientais da empresa e Análise de custo-benefício.

3. (ICMS-SP 2009) No PMBOK, a técnica que compara as realizações técnicas durante a execução do projeto com as do cronograma do plano de gerenciamento do projeto, podendo usar parâmetros técnicos importantes do produto desenvolvido pelo projeto como uma métrica de qualidade, sendo que os valores medidos fazem parte das informações sobre o desempenho do trabalho, é denominada

3

(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 iterações do processo de planejamento e estimativas mais exatas, elaboradas à medida que o projeto se desenvolve, são produtos da técnica aplicada para melhoria e detalhamento contínuos dos planos. Essa técnica, no PMBOK, é denominada

4

(a) Loop de rede. (b) Elaboração progressiva.

xx

(c) Estrutura Analítica dos Recursos. (d) Gerenciamento de Portfólios. (e) Estimativa paramétrica.

5. Segundo o PMBOK, as etapas de iniciação, planejamento, execução, monitoração/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: criação da estrutura analítica do projeto (EAP) e verificação do escopo do projeto devem ser realizados, respectivamente, nas etapas de

6

(a) planejamento e execução. (b) planejamento e monitoração/controle.

xx

(c) iniciação e execução. (d) iniciação e monitoração/controle. (e) iniciação e encerramento.

TI para concursos

11

7. Considere a seguinte definição com respeito à gerência de projetos: Ferramenta de decomposição do trabalho do projeto em partes manejáveis. É uma estrutura em forma de árvore exaustiva, hierárquica (de mais geral para mais específica ) de deliverables e tarefas que precisam ser feitas para completar um projeto. Tal é a definição de

7

(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 ser mais facilmente dimensionadas em relação a tempo de execução, recursos e custos, é o

8

(a) Flowchart. (b) Organization Chart. (c) Workflow. (d) Histogram. (e) Work Breakdown Structure.

xx

9. De acordo com o corpo de conhecimento da gerência de projetos, as simulações para análise de risco de prazos são possíveis utilizando

9

(a) o Arrow Diagramming Method. (b) a técnica Monte Carlo.

xx

(c) o modelo WBS. (d) a análise de custo/benefício. (e) o Project Charter.

10. O WBS, Word Breakdown Structure, é a principal ferramenta de gerenciamento de 10

(a) escopo do projeto.

xx

(b) integração dos elementos do projeto. (c) pessoal envolvido com o projeto. (d) comunicação das informações do projeto. (e) qualidade do projeto.

11. Considere a seguinte figura: No contexto da gerência de projetos de software, o diagrama parcialmente mostrado na figura representa, tipicamente,

11

(a) um PERT. (b) um gráfico de Gantt. (c) uma Work Breakdown Structure.

xx

(d) um Project Charter. (e) um Flowchart.

12. De acordo com o corpo de conhecimento da gerência de projeto, a necessidade de traduzir as necessidades implícitas em necessidades declaradas, através da gerência do escopo do projeto, é

12

(a) um aspecto crítico da gerência da qualidade, no contexto do projeto.xx

(b) objeto de avaliação da gerência do custo do projeto. (c) dispensada se for elaborado um planejamento de respostas aos riscos. (d) destacada durante a medição de desempenho. (e) um aspecto crítico da análise de precedência de tarefas.

13. De acordo com o corpo de conhecimento da gerência de projeto, para estimar os custos totais, quando ainda existe uma quantidade limitada de informações detalhadas sobre o projeto (por exemplo, nas fases iniciais), é freqüentemente

13

(a) elaborado um modelo paramétrico. (b) usada uma estimativa por analogia.

xx

(c) usada uma estimativa bottom-up. (d) elaborada uma análise de precedência. (e) elaborada uma análise da variação.

14. Existem métodos que objetivam formas de comprimir as durações das atividades sem alteração no escopo do projeto. Um deles é usado para quando existem negociações de agenda e custos para determinar como (e se) fazer a maior compressão para o menor custo. Outro é usado para tentar programar atividades em paralelo (simultâneas), mas costuma gerar retrabalho e aumenta os riscos. São usual e respectivamente denominados de métodos

14

(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.

TI para concursos

12

15. Para um gerenciamento de projeto de informática bem sucedido, a ordem de execução das atividades deve ser 15

(a) planejamento, integração, organização, medição e revisão. (b) planejamento, organização, integração, medição e revisão.

xx

(c) organização, planejamento, integração, medição e revisão. (d) organização, planejamento, medição, integração e revisão. (e) planejamento, organização, medição, revisão e integração.

16. (ARCE FCC 2006) O fator de máximo desempenho de um projeto está diretamente relacionado ao fator de 16

(a) escopo limitado. (b) escopo genérico. (c) tempo reduzido. (d) custo alto.

xx

(e) tempo excessivo.

17. (CVM FCC 2006) Dentre os fatores que afetam os projetos, o fator performance se aproxima do máximo, ou ponto ótimo, quando relacionado ao fator

17

(a) custo alto.xx

(b) tempo reduzido. (c) tempo excessivo. (d) escopo limitado. (e) escopo genérico.

18. Duas atividades de um projeto podem ocorrer simultaneamente quando o inter-relacionamento das mesmas é do tipo

18

(a) início para início (SS) ou término para início (FS). (b) término para término (FF) ou término para início (FS). (c) início para início (SS) ou término para término (FF).

xx

(d) início para término (SF) ou término para término (FF). (e) término para início (FS) ou início para término (SF).

19. Os produtos a serem entregues no mais baixo nível da estrutura do projeto (WBS) geralmente são 19

(a) pacotes de trabalho.

xx

(b) planos do projeto. (c) fases do projeto. (d) recursos disponíveis. (e) cronogramas do projeto.

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

(a) um empreendimento não repetitivo de eventos numa seqüência clara e lógica, com início, meio e fim. (b) parte de um projeto ou subdivisão tática de fácil gerenciamento e controle. (c) um subprojeto, desvinculado de um projeto, que pode ser terceirizado. (d) um conjunto integrado de projetos que tem missões e objetivos comuns.

xx

(e) um conjunto de subprojetos, que podem ter vidas próprias isoladamente.

21. No ciclo da vida de um projeto, são aplicáveis todos os nove processos componentes da área de gerenciamento de projetos somente na fase de

21

(a) iniciação. (b) finalização. (c) planejamento.

xx

(d) execução. (e) controle.

22. Na determinação de cronogramas utilizando os modelos PERT e CPM, o caminho crítico representa 22

(a) a estimativa de tempo mais provável para o conjunto de tarefas do projeto. (b) o término mais breve da cada tarefa do projeto. (c) os limites de tempo que definem o início e o término da cada tarefa. (d) uma cadeia de tarefas que determina a duração do projeto.

xx

(e) uma rede de todas as tarefas desde o começo até o final de um projeto.

23. (ISS SP – 2012) Segundo o PMBOK, quando os projetos têm várias fases, estas são parte, em geral, de um processo sequencial projetado para garantir um controle adequado do projeto e obter o produto, serviço ou resultado desejado. Existem três tipos básicos de relação entre estas fases: iterativa, sequencial e

23

(a) sobreposta.xx

(b) randômica. (c) indexada. (d) modular. (e) unilateral.

TI para concursos

13

24. (ISS SP – 2012) Segundo o PMBOK, projetos variam em tamanho e complexidade, porém, 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 de

24

(a) modelagem. (b) organização e preparação.

xx

(c) execução do trabalho do projeto. (d) elicitação de requisitos. (e) análise de riscos.

25. (TCE-RJ 2012) De acordo com o PMBOK 4ª ed, um projeto pode ser dividido em fases, sendo que: 25

(a) o nível de incerteza do projeto é maior nas fases iniciais;

xx

(b) a capacidade das partes interessadas de influenciarem as características finais do produto vai aumentando à medida que o projeto vai se desenvolvendo nas diversas fases;

(c) os custos do projeto são mais altos na fase final; (d) são geralmente definidas por critérios subjetivos do solicitante do projeto; (e) o custo de promover mudanças no projeto é maior na fase inicial, dadas as indefinições ainda existentes.

26. (TCE-RJ 2012) O PMBOK define áreas de conhecimento para gestão de projetos. Os processos de estimativa de duração das atividades, do envio de relatórios de desempenho aos patrocinadores e do encerramento de contratos pertencem, respectivamente, às áreas de gerenciamento:

26

(a) do tempo, de comunicações e de aquisições;xx

(b) de integração, de escopo e de custo; (c) do tempo, de aquisições e de custo; (d) do tempo, da qualidade e de aquisições; (e) de risco, de comunicações e de custo.

27. (RFB – Analista Tributário – 2012) Com relação ao Escritório de Projetos (Project Management Office, PMO), a versão 4 do Guia PMBOK informa que ele é um corpo ou entidade organizacional a que são atribuídas varias responsabilidades relacionadas ao gerenciamento

27

(a) descentralizado e coordenado dos projetos sob seu domínio. (b) descentralizado e independente dos projetos sob seu domínio. (c) descentralizado e autônomo dos projetos sob seu domínio. (d) centralizado e autônomo dos projetos sob seu domínio. (e) centralizado e coordenado dos projetos sob seu domínio.

xx

28. (RFB – Analista Tributário – 2012) Na versão 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 informações. (e) Verificar o escopo.

29. (RFB – Analista Tributário – 2012) O Guia PMBOK na sua versão 4 apresenta as áreas de conhecimento. Uma delas é a de gerenciamento da integração do projeto. São processos desta área:

29

(a) Desenvolver o termo de abertura do projeto; Encerrar o projeto ou fase. xx

(b) Orientar e gerenciar a execução do projeto; Coletar os requisitos. (c) Sequenciar as atividades; Realizar o controle integrado de mudanças. (d) Desenvolver o plano de gerenciamento do projeto; Desenvolver o cronograma. (e) Realizar o controle integrado de mudanças; Controlar os custos.

TI para concursos

14

2 Gestão de Processos de Negócio (BPM)

A administração científica de Taylor pode ser interpretada como sendo a primeira onda da gestão de processos. Muitos dos conceitos de Taylor servem como base para os princípios de modelagem de processos, e quase um século depois, continuam vivos e fortes nos pressupostos das organizações (DAVENPORT, 1994).

A segunda onda, veio com a reengenharia de Michael Hammer (1994), baseada na idéia central de que era possível melhorar drasticamente o desempenho das empresas por meio de mudanças radicais nas operações. A popularização do conceito disseminou-se durante a década de 90, assim como outras técnicas 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 gestão e processos de negócio. Trata-se de um modelo que possibilita que empresas e colaboradores criem e otimizem processos de negócio em tempo real. Através de processos ágeis, cadeias de valor poderiam ser monitoradas e continuamente melhoradas. Essa onda não é reengenharia de processos de negócio, integração de aplicações ou gestão de workflow – é uma síntese e também uma extensão destas técnicas em um modelo unificado (SMITH; FINGAR, 2007).

4

O Business Process Management (BPM) ou Gerenciamento de Processos de Negócio é um conceito que une gestão de negócios e tecnologia da informação com foco na otimização dos resultados das organizações através da melhoria dos processos de negócio. São utilizados métodos, técnicas e ferramentas para analisar, modelar, publicar, otimizar e controlar processos envolvendo recursos humanos, aplicações, documentos e outras fontes de informação.

5

Um processo de negócio é uma sequência 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 informações que dão suporte ao negócio, enquanto aquele monitora os processos que o compõe. O BI é uma ferramenta útil à gestão de processos de negócios.

2.1 Técnicas de análise 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 técnicas.

2.1.1 BPMN - Modelagem de processos

Realizada pelos BPMS, divide-se em modelagem, simulação, execução, controle e otimização.

Um aplicativo do tipo BPMS, tipicamente, inclui o mapeamento dos processos de negócio ponta-a-ponta, desenho dos fluxos e formulários eletrônicos, definição de workflow, regras de negócio, integradores, monitoração em tempo real das atividades e alertas. É uma poderosa ferramenta de gestão, para

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

TI para concursos

15

garantir que os processos estão sendo efetivamente executados como modelados, contribuindo para os objetivos da organização.

A modelagem de processos é feita no próprio BPMS. Alguns destes seguem a notação mais usada atualmente, o BPMN (Business Process Modeling Notation). Esta notação trata-se de uma série de ícones padrões para o desenho de processos, o que facilita o entendimento do usuário. A modelagem é uma etapa importante da automação pois é nela que os processos são descobertos e desenhados. É nela também que pode ser feita alguma alteração no percurso do processo visando a sua otimização.

Após o desenho e o estabelecimento dos usuários responsáveis pela conclusão de cada tarefa, pode ser feita uma simulação, onde se pode testar se as regras pré-estabelecidas estão de acordo com o objetivo da empresa e se as tarefas estão sendo encaminhadas para as pessoas corretas.

A execução do processo ocorre após as etapas anteriores já terem sido realizadas. O BPMS utilizado faz com que as tarefas sejam enviadas para os seus devidos responsáveis, controlando o seu tempo de execução por pessoa e pelo processo em geral. Podem ser utilizadas também regras de negócio (Business Rules) pré-estabelecidas.

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

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

6

O Business Process Modeling Notation, em português Notação de Modelagem de Processos de Negócio, é uma notação da metodologia de gerenciamento de processos de negócio e trata-se de uma série de ícones padrões para o desenho de processos, o que facilita o entendimento do usuário.

A modelagem é uma etapa importante da automação, pois é nela que os processos são descobertos e desenhados. É nela também que pode ser feita alguma alteração no percurso do processo visando a sua otimização.

A notação também pode ser utilizada para a modelagem de Arquitetura de Processos.

O objetivo do BPMN é de apoiar a gestão de processos de negócios tanto para usuários técnicos e usuários de negócios, fornecendo uma notação que é intuitiva para os usuários corporativos ainda capaz de representar a semântica complexa do processo.

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

TI para concursos

16

Ilustração 2 Símbolos BMPN

2.1.2 Elementos

A modelagem em BPMN é feita através de diagramas simples, com um pequeno conjunto de elementos gráficos. Isto facilita que os usuários de negócio, bem como os desenvolvedores, entendam o fluxo e o processo. As quatro categorias básicas de elementos são as seguintes:

Objetos de Fluxo – definem o comportamento do fluxo. Fazem a movimentação das informações através de ações.

Eventos – Qualquer coisa que acontece durante o fluxo. Ações (trigger) que interferem no fluxo (result), tipicamente prazos, também podendo ser uma chamada de um sistema externo (web service) ou alguma alteração no banco de dados (watching). Representado por um círculo. Há três tipos de eventos: início, intermediário e fim.

Atividades – Ações (sub-processos ou tarefas) realizadas pelos usuários, chamados de atores, normalmente por tela de algum programa de computador. Representada por um retângulo arredondado.

Gateways – Controla a convergência e divergência da sequência de fluxos e atividades no fluxo. Determina ramificações (branch), bifurcações (forking), mistura (merging) e junções (join) de caminhos. Representado por um losango.

Objetos de Conexão

Fluxo de Sequência – seta em linha contínua ligando dois objetos, indica a ordem de execução dos objetos.

Fluxo de Mensagem – seta em linha tracejada indicando o fluxo de mensagens entre participantes Associação – linha ou seta em linha pontilhada indicando uma ligação entre uma informação,

normalmente uma anotação, e um artefato. Swim lane – uma área de agrupamento de objetos de fluxo representado por uma faixa que vai da

esquerda à direita da página, 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 interação entre pools é feita através de fluxos de mensagens. Nenhum fluxo de sequência pode ser associado a black boxes, mas os fluxos de mensagem podem ligá-los.

Lane – subdivisão de uma pool. Dados – possuem informações que os objetos de fluxo necessitam para serem realizadas

TI para concursos

17

Objetos de dados – informações armazenadas Dados de entrada – informações solicitadas Dados de saída – informações produzidas em uma atividade ou evento Armazenamento – gravação dos dados

Artefatos – informações adicionais sobre o fluxo

Grupo – agrupamento de elementos de uma mesma categoria para fins de entendimento, sem efeito sobre o fluxo. Representado por um retângulo arredondado tracejado.

Anotação – uma observação para facilitar o entendimento do fluxo para o leitor. Representado por uma linha de associação terminada por um colchete e o texto.

Mensagem – informação enviada entre dois participantes. Representado por ícone de uma carta.

Estas quatro categorias de elementos nos dão a oportunidade de fazer um diagrama de processos de negócio simples (BPD).

Ilustração 3 Exemplo de Fluxo utilizando pool, lanes, evento de início e fim, tarefas e gateway

7

2.1.3 Fluxograma

Diagrama que descreve a sequência de atividades de um processo empresarial através de uma simbologia padronizada, utilizando retângulos para representar atividades, losangos para pontos de decisão e setas para indicar o fluxo. Estes simbolos vêm acompanhado de textos explicativos.

Fácil de utilizar, mas pouco apropriado para representar processos de grande complexidade e divergências.

O fluxograma considera o processo do ponto de vista da empresa.

2.1.4 Service blueprint

Técnica de mapeamenteo de serviços derivado do fluxograma que considera o aspecto de interação com o cliente.

É um mapa de todas as transações que constituem o processo de entrega do serviço.

Divide-se em duas regiões separadas por uma linha, chamada de linha de visibilidade.

Na parte de cima da linha, é a área de evidências físicas percebida pelo cliente, as suas ações e interações com os empregados. Na parte de baixo, encontram-se as ações dos empregados e os processos de suporte que são invisíveis para o cliente.

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

TI para concursos

18

As evidências físicas, mostradas na parte de cima, identificam elementos que o cliente pode usar como indicador da qualidade do serviço. Cada conexão vertical através da linha de interação indica um ponto de contato. Estes pontos funcionam como o “momento da verdade” de cada serviço e podem ser usados como pontos de potencial falhas no sistema de serviço.

Fonte: http://www.lgti.ufsc.br/public/luciano.pdf

Apesar de ser mais evoluido do que os fluxogramas, também não consegue representar uma descrição completa da experiência com o cliente. O foco está na tarefa e não no cliente.

2.1.5 Mapa do serviço

Forma visual de três elementos críticos de serviços: processso de entrega de serviço, os papéis dos clientes e empregados e elementos visíveis de serviço. A criação do mapa requer a identificação de evidências físicas do serviço, indicadores de qualidade, as pessoas envolvidas e o fluxo operacional de atividades de entrega de serviços. Foca os serviços do ponto de vista do consumidor.

É uma evolução 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 relação entre o suporte e o processso de entrega de serviço. Mais abaixo, outra linha separa a gerência do suporte.

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

2.1.6 IDEF

Família de métodos de estruturar e analisar uma empresa. Utilizam-se de diagramas para representar os processos.

TI para concursos

19

Cada tarefa é representada por um retângulo. Cada lado representa uma informação de entrada, saída de produtos e/ou informações, recursos disponíveis e condições para ativação.

A ênfase não está na sequência, mas no conteúdo das atividades e nos recursos envolvidos no processo. Exemplo:

2.1.6.1 IDEF0 Método de modelagem funcional usado para processos associados a decisões, ações e atividades.

2.1.6.2 IDEF1 Método de modelagem de informação, para expressão dos requisitos de um sistema.

2.1.6.3 IDEF3 Método de captura da descrição do processo, que relaciona causa e efeito entre processos.

2.1.6.4 IDEF4 Método de desenho orientado a objeto, que auxilia no projeto de sistemas orientados a objetos.

2.1.6.5 IDEF5 Método de identificação de ontologias associadas aos processos e informações.

2.1.6.6 IDEF9 Método para auxiliar na identificação de restrições associadas a um sistema ou processo.

2.1.7 Estrutura de processamento de clientes

Modelo genérico de atividades-chave que são comuns à maioria dos processos de serviços. Visa especificamente o fluxo de clientes, indicando apenas atividades com eles.

São identificadas sete atividades-chave:

seleção, cliente decide a escolha

ponto de entrada, contato com a operação escolhida

tempo de resposta, tempo de espera para que o sistema responda

ponto de impacto, cliente é atendido

prestação de serviço, o serviço é prestado

ponto de partida, o cliente sai do processo

acompanhamento, atividades sobre o cliente após a conclusão do serviço

2.1.8 Walk-through-audit

Método de auditoria, que consiste em uma série de questões dirigidas aos clientes, e gerentes de serviços, para avaliação sistemática da visão do cliente sobre o serviço prestado.

Utilizam-se questões estruturadas que avaliam cada etapa do processo em uma escala de um a cinco, respondidas durante ou imediatamente após o serviço, ou aplicadas em clientes da concorrência.

Além de avaliar a percepção do cliente, também permite analisar a lacuna entre a opinião do cliente e da gerência e entre a empresa e a concorrência.

Funciona em conjunto com alguma outra técnica gráfica.

Processo Entradas Saídas

Controle

Mecanismo

TI para concursos

20

2.1.9 Análise da transação de serviço (STA – Service Transaction Analysis)

Método de avaliação do processo do ponto de vista do cliente, combinando quatro elementos: o conceito do serviço, o processo do serviço, a avaliação da qualidade em cada transação e a interpretação do serviço pelo cliente. Utiliza um formulário denominado “folha de análise da transação de serviço”.

Pessoas fazendo papel de clientes caminham ao longo do processo para analisar como o cliente poderia avaliar cada transação, usando uma mensagem curta e uma escala de três 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 conteúdo para uma série de outros sites ou subsites dentro, e também fora, do domínio ou subdomínio da empresa gestora do portal.

8

Na sua estrutura mais comum, os portais constam de um motor de busca, um conjunto, por vezes considerável, de áreas subordinadas com conteúdos próprios, uma área de notícias, um ou mais fóruns e outros serviços de geração de comunidades e um diretório, podendo incluir ainda outros tipos de conteúdos.

Para construir um portal é aconselhável utilizar ferramentas de gestão de conteúdo (CMS) em vez de tradicionais editores de HTML. Estes recursos ajudam a concentrar o trabalho num nível mais abstrato, na medida em que alguns aspectos tecnológicos já são automatizados. Uma das vantagens no uso dessas ferramentas é o fato de, na maior parte dos casos, possibilitar a troca do modelo de página sem que o conteúdo e a sua disposição no site sejam alterados; apenas a aparência é modificada.

Os Portais Corporativos têm entre suas características, a funcionalidade de oferecer acesso simplificado às informações e às aplicações, por utilizar o ambiente Web como sua camada de apresentação. Desta forma, a interação com o usuário se torna mais amigável e as informações apresentadas de forma mais simples e compreensível.

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

TI para concursos

21

Os Portais podem oferecer acesso a um grande número de colaboradores às informações estruturadas (informações armazenadas em sistemas e bases de dados, como por exemplo, datawarehouses e sistemas legados), assim como às informações não estruturadas (informações armazenadas em arquivos de texto, planilhas eletrônicas, arquivos de e-mail, dentre outros). O acesso a estas informações estruturadas ou não estruturadas se dá na maioria das vezes através do uso de APIs (Application Program Interfaces), também chamadas de applets, portlets, adaptadores ou conectores, sendo o acesso às informações estruturadas mais facilitado, pois através das linguagens de programação pode-se utilizar de APIs que facilitem ao colaborador acessar as informações através de interfaces intuitivas e amigáveis. Já para acessar as informações não estruturadas, é necessário utilizar, em conjunto com as APIs, métodos de categorização e taxonomia, mecanismos de busca.

Os métodos de categorização e taxonomia visam organizar as informações, criando informações sobre as informações (metadados) para assim, os mecanismos de busca retornarem as informações que o usuário deseja de forma mais precisa.

Existem quatro tipos de portais:

Portais Informativos - Portais que levam informações ao usuários;

Portais Colaborativos - Portais que habilitam as equipes de trabalho estabelecerem áreas de projetos virtuais ou comunidades através de ferramentas de colaboração;

Portais Especialistas - Portais que conectam pessoas com base em suas experiências, interesses e informações que precisam;

Portais do Conhecimento - Portais que combinam todas as características dos anteriores para prover conteúdo personalizado com base no que cada usuário faz.

Em linhas gerais, os Portais Corporativos (como ambiente de integração de informações e sistemas) facilitam a busca por informações nas diversas fontes disponíveis, agiliza a tomada de decisão e pode gerar mais produtividade com a redução no tempo dispendido na procura pelas informações.

O termo Portal Corporativo, em relação à internet, começou 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 conteúdo para seus assinantes, na tentativa de ter algum diferencial, já que o acesso discado era “commodity”.

9

Os Portais Corporativos são o resultado de uma fusão de aplicações de software que consolidam, gerenciam, analisam e distribuem a informação dentro e fora da organização. (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 informação de uma companhia e sua base de conhecimento para seus colaboradores e, possivelmente, para clientes, parceiros de negócios e também para o público em geral.

Ilustração 4 Portal Corporativo

Os Portais Corporativos proporcionam uma plataforma de e-business integradora de variadas fontes de informação. Com a evolução do Portal, parte do conhecimento pode ser transferido para o ambiente externo (clientes, fornecedores e parceiros).

9 http://www.portalcolaborativo.com.br/midias-sociais/home/comunidades-em-portais.html 10 http://kmol.online.pt/artigos/2008/11/06/portais-corporativos-e-sua-importancia-estrategica-na-gestao-do-conhecimento-das-organizacoes

TI para concursos

22

Para se classificar um software como Portal Corporativo é necessário ter:

Access/search (poderosos sistemas de busca e indexação); Categorization (categorização do conhecimento); Collaboration (aplicações para colaboração); Personalization (cada usuário é um usuário diferente); Expertise and profiling (perfis de acordo com competências); Application integration (integração com demais aplicações); Security (segurança para todas as aplicações e login único).

Outra característica muito comum em um Portal Corporativo, são os Portlets ou Gadgets, que são utilizados para integração de aplicações ou para personalização. Cada Portlet pode ser um “pedaço” de página e nele é possível aplicar configurações de segurança, personalização, etc. Colaboração é a palavra de ordem em Intranets e Portais Corporativos.

Um Portal Colaborativo é um portal corporativo com forte exploração de recursos colaborativos, ou seja, de recursos que permitem a colaboração entre funcionários de uma ou mais empresas. Um ambiente de colaboração deve permitir que pessoas que não se conheçam e que mesmo vivam em países diferentes possam trabalhar de forma colaborativa usufruindo de recursos do portal colaborativo.

Portlets de Colaboração geralmente estão disponíveis em boas ferramentas de gerenciamento de Intranets e Portais Corporativos. Os mais comuns são: enquetes, forums, chats, workplaces, wikis, dentre outros. Também softwares sociais e comunidades virtuais contribuem para a colaboração corporativa.

Os softwares de portais corporativos devem fornecer soluções colaborativas e permitir a integração de aplicativos corporativos que promovam e construam a colaboração corporativa. Um portal corporativo pode ser considerado um portal colaborativo quando o uso de seus recursos colaborativos supera o uso do conteúdo e páginas de conteúdo. O módulo de gerenciamento de conteúdo ou mesmo o gerenciador de conteúdo pode contribuir na produção de conteúdo colaborativo ou pelo menos suportar a colaboração através do gerenciamento de conteúdo aliado aos portlets (componentes) colaborativos.

A partir da metade de década de 90, com o surgimento dos portais de Internet para navegação/mídia, houve uma rápida evolução com a utilização da Internet no suporte aos negócios. Desta forma, começam a surgir, no final de década de 90, os portais de Internet chamados B2C (business to consumer), que suportam o comércio eletrônico 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 transações eletrônicas entre as empresas; os participantes são parceiros comerciais e possuem uma relação de negócios pré-estabelecida. Já através do portal B2E, os funcionários obtêm informações e serviços de caráter profissional e pessoal que lhes interessam.

11

2.3 GED - Gerenciamento Eletrônico de Documentos 12

GED é definido como a "tecnologia que facilita o armazenamento, localização e recuperação de informações estruturadas ou não, em formato digital, durante todo o seu ciclo de vida". De forma geral, essas soluções são compostas pelos módulos de Document Imaging, COLD/ERM e Document Management.

Document Imaging (DI) – Gerenciamento de Imagens: esse módulo é responsável pela transformação do documento papel em uma imagem digital, permitindo a sua manipulação nesse ambiente. Esse processo abrange três etapas: a digitalização do documento por meio de um scanner, seu armazenamento (gravação em CD-ROM, DVD, Disco Óptico ou Disk Array) e o gerenciamento (consultas, pesquisas etc.) das informações em meio digital.

COLD/Enterprise Report Management - Gerenciamento de Relatórios 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 relatórios são gravados em mídia magnética/óptica e disponibilizados aos usuários, para consulta, no vídeo, por meio de um visualizador próprio.

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 módulos desse tipo é a utilização de serviços de biblioteca que possibilitam o controle das diversas versões de um documento.

Com o crescimento da Internet, surgiu o termo Web Content Management (WCM), que trata do gerenciamento do conteúdo de informações e o que o diferencia do DM, da publicação desse conteúdo na Web.

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

TI para concursos

23

2.4 Workflow

Uma vez organizada a informação na empresa, precisamos conhecer o fluxo do processo do negócio, em outras palavras, o seu Workflow. Este é um conceito antigo que sempre existiu nas organizações. A novidade está na automação do controle do fluxo dos processos e o Workflow funciona como elemento aglutinador das ações 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 condições (os 3Rs do Workflow – Routes /Rotas, Roles/Papéis e Rules/ Regras). Para sua utilização é primordial que o trâmite de documentos, com as etapas e atividades envolvidas, esteja completamente sistematizado.

Podemos conceituar Workflow como o elemento responsável por gerenciar o fluxo dos processos da empresa permitindo um controle automático de tarefas, eventos e prazos, com o intuito de atingir os objetivos do negócio. As diversas soluções de Workflow podem ser grupadas nas seguintes classes:

Produção: processos de missão crítica de relevante valor agregado, com alto grau de estruturação nas regras de roteamento, controle e acompanhamento e com volume significativo de ocorrências repetitivas.

Colaborativo: coordenação das atividades de um grupo de pessoas, trabalhando juntas para a execução de um projeto, porém com regras e fluxos de baixo grau de estruturação.

Administrativo: processos administrativos com baixo valor agregado ao negócio e orientados para o roteamento de formulários e de documentos com baixo grau de estruturação.

Ad-hoc: processos eventuais com regras e fluxos com baixo grau de estruturação.

Enquanto em um sistema tradicional o trâmite do processo necessita de intervenção humana, ou seja, é passivo, em um sistema de Workflow isso é realizado de forma automática. Para tal, os sistemas de Workflow, independente de sua classe, abrangem diversas funções, dentre as quais podemos destacar:

Seqüenciamento: controle da seqüência de execução das diversas atividades do processo;

Controle de Tempo: estabelecimento de limites de tempo para a realização das tarefas;

Roteamento: caminhos alternativos de execução das tarefas (seqüencial, paralelo e condicional);

Atribuição de Papéis: capacidade de rotear uma ação para um papel/perfil de usuário quando uma condição for satisfeita ou um prazo se esgotar;

Monitoramento: facilidade de acompanhar a situação das tarefas e o trâmite das ações tomadas no processo.

Os principais pontos positivos do uso dessas soluções são: o aumento de produtividade, a redução de custo com papel, o aumento da segurança devido à eliminação do trâmite de documentos originais, a redução do espaço de armazenamento, a mobilidade dos arquivos (contingência), a redução do tempo de respostas para acesso às informações e a agilidade no tratamento de exceções (Workflow).

No que diz respeito às dificuldades encontradas, elas são referentes a barreiras culturais, à exigência de mudança comportamental dos usuários que não dispõem mais do papel, à falta de sistematização e padronização dos procedimentos da corporação e ao receio do desemprego, principalmente com a implantação de aplicações de Workflow.

A utilização da tecnologia de Workflow deve ser considerada na implantação de sistemas tipicamente processuais, cujo trâmite do processo possa ser automatizado, onde haja necessidade de controle do tempo de execução das tarefas e com diversas pessoas participando do processo.

O Workflow evoluiu de sistemas que implementavam fluxos de documentos, para funcionar também como integrador. Além disso, existe uma tendência crescente em se utilizar a Web para a entrada de formulários, a distribuição de documentos e o envio de mensagens de alerta por e-mails. Na Internet, onde mecanismos adicionais de segurança são preponderantes, surge a necessidade do uso de criptografia e certificação digital para a execução de determinadas funções do fluxo do processo.

O Gerenciamento Eletrônico de Documentos está convergindo para Gerenciamento de Conteúdo Corporativo (Enterprise Content Management), devendo gerir não apenas os documentos da empresa como também os conteúdos provenientes de sistemas legados, bancos de dados, sistemas de imagem, COLD, DM e qualquer outro arquivo digital, através de uma interface única baseada em browser.

2.5 Exercícios

30. (ICMS-SP 2009) No diagrama de fluxos de negócio (BPMN), para estabelecer "quem faz o que" devem ser representados os fluxos de negócio 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 negócio (BPMN), NÃO se aplica um End Event no tipo de trigger

31

(a) Exception. (b) Link. (c) Message. (d) Multiple. (e) Timer.

xx

32. (ICMS-SP 2009) Na modelagem de processos de negócio (BPMN), os Fluxos de Mensagem devem ser desenhados

32

(a) entre white boxes. (b) entre black boxes.

xx

(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”. Sobre as ondas evolutivas do BPM, assinale a alternativa correta.

33

(a) A primeira onda caracteriza-se pelo gerenciamento científico, na qual a divisão entre patrões 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 reimplementação das características da primeira onda. (d) A quarta onda caracteriza-se pela implementação do programa de melhoria contínua conhecido como 5S. (e) A quinta onda caracteriza-se pela implementação da automação de workflows.

34. (CVM 2010) São métodos para modelagem de processos:34

(a) Arquitetura de Sistemas de Informações Integrados (ARIS). Business Process Execution Language

(BPEL). Métodos Integrados de Definição (IDEF).xx

(b) Projeto de Sistemas de Informações Integrados (PRIS). Business Process Modeling Notation (BPMN).

Métodos Diretivos de Interface (IDM). (c) Arquitetura de Sistemas de Comunicação Integrados (ARCS). Business Decision and Execution

Processes (BDEP). Métodos Integrados de Definição (IDEF). (d) Arquitetura de Sistemas de Informações Integrados (ARIS). Power Level Enterprise Allowances (PLEA).

Métodos Simuladores de Processos Estáticos (MSPE). (e) Automação de Processos Integrados (API). Business Decision and Execution Processes (BDEP).

Métodos Integrados de Auditoria e Controle (MIAC).

35. (ICMS-SP 2009) A tecnologia de armazenamento de relatórios em discos óticos (COLD) envolvida no GED é tratada como sinônimo 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 gestão empresarial, cujos dados são armazenados nas formas transacionais, com ênfase na integração de processos, identificados pela sigla

37

(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 implementação das aplicações de

38

(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.

TI para concursos

25

39. (ICMS-SP 2009) A utilização de ferramentas de groupware e de workflow, cujas informações gerais são apresentadas sob a forma de textos, memorandos, gráficos, e-mails, boletins informativos, páginas Web e arquivos multimídia, caracterizam o tipo de portal de

39

(a) informações empresariais. (b) suporte à decisão. (c) especialista. (d) conhecimento. (e) cooperação.

xx

40. (ICMS-SP 2009) As empresas que implementam portais corporativos por meio dos quais estabelecem relacionamentos de negócios, com um certo nível de acoplamento eletrônico entre os seus sistemas de compras, vendas, logística, distribuição e outros, adotam uma forma de e-Business conhecida por

40

(a) B2C. (b) B2G. (c) B2B.

xx

(d) C2B. (e) C2C.

TI para concursos

26

3 Governança de TI

Governança deriva do termo governo. Segundo o Banco Mundial, é a maneira pela qual o poder é exercido, a administração dos recursos sociais e econômicos de um país visando o desenvolvimento. Representa a capacidade dos governo de planejar, formular e programar políticas e cumprir funções. Governança é o jeito de governar ou uma medida de governabilidade.

A administração moderna de tecnologia de informação busca fundamentos em boas práticas de gerenciamento alinhadas com objetivos do negócio.

Prática é uma maneira de trabalhar. Melhores práticas são atividades ou processos que tenham sido utilizados com sucesso.

O conceito de Governança Tecnológica, do termo em inglês IT Governance, define que a TI é um fator essencial para a gestão financeira e estratégica de uma organização. Governança Tecnológica é a metodologia (e seus processos integrados) de gestão corporativa dos recursos de TI.

13

Ilustração 5 Governança de TI

A governança de TI trata da integração e uso de processos corporativos suportados pelos pacotes de gestão, 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 avaliação de maturidade de desenvolvimento de software e duas metodologias de governança de TI.

CMMI é um modelo de referência que contém práticas (Genéricas ou Específicas) necessárias à maturidade em disciplinas específicas (Systems Engineering (SE), Software Engineering (SW), Integrated Product and Process Development (IPPD), Supplier Sourcing (SS)).

ITIL é um framework, ou uma estrutura de gerência de serviços de TI. Em sua versão 2, o foco era a própria prestação de serviços. Na versão 3, o ITIL mudou seu foco para a o alinhamento dos objetivos de serviços de TI com os do negócio, mudando da abordagem operacional para uma visão mais estratégica do uso da tecnologia.

O COBIT é um guia de boas práticas para a gestão de tecnologia, não apenas serviços.

3.1 Princípios de governança de TI

De acordo com a ISO/IEC 38500, são seis princípios para governança de TI:14

Responsabilidade – papéis e responsabilidades bem definidos na entrega de TI aos clientes e na sua aquisição, e garantia de autoridade compatível para o exercício desses papéis.

Estratégia – O desenvolvimento da estratégia de negócio considera a as capacidades atuais e futuras de TI e o planejamento de TI busca atender às necessidades atuais e continuadas do negócio da organização (alinhamento).

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

TI para concursos

27

Aquisições – As aquisições de TI são adequadamente motivadas por meio de análises apropriadas e continuadas e de decisões claras e transparentes, de modo a garantir o alcance de equilíbrio adequado entre benefícios, oportunidades, custos e riscos, tanto no curto como no longo prazo.

Desempenho – A TI é estruturada para suportar adequadamente a organização e dispor serviços com os níveis e com a qualidade necessários para responder aos requisitos atuais e futuros do negócio.

Conformidade – A TI está em conformidade com a legislação e regulamentos aplicáveis. As políticas e as práticas estão claramente definidas, encontram-se implementadas e são aplicadas.

Comportamento Humano – As políticas, práticas e decisões relativas ao uso e gestão da TI consideram e respeitam o comportamento humano e incluem as necessidades atuais e a evolução das necessidades de todas as pessoas envolvidas no processo.

3.2 Alinhamento estratégico

O alinhamento estratégico entre o negócio e a TI é definido por Duffy (2002) como o processo e o objetivo de conseguir vantagem competitiva desenvolvendo e sustentando um relacionamento simbiótico entre o negócio e a TI.

15

Uma governança deve proporcionar à manutenção de um alinhamento estratégico e eficaz, sob a definição de três modalidades preliminares de governança de TI:

Centralizada: decisão delimitada a pequena quantidade de funções com capacidade para tal. Descentralizada: número maior de configurações, mas descentraliza o poder e dificulta o

alinhamento; é típica da organização divisional e/ou de gerentes de linha. Federativa: suas várias configurações se relacionam com os aspectos da decisão, balanceado

entre a alta gerência e a estrutura divisional e/ou de gerência de linha.

WEILL e ROSS (2006) expandiram estes conceitos e estabeleceram uma combinação de cinco decisões necessárias, que inter-relacionadas com seis possibilidades de quem deve ter a atribuição de decidir, constituem uma matriz de arranjos ajustada à atividade de cada empresa.

São cinco as decisões-chave:

Princípios de TI, que esclarecem o papel de negócio de TI; Arquitetura de TI, que define os requisitos de integração e padronização; Infra-estrutura de TI, que determina os serviços compartilhados e de suporte; Necessidade de aplicações de negócio, que especifica a necessidade comercial de aplicações de

TI, comprada ou desenvolvida internamente; Investimentos e priorização de TI, que priorizam quais iniciativas financiar e quanto gastar.

Os direitos decisórios são listados em seis arquétipos, ou tipo de pessoa envolvida em tomar uma decisão de TI:

Monarquia de negócio, representada pelos altos gerentes; Monarquia de TI, representada pelos especialistas em TI; Feudalismo, onde cada unidade de negócio toma decisões independentes; Federalismo, caracterizando uma combinação entre o centro corporativo e as unidades de

negócio, com ou sem o envolvimento do pessoal de TI; Duopólio de TI, com o envolvimento do grupo de TI e de algum outro grupo Tal como a alta

gerência ou os líderes das unidades de negócio; Anarquia, onde as tomadas de decisão são 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 através da definição e normatização 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 satisfaça às expectativas do cliente, dentro daquilo que foi acordado inicialmente.

A qualidade é o grau em que um conjunto de características inerentes a um produto, processo ou sistema cumpre os requisitos inicialmente estipulados.

16

A engenharia de software objetiva garantir a qualidade através da definição e normatização de processos de desenvolvimento, com um produto final que satisfaça às expectativas do cliente.

Os atributos qualitativos previstos na norma ISO 9126 são:

funcionalidade confiabilidade usabilidade

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

TI para concursos

28

eficiência manutenibilidade portabilidade.

Mensurar o bom funcionamento de um software envolve compará-lo com elementos como especificações, outros softwares da mesma linha, versões anteriores do mesmo produto, inferências pessoais, expectativas do cliente, normas relevantes, leis aplicáveis, entre outros.

A verificação compara o software com a especificação, enquanto que a validação 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. Organizações de software evoluem o seu ciclo de desenvolvimento de software através de sua avaliação contínua, identificação e ações corretivas dentro de uma estratégia de melhoria dos processos. Este caminho de melhoria é definido por cinco níveis de maturidade:

inicial, ad hoc, sem ambiente estável de desenvolvimento ou processos estruturados, que excedem prazos e orçamentos.

repetitivo, um minimo de disciplina nos processos para repetir sucessos anteriores, podendo utilizar ferramentas de gerência de projetos para administrar custos e prazos, e status do projeto visíveis (marcos e término).

definido, um conjunto de processos padrão estabelecidos e melhorados periodicamente

gerenciado, com utilização de indicadores de qualidade

otimizado, com a procura constante de inovação e a realização de um processo controlado e mensurado para melhoria contínua

O CMMI possui duas representações: "contínua" ou "por estágios". Estas representações permitem a organização utilizar diferentes caminhos para a melhoria de acordo com seu interesse.

Representação Continua, que possibilita à organização utilizar a ordem de melhoria que melhor atende os objetivos de negócio da empresa. É caracterizado por Níveis de Capacidade (Capability Levels) das áreas de processo:

Nível 0: Incompleto (Ad-hoc) Nível 1: Executado (Definido) Nível 2: Gerenciado Nível 3: Definido Nível 4: Quantitativamente gerenciado Nível 5: Em otimização

Representação Por Estágios, que oferece uma seqüência pré-determinada para melhoria baseada em estágios que não deve ser desconsiderada, pois cada estágio serve de base para o próximo. É caracterizado por Níveis de Maturidade (Maturity Levels) da organização:

Nível 1: Inicial (Ad-hoc) Nível 2: Gerenciado Nível 3: Definido Nível 4: Quantitativamente gerenciado Nível 5: Em otimização

3.3.1.1 Áreas de Processo

O modelo CMMI v1.2 (CMMI-DEV) contém 22 áreas de processo. Em sua representação por estágios, as áreas são divididas da seguinte forma:

Nível 1: Inicial (Ad-hoc)

Não possui áreas de processo.

Nível 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) Medição e Análise - MA (Measurement and Analysis)

TI para concursos

29

Garantia da Qualidade de Processo e Produto - PPQA (Process and Product Quality Assurance) Gerência de Configuração - CM (Configuration Management)

Nível 3: Definido

Desenvolvimento de Requisitos - RD (Requirements Development) Solução Técnica - TS (Technical Solution) Integração de Produto - PI (Product Integration) Verificação - VER (Verification) Validação - VAL (Validation) Foco de Processo Organizacional - OPF (Organizational Process Focus) Definição 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) Análise de Decisão e Resolução - DAR (Decision Analysis and Resolution

Nível 4: Quantitativamente gerenciado / Gerido quantitativamente

Desempenho de Processo Organizacional - OPP (Organizational Process Performance) Gerenciamento Quantitativo de Projeto - QPM (Quantitative Project Management)

Nível 5: Em otimização

Gestão de Processo Organizacional - OPM (Organizational Process Management) Análise Causal e Resolução - 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 nível a mais, em relação ao CMMI.

0 - Inexistente Completa falta de um processo reconhecido. A empresa nem mesmo reconheceu que existe uma questão a ser trabalhada.

1 - Inicial / Ad hoc Existem evidências que a empresa reconheceu que existem questões e que precisam ser trabalhadas. No entanto, não existe processo padronizado; ao contrário, existem enfoques Ad Hoc que tendem a ser aplicados individualmente ou caso-a-caso. O enfoque geral de gerenciamento é desorganizado.

2 - Repetível, porém Intuitivo Os processos evoluíram para um estágio onde procedimentos similares são seguidos por diferentes pessoas fazendo a mesma tarefa. Não existe um treinamento formal ou uma comunicação dos procedimentos padronizados e a responsabilidade é deixado com o indivíduo. Há um alto grau de confiança no conhecimento dos indivíduos e conseqüentemente erros podem ocorrer.

3 - Processo Definido Procedimentos foram padronizados, documentados e comunicados através de treinamento. É mandatório que esses processos sejam seguidos; no entanto, possivelmente desvios não serão detectados. Os procedimentos não são sofisticados mas existe a formalização das práticas existentes.

4 - Gerenciado e Mensurável A gerencia monitora e mede a aderência aos procedimentos e adota ações onde os processos parecem não estar funcionando muito bem. Os processos estão debaixo de um constante aprimoramento e fornecem boas práticas. Automação e ferramentas são utilizadas de uma maneira limitada ou fragmentada.

5 - Otimizado Os processos foram refinados a um nível de boas práticas, baseado no resultado de um contínuo aprimoramento e modelagem da maturidade como outras organizações. TI é utilizada como um caminho integrado para automatizar o fluxo de trabalho, provendo ferramentas para aprimorar a qualidade e efetividade, tornando a organização rápida 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 vários níveis de gerência a adequada visibilidade dos projetos, dos processos de desenvolvimento e dos produtos gerados. A GQS atua como “guardiã”, fornecendo um retrato do uso do Processo e não é responsável por executar testes de software ou inspeção em artefatos.

17

Obtendo a visibilidade desejada, a gerência 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

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

TI para concursos

30

alta qualidade, ter alta produtividade da equipe de desenvolvimento, cumprir o cronograma estabelecido junto ao cliente e não necessitar de recursos adicionais não previstos.

Para conseguir esses objetivos a área-chave de processo GQS estimula a atuação das equipes responsáveis pelo desenvolvimento de software em diversas frentes objetivando internalizar comportamentos e ações, podendo-se destacar:

o planejamento do projeto e o acompanhamento de resultados; o uso dos métodos e ferramentas padronizadas na organização; a adoção de Revisões Técnicas Formais; o estabelecimento e a monitoração de estratégias de testes; a revisão dos artefatos produzidos pelo processo de desenvolvimento; a busca de conformidade com os padrões de desenvolvimento de software; a implantação de medições associadas a projeto, processo e produto; a utilização de mecanismos adequados de armazenamento e recuperação de dados relativos a

projetos, processos e produtos; a busca de uma melhoria contínua 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 médias empresas de desenvolvimento de software no Brasil, ele é baseado nas normas ISO/IEC 12207 e ISO/IEC 15504 e compatível com o CMMI.

O projeto tem apoio do Ministério da Ciência 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 certificação em relação as normas estrangeiras, sendo ideal para micro, pequenas e médias empresas que são a grande maioria no Brasil.

Um dos objetivos do projeto é replicar o modelo na América Latina, incluindo o Chile, Argentina, Costa Rica, Peru e Uruguai.

18

O MPS.Br é dividido em 3 partes:

MR-MPS – modelo de referência. Apresenta 7 níveis de maturidade (o que é um diferencial em relação aos outros padrões de processo) que são: A - Em Otimização; B - Gerenciado quantitativamente; C - Definido; D - Largamente Definido; E - Parcialmente Definido; F - Gerenciado; G - Parcialmente Gerenciado.

MA-MPS – modelo de avaliação em conformidade com a norma ISO/IEC 15504 Planejar e preparar avaliação Conduzir Avaliação Relatar resultados Registrar e publicar resultados

MN-MPS – modelo de negócio

3.3.3 Exercícios

41. Segundo o modelo CMM, migrar do nível 3 de maturidade para o nível 4 representa uma melhoria da qualidade de processos

41

(a) otimizados para processos gerenciados. (b) definidos para processos repetíveis. (c) definidos para processos gerenciados.

xx

(d) gerenciados para processos otimizados. (e) repetíveis para processos definidos.

42. O metamodelo CMMI contínuo define que cada área de processo é avaliada formalmente, com base em metas e práticas específicas, e classificada de acordo com seis níveis de capacitação. O nível 3 é o

42

(a) Quantitativamente gerido. (b) Realizado. (c) Definido.

xx

(d) Gerido. (e) Otimizado.

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

TI para concursos

31

43. (SUSEP 2010) São áreas de Processo da Categoria Engenharia no CMMI:43

(a) Atualização de Requisitos, Otimização de Requisitos, Solução Técnica, Integração do Produto,

Verificação e Auditoria. (b) Desenvolvimento de Requisitos, Gestão de Requisitos, Métodos e Técnicas, Integração do Produto,

Análise de Decisões e Resolução. (c) Atualização de Requisitos, Gestão de Requisitos, Decisão Técnica, Integração do Produto, Segurança e

Auditoria. (d) Desenvolvimento de Requisitos, Gestão de Requisitos, Solução Técnica, Integração do Produto,

Verificação e Validação.xx

(e) Desenvolvimento de Requisitos, Composição de Requisitos, Métodos e Técnicas, Integração do Produto,

Verificação e Manutenção.

44. (SUSEP 2010) As abordagens para implementação do CMMI são:44

(a) Abordagem por Sistemas e Abordagem Sequencial. (b) Abordagem por Estágios e Abordagem Contínua.

xx

(c) Abordagem por Gestores e Abordagem em Degraus. (d) Abordagem por Estrutura e Abordagem por Processos. (e) Abordagem por Simulação e Abordagem por Pontos de Função.

45. (SUSEP 2010) As abordagens do CMMI envolvem a45

(a) avaliação da maturidade da informatização da organização ou a capacitação das suas áreas de projeto, o

estabelecimento de requisitos e a aquisição de recursos computacionais. (b) implementação da maturidade da organização ou a capacitação das suas áreas de racionalização, o

estabelecimento de requisitos e a modificação da estrutura. (c) avaliação da maturidade das interfaces da organização e a vinculação das suas áreas de processo ao

estabelecimento de prioridades para a capacitação de pessoal. (d) avaliação da mentalidade estratégica da organização para capacitação das suas áreas de risco,

estabelecimento de ações emergenciais e implementação de ações de melhoria. (e) avaliação da maturidade da organização ou a capacitação das suas áreas de processo, o

estabelecimento de prioridades e a implementação de ações de melhoria.xx

46. (SUSEP 2010) Assinale a opção correta.46

(a) A estratégia de outsourcing decide como gerenciar o desempenho dos equipamentos. (b) O objetivo principal da Governança de TI é gerenciar outsourcing. (c) A estratégia de outsourcing decide como gerenciar os negócios internos dos fornecedores ou prestadores

de serviços. (d) O objetivo principal da Governança de TI é escolher a melhor alternativa de programação. (e) O objetivo principal da Governança de TI é alinhar TI aos requisitos do negócio.

xx

47. (ICMS PR – 2012) Sobre o modelo CMMI, atribua V (verdadeiro) ou F (falso) às afirmativas a seguir. ( ) O principal propósito do CMMI é fornecer diretrizes baseadas em melhores práticas para a melhoria dos processos e habilidades organizacionais, cobrindo o ciclo de vida de produtos e serviços completos, nas fases de concepção, desenvolvimento, aquisição, entrega e manutenção. ( ) O CMMI para Serviços (CMMI-SVC) provê diretrizes para monitorar, mensurar e gerenciar processos de desenvolvimento, podendo ser estendida através da adição para o Desenvolvimento Integrado de Produto e Processo (IPPD). ( ) Uma constelação é uma coleção de componentes gerada a partir do framework CMMI, que engloba um modelo fundamental, seus materiais de treinamento e a documentação relacionada a avaliações, abrangendo uma área de interesse específica. ( ) Dentre os componentes da estrutura do CMMI, as Metas Específicas 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 constelações desse modelo, o CMMI para Aquisições (CMMI-ACQ) provê diretrizes para entrega de serviços dentro das organizações e para clientes externos. Assinale a alternativa que contém, de cima para baixo, a sequência correta.

47

(a) V, V, F, F, V. (b) V, F, V, V, F.

xx

(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 Referência MR-MPS define níveis de maturidade que são uma combinação entre processos e sua capacidade. Sobre esses níveis, considere as afirmativas a seguir. I. O nível B corresponde a Gerenciado Quantitativamente. II. O nível A corresponde a Definido. III. O nível C corresponde a Em Otimização. IV. O nível G corresponde a Parcialmente Gerenciado. Assinale a alternativa correta.

48

(a) Somente as afirmativas I e II são corretas. (b) Somente as afirmativas I e IV são corretas.

xx

(c) Somente as afirmativas III e IV são corretas. (d) Somente as afirmativas I, II e III são corretas. (e) Somente as afirmativas II, III e IV são corretas.

TI para concursos

32

49. (ICMS PR – 2012) Sobre a Implantação da Função de Qualidade (IFQ), atribua V (verdadeiro) ou F (falso) às afirmativas a seguir. ( ) Concentra-se em maximizar a satisfação do cliente a partir do processo de Engenharia de Software. ( ) Os Requisitos Normais estão implícitos no produto ou sistema e podem ser tão fundamentais que o cliente não se refere a eles explicitamente. ( ) É uma técnica que traduz as necessidades do cliente para requisitos técnicos 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 características que vão além das expectativas do cliente e mostram ser muito satisfatórias quando presentes. Assinale a alternativa que contém, de cima para baixo, a sequência correta.

49

(a) V, V, F, F, V. (b) V, F, V, V, F.

xx

(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 opção correta que apresenta Categoria e algumas de suas Áreas de Processo.

50

(a) Suporte: Gestão de Componentes, Medição e Revisão, Análise e Resolução de Consequências. (b) Gestão de Processo: Foco no Planejamento, Definição do Processo Organizacional, Desempenho do

Processo Organizacional. (c) Suporte: Gestão da Configuração, Garantia da Operacionalidade do Processo e do Produto, Análise de

Planejamento e Decisões. (d) Gestão de Processo: Foco no Processo Organizacional, Definição do Processo Operacional, Inovação e

Disseminação Estrutural. (e) Gestão de Processo: Foco no Processo Organizacional, Definição do Processo Organizacional, Inovação

e Disseminação Organizacional.xx

3.4 Gerenciamento de serviços

Gerenciamento de serviços é um conjunto de habilidades organizacionais especializadas para prover valor aos clientes na forma serviço.

Estas habilidades assumem a forma de funções e processos de gerenciamento dos serviços ao longo de um ciclo de vida.

Prestação de serviços oferece produtos de natureza intangível e processos, difíceis de medir, controlar ou validar.

Uma organização, do ponto de vista de gerenciamento, pode ser vista como um conjunto de funções, definidas, neste contexto, como unidades especializadas em executar determinados tipos de trabalho e responsáveis por resultados específicos. São auto-suficientes, com habilidades e recursos necessários para o seu desempenho.

A coordenação entre funções é tipicamente realizada através de processos.

Processo é um conjunto estruturado de atividades com uma finalidade, que proporciona a transformação em direção de uma meta. Ele recebe entradas (input) definidas e as transforma em resultados (saídas) definidos (output).

Um processo apresenta quatro características:

Mensurável

Entrega resultados específicos, identificáveis e calculáveis

Entrega para um cliente ou parte interessada

Responde a eventos específicos

Há diversas metodologias, técnicas ou frameworks de gerenciamento de serviços utilizadas nas organizações. 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 atenção em ITIL e COBIT, por sua incidência em concursos públicos.

3.5 Conceitos e definições

Função

Unidade especializada em executar determinados tipos de trabalho e responsável por resultados específicos.

São auto-suficientes, com habilidades e recursos necessários para o seu desempenho. A coordenação entre funções é tipicamente realizada através de processos

TI para concursos

33

Processo

Conjunto estruturado de atividades com uma finalidade Proporciona a transformação em direção de uma meta Recebe entradas (input) definidas e as transforma em resultados (saídas) definidos (output). Um processo apresenta quatro características: Mensurável Entrega resultados específicos, identificáveis e calculáveis Entrega para um cliente ou parte interessada Responde a eventos específicos

Evento

Qualquer fato identificável Tipicamente, alerta ou notificação criada por uma ferramenta de monitoração

Alerta

Aviso de que Um limite foi atingido Algo foi modificado Ocorreu uma falha

Incidente

Interrupção não planejada Redução de qualidade Falha de um item de configuração

Problema

Causa desconhecida de um ou mais incidentes

Solução de contorno

Solução temporária para superar uma dificuldade Reduz impacto de um incidente ou problema Não fecha o registro de problema

3.6 Fundamentos da ITIL V2

Versão anterior do framework, preocupava-se especificamente com a prestação de serviços.

Estrutura abstrata (framework) de serviços de TI. Orienta o “como fazer” das funções do gerente de tecnologia, dividindo estes serviços em dois grandes grupos – suporte a serviços e entrega de serviços – unidos por uma central de atendimento (service desk).

3.6.1 Suporte a serviços

O suporte a serviços tem foco nos usuários da instituição, administrando incidentes, suas origens (problema) e definindo formas de tratamento e de alterações necessárias para resolução.

TI para concursos

34

3.6.1.1 Central de serviços (service desk)

Suporte de primeiro nível. Atendimento ao usuário.

3.6.1.2 Gerenciamento de incidentes (apaga incêndio)

Restaurar o serviço o mais rápido possível, para minimizar o impacto nos negócios e para garantir o melhor nível de serviço, no tocante qualidade e disponibilidade.

Um incidente é um evento que não faz parte da operação padrão do serviço e que causa, ou poderá causar uma interrupção, ou uma redução na qualidade do serviço.

3.6.1.3 Gerenciamento de problemas (desenvolvimento de soluções)

Buscar a causa raiz do incidente e sua conseqüente solução e prevenção.

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 Solução de Contorno (work-around) ou permanente for identificada e aplicada.

As soluções são registradas na gerência de configuração e as mudanças necessárias são requisitadas à gerência de mudanças.

3.6.1.4 Gerenciamento de mudanças (implementação)

A partir de requisições de mudanças dos usuários ou do gerenciamento de problemas, implementa mudanças aprovadas, de maneira eficiente, em um custo efetivo, com um mínimo risco à infra-estrutura de TI existente e à nova.

3.6.1.5 Gerenciamento de liberação (implantação)

Libera e distribui a alteração autorizada. Implanta.

3.6.1.6 Gerenciamento de configuração (controle da infra-estrutura)

Gerenciar o banco de dados de todos os componentes necessários para fornecer serviços

3.6.2 Entrega de Serviço

A entrega de serviços volta-se para o cliente, preocupando-se em garantir uma qualidade ótima em função da estratégia do negócio, além da efetividade do serviço prestado como resultado de uma gestão de recursos tecnológicos (ativos) e financeiros.

3.6.2.1 Gerenciamento de nivel de serviço

A partir de um acordo do nível de serviço entre a TI e os usuários, contendo os requisitos do usuário, gerencia a qualidade dos serviços oferecidos, procurando a maior qualidade em consonância com o negócio da empresa.

3.6.2.2 Gerenciamento financeiro

Como justificar o orçamento? Necessidades da TI para o negócio planejados a partir dos processos (Mudança, Nível, Capacidade e Disponibilidade) compõe o orçamento e acompanhamento financeiro.

3.6.2.3 Gerenciamento de disponibilidade

Análise de riscos, oportunidades, satisfação, produtividade e tempo de manutenção e indisponibilidade.

3.6.2.4 Gerenciamento de capacidade

Confronto entre capacidade, demanda e satisfação do cliente. Taxa de utilização de recursos humanos e sistemas.

3.6.2.5 Gerenciamento de continuidade de serviços de TI

Todo o esforço possível para evitar interrupções. Implementação de medidas preventivas, testes para operar em ambientes de crise, redução do impacto dos incidentes, seguros.

TI para concursos

35

3.7 Fundamentos de ITIL V3 19

O ITIL em sua versão 3, muda a abordagem de gerenciamento de serviços de TI, em busca de alinhamento com os objetivos do negócio e reforço na capacidade de inovação, mais em concordância com os conceitos de governança em TI. Construir uma ponte entre os objetivos de negógio e de tecnologia está no cerne das estruturas de melhores práticas de Gerenciamento de Serviços de TI (GSTI/ITSM).

O ITIL oferece qualificação em dois caminhos, um baseado no ciclo de vida de serviços, em cinco volumes, e outro em quatro módulos de habilidades.

Pelo caminho de habilidades, o ITIL oferece quatro grupos:

Oferta de serviços e contratos Estratégia de serviço Processos de desenho Portfólio, nível de serviço, Catálogo de serviço, Demanda, Fornecedores e Gerenciamento financeiro

Liberação, controle e validação Transição de serviços Processos de operação Mudança, Liberação e implantação, Teste e validação de serviço, Gerenciamento da configuração e

ativos de serviço, Conhecimento, Gerenciamento de requisoções e Avaliação do serviço

Suporte e análise operacional Operação de serviço Processos de Melhoria de serviço continuada Eventos, Incidentes, Requisições, Problemas, Acesso, Central de serviços, Gerenciamento Técnico,

Operações de TI e Gerenciamento de aplicativos

Planejamento, proteção e otimização Desenho de serviço Processos de Capacidade, Disponibilidade, Continuidade, Segurança, Demanda e Gerenciamento de

riscos

Pelo caminho ciclo de vida dos serviços, os processos são distribuídos em cinco grupos:

Estratégia do serviço (Service Strategy) Projeto de serviço ou Desenho de serviço (Service Design) Transição do serviço (Service Transition) Operação do serviço (Service Operation) Melhoria contínua do serviço (Continual Service Improvement)

Ilustração 6 Ciclo de vida do serviço - Núcleo do ITIL V3

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

TI para concursos

36

3.7.1 Estratégia do serviço (Service Strategy)

Como ponto de origem do ciclo de vida de serviço ITIL, estratégia do serviço orienta sobre como tornar mais claro e priorizar investimentos sobre provimento de serviços, desenhar, desenvolver e implementar o gerenciamento de serviços.

Processos:

geração de estratégia, gerenciamento de portfólio de serviços, gerenciamento de demandas, gerenciamento financeiro de TI.

3.7.2 Desenho de serviço (Service Design)

O desenho de serviço fornece orientações para o desenvolvimento de serviços e processos de gerenciamento de serviços, incluindo mudanças e melhorias para aumentar ou manter o valor, para a continuidade dos serviços, para o atingimento de níveis de serviço e para a conformidade às normas.

O trabalho de projetar um serviço de TI é agregado em pacote de projeto de serviços (Service Design Package - SDP).

Processos de gerenciamento de:

nível de serviço (Service Level Management - SLM) disponibilidade capacidade continuidade de serviços segurança da informação fornecedores catálogo de serviços.

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

Este volume é direcionado à entrega dos serviços necessários ao negócio no uso operacional, e geralmente englobam o "projeto".

Processos:

Planejamento de transição e suporte Avaliação Teste e validação Gerenciamento de configurações e ativos de serviço Gerenciamento de liberação e implantação (release and deployment) Gerenciamento de mudança (Change Management) Gerenciamento de conhecimento

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

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

Processos:

Cumprimento de requisição. Gerenciamento de eventos. Gerenciamento de incidentes. Gerenciamento de problemas. Gerenciamento de acesso, (service desk).

Funções:

Central de serviços Gerenciamento técnico Gerenciamento de aplicativos Gerenciamento de operações de TI

3.7.5 Melhoria de serviço continuada (Continual Service Improvement)

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

Utiliza um sistema cíclico de revisão baseado no modelo PDCA (Plan Do, Check and Act).

Processos:

Medição de serviço Relato de serviço

TI para concursos

37

Sete passos de melhoria

3.8 ITIL V2 x V3

O ITIL apresenta os mesmo processos da versão 2 e acrescenta 16 novos.

ITIL V3

Estratégia do serviço Desenho de serviço Transição do

serviço Operação do

serviço Melhoria contínua

do serviço

ITIL V3

Gerenciamento de

portfólio

Segurança da

informação

Planejamento de

transição e suporte

Cumprimento de

requisição Medição de serviço

Geração de

estratégia Fornecedores Avaliação

Gerenciamento de

eventos Relato de serviço

Gerenciamento de demandas

Catálogo de serviços.

Teste e validação Gerenciamento de

acesso Sete passos de

melhoria

Gerenciamento de

conhecimento

ITIL

V2

Entr

eg

a

Gerenciamento financeiro

Nível de serviço (SLM)

Disponibilidade

Capacidade

Continuidade de serviços

Sup

ort

e

Gerenciamento de liberação e implantação

Gerenciamento de incidentes

Gerenciamento de

configurações e ativos de serviço

Gerenciamento de problemas

Gerenciamento de mudança

Service desk

TI para concursos

38

3.9 Fundamentos de COBIT

O COBIT – Control Objectives for Information and Related Technology, tem por missão explícita pesquisar, desenvolver, publicar e promover um conjunto atualizado de padrões internacionais de boas práticas 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 através do IT Governance Institute, organização independente que desenvolveu a metodologia considerada a base da governança tecnológica. O COBIT funciona como uma entidade de padronização e estabelece métodos documentados para nortear a área de tecnologia das empresas, incluindo qualidade de software, níveis de maturidade e segurança da informação.

Os documentos do COBIT definem Governança Tecnológica como sendo uma estrutura de relacionamentos entre processos para direcionar e controlar uma empresa de modo a atingir objetivos corporativos, através da agregação de valor e risco controlado pelo uso da tecnologia da informação e de seus processos”.

Ilustração 7 Cobit

TI para concursos

39

COBIT é um guia de boas práticas, que podem servir como um modelo de referência para gestão da TI. Inclui um sumário executivo, um "framework", controle de objetivos, mapas de auditoria, ferramentas para a sua implementação e um guia com técnicas de gerenciamento.

Para definição e monitoramento dos controles e nível 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 métricas dos processos de TI para definir e avaliar os seus resultados e performance baseados nos princípios 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 governança de TI como tópicos que os executivos precisam atentar para direcionar a área de TI:

Alinhamento estratégico: foca em garantir a ligação entre os planos de negócios e de TI, definindo, mantendo e validando a proposta de valor de TI, alinhando as operações de TI com as operações da organização.

Entrega de valor: é a execução da proposta de valor de IT através do ciclo de entrega, garantindo que TI entrega os prometidos benefícios previstos na estratégia da organização, concentrado-se em otimizar custos e provendo o valor intrínseco de TI.

Gestão de recursos: refere-se à melhor utilização possível dos investimentos e o apropriado gerenciamento dos recursos críticos de TI: aplicativos, informações, infraestrutura e pessoas. Questões relevantes referem-se à otimização do conhecimento e infraestrutura.

Gestão de risco: requer a preocupação com riscos pelos funcionários mais experientes da corporação, um entendimento claro do apetite de risco da empresa e dos requerimentos de conformidade, transparência sobre os riscos significantes para a organização e inserção do gerenciamento de riscos nas atividades da companhia.

Mensuração de desempenho: acompanha e monitora a implementação da estratégia, término do projeto, uso dos recursos, processo de performance e entrega dos serviços, usando, por exemplo, “balanced scorecards” que traduzem as estratégia em ações para atingir os objetivos, medidos através de processos contábeis convencionais.

Os domínios do COBIT são integrados da seguinte forma:

A informação de uma empresa é gerada/modificada pelas atividades de TI. Esta informação é requisito para o domínio de Planejamento e Organização (PO). Os requisitos de saída do PO são requisitos de entrada de informação para o domínio de

Aquisição e Implementação (AI), As saídas de AI definem os requisitos de entrada para o domínio de Entrega e Suporte (DS). O domínio de Monitoração (M) utiliza as informações do DS nos seus processos e atividades

relacionadas.

Os requisitos da informação são dados por: efetividade, eficiência, confidencialidade, integridade, disponibilidade, conformidade e confiabilidade.

Os recursos de TI são classificados como: pessoas, sistemas aplicativos, tecnologia, infraestrutura e dados.

COBIT cobre os quatro domínios, os quais possuem 34 processos (dois objetivos de controle para cada processo).

3.9.1 Planejar e Organizar

Uso de informação 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 Estratégico de TI e Orientações PO2 Definir a Arquitetura de Informação PO3 Determinar as Diretrizes de Tecnologia PO4 Definir os Processos de TI, Organização 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

TI para concursos

40

3.9.2 Adquirir e Implementar

Requisitos de TI, aquisição de tecnologia e implementação dentro dos processos de negócios da companhia.

Desenvolvimento do plano de manutenção que a companhia adota para prolongar a vida do sistema de TI e seus componentes.

AI1 Identificar Soluções Automatizadas AI2 Adquirir e Manter Software de Aplicação AI3 Adquirir e Manter Infraestrutura de Tecnologia AI4 Habilitar Operação e Uso AI5 Obter Recursos de TI AI6 Gerenciar Mudanças AI7 Instalar e Homologar Soluções e Mudanças

3.9.3 Entregar e Dar Suporte

Entrega de tecnologia da informação. Cobre a execução de aplicações dentro do sistema de TI e seus resultados, assim como o suporte dos processos, que incluem questões de segurança e treinamento e habilitam a execução.

DS1 Definir e Gerenciar Níveis de Serviço DS2 Gerenciar Serviços de Terceiros DS3 Gerenciar o Desempenhoe Capacidade DS4 Assegurar Serviço Contínuo DS5 Assegurar Segurança de Sistema DS6 Identificar e Alocar Recursos DS7 Treinar Usuários DS8 Gerenciar a Central de Serviço e os Incidentes DS9 Gerenciar a Configuração DS10 Gerenciar Problemas DS11 Gerenciar Dados DS12 Gerenciar o Ambiente Físico DS13 Gerenciar Operações

3.9.4 Monitorar e Avaliar

Estimativa estratégica 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 regulatórios. Estimativa e capacidade de atingir os objetivos de negócio, controlando os processos internos da companhia através de auditores internos e externos.

M1 Monitorar os processos M2 Assegurar avaliação dos controles internos M3 Obter avaliação independente M4 Prover auditoria independente

TI para concursos

41

3.10 Comparação ITIL V3 x COBIT

Ilustração 8 Comparação COBIT x ITIL V3

3.11 Exercícios

51. (ICMS-SP 2009) NÃO se trata de elemento que deve ser considerado como parte do controle de mudanças no gerenciamento de configuração:

51

(a) revisões e auditoria das mudanças.xx

(b) confiabilidade das instalações das modificações. (c) análise de impacto de mudanças. (d) conjunto de modificações. (e) pedido de modificações.

TI para concursos

42

52. (ICMS-SP 2009) A rastreabilidade ou a história das mudanças de cada software, incluindo quem fez o que, por que e quando, pode ser realizada no gerenciamento de configuração de software por meio do seu componente:

52

(a) Acordo de nível de serviço. (b) Configuração da construção. (c) Identificação do item de software. (d) Controle de versão.

xx

(e) Controle de mudanças.

53. (ICMS-SP 2009) Os objetivos de controle detalhados do COBIT estão diretamente associados53

(a) aos domínios de governança. (b) aos processos de TI. (c) às atividades de TI.

xx

(d) aos recursos de TI. (e) aos critérios de informação.

54. (ICMS-SP 2009) O processo Gerenciamento de Configurações está definido no COBIT dentro do domínio 54

(a) Monitoração & Avaliação. (b) Verificação & Controle. (c) Aquisição & Implementação. (d) Planejamento & Organização. (e) Entrega & Suporte.

xx

55. (ICMS-SP 2009) NÃO se trata de um princípio de governança de TI: 55

(a) Responsabilidade corporativa. (b) Objetivos do negócio.

xx

(c) Prestação de contas. (d) Transparência. (e) Equidade.

56. Gerenciar Projetos, segundo o COBIT, é um processo de TI pertencente ao domínio de 56

(a) Planejamento e Organização.

xx

(b) Planejamento e Controle. (c) Aquisição e Implementação. (d) Entrega e Suporte. (e) Monitoração e Controle.

57. (ICMS-SP 2009) No gerenciamento de serviços 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 serviços de TI, segundo o ITIL v.2, tem foco tático ou estratégico o processo:

58

(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 serviços Service Desk, segundo o ITIL v.2, NÃO gerencia59

(a) os contatos entre o provedor de serviços e os usuários. (b) a comunicação com os usuários. (c) os incidentes nos serviços. (d) os acordos de serviços.

xx

(e) as requisições de serviços.

60. O processo de Gerenciamento de Problemas, segundo o ITIL, deve ser executado no estágio do ciclo de vida de serviços denominado

60

(a) estratégia de serviços. (b) projeto de serviços. (c) transição de serviços. (d) operação de serviços.

xx

(e) melhoria contínua de serviços.

TI para concursos

43

61. (SUSEP 2010) São publicações do núcleo do ITIL:61

(a) Estratégia de Serviço, Tática de Serviço, Plano de Serviço, Operação de Serviço e Aplicação de Serviço. (b) Proposta de Serviço, Aceitação de Serviço, Transição de Serviço, Aplicação de Serviço e Melhoria de

Serviço Continuada. (c) Domínio de Serviço, Desenho de Serviço, Transição de Serviço, Abordagem de Serviço e Melhoria de

Serviço Continuada. (d) Estratégia de Serviço, Desenho de Serviço, Transição de Serviço, Operação de Serviço e Melhoria de

Serviço Continuada.xx

(e) Estratégia de Serviço, Desenho de Serviço, Transposição de Serviço, Operação de Serviço e Melhoria de

Serviço Externo.

62. (CVM 2010) Assinale a opção correta mostrando publicação e processos da ITIL. 62

(a) Estratégia de serviço: gerenciamento temporal de TI, gerenciamento de portfólio de fornecedores e

gerenciamento de demanda de serviços. (b) Mudança de serviço continuada: relatório de produtos e medição de desempenho. (c) Melhoria de serviço aprovada: relatório de ações e mediação de serviço. (d) Melhoria de serviço continuada: relatório de serviço e medição de serviço.

xx

(e) Tática de serviço: gerenciamento tático de TI, ampliação de portfólio de serviços e gerenciamento de demanda reprimida.

63. (ICMS-PR 2012) A Governança de TI pode ser considerada como uma ramificação da Governança Corporativa. Sobre a Gestão e a Governança de TI, assinale a alternativa correta.

63

(a) É papel da Administração determinar quem tem o direito de decidir sobre quanto uma empresa investirá em TI, enquanto a Governança determina a quantia a ser efetivamente investida num dado ano e as áreas que receberão 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 decisórios a indivíduos ou grupos de indivíduos específicos.

(d) Segundo o Center for Information Systems Research (CISR) do MIT, Ativos Humanos são representados por relacionamentos dentro da empresa, bem como relacionamentos, marca e reputação junto a clientes e fornecedores.

(e) Uma Matriz de Arranjos lista cinco decisões de TI inter-relacionadas: Princípios de TI, Arquitetura de TI, Infraestrutura de TI, Necessidade de aplicações de negócio, Investimentos e Priorização de TI.

xx

64. (ICMS-PR 2012) A Governança de TI é, em geral, motivada por vários fatores, sendo um dos mais importantes o Ambiente de Negócios, que, no Brasil, vem sendo caracterizado por

64

(a) barganha decrescente entre fornecedores e clientes. (b) ciclo de vida cada vez mais longo para os produtos e serviços. (c) menor dinamismo dos requerimentos dos negócios para TI. (d) novas ameaças devidas à maior internacionalização da economia.

xx

(e) uniformidade dos acionistas envolvidos no processo.

65. (ICMS-PR 2012) Sobre as caracterizações das Integrações Tecnológicas no Brasil, atribua V (verdadeiro) ou F (falso) às afirmativas a seguir. ( ) Integração da Gestão Estratégica com os processos de manufatura, através de aplicações de Product Life Cycle Management e de Product Data Management. ( ) Integração das cadeias de suprimentos, através de aplicações de supply-chain e da infraestrutura de comunicação e Internet. ( ) Integração dos processos de desenvolvimentos de produtos com os processos de gestão de clientes altamente sofisticados, através de aplicativos de Customer Resource Management. ( ) Integração entre a gestão da empresa e o seu chão de fábrica, através de aplicações de Enterprise Resource Planning - ERP e Manufacturing Execution System - MES. ( ) Integração entre as funções administrativas e padronização dos aplicativos de back-office no contexto da empresa, de suas divisões e filiais, através de Enterprise Resource Planning - ERP. Assinale a alternativa que contém, de cima para baixo, a sequência correta.

65

(a) V, F, V, F, F. (b) V, F, F, F, V. (c) F, V, V, F, F. (d) F, V, F, V, V.

xx

(e) F, F, F, V, V.

TI para concursos

44

66. (ICMS-PR 2012) Sobre o planejamento do Programa de Governança de TI, assinale a alternativa correta.66

(a) A construção do CobiT requer intensa colaboração entre o pessoal de negócios e o de TI. Comparando

com a avaliação com base no Balanced Scorecard, diz-se que o CobiT emprega uma abordagem dedutiva.

(b) No Balanced Scorecard, o escopo do Programa de Governança de TI será uma lista de processos que necessitam ser melhorados, ou seja, devem evoluir para um patamar de maturidade maior ou realizar a implantação de um processo inexistente.

(c) O modelo Balanced Scorecard fornece todo o instrumental para a avaliação 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 concepção de um modelo de Governança de TI, o emprego do CobiT é mais focado, mas ainda é pouco empregado na área de TI, entretanto com ele é possível ter maior liberdade para usar o Balanced Scorecard e outros modelos, conforme for mais apropriado.

(e) Segundo o padrão para o Gerenciamento de Programas do PMI, o ciclo de vida de um programa é constituído por: Set-up do Pré-Programa ! Set-up do Programa ! Infraestrutura do Programa ! Entrega dos Benefícios ! Encerramento do Programa.

xx

67. (CVM 2010) Assinale a opção correta.67

(a) A estratégia de outsourcing decide como gerenciar o desempenho dos equipamentos. (b) O objetivo principal da Governança de TI é gerenciar outsourcing. (c) A estratégia de outsourcing decide como gerenciar os negócios internos dos fornecedores ou prestadores

de serviços. (d) O objetivo principal da Governança de TI é escolher a melhor alternativa de programação. (e) O objetivo principal da Governança de TI é alinhar TI aos requisitos do negócio.

xx

68. (SUSEP 2010) Um dos fatores motivadores da Governança de TI é68

(a) a dependência do negócio em relação à TI.

xx

(b) o ambiente de trabalho. (c) a integração organizacional. (d) a TI como provedora de serviços. (e) o valor da informação.

69. (SUSEP 2010) Em relação ao COBIT, é correto afirmar que o mesmo69

(a) estabelece posicionamentos com os registros do negócio. (b) identifica os principais recursos de WFD, nos quais deve haver menos requisitos. (c) organiza as atividades de TI em um modelo de processos genérico.

xx

(d) estabelece prioridades entre os responsáveis pelo negócio. (e) define as métricas sem controle que devem ser sequenciadas no desenvolvimento.

70. (SUSEP 2010) Entre as aplicações do COBIT em uma organização, situam-se70

(a) auditoria de riscos operacionais de concorrentes e qualificação de armazenadores de TI. (b) implantação modular da Governança de TI e realização de benchmarking.

xx

(c) avaliação dos topservers de TI e desenvolvimento dos riscos situacionais de TI. (d) desmembramento de riscos e benefícios da TI e realização de branch and bound. (e) atualização de casual failures e implantação exógena da Governança de TI.

71. (SUSEP 2010) As áreas foco da Governança de TI na visão do COBIT são:71

(a) Alinhamento Estratégico, Agregação de Valor, Gerenciamento de Riscos, Gerenciamento de Recursos e

Medições de Desempenho.xx

(b) Alinhamento Estratégico, Medições de Perdas, Gerenciamento de Riscos, Gerenciamento de Requisitos e

Condições de Mercado. (c) Planejamento Estratégico, Valores de Ativos, Gerenciamento de Pessoas, Agregação de Componentes e

Medições de Custos. (d) Aquisições Estratégicas, Composição de Valor, Gerenciamento de Benefícios, Gerenciamento de

Recursos e Modificações de Desempenho. (e) Alinhamento de Desempenho, Associação de Valores e Benefícios, Gerenciamento de Decisões,

Gerenciamento de Perda de Recursos e Medições de Riscos.

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

(a) monitorar e avaliar os controles internos. (b) determinar a direção tecnológica. (c) garantir a segurança dos sistemas. (d) gerenciar desempenho e capacidade. (e) gerenciar mudanças.

xx

TI para concursos

45

73. (CVM 2010) Os níveis dos modelos de maturidade do COBIT são: 73

(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 mensurável (4).

Repetitivo (5). (c) Inexistente (0). Em definição (1). Restritivo mas intuitivo (2). Otimizado (3). Gerenciado e mensurável (4).

Disponibilizado (5). (d) A definir (0). Inicial / Ad hoc (1). Repetitivo e redundante (2). Definido (3). Orientado para mensuração (4).

Maximizado (5). (e) Inexistente (0). Inicial / Ad hoc (1). Repetitivo mas intuitivo (2). Definido (3). Gerenciado e mensurável (4).

Otimizado (5).xx

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

I - O gerente de determinada organização foi incumbido de definir nível de serviços (SLA) relacionados à tecnologia da informação (TI) nessa organização, com base no ITIL e no COBIT. Nessa situação, por se tratar de serviço, deve o gerente utilizar o ITIL como única referência, visto que o COBIT não trata de SLA, abordando níveis de serviço apenas da perspectiva de auditoria e alinhamento desses níveis à estratégia do negócio. 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 ITIL, não são abordados gerenciamentos relacionados a avaliação e monitoração de controles internos.

xx

III - Tanto no COBIT quanto no ITIL, há gerenciamento de configuração, que possibilita criar e manter um repositório central de dados sobre os itens de configuração da organização. No COBIT, essa gerência pertence ao domínio Entrega e Suporte; no ITIL, está descrita na Transição do Serviço.

xx

IV - Comparando-se, no nível macro, os processos do COBIT e as gerências do ITIL, é correto afirmar que há maior correlação das gerências do ITIL com os processos do domínio Entrega e Suporte do COBIT que com os do domínio Planejamento e Organização.

xx

Estão 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 mudanças é referenciado na Transição de Serviços do ITIL e no domínio Entrega e Suporte do COBIT. II - O foco do ITIL é o gerenciamento de serviços, o do COBIT, o negócio, do que se conclui que aspectos relacionados à gerência financeira e de investimentos de TI são tratados pelo COBIT, mas não pelo ITIL. III - Diferentemente do ITIL, que não prevê gerência para tratar diretamente da arquitetura da informação, no COBIT há um processo que visa estabelecer um modelo de dados de negócio, no qual se incluem esquemas de classificação de dados, com o objetivo de asseverar consistência e integridade e consistência dos dados.

xx

Estão corretos os itens: (a) I, II e III (b) I, III apenas (c) I apenas (d) II apenas (e) III apenas.

xx

TI para concursos

46

4 Segurança da informação

4.1 Conceitos básicos

Segurança da Informação é a proteção de um conjunto de dados, no sentido de preservar o valor que possuem para um indivíduo ou uma organização.

O conceito de Segurança Informática ou Segurança de Computadores inclui a segurança dos dados/informação e a dos sistemas em si.

20

Entende-se por informação todo e qualquer conteúdo ou dado que tenha valor para alguma organização ou pessoa. Ela pode estar guardada para uso restrito ou exposta ao público para consulta ou aquisição.

Podem ser estabelecidas métricas para a definição do nível de segurança existente e, com isto, serem estabelecidas as bases para análise da situação. A segurança de uma determinada informação pode ser afetada por fatores comportamentais e de uso de quem se utiliza dela, pelo ambiente ou infra-estrutura.

Os atributos básicos da segurança:

Confidencialidade - propriedade que limita o acesso a informação às entidades legítimas, ou seja, àquelas autorizadas pelo proprietário da informação.

Integridade - propriedade que garante que a informação mantenha todas as características originais estabelecidas pelo proprietário da informação, incluindo controle de mudanças e garantia do seu ciclo de vida (nascimento, manutenção e destruição).

Disponibilidade - propriedade que garante que a informação esteja sempre disponível para o uso legítimo, ou seja, por aqueles usuários autorizados pelo proprietário da informação.

O nível de segurança desejado, pode se consubstanciar em uma "política de segurança" que é seguida pela organização ou pessoa, para garantir que, uma vez estabelecidos os princípios, aquele nível desejado seja perseguido e mantido. Para a montagem desta política, deve-se levar em conta:

Riscos associados à falta de segurança;

Benefícios;

Custos de implementação dos mecanismos.

O suporte para as recomendações de segurança pode ser encontrado em:

Controles físicos: são barreiras que limitam o contato ou acesso direto a informação ou a infra-estrutura que a suporta, como portas, trancas, paredes, blindagem, guardas etc.

Controles lógicos: são barreiras que impedem ou limitam o acesso a informação, que está em ambiente controlado, geralmente eletrônico. Mecanismos de criptografia. Permitem a transformação reversível da informação de forma a torná-la

ininteligível a terceiros. Utiliza-se para tal, algoritmos determinados e uma chave secreta para, a partir de um conjunto de dados não criptografados, produzir uma sequência de dados criptografados. A operação inversa é a decifração. Os algoritmos com chave dupla, ou chaves assimétricas, podem usar uma chave pública para criptografar e uma chave diferente, privada, secreta, para decifrar.

Assinatura digital. Um conjunto de dados criptografados, associados a um documento do qual são função, garantindo a integridade do documento associado, mas não a sua confidencialidade.

Mecanismos de garantia da integridade da informação. Usando funções de "Hashing" ou de checagem, consistindo na adição.

Mecanismos de controle de acesso. Palavras-chave, sistemas biométricos, firewalls, cartões inteligentes. Mecanismos de certificação. Atesta a validade de um documento. Integridade. Medida em que um serviço/informação é genuíno, isto é, está protegido contra a

personificação por intrusos. Honeypot: É o nome dado a um software, cuja função é detectar ou de impedir a ação 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 segurança.

Existe hoje em dia um elevado número de ferramentas e sistemas que pretendem fornecer segurança. Alguns exemplos são os detectores de intrusões, os anti-vírus, firewalls, firewalls locais, filtros anti-spam, fuzzers, analisadores de código, etc.

As ameaças à segurança da informação são relacionadas diretamente à perda de uma de suas três características principais, quais sejam:

Perda de Confidencialidade: quebra de sigilo de uma determinada informação (ex: a senha de um usuário ou administrador de sistema) permitindo com que sejam expostas informações restritas as quais seriam acessíveis apenas por um determinado grupo de usuários.

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

TI para concursos

47

Perda de Integridade: determinada informação fica exposta a manuseio por uma pessoa não autorizada, que efetua alterações que não foram aprovadas e não estão sob o controle do proprietário (corporativo ou privado) da informação.

Perda de Disponibilidade: a informação deixa de estar acessível por quem necessita dela.

No caso de ameaças à rede de computadores ou a um sistema, estas podem vir de agentes maliciosos, muitas vezes conhecidos como crackers (hackers não são agentes maliciosos, pois tentam ajudar a encontrar possiveis falhas). Estas pessoas são motivadas para fazer esta ilegalidade por vários motivos. Os principais são: notoriedade, auto-estima, vingança e o dinheiro. De acordo com pesquisa elaborada pelo Computer Security Institute, mais de 70% dos ataques partem de usuários legítimos de sistemas de informação (Insiders) -- o que motiva corporações a investir largamente em controles de segurança para seus ambientes corporativos (intranet).

Depois de identificado o potencial de ataque, as organizações têm que decidir o nível de segurança a estabelecer para uma rede ou sistema os recursos físicos e lógicos a necessitar de proteção. No nível de segurança devem ser quantificados os custos associados aos ataques e os associados à implementação de mecanismos de proteção para minimizar a probabilidade de ocorrência de um ataque.

Segurança física - Considera as ameaças físicas como incêndios, desabamentos, relâmpagos, alagamento, acesso indevido de pessoas, forma inadequada de tratamento e manuseamento do material.

Segurança lógica - Atenta contra ameaças ocasionadas por vírus, acessos remotos à rede, backup desatualizados, violação de senhas etc.

De acordo com o RFC 2196 (The Site Security Handbook), uma política de segurança consiste num conjunto formal de regras que devem ser seguidas pelos utilizadores dos recursos de uma organização.

As políticas de segurança devem ter implementação realista, e definir claramente as áreas de responsabilidade dos utilizadores, do pessoal de gestão de sistemas e redes e da direção. Deve também adaptar-se a alterações na organização. As políticas de segurança fornecem um enquadramento para a implementação de mecanismos de segurança, definem procedimentos de segurança adequados, processos de auditoria à segurança e estabelecem uma base para procedimentos legais na sequência de ataques.

O documento que define a política de segurança deve deixar de fora todos os aspectos técnicos de implementação dos mecanismos de segurança, pois essa implementação pode variar ao longo do tempo. Deve ser também um documento de fácil leitura e compreensão, além de resumido.

Algumas normas definem aspectos que devem ser levados em consideração ao elaborar políticas de segurança. Entre essas normas estão a BS 7799 (elaborada pela British Standards Institution) e a NBR ISO/IEC 17799 (a versão brasileira desta primeira). A ISO publicou a série de normas 27000, em substituição à ISO 17799 (e por conseguinte à BS 7799), das quais a primeira, ISO 27001, foi publicada em 2005.

Existem duas filosofias por trás de qualquer política de segurança: a proibitiva (tudo que não é expressamente permitido é proibido) e a permissiva (tudo que não é proibido é permitido).

Os elementos da política de segurança devem ser considerados:

Disponibilidade: o sistema deve estar disponível de forma que quando o usuário necessitar possa usar. Dados críticos devem estar disponíveis ininterruptamente.

Utilização: o sistema deve ser utilizado apenas para os determinados objetivos.

Integridade: o sistema deve estar sempre íntegro e em condições de ser usado.

Autenticidade: o sistema deve ter condições de verificar a identidade dos usuários, e este ter condições de analisar a identidade do sistema.

Confidencialidade: dados privados devem ser apresentados somente aos donos dos dados ou ao grupo por ele liberado.

4.2 Plano de Continuidade de Negócio

Business Continuity Plan (BCP) é o desenvolvimento preventivo de um conjunto de estratégias e planos de ação de maneira a garantir que os serviços essenciais sejam devidamente identificados e preservados após a ocorrência de um desastre e até o retorno à situação normal de funcionamento da empresa dentro do contexto do negócio do qual ela faz parte. Além disso, sob o ponto de vista do PCN, o funcionamento de uma empresa deve-se a duas variáveis: os componentes e os processos.

21

Os componentes são todas as variáveis utilizadas para realização dos processos: energia, pessoas, telecomunicações, informática, infra-estrutura. Todas elas podem ser substituídas ou restauradas, de acordo com suas características.

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

TI para concursos

48

Já os processos são as atividades realizadas para operar os negócios da empresa.

O Plano de Continuidade de Negócios é constituído pelos seguintes planos:

Plano de Administração de Crises (PAC)

Plano de Recuperação de Desastres (PRD)

Plano de Continuidade Operacional (PCO)

Todos estes planos têm como objetivo principal a formalização de ações a serem tomadas para que, em momentos de crise, a recuperação, a continuidade e a retomada possam ser efetivas, evitando que os processos críticos de negócio da organização sejam afetados, o que pode acarretar em perdas financeiras.

A norma ISO 27002 estabelece uma estrutura de planejamento com diversos procedimentos:

Emergência Ações a serem tomadas após a ocorrência de um incidente que coloque em risco as operações do negócio;

Recuperação Ações necessárias para a transferência das atividades essenciais do negócio ou os serviços de infra-estrutura para localidades alternativas temporárias e para a reativação dos processos do negócio no prazo necessário; Ações a serem adotadas quando do restabelecimento das operações;

Operacionais temporários Para seguir durante a conclusão de recuperação e restauração;

A norma não define o que é restauração. Para a Microsoft, restauração é o procedimento de retornar um sistema a um estado anterior. Para o dicionário de português, é sinônimo de recuperar..

No que diz respeito à necessidade de atualizações, o Plano de Continuidade de Negócios deve ser revisado periodicamente, pois mudanças significativas em componentes, atividades ou processos críticos de negócio podem fazer com que novas estratégias e planos de ação sejam previstos, evitando assim com que eventuais desastres desestabilizem profundamente o andamento regular do negócio da empresa.

Desastre pode ser entendido como qualquer situação que afete os processos críticos do negócio de uma organização. Conseqüentemente, algumas ocorrências podem ser caracterizadas como sendo desastres para uma determinada empresa, mas podem não ser caracterizadas como um desastre para outra empresa.

As principais etapas de um plano de continuidade são:

Analise de riscos - Analisa-se o grau de exposição a que o negócio pode estar exposto. Sejam exposições de ação natural (vendaval, inundação, fogo) ou aquelas da ação do homem (sabotagem, erro ou falha humana).

Analise dos impactos no negócio - análise dos impactos da perda no negócio da organização. Neste estudo devem-se identificar as aplicações mais criticas para o negócio e seu tempo de recuperação necessário para a continuidade.

Estratégia de recuperação - planejamento do maior número de possibilidades e formas de recuperação, que seja rápida, eficiente e com baixo custo.

4.3 Vulnerabilidade

A vulnerabilidade na computação significa ter brecha em um sistema computacional, também conhecida como bug. Esta mesma pode ser explorada em um determinado sistema ou serviço vulnerável que esteja rodando na máquina.

As vulnerabilidades mais exploradas nos dias de hoje, são as do tipo buffer overflow, que muitas vezes pode dar privilégios de administrador para o invasor, rodar códigos maliciosos remotamente, burlar particularidades de cada sistema, ataques de Negação de Serviços (DDoS), e acesso irestrito ao sistema.

Existem ferramentas específicas para se explorar as vulnerabilidades, cada ferramenta para a sua respectiva vulnerabilidade a ser explorada (na maioria das vezes escritas em linguagem C e Assembly), essas ferramentas são chamadas de exploits.

Um exploit, em segurança da informação, é um programa de computador, uma porção de dados ou uma sequência de comandos que se aproveita das vulnerabilidades de um sistema computacional – como o próprio sistema operacional ou serviços de interação de protocolos (ex: servidores Web). São geralmente elaborados por hackers como programas de demonstração das vulnerabilidades, a fim de que as falhas sejam corrigidas, ou por crackers a fim de ganhar acesso não autorizado a sistemas. Por isso muitos crackers não publicam seus exploits, conhecidos como 0days, e o seu uso massificado deve-se aos script kiddies.

TI para concursos

49

Até meados dos anos 90, acreditava-se que os exploits exploravam exclusivamente problemas em aplicações e serviços para plataformas Unix. A partir do final da década, 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 comunicação com a rede que possa ser usado para entrar, uma porta ou uma consola.

Um exploit muito usado é no sistema RPC do Windows:

o usuário localiza a porta e envia à porta RPC uma sequência de bytes, que são interpretados como dados pelo servidor

quando são recebidos, estes dados deixam propositadamente o sistema em pane o sistema passa o controle a estes próprios dados que então são uma sequência de ordem para dominar

a CPU.

Desta forma esta sequência de informações toma conta do PC e abre-o para o hacker que aguarda na outra ponta.

Ameaças à segurança das redes que fazem com que os micros infectados por esses tipos de vírus formem redes de computadores "zumbis" que são comandados simultaneamente por seus invasores para enviar mensagens indesejadas (spam), colocar sites fora do ar e promover fraudes são categorizadas como botnet (robôs).

Keylogger é um programa capaz de capturar e armazenar as teclas digitadas pelo usuário no teclado de um computador.

No sistema Linux, quando existem vulnerabilidades, sempre são publicadas, como já houve no sistema Apache, Samba ou MySQL, que também 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 gestão de recursos, com o foco nos aspectos de eficiência, eficácia, economia e efetividade. A abrangência desse tipo de auditoria pode ser o ambiente de informática como um todo ou a organização do departamento de informática:

22

Ambiente de informática: Segurança dos outros controles; Segurança física; Segurança lógica; Planejamento de contingências; Operação do centro de processamento de dados.

Organização do departamento de informática: Aspectos administrativos da organização; Políticas, padrões, procedimentos, responsabilidades organizacionais, gerência pessoal e planejamento

de capacidade; Banco de dados; Redes de comunicação e computadores; Controle sobre aplicativos: Desenvolvimento, Entradas, processamento e saídas.

Auditoria da tecnologia da informação é abrangente, engloba todos os controles que podem influenciar a segurança de informação e o correto funcionamento dos sistemas de toda a organização:

Controles organizacionais;

De mudança;

De operação de sistemas;

Sobre Banco de Dados;

Sobre microcomputadores;

Sobre ambiente cliente-servidor.

Auditoria da segurança de informações determina a postura da organização com relação à segurança. Avalia a política de segurança e controles relacionados com aspectos de segurança institucional mais globais, faz parte da auditoria da TI. Seu escopo envolve:

Avaliação da política de segurança;

Controles de acesso lógico;

Controles de acesso físicos;

22 http://pucrs.campus2.br/~annes/sas_audit.doc

TI para concursos

50

Controles ambientais;

Planos de contingência e continuidade de serviços.

Auditoria de aplicativos verifica a segurança e o controle de aplicativos específicos, incluindo aspectos intrínsecos à área a que o aplicativo atende:

Controles sobre o desenvolvimento de sistemas aplicativos;

Controles de entradas, processamento e saída de dados;

Controle sobre conteúdo e funcionamento do aplicativo, com relação à área por ele atendida.

A natureza especializada da auditoria de sistemas de informação (SI) e a capacidade necessária para realizar essas auditorias requerem o estabelecimento de normas que se apliquem especificamente à auditoria de SI.

23

A Associação de Auditoria e Controle de Sistemas de Informação, ISACA, desenvolve normas aplicáveis globalmente, de forma a suportar essa visão. A estrutura das Normas de Auditoria de SI apresenta diversos níveis de orientação:

Normas: definem requisitos obrigatórios para auditorias e relatórios de SI. Informam: Os auditores de SI sobre o nível mínimo de desempenho aceitável exigido para cumprir as

responsabilidades profissionais estabelecidas no Código de Ética Profissional A gestão e outras partes interessadas sobre as expectativas da profissão no que se refere às atividades

daqueles que a exercem

Diretrizes: fornecem orientação para a aplicação das normas de auditoria de SI. O auditor de SI deve levá-las em consideração para determinar como alcançar a implementação das normas, utilizar a avaliação profissional na sua aplicação e estar preparado para justificar qualquer divergência. O objetivo das Directrizes de Auditoria de SI é fornecer informações adicionais sobre como cumprir as Normas de Auditoria de SI.

Procedimentos: fornecem exemplos de procedimentos que um auditor de SI pode seguir durante a realização de uma auditoria. Os documentos de procedimentos fornecem informações sobre como cumprir as normas ao realizar a auditoria de SI, mas não estabelecem requisitos. O objetivo dos Procedimentos de Auditoria de SI é fornecer informações adicionais sobre como cumprir as Normas de Auditoria de SI.

As normas da ISACA contêm princípios básicos e procedimentos essenciais que são obrigatórios, juntamente com orientações relacionadas com os mesmos, com o objetivo de estabelecer e fornecer orientações sobre áreas de governança 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 organização. conformidade com a organização: missão, visão, valores, qualidade de informações, objetivos e

estratégias. conformidade com as leis: ambientais, trabalhistas, fiduciárias e de segurança. eficiência e eficácia de SI, as suas realizações e os processos de gestão de desempenho. riscos que podem causar efeitos adversos no ambiente de SI.

Diretrizes de auditoria de SI: Carta de auditoria Conceitos de materialidade para auditoria de sistemas de informações Relacionamento e independência organizacionais Uso da avaliação de riscos no planeamento de auditoria Planeamento - lista detalhada das tarefas Impacto de terceiros em controles de TI de uma organização Impacto de função de não auditoria na independência do auditor de SI

4.5 Conhecimento sobre norma ISO 27001

ISO/IEC 27001 é um padrão para sistema de gerência da segurança da informação (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 informação - técnicas de segurança - sistemas de gerência da segurança da informação - requisitos mas conhecido como "ISO 27001".

24

Esta Norma foi preparada para prover um modelo para estabelecer, implementar, operar, monitorar, analisar criticamente, manter e melhorar um Sistema de Gestão de Segurança da Informação (SGSI/ISMS).

Seu objetivo é ser usado em conjunto com ISO/IEC 17799, renomeada para ISO 27002, o código de práticas para gerência da segurança da informação, o qual lista objetivos do controle de segurança e recomenda um conjunto de especificações de controles de segurança. Organizações que implementam

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

TI para concursos

51

um ISMS de acordo com as melhores práticas da ISO 17799 estão simultaneamente em acordo com os requisitos da ISO 27001, mas uma certificação é totalmente opcional.

Este padrão é o primeiro da família de segurança da informação relacionado aos padrões ISO que espera-se sejam agrupados à série 27000.

ISO 27000 - Vocabulário de Gestão da Segurança da Informação;

ISO 27001 - Publicada em Outubro de 2005 e substituiu a norma BS 7799-2 para certificação de sistema de gestão de segurança da informação;

ISO 27002 - Código de Boas Práticas. Substituiu em 2006/2007 o ISO 17799:2005;

ISO 27003 - Esta norma aborda a gestão de risco, contendo recomendações para a definição e implementação de um sistema de gestão de segurança da informação.

ISO 27004 - Esta norma incide sobre os mecanismos de mediação e de relatório de um sistema de gestão de segurança da informação.

ISO 27005 - Esta norma será constituída por indicações para implementação, monitoramento e melhoria contínua do sistema de controles. Conteúdo idêntico ao da norma BS 7799-3:2005 – “Information Security Management Systems - Guidelines for Information Security Risk Management”;

ISO 27006 - Referente à recuperação e continuidade de negócio.

ISO 27001 foi baseado e substitui o BS 7799 parte 2.

A série ISO 27000 está de acordo com outros padrões de sistemas de gerência ISO, como ISO 9001 (sistemas de gerência da qualidade) e ISO 14001 (sistemas de gerência ambiental), ambos em acordo com suas estruturas gerais e de natureza a combinar as melhores práticas com padrões de certificação.

Certificações de organização com ISMS ISO/IEC 27001 é um meio de garantir que a organização certificada implementou um sistema para gerência da segurança da informação de acordo com os padrões. Credibilidade é a chave de ser certificado por uma terceira parte que é respeitada, independente e competente. Esta garantia dá confiança à gerência, parceiros de negócios, clientes e auditores que uma organização é séria sobre gerência de segurança da informação - não perfeita, necessariamente, mas está rigorosamente no caminho certo de melhora contínua.

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 segurança de informação e as expectativas das partes interessadas, e como as ações necessárias e processos de segurança da informação produzidos resultam no atendimento a estes requisitos e expectativas.

Ilustração 9 Modelo PDCA aplicado aos processos do SGSI

Esta norma apresenta alguma definições:

Ativo Qualquer coisa que tenha valor para a organização

Disponibilidade Propriedade de estar acessível e utilizável sob demanda por uma entidade autorizada

Confidencialidade Propriedade de que a informação não esteja disponível ou revelada a indivíduos, entidades ou processos não autorizados

Segurança da informação Preservação da confidencialidade, integridade e disponibilidade da informação; adicionalmente, outras propriedades, tais como autenticidade, responsabilidade, não repúdio e confiabilidade, podem também estar envolvidas

TI para concursos

52

Evento de segurança da informação Uma ocorrência identificada de um estado de sistema, serviço ou rede, indicando uma possível violação da política de segurança da informação ou falha de controles, ou uma situação previamente desconhecida, que possa ser relevante para a segurança da informação

Incidente de segurança da informação Um simples ou uma série de eventos de segurança da informação indesejados ou inesperados, que tenham uma grande probabilidade de comprometer as operações do negócio e ameaçar a segurança da informação

Sistema de gestão da segurança da informação - SGSI A parte do sistema de gestão global, baseado na abordagem de riscos do negócio, para estabelecer, implementar, operar, monitorar, analisar criticamente, manter e melhorar a segurança da informação O sistema de gestão inclui estrutura organizacional, políticas, atividades de planejamento, responsabilidades, práticas, procedimentos, processos e recursos.

Integridade Propriedade de salvaguarda da exatidão e completeza de ativos

Risco residual Risco remanescente após o tratamento de riscos

Aceitação do risco Decisão de aceitar um risco

Análise de riscos Uso sistemático de informações para identificar fontes e estimar o risco

Análise/avaliação de riscos Processo completo de análise e avaliação de riscos

Avaliação de riscos Processo de comparar o risco estimado com critérios de risco predefinidos para determinar a importância do risco

Gestão de riscos Atividades coordenadas para direcionar e controlar uma organização no que se refere a riscos A gestão de riscos geralmente inclui a análise/avaliação de riscos, o tratamento de riscos, a aceitação de riscos e a comunicação de riscos.

Um dos procedimentos previstos na norma é identificar os riscos.

Identificar os ativos dentro do escopo do SGSI e os proprietários destes ativos.

Identificar as ameaças a esses ativos.

Identificar as vulnerabilidades que podem ser exploradas pelas ameaças.

Identificar os impactos que as perdas de confidencialidade, integridade e disponibilidade podem causar aos ativos.

Um SGSI deve identificar e avaliar as opções para o tratamento de riscos. Possíveis ações incluem:

aplicar os controles apropriados;

aceitar os riscos consciente e objetivamente, desde que satisfaçam claramente às políticas da organização e aos critérios de aceitação de riscos;

evitar riscos;

transferir os riscos associados ao negócio a outras partes, por exemplo, seguradoras e fornecedores.

A norma ISO 27002, consolida procedimentos de segurança de informação em um código de práticas para a gestão da segurança da informação.

A ISO trata também de conformidade com requisitos legais, para evitar violação de qualquer lei criminal ou civil, estatutos, regulamentações ou obrigações contratuais e de quaisquer requisitos de segurança da informação. O projeto, a operação, o uso e a gestão de sistemas de informação podem estar sujeitos a requisitos de segurança contratuais, regulamentares ou estatutários.

4.6 Exercícios

76. (ICMS-SP 2009) Segundo as normas ABNT sobre segurança da informação, o tratamento de risco está inserido no processo de

76

(a) gestão de riscos.xx

(b) aceitação do risco. (c) análise de riscos. (d) avaliação de riscos. (e) análise/avaliação de riscos.

TI para concursos

53

77. (ICMS-SP 2009) As ações a serem tomadas imediatamente após a ocorrência de um incidente que coloque em risco as operações do negócio devem estar descritas no plano de continuidade de negócios como procedimentos

77

(a) operacionais temporários. (b) de ensaio geral. (c) de recuperação. (d) de restauração. (e) de emergência.

xx

78. (ICMS-SP 2009) Se qualquer não-conformidade for encontrada como um resultado da análise crítica nas áreas sobre o cumprimento das políticas e normas de segurança da informação, NÃO convém que os gestores

78

(a) determinem as causas da não-conformidade. (b) determinem e implementem ação corretiva apropriada. (c) analisem criticamente a ação corretiva tomada. (d) avaliem a necessidade de ações para assegurar que a conformidade não se repita.

xx

(e) registrem os resultados das análises e das ações corretivas e que esses registros sejam mantidos.

79. (ICMS-SP 2009) No modelo PDCA adotado para estruturar todos os processos do SGSI – Sistema de Gestão de Segurança da Informação, os resultados das atividades da auditoria interna do SGSI estão vinculados ao ciclo PDCA como entrada dos processos na etapa

79

(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. (e) Act (Agir): manter e melhorar o SGSI.

xx

80. No Brasil, a NBR ISO17799 constitui um padrão de recomendações para práticas na gestão de Segurança da Informação. De acordo com o estabelecido nesse padrão, três termos assumem papel de importância capital: confidencialidade, integridade e disponibilidade. Nesse contexto, a confidencialidade tem por objetivo:

80

(a) salvaguardar a exatidão e a inteireza das informações e métodos de processamento. (b) salvaguardar os dados gravados no backup por meio de software que utilize assinatura digital. (c) permitir que os usuários tenham acesso aos arquivos de backup e aos métodos de criptografia

empregados. (d) permitir que os usuários autorizados tenham acesso às informações e aos ativos associados, quando

necessário. (e) garantir que as informações sejam acessíveis apenas para aqueles que estejam autorizados a acessá-

las.xx

81. Para garantir a segurança da informação em uma rede de computadores, um sistema de autenticação típico é composto apenas do código do usuário, uma senha e um

81

(a) processo de certificação. (b) método de criptografia. (c) sistema de detecção de intrusão. (d) plano de recuperação. (e) firewall.

xx

82. NÃO é um algoritmo de chave simétrica o sistema de criptografia de chave 82

(a) única. (b) pública.

xx

(c) secreta. (d) simétrica. (e) compartilhada.

83. Um conjunto de dados de computador, em observância à Recomendação Internacional ITUT X.509, que se destina a registrar, de forma única, exclusiva e intransferível, a relação existente entre uma chave de criptografia e uma pessoa física, jurídica, máquina ou aplicação é

83

(a) uma autoridade certificadora. (b) uma trilha de auditoria. (c) uma chave assimétrica. (d) uma assinatura digital. (e) um certificado digital.

xx

TI para concursos

54

84. Considere a seguinte definição: "Evitar violação de qualquer lei criminal ou civil, estatutos, regulamentação ou obrigações contratuais; evitar a violação de direitos autorais dos software - manter mecanismos de controle dos softwares legalmente adquiridos". De acordo com as especificações das normas brasileiras de segurança da informação, esta definição se inclui corretamente em

84

(a) Gestão de Incidentes e Segurança da Informação. (b) Conformidade.

xx

(c) Controle de Acesso. (d) Gestão da Continuidade do Negócio. (e) Gestão de Ativos.

85. É um elemento biométrico de identificação85

(a) a impressão digital.

xx

(b) o cartão bancário. (c) a senha da internet. (d) o certificado digital. (e) a assinatura eletrônica.

86. Ameaças à segurança das redes que fazem com que os micros infectados por esses tipos de vírus formem redes de computadores "zumbis" que são comandados simultaneamente por seus invasores para enviar mensagens indesejadas (spam), colocar sites fora do ar e promover fraudes são categorizadas como.

86

(a) Advance Fee Fraud. (b) Botnet.

xx

(c) Hoax. (d) Phishing. (e) Rootkit.

87. Programa capaz de capturar e armazenar as teclas digitadas pelo usuário no teclado de um computador é o 87

(a) Worm. (b) Spyware. (c) Backdoor. (d) Keylogger.

xx

(e) Cavalo de Tróia.

88. Por meio da análise dos procedimentos para estabelecer e finalizar uma conexão utilizada para troca de informações entre dois hosts, obtém-se informações que permitem uma prospecção sobre os serviços por eles oferecidos. Essa técnica, utilizada para descobrir um possível ataque do tipo DoS, é denominada

88

(a) network security. (b) file scan. (c) packet sniffer. (d) network scan.

xx

(e) scan vírus.

89. A integridade de software é medida89

(a) em defeitos por KLOC (milhares de linhas de código). (b) por sua usabilidade. (c) pelo mean-time-to-change - MTTC. (d) por sua conectividade. (e) pela capacidade do sistema resistir a ataques à sua segurança.

xx

90. Em relação aos conceitos de segurança, é correto afirmar:90

(a) Confidencialidade é a propriedade que se refere ao fato de determinada informação não poder ser

alterada ou destruída de maneira não autorizada. (b) Medidas físicas e organizacionais de proteção relacionam-se não apenas à proteção de hardware, mas

também a elementos lógicos de um sistema.xx

(c) Umidade e temperatura não podem ser consideradas ameaças a uma rede de SI. (d) Negação 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 desnecessário, desde que todos os

computadores da rede sejam dotados de antivírus ativos e atualizados.

91. A Disponibilidade do sistema, a Integridade dos dados e a Confidencialidade dos dados são objetivos de segurança dos sistemas, respectivamente, sujeitos às ameaças de

91

(a) Adulteração dos dados, Recusa de serviço e Exposição aos dados. (b) Recusa de serviço, Exposição aos dados e Adulteração dos dados. (c) Exposição aos dados, Recusa de serviço e Adulteração dos dados. (d) Recusa de serviço, Adulteração dos dados e Exposição aos dados.

xx

(e) Exposição aos dados, Adulteração dos dados e Recusa de serviço.

92. Na disciplina de segurança de redes e criptografia, a propriedade que traduz a confiança em que a mensagem não tenha sido alterada desde o momento de criação é:

92

(a) autenticidade. (b) criptologia. (c) não-repúdio. (d) integridade.

xx

(e) confidencialidade.

TI para concursos

55

93. Os mecanismos de segurança para autenticação efetiva de um usuário devem ser baseados em: I. Conhecimento individual. II. Posse de alguma coisa. III. Característica pessoal. IV. Local em que se encontra. É correto o que se afirma em

93

(a) I, II e III, apenas. (b) I, II e IV, apenas. (c) I, III e IV, apenas. (d) II, III e IV, apenas. (e) I, II, III e IV.

xx

94. Receber as solicitações de serviços, oriundas de clientes internos, e enviá-las para a rede externa como se fosse o cliente de origem é uma função do

94

(a) criptógrafo. (b) firewall. (c) proxy.

xx

(d) soquete. (e) broadcast.

95. Sobre segurança da informação, é correto afirmar que95

(a) vulnerabilidades determinam controles de segurança. (b) riscos são determinados pelas vulnerabilidades. (c) controles de segurança eliminam os riscos. (d) ameaças exploram vulnerabilidades.

xx

(e) vulnerabilidades provocam ameaças.

96. O controle de acesso lógico pode utilizar, para proteção aos arquivos de dados e de programas, uma senha pessoal como recurso de

96

(a) permissão de acesso. (b) direito de acesso. (c) monitoração de acesso. (d) autenticação do usuário.

xx

(e) identificação do usuário.

97. Com relação à estrutura, objetivos e conceitos gerais da NBR ISO/IEC 17799:2005 é correto afirmar: 97

(a) Estabelece diretrizes e princípios gerais para iniciar, implementar, manter e melhorar a gestão de

segurança da informação em uma organização. Os objetivos definidos nesta Norma provêem diretrizes gerais sobre as metas geralmente aceitas para a gestão da segurança da informação.

xx

(b) Os objetivos de controle e os controles desta Norma têm como finalidade ser implementados para atender aos requisitos identificados exclusivamente por meio da classificação das informações.

(c) Um incidente de segurança da informação é indicado por um evento de segurança da informação esperado, que tenha uma grande probabilidade de comprometer as operações do negócio e ameaçar a segurança da informação.

(d) A gestão de riscos consiste no processo de seleção e implementação de medidas para modificar um risco. Inclui a análise, o tratamento e a comunicação de riscos e exclui a aceitação de riscos.

(e) Contém 9 seções de controles de segurança da informação, que juntas totalizam 59 categorias principais de segurança e uma seção introdutória que aborda a questões de contingência.

98. (TCE AM 2012) Com relação ao Plano de Continuidade de Negócio é INCORRETO afirmar98

(a) Deve ser elaborado um Plano de Continuidade de Negócio que possibilite que a organização funcione em

um nível aceitável para sua sobrevivência e absorva possíveis impactos financeiros, operacionais e de imagem.

(b) O desenvolvimento do Plano de Continuidade de Negócio deve ser específico para cada organização, pois deve ser baseado em uma análise de impacto no negócio caso ocorra uma indisponibilidade dos recursos de informação.

(c) A alta administração e os acionistas da organização não precisam conhecer e aprovar as ameaças e riscos que estão fora de cada versão do Plano de Continuidade de Negócio, pois esses aspectos são definidos e homologados pela gerência de TI.

xx

(d) O Plano de Continuidade de Negócio deve ser eficiente/ eficaz, mantido atualizado e testado periodicamente com a participação de todos os envolvidos.

(e) Seu objetivo é o planejamento de ações para serem executadas quando da ocorrência de uma situação de contingência, de maneira a garantir que a organização mantenha suas atividades críticas em um nível previamente definido pela área de negócio e direção como aceitável.

TI para concursos

56

5 Arquitetura de Software

O aumento da competitividade e das exigências impostas às empresas e organizações leva estas a adotar modelos organizacionais e processos de negócio cada vez mais complexos e interdependentes. A definição, a execução, o controle e a evolução de tais processos só é possível devido aos avanços nas estruturas organizacionais e no projeto e uso de sistemas de informação.

Estes sistemas são frequentemente construídos a partir da compreensão e captura dos processos organizacionais e são cada vez mais compostos a partir da integração de dezenas de serviços eletrônicos heterogêneos, potencialmente distribuídos em diversas organizações e apoiados por uma complexa infra-estrutura de Tecnologia de Informação (TI).

Neste contexto, a complexidade dos ambientes organizacionais e dos sistemas de informação 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 princípios, métodos e modelos que são usados na definição e implementação de estruturas organizacionais, processos de negócio, sistemas de informação e infra-estrutura técnica de TI no contexto de uma organização.

A importância do conceito de Arquitetura Organizacional está refletida nos diversos frameworks para estruturação 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 refêrencia RM-ODP da ISO (Reference Model for Open Distributed Processing), e ainda a arquitetura ARIS (Architecture of Integrated Information Systems) considerada um padrão de fato em diversos segmentos produtivos.

A grande maioria destes frameworks considera uma organização como um sistema cujos elementos incluem:

as estruturas organizacionais (como os atores, papéis e unidades de uma organização);

as atividades organizacionais estruturadas em serviços e processos de negócio;

os serviços eletrônicos e sistemas de informação que apóiam as atividades organizacionais,

os modelos conceituais de informação

a infra-estrutura técnica de suporte aos sistemas de informação.

Desta forma, uma Arquitetura Organizacional deve abranger elementos em domínios de discurso diversos que são relevantes para diferentes interessados (stakeholders), devendo ainda relacionar estes elementos para formar uma visão coesa da organização e seus sistemas.

Um dos principais desafios enfrentados na aplicação do conceito de Arquitetura Organizacional é encontrado na captura e formalização de uma descrição para que esta sirva como um veículo para documentação, visualização, análise, manipulação e evolução de uma organização e seus sistemas.

25

Assim como no caso das arquiteturas de software, os primeiros esforços para capturar arquiteturas organizacionais foram baseados em conjuntos de diagramas informais. Diagramas informais envolvem o uso de elementos gráficos de forma intuitiva, porém imprecisa e desestruturada. Técnicas para descrição de arquiteturas organizacionais permitiram aumentar o rigor da atividade de captura de arquiteturas organizacionais com a definição de linguagens para modelagem de arquiteturas organizacionais.

Um domínio particularmente maduro no escopo da modelagem de arquiteturas organizacionais é o domínio de modelagem de processos de negócio (Business Process Modelling). Há diversas linguagens de modelagem de processos de negócio de ampla relevância como o subconjunto eEPC do ARIS Method, a linguagem AMBER suportada pelas ferramentas da BizzDesign, e mais recentemente, o padrão Business Process Modelling Notation (BPMN) do Object Management Group (OMG).

A proliferação das metodologias levou ao aparecimento de diversas notações e técnicas de modelação, que muitas vezes são partilhadas entre várias delas. Os recentes esforços de unificação permitiram que algumas dessas técnicas se tenham destacado.

Apesar dos benefícios que se reconhecem na utilização de metodologias (independentemente do paradigma utilizado), elas não estão isentas de críticas e de aspectos menos positivos:

Complexidade nos conceitos, técnicas e aplicação.

Desconhecimento global da metodologia e falta de competências dos informáticos para a sua execução com qualidade.

Ferramentas que suportam a metodologia difíceis de utilizar.

Constatação da ausência de melhorias significativas no processo e produto final.

Concentração na análise da situação actual, menor importância aos objectivos futuros.

Tempo que decorre até à disponibilização dos resultados finais.

Rigidez na aplicação dos métodos e conceitos.

Independentemente da evolução das linguagens para modelagem de arquiteturas organizacionais, a evolução das linguagens de modelagem de sistemas de software (das quais o exemplo mais proeminente é a Unified Modeling Language (UML)), resultou na ampla adoção de técnicas de modelagem para a especificação de sistemas de informação. Mais recentemente, a UML tem sido empregada também na descrição de arquiteturas

25 ALMEIDA, João Paulo A. “Modelagem de Arquiteturas Organizacionais de TI Orientadas a Serviços”

TI para concursos

57

organizacionais, com desenvolvimentos do perfil da UML para o modelo de referência RM-ODP (UML Profile for RM-ODP), os perfis de UML para descrições arquiteturais de acordo com o framework DoDAF e a combinação 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 também se refere à documentação da arquitetura de software do sistema. A documentação da arquitetura do software facilita a comunicação entre os stakeholders, registra as decisões iniciais acerca do projeto de alto nível e permite o reuso do projeto dos componentes e padrões entre projetos.

26

A arquitetura de software é organizada em visões, que descrevem a arquitetura na perspectiva de um conjunto de pessoas interessadas, como:

Visão funcional/lógica

Visão de código

Visão de desenvolvimento/estrutural

Visão de concorrência/processo/thread

Visão física/evolutiva

Visão de ação do usuário/feedback

Várias linguagens para descrição da arquitetura de software foram inventadas, mas nenhum consenso foi ainda alcançado em relação a qual conjunto de símbolos ou sistema representação deve ser adotado. Alguns acreditam que a UML irá estabelecer um padrão para representação de arquitetura de software. Outros acreditam que os desenvolvimentos efetivos de software devem contar com a compreensão única das restrições de cada problema, e notações tão universais são condenadas a um final infeliz porque cada uma provê um notação diferenciada que necessariamente torna a notação inútil ou perigosa para alguns conjuntos de tarefas. Eles apontam a proliferação de linguagens de programação e a sucessão de tentativas falhas para impor uma simples 'linguagem universal' na programação, como uma prova da tendência do software para a diversidade e não para padrões.

5.1 UML

A UML (Unified Modeling Language) é uma linguagem de modelagem não proprietária de terceira geração para especificação, construção, visualização e documentação de artefatos de um sistema de software.

A UML surgiu em 1997 na sequência de um esforço de unificação de três das principais linguagens de modelação 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 contribuições 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 notação gráfica, a UML também especifica significados (semântica).

Os objetivos da UML são: especificação, documentação, e estruturação para sub-visualização e maior visualização lógica do desenvolvimento completo de um sistema de informação. A UML é um modo de padronizar as formas de modelagem.

O UML se compõe de diversos diagramas, cada um para um tipo diferente de visão.

Diagramas Comportamentais Diagrama de Caso de Uso - descreve a funcionalidade proposta para o novo sistema. Um desenho com

representação de um ator, humano ou entidade máquina, que interage (relação) com o sistema (casos de uso) para executar um trabalho. Estes relacionamentos podem ser: associações entre atores e casos de uso. Define uma funcionalidade do sistema do ponto de vista do

usuário. generalizações entre os atores. Os casos de uso de um ator são também casos de uso do outro, que

tem seus próprios casos de uso. generalizações entre os casos de uso. O caso de uso B é um caso de uso A (A é uma generalização

de B, ou B é uma especialização de A). Um relacionamento entre um caso de uso genérico para um mais específico, que herda todas as características de seu pai.

extensões 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 (não é essencial). A extensão é inserida em um ponto de extensão do caso de uso A.

inclusões 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 também que B is_part_of A ou que A depende de B.

Diagrama de transição de estados - representação do estado ou situação em que um objeto pode se encontrar no decorrer da execução de processos de um sistema.

Diagrama de atividade - mostra o fluxo de controle de uma atividade para outra.

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

TI para concursos

58

Diagramas Estruturais Diagrama de classes - representação da estrutura e relações das classes que servem de modelo para

objetos. Uma propriedade, atributo ou operação 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 código fonte do software. Diagrama de instalação - descreve os componentes de hardware e software e sua interação com outros

elementos de suporte ao processamento. Diagrama de pacotes - descreve grupos de classes, de outros elementos ou pedaços do sistema divididos

em agrupamentos lógicos mostrando as dependências entre estes. Diagrama de estrutura - descreve a colaboração interna de classes, interfaces ou componentes para

especificar uma funcionalidade.

Diagramas de Interação Diagrama de sequência - representa a sequência de mensagens passadas entre objetos num programa

de computador. Utiliza-se também o termo cenário associado com diagramas de seqüência.27

Diagrama de Interatividade – descreve o fluxo de atividades mostrando como elas trabalham em uma

sequência de eventos. Diagrama de colaboração ou comunicação - exibe uma interação, 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 interação em uma escala de tempo,

focalizando as condições que mudam no decorrer desse período.

Também se utiliza de elementos para sua representação:

De estrutura: Classe Classe ativa Interface Componente Colaboração Nó (cubo) - objeto físico em tempo de execução que representa um recurso computacional, possuindo,

geralmente, pelo menos uma memória, bem como, uma capacidade de processo. Objetos em tempo de execução e componentes podem residir em nó. Graficamente, um Nó é representado pelo desenho de um Cubo.

De comportamento: Casos de uso Iteração Máquina de estados

De agrupamento: Pacote Modelo Subsistema Framework

De anotação: Notas

De relacionamentos Associação (bidirecional ou unidirecional) Generalização Composição

5.2 Arquitetura Orientada a Serviço (SOA)

Service-oriented architecture (SOA) é um estilo de arquitetura de software cujo princípio fundamental preconiza que as funcionalidades implementadas pelas aplicações devem ser disponibilizadas na forma de serviços. Freqüentemente estes serviços são organizados através de um "barramento de serviços" (enterprise service bus, em inglês) que disponibiliza interfaces, ou contratos, acessíveis através de web services ou outra forma de comunicação entre aplicações. A arquitetura SOA é baseada nos princípios da computação distribuída e utiliza o paradigma request/reply para estabelecer a comunicação entre os sistemas clientes e os sistemas que implementam os serviços.

28

Além da perspectiva estritamente técnica, a arquitetura orientada a serviços também se relaciona com determinadas políticas e conjuntos de "boas práticas" que pretendem criar um processo para facilitar a tarefa de encontrar, definir e gerenciar os serviços disponibilizados.

A arquitetura orientada a serviços também se insere em um processo de reorganização dos departamentos de tecnologia da informação das organizações, permitindo um melhor relacionamento entre as áreas que dão suporte tecnológico à empresa e as áreas responsáveis pelo negócio

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

TI para concursos

59

propriamente dito, graças a maior agilidade na implementação de novos serviços e reutilização dos ativos existentes.

5.2.1 Serviço

Um serviço, do ponto de vista da arquitetura SOA, é uma função de um sistema computacional que é disponibilizado para outro sistema. Um serviço deve funcionar de forma independente do estado de outros serviços, exceto nos casos de serviços compostos (composite services), e deve possuir uma interface bem definida. Normalmente, a comunicação entre o sistema cliente e aquele que disponibiliza o serviço é realizada através de web services.

5.2.2 Processos

A Arquitetura Orientada a Serviços pode ser bem representada a partir do seguinte processo, chamado de "find-bind-execute paradigm" o que significa aproximadamente paradigma de "procura-consolida-executa". Tal conceito é análogo a "Ciclo de Deming" aplicado aos serviços, que define o ciclo que envolve o planejamento, a execução, o monitoramento e a tomada de ação pró-ativa para a melhoria da qualidade.

Esquema adaptado do paradigma "find-bind-execute", tecnicamente falando, o processo preconiza que os provedores de serviços registrem informações em um registro central, com suas características, indicadores, e aspectos relevantes às tomadas de decisões. O registro é utilizado pelo cliente para determinar as características dos serviços necessários, e se o mesmo estiver disponível no registro central, como por exemplo por um catálogo de serviços, o cliente poderá utilizá-lo, sendo este oficializado através de um contrato que enderece este serviço.

5.2.3 Definições de SOA

O termo "Service-Oriented Architecture" (SOA) ou Arquitetura Orientada a Serviços expressa um conceito no qual aplicativos ou rotinas são disponibilizadas como serviços em uma rede de computadores (Internet ou Intranets) de forma independente e se comunicando através de padrões abertos. A maior parte das implementações de SOA se utilizam de Web services (SOAP , REST e WSDL). Entretanto, uma implementação de SOA pode se utilizar de qualquer tecnologia padronizada baseada em web.

O SOA coloca a prestação de serviço como eixo de todo o negócio, dando destaque à gestão de serviços e ao cliente.

Serviço - É uma função independente, sem estado (stateless) que aceita uma ou mais requisições e devolve uma ou mais respostas através de uma interface padronizada e bem definida. Serviços podem também realizar partes discretas de um processo tal como editar ou processar uma transação. Serviços não devem depender do estado de outras funções ou processos. A tecnologia utilizada para prover o serviço, tal como uma linguagem de programação, não pode fazer parte da definição do serviço.

Orquestração - Processo de sequenciar serviços e prover uma lógica adicional para processar dados. Não inclui uma representação de dados.

Stateless - Não depende de nenhuma condição pré-existente. Os serviços não devem depender de condições de outros serviços. Eles recebem todas as informações necessárias para prover uma resposta consistente. O objetivo de buscar a característica de stateless dos serviços é possibilitar que o consumidor do serviço possa sequenciá-lo, ou seja, orquestrá-los em vários fluxos (algumas vezes chamados de pipelines) para executar a lógica de uma aplicação.

Provedor - O recurso que executa o serviço em resposta a uma requisição de um consumidor.

Consumidor - É quem consome ou pede o resultado de um serviço fornecido por um provedor.

Descoberta - SOA se baseia na capacidade de identificar serviços e suas características. Conseqüentemente, esta arquitetura depende de um diretório que descreva quais os serviços disponíveis dentro de um domínio.

Binding - A relação entre os serviços do provedor e do consumidor deve ser idealmente dinâmica; ela é estabelecida em tempo de execução através 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 implementação ou de plataforma e pode ser descrito, publicado e invocado sobre uma rede por meio de mensagens padrão XML. As mensagens XML são transportadas usando protocolos padrões da Internet. Com web service é possível realizar a integração entre sistemas desenvolvidos em diferentes linguagens e plataforma, e disponibilizar serviços interativos na Web. é uma tecnologia de padrão aberto e padronizada pelo W3C.

TI para concursos

60

A arquitetura do Web Service é constituída por três componentes básicos:

o servidor de registro (broker server ou service registry) o provedor de serviços (service provider) o solicitante de serviços (service requestor). As interações entre esses componentes são de

busca, publicação e interação de operações.

Na operação de publicação o provedor publica a descrição do serviço de tal forma que um solicitante possa localizá-la. Na operação de busca o solicitante obtém a descrição do serviço diretamente ou consulta o servidor de registro procurando pelo tipo de serviço desejado. Essa operação pode ser executada em duas fases distintas: desenvolvimento ou execução. Na operação de interação o solicitante chama ou inicia uma interação com o provedor, em tempo de execução, utilizando os detalhes contidos na descrição do serviço para localizar, contactar e chamar o serviço.

O provedor de serviços representa a plataforma que hospeda o web service permitindo que os clientes acessem o serviço. O provedor de serviços fornece o serviço e é responsável por publicar a descrição do serviço que provê. O solicitante de serviços é a aplicação que está procurando, invocando uma interação com o web service, ou seja, requisita a execução de um serviço. O solicitante de serviço pode ser uma pessoa acessando por meio do browser ou uma aplicação realizando uma invocação aos métodos descritos na interface do web service. O servidor de registro é um repositório central que contém a descrição (informação) de um web service, e é por meio do servidor de registro que essas descrições são publicadas e disponibilizadas para localização.

Ilustração 10 Componentes básicos da arquitetura do Web Service

Os clientes buscam por serviços no servidor de registro e recuperam informações referentes à interface de comunicação para os web service durante a fase de desenvolvimento ou durante a execução do cliente, denominadas interação estática (static bind) e interação dinâmica (dinamic bind), respectivamente. Na interação estática, o cliente recupera a assinatura do serviço, necessária à codificação. Na interação dinâmica, o cliente recupera os valores de parâmetros e a localização do serviço.

O ciclo de vida de um web service compreende quatro estados distintos:

Publicação processo, opcional, por meio do qual o fornecedor do web services dá a conhecer a existência do seu serviço, efetuando o registro do mesmo no repositório do web service;

Descoberta processo, opcional, por meio do qual uma aplicação cliente toma conhecimento da existência do web services pretendido pesquisando num repositório UDDI;

Descrição processo pelo qual o web service expõe a sua API (documento WSDL). Desta maneira a aplicação cliente tem acesso a toda a interface do web service, onde encontram descritas todas as funcionalidades por ele disponibilizadas;

Invocação (Mensagens) processo pelo qual o cliente e o servidor interagem, por meio do envio de mensagens;

O fornecedor constrói o serviço:

Utilizando a linguagem de programação que entender; Em seguida, especifica a interface/assinatura do serviço que definiu em WSDL; Após a conclusão dos dois primeiros passos, o fornecedor registra o serviço no UDDI; O utilizador (aplicação cliente) pesquisa num repositório UDDI e encontra o serviço; A aplicação cliente estabelece a ligação com o web service e estabelece um diálogo com este, via

mensagens SOAP.

TI para concursos

61

Ilustração 11 Ciclo de vida do web service

A interação entre os web services se dá sob vários protocolos abertos, em diferentes níveis de abstração. Os protocolos utilizados para realizar a comunicação são o: UDDI (Universal Description Discovery and Integration), WSDL (Web Services Description Language), XML, SOAP (Simple Object Access Protocol) e o HTTP.

Ilustração 12 Protocolos de comunicação de Web services

As mensagens trocadas são formatadas no protocolo SOAP, o que permite a interoperabilidade entre diferentes plataformas, em um processo denominado serialização XML. Porém, antes que as mensagens SOAP sejam trocadas, suas características são explicitadas por meio de documentos WSDL, que descrevem quais dados estarão sendo trocados, e como estes dados estarão organizados nas mensagens SOAP. Adicionalmente, os serviços dos web services podem ser publicados através de UDDI, que é um formato utilizado para seu armazenamento em repositórios disponíveis 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 não bloqueiam a porta utilizada pelo protocolo HTTP, não existem grandes restrições para o uso deste tipo de aplicação em redes de longa distância.

Um serviço pode ser chamado de forma síncrona, o que significa que quem chamou a função deve esperar o retorno antes de prosseguir. Esta é a maneira mais comum de chamar qualquer função. Em uma chamada assíncrona, não esperamos que a função chamada retorne antes de continuar, mantendo mais de uma "linha de execução" no código. Esta maneira não é muito usada, pois é mais complexa e, na maioria dos casos, ou a função retorna rapidamente ou, mesmo que demore, não temos o que fazer antes da função retornar. No entanto, em uma chamada a WebService, é comum que a sua chamada demore um pouco e também tenhamos o que fazer antes de um WebService voltar, por exemplo, chamar outro WebService.

Pode-se definir, resumidamente, o web service como sendo um serviço 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 disseminação no uso de web services incentivou o mercado a oferecer uma grande variedade de ferramentas e aplicações para prover suporte a essa tecnologia. Atualmente, as principais plataformas para web services são: Sun Microsystems, IBM, BEA, Apache, Systinet e Microsoft.

5.2.5 SOAP

Simple Object Access Protocol é um protocolo leve para troca de informações em um ambiente descentralizado e distribuído que permite comunicação entre aplicações de forma simples e completamente independente de sistema operacional, linguagem de programação ou plataforma. É o protocolo de comunicação para os Web Services.

A comunicação é realizada por meio de trocas de mensagens, transmitidas em formato XML, incluindo os parâmetros usados nas chamadas, bem como os dados de resultados. Também pode ser utilizado para invocar, publicar e localizar web services no registro UDDI.

Parte da sua especificação é composta por um conjunto de regras de como utilizar o XML para representar os dados. Outra parte define o formato de mensagens, convenções para

Ilustração 13 Estrutura SOAP

TI para concursos

62

representar as chamadas de procedimento remoto (RPC – Remote Procedure Calls) utilizando o SOAP, e associações ao protocolo HTTP. O protocolo HTTP é o único protocolo padronizado pelo SOAP, mas existem algumas implementações 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 início e o fim das mensagens;

Header é um cabeçalho opcional. Ele carrega informações adicionais, como exemplo, se a mensagem deve ser processada por um nó intermediário. Quando utilizado, o Header deve ser o primeiro elemento do envelope;

Body é obrigatório e contém 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 ”nós”ao pro cessarem a mensagem;

RPCs ou chamadas remotas de procedimento são chamadas locais a métodos de objetos (ou serviços) remotos. Portanto, pode-se acessar os serviços de um objeto localizado em outro ponto da rede, através de uma chamada local a este objeto. Cada chamada ou requisição exige uma resposta.

O processo de uma chamada RPC: Antes de serem enviadas pela rede, as chamadas de RPC (emitidas pela aplicação cliente) são encapsuladas (ou serializadas) segundo o padrão SOAP. O serviço remoto, ao receber a mensagem faz o processo contrário, desencapsulando-a e extraindo as chamadas de método. A aplicação servidora então processa esta chamada, e envia uma resposta ao cliente. O processo então se repete: a resposta é também serializada e enviada pela rede. Na máquina cliente, esta resposta é desencapsulada e é repassada para a aplicação cliente.

A especificação SOAP define as seguintes informações, como necessárias em toda chamada de RPC:

A URI do objeto alvo;

O nome do método;

Os parâmetros do método (requisição ou resposta);

Uma assinatura do método opcional;

Um cabeçalho (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, operações, esquemas de codificação, o conteúdo das mensagens, onde o serviço está disponível e quais os protocolos de comunicação são usados para conversar com o serviço e entre outros neste documento. Um documento WSDL define um XML Schema para descrever um web service.

A descrição de um serviço consiste de duas partes: definição de implementação do serviço e definição da interface do serviço. A separação entre as duas camadas permite que elas sejam utilizadas separadamente.

Ilustração 14 Descrição WSDL

A parte de definição de interface do serviço descreve o web service, incluindo métodos que são invocados e parâmetros que são enviados. A parte de definição de implementação de serviços descreve como uma interface de serviço é im-plementada por um provedor: onde o serviço está instalado e como pode ser acessado. As descrições dos elementos das duas partes:

Binding descreve protocolos, formato de data, segurança e outros atributos para uma interface (portType) em particular;

Porttype informa elementos de operações do web service;

Message define entrada e saída de dados referentes a operações;

Type define tipos de dados complexos em uma mensagem;

Service contém uma coleção de elementos port com elementos binding;

TI para concursos

63

Port é a combinação de um binding com endereço de rede, fornecendo o endereço alvo para a comunicação dos serviços.

Tão logo o cliente tenha acesso à descrição do serviço a ser utilizado, a implementação do Web Service pode ser feita em qualquer linguagem de programação. Normalmente são utilizadas linguagem construídas para interação 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 obtém a descrição do serviço (através da localização do respectivo documento WSDL), e em seguida constrói a mensagem, passando os tipos de dados corretos (parâmetros, etc) de acordo com a definição encontrada no documento. As duas partes envolvidas em uma interação web service precisam ter acesso à mesma descrição WSDL para conseguirem entender uma à outra. Em seguida, a mensagem é enviada para o endereço onde o serviço está localizado, a fim de que possa ser processada. O web service, quando recebe esta mensagem valida-a conforme as informações contidas no documento WSDL. A partir de então, o serviço 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 serviço seja utilizado é necessário que o cliente consiga localizá-lo, e essa localização pode ser feita por meio do UDDI (Universal Description, Discovery and Integration), que é uma especificação técnica para descrever, descobrir e publicar web services.

Uma implementação de UDDI corresponde a um registro web service, que provê um mecanismo para busca e publicação de web services. Um registro UDDI contém informações categorizadas sobre os serviços e as funcionalidades que eles oferecem, e permite a associação desses serviços com suas informações técnicas, geralmente definidas usando WSDL.

O UDDI possui um componente central chamado UDDI Project, que ma-nipula um registro global e público chamado business registry. A informação oferecida pelo bussines registry consiste de três componentes: white pages, yel-low pages e green pages.

A informação fornecida por um registro UDDI pode ser comparada à uma lista telefônica. As páginas brancas (white pages), fornecem informações tais como nome da organização, contato e identificadores. As páginas amarelas (yellow pages) são compostas por um índice de serviços e produtos e as páginas verdes (green pages) contém informações a respeito de transações, descrições de serviço e invocação de aplicações.

As informações contidas em arquivos de descrição de serviço (WSDL) completam aquelas que estão no registro. No entanto, UDDI não fornece suporte a vários tipos de descrição de serviço, mas não suporta a criação de descrições WSDL de forma direta.

Uma descrição WSDL completa consiste da combinação dos documentos de interface e de implementação de serviço. A primeira é publicada no registro UDDI como businessservice e a segunda como tmodel.

5.2.8 Segurança

A segurança no envio de mensagens SOAP é um tópico importante. Em um nível mais baixo, mensagens SOAP podem ser trocadas pela rede utilizando HTTPS ao invés de HTTP. Como HTTPS utiliza SSL no seu transporte, fica garantida a proteção contra possíveis intervenções. Além disso, o cliente e servidor podem verificar cada um suas respectivas identidades.

Embora HTTPS resolva o problema de proteção das mensagens contra possíveis invasores, este não ajuda muito quando se necessita da segurança necessária para a autenticação de usuários de web services específicos. Estes serviços irão fornecer algum tipo de combinação de usuário/senha durante a fase inicial de registro no serviço e então esta será utilizada para acessos futuros. Não há ainda um padrão de autenticação para Web services, mas pode utilizar os firewalls, VPNs, NTFS, produtos de single-in para oferecer a autenticação e autorização de usuários.

TI para concursos

64

5.3 Exercícios

99. (ICMS-SP 2009) Uma vantagem que o Web Service oferece I. em relação à empresa que desenvolve uma DLL é que não 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", não precisando pedir autorização 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. (ICMS-SP 2009) Para uma Web Service síncrona, quem chamou a função 100

(a) deve esperar o retorno para prosseguir e, para uma Web Service assíncrona, não precisa esperar o

retorno, podendo manter mais uma linha de execução no código.xx

(b) deve esperar o retorno para prosseguir e, para uma Web Service assíncrona, não precisa esperar o

retorno, não podendo manter mais uma linha de execução no código. (c) não precisa esperar o retorno, podendo manter mais uma linha de execução no código e, para uma Web

Service assíncrona, deve esperar o retorno para prosseguir. (d) não precisa esperar o retorno, não podendo manter mais uma linha de execução no código e, para uma

Web Service assíncrona, deve esperar o retorno para prosseguir. (e) não precisa esperar o retorno, tal qual para uma Web Service assíncrona, porém, para a forma síncrona

pode manter mais uma linha de execução no código e para a forma assíncrona não pode.

101. (FCC TRT 2012) Segundo o Web Services for Remote Portlets Specification v2.0 (WSRP), em um fluxo típico de interação entre os atores, a fase que deve ocorrer primeiro, na ordem cronológica, é aquela em que

101

(a) se estabelece uma relação entre o consumidor e o usuário final. (b) o consumidor aprende as capacidades totais e serviços do produtor. (c) se estabelece a relação entre o consumidor e o produtor.

xx

(d) páginas agregadas são produzidas pelo produtor. (e) uma página é requisitada pelo consumidor.

102. (ICMS-SP 2009) A Service-Oriented Architecture – SOA trata-se de I. um conjunto de produtos para implementar aplicativos dinâmicos e ágeis, do tipo loosely couple. II. uma meta a ser alcançada, ou seja, disponibilizar uma metodologia de implementação que usa padrões e protocolos de linguagem específicos para execução de aplicativos. III. soluções que não requerem uma renovação completa de tecnologia e de processo de negócios, que devem ser incrementais e baseadas nos investimentos atuais. IV. uma abordagem de design de sistemas que orientam como os recursos do TI serão integrados e quais serviços serão 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 negócios quanto em tecnologia da informação, sendo que o SOA com foco em negócios normalmente inclui

103

(a) pessoas, processo e conectividade. (b) pessoas, processos e informações.

xx

(c) reusabilidade, pessoas e processos. (d) conectividade, processos e informações. (e) conectividade, reusabilidade e informações.

104. (ICMS-SP 2009) As ferramentas de modelagem de análise, que utilizam a notação UML, fornecem capacidade de desenvolver modelos baseados em

104

(a) cenários, fluxos e dados. (b) cenários, classes e dados. (c) cenários, classes e objetos.

xx

(d) classes, fluxos e objetos. (e) classes, fluxos e dados.

105. (TRF 2007) No âmbito dos Web Services, as chamadas de RPC - emitidas pela aplicação cliente são105

(a) convertidas na linguagem Unique Resource Identifier, quando da entrega ao protocolo IP. (b) espacializadas pela Cascade Style Sheet, tão logo recebidas pelo Server. (c) encapsuladas segundo o padrão SOAP, antes de serem enviadas pela rede.

xx

(d) convertidas para o padrão WSDL, no retorno do Server. (e) adaptadas à eXtended Style Language, quando formatadas pela DTD/DOM.

TI para concursos

65

106. Considere as seguintes assertivas sobre uma arquitetura orientada a serviços (SOA): I. SOA é apenas uma implementação de Serviços Web, possuindo ambas as mesmas características. II. As mensagens são o principal meio de comunicação entre os provedores e os consumidores de serviços. III. SOA não prescreve como projetar ou construir a implementação do serviço. IV. Quando os serviços são disponibilizados na web, eles são identificados por uma URI. As assertivas corretas são:

106

(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 número 1 e símbolo 1..* que aparecem ao lado das classes Nota Fiscal e Itens se referem à restrição de

107

(a) herança. (b) agregação. (c) identidade. (d) Multiplicidade.

xx

(e) polimorfismo.

108. (FCC – TRT – SP/2008 - Analista) Na UML, a multiplicidade 108

(a) é aplicada aos atributos, somente. (b) aplicada a uma classe é o número de instâncias que esta pode ter.

xx

(c) indica a quantidade de atributos herdados por uma classe-filha em uma hierarquia de classes. (d) aplicada nas associações entre classes indica o número de atributos comuns às classes envolvidas. (e) aplicada a uma classe concreta é o número de operações que esta pode ter.

109. Dos diagramas definidos na UML 2.0, é aplicado na modelagem do comportamento de uma interface, classe ou colaboração, o Diagrama de

109

(a) Componente. (b) Objeto. (c) Estrutura Composta. (d) Pacote. (e) Estado de Máquina.

xx

110. (FCC TRT 2012) Considere o seguinte diagrama em UML:

Uma representação válida deste diagrama é obtida substituindo-se as classes representadas pelas letras A, B, C, D e E, respectivamente, por

110

(a) Desenho, Cor, Tipo, Azul, Retângulo. (b) Computador, Notebook, Desktop, Impressora, Monitor. (c) Pedido, Compra, Venda, Item, Cliente.

xx

(d) Livro, Índice, Capa, Romance, Aventura. (e) Internet, Navegadores, Correio Eletrônico, Firefox, Outlook.

111. Em um diagrama de Caso de Uso são admitidos os relacionamentos 111

(a) dependência, somente. (b) dependência e generalização, somente. (c) dependência, generalização e associação.

xx

(d) associação, somente. (e) dependência e associação, somente.

TI para concursos

66

112. Em um Caso de Uso, um relacionamento de inclusão é a estereotipação 112

(a) dos Casos de Uso aos quais se relaciona. (b) de uma Generalização. (c) de uma Extensão. (d) de uma Agregação. (e) de um relacionamento de dependência.

xx

113. No diagrama de casos de uso da UML, o relacionamento de generalização acontece entre 113

(a) atores, somente. (b) casos de uso, somente. (c) casos de uso e entre atores.

xx

(d) casos de uso e atores, somente. (e) casos de uso incluídos e estendidos, somente.

114. Um diagrama de objetos 114

(a) tem a mesma função que um diagrama de atividades diferenciando deste apenas na representação

gráfica. (b) capta um conjunto de abstrações como um grupo de interesse e em tal contexto expõe sua semântica e

seus relacionamentos com outras abstrações 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 seqüência de execução de atividades entre objetos relacionados, no tempo, e a duração 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 operação 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 representação gráfica de um diagrama de seqüências da UML é baseada em I. uma dimensão horizontal que representa as mensagens trocadas no decorrer de um tempo de vida. II. uma dimensão vertical que representa os objetos participantes das interações. III. mensagens que correspondem a chamadas de serviços ou de operações dos objetos. IV. objetos representados por retângulos 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. (d) III e IV, apenas.

xx

(e) I e II, apenas.

117. Um cubo, graficamente na UML, é um elemento físico existente em tempo de execução que representa um recurso computacional com pelo menos alguma memória, e, freqüentemente, com capacidade de processamento. Trata-se de

117

(a) pacote. (b) nó.

xx

(c) interface. (d) objeto. (e) nota.

118. Na UML um nó é um elemento físico que existe em tempo de execução e representa um recurso computacional. Graficamente, ele é representado por

118

(a) um losango. (b) um cubo.

xx

(c) um quadrado. (d) uma seta vasada (triângulo). (e) uma elipse.

TI para concursos

67

119. (TRT FCC 2012) Sobre o diagrama de classe da UML é correto afirmar:119

(a) Quando se utiliza diagramas de classe deve-se focar exclusivamente na estrutura do software e ignorar

seu comportamento. (b) Dependência com classes não são adequadas para ilustrar um relacionamento transitório, como quando

um objeto é passado para outro como parâmetro. (c) A UML permite representar dependência apenas de classes. Utilizam-se dependências quando se deseja

mostrar que as mudanças em uma classe não afetam a outra classe. (d) Suporta quatro abreviações de visibilidade: + (público), − (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 identificação do documento XML, como uma mensagem SOAP, está contida no elemento da estrutura SOAP denominado

120

(a) root. (b) body. (c) envelope.

xx

(d) fault. (e) header.

121. NÃO é uma informação requerida para invocar um serviço de Web e encapsulada pelo WSDL na forma de um documento XML:

121

(a) O local do serviço. (b) As operações que o serviço apoia. (c) Os parâmetros que o serviço espera. (d) Os detalhes das mensagens do serviço. (e) Os meios para publicar e localizar o serviço.

xx

TI para concursos

68

6 Gerência de Requisitos de Software

A engenharia de requisitos29

é um processo que engloba todas as atividades que contribuem para a produção de um documento de requisitos e sua manutenção ao longo do tempo.

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

Identificação.

Análise e negociação.

Especificação e documentação.

Validação.

A gestão dos requisitos faz parte deste processo, se incluirmos a fase de manutenção, sendo que as alterações podem ser causadas pelos mais diversos fatores desde inovações tecnológicas a mudanças na natureza do negócio.

O gerenciamento de requisitos é um modelo sistemático para encontrar, documentar, organizar e rastrear os requisitos variáveis de um sistema.

30

A implementação de boas práticas de gerência de requisitos de software constitui uma das prioridades na implantação de melhoria do processo de software.

O principal risco, que atinge 80% dos projetos de software, é o da Evolução de Requisitos. Os indicadores de desempenho são formas de representação quantificáveis de características 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 condição ou uma capacidade com a qual o sistema deve estar de acordo".

31

Os requisitos expressam as características e restrições do produto de software do ponto de vista de satisfação das necessidades do usuário. Em geral, independem da tecnologia empregada na construção da solução, sendo uma das partes mais críticas e propensas a erros no desenvolvimento de software

Os requisitos do utilizador destinam-se aos vários níveis hierárquicos da organização e são descritos usando apenas linguagem natural, formulários e diagramas muito simples. Neste nível de especificação, surgem algumas dificuldades:

Ambiguidade: torna-se difícil descrever os requisitos de uma forma inequívoca sem tornar a sua descrição muito longa ou de difícil compreensão.

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

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

Algumas considerações:

Usar o mesmo formato em todos os requisitos para evitar omissões e facilitar a verificação dos requisitos.

Distinguir claramente, através do uso de expressões, entre comportamentos esperados "O sistema permitirá criar (...)" ou desejáveis "Deverá ser possível criar (...)". É importante deixar claro o que o sistema tem de fazer e sugestões de como o deve fazer e, acima de tudo, usar este tipo de expressões de forma consistente ao longo de todo o documento.

Usar formatação de texto para salientar determinados aspectos do documento (negrito, sublinhado, itálico).

Evitar usar termos demasiado técnicos ou fora do âmbito do sistema, identificando e definindo de uma forma clara quando for absolutamente necessário usá-los.

Os requisitos do sistema têm um carácter mais técnico, consistindo numa descrição detalhada dos requisitos do utilizador recorrendo ao uso de linguagens estruturadas e notações gráficas. Estes requisitos destinam-se aos utilizadores do sistema, às equipes de especificação de arquitetura do sistema e de desenvolvimento.

O uso de linguagem natural levanta problemas:

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

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

TI para concursos

69

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

6.1.1 Levantamento de requisitos

Sommerville (2003) propõe um processo genérico de levantamento e análise que contém as seguintes atividades:

32

Compreensão do domínio: Os analistas devem desenvolver sua compreensão do domínio da aplicação;

Coleta de requisitos: É o processo de interagir com os stakeholders do sistema para descobrir seus requisitos. A compreensão do domínio se desenvolve mais durante essa atividade; Elicitação é o nome dado à qualquer técnica de obtenção de dados junto aos usuários

detententores das informações, principalmente para a construção de um sistema ou um produto ou, ainda para melhorar um processo de trabalho. Algumas técnicas são: Entrevistas Documentos do sistema existente Análise do domínio do problema Estudos do mercado

Classificação: Essa atividade considera o conjunto não estruturado dos requisitos e os organiza em grupos coerentes;

Resolução de conflitos: Quando múltiplos stakeholders estão envolvidos, os requisitos apresentarão conflitos. Essa atividade tem por objetivo solucionar esses conflitos;

Definição das prioridades: Em qualquer conjunto de requisitos, alguns serão mais importantes do que outros. Esse estágio envolve interação com os stakeholders para a definição dos requisitos mais importantes;

Verificação de requisitos: Os requisitos são verificados para descobrir se estão completos e consistentes e se estão em concordância com o que os stakeholders desejam do sistema.

O levantamento e análise de requisitos é um processo iterativo, com uma contínua validação de uma atividade para outra.

Ilustração 15 Processo de levantamento e análise de requisitos

6.1.1.1 Joint Application Development (JAD)33

Técnica para levantamento de requisitos desenvolvido pela IBM nos anos 70, que organiza reuniões que discutem o processo de levantamento de requisitos no gerenciamento do projeto.

Os princípios básicos:

Ninguém é melhor para explicar um determinado processo do que as pessoas que trabalham com ele.

Os profissionais de TI são os mais preparados para identificar as possibilidades que a tecnologia oferece, assim como suas limitações.

Sistemas de informação e processos do negócio não são isolados. Os melhores sistemas de informação são resultado do trabalho conjunto de todas as pessoas

envolvidas: profissionais de TI, usuários, gestores, analistas de negócio etc.

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

TI para concursos

70

O JAD orienta a condução das sessões a partir de alguns papéis.

O facilitador é neutro: ele não opina nos assuntos discutidos, mas pode direcionar os assuntos conforme o planejamento inicial. Cabe a ele também evitar que determinados indivíduos dominem reunião.

O anotador está dedicado a registrar os assuntos discutidos e decisões tomadas, liberando assim os outros membros a participar das discussões sem perder tempo com anotações.

O gerenciador de tempo vai evitar que determinadas discussões demorem demasiadamente, evitando assim que outros assuntos não sejam abordados.

O quadro do projeto serve para lembrar os assuntos em foco e os que estão fora do foco, impedindo assim discussões infrutíferas.

6.1.1.2 Estudo etnográfico34

Estudo etnográfico é uma técnica, proveniente das disciplinas de Antropologia Social, que consiste no estudo de um objeto por vivência direta da realidade onde este se insere, permitindo analisar a componente social das tarefas desempenhadas numa dada organização 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 tácitas de trabalhar:

modo como realmente as pessoas executam as suas funções que muitas vezes difere da forma como as definições dos processos sugerem que elas devem fazer;

cooperação e conhecimento das atividades de outras pessoas.

Para isso, um sociólogo, externo à organização em causa, passa algum tempo observando e analisando as atividades das pessoas sem que estas necessitem explicar o seu trabalho (interações implícitas), extraindo daí conclusões importantes acerca de fatores sociais e organizacionais. Desta forma, é necessário assumir que as pessoas em estudo são competentes na realização do seu trabalho.

Estes estudos têm mostrado que o trabalho das pessoas é, normalmente, mais rico e complexo do que o descrito pelas definições dos processos e pelos modelos dos sistemas.

O principal problema da aplicação deste método é fruto da dificuldade na generalização dos resultados. É um método qualitativo que se insere na corrente filosófica do Interpretivismo.

6.2 Requisitos Funcionais e Não-Funcionais

Os requisitos funcionais especificam ações que um sistema deve ser capaz de executar, sem levar em consideração restrições físicas. Geralmente, isso é melhor descrito em um modelo de casos de uso. Os requisitos funcionais especificam o comportamento de entrada e saída de um sistema. É aquilo que o utilizador espera que o sistema ofereça, atendendo aos propósitos para qual o sistema será desenvolvido.

conjuntos de recursos habilidades segurança

Requisitos não-funcionais são restrições nas quais o sistema deve operar ou propriedades emergentes do sistema. Vários requisitos não são funcionais e descrevem apenas atributos ou ambiente do sistema. Alguns deles podem ser capturados em casos de uso, outros em Especificações Suplementares.

Usabilidade fatores humanos estética consistência na interface do usuário ajuda online e contextual assistentes e agentes documentação do usuário materiais de treinamento

Confiabilidade freqüência e gravidade de falha possibilidade de recuperação possibilidade de previsão exatidão tempo médio entre falhas (MTBF)

Desempenho velocidade eficiência disponibilidade exatidão taxa de transferência

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

TI para concursos

71

tempo de resposta tempo de recuperação uso de recurso

Suportabilidade possibilidade de teste extensibilidade adaptabilidade manutenibilidade compatibilidade possibilidade de configuração possibilidade de serviço possibilidade de instalação possibilidade de localização (internacionalização)

Restrições de design especifica ou restringe o design de um sistema

Requisitos de implementação padrões obrigatórios linguagens de implementação políticas de integridade de banco de dados limites de recursos ambientes operacionais

Requisitos de interface um item externo com o qual o sistema deve interagir restrições de formatos, tempos ou outros fatores usados por tal interação

Requisitos físicos material forma tamanho peso

6.3 Exercícios

122. (ICMS-SP 2009) Quanto aos requisitos de software, considere: I. É importante que se estabeleçam práticas para encontrar, documentar, organizar e rastrear os requisitos variáveis de um sistema. II. Etnografia (observação e análise dos fluxos de trabalho) e sessões de JAD são práticas que podem ser aplicadas na elicitação. III. Elicitar significa descobrir os requisitos de um sistema por meio de entrevistas, de documentos do sistema existente, de análise do domínio 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 características e restrições do produto de software do ponto de vista de satisfação das necessidades do usuário. Em geral, independem da tecnologia empregada na construção da solução, sendo uma das partes mais críticas e propensas a erros no desenvolvimento de software”. Quanto aos requisitos de software, a descrição acima está

123

(a) incoerente ao afirmar que expressam restrições. (b) incoerente ao afirmar que independem da tecnologia. (c) incoerente ao afirmar que expressam características do ponto de vista de satisfação das necessidades do

usuário. (d) totalmente coerente.

xx

(e) incoerente ao afirmar que os requisitos são uma das partes mais críticas e propensas a erros.

124. (FCC 2008 - TRT) A frase "o tempo médio de resposta do sistema não deve ultrapassar 5 segundos" indica 124

(a) uma funcionalidade do sistema. (b) uma atividade do cronograma do sistema. (c) uma função executada pelo usuário do sistema. (d) uma possível definição de requisito não funcional.

xx

(e) um ponto de controle nas etapas de desenvolvimento do sistema.

125. (FCC - 2008 – TCE AL) Em um sistema cujo objetivo principal seja emitir guias de cobrança de impostos e fazer o controle de contribuintes, NÃO é um produto inerente ao trabalho de levantamento de requisitos

125

(a) uma descrição da relação possível entre as linhas de código com os pontos de função.xx

(b) uma declaração da necessidade e da viabilidade. (c) uma descrição do ambiente técnico do sistema. (d) uma afirmação limitada do escopo do sistema. (e) um conjunto de cenários que fornecem informações sobre o uso do sistema sob diferentes condições de

operação.

TI para concursos

72

126. É correto afirmar que 126

(a) um relatório não é um artefato de sistema. (b) segurança não é um requisito não funcional de sistema. (c) um executável é um artefato de sistema.

xx

(d) os atributos de uma classe UML são especificações dos seus métodos. (e) confiabilidade é um requisito funcional de sistema.

(ICMS-SP 2009) Instruções: Para responder às duas próximas questões, considere:

“É necessário que o software calcule os salários dos diaristas e mensalistas e emita relatórios mensais sumariados por tipo de salário. Entretanto, a base de dados deve estar protegida e com acesso restrito aos usuários autorizados. De qualquer forma, o tempo de resposta das consultas não deve superar os quinze segundos, pois inviabilizaria todo o investimento nesse sistema. Devo lembrar que os relatórios individuais dos departamentos, nos quais constam os salários dos funcionários, devem ser emitidos quinzenalmente em razão dos adiantamentos e vales que recebem. É fundamental que o software seja operacionalizado usando código aberto. Necessito, ainda, forte gerenciamento de risco, prazo e custo, porque a entrega do produto final não pode ultrapassar o prazo de oito meses a contar da data de início do projeto. A frase acima, expressa por um funcionário do cliente, aborda alguns requisitos de software especificados para um sistema de gestão de pessoal.

127. (ICMS-SP 2009) No texto, são requisitos não-funcionais:127

(a) não pode ultrapassar o prazo de oito meses e necessário que o software calcule os salários dos diaristas

e mensalistas. (b) os relatórios individuais dos departamentos, nos quais constam os salários dos funcionários, devem ser

emitidos quinzenalmente e em razão dos adiantamentos e vales que recebem. (c) É fundamental que o software seja operacionalizado usando código aberto e os relatórios individuais dos

departamentos, nos quais constam os salários dos funcionários, devem ser emitidos quinzenalmente. (d) tempo de resposta das consultas não deve superar os quinze segundos e entrega do produto final não

pode ultrapassar o prazo de oito meses.xx

(e) pois inviabilizaria todo o investimento nesse sistema e em razão dos adiantamentos e vales que recebem.

128. (ICMS-SP 2009) No texto, são requisitos funcionais:128

(a) calcule os salários dos diaristas e mensalistas e os relatórios individuais dos departamentos, nos quais

constam os salários dos funcionários, 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 usuários autorizados. (c) é fundamental que o software seja operacionalizado usando código aberto e emita relatórios mensais

sumariados por tipo de salário. (d) emita relatórios mensais sumariados por tipo de salário e necessito, ainda, forte gerenciamento de risco,

prazo e custo. (e) a base de dados deve estar protegida e com acesso restrito aos usuários autorizados e entrega do

produto final não pode ultrapassar o prazo de oito meses.

129. (ICMS-SP 2009) O processo de confirmação que um software vai ao encontro das especificações de software se trata de um conceito-chave de qualidade denominado

129

(a) Validação. (b) Verificação.

xx

(c) Precisão. (d) Acurácia. (e) Confiabilidade.

6.4 Técnicas de avaliação de software

Em função de seus requisitos funcionais e não funcionais, um grande desafio em desenvolvimento de sistemas é a estimativa do tamanho e do esforço 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 esforço e custo de projeto, e a Análise de Ponto de Função, que estima tamanho relativo apenas de requisitos funcionais.

6.4.1 Método COCOMO

O método 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 três projetos. Os programas examinaram de 2.000 a 100.000 linhas de código em linguagens de programação 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 necessários para cada etapa do ciclo de vida do produto.

COCOMO consiste em três implementações:

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

TI para concursos

73

Básico - É um modelo estático que calcula o esforço de desenvolvimento de software e seu custo, em função do tamanho de linhas de códigos desenvolvidas. Cocomo básico é bom por ser rápido em estimativas e custos de software, mas sua exatidão é limitada por causa de sua falta de fatores para explicar as diferenças entre ferramentas, qualidade de pessoal e experiência, uso de ferramentas modernas e técnicas, e outros atributos de projeto que influenciam nos custos de software.

Intermediário - Calcula o esforço de desenvolvimento de software em função do tamanho do programa, que inclui custo, avaliação subjetiva do produto, hardware, pessoal e atributos de projeto. O método intermediário é uma extensão do método básico, mas com mais categorias de controle como: atributos do produto, atributos de hardware, atributos pessoais, atributos do projeto.

Avançado - São incorporadas características da versão intermediária com uma avaliação de impacto de custo em cada passo de todo o projeto.

6.4.2 Análise por Pontos de Função

Análise de Pontos de Função (APF) é uma técnica para a medição de projetos de desenvolvimento de software, visando estabelecer uma medida de tamanho, em Pontos de Função (PF), considerando a funcionalidade implementada, sob o ponto de vista do usuário. A medida é independente da linguagem de programação ou da tecnologia que será usada para implementação.

36

Seus objetivos são:

medir a funcionalidade solicitada pelo usuário, antes do projeto de software, de forma a estimar seu tamanho

medir projetos de desenvolvimento de software, independentemente da tecnologia utilizada na implementação, de forma a acompanhar sua evolução

medir a funcionalidade recebida pelo usuário, após o projeto de software, de forma verificar seu tamanho

As organizações podem aplicar a Análise de Pontos por Função como:

uma ferramenta para determinar o tamanho de pacotes de software adquiridos, através da contagem de todos os Pontos por Função incluídos no pacote

uma ferramenta para apoiar a análise de produtividade um fator de normalização para comparação de software

O procedimento para contagem de PFs compreende:37

Determinar o Tipo de Contagem projeto de desenvolvimento aplicações instaladas projetos de melhoria

Identificar o Escopo de Contagem e Fronteira da Aplicação definir a parte do sistema (funcionalidades) a ser contada

Determinar os PFs não ajustados Contagem das Funções dados - arquivos lógicos internos (ALI) e arquivos de interface externa (AIE) transacionais – entradas (EE), saídas (SE) e consultas (CE) externas

Determinar o Fator de Ajuste o fator de ajuste é baseado em quatorze características gerais de sistemas, que avaliam a funcionalidade

geral da aplicação que está sendo contada, e seus níveis de influência. O nível de influência de uma característica é determinado com base em uma escala de 0 (nenhuma influência) a 5 (forte influência).

Calcular os PFs Ajustados

6.4.2.1 Contagem das Funções de Dados

O primeiro passo para a contagem das funções de dados consiste em identificar arquivos lógicos internos (ALIs) e arquivos de interface externa (AIEs). Cada uma dessas funções de dados deve ser classificada segundo sua complexidade funcional. Essa complexidade é definida com base nos conceitos de registros lógicos e itens de dados.

Registros Lógicos são subconjuntos de dados dentro de um ALI/AIE, que foram reconhecidos pelo usuário. Se o usuário não reconhecer subconjuntos de dados em um ALI/AIE, então se deve contar o ALI/AIE como um registro lógico.

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

TI para concursos

74

Um Item de Dados, por sua vez, é um campo reconhecido pelo usuário como único e não repetido. Vale destacar que só devem ser contados os itens de dados utilizados pela aplicação em contagem.

Contando-se os registros lógicos e os itens de dados de um ALI/AIE, pode-se chegar à sua complexidade, utilizando a tabela 1:

Número de Registros Lógicos

Número de Itens de Dados Referenciados

1 a 19 20 a 50 51 ou mais

Apenas 1 Simples Simples Média

2 a 5 Simples Média Complexa

6 ou mais Média Complexa Complexa

6.4.2.2 Contagem das Funções Transacionais

De maneira análoga à contagem das funções de dados, a contagem das funções transacionais envolve a identificação de funções transacionais (entradas externas, saídas externas e consultas externas) e sua classificação de acordo com a complexidade funcional envolvida (simples, média ou complexa). A definição da complexidade funcional é feita com base no número de arquivos referenciados e dos itens de dados manipulados pela função, utilizando as tabelas 2 para entradas externas e 3 para saídas e consultas externas.

Nessas tabelas, um arquivo referenciado pode ser um ALI lido ou mantido pela função transacional, ou um AIE lido pela função transacional. Já o número de itens de dados referenciados é calculado considerando apenas os itens de dados efetivamente referenciados pela função transacional em questão.

Tabela 2 para entradas externas:

Número de arquivos referenciados

Número de Itens de Dados Referenciados

1 a 4 5 a 15 16 ou mais

0 ou 1 Simples Simples Média

2 Simples Média Complexa

3 ou mais Média Complexa Complexa

Tabela 3 para saídas e consultas externas:

Número de arquivos referenciados

Número de Itens de Dados Referenciados

1 a 5 6 a 19 20 ou mais

0 ou 1 Simples Simples Média

2 ou 3 Simples Média Complexa

4 ou mais Média Complexa Complexa

6.4.2.3 Cálculo dos Pontos de Função Não Ajustados

Uma vez contadas as funções de dados e as funções transacionais, é possível calcular os PFs não ajustados de uma aplicação. Esse cálculo é feito da seguinte forma:

1. Para cada um dos cinco tipos de função (ALI, AIE, EE, SE e CE), são computados os totais de pontos de função (NPFi), segundo a seguinte expressão:

onde

NCi,j = número funções do tipo i (i variando de 1 a 5, segundo os tipos de função 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, média e complexa).

Ci,j = valor da contribuição da complexidade j no cálculo dos pontos da função i, dado pela tabela a seguir.

TI para concursos

75

Função Complexidade

Simples Média Complexa

arquivos lógicos internos - ALI

7 10 16

arquivos de interface externa - AIE

5 7 10

entradas externas - SE 4 5 7

saídas externas - EE 3 4 6

consultas externas - CE 3 4 6

Tabela 1 Contribuição das Funções na Contagem de PFs Não Ajustados

2. O total de pontos de função não ajustados (PFNA) é dado pelo somatório dos pontos das tabelas de função:

sendo que i varia de 1 a 5, segundo os tipos de função existentes (AIL, AIE, EE, SE e CE).

6.4.2.4 Determinação do Fator de Ajuste

O fator de ajuste influencia os pontos de função não ajustados em +/- 35%, obtendo-se o número de PFs ajustados. Para se calcular o fator de ajuste, são usadas 14 características gerais dos sistemas, a saber:

Comunicação de Dados Processamento de Dados Distribuído Desempenho Utilização do Equipamento (Restrições de Recursos Computacionais) Volume de Transações Entrada de Dados On-line Eficiência do Usuário Final (Usabilidade) Atualização On-line Processamento Complexo Reusabilidade Facilidade de Implantação Facilidade Operacional (Processos Operacionais, tais como Inicialização, Cópia de Segurança,

Recuperação etc) Múltiplos Locais e Organizações do Usuário Facilidade de Mudanças (Manutenibilidade)

Para cada uma dessas 14 características deve-se atribuir um valor de 0 (nenhuma influência) a 5 (forte influência), dito grau ou nível de influência, que indica o quanto determinada característica tem influência no sistema. Os 14 graus de influência (GIs) informados são somados, resultando no nível de influência total (NIT):

Finalmente, o valor do fator de ajuste (VFA) é determinado, então, pela fórmula:

Considerando que o valor máximo do NIT é 14x5=70 e o mínimo é zero, então, o valor do VFA varia de 0,65 a 1,35.

6.4.2.5 Cálculo dos Pontos de Função Ajustados

Uma vez calculados os PF não ajustados e o fator de ajuste, é possível calcular os PFs ajustados. Esse cálculo é feito de formas diferentes para cada tipo de contagem (projeto de desenvolvimento, projeto de manutenção ou aplicações instaladas). Para projetos de desenvolvimento, o cálculo é dado por:

PF = PFNA * VFA

onde

PFNA = Número de PFs não ajustados VFA = valor do fator de ajuste

TI para concursos

76

7 Gerência de Configuração e Mudança

7.1 Conceitos de Gerência de Configuração e Mudança de software

Gerência de Configuração de Software é uma área da engenharia de software responsável por fornecer o apoio para o desenvolvimento de software. Suas principais atribuições são o controle de versão, o controle de mudança e a auditoria das configurações.

38

Conjunto de atividades projetadas para controlar as mudanças pela identificação dos produtos do trabalho que serão alterados, estabelecendo um relacionamento entre eles, definindo o mecanismo para o gerenciamento de diferentes versões destes produtos, controlando as mudanças impostas, e auditando e relatando as mudanças realizadas.

A Gerência de Configuração e Software é definida por quatro funções básicas:

Identificação dos itens de configuração Documentação Controle Auditoria das mudanças

7.1.1 Configuração de software

Configuração é o estado em que um sistema se encontra em um determinado momento. Este sistema pode ser composto de todo tipo de elementos, como peças de hardware, artefatos eletrônicos ou não (i.e. documentos em papel), etc. A Configuração de Software trata apenas dos elementos que se encontram em formato eletrônico e fazem parte dessa configuração. Isso inclui todos os arquivos fontes, todos os documentos eletrônicos, as ferramentas de software utilizadas para construir ou mesmo ler estes arquivos, o sistema operacional utilizado, as bibliotecas de software, etc.

Essa configuração varia com o tempo, pois novos arquivos são incluídos, e arquivos existentes são alterados ou removidos. O objetivo da Gerência de Configuração 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 mudança de versão, quando o sistema foi enviado para auditoria, etc). A Gerência de Configuração como um todo trata dos elementos, incluindo hardware, necessários para a manutenção apropriada do sistema. A Gerência de Configuração de Software trata especificamente dos elementos necessários a construção de sistemas de software, e em geral, controla apenas os elementos em formato computadorizado.

Em Sistemas de controle de versão as configurações específicas são geralmente identificadas pelo uso de tags ou labels (placas ou etiquetas, em inglês).

7.1.2 Item de configuração de software

Durante o desenvolvimento de software, uma grande quantidade de informações é produzida e cada um desses documentos produzidos que precisam sofrer controle de versões e de mudanças é chamado de item de configuração de software O Item de configuração é um elemento unitário que será gerenciado: um arquivo de código fonte, um documento de texto, um projeto de uma placa eletrônica, uma planta feita em papel, um CD-ROM de instalação de um sistema operacional, etc. A configuração de um sistema é basicamente a lista de todos os itens de configuração necessários para reproduzir um determinado estado de um sistema. Em geral números de versão são associados aos itens de configuração de forma a podermos identificar também a evolução destes itens.

Exemplos de itens de configuração podem ser:

Item A: CD de instalação do sistema operacional, versão 1.0

Item B: Documento de ajuda do sistema em formato eletrônico, versão 2.0

Item C: Processador de texto usado para imprimir o documento de ajuda, versão 5.0

Segundo Pressman os seguintes SCIs tornam-se alvos das técnicas de GCS e formam um conjunto de linhas básicas (Baselines):

1.Especificação do Sistema.

2.Plano de Projeto do Software.

3.Requisitos 1.Especificação dos Requisitos de Software; 2.Protótipo executável ou "em papel".

4.Manual Preliminar do Usuário.

5.Especificação de Projeto:

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

TI para concursos

77

1.Descrição do projeto de dados; 2.Descrições do projeto arquitetural; 3.Descrições do projeto modular; 4.Descrições do projeto de interfaces; 5.Descrições de objetos (no caso do uso da metodologia OO).

6.Listagem do código-fonte.

7.Teste de Software/Sistema: 1.Plano e Procedimentos de Testes; 2.Casos de teste e resultados registrados.

8.Manuais Operacionais e de Instalação.

9.Programa Executável: 1.Módulos; 2.Módulos interligados.

10.Descrição do Banco de Dados: 1.Esquema e estrutura de arquivo; 2.Conteúdo inicial.

11.Manual Feito de Acordo com o Usuário.

12.Documentos de Manutenção: 1.Relatórios de problemas de software; 2.Solicitações de manutenção; 3.Pedidos de mudança de engenharia.

13.Padrões e procedimentos para engenharia de software.

7.1.3 Controle de versões

O Controle de versão rastreia e controla todos os artefatos do projeto (código-fonte, arquivos de configuração, documentação etc.) e assim consegue coordenar o trabalho paralelo de desenvolvedores através das seguintes funcionalidades:

Mantém e disponibiliza cada versão já produzida de cada item do projeto

Possui mecanismos para gerenciar diferentes ramos de desenvolvimento, possibilitando a existência de diferentes versões ao mesmo tempo (concorrência)

Estabelece uma política de sincronização de mudanças que evita a sobreposição de mudanças

Fornece um histórico completo de alterações sobre cada item do projeto

Controle de Versão resolve diversos problemas básicos de desenvolvimento tais como uso de diferentes versões de código, sincronização do trabalho paralelo de desenvolvedores no mesmo projeto, recuperação de versões anteriores e registro do histórico de alterações.

7.1.4 Papéis

Uma das principais definições da política de Gerência de Configuração de Software são os papeis a serem desempenhados. A política não determina quais pessoas desempenharão quais papeis, cabendo isso a gerência de projeto. Alguns papeis necessários numa política são:

Gestor de configuração do projeto. Ele é o responsável por acompanhar as alterações dos itens de configurações de um determinado projeto. Em geral este papel cabe ao integrador.

Gestor de ferramentas de Gerência de configuração. Ele é o responsável pela manutenção da infraestrutura necessária para o bom funcionamento da Gerência de configuração no conjunto dos projetos da organização, 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 Configuração de Software, ou Responsável de Gerência de Configuração de Software. Ele é o responsável por aprovar e gerenciar as atividades relativas a Gerência de Configuração de Software, coordenar a equipe de Gerência de Configuração de Software e algumas vezes, coordenar o trabalho de integração de sistemas.

Auditor de Configuração de Software. Ele é o responsável pela realização das auditorias de configuração nos projetos.

Desenvolvedor. Ele é o principal usuário da Gerência de configuração de software, sendo quem produz os itens de configuração que serão gerenciados.

7.2 Solicitações de Mudança

As mudanças nos artefatos de desenvolvimento são propostas através de Solicitações de Mudança (CRs ou Change Requests), que são usadas para documentar e controlar defeitos, solicitações de melhorias e qualquer outro tipo de solicitação de mudança no produto.

TI para concursos

78

A vantagem das CRs é que elas fornecem um registro das decisões e, devido a seu processo de avaliação, garantem que os impactos das mudanças sejam entendidos no projeto.

39

A necessidade de mudança parece ser inerente aos sistemas de software existentes e em desenvolvimento. O Gerente de Controle de Mudança é responsável pela definição dos procedimentos de Gerenciamento de Solicitações de Mudança e pela manutenção de CRs, garantindo que as mudanças 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 solicitações de mudanças no sistema, inclusive defeitos e solicitações de melhoria.

As solicitações de melhoria são usadas pelo Analista de Sistemas para determinar futuros recursos a serem incluídos no produto. Serão usadas como base durante a coleta de solicitações 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 são omissões e imperfeições localizadas durante as fases iniciais do ciclo de vida e sintomas (falhas) de erros contidos em softwares maduros o suficiente para teste e operação. Os defeitos também podem incluir desvios das expectativas ou qualquer questão que precise ser controlada e resolvida.

A finalidade de um defeito é comunicar os detalhes da questão, permitindo a ação corretiva, a solução e o acompanhamento.

As seguintes pessoas usam as CRs:

O Analista de Sistemas usa as CRs identificadas como Solicitações 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 são úteis para tomar uma decisão 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 mudança proposta é fácil de ser efetuada? Quais são as possíveis ramificações provenientes dessa mudança?

Gravidade

Qual é o impacto da não implementação desta solicitação? Há alguma perda de trabalho ou de dados envolvida? Esta é uma solicitação de melhoria? É um problema secundário?

Cronograma

Quando a mudança é necessária? Ela é viável?

Impacto

Quais as conseqüências de efetuar a mudança? Quais as conseqüências de não efetuar a mudança?

Custo

Qual é a economia proveniente desta mudança? Relacionamento com Outras Mudanças Outras mudanças substituirão ou invalidarão esta ou isso depende de outras mudanças?

Teste

Há algum requisito especial de teste?

As práticas de Gerenciamento de Mudanças normalmente são institucionalizadas ou estabelecidas no início do ciclo de vida do projeto. Desse modo, as CRs, que integram o processo de mudança, podem surgir a qualquer momento durante o curso do projeto.

A principal origem de defeitos consiste nos resultados da execução dos testes — integração, sistema e desempenho. Contudo, os defeitos podem aparecer em qualquer ponto do ciclo de vida de

39 http://www.wthreex.com/rup/process/artifact/ar_crqst.htm

TI para concursos

79

desenvolvimento do software e abranger a identificação de documentação, 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 Solicitação de Mudança é realizada por uma Equipe de Revisão ou um Comitê de Controle de Mudança (CCB).

O Gerente de Controle de Mudança é responsável pela integridade do defeito, garantindo que:

Sejam exatas todas as informações que identificam e descrevem o defeito e indicam como ele foi descoberto.

O defeito seja exclusivo ou que não seja outra ocorrência de um defeito já identificado.

Os campos e os dados reais necessários para identificar, descrever e controlar defeitos com precisão são variados e dependem do sistema de controle de mudanças, das diretrizes e dos padrões implementados.

7.3 Exercícios

(ICMS-SP 2009) Instruções: Para responder às três próximas questões, considere a tabela e os dados de referência para os cálculos de pontos de função.

Pontuação por complexidade de função

Tipos Simples Médio Complexo

EE 3 4 6

SE 4 5 7

CE 3 4 6

ALI 7 10 15

AIE 5 7 10 Níveis de Influência: 0 − Nenhuma influência. 1 − Influência mínima. 2 − Influência moderada. 3 − Influência média. 4 − Influência significante. 5 − Influência forte. Características Gerais de Sistema: 1. Comunicação de Dados. 2. Processamento de Dados Distribuído (Funções Distribuídas). 3. Performance. 4. Configuração do equipamento. 5. Volume de Transações. 6. Entrada de Dados On line. 7. Interface com o usuário. 8. Atualização On line. 9. Processamento Complexo. 10. Reusabilidade. 11. Facilidade de Implantação. 12. Facilidade Operacional. 13. Múltiplos Locais. 14. Facilidade de mudanças.

130. (ICMS-SP 2009) Durante o levantamento de requisitos de um sistema, foram apuradas as seguintes informações, base para o cálculo de pontos de função:

130

Complexidade de: − Entrada: 2 complexas , 4 médias e 5 simples. − Saída: 10 médias e 3 simples. − Arquivo mantido dentro da fronteira do sistema: 1 complexo e 2 médios. Sem nenhuma influência, o resultado apurado foi (a) 133 (b) 138 (c) 140

xx

(d) 149 (e) 161

TI para concursos

80

131. (ICMS-SP 2009) Mantida a pontuação bruta obtida na questão de número 22 e considerando que as influências por características gerais do sistema foram estimadas como: − Forte em performance. − Significante em entrada de dados on line e em processamento distribuído. − Demais características sem influência. O resultado final mais aproximado, após o ajuste, foi

131

(a) 98,0 (b) 107,8 (c) 110,6 (d) 109,2

xx

(e) 116,0

132. (ICMS-SP 2009) Após um levantamento mais apurado do sistema referido, funções foram modificadas, adicionadas ou excluídas e, em razão das modificações sugeridas, chegou-se às seguintes e novas informações: Complexidade de: − Consulta: 5 complexas, 10 médias e 11 simples. − Arquivo mantido fora da fronteira do sistema: 1 complexo e 1 médio. − Entrada: 2 complexas, 4 médias e 5 simples. − Saída: 5 complexas, 10 médias e 3 simples. − Arquivo mantido dentro da fronteira do sistema: 3 complexos, 1 médio e 4 simples. As novas influências por características gerais do sistema foram estimadas como: − Forte em performance. − Significante em entrada de dados on line, em processamento distribuído, em facilidade de mudanças e em interface com o usuário. − Mínima em volume de transações. − Moderada em comunicação de dados. − Demais características sem influência. Com base nessas novas informações levantadas, o resultado final mais aproximado, após o ajuste, foi

132

(a) 263,7 (b) 298,9 (c) 300,5 (d) 305,3

xx

(e) 432,8

133. NÃO é uma das nove características em um tratamento detalhado das métricas 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 coesão.

134. O método que busca medir esforço, prazo, tamanho de equipe e custo necessário para o desenvolvimento do software, desde que se tenha a dimensão do mesmo, por meio de um modelo de estimativa de tamanho de software (Boehm) é o

134

(a) Function Point Analysis. (b) CoCoMo.

xx

(c) Work Breakdown Structure. (d) Benchmarking. (e) Flowcharting.

135. Considere 1952 pontos por função brutos e a aplicação do valor 3 a todos os fatores de ajuste. Os pontos por função ajustados são

135

(a) 1268,80. (b) 1542,08. (c) 1815,36. (d) 2088,64.

xx

(e) 2635,00.

136. Durante a medição do grau de complexidade de um sistema foram apurados 550 pontos de função brutos. Considerando que o somatório dos graus atribuídos aos fatores de ajuste foi 30, a medida final em pontos de função foi

136

(a) 520 (b) 522,5

xx

(c) 552,5 (d) 580 (e) 585,5

TI para concursos

81

8 Engenharia de Software

Engenharias da sistemas é um campo interdisciplinar da engenharia que foca no desenvolvimento e organização de sistemas artificiais complexos. As técnicas de Engenharia de Sistemas podem ser utilizadas em desenvolvimento de softwares.

Engenharia de produção é o ramo da engenharia que dedica-se à concepção, melhoria e implementação de sistemas que envolvem pessoas, materiais, informações, 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 mão-de-obra, máquinas e equipamentos, para melhorar processos, para o aumento da qualidade do produto, redução de perdas e maior produtividade.

Neste contexto, a engenharia de software aproveita diversas técnicas de engenharia de sistemas, de produto e de processos para a produção de aplicativos com maior eficiência e eficácia.

Nos anos 40, grande parte dos esforços e custos era concentrada no desenvolvimento do hardware.

À medida que a tecnologia de hardware foi sendo dominada, as preocupações se voltaram, no início dos anos 50, para o desenvolvimento dos sistemas operacionais e de linguagens de programação de alto nível, como FORTRAN e COBOL.

No início dos anos 60, com o surgimento dos sistemas operacionais com características de multiprogramação, a eficiência e utilidade dos sistemas computacionais tiveram um considerável crescimento, surgindo a necessidade de desenvolver grandes sistemas de software em substituição aos pequenos programas aplicativos utilizados até então.

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 razão 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 instruções, estruturas de dados e documentação 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 usuário é o próprio autor, a documentação é pequena ou inexistente e a preocupação com a existência de erros de execução não é um fator muito relevante, pode não haver grandes dificuldades na detecção e correção de falhas, nem preocupação como a portabilidade, a flexibilidade e a possibilidade de reutilização.

Um produto de software é destinado ao uso por pessoas outras que os seus programadores, a sua interface é importante, reforçada com uma documentação rica em informações 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 usuários não estarão de detectar e corrigir os eventuais erros de execução.

o software é concebido e desenvolvido como resultado de um trabalho de engenharia e não manufaturado no sentido clássico;

o software não se desgasta, não aumenta a possibilidade de falhas à medida que o tempo passa; a maioria dos produtos de software é concebida inteiramente sob medida, sem a utilização de

componentes pré-existentes.

Em função destas características diferenciais, o processo de desenvolvimento de software pode desembocar um conjunto de problemas, os quais terão influência direta na qualidade do produto.

O processo de desenvolvimento de software procura responder:

por que o software demora tanto para ser concluído? por que os custos de produção têm sido tão elevados? por que não é possível detectar todos os erros antes que o software seja entregue ao cliente? por que é tão difícil medir o progresso durante o processo de desenvolvimento de software?

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

TI para concursos

82

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 concepção até ficar sem uso algum.

41

Quatro fases que são delimitadas por eventos típicos em diversos ciclos de vida. Cada fase inclui um conjunto de atividades ou disciplinas que devem ser realizadas pelas partes envolvidas.

Definição Desenvolvimento Operação Retirada

8.2.1 Fase de Definição

A fase de definição do software ocorre em conjunto com outras atividades como a modelagem de processos de negócios e análise de sistemas. Nesta atividade, diversos profissionais buscam o conhecimento da situação atual e a identificação de problemas para que possam elaborar propostas de solução de sistemas computacionais que resolvam tais problemas. Dentre as propostas apresentadas, deve-se fazer um estudo de viabilidade, incluindo análise custo-benefício, para se decidir qual solução será a escolhida.

O resultado desta atividade deve incluir a decisão da aquisição ou desenvolvimento do sistema, indicando informações sobre hardware, software, pessoal, procedimentos, informação e documentação.

Caso seja decidido pelo desenvolvimento do sistema, no escopo da engenharia de software, é necessário 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 domínio que serão utilizados na fase de desenvolvimento. Os requisitos são também fundamentais para que o engenheiro possa elaborar um plano de desenvolvimento de software, indicando em detalhes os recursos necessários (humanos e materiais), bem como as estimativas de prazos e custos (cronograma e orçamento).

Não existe um consenso sobre o que caracteriza o final da fase de definição. Isto varia de acordo com o modelo de processo adotado. Em algumas propostas, a fase de definição é considerada concluída com a apresentação da proposta de desenvolvimento apenas. Outros modelos de processo, considera que o software apenas está completamente definido com a especificação de requisitos e com a elaboração 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 definição não esteja completamente concluída.

8.2.2 Fase de Desenvolvimento

A fase de desenvolvimento ou de produção do software inclui todas as atividades que tem por objetivo a construção do produto. Ela inclui principalmente o design, a implementação e a verificação e validação do software.

8.2.2.1 Design

A atividade de design compreende todo o esforço de concepção e modelagem que têm por objetivo descrever como o software será implementado. O design inclui:

Design conceitual Design da interface de usuário Design da arquitetura do software Design dos algoritmos e estruturas de dados

O design conceitual envolve a elaboração das idéias e conceitos básicos que determinam os elementos fundamentais do software em questão. Por exemplo, um software de correio eletrônico tradicional inclui os conceitos: mensagem, caixa de entrada, caixa de saída, 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 conversação do Gmail é um exemplo.

O design conceitual exerce influência na interface de usuário e na arquitetura do software.

O design da interface de usuário envolve a elaboração da maneira como o usuário pode interagir para realizar suas tarefas, a escolha dos objetos de interfaces (botões, 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.

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

TI para concursos

83

O design de arquitetura de software deve elaborar uma visão macroscópica do software em termos de componentes que interagem entre si. O conceito de componente em arquitetura varia de acordo com a visão arquitetônica adotada. São exemplos de visões arquitetônicas, a visão conceitual, visão de módulos, visão de código e visão de execução.

Na visão conceitual, os componentes de software são derivados do design conceitual. Estes componentes são abstrações que devem definir outros elementos menos abstratos. Exemplos são arquiteturas cliente-servidor e arquitetura em camadas. Na visão de código, deve-se determinar como as classes e/ou funções estão organizadas e interagindo entre si. Estas classes implementam os componentes abstratos ou conceituais. Na visão de módulos, deve-se determinar quais são os módulos que serão utilizados na implementação e como eles organizam as classes e/ou funções. Na visão de execução, a arquitetura deve descrever os diferentes processos que são ativados durante a execução do software e como eles interagem entre si. Enquanto as anteriores oferecem uma visão estática, esta é uma visão dinâmica do software.

O design de algoritmos e estrutura de dados, também conhecido como design detalhado, visa determinar, de maneira independente da linguagem de programação adotada, as soluções algorítmicas e as estruturas de dados associados. Deve-se decidir, por exemplo, como as informações podem ser ordenadas (algoritmo de bolha ou quicksort) e em qual tipo de estrutura de dados (array, lista encadeada) elas vão ser armazenados.

8.2.2.2 Implementação

A implementação envolve as atividades de codificação, compilação, integração e testes. A codificação visa traduzir o design num programa, utilizando linguagens e ferramentas adequadas. A codificação 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 implementação. A depuração de erros ocorre durante a programação utilizando algumas técnicas e ferramentas. É fundamental um controle e gerenciamento de versões para que se tenha um controle correto de tudo o que está sendo codificado.

8.2.2.3 Verificação e validação

Verificação e validação destinam-se a mostrar que o sistema está de acordo com a especificação e que ele atende às expectativas de clientes e usuários. A validação visa assegurar se o programa está fazendo aquilo que foi definido na sua especificação (fazendo a coisa certa). A verificação visa verificar se o programa está correto, isto é, não possui erros de execução (fazendo certo a coisa). Existem diferentes formas de verificação e validação. Inspeção analítica e revisão de modelos, documentos e código fonte são formas que podem ser usadas antes mesmo que o programa seja completamente codificado. Os testes de correção, desempenho, confiabilidade, robustez, usabilidade, dentre outros, visam avaliar diversos fatores de qualidade a partir da execução do software. Diferentes técnicas de testes podem ser aplicadas para cada um destes fatores.

8.2.3 Fase de Operação

A fase de operação envolve diferentes tipos de atividades:

Distribuição e entrega Instalação e configuração Utilização Manutenção

A distribuição 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 genéricos).

O processo de instalação e configuração, normalmente, pode ser feito com a ajuda de software de instalação disponibilizados pelos fabricantes dos ambientes operacionais.

A atividade de utilização é o objeto do desenvolvimento do software. A qualidade da utilização é a usabilidade do software.

A manutenção normalmente ocorre de duas formas: corretiva e evolutiva. A manutenção corretiva visa a resolução de problemas referentes a qualidade do software (falhas, baixo desempenho, baixa usabilidade, falta de confiabilidade etc.). A manutenção evolutiva ou adaptativa visa a produção de novas versões do software de forma a atender a novos requisitos dos clientes, ou adaptar-se às novas tecnologias que surgem (hardware, plataformas operacionais, linguagens, etc). Mudanças no domínio de aplicação implicam em novos requisitos e incorporação de novas funcionalidades. Surgimento de novas tecnologias de software e hardware e mudanças para uma plataforma mais avançada também requerem evolução.

TI para concursos

84

8.2.4 Fase de retirada

A fase retirada é um grande desafio para os tempos atuais. Diversos software que estão em funcionamento em empresas possuem excelente níveis de confiabilidade e de correção. No entanto, eles precisam evoluir para novas plataformas operacionais ou para a incorporação de novos requisitos. A retirada desses software legados em uma empresa é sempre uma decisão difícil: como abrir mão daquilo que é confiável e ao qual os funcionários estão acostumados, após anos de treinamento e utilização?

Processos de reengenharia podem ser aplicados para viabilizar a transição ou migração 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 caótico42

O produto é construído sem qualquer especificação ou projeto. O produto é retrabalhado quantas vezes forem necessárias 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 segurança e a confiabilidade tem grande importância.

Orientado para documentação, que abrange representações gráficas e simulações, e com uma abordagem disciplinada, a cada fase são feitos procedimentos de verificação e validação (incluindo testes), são liberadas definições da documentação e todos produtos são formalmente revisados.

Uma vez definido o modelo de ciclo de desenvolvimento, existem três abordagens para implementá-lo

Cascata Pura Incremental Evolucionária

8.3.2.1 Abordagem Cascata Pura

Todas as fases do ciclo de desenvolvimento são executadas em sequência. As fases anteriores são revisitadas para correções de erros ou para adaptações. Esta abordagem é adequada quando :

existe um conjunto de Requisitos do Usuário estáveis e de alta qualidade a duração do projeto é pequena o sistema completo deve estar disponível de um única vez

8.3.2.2 Abordagem Incremental

Nesta abordagem o desenvolvedor executa múltiplas fases de PD, TR e OM. Dentro desta abordagem está a abordagem cascata.

A abordagem incremental é adequada quando:

a liberação do software deve estar de acordo com um conjunto de prioridades definidas nos Requisitos do Usuário

é necessário melhorar a eficiência da integração do software com outra partes de um sistema maior

são requeridas antecipadamente evidências de que o produto será aceito

8.3.2.3 Abordagem Evolucionária

Nesta abordagem, o desenvolvimento é formado por múltiplos ciclos da abordagem cascata pura, ocorrendo sobreposição das fases da

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

RU – Requisitos do usuário

RS – Requisitos do software

PA – Projeto da arquitetura

PD – Projeto detalhado TR – Treinamento OM – Operação e

Manutenção

TI para concursos

85

operação e manutenção do sistema anterior com o novo desenvolvimento. Esta abordagem é adequada quando:

é necessário alguma experiência do usuário para refinar e completar requisitos algumas partes da implementação podem depender da existência de tecnologia ainda não

disponível existem requisitos do usuário não bem conhecidos alguns requisitos são muito mais difíceis de serem implementados do que outros, decidindo-se

não implementá-lo para não atrasar o projeto

8.3.2.4 Modelo Espiral

Modelo em cascata onde cada fase é precedida por uma análise de risco e sua execução é feita evolucionariamente (ou incrementalmente).

A dimensão radial representa o custo acumulado atualizado e a dimensão angular representa o progresso através da espiral. Cada setor da espiral corresponde a uma tarefa (fase)do desenvolvimento.

Um ciclo se inicia com a tarefa "Determinação de objetivos, alternativas e restrições", onde ocorre o comprometimento dos envolvidos e o estabelecimento de uma estratégia para alcançar os objetivos.

Na tarefa "Avaliação de alternativas, identificação e solução de riscos", executa-se uma análise de risco. Prototipação é uma boa ferramenta para tratar riscos. Se o risco for considerado inaceitável, 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.

Variações do modelo espiral consideram entre três e seis tarefas ou setores da espiral. Por exemplo, as regiões:

comunicação com o cliente planejamento análise de risco engenharia construção e liberação avaliação do cliente

8.4 Desenvolvimento ágil43

Desenvolvimento ágil de software (do inglês Agile software development) ou Método á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 inúmeros frameworks de processos para desenvolvimento de software. A maioria dos métodos ágeis tenta minimizar o risco pelo desenvolvimento do software em curtos períodos, chamados de iteração, os quais gastam tipicamente menos de uma semana a até quatro. Cada iteração é como um projecto de software em miniatura de seu próprio, e inclui todas as tarefas necessárias para implantar o mini-incremento da nova funcionalidade: planejamento, análise de requisitos, projeto, codificação, teste e documentação. Enquanto em um processo convencional, cada iteração não está necessariamente focada em adicionar um novo conjunto significativo de funcionalidades, um projecto de software ágil busca a capacidade de implantar uma nova versão do software ao fim de cada iteração, etapa a qual a equipe responsável reavalia as prioridades do projecto.

Métodos ágeis enfatizam comunicações 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 necessárias para terminar o software: no mínimo, os programadores e seus clientes (clientes são as pessoas que definem o produto, eles podem ser os gerentes, analistas de negócio, ou realmente os clientes). Nesta sala devem também se encontrar os testadores, projectistas de iteração, redactores técnicos e gerentes.

43 http://pt.wikipedia.org/wiki/Desenvolvimento_Ágil_de_software

TI para concursos

86

Métodos ágeis também enfatizam trabalho no software como uma medida primária de progresso. Combinado com a comunicação face-a-face, métodos ágeis produzem pouca documentação em relação a outros métodos, sendo este um dos pontos que podem ser considerados negativos. É recomendada a produção de documentação que realmente será útil.

Os princípios do desenvolvimento ágil valorizam:

Garantir a satisfação do consumidor entregando rapidamente e continuamente softwares funcionais;

Softwares funcionais são entregues frequentemente (semanas, ao invés de meses); Softwares funcionais são a principal medida de progresso do projecto; Até mesmo mudanças tardias de escopo no projecto são bem-vindas. Cooperação constante entre pessoas que entendem do negócio e desenvolvedores; Projetos surgem através de indivíduos motivados, entre os quais existe relação de confiança. Design do software deve prezar pela excelência técnica; Simplicidade; Rápida adaptação às mudanças; Indivíduos e interações mais do que processos e ferramentas; Software funcional mais do que documentação extensa; Colaboração com clientes mais do que negociação de contratos; Responder a mudanças mais do que seguir um plano.

A maioria dos métodos ágeis compartilha a ênfase no Desenvolvimento iterativo e incremental para a construção de versões implantadas do software em curtos períodos de tempo. Métodos ágeis diferem dos métodos iterativos porque seus períodos de tempo são medidos em semanas, ao invés de meses, e a realização é 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 iteração. Outras equipes, mais especificamente as equipes de Programação extrema, trabalham com atividades simultaneamente.

A codificação cowboy, também chamada de Modelo Balbúrdia, é a ausência de metodologias de desenvolvimento de Software: os membros da equipe fazem o que eles sentem que é correto. Como os desenvolvedores que utilizam métodos ágeis freqüentemente reavaliam os planos, enfatizam a comunicação face a face e fazem o uso relativamente esparso de documentos, ocasionalmente levam as pessoas a confundirem isto com codificação cowboy. Equipes ágeis, contudo, seguem o processo definido (e freqüentemente de forma disciplinada e rigorosa).

Como em todas as metodologias, o conhecimento e a experiência dos usuários definem o grau de sucesso e/ou fracasso de cada atividade. Os controles mais rígidos e sistematizados aplicados em um processo implicam altos níveis de responsabilidade para os usuários. A degradação de procedimentos bem-intencionados e organizados pode levar as atividades a serem caracterizadas como codificação cowboy.

De uma perspectiva organizacional, a aplicabilidade pode ser expressa examinando três dimensões chaves da organização: cultura, pessoal e comunicação. Em relação a estas áreas inúmeros fatores chave do sucesso podem ser identificados (Cohen et al., 2004):[2]

A cultura da organização deve apoiar a negociação. As pessoas devem ser confiantes. Poucas pessoas, mas competentes. A organização deve promover as decisões que os desenvolvedores tomam. A Organização necessita ter um ambiente que facilite a rápida comunicação entre os membros.

O fator mais importante é provavelmente o tamanho do projeto. Com o aumento do tamanho, a comunicação face a face se torna mais difícil. Portanto, métodos ágeis são mais adequados para projetos com pequenos times, com no máximo de 20 a 40 pessoas.

Ambiente ideal para o desenvolvimento ágil:

Baixa criticidade Desenvolvedores senior Mudanças freqüente de requisitos Pequeno número de desenvolvedores Cultura que tem sucesso no caos.

Ambiente ideal para o desenvolvimento direcionado ao planejamento:

Alta criticidade Desenvolvedores Junior Baixa mudança nos requisitos Grande número de desenvolvedores Cultura que procura a ordem.

TI para concursos

87

8.5 Planejamento e avaliação de iterações

Uma iteração é um período de tempo definido dentro de um projeto em que você produz uma versão estável e executável do produto, junto com toda a documentação de apoio, scripts de instalação e similares, necessários para usar a liberação. É também conhecida como ciclo ou tempo definido.

A finalidade das iterações é produzir um executável que possa ser avaliado de forma que você possa obter feedback e fazer correções de rumo. Este executável lhe coloca uma etapa mais perto do produto final. As fases fornecem um foco para a equipe chegar a um determinado objetivo da gerência. O OpenUP tem quatro fases, cada uma terminando com respostas a perguntas específicas:

Concepção - Nós concordamos com o problema que estamos tentando resolver?

Elaboração - Nós concordamos com toda a solução, e compreendemos os riscos, custos e cronograma razoavelmente bem?

Construção - Nós concordamos que temos um sistema que atende às principais necessidades dos stakeholders?

Transição - Nós concordamos que podemos liberar o sistema e terminar o projeto?

Em cada fase, você pode ter uma ou várias iterações, onde cada uma visa produzir os resultados necessários para responder a estas perguntas. Por exemplo, para responder à pergunta da Elaboração, nós necessitamos implementar e testar alguns aspectos chaves do sistema de modo que possamos compreender qual arquitetura é necessária, que componentes comerciais (COTS) necessitaremos, quais os principais riscos que enfrentamos e como direcioná-los, qual a eficácia da equipe etc. Estas necessidades irão orientar a atribuição das prioridades ao que deve ser feito em uma iteração de Elaboração.

Uma das principais vantagens da abordagem iterativa em relação à abordagem em cascata é o fato de as iterações fornecerem marcos naturais para avaliar o progresso e os riscos prováveis. Na iteração, a avaliação do progresso e do risco deverá continuar (se realizada informalmente) para garantir que as dificuldades não desviem o projeto.

A Avaliação de Iteração captura o resultado de uma iteração, até que ponto os critérios de avaliação foram respeitados e as mudanças que devem ser feitas.

Cada iteração é concluída por uma Avaliação de Iteração, na qual a organização de desenvolvimento para para refletir sobre o que aconteceu, o que foi ou não alcançado e por quê, e as lições aprendidas.

Essa avaliação é uma etapa decisiva em uma iteração e não deve ser ignorada. Se a Avaliação de Iteração não for feita corretamente, muitos dos benefícios oferecidos por uma abordagem iterativa poderão se perder.

Algumas vezes, o procedimento correto nesta etapa é rever os critérios de avaliação, em vez de retrabalhar o sistema. Às vezes, a vantagem da Avaliação de Iteração está em revelar que um determinado requisito não é importante, é muito caro para ser implementado ou cria uma arquitetura que não pode ser mantida. Nesses casos, uma análise de custo e benefício deve ser feita e uma decisão de negócios deve ser tomada.

A métrica deve ser usada como base dessa avaliação.

Quase no final de cada iteração, a equipe central do projeto deverá se reunir para avaliar a iteração, enfatizando o seguinte:

A iteração obteve êxito no cumprimento de suas metas?

Os riscos foram reduzidos ou eliminados?

O release cumpriu suas metas de funcionalidade, qualidade, desempenho e capacidade?

São necessárias mudanças no projeto e nos planos de iteração futuros?

Alguma das descobertas capturadas no artefato, na avaliação da organização de desenvolvimento, foi invalidada pelas mudanças durante a iteração e, como conseqüência, exige mudanças em outros artefatos?

Houve alguma dificuldade no processo de desenvolvimento durante a iteração?

Que parte do release atual servirá como baseline? Sofrerá retrabalho?

Novos riscos foram identificados?

Houve mudanças externas (mudanças no mercado, na comunidade de usuários ou nos requisitos)?

Avalie os resultados da iteração com relação aos critérios de avaliação que foram estabelecidos para o plano de iteração: funcionalidade, desempenho, capacidade, medidas de qualidade.

Use as métricas obtidas nas atividades de teste e no passo coletar métricas como a base da avaliação, quando disponíveis, para quantificá-la. As medidas qualitativas são adequadas para a fase de iniciação e talvez para a iteração inicial, enquanto as fases posteriores de elaboração, construção e transição devem depender de medições de teste específicas para avaliar a qualidade, o desempenho, a capacidade etc. Aborde outros problemas pendentes que foram capturados nas avaliações de status durante a iteração e quaisquer outros problemas na lista de problemas do gerente de projeto.

TI para concursos

88

Se todos os riscos tiverem sido reduzidos a níveis aceitáveis, toda a funcionalidade tiver sido implementada e todos os objetivos de qualidade tiverem sido atingidos, o produto estará concluído. O planejamento e a execução eficientes são vitais para isso ocorrer no final da fase de Transição.

8.6 Testes Software

O teste do software é a investigação do software a fim de fornecer informações sobre sua qualidade em relação 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 ações que vão do levantamento de requisitos até a execução do teste propriamente dito.

Não se pode garantir que todo software funcione corretamente, sem a presença de erros, visto que os mesmos muitas vezes possuem um grande número de estados com fórmulas, 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 permutação possível do software deveria ser testada. Entretanto, isso se torna impossível para a ampla maioria dos casos devido à quantidade impraticável de possibilidades. A qualidade do teste acaba se relacionando à qualidade dos profissionais envolvidos em filtrar as permutações relevantes.

Falhas podem ser originadas por diversos motivos. Por exemplo, a especificação pode estar errada ou incompleta, ou pode conter requisitos impossíveis de serem implementados, devido à limitações de hardware ou software. A implementação também 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 têm uma disciplina dedicada aos testes. Atualmente esta é uma tarefa indispensável, porém 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 princípios em relação aos testes:44

Testar é um exercício de gerência de risco Treinamento em teste reduz custos a longo prazo As estimativas de teste devem ser baseadas no risco do negócio A estratégia de teste deve ser elaborada através de um trabalho conjunto entre as áreas envolvidas É melhor encontrar um defeito nas primeiras fases do que em produção

Um plano de testes deve passar por alguns estágios:

Planejamento Estratégia de Teste Cronograma básico Plano de Teste Cronograma final Análise de Risco Análise de Pontos deTeste

Elaboração Elaborar Cenário de Teste Elaborar Caso de Teste Procedimento de Teste Implementar Teste

Execução Casos de Teste Roteiros de Teste

Controle Relatórios de Defeitos Relatórios de Progresso

As pessoas envolvidas nos testes podem assumir os papéis de:

Líder ou Gerente de teste, responsável pela liderança de um projeto de teste específico Arquiteto de Teste, responsável pela montagem do ambiente de teste (infra-estrutura) e escolha das

ferramentas Analista de Teste, responsável pela modelagem e elaboração dos casos de testes e scripts de teste Testador, responsável pela execução dos casos de teste e scripts de teste

A definição de quem irá executar os testes dependerá do nível ou estágio do teste:

Teste Unitário - Desenvolvedores Teste de Integração - Analistas de Sistemas Teste de Sistema - Analistas de Teste Teste de Aceitação - Usuários e Analistas de Teste

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

TI para concursos

89

Existem técnicas de testes chamadas de funcionais, que verificam se o sistema faz o que deveria:45

Teste de caixa-branca - Também chamado de teste estrutural ou orientado à lógica, avalia o comportamento interno do componente de software. Essa técnica trabalha diretamente sobre o código fonte do componente de software para avaliar aspectos tais como: teste de condição, teste de fluxo de dados, teste de ciclos, teste de caminhos lógicos, códigos nunca executados.

Teste de caixa-preta - Também chamado de teste funcional, orientado a dado ou orientado a entrada e saída, avalia o comportamento externo do componente de software. Dados de entrada são fornecidos, o teste é executado e o resultado obtido é comparado a um resultado esperado previamente conhecido.

Há, por outro lado, as técnicas não funcionais, que testam como a operação correta do sistema se comporta em situações anormais, como casos de entradas inválidas ou inesperadas.

teste de desempenho com teste de carga, verifica se o software consegue processar grandes quantidades de dados nas especificações de tempo de processamento exigidas, o que determina a escalabilidade do software.

teste de usabilidade, necessário para verificar se a interface de usuário é fácil 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 recuperação, usado para verificar a robustez do software em retornar a um estado estável de

execução após estar em um estado de falha.

8.6.1 Documentos de Teste

IEEE 829-1998, também conhecido como o Padrão 829 para Documentação de Teste de Software, é um padrão IEEE que especifica a forma de uso de um conjunto de documentos em oito estágios definidos de teste de software, cada estágio potencialmente produzindo seu próprio tipo de documento. O padrão especifica o formato desses documentos mas não estipula se todos eles devem ser produzidos, nem inclui qualquer critério de conteúdo para esses documentos.

46

Documentação 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 mínimo os seguintes tópicos devem ser tratados: Descrição do programa a ser testado: o que faz; estrutura Objetivo dos testes: por exemplo, se são testes caixa branca ou caixa preta, se são testes de integração

ou de unidade Escopo dos testes: que itens serão testados, quais não serão

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. Definção das estruturas provisórias (drivers, stubs, arquivos ou bancos de dados criados para os testes, entre outros) que serão usadas nos testes.

Casos de Teste especificados no projeto. A descrição de cada caso de teste deve conter os seguintes tópicos: Identificação do caso de teste Itens a testar Entradas: valores dos campos de entrada Saídas esperadas: valores dos campos de saída Ambiente: necessidade de hw, sw, ferramentas e estruturas provisórias que sejam específicas desse caso

de teste Procedimentos: identificação do procedimento de teste (dentre os já listados na seção anterior) que será

usado para executar o caso de teste Dependências: condições prévias para a execução do caso de teste, inclusive outros casos de teste que

devam ser executados obrigatoriamente antes deste Saídas observadas: resultados fornecidos pelo item em teste ou anomalias ocorridas durante a execução Impacto: consequências do incidente de teste (evento indesejável que tenha ocorrido durante os testes).

Como para a inspeção, classificá-los em categorias: MA: maior. Causa resultados errados/anomalia na execução do programa ME: menor. Causa outro tipo de problema que não afeta a execução do programa

Procedimentos de Teste, que especifica os passos para execução. Definição dos procedimentos associados ao conjunto de testes: Uma identificação do procedimento . O objetivo do procedimento. Os requisitos especiais para a execução 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. Descrição de cada um dos casos de teste gerado.

Resultados do teste, contendo os registros dos testes realizados em ordem cronológica.

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

TI para concursos

90

Relatório de incidentes, contendo o registro dos problemas encontrados durante os testes que mereçam ser investigados.

Relatório de resumo dos teste, contendo um resumo dos resultados das atividades projetadas e fornecendo avalições baseadas nestes resultados. O relatório fecha a etapa de testes realizada, permitindo uma avaliação da eficácia dos mesmos, indicação do nível de qualidade do produto, se há necessidade de testes adicionais ou a reconstrução de alguns itens sob teste. O relatório de resumo pode conter: Identificador do relatório resumido Contexto: quais os itens testados, com respectivos números de versão e revisão Variações: descrever as possíveis variações dos testes realizados em relação ao previsto na

especificação, justifiando o motivo de tais variações Abrangência: avaliar se a cobertura foi suficiente, conforme o planejado. Indicar possíveis deficiências nos

testes, caso existam. Sumário dos resultados: resumir os incidentes ocorridos Avaliação: fornecer uma avaliação global da eficácia dos testes; uma base para isso pode ser o número

de defeitos classificados como MA que foram encontrados. Sumário das atividades: para cada item testado, indicar o tempo previsto e os efetivamente gastos para

as tarefas de teste Aprovações: indicar se o item testado foi considerado aprovado ou não.

8.7 Exercícios

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 integração.

xx

(c) de configuração. (d) operacional. (e) funcional.

138. (ICMS-SP 2009) O teste de ameaça normalmente deve ser aplicado dentro de um projeto de software nas etapas de

138

(a) desenvolvimento inicial e desenvolvimento intermediário. (b) desenvolvimento intermediário e teste de aceitação. (c) desenvolvimento intermediário e teste de sistema. (d) teste de integração e teste de aceitação. (e) teste de integração e teste de sistema.

xx

139. (ICMS-SP 2009) Na prática de garantia de qualidade de software, contrapondo com o controle de qualidade de software, se aplica a atividade:

139

(a) executar teste de software. (b) desenvolver casos de testes. (c) definir métricas e medição.

xx

(d) definir estratégias de testes. (e) definir planos de desenvolvimento de teste.

140. (ICMS-SP 2009) O processo de engenharia de software denominado ciclo de vida clássico refere-se ao modelo

140

(a) em cascata.xx

(b) incremental. (c) evolucionário. (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 denominado

141

(a) XP. (b) DAS. (c) DSDM. (d) Scrum.

xx

(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

TI para concursos

91

143. Na metodologia Scrum, NÃO faz parte de uma revisão do sprint (sprint review) o seguinte procedimento:143

(a) Todo o time colabora no que deve ser feito em seguida, de modo que esta revisão contribua para

reuniões de planejamento subsequentes. (b) O proprietário 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 questões sobre o

incremento. (e) Todo o time cria um plano para implementar melhorias no modo como o time efetua seu trabalho.

xx

144. O modelo FURPS, para melhoria de qualidade de software, representa as dimensões, que são mais relevantes para os clientes:

144

(a) Funcionalidade, Usabilidade, Confiabilidade, Desempenho e Suportabilidade.xx

(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. NÃO é um dos sete princípios (David Hooker) da Engenharia de Software: 145

(a) manter a coisa simples. (b) não especificar requisitos detalhadamente.

xx

(c) estar aberto para o futuro. (d) planejar o reúso com antecedência. (e) manter a visão.

146. Se em uma seqüência de atividades de um projeto todas elas tiverem retardo de zero dias em relação às suas predecessoras

146

(a) o projeto é inviável. (b) isso indica a ausência de caminho crítico. (c) essa seqüência é o caminho crítico.

xx

(d) a seqüência está errada. (e) o projeto deve ser desmembrado.

147. Um Plano de Projeto de Software é um documento gerencial que se destina a um público diverso e NÃO deve conter

147

(a) a comunicação do escopo e dos recursos à administração, aos clientes e à equipe técnica. (b) a definição dos principais requisitos e dos riscos com sugestões técnicas para, respectivamente,

atendêlos ou evitá-los. (c) o desenho dos componentes do software para planejar a sua instalação e operacionalização. (d) a definição dos custos e dos prazos para as revisões administrativas do projeto.

xx

(e) a apresentação de uma abordagem global do desenvolvimento do software para todas as pessoas envolvidas no projeto.

TI para concursos

92

9 Banco de Dados

9.1 Conceitos básicos

Dentre diversas definições, dado é tudo que pode ser processado e as informações são dados que descrevem um domínio físico ou abstrato. Registros são informações produzidas como subprodutos de atividades comerciais ou transações e retidas em virtude do seu valor.

48

Entidade é qualquer coisa do mundo real, abstrata ou concreta, na qual se deseja guardar informações.

Atributo é tudo o que se pode relacionar como propriedade da entidade. Domínio é o conjunto de valores possíveis do atributo. Em banco de dados, fisicamente, entidades são tabelas, atributos são as colunas e domínio é o tipo de dado contido na coluna.

Um atributo é dito obrigatório quando não 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 primária. Se houver mais do que uma chave candidata, uma deverá ser escolhida para se a chave primária, enquanto que as outras serão chamadas de chaves alternativas.

Bancos de dados (ou bases de dados) são conjuntos de registros dispostos em estrutura regular que possibilita a reorganização dos mesmos e produção de informação, 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 são armazenados, que pode determinar a forma como as informações podem ser processadas.

O modelo plano ou tabular consiste de tabelas, que são matrizes simples, bidimensionais, compostas por elementos de dados: caracteres, números inteiros, reais etc. Este modelo plano é a base das planilhas eletrônicas.

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

9.2 Modelagem de Dados Relacional

No modelo relacional, todos os dados estão guardados em tabelas. Toda sua definição é teórica e baseada na lógica de predicados e na teoria dos conjuntos. Consiste, principalmente, de três componentes:

uma coleção de estruturas de dados, nomeadamente relações ou tabelas;

uma coleção dos operadores, a álgebra e o cálculo relacionais;

uma coleção de restrições da integridade, definindo o conjunto consistente de estados de base de dados e de alterações de estados. As restrições de integridade podem ser dos tipos: domínio – indica os valores possíveis 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 primária – chave que identifica uma linha da própria tabela e não 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 não pode se repetir na outra tabela

Toda informação tem de ser representada como dados e qualquer tipo de atributo (coluna) representa relações entre conjuntos de dados (linhas).

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

9.2.1 Normalização

A normalização de dados é uma série 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

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

TI para concursos

93

relacional. Esses passos reduzem a redundância de dados e as chances dos dados se tornarem inconsistentes.

50

No entanto, muitos SGBDs relacionais não têm separação suficiente entre o projeto lógico da base de dados e a implementação física do banco de dados, e isso tem como conseqüência que as consultas feitas a um banco de dados totalmente normalizado têm um mau desempenho. Nestes casos, usa-se por vezes a desnormalização para melhorar o desempenho, com o custo de menores garantias de consistência.

Dizemos que duas colunas de uma tabela têm dependência funcional quando a valor de uma determina o valor da outra. Por exemplo, uma coluna com o número de matrícula e outra com o nome de um aluno. Um número de matrícula só pode corresponder a uma aluno, portanto há dependência funcional entre estas duas colunas.

Chamamos de chave a um conjunto de colunas que identifica unicamente cada linha da tabela. No exemplo anterior, o número de matrícula do aluno é campo chave da tabela, supondo não poder haver uma pessoa com dois números de matrícula. Em uma tabela contendo o número de matrícula do aluno, o código da disciplina, a nota e frequência 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 três números que identificam de forma única nosso aluno, três chaves. Dizemos que o número de matrícula, o RG e o CPF são chaves candidatas. Se escolhermos uma delas para identificar o aluno, esta será chamada de chave primária.

Tirando as chaves, os demais campos são chamados de descritores.

Ao imprimir a lista de notas finais dos alunos, podemos ter:

Núm Matrícula Nome Núm Disc Disciplina Prova 1 Prova 2 Média Frequência

123456 Funalo de Tal 12 Matemática 5,0 7,0 6,0 95%

123456 Funalo de Tal 13 Português 8,0 9,0 8,5 100%

234567 Cicrano da Silva 12 Matemática 6,0 9,0 7,5 80%

234567 Cicrano da Silva 13 Português 3,0 8,0 5,5 70%

A chave da tabela é composta das colunas Núm Matrícula e Núm Disc. Dizemos que há dependência parcial entre o nome a uma das colunas chave, entre o código e o nome da disciplina também.

Poderíamos preferir imprimir a lista sem repetir o nome de cada aluno:

Núm Matrícula Nome Núm Disc Disciplina Prova 1 Prova 2 Média Frequência

123456 Funalo de Tal 12 Matemática 5,0 7,0 6,0 95%

13 Português 8,0 9,0 8,5 100%

234567 Cicrano da Silva 12 Matemática 6,0 9,0 7,5 80%

13 Português 3,0 8,0 5,5 70%

Onde, para cada linha de um aluno, teríamos uma lista de disciplinas e notas. Dizemos que os campos número de matrícula e nome possuem valores atômicos, um só valor por linha.

Os demais campos são chamados de multivalorados, pois são 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 condições. Considera-se que as bases de dados estão normalizadas se aderirem à terceira forma normal.

Primeira Forma Normal (ou 1FN) requer que todos os valores de colunas em uma tabela, sejam atômicos (um número é um átomo, enquanto uma lista ou um conjunto não o são). A normalização elimina grupos repetidos pondo-os cada um em uma tabela separada, conectando-os com uma chave primária ou estrangeira. Por exemplo, pessoas têm diversos números de telefones. Uma tabela conterá as pessoas e outra tabela os telefones, ligadas pelo código da pessoa.

Segunda Forma Normal (ou 2FN) requer que não haja dependência funcional não-trivial de um atributo que não seja a chave, em parte da chave candidata. Por exemplo, uma tabela de pedidos com o código do pedido, chave primária, código do produto, chave estrangeira, e descrição do produto, campo dependente funcional do código do produto, que não é chave primária. O correto é levar a descrição e código do produto para outra tabela e deixar somente o código do produto na tabela de pedidos.

Terceira Forma Normal (ou 3FN) requer não haver dependências funcionais não-triviais de atributos que não sejam chave, em qualquer coisa exceto um superconjunto de uma chave candidata. Por exemplo, uma coluna preço total, que é resultado do produto do valor da coluna quantidade pelo preço unitário e não depende do código do pedido, chave primária. A coluna preço total deve ser eliminada, sendo o valor calculado quando for necessário em relatórios.

50 http://pt.wikipedia.org/wiki/Normaliza%C3%A7%C3%A3o_de_dados

TI para concursos

94

Forma Normal de Boyce-Codd (ou BCNF) requer que não exista nenhuma dependência funcional não-trivial de atributos em algo mais do que um superconjunto de uma chave candidata. Neste estágio, todos os atributos são dependentes de uma chave, de uma chave inteira e de nada mais que uma chave (excluindo dependências triviais, como A->A).

Quarta Forma Normal (ou 3FN) Uma relação está na 4ª forma normal, se está na Boyce-Codd, e se não existem dependências multivalor

Forma Normal (ou 3FN) Uma relação está na 5ª forma normal, se está na 4ª FN, e se não existem dependências de junção.

As quarta e quinta formas normais são raras e difíceis de detectar.

Frequentemente considera-se que uma relação na 3ª forma normal ou Boyce-Codd está num nível de normalização aceitável.

9.2.2 Etapas de modelagem

A construção de modelos relacionais envolve as etapas:51

Modelo conceitual - Representa as regras de negócio sem limitações tecnológicas ou de implementação: Visão Geral do negócio Facilitação do entendimento entre usuários e desenvolvedores Possui somente as entidades e atributos principais Pode conter relacionamentos n para m.

Modelo Lógico - 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 primárias das entidades Normalização até a 3a. forma normal Adequação ao padrão de nomenclatura Entidades e atributos documentados

Modelo Físico - Leva em consideração limites imposto pelo SGBD (Sistema Gerenciador de Banco de dados) e pelos requisitos não funcionais dos programas que acessam os dados. Características: Elaborado a partir do modelo lógico Pode variar segundo o SGBD Pode ter tabelas físicas Pode ter colunas físicas

9.2.3 Relacionamentos

As tabelas podem ser relacionadas para compor uma consulta de informações, desde que a chave primária de uma seja uma coluna da outra, onde será chamada de chave estrangeira. No modelo lógico, este relacionamento pode se dar de três formas:

A chave primária da primeira é chave estrangeira na segunda tabela, de forma que podem haver diversas ocorrências 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 código do cliente e o nome, pode ser relacionada com uma outra tabela de telefones contendo o código do telefone, o código do cliente e o número do telefone.

As chaves primárias 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 código da matéria e nome, pode se relacionar com uma tabela de alunos, com código do aluno e nome, através de uma terceira tabela de matrículas com os dois códigos. Um aluno pode se matricular em diversas matérias e uma matéria pode ter vários alunos.

A chave primária 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 através de uma tabela de chefia, com o código do empregado na coluna subordinado e de outro empregado, como chefe do primeiro, na coluna superior.

9.2.4 Transação

Conjunto de procedimentos que é executado num banco de dados, que para o usuário é visto como uma única ação. A integridade de uma transação depende de 4 propriedades, conhecidas como ACID.

Atomicidade - Todas as ações que compõem a unidade de trabalho da transação devem ser concluídas com sucesso, para que seja efetivada. Qualquer ação que constitui falha na unidade de trabalho e a transação deve ser desfeita (rollback). Quando todas as ações são efetuadas com sucesso, a transação pode ser efetivada (commit).

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

TI para concursos

95

Consistência - Nenhuma operação do banco de dados de uma transação pode ser parcial. O status de uma transação deve ser implementado na íntegra. Por exemplo, um pagamento de conta não pode ser efetivado se o processo que debita o valor da conta corrente do usuário não for efetivado antes, nem vice-versa.

Isolamento - Cada transação funciona completamente à parte de outras estações. Todas as operações são parte de uma transação única. O principio é que nenhuma outra transação, operando no mesmo sistema, pode interferir no funcionamento da transação corrente (é um mecanismo de controle). Outras transações não podem visualizar os resultados parciais das operações de uma transação em andamento.

Durabilidade - Os resultados de uma transação são permanentes e podem ser desfeitos somente por uma transação subseqüente.

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

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 Informações ou que pertencem a um domínio. A principal ferramenta do modelo é sua representação gráfica, o Diagrama Entidade Relacionamento. Normalmente o modelo e o diagrama são conhecidos por suas siglas: MER e DER.

52

Existem muitas notações para Diagrama de Entidades e Relacionamentos. A notação original foi proposta por Chen e é composta de entidades (retângulos), relacionamentos (losangos), atributos (círculos) e linhas de conexão (linhas) que indicam a cardinalidade de uma entidade em um relacionamento. Chen ainda propõe símbolos para entidades fracas e entidades associativas.

Toda a notação moderna tem como característica importante definir a cardinalidade mínima e máxima em uma relação, não utilizar um símbolo especial para relacionamentos, mas sim a linha, e descrever atributos dentro do símbolo de entidades.

Diagrama entidade relacionamento é um modelo diagramático que descreve o modelo de dados de um sistema com alto nível de abstração. Ele é a principal representação do Modelo de Entidades e Relacionamentos. É usado para representar o modelo conceitual do negócio.

Uma relação entre duas tabelas é chamada de binária, três tabelas de ternária, enquanto que um auto-relacionamento, em que uma entidade se relaciona com ela mesma, é também chamado de relação unária.

Os tipos de relações utilizadas neste diagrama são:

Relação 1..1 (lê-se relação um para um) - indica que as tabelas têm relação unívoca entre si. Você escolhe qual tabela vai receber a chave estrangeira;

Relação 1..n (lê-se um para muitos) - a chave primária da tabela que tem o lado 1 vai para a tabela do lado N. No lado N ela é chamada de chave estrangeira;

Relação n..n (lê-se muitos para muitos) - quando tabelas têm entre si relação n..n, é necessário criar uma nova tabela com as chaves primárias das tabelas envolvidas, ficando assim uma chave composta, ou seja, formada por diversos campos-chave de outras tabelas. A relação então se reduz para uma relação 1..n, sendo que o lado n ficará com a nova tabela criada.

9.4 Modelagem de Dados Multidimensional

Na modelagem multidimensional os dados são de-normalizados e estruturados em diversas dimensões.

53

A finalidade de bases de dados multidimensionais (alguns autores chamam de dimensionais) é fornecer subsídio para realização de análises. Para tanto, sua arquitetura e terminologia empregada são distintas das utilizadas para bancos de dados transacionais. O fato de existirem diversas informações a serem cruzadas (dimensões) permite a realização de pesquisas.

As análises sobre dados históricos envolvem uma série de possibilidades de cruzamentos e agrupamentos de informações, com o uso dos seguintes termos:

Dimensões: estabelecem a organização dos dados, determinando possíveis consultas/cruzamentos. Por exemplo: região, tempo, canal de venda,... Cada dimensão pode ainda ter seus elementos, chamados membros, organizados em diferentes níveis hierárquicos. A dimensão tempo, por exemplo, pode possuir duas hierarquias: calendário gregoriano (com os níveis ano, mês e dia) e calendário fiscal (com os níveis ano, semana e dia);

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

TI para concursos

96

Medidas: são os valores a serem analisados, como médias, totais e quantidades;

Fatos: são os dados a serem agrupados, contendo os valores de cada medida para cada combinação das dimensões existentes. O tamanho da tabela que contém os fatos merece atenção especial do analista;

Agregações: totalizações calculadas nos diversos níveis hierárquicos.

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 agregações. Com isso obtém-se ganho de espaço de armazenamento, uma vez que os dados permanecem apenas na base de origem (multidimensional), embora a criação de grandes quantidades de agregações possa incorrer em explosão de dados.

Outra forma de armazenamento, cujo modelo matemático denomina-se hipercubos, apresenta a característica de possuir armazenamento e indexação em estruturas de dados que otimizam consultas ao invés de atualizações. Esta forma é erroneamente chamada MOLAP, ou Multidimensional OLAP. O erro está no fato de que bases ROLAP também são multidimensionais.

Quando o modelo multidimensional é processado, nova base é gerada, desta vez contendo tanto os dados quanto as agregações em formato próprio, utilizando-se de estruturas apropriadas para pesquisas.

Aplicações analíticas possuem peculiaridades tais como manipulação de grandes volumes de dados e baixa taxa de atualização. Essas características favorecem este modelo estrutural, mais rápido. Por exemplo, Business Intelligence (BI) é um processo de gerenciamento de informações que pode ser obtido por qualquer artefato, seja tecnológico ou não, que permita a extração de conhecimento a partir de análises do negócio. A efetividade destas análises será maior se os dados estiverem disponíveis de modo consistente e, preferencialmente, consolidado.

54

Soluções informatizadas de BI geralmente contém sistemas analíticos, que podem ser de diversos tipos, dependendo do objetivo das análises e do perfil do usuário:

Decision Support Systems (DSS), ou Sistemas de Apoio a Decisão (SAD): são baseados em relatórios analíticos, normalmente utilizados por usuários de nível operacional;

Management Information Systems (MIS), ou Sistemas de Informações Gerenciais (SIG): permitem análises mais profundas, com a realização de simulações de cenários. São utilizados por analistas de negócio no nível tático;

Executive Information Systems (EIS), ou Sistemas de Informações Executivas (SIE): são voltados para profissionais que atuam no nível estratégico das empresas, como diretores e presidência. 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 células multidimensionais que contêm dados do cubo.

9.4.1 Sistemas Transacionais X Sistemas Analíticos

Sistemas transacionais, também conhecidos como sintéticos ou ainda OLTP – Online Transactional Processing - são baseiados em transações. Por exemplo, Sistemas Contábeis, Aplicações de Cadastro, Sistemas de Compra, Estoque, Inventário, ERPs, CRMs etc.

Os sistemas transacionais se caracterizam pela alta taxa de atualização, grande volumes de dados e acessos pontuais, ou seja, pesquisas cujo resultado seja de pequeno volume.

Já os sistemas analíticos, ou OLAP – Online Analytical Processing – se caracterizam por fornecer subsídio para tomadas de decisão, a partir de análises realizadas sobre bases de dados históricas, por vezes com milhões de registros a serem totalizados. As atualizações não precisam ser tão freqüentes. As análises geralmente agrupam informações, sendo tais agrupamentos mais importantes neste contexto do que os dados detalhados.

As ferramentas OLAP (do inglês, Online Analytical Processing) são geralmente desenvolvidas para trabalhar com banco de dados denormalizados, embora existam ferramentas que trabalham com esquemas especiais de armazenamento, com dados (informações) normalizados.

55

Essas ferramentas são capazes de navegar pelos dados de um Data Warehouse, possuindo uma estrutura adequada tanto para a realização de pesquisas como para a apresentação de informações.

Nas ferramentas de navegação OLAP, é possível navegar entre diferentes níveis de granularidades (detalhamento) de um cubo de dados. Através de um processo chamado Drill o usuário pode aumentar (Drill down) ou diminuir (Drill up) o nível de detalhamento dos dados. Por exemplo, se um relatório estiver consolidado por países, fazendo um Drill down, os dados passarão a ser apresentados por Estados,

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

TI para concursos

97

cidades, bairros e assim sucessivamente até o menor nível de detalhamento possível. O processo contrário, o Drill up, faz com que os dados sejam consolidados em níveis superiores de informação.

Outra possibilidade apresentada pela maioria das ferramentas de navegação OLAP é o recurso chamado Slice and dice. Esse recurso é usado para criar visões dos dados por meio de sua reorganização, de forma que eles possam ser examinados sob diferentes perspectivas.

9.5 Conceitos de Datawarehouse e ETL

Um Data Warehouse é uma base de dados, geralmente relacional, que consolida as informações empresariais. Sua construção é um processo normalmente moroso e complexo, por diversos fatores, dentre os quais a grande quantidade de dados, diversas fontes de informações com bases heterogêneas e muitas vezes inconsistentes, envolvimento de várias áreas ou departamentos da empresa. Um dos maiores desafios na construção do DW é a extração e consolidação dos dados operacionais, pois:

Pode haver várias fontes; Os dados precisam ser limpos; A granularidade precisa ser ajustada; Pode ser necessário resumir dados; Deve haver valores default e tratamento de NULL; É necessário componente temporal; Os relacionamentos nos dados de entrada precisam ser claros.

Algumas situações comuns entre as fontes de dados:

Mesmos dados, nomes diferentes; Dados diferentes, mesmo nome; Dados exclusivos de uma aplicação; Chaves diferentes, mesmos dados.

Como métodos de construção, existem formalmente dois:

Top-down, no qual é realizada a modelagem integral do DW, seguida pelas extrações de dados. A principal vantagem é a criação de um modelo único. O revés 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 obtenção de resultados a intervalos mais curtos, garantindo muitas vezes sustentação ao projeto. A desvantagem é a maior dificuldade de se consolidar informações entre as diversas áreas.

Uma alternativa às estratégias 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 responsável pela integração dos demais;

As primeiras tabelas da área de interesse escolhida são povoadas: primeiras análises; Povoamento de mais tabelas com dados históricos; Alguns dados passam a compor o DW, saindo da base operacional; Surgimento dos data marts (a seguir nesta seção); O ciclo se repete até que o DW esteja completo. Bases de produção contêm apenas dados operacionais.

Outro fator crítico 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 não é infinita, devendo ser utilizada sabiamente. Apenas dados relevantes deveriam constar do DW. Pode ser que o horário de uma determinada transação seja importante quando o foco for o curto prazo, mas que apenas um contexto de agrupamento seja suficiente para dados de cinco anos atrás. Questões como essa devem ser consideradas durante o planejamento do DW, pois ajudam a dimensioná-lo.

A remoção de dados do DW é um assunto tratado com receio pelos DBAs e pelos analistas de negócio. A rigor, tão importante quanto saber que dados armazenar, é saber quando e quais dados remover do DW. Algumas estratégias são:

Resumir dados mais antigos;

Armazenar os dados antigos em meio mais barato (fita);

Remover os dados do DW.

Tais estratégias não são excludentes, podendo ser utilizadas em conjunto.

A importância da remoção de dados está em manter o DW o mais enxuto possível, embora isso possa parecer contraditório ao conceito de DW.

Com relação à granularidade, as bases de dados operacionais trabalham com o maior nível de detalhe possível, ou seja, a maior granularidade. Já no DW pode haver diversos graus de agregação 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, após isso, por total de pedidos por dia. A correta determinação da granularidade exerce papel fundamental no planejamento de capacidade e desempenho do DW.

Ao contrário do que ocorre com as bases operacionais, o DW, por conter dados históricos, não demanda alta taxa de atualização. Desse modo, pode ser atualizado a cada 24 horas ou até mesmo uma vez por

TI para concursos

98

semana. Além disso, por sofrer poucas modificações, e de forma controlada (por aplicações específicas para esse fim), seus relacionamentos podem ser implementados através de entidades, embora isso não seja freqüente.

Data Marts (DM), são bancos de dados multidimensionais específicos por área de negócio para realização de análises. Alguns conceitos sobre Data Marts não estão muito bem claros para o mercado.

Um DW construído iterativamente possui porções agrupadas por segmento de negócio, região ou qualquer outra forma que seja adequada à empresa. Essas porções alimentam os Data Marts, que podem ser então consultados por ferramentas de análise.

9.5.1 ETL

Extract, Transform and Load (Extração, Transformação e Carga) são ferramentas de software cuja função é a extração de dados de diversos sistemas, transformação desses dados conforme regras de negócios e carga dos dados em um data mart ou um data warehouse. É considerada uma das fases mais críticas do Data Warehouse e/ou Data Mart.

Os projetos de data warehouse consolidam dados de diferentes fontes. A maioria dessas fontes tendem a ser bancos de dados relacionais ou 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 organização. Essa pode ser uma tarefa não trivial, e muitas fontes de dados podem não ser acessadas muito facilmente.

Existem ferramentas ETL, mas ETL não são 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 características originais do SQL foram inspiradas na álgebra relacional.

56

Uma consulta SQL especifica a forma do resultado e não o caminho para chegar a ele. Padronizado pela ANSI e ISO, possui muitas variações e extensões produzidos pelos diferentes fabricantes de sistemas gerenciadores de bases de dados. Tipicamente a linguagem pode ser migrada de plataforma para plataforma sem mudanças estruturais principais.

O padrão do SQL (ANSI) utiliza operadores, funções de agregação e comandos, que dividem-se em cinco subconjuntos. Os comandos podem ser escritos e executados por linhas de comando dentro de algum aplicativo do próprio gerenciador de banco de dados, por lotes de comandos definidos dentro do banco de dados (procedures) ou lotes de comandos por qualquer aplicativo com conexão 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 padrões ANSI e adicionando mais recursos para administração eficiente de dados.

9.6.1.1 DML - Linguagem de Manipulação de Dados

A DML (Data Manipulation Language) é um subconjunto da linguagem usada para inserir, atualizar e apagar dados.

INSERT - insere registros (linhas ou tuplas)

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

TI para concursos

99

UPDATE - altera valores de dados

DELETE - remove linhas (registros ou tuplas)

9.6.1.2 DDL - Linguagem de Definição 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, não é 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 usuários e direitos de acesso aos objetos dentro do banco de dados.

GRANT - autoriza ao usuário executar ou setar operações.

REVOKE - remove ou restringe a capacidade de um usuário de executar operações.

ALTER PASSWORD - altera senha

CREATE SYNONYM - cria sinônimos, nomes alternativos para os objetos

9.6.1.4 DTL - Linguagem de Transação de Dados

DTL (Data Transaction Language) define blocos de comandos – transações – que podem ser efetivados ou não.

BEGIN WORK (ou START TRANSACTION) - usado para marcar o começo de uma transação.

COMMIT - confirma todas as ações, desde o comando begin, permanentemente.

ROLLBACK faz com que os comandos de mudanças nos dados sejam descartados.

COMMIT e ROLLBACK interagem com áreas de controle como transação e locação. Ambos terminam qualquer transação aberta e liberam qualquer bloqueio ligado a dados. Na ausência de um BEGIN WORK ou uma declaração semelhante, a semântica de SQL é dependente da implementação.

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 descrição do resultado desejado. Esse comando é composto de várias cláusulas e opções, possibilitando elaborar consultas das mais simples às mais elaboradas.

As cláusulas são condições de modificação 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 restrição, isto é, especificar as condições que devem reunir os

registros que serão selecionados. GROUP BY – Utilizada para separar os registros selecionados em grupos específicos. HAVING – Utilizada para expressar a condição que deve satisfazer cada grupo, criar uma restrição para o

grupo. ORDER BY – Utilizada para ordenar os registros selecionados com uma ordem especifica. DISTINCT – Utilizada para selecionar dados sem repetição. JOIN – utilizada para criar junções entre a tabelas, criando restrições ou atendendo a critérios, e

permitindo a seleção de colunas das tabelas envolvidas. O join pode ser definido de diversas formas: Sem a utilização da cláusula join, colocando os nomes das tabela logo depois da clausula from

separados por vírgulas, e com uma restrição de relacionamento após a cláusula where.

9.6.1.6 Operadores Lógicos

Operadores lógicos relacionam elementos de uma expressão lógica.

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 contrário da expressão.

9.6.1.7 Operadores Relacionais

Os operadores estabelecem critérios para uma expressão lógica.

< – Menor que

> – Maior que

TI para concursos

100

<> – Diferente de

<= – Menor ou Igual que

>= – Maior ou Igual que

= – Igual a

BETWEEN – Utilizado para especificar um intervalo de valores.

LIKE – Utilizado na comparação de um modelo e para especificar registros de um banco de dados."Like" + extensão % vai significar buscar todos resultados com o mesmo início da extensão.

9.6.1.8 Funções de Agregação

As funções de agregação, dentro de uma cláusula SELECT com cláusula GROUP BY, devolve valores agregados de um grupo de registros.

AVG – calcular a média dos valores de um campo numérico determinado.

COUNT – devolve o número de registros da seleção.

SUM – devolve a soma de todos os valores de um campo numérico 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 através de operações de seleção (select) de diversos tipos:

Junção – dois conjuntos de dados são concatenados de acordo com uma determinada condição de relação e seleção.

Restrição – condição que limita a seleção das linhas de uma relação.

Projeção – uma ou mais colunas de uma relação são selecionadas formando um subconjunto vertical.

União – são selecionadas todas as linhas que aparecem em ambas as relações

Intersecção – são 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 módulos programados e objetos que melhoram a manipulação dos dados.

Tabelas – modelo abstrato de armazenamento de dados em forma de registros e campos em banco de dados relacional. Cada tabela armazena informações de uma entidade modelada do banco de dados.

Views - ajuda a encapsular uma consulta em uma entidade relacional e facilita a visão de um dado de uma ou mais tabelas em um banco de dados.

Restrição - define regras a respeito de valores permitidos em colunas e é um mecanismo que executa a integridade de dados

Índices - oferece rápido acesso ao dado de uma tabela baseado em valores classificados em ordem crescente ou decrescente. A chave primária de uma tabela é automaticamente indexada.

Funções - pedaço de código que opera como uma unidade lógica. Uma função pode retornar tanto uma tabela quanto um valor escalar. Qualquer código que deve executar a lógica incorporada em uma função pode chamar a função, em vez de repetir a função lógica.

Procedimento (Procedure) – lote (texto) de comandos (código) armazenado no banco de dados.

Gatilho (Trigger) - procedimento que é executado quando ocorre um evento qualquer previsto para um registro, campo ou para a própria tabela.

9.6.2 Arquitetura de um Servidor Oracle

Um banco de dados Oracle é composto por uma ou mais tablespaces. Uma tablespace contém um ou mais arquivos no nível 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. é possível que um objeto seja atribuído a mais de um segmento, mas, para isso, o usuário deverá particionar explicitamente o objeto. Várias tabelas ou índices podem ser incluídos em um mesmo segmento através da criação de um objeto conhecido como cluster.

A medida que um objeto de banco de dados necessita de mais espaço, é necessário que o segmento aloque mais dados. O banco de dados procura, nos arquivos do tablespace, áreas contíguas de tamanho pré-determinado para o armazenamento de novos dados. Essa área contígua é conhecida como extensão (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 parâmetros de configuração, esse tamanho

TI para concursos

101

fixo deve ser múltiplo do tamanho de um bloco do nível do sistema operacional. O tamanho extent também pode ser configurado pelo usuário ou determinado automaticamente pelo Oracle.

A criação de um banco de dados pode ser realizada através de uma ferramenta gráfica conhecida como Database Configuration Assistant. Com essa ferramenta também é possível configurar opções de um banco de dados existente, deletar um banco de dados e gerenciar gabaritos de banco de dados.

Os tipos de usuários (papéis) variam de acordo com o lugar, mas podem ser divididos em administadores de banco de dados, responsáveis pela segurança, administradores de rede, desenvolvedores de aplicação, administradores de aplicação e usuários do banco de dados.

PL/SQL (Procedural Language/SQL) é uma extensão da linguagem padrão SQL para o Oracle. Permite que a manipulação de dados seja incluída em unidades de programas. Blocos de PL/SQL são 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 básica para criar programas complexos e poderosos, não só no banco de dados, mas também em diversas ferramentas Oracle.

57

A unidade básica em PL/SQL é um bloco. Todos os programas em PL/SQL são compostos por blocos, que podem estar localizados uns dentro dos outros. Geralmente, cada bloco efetua uma ação lógica no programa. Um bloco tem basicamente a seguinte estrutura:

DECLARE

Seção (opcional) para declaração de variáveis,tipos e subprogramas locais.

BEGIN

Seção Executável, nesta seção ficam as instruções procedurais e SQL. Esta é a única seção do bloco que é indispensável e obrigatória.

EXCEPTION

Seção/Setor (opcional) onde ficam as instruções 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 físico de um conjunto de objetos de esquema de um banco de dados em um ou mais arquivos físicos. Os bancos de dados podem ser classificados como bancos de dados de sistemas e bancos de dados dos usuários. Os banco de dados de sistema armazenam dados do sistema e também controlam o armazenamento temporário requerido para os dados de aplicação.

Cada instância do SQL Server pode suportar vários bancos de dados. Além disso, pode haver várias instâncias em um mesmo computador. Cada banco de dados pode suportar grupos de arquivos (filegroups), que proveêm a funcionalidade de distribuir os dados fisicamente. Um banco de dados pode possuir vários filegroups, mas o contrário não é possível. Após a criação do banco de dados, os filegroups do banco de dados podem ser adicionados.

O SQL Server utiliza a unidade básica de IO fixo (página) em 8KB. Para organizar melhor os dados, essas páginas são agrupadas em uma quantidade de oito contíguas entre si formando as chamadas extensões (extents). O espaço é gerenciado em termos de extensões. Cada página pertence a um objeto de um tipo (dado, índice etc), mas uma extensão pode pertencer a vários objetos.

Uma extensão em que as oito páginas pertencem ao mesmo objeto é considerada uma extensão uniforme, caso contrário, trata-se de uma extensão mista.

O SQL Server utiliza os filegroups para controlar a alocação das tabelas e dos índices. Os dados contidos em filegroup são proporcionalmente distribuídos entre os arquivos do filegroup. Se os filegroups não estiverem definidos, os objetos do banco de dados serão armazenados em um filegroup padrão que é implicitamente definido durante a criação do banco de dados.

Os segmentos utilizados no Oracle não são necessários no SQL Server. Em vez disso, o SQL Server distribui os dados através de RAID suportado em hardware ou software (solução presente no Windows ou em outro software).

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

TI para concursos

102

9.7 Exercícios

148. (ICMS-SP 2009) A arquitetura ANSI/SPARC aplicada aos bancos de dados divide-os em níveis com as seguintes características: I. O que se ocupa do modo como os dados são fisicamente armazenados. II. O que se ocupa do modo como os dados são vistos por usuários individuais. III. Nível lógico de comunidade ou apenas lógico (mais abstrato que o físico e diferente da visão do usuário individual). Em um projeto arquitetural, os itens I, II e III são classificados, respectivamente, como níveis

148

(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 independência de dados física e a independência de dados lógica são possibilitadas de forma ideal, respectivamente, por um

149

(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 organização do sistema de banco de dados, principalmente na ocorrência das mudanças de requisitos, visando à manutenção constante do melhor desempenho para a empresa, é denominado

150

(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 à linguagem

151

(a) MDX.xx

(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 assinatura

152

(a) pull. (b) push.

xx

(c) anônima. (d) de cliente. (e) de servidor.

TI para concursos

103

153. (ICMS-SP 2009) No SQL Server, uma única dimensão de banco de dados unida à tabela de fatos em uma chave estrangeira diferente, para produzir várias dimensões de cubo, é denominada dimensão

153

(a) de fatos. (b) de referência. (c) compartilhada. (d) com função múltipla.

xx

(e) muitos para muitos.

154. (ICMS-SP 2009) No formato de um bloco de dados do Oracle, um overhead é uma referência ao154

(a) Header. (b) Space free. (c) Table directory. (d) Space free e Row data, coletivamente. (e) Header, Table directory e Row directory, coletivamente.

xx

155. (ICMS-SP 2009) NÃO é um conjunto de extensões do Oracle que contém todos os dados para uma estrutura lógica de armazenamento dentro de uma tablespace:

155

(a) Automatic Undo Management. (b) Automatic Storage Management.

xx

(c) Temporary Segments. (d) Index Segments. (e) Data Segments.

156. (ICMS-SP 2009) Um database Oracle é constituído de um ou mais156

(a) datafiles, estruturas físicas de armazenamento, e cada datafile consiste de um ou mais tablespaces,

unidades lógicas de armazenamento. (b) datafiles, unidades lógicas de armazenamento, e cada datafile consiste de um ou mais tablespaces,

estruturas físicas de armazenamento. (c) tablespaces, unidades lógicas de armazenamento, e cada tablespace consiste de um ou mais datafiles,

estruturas físicas de armazenamento.xx

(d) tablespaces, estruturas físicas de armazenamento, e cada tablespace consiste de um ou mais datafiles,

unidades lógicas de armazenamento. (e) tablespaces, unidades lógicas de armazenamento, e cada tablespace consiste de um ou mais datafiles,

também unidades lógicas de armazenamento.

157. (ICMS-SP 2009) Considere a seguinte regra de Codd, aplicada aos bancos de dados relacionais: A descrição do banco de dados é representada no nível lógico da mesma forma que os dados ordinários, permitindo que usuários autorizados utilizem a mesma linguagem relacional aplicada aos dados regulares. O sentido dessa regra diz respeito à

157

(a) formação do catálogo.xx

(b) manipulação, por meio de visões. (c) independência física. (d) independência lógica. (e) independência de distribuição.

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 não-chave forem III . I, II e III podem ser corretamente preenchidos por:

158

(a) FNBC, 1FN, totalmente dependentes da totalidade da chave primária (b) 3FN, 2FN, independentes da chave primária (c) 3FN, 1FN, totalmente dependentes de parte da chave primária (d) 2FN, 1FN, totalmente dependentes de parte da chave primária (e) 2FN, 1FN, totalmente dependentes da totalidade da chave primária

xx

159. (ICMS-SP 2009) Considere a relação 1:N entre cliente e seus pedidos e a necessidade de exclusão de um determinado cliente. A fim de manter informações históricas sobre pedidos já efetuados, independentemente da existência do cliente que os fez, deseja-se que aqueles pedidos já efetuados pelo cliente excluído não sejam apagados. As chaves primárias de ambas e em cada tabela são definidas como única. Em um banco de dados relacional normalizado até a 3FN, o atendimento de tal requisito pode ser obtido por meio de

159

(a) restrição de chave estrangeira on delete set null.xx

(b) colocação de uma constante (ex. ‘9999’) nas chaves primárias dos pedidos do cliente excluído. (c) colocação de uma constante (ex. ‘9999’) nas chaves primárias de cada cliente excluído. (d) não limpeza das chaves estrangeiras dos pedidos, existentes na tabela do cliente. (e) restrição de chave estrangeira on delete cascade.

TI para concursos

104

160. (ICMS-SP 2009) Em um banco de dados multidimensional, considere, por exemplo, que os dados podem ser representados como um array de três dimensões, correspondendo a produtos, clientes e períodos de tempo. Dessa forma, um determinado valor individual em uma célula pode representar a quantidade de um produto vendido a um cliente em um dado momento. De acordo com essa consideração,

160

(a) produtos e clientes são variáveis independentes, e períodos de tempo e quantidade são variáveis dependentes.

(b) produtos, clientes e períodos de tempo são variáveis dependentes, e quantidade é uma variável independente.

(c) produtos, clientes e períodos de tempo são variáveis independentes, e quantidade é uma variável dependente.

xx

(d) produtos são variáveis dependentes, e clientes, períodos de tempo e quantidade são variáveis independentes.

(e) produtos são variáveis independentes, e clientes, períodos de tempo e quantidade são variáveis dependentes.

161. (ICMS-SP 2009) As variáveis dimensionais aplicadas em um MOLAP estão frequentemente relacionadas em hierarquias, que determinam meios para agregar dados das células a elas associados. Nesse contexto, os operadores do processador que permitem percorrer (para acesso e não para criação) as hierarquias do nível de agregação mais baixo para o mais alto executam a função

161

(a) snow flake. (b) roll back. (c) drill down. (d) rolap. (e) drill up.

xx

162. (ICMS-SP 2009) Se uma empresa de grande porte, com alto volume de transações e informações, resolver iniciar um projeto usando o conceito de Data Mart (DM) em vez de Data Warehouse (DW), independentemente disso ser ou não a melhor opção, os fatores que a levam a tal decisão podem ser justificados por:

I. Possibilidade de extrair e preparar os dados diretamente de fontes de interesse específicas, fornecendo

acesso mais rápido pela não necessidade de sincronia com dados de outras fontes.

II. Menor risco quanto ao sucesso do projeto.

III. Necessidade imediata de informações 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 análise dos fatos relacionados à função que exerce em uma organização. Essa análise deve ser feita com as ferramentas e os dados disponíveis, permitindo aos executivos e gerentes detectar as tendências e tomar as decisões com eficiência e eficácia. Devido a essa necessidade, surgiu o conceito de Business Intelligence – “BI”. Assinale a alternativa que indique duas características dos atuais sistemas de Business Intelligence.

163

(a) procurar relações de causa e efeito / extrair e integrar dados de múltiplas fontes.xx

(b) evitar a utilização de ferramentas automatizadas / desprezar dados contextualizados. (c) extrair e integrar dados de múltiplas fontes / evitar a utilização de ferramentas automatizadas. (d) desprezar dados contextualizados / trabalhar exclusivamente com fatos reais e não hipotéticos. (e) trabalhar exclusivamente com fatos reais e não hipotéticos / procurar relações de causa e efeito.

164. (TRT FCC 2008) No âmbito do OLAP, gráficos de produtos são generalizações da estrutura de ...... apresentada por HRU (Harinarayan, Rajaraman e Ullman), na qual as dimensões podem ter hierarquias associadas. Preenche corretamente a lacuna:

164

(a) tabela. (b) roll-up. (c) data mart. (d) hipercubo.

xx

(e) drill-down.

165. Uma das funcionalidades do OLAP, utilizada para realizar operações de projeção nas dimensões, compreende a extração de informações sumarizadas de um cubo de dados e extração de um "subcubo", a partir do valor de uma dimensão. Trata-se de

165

(a) sorting. (b) pivot and sorting. (c) drill-up. (d) selection. (e) slice and dice.

xx

166. Para eliminar a condição de existência de valores não atômicos em uma coluna de tabela relacional, 166

(a) deve ser aplicada, no mínimo, a primeira Forma Normal.

xx

(b) devem ser aplicadas, no mínimo, as quatorze regras de Codd. (c) deve ser aplicada, no mínimo, a Forma Normal Boyce-Codd. (d) deve ser aplicada, no mínimo, a terceira Forma Normal. (e) devem ser aplicadas, no mínimo, as regras de integridade referencial.

TI para concursos

105

167. Um banco de dados relacional normalizado significa que as relações que o compõe atendem à 167

(a) 1FN, no máximo. (b) 3FN, no mínimo.

xx

(c) 2FN, mas não necessariamente 1FN. (d) 2FN, no máximo. (e) 3FN, mas não necessariamente a 1FN e 2FN.

168. Uma relação estará na Segunda Forma Normal (2FN) se ela estiver na 1FN e todos os atributos168

(a) não chave forem dependentes não transitivos da chave primária. (b) não chave forem totalmente dependentes da chave primária.

xx

(c) chave forem dependentes não transitivos das chaves estrangeiras. (d) chave forem totalmente dependentes das chaves estrangeiras. (e) chave forem totalmente dependentes dos atributos não chave.

169. Em um modelo E-R, o tipo de associação unária é aquela em que 169

(a) uma entidade se relaciona unicamente com uma outra entidade. (b) uma entidade se relaciona com ela própria.

xx

(c) uma entidade não se relaciona com qualquer outra entidade, nem com ela própria. (d) um relacionamento é do tipo 1:1, somente. (e) um relacionamento é do tipo 1:1 ou N:1.

170. Sobre um modelo E-R, considere que uma chave primária I. simples pode ser constituída de um atributo atômico ou de um atributo composto. II. simples pode ser constituída de apenas um atributo atômico. III. composta pode ser constituída de um atributo composto. IV. composta pode ser constituída de dois ou mais atributos atômicos. Está correto o que consta APENAS em

170

(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 informação que fornece um arquivo para ser tratado pelo sistema objeto da modelagem, utilizando DFD da análise estruturada, é caracterizado como

171

(a) fluxo de dados. (b) entidade externa.

xx

(c) depósito 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 função.

xx

(b) uma função pode enviar, mas não receber um fluxo de dados de um depósito de dados. (c) uma entidade externa representa a mesma coisa que uma entidade no modelo entidade relacionamento. (d) uma entidade externa pode enviar, mas não receber um fluxo de dados de um depósito de dados. (e) uma entidade externa pode receber, mas não enviar um fluxo de dados a um depósito de dados.

173. Quando dois conjuntos de dados são concatenados de acordo com uma determinada condição, representa o resultado da operação relacional

173

(a) junção.xx

(b) união. (c) restrição. (d) projeção. (e) intersecção.

174. Um comando SQL executa uma operação que exibe I. certas colunas de uma relação, denominada subconjunto vertical. II. todas as linhas que aparecem em ambas as relações. III. apenas aquelas linhas que existem em ambos os conjuntos. As definições acima correspondem, respectivamente, aos operadores relacionais

174

(a) união, projeção e intersecção. (b) união, intersecção e projeção. (c) intersecção, projeção e união. (d) projeção, união e intersecção.

xx

(e) projeção, intersecção e união.

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

(a) aumenta a capacidade não-procedural da SQL, oferecendo e combinando blocos de construtores

procedurais.xx

(b) constitui uma interface básica pela qual pode-se entrar e executar comandos SQL para manipulações

genéricas de um banco. (c) trata-se de uma linguagem que identifica quais as informações necessárias e não 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.

TI para concursos

106

176. A linguagem PL/SQL é uma estrutura em blocos, compostos basicamente das partes declarativa, executável e manipulação de exceções, as quais são, respectivamente, de uso

176

(a) opcional, para todas as partes. (b) obrigatório, para todas as partes. (c) opcional, obrigatório e obrigatório. (d) obrigatório, obrigatório e opcional. (e) opcional, obrigatório e opcional.

xx

177. Um bloco PL/SQL que está associado a um evento ocorrido no banco de dados Oracle é do tipo177

(a) função. (b) gatilho.

xx

(c) anônimo. (d) procedimento. (e) dinâmico.

178. A estrutura lógica de armazenamento nas bases de dados Oracle é representada na seqüência hierárquica de 178

(a) segmentos, blocos de dados e extensões. (b) segmentos, extensões e blocos de dados.

xx

(c) extensões, segmentos e blocos de dados. (d) extensões, blocos de dados e segmentos. (e) blocos de dados, segmentos e extensões.

179. Na estrutura lógica do Oracle NÃO estão contidos179

(a) extents. (b) data blocks. (c) data files.

xx

(d) schemas. (e) tablespaces.

180. Todos os dados de uma tabela Oracle são armazenados em extents de um180

(a) data segment.

xx

(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 cláusulas do comando de consulta da linguagem SQL devem ser escritas na seqüência 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 composição de peças e respectivos componentes (peças são compostas de peças), em um DER, usa-se

183

(a) o grau de relacionamento quaternário. (b) a cardinalidade ternária. (c) a entidade fraca. (d) a entidade associativa. (e) o auto-relacionamento.

xx

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

(a) uma elipse. (b) um retângulo. (c) um círculo. (d) um losango.

xx

(e) números da cardinalidade.

185. Considere, as definições abaixo: I. Especificação do número de ocorrências de um objeto que pode ser relacionado ao número de ocorrências de outro objeto. II. Especificação da participação (ou não) do relacionamento de um objeto em particular. Na modelagem de dados estas definições pertencem, respectivamente, a

185

(a) grau e cardinalidade. (b) cardinalidade e grau. (c) cardinalidade e modalidade.

xx

(d) modalidade e cardinalidade. (e) modalidade e grau.

TI para concursos

107

186. Em um banco de dados relacional, a operação de exclusão sobre a tabela referenciada se propaga para todas as chaves estrangeiras correspondentes quando usada a expressão SQL ANSI on delete

186

(a) set default. (b) spread. (c) propagate. (d) cascade.

xx

(e) set null.

187. Uma transação executará qualquer operação somente depois que o gerenciador de banco de dados conceder o bloqueio do dado por meio do

187

(a) gerenciador de arquivos. (b) seletor de estratégia. (c) controlador de concorrência.

xx

(d) gerenciador de recuperação. (e) gerenciador de buffer.

TI para concursos

108

10 Programação de Sistemas

10.1 Lógica de Programação

O computador, como todo componente eletrônico, só entende sinais de carga elétrica sequenciadas, um choquinho após o outro. Dividido em diversos tipos de componentes físicos que se comportam de forma diferente ao estímulo elétrico, pode-se determinar a ação de um equipamento eletrônico alterando-se o sequenciamento destas peças pela ação de chaves (componentes eletrônicos) que desviam o fluxo de energia. Esta definição da sequência de chaves, que determina por onde e quando a corrente elétrica vai passar resultando em um comportamento previsto do sistema elétrico, é chamada de programação.

Os primeiros programadores definiam e alteravam estas chaves diretamente com fios em placas. A evolução permitiu que a programação pudesse ser feita por sequenciamento lógico de números que poderiam ser transferidos para os computadores através de cartões 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 inglês), textos inteligíveis, em comandos em linguagem da máquina (números). Estes programas são os compiladores. Endereços de memória que contém dados recebem nomes pelo programador (variáveis). Programar passou, então, a ser redigir um texto obedecendo certas regras de sintaxe, submeter o texto a um compilador que faz a tradução para a linguagem que a máquina consegue processar.

Por certo tempo, programação consistia em sequenciar comandos e atribuir “endereços” (números ou índices), a eles. Para se repetir uma sequencia de comandos, ou seja, fazer uma iteração, utilizava-se um comando para desviar o processamento para o endereço do primeiro comando da sequencia. Os comandos eram basicamente: leia, armazene na variável, faça a conta, grave (na tela, disco ou impressora) e desvie para o endereço tal, além do comando de condição SE (IF - se o valor for tanto, pule para o endereço tal). Era a programação indexada. Tudo era controlado por números e o programador tinha que pensar como máquina. 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 criação dos comandos do tipo declaração (statement): enquanto (while), repita-até que (repeat until), caso (case) e para-faça (for do); o sequenciamento de comandos passou a apresentar o formato de uma contrução lógica, dispensando a numeração das linhas de programação. 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 programação estruturada, procedural ou procedimental. O próprio 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.

TI para concursos

109

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 número inteiro positivo (zero para terminar): ‘);

Readln(Numero);

If Numero>=0 then

Writeln(‘O fatorial de ‘, Numero, ‘ é ‘, Calcula_Fatorial(Numero))

Else

Writeln(‘Valor inválido’);

Until Numero=0;

Writeln(‘Fim de processamento.’);

End.

A grande revolução na arte da programação de computadores foi quando alguém percebeu que o homem não deve pensar como máquina para escrever um programa, mas deve fazer o computador comportar-se como gente e compreender comandos humanos. Criou-se uma técnica de raciocínio 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, características ou, genericamente, atributos.

Tem comportamento. Pode ser móvel ou não, fazer coisas.

É formado por objetos menores (até o átomo, ou menor) que possuem também atributos e comportamentos

Quando esta técnica se transformou em uma linguagem, criou-se a programação orientada a objetos. Ela utiliza uma nova forma de fazer programas, não jogou fora todos os aspectos positivos da programaçao procedimental e estruturada, mas evoluiu estes conceitos. Os procedimentos e funções são chamados de métodos quando estão dentro de um objeto. As variáveis internas ao objeto são chamadas de propriedades ou atributos.

O conjunto de valores das propriedades formam o estado do objeto. Mensagens são ações de dispositivos externos (teclado, mouse, placa de rede, scanner, outros programas) ou de outros objetos que provocam mudanças de estado. Algumas mudanças do estado do objeto podem determinar uma situação em que algum método deve ser executado (ação). Por exemplo, um clique do mouse sobre um objeto botão muda a propriedade “Clicado” de falso para verdadeiro. O seu novo estado pode desencadear uma sequencia de comandos ou métodos. Mudanças de estado que fazem uma ação são 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 série de ações que provocam mudanças de estado que podem desencadear outras ações.

10.1.1 Tipos de dados e variáveis

Durante o seu processamento, um programa deve necessitar de dados para efetuar cálculos e tratamentos e devolver informação ao usuário. Estes dados são introduzidos por qualquer meio, como digitação, envio de parâmetros por outro objeto ou leitura em um arquivo, depois armazenados em áreas da memória do computador chamadas de variáveis. Os valores armazenados nas variáveis podem ser utilizados através de seu endereço físico na memória (por apontadores ou pointers) ou, mais comum, por um nome atribuído á variável.

Da mesma forma que não se somam bananas com maçãs, o programa não costuma misturar tipos diferentes de dados em suas operações. O programador deve ter conhecimento dos tipos possíveis de dados para não provocar erros no processamento. Linguagens de programação são ditas tipadas

TI para concursos

110

quando exigem que as variáveis a serem utilizadas sejam pré-definidas como seu nome e tipo, como no pascal. São não tipadas quando as variáveis são definidas no momento de sua utilização, assumindo um determinado tipo de acordo com o valor atribuído a ela.

De forma geral, define-se como numérico os valores que serão utilizados para cálculos algébricos. São de tipo lógico as variáveis que assumem apenas dois estados, verdadeiro ou falso, ou equivalente (0 ou 1, v ou t, sim ou não etc). São alfanuméricas as variáveis que não são destinadas a cálculos, mas somente operações de comparações, buscas, concatenações ou simples exibição. São de tipo apontador, variáveis que armazenam endereços de memória.

Dependendo da linguagem de programação, as variáveis numéricas podem se subdividir em reais ou inteiras, e também em outras variações destes dois tipos, como inteiro não negativo, monetário, inteiro longo etc. O tipo alfanumérico também pode receber variações como memorando (texto), ou texto formatado.

Existem também outros tipos de armazenamento de dados na memória, que são agrupamentos de variáveis:

Vetor – conjunto de variáveis identificado por um nome e números inteiros positivos (começando em zero) para cada elemento. A parte numérica do nome da variável fica entre parênteses ou colchetes à direita do nome. Para se referir a uma posição do vetor, a parte numérica pode ser resultado de uma operação matemática. Um vetor que utiliza mais do que um número (dimensões) para identificar cada uma de suas posições (separados por vírgulas) é chamado de matriz.

Registro – grupo de variáveis de vários tipos, identificado por um nome. Cada variável dentro de um registro é chamada de campo.

Lista – conjunto de registros ligados por apontadores, usado em conjunto de dados hierárquicos em que a relação entre os dados não precisa ser representada em forma de matrizes, ou para armazenar dados de uma tabela na memória para algum tratamento especial.

Fila – sequência 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 – sequência 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 Programação orientada a objetos

A análise e o projeto orientados a objetos têm 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 programação que dão suporte a orientação a objetos são:

Smaltalk, Perl, Python, Ruby, PHP, ColdFusion, C++, Object Pascal, Java, JavaScript, ActionScript, Delphi (object pascal) e C#.

Os conceitos mais importantes na programação orientada a objetos são:

Objetos (instâncias) e encapsulamento

Classes

Persistência

Métodos e propriedades

Herança e classes hierárquicas

Polimorfismo

Interfaces

Sobrecarga

Para uma linguagem ser considerada verdadeiramente orientada a objetos, a linguagem de programação deve oferecer, no mínimo, as características de: encapsulamento, herança e polimorfismo.

10.2.1 Objetos

Objeto é uma abstração do mundo real. Objetos de software são modelados de acordo com os objetos do mundo real, ou seja, possuem estado e comportamento. Um objeto de software armazena seu estado em variáveis e implementa seu comportamento com métodos. Estas variáveis e métodos são formalmente chamados de variáveis de instância e métodos de instância a fim de distingui-los de variáveis e métodos de classe.

As variáveis de um objeto fazem parte do seu núcleo (centro). Os métodos envolvem e escondem (empacotam) o núcleo do objeto de outros componentes da aplicação. Empacotar as variáveis de um objeto sobre proteção de seus métodos é chamado de encapsulamento. O encapsulamento é utilizado

TI para concursos

111

para esconder detalhes de implementação. Este é um dos princípios fundamentais da programação orientada a objetos.

Às vezes, por razões de eficiência ou implementação, um objeto deseja expor algumas de suas variáveis ou esconder alguns de seus métodos. Esta capacidade de controlar quais componentes podem acessar seus métodos e suas variáveis é chamada de Controle de Acesso.

Cada objeto tem sua identidade, o que significa que dois objetos são distintos mesmo que eles apresentem exatamente as mesmas características (atributos iguais). Esta identificação de objeto deve ser única, uniforme e independente do conteúdo do objeto.

Em geral, os objetos possuem, pelo menos, dois métodos:

Construtor: define o comportamento no momento da criação de um objeto de uma classe;

Destrutor: define o comportamento no momento da destruição do objeto de uma classe. Normalmente utilizado para liberar recurso (memória) do sistema.

10.2.2 Classe

Objetos podem apresentar métodos e atributos (propriedades) idênticos. Em relação a estes elementos em comum, dizemos que eles pertencem a uma mesma classe. Na programação orientada a objeto, classe é uma abstração, enquanto que, neste contexto, objeto é considerado um elemento fático.

Uma classe é um modelo, ou protótipo, que define as variáveis (estado) e os métodos (comportamento) comuns a todos os objetos do mesmo tipo. Na classe são definidas as variáveis e implementados os métodos. Os objetos são criados a partir de suas classes.

Dois botões na tela pertencem à classe botão. 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 botão, cinza, em alto-relevo, com determinado comportamento ao clicar, pode ter duas instâncias na tela. Definidas as características de um tipo de botão, ao criar (instanciar) um objeto, por uma instrução determina-se que ele fará parte da classe, e isto fará com que ele herde todas as características de um botão típico. Depois de instanciado, ações poderão alterar seu estado, como sua aparência e comportamento.

Na programação orientada a objetos, implementa-se um conjunto de classes que definem os objetos presentes no sistema de software. Cada classe determina o comportamento (métodos e eventos) e os estados possíveis (valores dos atributos) de seus objetos, assim como o relacionamento com outros objetos.

As classes não são diretamente suportadas em todas as linguagens de objetos, e não são necessárias para que a linguagem seja orientada a objetos.

A classe define as características comuns e os objetos são instâncias dessa classe, com estado próprio.

10.2.3 Persistência

Alguns objetos são criados, cumprem sua função e são destruidos logo em seguida. Outros objetos continuam por tempo indeterminado e isto é chamado de persistência. Não faz sentido falar de persistência de classes, somente de instâncias (objetos).

10.2.4 Métodos

Método é uma sub-rotina interna a um objeto, que pode ser executado por uma ação externa, isto é, ao receber uma mensagem, ou por uma ação interna de um evento.

10.2.5 Atributos

Os atributos são os elementos que definem a estrutura de uma classe. Os atributos também são conhecidos como variáveis de classe, e podem ser divididos em dois tipos básicos: atributos de instância e de classe.

TI para concursos

112

Os valores dos atributos de instância 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 também de atributos estáticos ou constantes.

10.2.6 Mensagens

Objetos modificam seu estado por meio do recebimentos de mensagens. Alguns métodos de um objeto que recebe a mensagem precisam de informações, os parâmetros, para saber exatamente o que fazer.

Assim, três componentes fazem parte de uma mensagem:

o objeto para onde a mensagem é endereçada;

o nome do método a realizar;

parâmetro(s) necessários para realizar o método;

10.2.7 Herança

A herança é um mecanismo que permite criar novas classes a partir de classes já existentes, aproveitando-se das características existentes na classe a ser extendida. Com a herança é possível criar classes derivadas (sub-classes) a partir de classes bases (superclasses).

As subclasses herdam todas as características de suas superclasses, como suas variáveis (estado) e seus métodos (comportamento). Entretanto, as subclasses não estão limitadas ao comportamento herdado de sua super-classe. As subclasses podem adicionar variáveis e métodos a aqueles herdados.

As subclasses, também, podem redefinir (override) métodos herdados e oferecer implementações especializadas para estes métodos. O conceito de herança pode ser aplicado para mais de um nível. A árvore de herança, ou hierarquia de classe, pode ser tão profunda quanto necessário. Os métodos e variáveis são herdados por meio dos níveis. Em geral, quanto mais baixa na hierarquia for a posição da classe, mais específico é o seu comportamento.

Como benefícios do conceito de herança, podemos citar:

Programadores podem definir classes abstratas que determinam comportamentos genéricos.

Subclasses oferecem comportamentos especializados a partir de elementos básicos comuns, oferecidos pela superclasse.

A utilização de herança promove o reuso e reaproveitamento de código existente, tornando a manutenção do código mais eficiente.

A superclasse define e pode implementar parcialmente o comportamento de uma classe, mas a maioria das informações da classe fica indefinida ou não é implementada.

A herança múltipla ocorre quando uma classe pode estender características de várias 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 codificação confusa o que dificulta a manutenção do código. A linguagem Java não suporta herança múltipla, apenas herança simples. Já a linguagem C++ oferece suporte à herança múltipla.

Uma linguagem ao utilizar herança múltipla está sujeita a dois problemas: colisão de nomes (nomes idênticos nas classes superiores) e herança repetida (classe herda de uma classe superior que herda de uma classe comum);

10.2.8 Polimorfismo

Segundo a terminologia de orientação 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 métodos que têm a mesma assinatura (nome, lista de parâmetros e retorno), mas comportamentos distintos, especializado para cada classe derivada, usando para tanto uma referência a um objeto do tipo superclasse.

A decisão sobre qual método deve ser selecionado, de acordo com o tipo da classe derivada, é tomada em tempo de execução por meio do mecanismo de ligação tardia. No caso do polimorfismo, é necessário que os métodos tenham exatamente a mesma identificação, sendo utilizado o mecanismo de redefinição de métodos.

Os benefícios do polimorfismo são: a clareza e manutenção do código, a divisão da complexidade e aplicações flexíveis. 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 existência de vários métodos de mesmo nome, porém com assinaturas levemente diferentes, ou seja, variando no número e tipo de argumentos e o

TI para concursos

113

valor de retorno. Ficará a cargo de o compilador escolher de acordo com as listas de argumento os procedimentos ou métodos 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 relação de métodos, com seus parâmetros, das propriedades que podem ser acessados por outros objetos e também pode incluir declarações de constantes.

Uma interface apresenta somente as definições de métodos, sem sua implementação. A classe que implementa a interface deve implementar todos os métodos definidos na interface.

10.2.11 Pacotes

Para tornar as classes mais fáceis 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 diretório, ou seja, as classes e as interfaces de um mesmo pacote devem estar em um mesmo diretório.

A utilização de pacotes proporciona as seguintes vantagens:

Fica mais fácil para outros programadores determinar quais classes e interfaces estão relacionadas.

Os nomes das classes de um pacote não irão 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, variáveis e métodos) públicos são acessíveis fora do pacote onde foram definidos.

10.3 Programação na WEB

Visualizar uma página web ou outro recurso disponibilizado normalmente inicia ou ao digitar uma URL no navegador ou seguindo (acessando) uma hiperligação. Primeiramente, a parte da URL referente ao servidor web é separada e transformada em um endereço IP, por um banco de dados da Internet chamado Domain Name System (DNS). O navegador estabelece então uma conexão TCP-IP com o servidor web localizado no endereço IP retornado.

58

O próximo passo é o navegador enviar uma requisição HTTP ao servidor para obter o recurso indicado pela parte restante da URL (retirando-se a parte do servidor). No caso de uma página web típica, o texto HTML é recebido e interpretado pelo navegador, que realiza então requisições adicionais para figuras, arquivos de formatação, arquivos de script e outros recursos que fazem parte da página.

O navegador então renderiza a página na tela do usuário, assim como descrita pelos arquivos que a compõe.

A funcionalidade da Web é baseada em três padrões:

URI, um sistema que especifica como cada página de informação recebe um "endereço" único onde pode ser encontrada.

HTTP, um protocolo que especifica como o navegador e servidor web comunicam entre si.

HTML, uma linguagem de marcação para codificar a informação de modo que possa ser exibida em uma grande quantidade de dispositivos.

Desta forma, programar para Web é escrever páginas em HTML. Para isto, o programador pode escrever um texto em HTML puro e gravar este arquivo em um servidor web. Estes textos são chamados de páginas estáticas. Elas só mudam quando o programador alterar o arquivo.

Porém, o servidor web utilizado pode ter instalado programas que geram páginas HTML no momento em que a requisição chega. Neste caso, o texto requisitado não é um texto HTML, mas é um código em alguma linguagem de programação que, ao ser processado pelo servidor, gera um texto HTML dentro das especificações da requisição. Estes textos são chamados de páginas dinâmicas. Estas páginas

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

TI para concursos

114

permitem a interação com o usuário e com gerenciadores de bancos de dados, podendo gerar páginas HTML diferentes a cada instante.

Assim, ao projetar um site, o programador decide se vai usar páginas estáticas, dinâmicas ou as duas.

10.3.1 Linguagem HTML

HTML (acrônimo para a expressão inglesa HyperText Markup Language, que significa Linguagem de Marcação de Hipertexto) é uma linguagem de marcação utilizada para produzir páginas na Web. Documentos HTML podem ser interpretados por navegadores. A tecnologia é fruto do "casamento" dos padrões HyTime e SGML.

59

HyTime é um padrão para a representação estruturada de hipermédia e conteúdo baseado em tempo. Um documento é visto como um conjunto de eventos concorrentes dependentes de tempo (como áudio, vídeo, etc.), conectados por hiper-ligações. O padrão é independente de outros padrões de processamento de texto em geral.

SGML é um padrão de formatação de textos. Não foi desenvolvido para hipertexto, mas tornou-se conveniente para transformar documentos em hiper-objetos e para descrever as ligações.

Todo documento HTML apresenta tags (tags), elementos entre parênteses angulares (sinais de maior e menor). Esses elementos são os comandos de formatação da linguagem. A maioria das tags tem sua correspondente de fechamento:

<tag>...</ tag >

Isso é necessário porque as tags servem para definir a formatação de uma porção do documento, e assim marcamos onde começa e termina o texto com a formatação especificada por ela. Alguns elementos são chamados “vazios”, pois não marcam uma região de texto, apenas inserem algum elemento no documento:

Uma tag é formada por comandos, atributos e valores. Os atributos modificam os resultados padrões dos comandos e os valores caracterizam essa mudança.

A estrutura de um documento HTML apresenta os seguintes componentes:

<html>

<head>

<title>Título do Documento</title>

</head>

<body>

texto,

imagem,

links,

...

</body>

</html>

De uma maneira geral o HTML é um poderoso recurso, sendo uma linguagem de marcação muito simples e acessível voltada para a produção e compartilhamento de documentos e imagens.

As tags HTML não são sensíveis à maiúsculas ou minúsculas, portanto tanto faz escrever <HTML>, <Html>, <html> ou <HtMl>.

As tags básicas de HTML, cuja presença é altamente recomendada nas páginas são:

<html>: define o início de um documento HTML e indica ao navegador que todo conteúdo posterior deve ser tratado como uma série de códigos HTML.

<head>: define o cabeçalho de um documento HTML, que traz informações sobre o documento que está sendo aberto.

<body>: define o conteúdo 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 página, como cor de fundo, margens, e outras formatações.

Dentro do cabeçalho podemos encontrar os seguintes comandos:

<title>: define o título da página, que é exibido na barra de título dos navegadores.

<style>: define formatação em CSS (Cascading Style Sheets), uma linguagem de estilo utilizada para definir a apresentação de documentos escritos em HTML ou XML.

<script>: define programação de certas funções em página com scripts (códigos de programa) em diversas linguagens web cliente, como Javascrip, Visual Basic Script, DHTML ou CSS.

59 http://pt.wikipedia.org/wiki/HTML

TI para concursos

115

Applets de Java

<link>: define ligações da página com outros arquivos como feeds, CSS, scripts etc.

<meta>: define propriedades da página, como codificação de caracteres, descrição da página, autor, etc. São meta informações sobre documento. Tais campos são muitos usados por mecanismos de busca (como o Google) para obterem mais informações sobre o documento, a fim de classificá-lo melhor. Por exemplo, pode-se adicionar o código <meta name="description" content="descrição da sua página" /> no documento HTML para indicar ao motor de busca que texto de descrição apresentar junto com a ligação para o documento.

As tags <style> e <script> servem tanto para delimitar o espaço usados pelos códigos na página quanto para invocar códigos existentes em outros arquivos externos.

Dentro do corpo podemos encontrar outras várias tags, como por exemplo:

<h1>, <h2>,... <h6>: cabeçalhos e títulos no documento em diversos tamanhos. (quanto menor for o número, maior sera o tamanho da letra)

<p>: novo parágrafo.

<br>: quebra de linha.

<table>: cria uma tabela (linhas são criadas com <TR> e novas células com <TD>. Já os cabeçalhos de coluna são criados com a tag <TH>.)

<div>: determina uma divisão na página a qual pode possuir variadas formatações.

<font>: altera a formatação (fonte, cor e tamanho) de um trecho do texto.

<b>, <i>, <u> e <s>: negrito, itálico, sublinhado e riscado, respectivamente.

<img>: imagem.

<a>: hiper-ligação para um outro local, seja uma página, um e-mail ou outro serviço.

<textarea>: caixa de texto (com mais de uma linha); estas caixas de texto são muito usadas em blogs, elas podem ser auto selecionáveis e conter outros códigos a serem distribuídos.

<acronym>: acrônimo (sigla)

<cite>: citação

<address>: endereço

Uma propriedade importante dos documentos HTML é a possibilidade de fazer hiperligações. Para isso usa-se a tag <a> (do inglês, anchor). Esta tem os atributos: href que define o alvo da hiperligação (que pode ser uma página de Internet, uma parte da mesma página ou um endereço de email) ou name que define um alvo nessa página (a onde se pode fazer uma hiperligação usando a tag a com o atributo href). Exemplos:

<a href="http://pt.wikipedia.org/">Clique aqui para aceder à página principal da Wikipédia em português.</a>

<a name="nome">texto</a>

Os caracteres especiais definem-se usando comandos que começam com & e terminam com um ;. Alguns exemplos incluem &aacute; (á), &agrave; (à), &atilde; (ã), &acirc; (â), &auml; (ä) e &ccedil; (ç). Qualquer outra vogal pode ser substituída pelo a destes exemplos, incluindo maiúsculas.

10.3.2 Linguagens web de servidor

Para a criação de páginas dinâmicas, existem diversas linguagens de programação 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 criação de documentos com dados organizados de forma hierárquica, 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 propósito principal é a facilidade de compartilhamento de informações através da Internet.

60

Pela sua portabilidade, já que é um formato que não depende das plataformas de hardware ou de software, um banco de dados pode, através de uma aplicação, escrever em um arquivo XML, e um outro banco distinto pode ler então estes mesmos dados.

Este exemplo demonstra a sintaxe flexível do XML sendo usada para descrever uma receita de pão:

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

TI para concursos

116

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

<receita nome="pão" tempo_de_preparo="5 minutos" tempo_de_cozimento="1 hora">

<titulo>Pão simples</titulo>

<ingredientes>

<ingrediente quantidade="3" unidade="xícaras">Farinha</ingrediente>

<ingrediente quantidade="7" unidade="gramas">Fermento</ingrediente>

<ingrediente quantidade="1.5" unidade="xícaras" 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="pão" tempo_de_preparo="5 minutos" tempo_de_cozimento="1 hora">

"Receita" é o nome principal para o seu documento. Note que a semelhança 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 conteúdos são inseridos entre tags (marcadores) de mesmo nome, sendo que a segunda tag tem uma barra (/) antes do nome.

O XML apresenta algumas regras básicas:

Letras maiúsculas e minúsculas são 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 não 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="xícaras">

10.4 Conceitos de linguagem de programação 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 essência, é muito similar ao J2EE (Java 2 Enterprise Edition).

Um compilador .Net gera um código intermediário, e quando é executado, o compilador JIT (Just in Time) traduz este código intermediário para código nativo do processador, com um enorme ganho de performance.

A .Net também oferece independência de plataforma, hardware e linguagem de programação.

TI para concursos

117

10.4.1 arquitetura da .Net

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

10.4.2 Linguagens de programação

Esta é a primeira camada da plataforma. Neste nível ficam as ferramentas de desenvolvimento e os respectivos compiladores.

A .Net oferece independência de linguagem. Atualmente existem mais de trinta com suporte para .Net. Todas as linguagens .Net obrigatoriamente devem seguir os padrões da plataforma. Quando dizemos que uma linguagem é compatível 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 características herdadas do C++ e Java, mas muito mais fácil de aprender e utilizar

VB.Net, a versão do Visual Basic que foi reescrito para a plataforma

C++ Embedded, a versão C++ da .Net, pouquíssimo usada

J# (leia-se Jei Sharp), a versão Java da .Net, também muito pouco usada, cujo objetivo é apenas facilitar a migração dos desenvolvedores Java para a .Net.

Oferece total compatibilidade com suas linguagens, onde códigos escritos numa determinada linguagem podem ser executadas em outra sem nenhum problema. Ou seja, é possível escrever uma classe em C#, herdá-la em VB.Net e usá-la no C++ Embedded (a versão C++ da .Net).

10.4.3 Common Language Specification (CLS)

A Microsoft liberou um conjunto de especificações que uma linguagem deve possuir para ser considerada compatível com .Net. Como a IL (ou o assembly .Net) é uma linguagem muito rica, não é necessário que sejam implementadas todas suas funcionalidades, basta uma parte dela para tornar a linguagem compatível. Esta é a razão pela qual muitas linguagens, procedurais ou oop, já estão executando sob o guarda-chuva da .Net. A CLS basicamente determina especificações de desenvolvimento e estabelece certos padrões. Por exemplo, não pode haver declaração de funções globais, acesso a ponteiros, herança múltipla e coisas deste tipo. Um detalhe importante é que, se seu código 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 também é um conjunto de padrões que define os tipos de dados básicos que a IL entende. Toda linguagem .Net deve mapear seus tipos primitivos para estes padrões. Isto possibilita que as linguagens se comuniquem passando/recebendo parâmetros de uma para a outra.

TI para concursos

118

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 são iguais, ou seja, um Int32.

10.4.5 Framework Class Library (FCL)

A .Net oferece uma gigantesca biblioteca de classes básicas para as tarefas mais comuns e usuais. A FCL contém milhares de classes para acesso a API do Windows e funções em geral, como manipulação de strings, estrutura de dados, entrada/saída, fluxos, segurança, multi-tarefa, programação em rede, Web, acesso a dados, etc. Ela é simplesmente a maior biblioteca padrão já fornecida por qualquer linguagem de programação ou ambiente de desenvolvimento. A melhor parte da FCL são seus padrões de desenvolvimento totalmente OOP, tornando seu acesso e utilização muito simples e previsíveis. Você utiliza estas classes em seus programas como utilizaria qualquer outra, inclusive aplicando herança 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 apresentação

Este nível define o tipo de interação do sistema com o usuário, que pode ser através de uma aplicação Web (utilizando o ASP.Net e Web Forms), Windows (utilizando Windows Forms) ou console (utilizando um prompt de comando, em modo caracter). Na minha opinião, os sistemas para Smart Devices (como Pockets, celulares, etc) também deveriam ser considerados uma camada de apresentação diferente, mas neste esquema eles foram incluídos com os Windows Forms.

10.4.7 ADO.Net

Esta camada é responsável pela comunicação das aplicações 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 instruções SQL diretamente;

• Modo desconectado: neste modo, você armazena informações de um banco de dados localmente, na memória do computador onde a aplicação está executando. Estas informações são armazenadas em objetos das classes Dataset, que permitem qualquer operação aceita por um banco de dados, também conhecida pela sigla CRUD (Create, Retrieve, Update, Delete) ou seja, criar, recuperar, atualizar e excluir linhas (ou registros). Periodicamente, uma conexão é feita com o banco e as informações são sincronizadas. Deste modo, você pode criar aplicações para Web ou dispositivos móveis (tipo Pocket PC), que não tem uma conexão permanente com o banco, ou mesmo aplicações 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 são máquinas ou processos diferentes. Na .NET Framework, esta tecnologia fornece a base para aplicações distribuídas, ou seja, ela simplesmente substitui o DCOM.

• DCOM é a abreviatura de Distributed Component Object Model, uma extensão do COM (Component Object Model) que permite que objetos se comuniquem em uma rede. Componentes COM tradicionais somente executam esta comunicação entre processos na máquina local. O DCOM usa o mecanismo RPC para enviar e receber informações 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 técnica, o desenvolvedor não precisa criar procedimentos específicos 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 própria Internet (que não passa de uma rede mundial gigantesca).

Implementações Remoting geralmente fazem distinção entre objetos remotos e objetos móveis.

• Objetos remotos: Remoting fornece a capacidade de executar métodos em servidores remotos, passando parâmetros e recebendo valores de retorno. O objeto remoto sempre fica num servidor e as outras máquinas apenas passam uma referência a ele.

• Objetos móveis: Neste caso os dados enviados são serializados (organizados) num formato que pode ser binário ou legível para nós, como XML, e de-serializados no outro contexto envolvendo o processo. Ambos, servidor e cliente, mantém cópias do mesmo objeto. Nestas cópias, os métodos são executados no contexto local e nenhuma mensagem vai trafegar de volta a máquina que originou o objeto. Na verdade, após a serialização e de-serialização os objetos copiados são idênticos aos objetos locais normais, e não há distinção entre um objeto servidor e um objeto cliente.

TI para concursos

119

A .NET expande este conceito para incluir a habilidade de definir contextos adicionais dentro de uma aplicação em execução, e o acesso a estes objetos além dos seus limites também passarão pelo .NET Remoting Framework.

10.4.9 Common Language Runtime (CLR)

O conceito mais importante da .Net Framework é a existência e funcionalidade do Common Language Runtime (CLR), também conhecida como .Net Runtime ou máquina virtual .Net. Ele é uma camada do framework que fica acima do sistema operacional e manipula a execução de todas as aplicações .Net. Nossos programas não se comunicam diretamente com o sistema operacional, apenas através do CLR. Ele é o responsável por chamar o compilador JIT (Just In Time, ou em tempo de execução) e transformar o código MSIL (Microsoft Intermediate Language ou assembly), gerado pelos compiladores .Net, em código nativo da plataforma onde está executando. Ou seja, quando você compila um programa ou dll .Net você obtém um arquivo com a extensão .exe ou .dll mas estes arquivos não executarão se o CLR não estiver instalado.

O CLR também contém o Garbage Collector (GC), ou coletor de lixo, o qual executa como uma tarefa de baixa prioridade e verifica por espaços de memória não referenciados, alocados dinamicamente. Se ele encontra algum dado que não é mais utilizado por nenhuma variável/referência, ele libera esta memória para o sistema operacional usá-lo para outros programas, quando necessário. A presença 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 especificação CLI é um padrão internacional para criar ambientes de desenvolvimento e execução no qual linguagens e bibliotecas trabalham juntas. Ela descreve como aplicações escritas em múltiplas linguagens de alto nível podem ser executadas em diferentes ambientes operacionais sem necessidade de se reescrever a aplicação, para levar em conta as características destes ambientes. Na plataforma .Net, a implementação da CLI é exatamente a CLR.

10.4.11 Operating System (OS)

No último nível, temos o sistema operacional (SO), responsável pela comunicação direta com os dispositivos (hardware) do computador. Para que uma aplicação .Net funcione em vários ambientes operacionais diferentes, deve haver uma CLR específica para cada um deles. Desta forma, uma vez escrita e compilada, uma aplicação pode ser transportada de uma ambiente para outro sem nenhum tipo de modificação (pelo menos, teoricamente).

10.4.12 Outros detalhes da .Net

• Assembly: Toda aplicação .Net, após compilada, é armazenada fisicamente numa unidade de códigos chamada assembly. Uma aplicação pode ser composta por um ou mais assemblies, os quais aparecem no sistema operacional como arquivos executáveis com a extensão .exe ou como bibliotecas dinâmicas com a extensão .dll.

• Metadados: São conjuntos de instruções geradas no processo de compilação de um programa .Net, junto com o MSIL, e que contém informações específicas da aplicação, que incluem, entre outras:

o Descrição de tipos: classes, estruturas, tipos enumerados, etc, que são usados no sistema, seja um executável ou dll;

o Descrição dos membros: propriedades, métodos, eventos, etc;

o Descrição de cada assembly: que é usado na aplicação e é necessário para sua execução;

o Versão: permite que aplicações homônimas, mas com versões diferentes, executem no mesmo computador sem conflitos.

Com as informações contidadas nos metadados, podemos dizer que uma aplicação .Net é auto-explicativa, dispensando a utilização do registro do Windows, usado pela maioria dos programas. Desta forma, a não ser que você crie chaves específicas no registro para seu uso, a instalação de um programa .Net se resume em copiar os assemblies da aplicação para a máquina que irá executá-lo.

TI para concursos

120

10.5 Exercícios

(ICMS-SP 2009) Instruções: Para responder às cinco próximas questões, utilize um computador hipotético que tem um registrador R (valor inicial: R=10) e 5 posições de memória de M1 até M5 (valores iniciais: M1=030, M2=005, M3=020, M4=015 e M5=010), com capacidade de 3 dígitos cada posição para armazenar valores inteiros de −999 e +999, e que reconhece os seguintes tipos de instruções (cada instrução tem um endereço “n” sequencial e termina com um ponto-e-vírgula):

INI; (= inicia o programa). FIM; (= termina o programa). IMP; (= imprime o conteúdo de R). LER nnn; (= carrega em R o número “nnn” digitado pelo teclado). CAR Mx; (= carrega em R o conteúdo de Mx). CAR n; (= carrega em R o número “n”). MOV Mx; (= move para Mx o conteúdo 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 instrução de endereço “n”). SE condição instruções1 SENAO instruções2; (= se “condição” =VERDADEIRA executa “instruções1”, se =FALSA executa “instruções2”).

188. (ICMS-SP 2009) Dado o programa: 1.INI; 2.LER 050; 3.SOM M3; 4.MOV M1; 5.SUB M5; 6.FIM; Ao término da execução, os conteúdos de M1, M3 e M5 são, respectivamente,

188

(a) 070, 020 e 010.xx

(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 término da execução, os conteúdos de R, M2 e M4 são, respectivamente,

189

(a) 015, 005 e 015 (b) 015, 015 e 005 (c) 015, 015 e 015

xx

(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 término da execução, o conteúdo impresso será igual a

190

(a) 10 (b) 11

xx

(c) 15 (d) 25 (e) 30

191. (ICMS-SP 2009) A lógica principal do programa apresentado na questão anterior representa uma estrutura de controle denominada estrutura

191

(a) sequence. (b) de repetição do-until. (c) de repetição do-while. (d) de seleção if-then-else.

xx

(e) de seleção 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; O programa que obtém o mesmo resultado final é:

192

(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

TI para concursos

121

193. (ICMS-SP 2009) Os valores das propriedades de um objeto em um determinado instante, que podem mudar ao longo do tempo, representam

193

(a) a instância de uma classe. (b) a identidade de um objeto. (c) o estado de um objeto.

xx

(d) o comportamento de um objeto. (e) as operações de uma classe.

194. (ICMS-SP 2009) Na orientação a objetos, ao nível de classe, são definidos os194

(a) atributos e os valores dos atributos. (b) atributos e a invocação das operações. (c) atributos e os métodos.

xx

(d) métodos e os valores dos atributos. (e) métodos e a invocação das operações.

195. (ICMS-SP 2009) Uma classe é uma abstração que ajuda a lidar com a complexidade e um bom exemplo de abstração é

195

(a) um aluno e as disciplinas que está cursando. (b) um professor e os cursos nos quais ministra aulas. (c) um funcionário e o departamento em que trabalha. (d) uma pessoa e o número do seu CPF na Receita Federal.

xx

(e) uma casa e a empresa que a projetou e construiu.

196. (ICMS-SP 2009) O método utilizado para inicializar objetos de uma classe quando estes são criados é denominado

196

(a) void. (b) interface. (c) agregação. (d) composição. (e) construtor.

xx

197. (ICMS-SP 2009) Sobre a visibilidade dos métodos na orientação a objetos considere: I. Os métodos públicos de uma classe definem a interface da classe. II. Os métodos privativos de uma classe não fazem parte da interface da classe. III. O nome dos métodos é a informação reconhecida como a assinatura dos métodos. Está correto o que consta APENAS em

197

(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 estratégia Microsoft .NET I. constituída das partes Common Language Runtime, bibliotecas de classes, ASP.NET e ADO.NET. II. para construir, implementar e executar aplicações e webservices. III. desenvolvida como um componente integral do Windows. Está correto o que consta em

198

(a) I, apenas. (b) II, apenas. (c) I e II, apenas. (d) II e III, apenas.

xx

(e) I, II e III.

199. (ICMS-SP 2009) NÃO é uma linguagem de programação do pacote Visual Studio 2005 que utiliza o mesmo IDE e as funcionalidades da .NET Framework:

199

(a) Visual Basic. (b) Visual FoxPro.

xx

(c) Visual C++. (d) Visual C#. (e) Visual J#.

TI para concursos

122

200. (ICMS-SP 2009) A .NET Framework 3.0 é o modelo de programação de código gerenciado da Microsoft, que integra os componentes da .NET Framework 2.0 às novas tecnologias

200

(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 publicação de aplicativos e para atualização de aplicativos implantados por meio diretamente do ClikOnce apenas para projetos criados com

201

(a) Visual Basic, Visual C# e Visual J#.xx

(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 opção de escolha no Visual Studio 2005 para usar Web Forms como interface de usuário no desenvolvimento de um aplicativo indica que o aplicativo deverá ser implantado no

202

(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 não no servidor. (d) computador cliente e que o .NET Framework deverá ser executado apenas no computador cliente e não

no servidor. (e) computador cliente e que o .NET Framework deverá ser executado tanto no servidor quanto no

computador cliente.

203. Uma ou mais instruções são executadas ou não, dependendo do resultado do teste efetuado. Esta afirmação define uma estrutura de controle de programação do tipo

203

(a) pilha. (b) seleção.

xx

(c) fila. (d) repetição. (e) seqüência.

204. A estrutura de dados de iteração na qual uma ação será executada pelo menos uma vez, antes da avaliação da condição, é implementada pelo comando básico

204

(a) condicional. (b) faça enquanto. (c) seqüencial. (d) de repetição.

xx

(e) de seleção.

205. Em uma hierarquia de classes é possível especificar operações com a mesma assinatura em pontos diferentes da hierarquia. Portanto, essas operações presentes nas classes-filha

205

(a) anulam o comportamento das operações existentes nas classes-mãe.xx

(b) herdam os atributos existentes nas classes-mãe. (c) são composições de alguns atributos existentes nas classes-mãe. (d) complementam o comportamento das operações existentes nas classes-mãe. (e) agregam as operações existentes nas classes-mãe.

206. As instâncias de uma classe são 206

(a) seus atributos. (b) suas superclasses. (c) suas operações. (d) seus objetos.

xx

(e) seus relacionamentos.

207. A nomenclatura da linguagem C++ para Chamada de Função e Classe Base corresponde, respectivamente, na programação orientada a objetos a

207

(a) Método e Subclasse. (b) Método e Superclasse. (c) Hereditariedade e Subclasse. (d) Mensagem e Subclasse. (e) Mensagem e Superclasse.

xx

208. Em um diagrama entidade relacionamento, uma situação de composição tal qual "empregado gerencia empregado", geralmente é apresentada como

208

(a) entidade fraca. (b) relacionamento associativo. (c) auto relacionamento.

xx

(d) relacionamento interativo. (e) relacionamento restritivo.

TI para concursos

123

209. A execução de uma expressão lógica obedece como prioridade a ordem dos operadores209

(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.

210. Respeitando as ordens de inserção e de retirada dos dados, uma estrutura de 210

(a) fila é também denominada LIFO ou LILO. (b) fila é também denominada FIFO ou FILO. (c) fila é também denominada FIFO ou LIFO. (d) pilha é também denominada FIFO ou FILO. (e) pilha é também denominada LIFO ou FILO.

xx

211. Uma fila dupla que se trata de uma lista linear na qual os elementos podem ser inseridos ou removidos de qualquer extremo denomina-se

211

(a) hashing. (b) grafo. (c) deque.

xx

(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>. Está correto o que consta APENAS em

212

(a) III. (b) II.

xx

(c) II e III. (d) I e III. (e) I e II.

213. Em XML pode-se definir um atributo, como informação adicional ao elemento, conforme o exemplo abaixo:213

(a) <funcionario> <sexo> masculino ... (b) <funcionario sexo=masculino> ... (c) <funcionario sexo="masculino">

xx...

(d) <funcionario> <sexo> "masculino" ... (e) <funcionario <sexo>= "masculino"> ...

214. NÃO é um tipo de dados considerado primitivo:214

(a) real. (b) inteiro. (c) lógico. (d) caracter. (e) matriz.

xx

TI para concursos

124

11 Sistemas Operacionais

11.1 Conceitos de administração de servidores em plataforma Windows

A administração de servidores Windows é feita sobre uma interface gráfica, com mouse, janelas e botões. Nem por isto a tarefa se torna fácil. O usuário precisa saber em que ícones clicar e que controles modificar.

Administrar servidores em plataforma Windows é instalar e manter em funcionamento os serviços que a rede necessita. Este serviços são acessíveis a partir do Painel de Controle e do menu Ferramentas administrativas.

O primeiro serviço que deve funcionar muito bem é administração de usuários, que consiste em criar contas, que são identificadas por um nome de usuário (login) e atribuir direitos a eles. Para esta função, utiliza-se o aplicativo “Contas de usuário”, no painel de controle. Usuários com direitos de administradores, conforme a sua configuração, podem fazer tudo, enquanto que usuário comuns só podem usar recursos definidos pelo administrador.

O Windows administra os recursos da rede dividindo-a em subredes chamadas de domínios. Em cada domínio há uma lista distinta de usuários e um servidor para controlar.

Um servidor na rede que centraliza a configuração de usuários em um domínio é o Primary Domain Controller (PDC), ou controlador primário de domínio. Em uma rede pode haver diversos servidores Windows, mas apenas um servidor primário de domínio para cada domínio, sendo os demais Backup Domain Controle (BDC), ou servidores de backup.

Os recursos oferecidos na rede estão, em geral, ligados a um computador. Este computador faz o papel de servidor deste recurso, como serviço de impressão, de conexão internet (proxy e firewall), de armazenamento de dados etc. Mas a permissão de acesso a todos os serviços passa pelo servidor primário do domínio.

Dois domínios diferentes podem se comunicar e os usuários de um ser autorizado pelo outro. Para isto o Windows utiliza o conceito de relação de confiança, que é estabelecido entre os dois domínios. Eles passam a se comportar como um único domínio, mas com duas lista de usuários.

O Windows utiliza o recurso Active Directory para administrar os domínios como se fossem uma estrutura de diretórios, agrupando domínios em árvores e estas em florestas.

11.2 Conceitos de administração de servidores em plataforma Linux

A administração 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 gráficas, chamados de shells, que facilitam a vida de usuários inesperientes.

Os servidores Linux com serviços para internet são mais usados do que os demais sistemas por sua estabilidade e confiabilidade. Assim são os servidores linux:

apache, servidor http, que adminstra páginas de internet,

proftpd, servidor ftp, para administrar transferências de arquivos

Bind, serviço dns, para administração de nomes de domínios

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 [opções] [origem] [destino]

mv move ou renomeia arquivos e diretórios. O processo é semelhante ao do comando cp mas o arquivo de origem é apagado após o término da cópia.

mv [opções] [origem] [destino]

chown muda dono de um arquivo/diretório. Opcionalmente pode também ser usado para mudar o grupo.

chown [opções] [dono.grupo] [diretório/arquivo]

chmod é usado para alterar permissões de arquivos (ou ficheiros) e diretórios (directórios ou pastas). Sua sintaxe é a seguinte:

chmod [permissões] arquivo

11.2.1.1 Gerenciando Usuários61

Para adicionar um usuário: 61 http://apostilas.netsaber.com.br/apostilas/1662.pdf

TI para concursos

125

adduser <usuário>

Em seguida é necessário definir uma senha para este usuário, utilizando o comando:

passwd <usuário>

Para remover um usuário e seu diretório home:

userdel -r usuário

Para obter as permissões de outros usuários:

su <usuário>

Se o campo <usuário> for omitido, o su intenderá como root. E para simular um login, executando os scripts de inicialização do usuário acrescenta-se “- “ entre su e o <usuário> , como no exemplo:

su - vinicius

11.2.1.2 Diretório /etc

O diretório /etc contém todas as configurações do servidor, por isso deve-se conhecer todo o seu conteúdo e também ter uma preocupação especial com as permissões de arquivos nele contidos:

passwd - ficam os usuários cadastrados no sistema. Cada linha corresponde a um usuário 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:Diretório:Shell Login: É a identificação do usuário que também pode ser usado para identificação do email. Senha: “ x “ informa que a senha está em outro arquivo mais seguro. Id: código único para o Linux identificar cada usuário. Nunca deve-se ter dois usuários com o mesmo

código. Gid: código do grupo primário que o usuário pertence. Nome e Dados: usado para armazenar informações sobre o usuário como nome, telefone, sala, etc..

Esses dados são separados por “,” e devem obedecer um padrão. Diretório: informa qual é o directório home, do usuário. Shell: shell default do usuário. Para usuários que não precisam de shell deve-se colocar “/dev/null”.

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

group - descreve quais são 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 próximo campo são os usuários pertencentes a este grupo, observando que os mesmos são separados por “,“.

Inittab - arquivo principal de inicialização do Linux, ele é quem dá inicio aos demais arquivos dentro do diretório /etc/rc.d . O modo mais usado é o “3” que indica para iniciar todas as tarefas, mas continuar no console. Existe também o modo “5” que entra com a tela de login já em modo gráfico. Veja detalhes no Apêndice E, Níveis de Execução no Red Hat Linux .

Fstab - configura os sistemas de arquivos montados durante o processo de inicialização do Linux. Estabelece os pontos default de montagem do sistema. O arquivo /etc/fstab permite configurar o sistema para montar partições, cdroms, disquetes e compartilhamentos de rede durante o boot. Cada linha é responsável por um ponto de montagem.

login.defs - É o arquivo de configurações do login, possui informações valiosas para melhorar a segurança do seu ambiente. É um arquivo muito simples de configurar pois é baseado em exemplos, e seus parâmetros são simples.

Profile - Toda vez que um usuário loga, este arquivo é executado, por isso ele é usado para setar as variáveis de ambiente globais, dentre outras coisas.

hosts.deny - Hosts que não tem permissão para acessar a máquina.

hosts.allow - Hosts que tem permissão para acessar a máquina.

Services - Este arquivo descreve a relação entre os serviços e as portas mais comuns.

11.2.1.3 Diretórios mais importantes:

• /etc/rc.d - arquivos responsáveis pela carga dos daemons na inicialização do Linux.

• /etc/skel - arquivos que serão copiados para o home de um usuário recém criado.

11.2.2 Gerenciando a iniciação do Linux

O lilo e o grub disputam o posto de gerenciador de boot default entre as distribuições Linux. São os responsáveis pela “carga” do kernel do Linux na memória. Sem o gerenciador de boot o sistema simplesmente não inicializa.

Muitas distribuições permitem que você escolha entre usar o lilo ou o grub durante a instalação. Outras usam um dos dois por padrão. O grub oferece mais opções e inclui um utilitário, o update-grub que gera um arquivo de configuração básico automaticamente. Por outro lado, a sintaxe do arquivo de

TI para concursos

126

configuração do grub é mais complexa o que o torna bem mais difícil de editar manualmente que o do lilo.

O lilo utiliza um único arquivo de configuração, o /etc/lilo.conf. Ao fazer qualquer alteração neste arquivo é preciso chamar o executável do lilo, o "/sbin/lilo" para que ele leia o arquivo e salve as alterações..

O grub usa o arquivo de configuração /boot/grub/menu.lst. Este arquivo é lido a cada boot, por isso não é necessário reinstalar o grub ao fazer alterações, 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 pode-se usar o comando tar para compactar os arquivos.

Sintaxe: tar [opções] [-f arquivo]

Opções:

x : descompactar.

t : lista o conteúdo de um arquivo.

v : mostra na tela o que está sendo feito.

z : descompacta arquivos que também estejam gzipados .

f : especifica o nome do arquivo.

c : cria um novo arquivo.

Exemplos:

tar cvzf meu_backup.tgz ~ (faz o backup de sua área pessoal)

tar cvzf backup.tgz /home (faz o backup da área dos usuários )

tar xvzf /root/backup.tar.gz (descompacta o backup)

11.2.4 Recompilando e Adaptando o Kernel

Os administradores devem se preocupar em manter a máquina mais enxuta possível e para isso deve-se recompilar o kernel apenas com o necessário. Uma sugestão é a separação em módulos, o que sem dúvida reduzirá o “peso” da máquina. Para recompilar o kernel deve-se baixar o fonte de uma versão estável no site http://www.kernel.org ou um mirror confiável.

O fonte deve ser descompactado no diretório /usr/src. No diretório /usr/src/linux devem ser feitos alguns procedimentos:

make menuconfig - Entra no modo de configuração do kernel. Um ambiente amigável de fácil compreensão onde se pode marcar os pacotes que serão usados.

make dep - Acerta as dependências das bibliotecas necessárias para a compilação. make - Compila o kernel. make modules - Compila os módulos. make install - Instala o kernel. make modules_install - Instala os módulos.

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 execução automática, deve-se usar basicamente dois comandos:

at - agenda a execução de um comando e logo depois que esse processo ocorre este comando não 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, informações como: data e hora do boot, login de usuário e outros dados importantes para analisar o servidor. O arquivo responsável pelas configuração do syslogd é o /etc/syslog.conf .

Os registros deste arquivo são divididos em facility, priority e destino, podendo haver derivações 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 contém informações genéricas sobre todo o sistema.

Outro arquivo muito comum é o /var/log/debug que contém informações mais detalhadas.

TI para concursos

127

11.2.7 Técnicas Básicas para Trabalhar com Redes (ifconfig, route)

O Linux é um sistema operacional totalmente compatível com redes, dos tipos mais heterogêneos.

Para listar as interfaces de rede usa-se o comando:

ifconfig -a

Para atribuir um endereço IP para uma interface usa-se:

ifconfig eth0 <endereço> broadcast <broadcast> netmask <mascara>

Também 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 Serviços - inetd

O inetd é um daemon que pode gerenciar outros daemons, tendo uma função de supervisor. Este supervisor é executado sempre na carga do sistema, e busca a lista de serviços 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 contínua nos vários 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 (não criptografados) pela rede possibilitando um ataque, captura de todos os pacotes que percorrem na rede, inclusive senhas, números de cartão de crédito etc.

A solução encontrada pelos profissionais de segurança e administradores foi a substituição do telnet por ssh, que criptografa os dados dos pacotes, impossibilitando a sua fácil compreensão.

Para instalar o SSh deve-se baixar o pacote de algum lugar, tendo o cuidado de se baixar o produto de instituições com reconhecida credibilidade, pois do contrário, corre-se um sério risco de baixar “trojan horse”. Depois de pegar o pacote:

tar xvzf ssh-1.2.27.tar.gz

Depois, apenas mais três comandos dentro do diretório 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 Virtualização

Virtualização é a técnica que permite particionar um único sistema computacional em vários outros denominados de máquinas virtuais. Cada máquina virtual oferece um ambiente completo muito similar a uma máquina física. Com isso, cada máquina virtual pode ter seu próprio sistema operacional, aplicativos e serviços de rede (Internet). É possível ainda interconectar (virtualmente) cada uma dessas máquinas através de interfaces de redes, switches, roteadores e firewalls virtuais, além do uso já bastante difundido de VPN (Virtual Private Networks).

62

A virtualização pode auxiliar a se trabalhar em um ambiente onde haja uma diversidade de plataformas de software (sistemas operacionais) sem ter um aumento no número de plataformas de hardware (máquinas físicas). Assim, cada aplicação pode executar em uma máquina virtual própria, possivelmente incluindo suas bibliotecas e seu sistema operacional que, por sua vez, executam em uma plataforma de hardware comum.

Ao se executar múltiplas instâncias de máquinas virtuais em um mesmo hardware, também se está proporcionando um uso eficiente de seu poder de processamento. Essa situação é comumente denominada de consolidação de servidores e é especialmente interessante em data centers devido a

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

TI para concursos

128

heterogeneidade de plataformas inerente ao próprio negócio. Além disso, em data centers, a diminuição de máquinas físicas implica na redução de custos de infra-estrutura física como espaço, energia elétrica, cabeamento, refrigeração, suporte e manutenção a vários sistemas.

A flexibilidade e a portabilidade das máquinas virtuais também tornam interessante o uso da virtualização em desktops. É possível imaginar, por exemplo, o desenvolvimento de produtos de software destinados a vários sistemas operacionais sem ter a necessidade de uma plataforma física para desenvolver e testar cada um deles. Assim, as máquinas virtuais em desktops podem ser usadas para se definir ambientes experimentais sem comprometer o sistema operacional original da máquina, ou ainda, para compor plataformas distribuídas como clusters e grades computacionais.

As máquinas virtuais, por emularem um ambiente computacional sobre outro, impõem algumas restrições de implementação e de desempenho. É aqui que entra o desenvolvimento dos produtos de software para a virtualização.

As máquinas virtuais podem ser:

máquina virtual de processo – aplicação sobre um sistema operacional

hypervisor ou monitor de máquina virtual – camada de software posicionada entre o hardware da máquina e o sistema operacional por duas técnicas: para-virtualização – o sistema hóspede é modificado para chamar a VMM sempre que for executada uma

instrução ou ação considerada sensível. Dessa forma, o teste por instrução não é necessário. Os dispositivos de hardware são acessados por drivers da própria VMM. A substituição da chamada de uma instrução sensível pela chamada a um tratador de interrupção de software (trap) é chamado de hypercall.

virtualização total – réplica do hadware subjacente de tal forma que o sistema operacional e as aplicações podem executar como se tivessem executando diretamente sobre o hardware original. A grande vantagem dessa abordagem é que o sistema operacional hóspede não precisa ser modificado para executar sobre a VMM.

Sistema operacional é a camada de software inserida entre o hardware e as aplicações que executam tarefas para os usuários e cujo objetivo é tornar a utilização do computador, ao mesmo tempo, mais eficiente e conveniente.

A utilização mais eficiente busca um maior retorno no investimento feito no hardware. Maior eficiência significa mais trabalho obtido pelo mesmo hardware. Isso é obtido através da distribuição de seus recursos (espaço em memória principal, processador, espaço em disco etc) entre diferentes programas. Cada programa tem a ilusão de estar executando sozinho no computador quando na realidade ele está compartilhando com os demais. Uma utilização mais conveniente do computador é obtida, escondendo-se do usuário detalhes de hardware, em especial, dos periféricos de entrada e saída. Tipicamente, isso é feito através da criação de recursos de mais alto nível oferecido através de interfaces gráficas. Por exemplo, os usuários usam espaço em disco através do conceito de arquivos. Arquivos não existem no hardware. Eles formam um recurso criado a partir do que o hardware oferece. Genericamente, isso é denominado de virtualização de recursos.

O elemento central de um computador é seu processador. Cada processador tem um conjunto de instruções de máquina que pode seguir um determinado padrão. Por exemplo, Intel e AMD, fabricam processadores que implementam um mesmo padrão ISA, o Intel IA-32 (x86). Os projetistas de software compilam seu programas para obter códigos binários para um determinado ISA. Portanto, o conjunto de instruções (ISA) é uma interface entre o hardware e o software.

Tipicamente, um sistema de computação oferece três tipos de interfaces:

instruções de máquina (privilegiadas) - interface que permite que apenas alguns programas, os com privilégios especiais, como o sistema operacional, possam executar todas as instruções, entre elas, as de manipulação de recursos de hardware, como entrada e saída e interrupções.

instruções de máquina (não privilegiadas) e chamadas de sistema - interface que possibilita que um programa de usuário execute instruções não-privilegiadas diretamente no processador, mas não permite o acesso aos recursos de hardware (instruções privilegiadas). As chamadas de sistema são uma forma de permitir que os programas de usuários acessem de forma indireta, e controlada, os recursos de hardware. Através delas, os programas de usuário executam, após ter sido garantido a autenticidade e a validade da operação, operações de acesso a recursos de hardware (tipicamente E/S).

interface aplicativa de programação – mais conhecida como API (Application Program Interface), são funções de biblioteca que fazem com que as chamadas de sistema sejam ocultadas.

Considerando essas interfaces, a implementação de máquinas virtuais pode ser feita de três modos:

programa de aplicação que forneçe um ambiente de execução para outras aplicações. Esse ambiente pode possuir um conjunto de instruções abstratas que são interpretadas para gerar as instruções de máquinas não-privilegiadas, as chamadas de sistema e de API de bibliotecas que correspondem à ação abstrata desejada. É o caso da máquina virtual java (JVM).

programa de aplicação 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 virtualização é o que se denomina de máquina virtual de processo.

TI para concursos

129

camada de software entre o hardware e o sistema operacional protegendo o acesso direto deste aos recursos físicos da máquina. Essa camada oferece como interface ao sistema operacional um conjunto de instruções de máquina que pode ser o mesmo do processador físico, ou um outro. O ponto importante é que essa interface deve estar disponível sempre que o computador estiver ligado e que ela possa ser usada simultaneamente por diferentes programas. O resultado final é que possível ter diversos sistemas operacionais (programas) executando independentemente na mesma plataforma. Genericamente, essa máquina virtual é referenciada como monitor de máquina virtual (Virtual Machine Monitor ou VMM), também conhecido como hypervisor, ou ainda, máquina virtual de sistema.

O processo ou sistema que executa sobre uma máquina virtual é denominado de hóspede, enquanto o ambiente sobre o qual ele executa é chamado de hospedeiro.

Os fabricantes de processadores, AMD e Intel, desenvolveram extensões para a arquitetura x86 para suportarem a virtualização:

Pacífica – 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 funções especiais no processador que são executadas por um hypervisor e que podem controlar, em seu nome, se determinados acessos de um sistema hóspede são 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 idéia do conceito de anéis de proteção com dois novos modos: root e não-root. Esses modos são controlados pelo hypervisor (que executa em modo root) e que pode transferir a execução de um sistema operacional hóspede para o modo não-root no qual instruções do anel zero são executadas sem risco para o sistema.

As soluções da AMD e da Intel foram desenvolvidas independentemente uma da outra e são incompatíveis, embora sirvam para o mesmo propósito.

Existem diversas soluções 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 virtualização completa com produtos abrangendo desde desktops a data centers organizados em três categorias:

gestão e automatização, forma automatizada e centralizada de gerência de todos os recursos da infra-estrutura virtual permitindo a monitoração do sistema, auxiliando na conversão de sistemas físicos em virtuais, na recuperação de desastres, entre outros.

infra-estrutura virtual, monitoração e alocação de recursos entre as máquinas virtuais de forma a atender requisitos e regras de negócios. Soluções para alta disponibilidade, backup, migração de máquinas virtuais e atualização de versões de software.

virtualização de plataformas, destinado a criar máquinas virtuais.

O Xen é um monitor de máquina virtual (hypervisor ou VMM), em software livre, licenciado nos termos da GNU General Public Licence (GPL), para arquiteturas x86, que permite vários sistemas operacionais hóspedes serem executados em um mesmo sistema hospedeiro. O Xen é originário 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 são:

domínios - máquinas virtuais do Xen e são de dois tipos: privilegiada (domínio 0) - máquina virtual única que executa um núcleo linux modificado e que possuí

privilégios especiais para acessar os recursos físicos de entrada e saída e interagir com as demais máquinas virtuais (domínios U). Por ser um sistema operacional modificado, possui os drivers de dispositivos da máquina física e dois drivers especiais para tratar as requisições de acesso a rede e ao disco efetuados pelas máquinas virtuais dos domínios U.

não-privilegiada (domínio U)

hypervisor - controla os recursos de comunicação, de memória e de processamento das máquinas virtuais e não possui drivers de dispositivos. O hypervisor Xen não é capaz de suportar nenhum tipo de interação com sistemas hóspedes, é necessário que exista um sistema inicial para ser invocado pelo hypervisor. Esse sistema inicial é o domínio 0. As outras máquinas virtuais só podem ser executadas depois que ele for iniciado. As máquinas virtuais de domínio U são criadas, iniciadas e terminadas através do domínio 0.

O Virtual PC 2007 é uma máquina virtual para família Windows que pode ser configurada para executar qualquer outro sistema operacional. O Virtual PC oferece mecanismos para interconectar logicamente as diferentes máquinas virtuais. Cada máquina virtual tem seu próprio endereço MAC e endereço IP. Além disso, o Virtual PC oferece um servidor de DHCP, um servidor NAT e switches virtuais. Dessa forma, é possível construir cenários de rede usando máquinas virtuais. O virtual PC 2007 é disponível para download, assim como um white paper que ensina a configurar as máquinas virtuais e um ambiente de rede.

TI para concursos

130

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 virtualização (monitoração, automatização de procedimentos, migração, recuperação de desastres etc).

Entre as principais vantagens do Windows 2008 Server Hyper-V estão várias ferramentas para automatizar o processo de virtualização. Uma delas é o Manager Physical-to-virtual (P2V) que auxilia na conversão de servidores físicos para virtuais. Há também 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 homogênea independente de falhas e de “picos” de carga. Isso é feito por técnicas de migração de máquinas virtuais.

11.4 Active Directory

Software da Microsoft utilizado em ambientes Windows, o Active Directory é uma implementação de serviço de diretório no protocolo LDAP que armazena informações sobre objetos em rede de computadores e disponibiliza essas informações a usuários e administradores desta rede.

63

O "diretório ativo" permite que os administradores atribuam à empresa políticas largas, ofereçam programas a muitos computadores, e apliquem updates críticos a uma organização inteira. Uma informação ativa e ajustes das lojas do diretório que relacionam-se a uma organização em uma central, base de dados organizada, acessível.

O Active Directory está relacionado à:

Gerenciamento centralizado

GPO – Políticas de Grupo

Catálogo Global

Gerenciamento de Desktop Intellimiror

Distribuição de Software Automática

Interface de acesso ADSI

Compatibilidade com sistemas operacionais MS Legados

Administração Delegada

Replicação Automática

O Active Directory (AD) surgiu da necessidade de se ter um único diretório – um banco de dados que armazena as informações dos usuários, grupos, senhas, contas de computadores, relações de confiança, informações sobre o domínio, unidades organizacionais etc – onde os usuários poderão ter apenas uma senha para acessar todos os recursos disponíveis na rede.

Disponibiliza vários serviços, como: autenticação dos usuários, replicação do seu banco de dados, pesquisa dos objetos disponíveis na rede, administração centralizada da segurança utilizando GPO, entre outros serviços.

O AD é organizado de uma forma hierárquica, com o uso de domínios. Um domínio é um limite administrativo com diferentes administradores e diferentes políticas de segurança.

Domínios baseados no AD pussuem os seguintes recursos:

Logon único: com esse recurso, o usuário necessita fazer apenas um logon para acessar os recursos em diversos servidores da rede, inclusive email e banco de dados.

Conta de usuário única: os usuários possuem apenas um nome de usuário para acessar os recursos da rede. As contas de usuários ficam armazenadas no banco de dados do AD.

Gerenciamento centralizado: com os domínios baseados no AD, temos uma administração centralizada. Todas as informações sobre contas de usuários, grupos e recursos da rede, podem ser administradas a partir de um único local no domínio.

Escalonabilidade: os domínios podem crescer a qualquer momento, sem limite de tamanho. A forma de administração é a mesma para uma rede pequena ou grande.

Nos domínios baseados no AD, podemos ter dois tipos de servidores:

Controlador de Domínio (DC – Domain Controller): é o servidor que possui o AD instalado. Em um mesmo domínio podemos ter mais de um Controlador de Domínio. As alterações efetuadas em um DC são replicadas para todos os outros DC’s. São os DC’s quem fazem a autenticação dos usuários de um domínio. Um destes DC é eleito o controlador primário do domínio (PDC). Quando ele sai da rede, um controlador secundário assume a função.

Servidor Membro (Member Server) ou estação de trabalho (workstation): é um computador que não possui uma cópia do AD, porém tem acesso aos objetos do AD. Não fazem a autenticação dos usuários.

O AD utiliza o DNS para a nomeação de servidores e recursos, e também para resolução de nomes.

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

TI para concursos

131

Esquema é um conjunto de regras que define as classes de objetos e atributos contidos no diretório, as restrições e os limites das ocorrências desses objetos e o formato de seus nomes, que está incluído no Active Directory.

Com a utilização de domínios, a rede pode refletir a estrutura de uma empresa. Diversos domínios podem se interligar através do estabelecimento de relação de confiança, que permite aos usuários de ambos os domínios acessar seus recursos. No Windows 2000, as relações de confianças são bidirecionais e transitivas, ou seja, se o domínio X confia no domínio Y, e Y confia no domínio W, o domínio X também confia no domínio W.

Algumas características próprias de cada domínio:

Um domínio armazena informações somente dos objetos do próprio domínio.

Um domínio possui suas próprias diretivas de segurança

11.5 Exercícios

215. (ICMS-SP 2009) Na arquitetura do sistema operacional Windows XP, o Executivo expõe serviços aos processos usuários por meio

215

(a) dos Drivers de dispositivo. (b) das DLL. (c) da API nativa.

xx

(d) do Gerenciador de objeto. (e) do Gerenciador de E/S.

216. (ICMS-SP 2009) NÃO é uma característica do Active Directory do Windows XP:216

(a) Um serviço de rede que permite aos usuários compartilhar informações, recursos e objetos por meio de

rede. (b) Serviços de diretório para objetos compartilhados em uma rede, por exemplo: arquivos, impressoras,

usuários etc. (c) Um serviço de acesso remoto que permite aos usuários se conectarem remotamente com uma LAN.

xx

(d) O cliente LDAP – Protocolo Leve de Acesso a Diretório, para pesquisar e modificar diretórios de Internet, pode acessar o Active Directory.

(e) As localizações dos objetos são transparentes, ou seja, os usuários não sabem o endereço de um objeto.

217. (ICMS-SP 2009) Os mecanismos IPC disponíveis, tais como Sinais, Pipes, Soquetes, Mensagens, Memória compartilhada e Semáforos de System V, são implementados no núcleo do Linux pelo subsistema primário

217

(a) Sistemas de arquivos. (b) Sistema de comunicação interprocessos.

xx

(c) Gerenciador de processo. (d) Gerenciador de memória. (e) Gerenciador de E/S.

218. Para configurar e gerenciar o processo de inicialização (boot) de um computador com o sistema operacional Linux, pode-se utilizar o LILO ou o

218

(a) INIT (b) BOOT. (c) LINX. (d) LOAD (e) GRUB

xx

219. O Windows Server 2003 fornece várias ferramentas que podem ser usadas para gerenciar arquivos e pastas. A respeito das práticas recomendadas, quando se trata de pastas compartilhadas, analise as afirmativas a seguir: I. A atribuição de permissões a grupos simplifica o gerenciamento dos recursos compartilhados, pois se pode adicionar ou remover usuários nos grupos sem precisar reatribuir as permissões. II. As permissões compartilhadas se aplicam somente aos usuários que acessam os recursos compartilhados na rede e não a usuários que fazem logon localmente. III. Na implementação das ferramentas, a descentralização das pastas de dados facilita o backup dos dados e o gerenciamento do compartilhamento.

219

Assinale: (a) se somente a afirmativa I estiver correta. (b) se somente as afirmativas I e II estiverem corretas.

xx

(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 diretório, as restrições e os limites das ocorrências desses objetos e o formato de seus nomes, que está incluído no Active Directory, denomina-se

220

(a) floresta. (b) domínio. (c) diretiva de grupo. (d) esquema.

xx

(e) catálogo global.

TI para concursos

132

221. Quando se elimina o nó raiz de uma estrutura em árvore, o que dela restar forma221

(a) outra árvore. (b) uma floresta.

xx

(c) uma árvore binária. (d) uma sub-árvore. (e) um conjunto de sub-árvores.

222. Obtidas as permissões de acesso a um arquivo GNU/Linux: rw-r-xr-x Trata-se de um arquivo do tipo222

(a) normal, cuja execução é permitida ao dono, aos usuários do grupo user e aos outros usuários do arquivo. (b) normal, cujas alteração ou "deleção" são permitidas apenas ao dono do arquivo.

xx

(c) normal, cujas alteração ou "deleção" são permitidas ao dono do arquivo ou aos usuários do grupo user do arquivo.

(d) diretório, cujas leitura, gravação e execução são permitidas apenas ao dono do arquivo. (e) diretório, cujas leitura e execução são permitidas ao dono, aos usuários do grupo user e aos outros

usuários do arquivo.

223. O Kernel do Linux deve ser descompactado no diretório223

(a) /usr/src, após login como root.

xx

(b) /root/src, após login como user. (c) /sys/src, após login como root. (d) /home, após login como wrapper. (e) /boot, após login como kewl.

224. Para diversas partes de um programa serem executadas ao mesmo tempo, um sistema operacional utiliza uma tecnologia de

224

(a) multitarefa. (b) camadas. (c) threads.

xx

(d) particionamento. (e) multiprocessamento.

TI para concursos

133

12 Redes

12.1 Conceito de rede

Rede de computadores é um conjunto de computadores interligados por qualquer meio e que se comunicam por uma codificação 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, estão em uma rede local (LAN). Quando duas ou mais redes se ligam em um espaço mais amplo, diz-se que estão em uma rede WAN. Existem milhões de computadores no mundo interligados em rede por um protocolo chamado TCP/IP, formando uma única rede chamada de internet.

O meio de ligação entre os computadores (estações de trabalho) e a forma da disposição das conexões são camados de topologia da rede. Cabos metálicos, fibras óticas ou comunicação sem fios formam os enlaces entre computadores, ou entre computadores e outros equipamentos que fazem o papel de nós que recebem e distribuem os sinais na rede.

A topologia de uma rede de comunicação refere-se à forma como os enlaces físicos e os nós estão organizados, determinando os caminhos físicos existentes e utilizáveis entre quaisquer pares de estações conectadas a essa rede. A topologia de uma rede muitas vezes caracteriza o seu tipo, eficiência e velocidade.

Malha (fully) - A interconexão é total garantindo alta confiabilidade, porém a complexidade da implementação física e o custo inviabilizam seu uso comercial;

Estrela (star) - A conexão é feita através de um nó central que exerce controle sobre a comunicação. Sua confiabilidade é limitada à confiabilidade do nó central, cujo mau funcionamento prejudica toda a rede;

Barramento (bus) - As estações são conectadas através de um cabo com difusão da informação para todos os nós. é necessária a adoção de um método de acesso para as estações em rede compartilharem o meio de comunicação, evitando colisões. é de fácil expansão, mas de baixa confiabilidade, pois qualquer problema no barramento impossibilita a comunicação em toda a rede;

Anel (ring) - O barramento toma a forma de um anel, com ligações unidirecionais ponto a ponto. A mensagem é repetida de estação para estação até retornar à estação de origem, sendo então retirada do anel. Como o sinal é recebido por um circuito e reproduzido por outro há a regeneração do sinal no meio de comunicação; entretanto há também a inserção de um atraso a cada estação. O tráfego passa por todas as estações do anel, sendo que somente a estação destino interpreta a mensagem;

Árvore (tree) - é a expansão da topologia em barra herdando suas capacidades e limitações. O barramento ganha ramificações que mantêm as características de difusão das mensagens e compartilhamento de meio entre as estações;

Mistas (mesh) - Combinam duas ou mais topologias simples. Alguns exemplos são o de estrelas conectadas em anel e as árvores conectadas em barramento. Procuram explorar as melhores características das topologias envolvidas, realizar a conexão em um barramento único de módulos concentradores aos quais são ligadas as estações em configurações mais complexas e mais confiáveis.

12.1.1 Configuração de redes TCP-IP

Em uma rede de computadores que utiliza o protocolo TCP-IP, existem determinadas práticas de configuração que permitem que se usufrua da internet sem perder a rede local suas características e segurança.

A cada equipamento conectado fisicamente na rede atribui-se um número chamado de endereço IP. Este número é formado por quatro números de 0 a 255 separados por pontos. Por exemplo, 192.168.1.23 ou 10.10.0.128 são endereços IP válidos e 175.268.1.0 não é válido, pois contém um número maior do que 255.

TI para concursos

134

Estes números são, na verdade, uma representação decimal, pois a rede enxerga estes endereços como quatro grupos de oito números binários (0 ou 1) ou octetos. Para transformar um número decimal em binário, faz-se a divisão inteira daquele por sete vezes, então toma-se os restos das divisões em ordem contrária:

Por exemplo, dividindo-se 244 por dois e guardando o resto da divisão:

div 2 sobra

244 0

122 0

61 1

30 0

15 1

7 1

3 1

1 1

temos que o número 244 do sistema decimal é representado por 11110100 no sistema binário.

Em uma rede local, sem conexão com outras redes que utilizam o protocolo TCP-IP, qualquer endereço válido pode ser atribuída a qualquer computador. Porém, isto pode dificultar a sua manutenção e prejudicar seu desempenho quando o número de computadores na rede aumentar.

O IP, elemento comum encontrado na internet pública, é 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 versão do protocolo é designada de versão 4, ou IPv4. O IPv6 tem endereçamento de origem e destino de 128 bits, oferecendo mais endereçamentos que os 32 bits do IPv4, com previsão de ser padrão na internet a partir de 2011.

Originalmente, o espaço do endereço IP foi dividido em poucas estruturas de tamanho fixo chamados de "classes de endereço". As três principais são a classe A, classe B e classe C. Examinando os primeiros bits de um endereço, o software do IP consegue determinar rapidamente qual a classe, e logo, a estrutura do endereço.

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 são 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 três bits são 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: (endereço multicast): Primeiros quatro bits são: 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: (endereço especial reservado): Primeiros cinco bits são 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 não são consideradas públicas, não são consideradas como endereçáveis.

São reservados para a comunicação em uma rede privada os endereços que começam com 10.0.0.0, e 192.168.0.0 e os endereços na faixa 172.16.0.0 até 172.31.255.254.

É reservado para representar o computador local ("localhost") a faixa de endereços 127.0.0.0 a 127.255.255.255. Um computador usa qualquer destes endereços para designar a ele mesmo, como o pronome pessoal “eu”.

É reservado para representar rede corrente o endereço 0.0.0.0. Um computador usa este endereço para designar a própria rede.

A utilização destes endereços torna o computador inacessível por outros computadores na internet, o que representa uma segurança. Por outro lado, para acessar a internet, a rede local precisa de pelo menos um equipamento com um endereço público não reservado. Este equipamento pode fazer a ligação entre a rede e a internet, ou roteamento. Pode ser um roteador ou um computador.

O endereço IP tem a função de identificar o computador, que chamamos de host, e também 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 são utilizados para a rede. A quantidade de bits utilizada é definida pelo administrador da rede por um número chamado de máscara de rede ou netmask. O netmask é um conjunto de quatro octetos, como um endereço IP, iniciado por um grupo de uns à esquerda e outro grupo com zeros à direita.

Uma rede com endereços que comece com 192.168 e netmask 255.255.0.0, por exemplo, pode ter até 255x255=65536 endereços. O primeiro (192.168.0.0) é reservado para identificar a própria rede e o último (192.168.255.255) é usado para distribuir dados para toda a rede (broadcast), os demais 65534 endereços são para os hosts. Todas as informações de todos os computadores nesta rede vai ser inviada para todos os computadores, gerando colisões que podem tornar a rede muito lenta.

TI para concursos

135

Para minimizar este problema, uma rede pode ser dividida em várias subredes alterando-se o natmask. Um netmask 255.255.255.0 vai reduzir o número de endereços em cada rede para apenas 256 (254 para hosts) e aumentar o número de redes em 256 vezes. Cada subrede recebe um endereço para ser identificada e outro para o broadcast a partir de operações lógicas entre a máscara de rede (netmask) e cada endereço de cada equipamento.

Por exemplo, uma net mask pode ser 11111111. 11111111. 11111111.00000000, representada por 255.255.255.0.

A identificação de rede de um endereço IP é dada pela operação lógica ^ (e/and) entre a máscara e o endereço. Nesta operação, comparam-se os octetos posição a posição, sendo atribuido o valor zero se um dos dígitos for zero, ou valor um em caso contrário.

Um endereço 192.168.1.101 E uma máscara 255.255.255.0 produz o endereço 192.168.1.0, que identifica a rede.

A identificação de rede do broadcast é obtido pelo operação lógica v (ou/or) entre a negação da máscara e o endereço.

Um endereço 192.168.1.101 OU uma máscara 255.255.255.0 produz o endereço 192.168.1.255, que identifica o broadcast.

O netmask não precisa usar somente grupos completos de oito bits. Desde que não 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 endereço, por exemplo, 192.168.1.132/25, dentro desta subrede será representada com o número de bits da máscara à sua direita, neste caso 25 (8+8+8+1). Neste exemplo, o número de endereços se reduziu para 128 (126 para hosts) e o número de redes aumentou em 128 vezes.

Assim, podem ser criadas subredes com 128 endereços (126 hosts), 64, 32, 16, 8, 4 ou 2 endereços (que não seve para nada). A conta de quantos hosts podem haver em uma subnet é dois elevado ao número de zeros na netmask menos dois: hosts=2

n-2. O número de subredes é dois elevado ao número

de uns do octeto incompleto: redes=2n.

Na nossa net mask 11111111. 11111111. 11111111.10000000, com sete zeros, teremos 27-2=126 endereços para hosts e 21=2 para subredes.

Em uma net mask 11111111. 11111111. 11111111.11100000, com cinco zeros, teremos 25-2=30 endereços para hosts e 23=8 subredes.

Com isto tudo, o acesso de um equipamento a outro na mesma subrede é direta e rápida, 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 especificação de uma arquitetura deve conter informações suficientes para permitir que um implementador desenvolva programas ou construa o hardware de cada camada, de forma que ela obedeça corretamente ao protocolo adequado.

64

ISO foi uma das primeiras organizações a definir formalmente uma forma comum de conectar computadores. Sua arquitetura é chamada OSI (Open Systems Interconnection), Camadas OSI ou Interconexão de Sistemas Abertos.

65

Esta arquitetura é um modelo que divide as redes de computadores em sete camadas, de forma a se obter camadas de abstração. Cada protocolo implementa uma funcionalidade assinalada a uma determinada camada.

1 Camada física Subcamada MAC Subcamada LLC

2 Camada de enlace

3 Camada de rede

4 Camada de transporte

5 Camada de sessão

6 Camada de apresentação

7 Camada de aplicação

12.2.1 Camada Física

A camada física define as características técnicas dos dispositivos elétricos (físicos) do sistema. Ela contém os equipamentos de cabeamento ou outros canais de comunicação que se comunicam diretamente com o controlador da interface de rede. Preocupa-se, portanto, em permitir uma comunicação bastante simples e confiável, na maioria dos casos com controle de erros básico:

Move bits (ou bytes, conforme a unidade de transmissão) através de um meio de transmissão.

Define as características elétricas e mecânicas do meio, taxa de transferência dos bits, tensões etc.

Controle de acesso ao meio.

64 http://pt.wikipedia.org/wiki/Arquitetura_de_rede 65 http://pt.wikipedia.org/wiki/Modelo_OSI

TI para concursos

136

Controle da quantidade e velocidade de transmissão de informações na rede.

Os principais equipamentos relacionados à camada física são:

Repeater ou repetidor - utilizado para interligação de redes idênticas, amplificam e regeneram eletricamente os sinais transmitidos no meio físico. 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 ligação entre diversos computadores que estão em uma rede local. Trabalha por broadcast, que envia a mesma informação dentro de uma rede para todas as máquinas interligadas. Possui diversas portas que partilham o mesmo domínio de colisão.

12.2.2 Camada de Enlace ou Ligação de Dados

Detecta e, opcionalmente, corrige erros que possam acontecer no nível físico. É responsável pela transmissão e recepção (delimitação) de quadros e pelo controle de fluxo. Estabelece um protocolo de comunicação entre sistemas diretamente conectados, como PPP ou NetBios.

Esta camada é dividida em outras duas camadas:

Controle de ligação lógica (LLC), que fornece uma interface para camada superior (rede).

Controle de acesso ao meio físico (MAC), que acessa diretamente o meio físico e controla a transmissão de dados.

Os principais equipamentos relacionados à camada de enlace são:

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 endereço do pacote. Este endereço não é o endereço IP (internet protocol), mas o MAC (media access control) que é único para cada placa de rede. Os únicos dados que são permitidos atravessar uma bridge são dados destinados a endereços válidos no outro lado da ponte. Desta forma é possível 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 nós e segmenta a rede internamente. Possui diversas portas, cada uma corresponde um dominio de colisão diferente, não havendo colisões entre pacotes de segmentos diferentes. Com um Switch gerenciável, 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 é responsável pelo endereçamento dos pacotes, convertendo endereços lógicos (ou IP) em endereços físicos, de forma que os pacotes consigam chegar corretamente ao destino. Essa camada também determina a rota que os pacotes irão seguir para atingir o destino, baseada em fatores como condições de tráfego 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 funções da camada de rede são encaminhamento, endereçamento, interconexão de redes, tratamento de erros, fragmentação de pacotes, controle de congestionamento e sequenciamento de pacotes.

Movimenta pacotes a partir de sua fonte original até seu destino através de um ou mais enlaces. Define como dispositivos de rede descobrem uns aos outros e como os pacotes são roteados até seu destino final.

Dispositivo: Swith L3

Protocolo: IP.

12.2.4 Camada de Transporte

A camada de transporte é responsável por usar os dados enviados pela camada de Sessão e dividi-los em pacotes que serão transmitidos para a camada de Rede. No receptor, a camada de Transporte é responsável por pegar os pacotes recebidos da camada de Rede, remontar o dado original e assim enviá-lo à camada de Sessão.

Isso inclui controle de fluxo, ordenação dos pacotes e a correção de erros, tipicamente enviando para o transmissor uma informação de recebimento, informando que o pacote foi recebido com sucesso.

A camada de Transporte separa as camadas de nível de aplicação (camadas 5 a 7) das camadas de nível físico (camadas de 1 a 3). A camada 4, Transporte, faz a ligação entre esses dois grupos e determina a classe de serviço necessária como orientada a conexão e com controle de erro e serviço de confirmação, sem conexões e nem confiabilidade.

TI para concursos

137

O objetivo final da camada de transporte é proporcionar serviço eficiente, confiável e de baixo custo. O hardware e/ou software dentro da camada de transporte e que faz o serviço é denominado entidade de transporte.

A ISO define o protocolo de transporte para operar em dois modos:

Orientado a conexão – usando o protocolo TCP, mais confiável.

Não-Orientado a conexão – através do protocolo UDP, mais rápido.

Dispositivos: Swith L4.

12.2.5 Camada de Sessão

A camada de Sessão permite que duas aplicações em computadores diferentes estabeleçam uma sessão de comunicação. Nesta sessão, essas aplicações definem como será feita a transmissão de dados e coloca marcações nos dados que estão sendo transmitidos. Se porventura a rede falhar, os computadores reiniciam a transmissão dos dados a partir da última marcação recebida pelo computador receptor.

Disponibiliza serviços como pontos de controle periódicos a partir dos quais a comunicação pode ser restabelecida em caso de pane na rede.

Abre portas (sockets) para que várias aplicações possam escalonar o uso da rede e aproveitar melhor o tempo de uso. Por exemplo, um browser quando for fazer o download de várias imagens pode requisitá-las juntas para que a conexão não fique ociosa em uma só imagem.

Protocolos: NetBIOS, IPX, Appletalk.

12.2.6 Camada de Apresentação

A camada de Apresentação, também chamada camada de tradução, converte o formato do dado recebido pela camada de Aplicação em um formato comum a ser usado na transmissão desse dado, ou seja, um formato entendido pelo protocolo usado. Um exemplo comum é a conversão do padrão de caracteres (código de página) quando o dispositivo transmissor usa um padrão diferente do ASCII. Pode ter outros usos, como compressão de dados e criptografia.

A compressão de dados pega os dados recebidos da camada sete e os comprime, e a camada 6 do dispositivo receptor fica responsável por descompactar esses dados. A transmissão dos dados torna-se mais rápida, já que haverá menos dados a serem transmitidos: os dados recebidos da camada 7 foram "encolhidos" e enviados à camada 5.

Para aumentar a segurança, pode-se usar algum esquema de criptografia neste nível, sendo que os dados só serão decodificados na camada 6 do dispositivo receptor.

Ela trabalha transformando os dados em um formato no qual a camada de aplicação possa aceitar.

12.2.7 Camada de Aplicação

A camada de aplicação faz a interface entre o protocolo de comunicação e o aplicativo que pediu ou receberá a informação através da rede. Por exemplo, ao solicitar a recepção de e-mails através do aplicativo de e-mail, este entrará em contato com a camada de Aplicação do protocolo de rede efetuando tal solicitação. Tudo nesta camada é direcionado aos aplicativos. Telnet e FTP são exemplos de aplicativos de rede que existem inteiramente na camada de aplicação.

Protocolos: SMTP, FTP, Telnet, SSH, IRC, http, POP3, VFRAD

12.3 Noções de administração de redes

O Administrador de Rede tem como atribuição principal o gerenciamento da rede local, bem como dos recursos computacionais relacionados direta ou indiretamente.

66

Suas atribuições são:

Instalação e ampliação da rede local; Acompanhar o processo de compra do material necessário para manutenção da rede local junto com o

SAT (Setor de Assistência Técnica), orientando o processo de compra e mantendo contato com os fornecedores de equipamentos e materiais de informática;

Instalar e configurar a máquina gateway da rede local seguindo as orientações "Normas de Utilização do DIN";

Orientar e/ou auxiliar os administradores das sub-redes na instalação/ampliação da sub-rede; manter em funcionamento a rede local do DIN, disponibilizando e otimizando os recursos computacionais disponíveis;

Executar serviços nas máquinas principais da rede local, tais como: gerenciamento de discos, fitas e backup's, parametrização dos sistemas, atualização de versões dos sistemas operacionais e aplicativos, aplicação de correções e patches;

66 http://pt.wikipedia.org/wiki/Administrador_de_rede

TI para concursos

138

Realizar abertura, controle e fechamento de contas nas máquinas principais do domínio 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 atualização dos recursos de software e hardware aos seus superiores; Manter atualizado os dados relativos ao DNS das máquinas da rede local; Divulgar informações de forma simples e clara sobre assuntos que afetem os usuários locais, tais como

mudança de serviços da rede, novas versões de software, etc.; Manter-se atualizado tecnicamente através de estudos, participação em cursos e treinamentos, listas de

discussão, etc.; Garantir a integridade e confidenciabilidade das informações sob seu gerenciamento e verificar

ocorrências de infrações e/ou segurança; Comunicar ao DIN qualquer ocorrência de segurança na rede local que possa afetar a rede local e/ou

Internet; Promover a utilização de conexão segura entre os usuários do seu domínio. Tendo como foco principal os serviços de Rede e equipamentos a qual a ele compete. Colocar em pratica a política de segurança de redes, além de desenvolvê-la.

12.4 Acesso Remoto

Acesso remoto é utilização de um computador através de outro por algum meio de comunicação. 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 serviço, como o VNC, PCAnyWhere, Dameware, Conexão de área de trabalho remota do Windows entre outros.

Muito utilizado em data centers para administrar diversos servidores com um só vídeo, 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 padrão IEEE 802.11. O termo Wi-Fi é entendido como uma tecnologia de interconexão entre dispositivos sem fios, usando o protocolo IEEE 802.11.

67

O padrão Wi-Fi opera em faixas de freqüências que não necessitam de licença para instalação e/ou operação. Este fato as tornam atrativas. No entanto, para uso comercial no Brasil é necessária licença da Agência Nacional de Telecomunicações (Anatel).

Para se ter acesso à internet através de rede Wi-Fi deve-se estar no raio de ação ou área de abrangência de um ponto de acesso (normalmente conhecido por hotspot) ou local público onde opere rede sem fios e usar dispositivo móvel, como computador portátil, Tablet PC ou Assistente Pessoal Digital com capacidade de comunicação sem fio.

Hotspot Wi-Fi existe para estabelecer ponto de acesso para conexão à internet. O ponto de acesso transmite o sinal sem fios numa pequena distância – cerca de 100 metros. Quando um periférico que permite "Wi-Fi", como um Pocket PC, encontra um hotspot, o periférico pode na mesma hora conectar-se à rede sem fio. Muitos hotspots estão localizados em lugares que são acessíveis ao público, como aeroportos, cafés, hotéis e livrarias. Muitas casas e escritórios também têm redes "Wi-Fi". Enquanto alguns hotspots são gratuitos, a maioria das redes públicas é suportada por Provedores de Serviços de Internet (Internet Service Provider - ISPs) que cobram uma taxa dos usuários para se conectarem.

Atualmente praticamente todos os computadores portáteis vêm de fábrica com dispositivos para rede sem fio no padrão Wi-Fi (802.11 a, b, g ou n). O que antes era acessório está se tornando item obrigatório, principalmente devido ao fato da redução do custo de fabricação.

12.6 Exercícios

225. (ICMS-SP 2009) As redes wireless utilizam os padrões IEEE 802.11 de conectividade sem fio para redes locais, que determinam a velocidade, ou taxa de transmissão em Mbps, e a frequência, ou faixa de operação em GHz. O padrão que tem as características de velocidade e frequência corretas corresponde a:

225

(a) IEEE 802.11n 128 Mbps 5 GHzxx

(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.

67 http://pt.wikipedia.org/wiki/Wi-Fi

TI para concursos

139

226. (ICMS-SP 2009) A arquitetura OSI de 7 camadas (1. Física, 2. Enlace, 3. Rede, 4. Transporte, 5. Sessão, 6. Apresentação e 7. Aplicação) pode funcionalmente representar um sistema de comunicação dividido em três partes: redes (conectividade), transporte (ligação entre redes e aplicação) e aplicação (programas que utilizam a rede). As camadas que representam as três partes são:

226

(a) Redes (camadas 1 e 2), Transporte (camadas 3 e 4) e Aplicação (camadas 5, 6 e 7). (b) Redes (camadas 1, 2 e 3), Transporte (camada 4) e Aplicação (camadas 5, 6 e 7).

xx

(c) Redes (camadas 1 e 2), Transporte (camadas 3, 4 e 5) e Aplicação (camadas 6 e 7). (d) Redes (camadas 1, 2 e 3), Transporte (camadas 4, 5 e 6) e Aplicação (camada 7). (e) Redes (camada 1), Transporte (camadas 2, 3, 4 e 5) e Aplicação (camadas 6 e 7).

227. (ICMS-SP 2009) Em um modelo simplificado de gerenciamento de redes SNMP Internet, o programa executado nas entidades a serem gerenciadas (hosts, hubs, roteadores etc.) é denominado

227

(a) MIB. (b) SMI. (c) SNMP. (d) Agente SNMP.

xx

(e) Gerenciador SNMP.

228. Switches, Repetidores e Roteadores atuam respectivamente nas camadas228

(a) de enlace, física e de rede.

xx

(b) de rede, de enlace e de transporte. (c) física, de enlace e de rede. (d) de enlace, de transporte e física. (e) física, de rede e de enlace.

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 ... Roteador

xx

230. No modelo de referência OSI, os pacotes e os quadros são unidades intercambiadas, respectivamente, pelas camadas de

230

(a) enlace e de transporte. (b) enlace e de rede. (c) rede e física. (d) rede e de enlace.

xx

(e) transporte e de enlace.

231. No modelo de referência TCP/IP, os protocolos IP, TCP e também aquele cujo objetivo é organizar máquinas em domínios e mapear nomes de hosts em ambientes IP, são, respecivamente, partes integrantes das camadas

231

(a) Inter-Redes, de Aplicação e de Transporte. (b) Host/Rede, Inter-Redes e de Transporte. (c) Inter-Redes, Host/Rede e de Aplicação. (d) Inter-Redes, de Transporte e de Aplicação.

xx

(e) Host/Rede, de Transporte e de Aplicação.

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 endereço IP

232

(a) 0.0.0.0 (b) 1.1.1.1 (c) 127.0.0.1

xx

(d) 255.0.0.0 (e) 255.255.255.0

233. A Internet utiliza a pilha de protocolos TCP/IP para prover todos os serviços. 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 ... endereçamento (b) roteamento ... transporte (c) transporte ... empacotamento (d) transporte ... endereçamento

xx

(e) transporte ... sequenciamento

TI para concursos

140

234. O processo de navegação na Internet é facilitado pelo uso de endereços de domínio no lugar dos endereços IPs (mais difíceis de memorizar e relacionar com os sites endereçados). O serviço que faz o relacionamento entre o domínio e o IP é denominado

234

(a) DHCP. (b) DNS.

xx

(c) IMAP. (d) PPP. (e) TCP/IP.

235. O equipamento de rede de computador utilizado para armazenar cópias (cache) de páginas mais visitadas e, além disso, verificar o conteúdo dessas páginas, é denominado

235

(a) Proxy.xx

(b) Bridge. (c) Spyware. (d) Firewall. (e) Gateway.

236. TCP/IP (transmission control protocol/Internetprotocol) são os dois protocolos mais importantes de um conjunto de protocolos que deram seus nomes à arquitetura. Deles, surge a Internet, uma rede pública de comunicação de dados que, com controle descentralizado, utiliza esse conjunto de protocolos como base para sua estrutura de comunicação e seus serviços de rede. A arquitetura TCP/IP não só fornece os protocolos que habilitam a comunicação de dados entre redes, mas também define uma série de aplicações que contribuem para a eficiência e sucesso da arquitetura. Tendo como referência inicial as informações acima, assinale a opção correta a respeito de Internet, intranet e padrões de tecnologia Web.

236

(a) Uma intranet é a aplicação 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 informações e aplicações é disponibilizada por meio dos sistemas Web (protocolo HTTP) e correio-eletrônico, sendo, comumente, verificadas funcionalidades como informações dos empregados e dos clientes que a acessam em busca de informações 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 são enviados e recebidos entre roteadores e sistemas finais.

(c) Os protocolos UDP e SMTP podem ser utilizados na transferência de arquivos para um computador remoto que também os execute e em qualquer estrutura de rede, seja ela simples, como uma ligação ponto-a-ponto, seja ela uma rede de pacotes complexa.

(d) O DNS (domain name system) é um sistema de banco de dados distribuído implementado em uma hierarquia de servidores de nome (servidores DNS) e em um protocolo de camada de aplicação que permite a hospedeiros consultarem o banco de dados distribuído.

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 autônomos, pode operar em conjunto com os protocolos EGP (exterior gateway protocol) e BGP (border gateway protocol), o que permite maior confiabilidade à ligação entre dois sistemas autônomos.

237. Para acesso aos recursos da Internet, os browsers possibilitam o uso de endereços de sites na forma de mnemônicos, 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 necessárias conversões para os correspondentes endereços IP´s. Esse recurso é conhecido pela sigla:

237

(a) ARP. (b) DNS.

xx

(c) ISP. (d) NAT. (e) NFS.

238. Dentre os recursos atualmente disponíveis no âmbito da tecnologia da informação, a Extranet constitui um termo associado às facilidades de comunicação na busca do aumento da produtividade. Nesse sentido, a Extranet é definida como:

238

(a) uma parte da Intranet que fica disponível à troca de informações com os funcionários de uma organização, 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 segurança, mas libera acesso por meio do firewall.

(c) uma parte da Intranet que fica disponível na Internet para interação com clientes e fornecedores de uma organização, mas com acesso autorizado, controlado e restrito.

xx

(d) uma sub-rede que disponibiliza uma maior quantidade de microcomputadores com acesso à Internet por meio da utilização do mecanismo NAT, mas restringe a intercomunicação com usuários indesejados à organização.

(e) uma parte da Intranet que disponibiliza a comunicação com fornecedores e determinados clientes de uma organização, mas inibe todo tipo de acesso ao ambiente interno por meio do firewall.

TI para concursos

141

239. A Internet constitui o melhor exemplo de uma WAN operando por meio de uma infraestrutura baseada no emprego de endereços IP´s para o roteamento dos pacotes de informações. Por definição na RFC 1918, alguns endereços IP são reservados e não-roteáveis externamente, sendo somente usados para redes internas, significando que nenhum computador conectado em rede local e usando qualquer uma das classes desses endereços reservados conseguirá acessar a internet. A exceção 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 endereços 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 endereços reservada para a classe C.

239

(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 (d) de 192.168.0.0 a 192.168.255.255

xx

(e) de 198.162.0.0 a 198.162.255.255

240. Dada uma faixa de endereços que utilize a máscara de sub-rede 255.255.255.240, será possível atribuir endereços IP para

240

(a) 2 redes e 62 estações em cada rede. (b) 6 redes e 30 estações em cada rede. (c) 14 redes e 14 estações em cada rede.

xx

(d) 30 redes e 6 estações em cada rede. (e) 62 redes e 2 estações 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 são características de um

241

(a) concentrador. (b) multiplexador. (c) comutador.

xx

(d) modulador de amplitude. (e) repetidor.

242. Padrão de protocolo da camada de transporte, sem conexão, não confiável, destinado a aplicações que não querem controle de fluxo e nem manutenção da seqüência das mensagens enviadas, usado pelo TCP para enviar mensagens curtas. Trata-se de

242

(a) UDP.xx

(b) IP. (c) SMTP. (d) POP. (e) Telnet.

243. As mensagens de correio eletrônico, a partir de um microcomputador pessoal, serão enviadas243

(a) pelo protocolo SMTP, conectado pela porta 25, e serão recebidas pelos protocolos POP3 ou IMAP,

conectado respectivamente pelas portas 110 ou 220.xx

(b) pelo protocolo SMTP, conectado pela porta 110, e serão 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 serão recebidas

pelo protocolo POP3, conectado pela porta 110. (d) pelos protocolos SMTP ou IMAP, conectado respectivamente pelas portas 110 ou 220, e serão recebidas

pelo protocolo POP3, conectado pela porta 25. (e) pelo protocolo SMTP, conectado pela porta 110, serão recebidas pelo protocolo POP3, conectado pela

porta 25, e serão enviadas ou recebidas pelo protocolo IMAP, conectado pela porta 220.

244. O daemon de correio eletrônico que se comunica com o SMTP permanece em escuta na porta244

(a) 21 (b) 15

xx

(c) 69 (d) 80 (e) 110

245. Controlar o acesso ao canal compartilhado é uma questão que as redes de difusão têm a resolver na camada de enlace de dados. Para cuidar desse problema existe

245

(a) o roteador. (b) a VPN. (c) a subcamada MAC.

xx

(d) o protocolo IP. (e) o protocolo HTTP.

TI para concursos

142

246. Serviço que permite ao usuário entrar em outro computador ligado à internet, transformando sua máquina local em um terminal do computador remoto é o

246

(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) Sessão. (c) Enlace.

xx

(d) Transporte. (e) Aplicação.

TI para concursos

143

13 Informática Básica

13.1.1 Questões de informática do concurso ICMS-SP 2009

248. Durante a elaboração 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 página, onde algumas células (intersecções de linhas e colunas) continham valores. Entretanto, esses valores deveriam ser totalizados na vertical (por coluna), porém, no sentido horizontal, um valor médio de cada linha era exigido. Nessas circunstâncias, visando à execução dos cálculos automaticamente, o Agente optou, acertadamente, por elaborar a tabela no

248

(a) MS-Excel e depois importá-la no editor de textos pelo menu Editar, utilizando as funções apropriadas do MS-Word.

(b) MS-Excel e depois importá-la no editor de textos pelo menu Tabela, utilizando as funções apropriadas do MS-Word.

(c) MS-Excel e depois importá-la no editor de textos pelo menu Arquivo, utilizando as funções apropriadas do MS-Word.

(d) próprio MS-Word, utilizando as funções apropriadas disponíveis no menu Ferramentas do editor de textos.

(e) próprio MS-Word, utilizando as funções apropriadas disponíveis no menu Tabela do editor de textos.xx

249. No MS-Word, ao marcar uma parte desejada de um texto e249

(a) optar pela cópia, o objetivo é fazer a cópia de formatos de caractere e parágrafo, somente. (b) optar pelo recorte, o objetivo é fazer a cópia de formatos de caractere e parágrafo, somente. (c) optar pelo recorte, o objetivo é fazer a cópia do conteúdo do texto e/ou marcadores, somente. (d) pressionar o ícone Pincel, o objetivo é fazer a cópia de formatos de caractere e/ou parágrafo, somente.

xx

(e) pressionar o ícone Pincel, o objetivo é fazer a cópia do conteúdo de texto do parágrafo e/ou marcadores, somente.

250. Em uma planilha MS-Excel, um Agente digitou o conteúdo abaixo:

A B C

1 2 5 =$A1+B$1

2 3 6

3 4 7

O valor da célula C1 e os valores da célula C2 e C3, após arrastar a célula C1 pela alça de preenchimento para C2 e C3, serão

250

(a) 7, 9 e 11 (b) 7, 8 e 9

xx

(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 conteúdo da célula C1 foi obtido pela fórmula =A$1*$B$1 apresentando, inicialmente, o resultado 10. Caso todas as células, com exceção da C1, tenham seu conteúdo multiplicado por 8, o resultado da ação de arrastar a célula C1 pela alça de preenchimento para as células C2 e C3 será

251

(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 fórmulas em C2 e C3 idênticos aos de C1.

xx

(d) valores iguais, porém fórmulas diferentes nas células C1, C2 e C3. (e) valor de C2 igual ao de C1 porém menor que o de C3.

252. No Windows XP (edição doméstica), o uso da Lente de aumento da Microsoft é objeto de252

(a) acessibilidade.

xx

(b) gerenciamento de dispositivos. (c) gerenciamento de impressoras. (d) configuração de formatos de dados regionais. (e) configuração das propriedades de teclado.

253. Pressionando o botão direito (destro) do mouse em um espaço vazio do desktop do Windows XP (edição doméstica) e selecionando Propriedades, será exibida uma janela com abas tais como Área de Trabalho e Configurações. Entre outras, será exibida também a aba

253

(a) Ferramentas administrativas. (b) Opções de pasta. (c) Propriedades de vídeo.

xx

(d) Painel de controle. (e) Tarefas agendadas.

TI para concursos

144

254. A boa refrigeração de um processador geralmente é obtida mediante254

(a) a execução do boot proveniente de uma unidade periférica. (b) a instalação de uma placa-mãe compacta. (c) a adequada distribuição da memória. (d) o uso de um cooler.

xx

(e) o aumento do clock.

255. Na Web, a ligação entre conjuntos de informação na forma de documentos, textos, palavras, vídeos, imagens ou sons por meio de links, é uma aplicação das propriedades

255

(a) do protocolo TCP. (b) dos hipertextos.

xx

(c) dos conectores de rede. (d) dos modems. (e) das linhas telefônicas.

256. Nos primórdios da Internet, a interação entre os usuários e os conteúdos virtuais disponibilizados nessa rede era dificultada pela não existência de ferramentas práticas que permitissem sua exploração, bem como a visualização amigável das páginas da Web. Com o advento e o aperfeiçoamento de programas de computador que basicamente eliminaram essa dificuldade, os serviços e as aplicações que puderam ser colocados à disposição dos usuários, iniciaram uma era revolucionária, popularizando o uso da Internet. Segundo o texto, a eliminação da dificuldade que auxiliou na popularização da Internet foi

256

(a) o uso de navegadores.xx

(b) o surgimento de provedores de acesso. (c) o aumento de linhas da rede. (d) o surgimento de provedores de conteúdo. (e) a disponibilização de serviços de banda larga.

257. Um Agente foi acionado para estudar a respeito dos conceitos de certificação digital. Após alguma leitura, ele descobriu que NÃO tinha relação direta com o assunto o uso de

257

(a) chave pública. (b) criptografia. (c) assinatura digital. (d) chave privada. (e) assinatura eletrônica.

xx

TI para concursos

145

14 Referências

Além das referências anotradas nos rodapés das páginas: OBJECT Management Group, Inc. (OMG), Business Process Model and Notation (BPMN). Version 2.0 de

03/01/2011. Disponível em http://www.omg.org/spec/BPMN/2.0. Acesso em 15/09/2012.

MAZZOLA, Vitório Bruno. “Engenharia de Software”. Disponível 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 edição. ©2008.

TI para concursos

146

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 Informações (CDS-DTI) da Secretaria da Fazenda de São Paulo.

Este material foi um resumo de tudo de TI que estudou para esta prova.

Formado em licenciatura em química pela Universidade de São Paulo, lecionou informática básica para alunos do ensino fundamental e médio no Colégio Rio Branco por doze anos.

Exerceu consultoria de informática e desenvolveu mais de trinta sistemas para diversas intituições públicas e privadas por 25 anos, para FIPE, FIA, FIPECAFI, Secretaria do Meio Ambiente, CDHU, Convap Engenharia e Construções, GMR Arquitetos Associados, Fundação Padre Anchieta, Fundação Osesp, ABEM, Souza Cruz, entre outras.

TI para concursos

147

16 Gabarito

1 (b)

2 (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)

59

(d) 60

(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)

119

(d) 120

(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)

179

(c) 180

(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)

239

(d) 240

(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)