Gestão de Tecnologia

da Informação
 Material teórico
Governança e Projetos em TI

Responsável pelo Conteúdo:

Prof. Ms. Artur Marques

Revisão Textual:
Profa. Ms. Magnólia Gonçalves Mangolini
 Governança e Projetos em TI

Nessa unidade falaremos, de forma introdutória, da

importância do gerenciamento de projetos na área de TI,
focada no framework, proposto pelo PMBOK®, não
concentrado em desenvolvimento de sistemas. Para isso,
podemos utilizar métodos ágeis e alguns outros associados a
CMMI e ao próprio PMBOK®, estamos nos referindo
especificamente em infraestrutura e outros tipos de projetos
que ocorrem em Gestão de Tecnologia de Informação.

Também abordaremos o framework ITIL, muito utilizado em

TI para realizar a gestão de serviços visando à prestação de
um serviço melhor ao usuário e atendimento das áreas da
empresa que precisam de suporte. Atuam também em
incidentes e problemas. Trata-se, atualmente, do framework
mais utilizado para este fim, no Brasil e no mundo.

Veremos introdutoriamente os livros que cuidam de gestão de

suporte e serviços.

Enfatizo a leitura do material deste módulo de forma atenta e,

após isso, você precisa realizar os exercícios propostos.

Atenção

Para um bom aproveitamento do curso, leia o material teórico atentamente antes de realizar
as atividades. É importante também respeitar os prazos estabelecidos no cronograma.
 Contextualização

Silva Filho (2006) versa que, até certo ponto, é natural àqueles que desenvolvem
novos sistemas iniciarem suas atividades de desenvolvimento antes mesmo que eles entendam
o que tem de ser feito, ou seja, antes mesmo que saiba qual é o problema a ser solucionado.
O resultado desse tipo de atitude é e tem sido o insucesso de projetos.

Para trabalharmos e gerirmos um projeto, devemos trabalhar longamente no

entendimento do trabalho a ser feito e nas entregas esperadas, caso contrário, não saberemos
onde temos que chegar e isso é o grande causador de fracassos e problemas com clientes
internos e externos a organização e também é a causa mais comum da inserção de erros logo
cedo no desenvolvimento que custarão muito caro quando forem descobertos. Isso acontece
infelizmente porque há pouca preocupação do profissional de tecnologia da informação com a
Gestão, principalmente dos insumos humanos e materiais necessários para o correto
aproveitamento e cumprimento dos objetivos do projeto. Problemas culturais e baixa
capacitação dos colaboradores são outros problemas que recrudescem o resultado ruim dos
projetos em tecnologia da informação.

Renner (2008), citando Ricardo Viana Vargas do PMI board, diz que apesar do Brasil
ter um número limitado de profissionais certificados em práticas de gerenciamento de projetos,
cerca de cinco mil, e da América Latina responder por apenas 4% do total mundial, a
realidade é muito diferente em outras partes do globo.

Grande parte dos profissionais certificados no Brasil atua preponderantemente na área

de tecnologia da informação, setor que tem maior carência e necessidade desse tipo de
profissional devido à complexidade dos projetos que são realizados e a criticidade empresarial
que representam nos dias de hoje.

As organizações no mercado globalizado em que vivemos realizam seus objetivos

estratégicos através de projetos. Neles estão contidas as doses de inovação investidas para
produzir produtos e serviços diferenciados que garantirão a sobrevivência das empresas na
economia moderna e hiper competitiva a qual vivemos.

Vamos conhecer um pouco sobre as melhores práticas que têm transformado em

sucesso os projetos das organizações em todo o mundo.
 Material Teórico

Fundamentos de Gestão de Projetos

O conceito moderno sobre gerência de projetos nasceu nos Estados Unidos, no final da
década de 50 e início da década de 60, motivado, entre outras coisas, pelo projeto Apollo que
levaria o homem à Lua. Todavia, as aplicações iniciais das melhores práticas foram aplicadas
para se realizar a análise de sistemas computacionais e a implementação de empreendimentos
físicos, como construções complexas e bens de consumo.

A gestão de projetos fornece conceitos e melhores práticas para que sejam enfrentadas
as mudanças e riscos impostos pelo dia a dia da globalização e a necessidade de lançar
produtos e serviços em tempos cada vez menores, com cada vez mais qualidade e valor
agregado. Além disso, a gestão de projetos oferece ferramentas e técnicas para lidar com essas
mudanças. O responsável pela execução e gerenciamento dessas mudanças se chama gerente
de projetos.

De acordo com o PMBOK (2008) “um projeto é um empreendimento único que deve
apresentar um começo e um fim claramente definidos e que, conduzido por pessoas, possa
atingir seus objetivos respeitando os parâmetros de prazo, custo e qualidade”.

O que caracteriza de forma mais marcante um projeto são as categorias de entregas

que ele pode proporcionar, como por exemplo:

• Produtos: produto ou objeto produzido, quantificável, podendo ser final ou

intermediário.
• Serviços: são itens de capacidade, funções de negócio para produção,
armazenagem ou logística, desenhos ou melhorias em processos, inovação em uma
abordagem de sistemas, entre outros.
• Resultados: relatórios, pareceres, documentos, resultados finais. Por exemplo,
criação de algo inovador que gere uma documentação de patente, um projeto de
pesquisa exploratória que desenvolve ciência.

Subprojetos: em vários casos um projeto precisa ser dividido em partes devido a sua
grande complexidade ou característica de produção, isso auxilia em seu gerenciamento e
controle. Essas partes, que foram divididas, chamamos de subprojetos. Elas são muito
específicas e podem ser feitas por terceiros ou por equipes dedicadas. O mais importante é
que o subprojeto tratado isoladamente não faz sentido, ele precisa estar agregado ao projeto
principal. Imagine que a arquitetura e modelagem do banco de dados para uma aplicação
específica em tempo real seja tratada como subprojeto, ela não tem sentido em ser
desenvolvida se não houver o projeto de software que tratará estas informações em tempo
real, ou seja, não há outra utilidade para essa modelagem que não seja servir esse software,
ela não serve para outro software.

