apostila de TI para concursos

Material de referência

TI – ICMS

Walter de Tarso

Versão 1

Curso de TI

Sumário

1

Gerência de Projetos ... 1

1.1 Conceitos básicos ... 1

1.2 Processos do PMBOK ... 2

1.2.1 Áreas de conhecimento do PMBOK ... 3

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

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

1.5 Exercícios ... 14

2

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

2.1 BPMN - Modelagem de processos ... 18

2.1.1 Elementos ... 18

2.2 Técnicas de análise de processos ... 20

2.2.1 Automação de processos ... 20

2.2.2 Fluxograma ... 20

2.2.3 Service blueprint ... 20

2.2.4 Mapa do serviço ... 21

2.2.5 IDEF ... 21

2.2.6 Estrutura de processamento de clientes ... 22

2.2.7 Walk-through-audit ... 22

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

2.3 Exercícios ... 23

3

Gerência de Serviços de TI ... 25

3.2.1 Estratégia do serviço (Service Strategy) ... 28

3.2.2 Desenho de serviço (Service Design) ... 28

3.2.3 Transição do serviço (Service Transition) ... 29

3.2.4 Operação do serviço (Service Operation) ... 29

3.2.5 Melhoria de serviço continuada (Continual Service Improvement) ... 29

3.3 Fundamentos de COBIT... 29

3.3.1 Planejar e Organizar ... 30

3.3.2 Adquirir e Implementar ... 30

3.3.3 Entregar e Dar Suporte ... 30

3.3.4 Monitorar e Avaliar ... 31

3.4 Exercícios ... 31

4

Engenharia de Software ... 33

4.1 Software ... 33

4.2 Ciclo de vida do software ... 34

4.2.1 Fase de Definição ... 34

4.2.2 Fase de Desenvolvimento ... 34

4.2.3 Fase de Operação ... 35

4.2.4 Fase de retirada ... 36

4.3 Metodologias de desenvolvimento de software. ... 36

4.3.1 Modelo caótico ... 36

4.3.2 Modelo Cascata ... 36

4.4 Desenvolvimento ágil ... 38

4.6 Técnicas de avaliação de software ... 40

4.6.1 Análise por Pontos de Função ... 40

4.6.2 Método COCOMO ... 44

4.7 Gerência de Requisitos de Software ... 44

4.7.1 Conceitos de Requisitos ... 45

4.7.2 Requisitos Funcionais e Não-Funcionais ... 46

4.8 Gerência de Configuração e Mudança ... 47

4.8.1 Conceitos de Gerência de Configuração e Mudança de software ... 47

4.8.2 Solicitações de Mudança... 48

4.9 Testes e Avaliação de Qualidade de Software ... 49

4.9.1 Qualidade de Software ... 49 4.9.2 Teste de software ... 51 4.9.3 Documentos de Teste... 52 4.10 Exercícios ... 53

5

Arquitetura de Software ... 59

5.3 GED - Gerenciamento Eletrônico de Documentos e Workflow ... 61

5.3.1 Exercícios ... 62

5.4 Arquitetura Orientada a Serviço (SOA) ... 63

5.4.1 Serviço ... 63 5.4.2 Processos ... 63 5.4.3 Tecnologia ... 63 5.4.4 Definições de SOA ... 63 5.4.5 Web Services ... 64 5.4.6 SOAP ... 66 5.4.7 WSDL ... 67 5.4.8 UDDI ... 67 5.4.9 Segurança ... 68 5.4.10 Exercícios ... 68

5.5 Portais corporativos e colaborativos ... 69

5.6 Exercícios ... 70

6

Banco de Dados ... 73

6.1 Conceitos básicos ... 73

6.2 Modelagem de Dados Relacional ... 73

6.2.1 Normalização ... 74

6.2.2 Etapas de modelagem ... 75

6.2.3 Relacionamentos ... 75

6.2.4 Transação ... 76

6.3 Modelo Entidade Relacionamento... 76

6.4 Modelagem de Dados Multidimensional ... 77

6.4.1 Sistemas Transacionais X Sistemas Analíticos ... 78

6.5 Conceitos de Datawarehouse e ETL ... 78

6.5.1 ETL ... 80

6.6 Conceitos de desenvolvimento em banco de dados SQL Server e Oracle ... 80

6.6.1 SQL ... 80

6.6.2 Arquitetura de um Servidor Oracle... 82

6.6.3 Arquitetura de um Servidor SQL Server ... 83

6.7 Exercícios ... 84

7

Programação de Sistemas ... 90

Curso de TI

7.1.1 Tipos de dados e variáveis ... 91

7.2 Programação orientada a objetos ... 92

7.2.1 Objetos... 92 7.2.2 Classe ... 93 7.2.3 Persistência ... 93 7.2.4 Métodos ... 93 7.2.5 Atributos ... 94 7.2.6 Mensagens ... 94 7.2.7 Herança ... 94 7.2.8 Polimorfismo... 94 7.2.9 Sobrecarga ... 95 7.2.10 Interfaces ... 95 7.2.11 Pacotes ... 95 7.3 Programação na WEB ... 95 7.3.1 Linguagem HTML ... 96