• Programas: usamos esse termo para designar quando vários projetos estão
concentrados em um conjunto de melhoramentos e táticas comuns. O mais
importante é que eles podem ter vida própria, além do projeto principal. Por
exemplo, vamos fazer um avião, uma das partes é a turbina, ela faz parte do
programa do avião, ou seja, a turbina pode ser desenvolvida para esse avião que
será construído, mas pode ser usada por outros projetos de aviões diferentes que
possam utilizar o mesmo propulsor.

Gerenciamento de projetos: conforme definição do PMBOK (2008) é a aplicação de

conhecimentos, habilidades, ferramentas e técnicas às atividades do projeto, cuja finalidade é
atender aos seus requisitos. Isso inclui, mas não se esgota em:

• Identificar as necessidades do projeto;

• Estabelecer objetivos claros, mensuráveis e alcançáveis;
• Balancear, distribuir e resolver demandas conflitantes que envolvam entre outras
áreas de conhecimento: riscos, qualidade, escopo, tempo, comunicação e custo;
• Adaptar as especificações e abordagens, dos diferentes planos, preocupações e
expectativas dos stakeholders (partes interessadas) que na versão 5 do PMBOK é
uma área de conhecimento nova.

Conforme Schmitz (2005, 16), as áreas de conhecimento do PMBOK são 9 e possuem

os seguintes propósitos:

• Escopo: A Gerência de Escopo assegura que o projeto inclua todo o trabalho necessário,
e tão somente o necessário, para complementar de forma bem sucedida o mesmo. Define
e controla o que está e o que não está incluído no projeto. A principal ferramenta é a
Estrutura Analítica do Projeto – EAP (em inglês, WBS – Work Breakdown Structure), que
identifica e decompõe os principais elementos do projeto.
• Tempo: Seus processos consideram a definição de atividades e seu sequenciamento
(identificação de relacionamentos de dependência entre elas), estimativas de recursos e
duração, desenvolvimento do cronograma e seu controle. Os processos da gerência de
tempo são executados em paralelo com a gerência de custos, uma vez que a duração de
uma atividade depende diretamente da quantidade de recursos alocados para a mesma.
• Custo: Contempla os custos dos recursos necessários a implantação das atividades. Ela
inclui os processos necessários para assegurar que o projeto será concluído dentro do
orçamento aprovado. Seus processos são a estimativa e orçamento dos custos e seu
controle. As principais técnicas e ferramentas utilizadas são: avaliação especializada de
consultores, estimativas por analogia de outros projetos, estimativas por desagregação de
custos (botton-up) ou modelos paramétricos.
 • Qualidade: Garantir que o projeto irá satisfazer as necessidades para as quais ele foi
empreendido. A preocupação com qualidade deve ser estendida também para os
fornecedores de insumos do projeto, devendo ficar claro que as referências de qualidade
da organização devem ser seguidas nos projetos.
• Risco: propõe a identificação, análise e resposta aos riscos do projeto, considerando
riscos internos e externos. Os processos contemplam a identificação, qualificação e
quantificação dos riscos, desenvolvimento e controle de respostas, e monitoramento. A
abordagem geralmente utilizada é a análise dos resultados que devem ser evitados e a
monitoração de suas causas por meio do estabelecimento de gatilhos de aviso.
• Comunicação: Garantir a geração, coleta, distribuição, armazenamento, recuperação e
destinação final das informações sobre o projeto de forma oportuna e adequada. Previne
interpretações errôneas e garante que a informação correta esteja disponível para quem
dela necessite.
• RH: Contempla os processos requeridos para possibilitar o uso mais efetivo das pessoas
envolvidas no projeto. Os principais tópicos a serem destacados são: liderança,
negociação, comunicação, delegação, motivação, formação de equipes, gerência de
conflitos, treinamento, avaliação de desempenho, recrutamento e manutenção das
relações de trabalho.
• Aquisição: Inclui os processos necessários para a obtenção de bens e serviços externos a
organização executora, para a realização do trabalho. Possui as seguintes necessidades:
preparação das aquisições e contratações, obtenção de propostas, seleção de
fornecedores, administração e encerramento dos contratos.
• Integração: Compreende a coordenação entre os diversos elementos do projeto, através
de processos, ferramentas e técnicas. É executada durante todo o projeto, paralelamente
as demais gerências, integrando seus resultados no Plano do Projeto.

Grupo de processos: trata-se dos macroprocessos existentes durante o ciclo de vida de

um projeto e serve para demonstrar, determinar e atuar sobre documentos, relatórios,
atuações, papéis e fases esperadas para saber como está à situação do projeto e quais esforços
estão consumindo os recursos. Essas fases são:

• Iniciação: Determina a existência do projeto, são documentos e atividades de

autorização e início. Por exemplo: contrato assinado, designação do gerente de
projeto, termo de abertura do projeto.
• Planejamento: Cria e depura os objetivos do projeto, cria documentos
estruturados de planejamento de ação necessários para atingir as metas e o escopo
do projeto.
• Execução: trata da junção de recursos humanos e materiais para a execução do
projeto, é o fazer, conforme estabelecido na fase de planejamento.
• Monitoramento e controle: estabelece medidas para controle de desempenho e
previsão identificando variações contra o plano estabelecido para que possam ser
tomadas medidas proativas e reativas sob as situações encontradas.
• Encerramento: constitui os elementos de finalização do projeto, entre outros a
parte operacional, entregas, termos de aceite, termos de homologação e também a
 parte administrativa, como por exemplo, ordem de emissão de nota fiscal final,
encerramento de contrato, entre outros.

Figura 1: Grupo de Processos do PMBOK para Gestão de Processos.

Fonte: http://professorprojeto.blogspot.com.br/2011/04/mapas-mentais-pmbok.html

Então podemos perceber que cabe ao GP e a equipe determinar quais processos são
os adequados e o grau de exigibilidade de cada processo para cada empresa e para cada
projeto em específico.

Escopo

Conforme Ricardi (2005), Escopo possui os seguintes componentes:

• Do produto: é aquilo que vai ser entregue como resultado do projeto, ou seja, um
produto, serviço ou qualquer outro resultado específico.
• Do projeto: é o conjunto das atividades que precisam ser realizadas para entregar
o escopo do produto.
• Requisitos: representam as características de algo que será entregue ou
executado. Portanto podemos ter, em uma visão macro, requisitos de produto e
requisitos de projeto. Uma das melhores formas de detalhar o escopo do projeto e
 do produto é através do detalhamento de requisitos associados. Através deles você
consegue aumentar a precisão em documentar as necessidades e desejos dos
envolvidos (partes interessadas) no projeto. Devem atender as seguintes
características:
o Necessário: ele é essencial para o bom funcionamento da entrega ou do
projeto. Se não estiver presente, caracteriza uma deficiência;
o Completo: não exige complementos para ser atingido ou atendido, ou então
está relacionado a outros requisitos que o complementam e esta relação está
explícita e é de conhecimento e aprovada por todos quem interessa;
o Consistente: não contradiz outros requisitos ou outros aspectos relacionados
ao projeto;
o Não ambíguo: evita interpretação ambígua;
o Conciso: define uma única coisa que deve ser feita e só a coisa que deve ser
feita;
o Isento de implementação: define o que deve ser feito ou atendido, e não
como ocorrerá;
o Factível: é passível de ser atingido durante a execução do projeto, por um
custo dentro dos limites orçados, no prazo necessário e com os recursos
disponíveis;
o Verificável: pode ser quantificado de forma a ter o seu atendimento verificado
através de testes ou inspeções.
• Componentes: um documento de escopo bem definido deverá conter em sua
composição pelo menos:
o Critérios de aceitação
o Objetivos
o Premissas
o Restrições

Sua constituição é feita dos seguintes processos e atividades:

Entradas
• Termo de abertura do projeto
Fornece a base para iniciar o detalhamento dos requisitos, pois contém a descrição
do produto e alguns requisitos em alto nível.

• Registro das partes interessadas

Serve de referência para identificar quais as partes interessadas que poderão
fornecer detalhes e definição a respeito dos requisitos necessários.
Ferramentas e Técnicas

• Entrevistas
Utiliza conversas diretas com as partes interessadas, individualmente, no formato
de perguntas e respostas, que deverão ser registradas e aprovadas pelos
entrevistados.

• Dinâmicas de grupo
Reúnem especialistas e partes interessadas pré-qualificadas, com o objetivo de
levantar expectativas e atitudes relacionadas ao escopo do produto e/ou ao escopo
do projeto.

• Oficinas
Reúnem partes interessadas de diversas áreas e/ou funções, com o objetivo de
definir rapidamente requisitos que atendam a todos, reconciliando diferenças entre
os diversos requisitos associados. Técnica recomendada para levantamento de
funcionalidades complexas e que envolvem muitos interessados. Exemplos: JAD
(Joint Application Design) e QFD (Desdobramento da Função de Qualidade).

• Técnicas de criatividade em grupo

 Brainstorming
A criatividade não é repreendida, e todos podem sugerir e opinar a respeito.

 Técnica de grupo nominal

Amplia a técnica de Brainstorming incluindo um processo de votação.

 A técnica DELPHI
São elaborados questionários que são submetidos, de forma anônima, a
especialista no assunto. Estes deverão responder a um facilitador que repetirá o
envio aos envolvidos, em ciclos de perguntas e respostas, até coletar todos os
requisitos necessários.

 Mapas mentais
Diagramas com estrutura de itens e subitens, assuntos e descrições, que
denotam linha de raciocínio semelhante ao cérebro humano.

 Diagrama de afinidade
Organiza grande quantidade de ideias agrupando para revisão e análise.

• Técnicas de tomada de decisão em grupo

Avalia múltiplas alternativas com o objetivo de resolver ações futuras. Gera,
classifica e prioriza os requisitos do produto. Inclui os seguintes métodos:
 Unanimidade
 Maioria
  Pluralidade
 Ditatura

• Questionários e pesquisas
Utilizados quando existe um universo muito grande de candidatos a entrevistas, e
não há tempo hábil para conversas individuais.

• Observações
Acompanhamento e observação dos profissionais em seu ambiente de trabalho,
onde a probabilidade de esquecimento de requisitos importantes é minimizada, e o
entendimento das necessidades fica facilitado.

• Protótipos
Validação de modelo funcional do produto anterior à sua construção. Permite ao
cliente visualizar e em algumas situações manipular o produto de forma simulada.

Saídas

• Documentação dos requisitos

Algumas organizações têm ferramentas específicas que permitem a documentação
e o gerenciamento dos requisitos do projeto e do produto. Descreve como os
requisitos individuais irão atender às necessidades de negócio do projeto, e pode
ser apresentada em forma de listas categorizadas, priorizadas e associadas a outras
informações importantes e necessárias para o projeto.

• Plano de gerenciamento dos requisitos

Define como os requisitos serão levantados, analisados, documentados e
gerenciados durante todo o ciclo de vida do projeto. Não menospreze a
importância deste plano, por ele ser um plano auxiliar. Sem uma definição
consistente relacionada a este assunto, o projeto pode tomar um rumo de
descontrole e falta de objetividade, e as consequências serão imprevisíveis.

• Matriz de rastreabilidade dos requisitos

Associa os requisitos aos objetivos de negócio e aos objetivos do projeto. Ainda,
consolida os requisitos criando referência com outros requisitos e com as entregas
do projeto.

• EAP: trata-se de Estrutura hierárquica que decompõe as entregas do projeto e os

pacotes de trabalho associados. Será utilizada como base para estimar e controlar
escopo, custos e cronograma.
• Dicionário da EAP: Fornece o detalhamento dos componentes da EAP. Segundo o
Guia PMBOK, poderá conter as seguintes informações (inclua ou retire aquelas que
considerar necessário):

o Código de identificador da conta

o Descrição do trabalho necessário
o Organização ou pessoa responsável pela execução
o Lista de marcos do cronograma
o Atividades do cronograma associadas
o Recursos necessários
o Estimativa de custos
o Requisitos de qualidade
o Critérios de aceitação (da entrega, que pode conter os critérios dos requisitos
associados, e mais algum que tenha a ver diretamente com a entrega. Exemplo:
esta entrega deverá ser validada pelo Diretor Fulano de Tal)
o Referência técnica
o Informações do contrato
o

• Linha de base do escopo: Componente do plano de gerenciamento do projeto é

composta pelos documentos:
o Declaração de escopo do projeto
o EAP
o Dicionário da EAP
 Figura 2: exemplo EAP para um sistema de informação
Fonte: http://www.gtics.com.br/wa_files/GRUPO-04_EAP_v1_3.png
Id. Pacote de Trabalho Descrição

Análise da situação atual Levantamentos dos pontos críticos e oportunidades de melhoria,