7.3.2 Linguagens web de servidor... 97

7.3.3 XML ... 98

7.4 Conceitos de linguagem de programação Microsoft .NET ... 98

7.4.1 arquitetura da .Net ... 99

7.4.2 Linguagens de programação ... 99

7.4.3 Common Language Specification (CLS) ... 100

7.4.4 Common Type System (CTS) ... 100

7.4.5 Framework Class Library (FCL) ... 100

7.4.6 Camada de apresentação ... 100

7.4.7 ADO.Net ... 100

7.4.8 .Net Remoting ... 100

7.4.9 Common Language Runtime (CLR)... 101

7.4.10 Common Language Infrastructure (CLI) ... 101

7.4.11 Operating System (OS) ... 101

7.4.12 Outros detalhes da .Net ... 101

7.5 Exercícios ... 102

8

Segurança da informação ... 106

8.1 Conceitos básicos ... 106

8.2 Plano de Continuidade de Negócio ... 108

8.3 Vulnerabilidade ... 108

8.4 Auditoria e conformidade ... 109

8.5 Conhecimento sobre norma ISO 27001 ... 111

8.6 Exercícios ... 111

9

Sistemas Operacionais ... 115

9.1 Conceitos de administração de servidores em plataforma Windows ... 115

9.2 Conceitos de administração de servidores em plataforma Linux ... 115

9.2.1 Alguns comandos no Linux ... 115

9.2.2 Gerenciando a iniciação do Linux ... 117

9.2.3 Fazendo Backups... 117

9.2.4 Recompilando e Adaptando o Kernel ... 117

9.2.5 Agendando Processos ... 117

9.2.6 Syslogd - A Caixa Preta do Linux ... 117

9.2.7 Técnicas Básicas para Trabalhar com Redes (ifconfig, route) ... 118

9.2.8 Gerenciando os Serviços - inetd ... 118

9.2.9 Utilizando Ferramentas de Busca ... 118

9.2.10 Instalando SSh / SShD ... 118

9.3 Conceitos de Virtualização ... 119

9.5 Exercícios ... 122

10

Redes ... 125

10.1 Conceito de rede ... 125

10.1.1 Configuração de redes TCP-IP ... 125

10.2 Arquitetura de Rede ... 127

10.2.1 Camada Física ... 128

10.2.2 Camada de Enlace ou Ligação de Dados ... 128

10.2.3 Camada de Rede ... 128

10.2.4 Camada de Transporte ... 129

10.2.5 Camada de Sessão ... 129

10.2.6 Camada de Apresentação ... 129

10.2.7 Camada de Aplicação ... 129

10.3 Noções de administração de redes... 130

10.4 Acesso Remoto ... 130 10.5 Rede Wireless ... 130 10.6 Exercícios ... 131

11

Referências ... 135

12

Sobre o autor ... 136

13

Gabarito... 137

Sumário de imagens

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

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

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

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

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.

Um programa é um conjunto de projetos com um objetivo comum.

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

TI para concursos

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:

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

3_{http://pt.wikipedia.org/wiki/PMBOK}

1.2.1 Á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 escopo preliminar 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 Planejamento do escopo 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

Planejamento de RH Controlar ou mobilizar a equipe do projeto Desenvolver a equipe do projeto Gerenciar a equipe do projeto 10 - Comunicação Planejamento das comunicações Distribuição das informações Relatório de desempenho Gerenciar as partes interessadas 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 compras e aquisições Planejar contratações

Solicitar respostas dos fornecedores Selecionar fornecedores

Administração de contratos Encerramentos de contratos

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 - que se aplicam as entradas  Saidas – que podem ser entradas de outros processos

TI para concursos

1.2.1.1 Integração de projetos

Núcleo do gerenciamento de projetos, é composto dos processos do dia-a-dia com os quais o gerente de projetos conta para garantir que todas as partes do projeto funcionem juntas. É um processo contínuo que o gerente completa para garantir que o projeto prossiga do início ao fim – é a atividade diária de completar o trabalho do projeto..

1.2.1.2 Escopo de projetos

Garantir que o projeto inclui todo o trabalho requerido (requisitos), e somente o trabalho requerido.  Destaca-se nesta área a criação da estrutura analítica de processos (EAP), ou Work Breakdown

Structure (WBS), uma 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 entregáveis (deliverables) e tarefas, genericamente pacotes, que precisam ser feitas para completar um projeto. 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.

TI para concursos

1.2.1.3 Tempo de projetos

1.2.1.4 Custo de projetos

TI para concursos

1.2.1.5 Qualidade de projetos

 Garantir que o projeto vai satisfazer as necessidades pelas quais ele foi feito. Qualidade não é o melhor resultado possível, mas o atendimento justo dos requisitos, do cronograma e orçamento.  Qualidade é a totalidade de características de uma entidade que a torna capaz de satisfazer

necessidades declaradas ou implícitas .

 Um aspecto crítico da gerência da qualidade, no contexto do projeto, é a necessidade de traduzir as necessidades implícitas em necessidades declaradas, através da gerência do escopo do projeto

1.2.1.6 Recursos humanos de projetos

TI para concursos

1.2.1.7 Comunicações de projetos

 Garantir rápida e adequada geração, coleção, disseminação, armazenamento e disposição final das informações do projeto.

1.2.1.8 Riscos de projetos

TI para concursos

1.2.1.9 Aquisições de projetos

1.3

Planejamento e controle de métricas de projeto

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.

 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

Andamentoem 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)