1.1 suas causas e consequências. Este pacote realizou o estudo
necessário para a definição da estratégia a ser seguida: terceirizar ou
desenvolver solução própria

Alocação da equipe Designação de funcionários para o projeto.

1.2
Definição da função de cada membro e disponibilidade de tempo
exigida.

Definição de cada membro da equipe, por pacote de trabalho.

Elaboração do Plano de Define como o projeto será executado, quais são os recursos,
1.3 Projeto financeiros e humanos alocados.

Estudo e mapeamento Analisar e realizar um mapeamento de um fluxo de trabalho padrão

2.1 do fluxo de trabalho para leilão eletrônico a todos os cartórios.
para procedimento de
leilão eletrônico

Figura 3: exemplo de um dicionário de EAP

Fonte: http://desenv.tjms.jus.br/confluence/pages/viewpage.action?pageId=5505070

Tempo

Para o PMBOK® (2008:112), “o Gerenciamento do Tempo do Projeto inclui os

processos necessários para gerenciar o término pontual do projeto”.

Marques et ali (2011) apontam e comentam os seguintes processo e atividades

necessários para a gestão do tempo no projeto, incluindo o diagrama de rede e o cálculo DO
CAMINHO Crítico envolvendo a técnica CPM – Critical Path Method a saber:

• Definir as atividades: Trata-se da identificação das ações que precisam ser feitas
para produzir as entregas do projeto. Para tanto precisamos, após identificá-las,
criar a EAP – Estrutura Analítica do Projeto - que serve para identificar as entregas
no nível mais baixo da estrutura, a qual chamamos de pacote de trabalho. Uma
vez levantada junto às áreas uma lista de atividades que serão realizadas, passamos
a criação da EAP e inserimos seus tempos. Porém, para iniciarmos, precisamos
conhecer algumas técnicas para definir essas atividades.
• Decomposição: trata-se de subdividirmos os pacotes de trabalho em atividades
que, de acordo com o PMBOK®, são mais gerenciáveis, de forma que o trabalho e
 as entregas estejam definidos até o nível de pacote de trabalho. Este nível é o mais
baixo na EAP antes do Deliverable e é onde o custo e o cronograma podem ter
uma estimativa mais confiável. Decompor envolve algumas atividades como:
o Identificar as entregas relacionadas à estruturação e organização da EAP.
o Quebrar os níveis mais elevados da EAP ampliando a granularidade, ou seja,
detalhando para níveis mais baixos.
o Atribuir os códigos de identificação (taxonomia) aos itens da EAP.

• Lista das atividades: segundo as melhores práticas do PMBOK® (2009:118), a

lista das atividades é uma lista abrangente que inclui todas as atividades
necessárias no projeto. Inclui o identificador e uma descrição do escopo do
trabalho de cada atividade em detalhe suficiente para assegurar que os membros
da equipe entendam qual trabalho precisa ser executado.

• Lista dos marcos: o marcos é datas chave no projeto e servem para designar ou
identificar um evento significativo e importante no projeto. Podendo ser uma
entrega, uma reunião ou uma homologação, início ou encerramento.

• Sequenciar as atividades: Considera que as principais atividades de um projeto

devem ser executadas levando-se em consideração a ordem e os desdobramentos
das atividades que compõem os pacotes de trabalho e as entregas da EAP. Para o
PMBOK® (2009:119), sequenciar as atividades “é processo de identificação e
documentação dos relacionamentos entre as atividades do projeto”. Essas são
sequenciadas usando relações lógicas (atividade predecessora e sucessora).
Sequenciamento permite que todas as partes interessadas no projeto possam
visualizar o trabalho a se realizar até a finalização do projeto. O Gerente de
Projetos deverá possuir em suas mãos como entradas para a execução das
atividades de sequenciamento:
o Lista das atividades;
o Atributos das atividades;
o Lista dos marcos;
o Declaração do escopo do projeto;
o Ativos de processos organizacionais.
• Método do diagrama de precedência (MDP): constrói o diagrama de rede do
projeto através do uso de diversos nós que objetivam representar as atividades, e
setas são utilizadas para que os nós fiquem ligados, mostrando suas dependências.
Esta técnica é chamada de Atividade nos Nós, a maioria dos sistemas que apoiam
o gerenciamento de projetos é baseada nela. O PMBOK® (2009:120) determina
quatro tipos de dependências:
o Término para Início (TI) - o início da atividade sucessora depende do
término da atividade predecessora.
o Término para Término (TT) - o término da atividade sucessora depende do
término da atividade predecessora.
 o Início para Início (II) - o início da atividade sucessora depende do início da
atividade predecessora.
o Início para Término (IT) - o término da atividade sucessora depende do
início da atividade predecessora.

Figura 4: Exemplo de diagrama de precedência MDP

Fonte: http://arquivos.unama.br

Existem três tipos de determinação que podemos utilizar:

o Dependências obrigatórias: conforme o PMBOK® (2008:120), são aquelas
exigidas contratualmente ou inerentes à natureza do trabalho. A equipe do projeto
define quais dependências são obrigatórias durante o processo de sequenciamento
das atividades. Geralmente envolvem limitações físicas, tais como num projeto de
construção onde é impossível erguer a superestrutura antes que a fundação tenha
sido concluída, ou num projeto de componentes eletrônicos, onde um protótipo
tem que ser construído antes de ser testado.
o Dependências arbitradas: normalmente são estabelecidas baseadas no
conhecimento das melhores práticas numa área de aplicação específica ou em
algum aspecto particular do projeto onde uma sequência específica é desejada,
mesmo que haja outras sequências possíveis ou aceitáveis. Existe a necessidade de
documentação dessa dependência para evitar problemas de comunicação e para
justificativa do caminho escolhido.
o Dependências externas: o gerente do projeto ou sua equipe definem quais
dependências são externas durante o processo de sequenciamento das atividades.
Isso envolve uma relação entre as atividades do projeto e as não pertencentes ao
mesmo. Aplicação de antecipações e esperas: PMBOK® (2009) determina que
uma antecipação permita um aceleramento da atividade sucessora. Por exemplo,
num projeto para construir um novo edifício de escritórios, o paisagismo poderia
ser agendado para começar duas semanas antes do término agendado dos itens da
lista. Isso seria mostrado como um término para início com uma antecipação de
duas semanas. Uma espera direciona um retardo na atividade sucessora. Por
exemplo, uma equipe de redação técnica pode iniciar a edição do rascunho de um
grande documento quinze dias após ter começado a escrevê-lo. Isso poderia ser
mostrado como um início para início com uma espera de quinze dias. O uso de
antecipações e esperas não deve substituir a lógica de desenvolvimento do
cronograma. As atividades e suas premissas relacionadas devem ser
documentadas. Uma antecipação permite um aceleramento da atividade sucessora.
 • Modelos de diagrama de rede de cronograma: são utilizados para agilizar a
preparação da rede de atividades e normalmente estão em repositórios de
conhecimento nas organizações para esta finalidade. Podem conter todo projeto ou
partes ou até mesmo fragmentos. Segundo o PMBOK® (2009:121): (...) os
modelos de sub-redes são especialmente úteis quando um projeto inclui várias
entregas idênticas ou quase idênticas, tais como andares num alto prédio de
escritórios, testes clínicos num projeto de pesquisa farmacêutico, módulos de
programas de codificação num projeto de software, ou a fase inicial de um projeto
de desenvolvimento.
• Estimar os Recursos da Atividade: As melhores práticas do PMBOK® rezam
que, para estimar os recursos de uma atividade envolvemos os tipos e quantidades
de material, pessoas, equipamentos ou suprimentos que serão necessários para
realizar cada atividade da EAP. Estimar os recursos para uma atividade está
intimamente ligado com o processo de estimativa de custos, sendo que podemos
nos apropriar das mesmas técnicas que utilizamos nessa área da gestão de projetos.
Dois exemplos práticos impostos pelo PMBOK® (2009:122) demonstra o grande
grau de sinergia entre esses processos:
o Uma equipe de um projeto de construção precisará estar familiarizada com as
legislações de construção locais. Geralmente, tal conhecimento está facilmente
disponível em fornecedores locais. Contudo, se o serviço de mão de obra local
carece de experiência em técnicas de construção incomuns ou especializadas,
o custo adicional de um consultor pode ser a maneira mais efetiva de assegurar
o conhecimento das legislações de construção locais.
o Uma equipe de planejamento automotivo precisará estar familiarizada com as
mais recentes técnicas de montagem automatizada. O conhecimento
necessário pode ser obtido através da contratação de um consultor, do envio
de um projetista a um seminário de robótica, ou da inclusão de alguém da
produção como um membro da equipe do projeto.
• Estimar as Durações da Atividade: segundo o PMBOK® (2008), é o processo de
estimativa do número de períodos de trabalho que serão necessários para terminar
as atividades específicas com os recursos estimados.
o A estimativa das durações das atividades utiliza informações sobre as atividades
do escopo do projeto, tipos de recursos necessários, quantidades estimadas de
recursos e calendários de recursos. As entradas para as estimativas de duração
da atividade se originam da pessoa ou grupo na equipe do projeto que está
mais familiarizado com a natureza do trabalho na atividade específica. A
estimativa da duração é elaborada progressivamente e o processo considera a
qualidade e a disponibilidade dos dados de entrada (PMBOK®, 2009:125).

Estimar a duração de uma atividade requer que a quantidade do esforço e recursos

necessários sejam aplicados para finalizar a atividade. Dessa forma, estes elementos são
utilizados para gerar o número de mês/dias/horas de trabalhos necessários para a finalização
da atividade. A duração decorre do esforço requerido para completar o trabalho relativo a
uma atividade do projeto, e ajustar esse esforço levando em conta com os seguintes fatores:

o A quantidade de recursos que irão realizar o trabalho e o grau de eficiência desses

recursos.
o O calendário de disponibilidade dos recursos (isto é se eles estão disponíveis a 100%
ou numa outra qualquer percentagem inferior de tempo).
o Os períodos específicos de inatividade (fins de semana, feriados e férias contratuais).
o Número normal de horas diárias de trabalho.

Para estimarmos a duração, podemos utilizar um mapeamento mediante o uso de um

fluxo como nos exemplos abaixo:

Figura 5: Fluxo para concluirmos a atividade para estabelecer a duração das atividades no projeto.
Fonte: http://ricardosatin.blogspot.com/2009/12/estimativa-de-duracao-de-atividades.html

• Desenvolver o Cronograma: Conforme o PMBOK® (2009:129), desenvolver o

cronograma é o

“processo de análise de sequências das atividades, suas durações, recursos

necessários e restrições do cronograma visando criar o cronograma do projeto.
A entrada das atividades, durações e recursos na ferramenta de elaboração de
cronograma gera um cronograma com datas planejadas para completar as
atividades do projeto” (PMBOK®. 2009. P.129).
 Importante citar no processo de construção do cronograma, tratar-se de um elemento
dinâmico e ativo de forma que a sua revisão e a manutenção são necessárias para mantê-lo
em concordância à realidade e deve ser executada durante todo o projeto à medida que o
trabalho avança, pois o plano de gerenciamento muda e a natureza dos eventos de riscos,
custos e recursos humanos evolui. Para podermos desenvolver o cronograma, precisamos
estar munidos dos seguintes documentos de projeto, que chamaremos aqui de entradas do
processo Desenvolver o Cronograma:

o Lista das atividades

o Atributos das atividades
o Diagramas de rede do cronograma do projeto
o Requisitos dos recursos da atividade
o Calendários dos recursos
o Estimativas da duração da atividade
o Declaração do escopo do projeto
o Fatores ambientais da empresa
o Ativos de processos organizacionais.

• Análise da rede do cronograma: os diagramas de rede são amostras

esquemáticas das atividades do cronograma do projeto e as suas relações lógicas,
também chamadas de dependências.
• Método do caminho crítico: calcula as datas hipotéticas de início e término
mais cedo e início e término mais tarde, em todas as atividades, sem considerar
quaisquer limitações de recursos, executando uma análise dos caminhos de ida e
de volta através da rede do cronograma. De acordo com o PMBOK® (2009), as
datas resultantes de início e término mais cedo e início e término mais tarde não
são necessariamente o cronograma do projeto, mas sim uma indicação dos
períodos de tempo dentro dos quais a atividade poderia ser agendada, dadas as
durações do projeto, relações lógicas, antecipações, esperas e outras restrições
conhecidas.