Estabilidadeem 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

Modularidadeem 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

Qualidadeem 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

TI para concursos

Métrica Finalidade Exemplos de medidas/perspectivas

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

Maturidadeem 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 despesasdo 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. 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, é denominada3

(a) Critical Chain Method. (b) Probability and Impact Matrix. (c) Work Performance Information. (d) Performance Measurement Baseline.

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, é denominada4

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

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.

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.

TI para concursos

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.

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

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

TI para concursos

2

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

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

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

BPMN - Modelagem de processos

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.

2.1.1 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 comporatmento 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 esquera à 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  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. Represnetado 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 2 Exemplo de Fluxo utilizando pool, lanes, evento de início e fim, tarefas e gateway

TI para concursos

2.2

Técnicas de análise de processos

2.2.1 Automação 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 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.5

2.2.2 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.2.3 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.

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.2.4 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.2.5 IDEF

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

TI para concursos

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.2.5.1 IDEF0

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

2.2.5.2 IDEF1

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

2.2.5.3 IDEF3

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

2.2.5.4 IDEF4

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

2.2.5.5 IDEF5

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

2.2.5.6 IDEF9

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

2.2.6 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.2.7 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.

Processo

Entradas _Saídas

Controle

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.

2.2.8 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.3

Exercícios

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

(a) processes e tasks. (b) events e gateways.

(c) pools e lanes.xx

(d) pools e processes. (e) lanes e tasks.

24. (ICMS-SP 2009) Na modelagem de processos de negócio (BPMN), NÃO se aplica um End Event no tipo de trigger 24 (a) Exception. (b) Link. (c) Message. (d) Multiple. (e) Timer.xx

TI para concursos

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

(a) entre white boxes.

(b) entre black boxes.xx

(c) entre tasks. (d) dentro de tasks. (e) dentro de black boxes.

3

Gerência de Serviços de TI

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

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

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

 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).

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

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.

TI para concursos

3.1

Fundamentos da ITIL V2

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

3.1.1.1 Central de serviços (service desk)

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

3.1.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.1.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.1.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.1.1.5 Gerenciamento de liberação (implantação) Libera e distribui a alteração autorizada. Implanta.

3.1.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.1.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.1.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.1.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.1.2.3 Gerenciamento de disponibilidade

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

3.1.2.4 Gerenciamento de capacidade

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

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

3.2

Fundamentos de ITIL V3

O núcleo do ITIL V3 é composto de cinco processos baseados no ciclo de vida dos serviços:  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 4 Ciclo de vida do serviço - Núcleo do ITIL V3

3.2.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.2.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

8_{http://pt.wikipedia.org/wiki/ITILv3}

 capacidade

 continuidade de serviços  segurança da informação  fornecedores

 catálogo de serviços.

3.2.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.2.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.2.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  Sete passos de melhoria

3.3

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.

TI para concursos

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

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.

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.3.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 o Gerenciamento Tecnológico

 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

3.3.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 Credenciar Soluções e Mudanças

3.3.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 Performance e Capacidade  DS4 Assegurar Serviço Contínuo

 DS5 Assegurar Segurança de Sistema  DS6 Identificar e Alocar Recursos  DS7 Treinar Usuários

 DS8 Gerenciar Serviços de Escritório e Incidentes  DS9 Gerenciar a Configuração

 DS10 Gerenciar Problemas  DS11 Gerenciar Dados

 DS12 Gerenciar o Ambiente Físico  DS13 Gerenciar Operações

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

3.4

Exercícios

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

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

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

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

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

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

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

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

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

(a) Responsabilidade corporativa.

(b) Objetivos do negócio.xx

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

TI para concursos

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

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

32. (ICMS-SP 2009) No gerenciamento de serviços de TI, segundo o ITIL v.2, tem foco operacional o processo:32

(a) configuration management.xx

(b) capacity management. (c) availability management. (d) service level management.

(e) customer relationship management.

33. (ICMS-SP 2009) No gerenciamento de serviços de TI, segundo o ITIL v.2, tem foco tático ou estratégico o processo:33

(a) problem management. (b) incident management. (c) release management.

(d) continuity management.xx

(e) change management.

34. (ICMS-SP 2009) O processo de gerenciamento de serviços Service Desk, segundo o ITIL v.2, NÃO gerencia34

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

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

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

(d) operação de serviços.xx