O PMBOK® (2009:132) determina que os caminhos críticos tenham uma folga total
igual à zero ou negativa e as atividades do cronograma que estão no caminho crítico são
chamadas ― atividades críticas. Um caminho crítico é normalmente caracterizado por uma
folga total igual à zero no caminho crítico. Redes podem ter múltiplos caminhos quase críticos.
Ajustes às durações da atividade, relações lógicas, antecipações e esperas e outras restrições
do cronograma podem ser necessários para produzir caminhos com folga total zero ou
negativa. Uma vez que a folga total para um caminho da rede tenha sido calculada, a folga
livre, isto é, a quantidade de tempo que uma atividade pode ser atrasada sem atrasar a data
de início mais cedo de qualquer atividade imediatamente sucessora dentro do caminho crítico,
pode também ser determinada.
 Figura 06: Caminho crítico em um projeto (em vermelho)
Fonte: http://teccrono.com.br/plan-desenvolvimento.html
• Compressão do Cronograma: conforme PMBOK® (2009), serve para encurtar
o cronograma do projeto sem mudar o escopo do mesmo, para respeitar as
restrições do cronograma, datas impostas ou outros objetivos do cronograma, as
técnicas de compressão do cronograma incluem:
o Compressão. Exemplos de compressão poderiam incluir a aprovação de horas
extras, recursos adicionais ou o pagamento para a aceleração da entrega das
atividades no caminho crítico. A compressão funciona somente para as
atividades onde recursos adicionais encurtarão a sua duração. A compressão
nem sempre produz uma alternativa viável e pode resultar num maior risco
e/ou custo.
o Paralelismo. Uma técnica de compressão do cronograma na qual fases ou
atividades normalmente executadas em sequência são executadas em
paralelo. Um exemplo é a construção da fundação de um prédio antes que
todos os desenhos arquitetônicos tenham sido terminados. O paralelismo
pode resultar na repetição de trabalho e aumento de risco. O paralelismo
funciona somente se as atividades podem ser sobrepostas para encurtar a
duração.

Figura 06: Compressão

Fonte: http://teccrono.com.br/
 Figura 07: Paralelismo
Fonte: http://teccrono.com.br/

• Saídas do processo para criar o cronograma:

o Cronograma do projeto: o cronograma do projeto inclui pelo menos uma data
de início e de término planejadas para cada atividade.
o Gráficos de marcos: esses gráficos assemelham-se aos gráficos de barras, porém
identificam somente o início ou término agendado para as entregas mais
importantes e interfaces externas chaves.
o Gráfico de barras: esses gráficos, onde as barras representam as atividades,
mostra as datas de início e término da atividade, assim como as durações
esperadas.
o Diagramas de rede do cronograma do projeto: esses diagramas, com
informações sobre as datas das atividades, normalmente mostra tanto a lógica
da rede do projeto como suas atividades do seu caminho crítico.
o Linha de base do cronograma: uma linha de base do cronograma é uma versão
específica do cronograma do projeto desenvolvido a partir da análise de rede
do mesmo.
o Dados do cronograma: os dados de apoio do cronograma para compor o
cronograma do projeto incluem pelo menos os marcos, as atividades, os
atributos das atividades e a documentação de todas as premissas e restrições
identificadas.
o Por último, o PMBOK® (2009:139) depois consultar o especialista, reza que
para manter os documentos em dia é preciso.
o Requisitos dos recursos das atividades. O nivelamento dos recursos pode ter um
efeito significativo nas estimativas preliminares dos tipos e quantidades de
recursos necessários. Se a análise do nivelamento de recursos muda os
requisitos dos recursos do projeto, então os mesmos são atualizados.
o Atributos das atividades. Os atributos das atividades são atualizados para incluir
quaisquer requisitos de recursos revisados ou quaisquer outras revisões
geradas pelo processo Desenvolver o Cronograma.
o Calendário. O calendário para cada projeto pode usar diferentes unidades como
base para Desenvolver o Cronograma do projeto.
 o Registro dos riscos. O registro dos riscos pode precisar ser atualizado para refletir
oportunidades ou ameaças percebidas através das premissas de agendamento.

• Controlar o Cronograma: E o processo de monitoramento do andamento do

projeto para atualização do seu progresso e gerenciamento das mudanças feitas na
linha de base do cronograma. Conforme o PMBOK® (2009: 136), o controle do
cronograma está relacionado a:
o Determinação da situação atual do cronograma do projeto;
o Influência nos fatores que criam mudanças no cronograma;
o Determinação de que o cronograma do projeto mudou;
o Gerenciamento das mudanças reais conforme ocorrem.

Fundamentos de Governança com ITIL

Como estamos constantemente frisando em nossos estudos, a TI tem ganhado peso e

importância nas organizações, seus desafios também aumentaram em proporção semelhante;
abaixo citamos alguns:

• Ajustar os serviços de TI com as necessidades e metas atuais e futuras dos negócios

da empresa.
• Aumento da complexidade no ambiente de TI.
• Os negócios estão cada vez mais dependentes de TI.
• Minimização de riscos e custos.
• Melhores justificativas para o ROI - retorno sobre os investimentos em TI.
• Mais leis e regulamentos com exigência de conformidade imediata.
• Zelo sobre a segurança das Informações.

Os negócios empresariais, buscam melhorias e otimizações com maior frequência e

possuem metas audaciosas para reduzir riscos e custos, por isso foram pensados diversos
frameworks com a intenção de melhorar processos e práticas. Vamos falar especificamente de
ITIL - IT Infrastructure Lybrary, composta pelas melhores práticas para Gerenciamento de
Serviços de TI. Foi introduzida pelo Governo Britânico em 1980 e se tornou padrão no
mercado em 1990. É uma biblioteca composta de 5 livros. Não é uma metodologia, mas sim
um conjunto de melhores práticas adotadas por diversas empresas em várias partes do
mundo.

Estas melhores práticas pretendem:

• Inspirar a melhoria dos processos de TI;

 • Estabelecer metas e nortear o futuro mostrando que outras empresas já lograram
êxito;
• Orientar e sugerir para que servem os processos e práticas;
• Propor e motivas a adoção destes processos e práticas.

Conforme Pinheiro (2006,13), os livros que compõem a biblioteca de melhores práticas

ITIL são:

• Suporte a Serviços: descreve os processos associados ao suporte do dia-a-dia e

atividades de manutenção associadas com a provisão de Serviços de TI.
• Entrega de Serviços: cobre os processos necessários para o planejamento e
entrega de Serviços de TI com qualidade e se preocupa ao longo do tempo com o
aperfeiçoamento desta qualidade.
• ICT - Gerenciamento da Infraestrutura: cobre todos os aspectos do
Gerenciamento da Infraestrutura como a identificação dos requisitos do negócio,
testes, instalação, entrega, e otimização das operações normais dos componentes
que fazem parte dos Serviços de TI.
• Planejamento para Implementação do Gerenciamento de Serviços:
examina questões e tarefas envolvidas no planejamento, implementação e
aperfeiçoamento dos processos do Gerenciamento de Serviços dentro de uma
organização. Também foca em questões relacionadas à Cultura e Mudança
Organizacional.
• Gerenciamento de Aplicações: descreve como gerenciar as aplicações a partir
das necessidades iniciais dos negócios, passando por todos os estágios do ciclo de
vida de uma aplicação, incluindo até a sua saída do ambiente de produção
(quando o sistema é aposentado). Este processo dá ênfase em assegurar que os
projetos de TI e as estratégias estejam corretamente alinhados com o ciclo de vida
da aplicação, assegurando que o negócio consiga obter o retorno do valor
investido.
• Perspectiva de Negócio: fornece um conselho e guia para ajudar o pessoal de
TI a entender como eles podem contribuir para os objetivos do negócio e como
suas funções e serviços podem estar mais bem alinhados e aproveitados para
maximizar sua contribuição para a organização.
• Gerenciamento da Segurança: detalha o processo de planejamento e
gerenciamento da segurança da informação e Serviços de TI, incluindo todos os
aspectos associados com a reação da segurança dos incidentes. Também inclui
uma avaliação e gerenciamento dos riscos e vulnerabilidade, e implementação de
custos justificáveis para a implementação de contra-recursos (estratégia de
segurança).
 Figura 1: ITIL e seus livros
Fonte:Service Suport OGC

Para esta nossa disciplina, vamos estudar apenas os dois primeiros.

Conforme o livro de Services Suport do ITIL, o relacionamento entre os processos está

descrito na imagem abaixo.

Figura 2: relacionamento entre processos do Service Suport – ITIL

Fonte: livro ITIL-SS
Figura 2: conforme figura do livro sobre Entrega de serviços do Service Suport – ITIL e seus
relacionamentos
Fonte: livro ITIL-ES

Possíveis ganhos ou economias com ITIL:

• Redução do custo total em até 48% - Gartner

• 6-8% de redução de custos operacionais. $ 125 milhões de economia (10% do
budget). Procter e Gamble
• Aumento da satisfação do cliente
• Aumento de resolução de incidentes de 5% para 30% com o uso de uma base de
conhecimento - IS Organizations
• Redução de 50% no tempo médio de resolução. Redução de 30% no tempo para
realizar novas mudanças. Redução de 50% dos recursos –
• Utility Provider

Dentre os diversos motivos para de adotar uma estratégia de serviços em ITIL, destaco:

• Incrementar a qualidade no serviço, com um suporte mais confiável em T.I.

• Uma percepção e vivência da segurança e confiança da continuidade nos serviços
de TI.
• Percepção da capacidade atual mais visível e transparente a todos.
• Fornecimento de informações gerenciais para acompanhamento de desempenho,
possibilitando traçar melhorias.
• Equipe de TI mais motivada: conhecendo a carga de trabalho é possível gerenciar
melhor as expectativas.
 • Maior satisfação para os clientes e usuários, entregando o serviço com mais
qualidade e rapidez.
• (Em alguns casos) Redução de custos: a partir do melhor planejamento e controle
dos processos internos é possível otimizar os custos operacionais.
• Maior agilidade e segurança para realizar as mudanças propostas pelo negócio.
Com processos definidos e controlados é mais fácil implementar várias mudanças
simultaneamente.

O conceito de serviço em T.I. deve ser entendido como sendo um conjunto de objetos
relacionados, aprovisionados para suporte a um ou mais processo de negócios.
Diferentemente de processo, em serviços é sempre o usuário que interage.

A definição de processo em ITIL é a reunião de atividades que são interdependentes e

inter-relacionadas com uma meta específica. Como componentes mais notáveis pode-se citar:
entradas de dados, informações, produtos, que transformam os recursos necessários nos
objetivos previstos.

Figura: exemplo de processo

Fonte: Pinheiro (2006, 18)

Visando a melhor prestação de serviços em TI, ITIL separa em dois os atores da

prestação de serviços, a saber:

Cliente: é quem paga pelos serviços. Caso TI seja uma área interna, os clientes podem
ser as unidades de negócios ou departamentos da empresa; caso TI seja um terceiro, prestador
de serviços, os clientes serão, então, as próprias empresas que o terceiro atenderá.

Usuário: é quem utiliza os serviços de TI quotidianamente.

Segundo Pinheiro (2006,25), a implementação de uma central de serviços ITIL tem por
objetivos:

• Funcionar como o ponto central de contato (SPOC – Single Point of Contact) entre
os usuários e departamento de TI. A Central de serviços funciona como o 1º. Nível
de suporte aos usuários.
• Restaurar os serviços sempre que possível. A equipe de suporte deve estar
equipada com ferramentas e informações, tais como Erros Conhecidos, Base de
Conhecimento, para que possa oferecer soluções o mais rápido possível.
• Prover suporte com qualidade para atender os objetivos do negócio. É necessário
que a equipe esteja bem treinada para ter conhecimento de todos os serviços que
serão fornecidos e entender o impacto que eles têm para o negócio.
• Gerenciar todos os incidentes até o seu encerramento. A central de serviço será
responsável pelo processo de Gerenciamento de Incidentes, e será responsável
pelo tratamento de todos os incidentes. É de responsabilidade também da Central
de Serviços monitorar o cumprimento dos acordos estabelecidos nas ANS (SLA-
Acordos de Níveis de Serviços).
• Dar suporte a mudanças, fornecendo comunicação aos usuários sobre o
agendamento de mudanças.
• Aumentar a satisfação do usuário, provendo suporte com maior qualidade, estando
sempre de prontidão para o atendimento, buscando solucionar os incidentes de
forma mais rápida.
• Maximizar a disponibilidade do serviço.

Suas atividades principais dizem respeito a:

• Receber e gravar TODAS as chamadas dos usuários.

• Gravar e acompanhar incidentes e reclamações.
• Prover uma avaliação inicial dos incidentes.
• Monitorar / escalar incidentes por ANS - Acordo de Nível de Serviço (SLA em
inglês).
• Comunicar mudanças planejadas nos níveis de serviço.
• Encerrar os incidentes com confirmação.
• Manter os usuários informados sobre o progresso de suas requisições.
• Produzir relatórios de gerenciamento.
• Coordenar os grupos de suporte de 2º e 3º nível.
• Prover informações gerenciais.
• Identificar necessidades de treinamento dos usuários.
• Contribuir na identificação de problemas.

Para o ITIL, existem 3 tipos de central de serviço, conforme Bom (2007, 38):

• Central de Atendimento (Call Center), atende grandes volumes, utiliza o

telefone.
• Central de Suporte (Help Desk), o foco é não perder nenhuma requisição -
seja abandonada ou não atendida, sua meta é resolver e coordenar incidentes
servindo como interface.
• Central de Serviços (Service Desk), mais abrangente, inclui os processos de
negócio de forma integrada não ficando apenas em incidentes, resolve problemas e
dúvidas.
 Figura: Central de Serviços Local – esquema
Fonte: Pinheiro (2006,24)

Como toda implementação, pode-se criar barreiras ao sucesso da implementação da

central de serviços, dentre elas o Service Delivery (2000, 48) expõem:

• Usuários não ligarem para Central de Serviços, mas tentarem buscar uma solução
diretamente com uma pessoa que conhece, ou que a ajudou da última vez.
• A equipe técnica não estar preparada para atender as necessidades do negócio ou
usuários.
• Nem todas as partes estão informadas sobre os serviços fornecidos e os níveis de
serviços acordados, resultando em frustração por parte dos usuários.

A central de serviços atua sobre duas frentes, a primeira é a gestão de incidentes, a

segunda gestão de problemas. Entende-se que a gestão de incidentes tem como alvo restaurar
os serviços o mais rápido possível com o mínimo de interrupção, minimizando os impactos
negativos nas áreas de negócio.

Para Pinheiro (2006) e o livro ITIL intitulado Service Delivery (2000), o Processo de
Gerenciamento de Incidentes tem como objetivos:

• Resolver os incidentes o mais rápido possível, restabelecendo o serviço normal

dentro do prazo acordado.
• Manter a comunicação dos status dos incidentes aos usuários.
• Escalonar os incidentes para os grupos de atendimento para que seja cumprido o
prazo de resolução.
• Fazer avaliação dos incidentes e as possíveis causas informando ao processo de
Gerenciamento de Problemas.

Quanto ao gerenciamento de problemas, sua principal tarefa é mitigar a interrupção

nos serviços de TI, organizando os recursos disponíveis resolvendo o problema conforme as
necessidades do negócio, tentando evitar a recorrência e agindo no sentido de documentar
para promover a melhoria continua da disponibilidade e produtividade.

De acordo com o Livro ITIL Service Delivery (2000), leva em conta os seguintes
conceitos gerais:

• Problema: é a causa desconhecida de um ou mais incidentes

• Solução de Contorno: solução não definitiva (em inglês Workaround)
• Causa: é um erro em um Item de configuração
• Erro Conhecido (Known Error): É um problema cuja causa foi diagnosticada e
para qual existe uma solução
• Solução: solução definitiva
• Gestão de Incidentes X Problemas: foco na Solução rápida x foco na
introdução de melhorias confiáveis e robustas na infraestrutura
Material Complementar

Caso você queira se aprofundar em ITIL e entender mais detalhadamente as

funções dos livros de serviços e até poder implementar algumas práticas no
lugar que você trabalha, sugiro a leitura desta apostila de fundamentos em
gerenciamento usando ITIL.
Disponível em:
http://pt.scribd.com/doc/88136757/10/Fundamentos-em-Gerenciamento-de-
Servicos-de-TI

Outro material interessante já focado na versão 3 do ITIL é este, disponível

em: http://www.slideshare.net/blogdufraga/apostila-itilv3conceitos

Existe, disponível nesse link

http://www.mp.go.gov.br/portalweb/hp/12/docs/apresentacao_gp.pdf, um
material muito bom sobre um resumo de gestão de projetos para que você
possa conhecer essa área que cresce a cada dia em nosso país e que tem falta
crônica de mão de obra.

Para uma leitura mais aprofundada na aplicação do gerenciamento de

projetos em tecnologia da informação, eu recomendo a leitura do artigo
intitulado “Aplicabilidade dos Escritórios de Projetos de TI nas organizações
públicas e privadas”. Este fala um pouco das dificuldades em se implementar
um escritório de projetos voltado para TI. Disponível em:
http://www.upis.br/posgraduacao/revista_integracao/projetos_ti%20.pdf

Depois de ler o material e informar-se sobre

o assunto, vamos pôr em prática esses
conhecimentos nas atividades!

Bom trabalho!
 Referências

BON, Jan Von. Foundations of IT Service Management, based on ITIL. Lunteren -

Holanda: Van Haren Publishing. 2005.

JUNIOR MARQUES, Artur Ubaldo; MARQUES, Daniela Gonçalves de Moraes.

Gerenciamento do Tempo em Projetos. EAD – Universidade Cruzeiro do Sul, 2011.

PINHEIRO, Flávio R. Fundamentos em gerenciamento de serviços de TI baseados em

ITIL. 2006. Disponível em: http://pt.scribd.com/doc/32939973/ Apostila-ITIL. Acessado em:
22 jul. 2012.

PMI® – Project Management Institute. Guia PMBOK®. Um Guia do Conhecimento em

Gerenciamento de Projetos. 4ªEd.. PMI®. 2008.

RICARDI, André Luis Fonseca. Gerenciamento do Escopo do Projeto. EAD –

Universidade Cruzeiro do Sul. 2011.

SCHMITZ, Leandro Costa. Gerência de Projetos: Histórico, Contextualização, Principais

Conceitos e Relações. UDESC/ESAG. 2005.

THE STATIONARY OFFICE. Service Delivery. Inglaterra: Londres. 2000

Anotações

_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________