INTRODUÇÃO ÀS REDES

DE COMPUTADORES
 Diretor Geral
Diretor Geral:
Nildo Ferreira
Superintendente:

Secretário Geral:
Aleçandro Moreth
Coordenador Acadêmico de Educação a
Distância:

Produção do Material Didático-Pedagógico

Escola Superior Aberta do Brasil

Equipe Multidisciplinar
Coordenador:

Diagramadores:
Felipe Silva Lopes Caliman
Rayron Rickson Cutis Tavares

Copyright © Todos os direitos desta obra são da Escola Superior Aberta do Brasil.
www.esab.edu.br
Sumário
1. Apresentação .................................................................................................................7
2. Conceituação...................................................................................................................8
3. Ciclo de Vida dos Projetos...............................................................................................21
4. Integração dos Projetos..................................................................................................27
5. Gerenciamento do Escopo e Tempo................................................................................40
6. Gerenciamento de Custos e Qualidade...........................................................................51
7. Resumo..........................................................................................................................63
8. Apresentação 1..............................................................................................................65
9. Gerenciamento de Recursos Humanos e Comunicação...................................................66
10. Gerenciamento de Riscos...............................................................................................77
11. Gerenciamento de Aquisições e Partes Interessadas.......................................................89
12. Governança em TI e Gestão de Mudanças.....................................................................100
13. ITIL...............................................................................................................................114
14. Resumo 2.....................................................................................................................127
15. Apresentação 2...........................................................................................................128
16. COBIT...........................................................................................................................129
17. Projetos em TI..............................................................................................................139
18. CMMI...........................................................................................................................150
19. Qualidade em TI...........................................................................................................156
20. Resumo........................................................................................................................172
21. GLOSSÁRIO...................................................................................................................173
22. BIBLIOGRAFIA..............................................................................................................179
PALAVRAS DO TUTOR

Pretendemos com este curso, apresentar ao aluno algumas das

ferramentas que hoje estão sendo empregadas mundialmente
para o Gerenciamento de Projetos.

Trata-se de um curso teórico quanto ao seu conteúdo explícito

que pretende fornecer um espaço para discussões e troca de
experiências entre os alunos e o tutor. Ao iniciar cada unidade, há
indicações para que o aluno execute as atividades complementares,
participe com dúvidas junto ao tutor, fórum ou chat com outros
alunos e enriqueça sua própria experiência de curso efetuando a
análise de CASES, exemplos e laboratórios.

As listas de exercícios estão segmentadas pelos temas de

abrangência: 1) Gerência de Projetos (Introdução e PMI) – 2)
Governança em TI (incluindo ITIL e COBIT) e 3) Gestão de projetos
de sistemas e Qualidade.

Para maior aproveitamento, recomendamos a leitura e utilização

do material de apoio Indicados ao longo do material e do apoio do
tutor.

Bons estudos!

www.esab.edu.br 4
OBJETIVO

Aprofundar os estudos e metodologias, bem como apresentar as

ferramentas utilizadas para o gerenciamento de projetos nas
empresas e organizações.

EMENTA

Gerencia de projeto – função do gerente – competências – ciclo

de projetos – organização de trabalho - PMBOK – metodologias
de gerenciamento de projetos – governança em TI - COBIT -
padrão CMMI – normas de qualidade para desenvolvimento e
comercialização de software.

SOBRE O AUTOR

Ângela dos Santos Oshiro:

Professora nos cursos de Ciência da Computação, Sistemas de
Informação, Redes e Webdesign na Faculdade Sumaré - São
Paulo

Professora do núcleo de tecnologia da Universidade Anhembi/

Interamérica

Coordenadora/Professora do Colégio Politécnico de Sorocaba -

Fundação Ubaldino do Amaral www.fua.org.br

www.esab.edu.br 5
Pesquisadora nas áreas de Telecomunicações e Convergência de
Sistemas Móveis

Pesquisadora/Coordenadora de projetos sobre Interface Homem-

Máquina, Comunicação entre Máquinas e Realidade Virtual www.
vidartec.com

Mestrado em Educação - dissertação em Educação a Distância-

UNISO

Pós-Graduação em Análise de Sistemas - UNIMEP

Bacharel em Administração de Empresas - UNISO

Apostila atualizada por:

Thiago Bronzoni Liberato

Tutor dos cursos Graduação e Pós-Graduação da – ESAB.

Consultor em Business Intelligence (BI), Coordenador e Gerente

de projetos na Accenture do Brasil.

Bacharel em Ciências da Computação e Engenharia de Produção

– FAESA.

MBA em Gerenciamento de Projetos – FGV.

Bacharel em Egenharia de Produção - FAESA

Pós Graduação em Engenharia de Segurança do Trabalho –

FACAM

www.esab.edu.br 6
Conceitos Inicias de Projetos

Esta apostila foi dividida em 3 eixos temáticos. O primeiro eixo,

denominado Conceitos inicias de projetos, refere-se à introdução
dos conceitos básicos de projeto e o papel do gerente de projetos.
Estes conceitos podem ser observados nas duas primeiras
unidades desta apostila.

Na Unidade I é discutida a função do Gerente de Projetos – suas

atribuições, competências e desafios, bem como a postura que
pode adotar diante de seu mundo adverso.

A Unidade II – faz uma introdução sobre o ciclo de projetos que

será detalhado nas unidades posteriores, conforme a abordagem
de cada metodologia estudada.

Ainda neste eixo vamos dar inicio às áreas de conhecimento na

visão PMI, onde as Unidades III - IV - V tratam das áreas de
conhecimento e das problemáticas comuns aos projetos e as
diversas possibilidades de organização do trabalho, tomando
como referência o guia PMBOK. Cada unidade detalha passo-a-
passo as práticas do PMI.

www.esab.edu.br 7
Introdução

Os estudos da administração moderna há muito vêm procurando

aperfeiçoar seus processos, elaborando métodos de diagnóstico,
padronização, motivação, logística, suporte técnico, etc.

O advento da Globalização, a ampliação

dos mercados e a inter-relação que surge por parte de investidores
estrangeiros em cada país, incentiva a busca de uma forma de
comunicação mais integrada e padronizada no intuito de minimizar
conflitos, ampliar as técnicas aplicadas por cada cultura
organizacional e otimizar os processos produtivos.

É neste contexto, que as empresas têm voltado seus esforços

para a implementação de técnicas de Qualidade – 5S, Kaisen,
Kanban, ISO, QS, PDCA, SeisSigma, etc. e buscado um consenso
quanto à metodologia para o desenvolvimento de projetos. É
desta forma que surgem orientações de trabalho, como PMI, ITIL,
COBIT,etc.

www.esab.edu.br 8
Projetos – O que são?

Segundo o PMBOK (2013), Projeto é um esforço temporário

empreendido para criar um produto, serviço ou resultado exclusivo.

Os projetos são realizados em todos os níveis da organização e

podem envolver uma única pessoa ou milhares de pessoas. Sua
duração varia de poucas semanas a vários anos. Trata-se de um
meio de organizar atividades que não podem ser abordadas dentro
dos limites operacionais cotidianos da organização. Portanto, são
frequentemente utilizados como um meio de atingir o plano
estratégico de uma organização, seja a equipe do projeto formada
por funcionários da organização ou um prestador de serviços
contratado.

Os projetos são normalmente autorizados como um resultado de

uma ou mais das seguintes considerações estratégicas:

Uma demanda de mercado (por exemplo,

uma companhia de petróleo autoriza um projeto
para construir uma nova refinaria em resposta a
um problema crônico de falta de gasolina) 1

Uma necessidade organizacional (por

exemplo, uma empresa de treinamento autoriza um
projeto para criar um novo curso para aumentar sua
receita)

www.esab.edu.br 9
 Uma solicitação de um cliente (por exemplo, uma
companhia de energia elétrica autoriza um projeto de construção
de uma nova subestação para atender a um novo parque industrial);

Um avanço tecnológico (por

exemplo, uma empresa de software
autoriza um novo projeto para
desenvolver uma nova geração de
videogames após o lançamento de um novo
equipamento para jogos por empresas de produtos
eletrônicos).

Um requisito legal (por exemplo, um fabricante

de tintas autoriza um projeto para estabelecer
diretrizes para o manuseio de um novo material tóxico) (PMBOK,
2013)

1
Fig1 - Revista Galiza CIG – Outubro 2004 – artigo de Andre Levy
Conforme PMBOK (2013), os projetos podem criar:

• Um produto que pode ser um componente de outro item, um

aprimoramento de outro item, ou um item final;
• Um serviço ou capacidade de realizar um serviço (p.ex.,
uma função de negócios que dá suporte à produção ou
distribuição);
• Uma melhoria nas linhas de produtos e serviços (por
exemplo, um projeto Seis Sigma executado para reduzir
falhas); ou
• Um resultado, como um produto ou documento (por exemplo,

www.esab.edu.br 10
 um projeto de pesquisa que desenvolve o conhecimento
que pode ser usado para determinar se uma tendência existe
ou se um novo processo beneficiará a sociedade).

Muitas são as técnicas e ferramentas adotadas pelas empresas,

quanto ao desenvolvimento de projetos. Indústrias, por exemplo,
geralmente atribuem a gerência de projetos aos “engenheiros”
que ocupam cargos de chefia, como gerentes ou coordenadores,
cuja experiência técnica é ampla, porém não dominam as técnicas
administrativas para coordenação de equipes,
comunicação empresarial, gerenciamento de conflitos,
prazos, habilidades de negociação, etc. Da mesma
forma, é o que ocorre com os especialistas das diversas
áreas: Analistas de Sistemas, Químicos, Físicos, Tecnólogos e
outros.

Bem distante das indústrias e dos ambientes produtivos da

sociedade, até mesmo a educação contribui para a concepção
deste momento, onde escolas, faculdades e instituições de ensino
em geral ampliam e orientam seu trabalho para a confecção de
“projetos” e incentivo à pesquisa.

Visando fornecer um guia de procedimentos e boas práticas para

a solução desses problemas, surgem organizações buscando
estabelecer um consenso para os processos de gerenciamento
de projetos e aprimoramento dos métodos de trabalho empregados
pelos profissionais que assumem a tarefa de Gerenciar Projetos.

3
Guia PMBOK – 2013 – pág. 4
Essa é uma garantia de que além do “produto final”, os processos

www.esab.edu.br 11
de trabalho também são estruturados a partir de critérios que
visam melhoria da qualidade.

Os processos de comunicação entre a equipe de um projeto e

entre a equipe e os demais trabalhadores de uma empresa, os
objetivos da empresa e os objetivos perseguidos pela equipe
desenvolvedora do projeto, devem estar em fina sintonia.

Muitos foram os problemas no passado e, existem muitos

problemas como por exemplo: de clareza nos objetivos de um
projeto, falta de direcionamento para o desenvolvimento do
trabalho, erros ou falta de registro e documentação, etc.

Para entendermos o papel do gerente de projetos, é importante

estar claro a definição do que é gerenciamento de projetos.
Conforme PMBOK (2013) o Gerenciamento de projetos é a
aplicação do conhecimento, habilidades, ferramentas e técnicas
às atividades do projeto para atender aos seus requisitos. O
gerenciamento de projetos é realizado através da aplicação e
integração apropriadas dos processos de gerenciamento de
projetos, logicamente agrupados em cinco grupos de processos

(Iniciação, Planejamento, Execução, Monitoramento e controle e

Encerramento).

www.esab.edu.br 12
É buscando analisar as recomendações e práticas aplicadas pelos
altos profissionais e pesquisadores envolvidos com Gerenciamento
de Projetos, que discutiremos sobre o papel do gerente de projetos,
as fases de gerenciamento a partir do PMI, desenvolvimento de
projetos de sistemas, governança em TI, Itil e Cobit.

O papel do gerente de projetos

Conforme Carvalho Junior (2012), o Gerente de projetos de possuir

conhecimento técnico especifico e depende de muita criatividade
diária, assim como sensibilidade no trato com outras pessoas.

A eficácia de um gerente depende do quanto ele compreende e

domina três dimensões de seu trabalho:

• O quê - as atividades funcionais do trabalho;

• Por que - a finalidade e os objetivos do trabalho;

• Como - os comportamentos necessários para se conseguir

a execução do trabalho.

O gerente de projetos deve ter os papéis de integrador e

empreendedor e ainda, possuir liderança.

O trabalho dos gerentes de projeto difere do executado pelos

gerentes funcionais em função da ABORDAGEM empregada em
relação aos seguintes aspectos:

Orientações para Resultado: Geralmente, o gerente de projeto

está preocupado em conduzir adequadamente seu projeto e não

www.esab.edu.br 13
em dispersar esforços tentando resolver ou redirecionar problemas
existentes dentro das áreas funcionais com as quais interage.

Administração de Pessoal: O gerente de projeto geralmente

emprega um estilo de persuasão e motivação para manter o
contínuo apoio dos envolvidos no projeto.

Gerência de Interfaces: O gerente de projeto enfatiza a integração

das tarefas e atividades do projeto, em seus aspectos
organizacionais e sistêmicos, uma vez que cada área funcional
apresenta seus propósitos e objetivos particulares, ocasionando
desentendimentos e conflitos.

Perspectiva Gerencial: O gerente de projeto apresenta um

enfoque basicamente organizacional e tem uma larga amplitude
de interesses. Enfoque predominantemente gerencial; o gerente
de projeto deve executar todas as funções administrativas
requeridas pelo projeto, coordenando e sincronizando as atividades
do projeto com seus superiores, subordinados, outros gerentes,
usuários, etc. Estilo generalista, com conhecimento técnico em
diversas especialidades e com capacidade de aprofundar
rapidamente seu conhecimento em uma dada área quando
necessário.

www.esab.edu.br 14
Atuação do Gerente de Projetos (GP)

O trabalho do Gerente de Projetos envolve o manuseio da não

rotina, de problemas inesperados que surgem entre as funções
tradicionais que cada um desenvolve,
obrigando-o a resolver conflitos
interdepartamentais. Sua tarefa é limitada no
tempo e normalmente ele não possui feedback
nos primeiros estágios do projeto, devendo
valer-se apenas de sua sensibilidade e experiência. A
responsabilidade fundamental de sua atividade é de entregar seu
produto final de acordo com os resultados desejados, dentro dos
limites de seu orçamento e dentro da programação de tempo
especificada.

A autoridade do Gerente de Projetos deve variar de fraca a forte,

dependendo do progresso de seu projeto e dos objetivos de sua
atuação: deve ser mais fraca no inicio, a fim de não inibir as ideias
na formulação do programa do projeto, e intensificar-se à medida
que o projeto se desenvolve, a fim de assegurar a consecução
dos objetivos.

O Gerente de Projetos não tem autoridade direta em suas relações,

exceto aquelas definidas no plano de trabalho do projeto. Mas sua
autoridade existe, pelo menos informalmente, pois ele a compartilha
com muitos outros. Faz barganhas, constrói alianças, busca
acordos comuns entre os intrincados pontos de vista que ocorrem
dentro do projeto e supervisiona as decisões que serão apoiadas
pelos demais participantes. Uma vez que sua autoridade não
acompanha a escala hierárquica da empresa, mas cruza todas as

www.esab.edu.br 15
funções, ele pode entrar em deliberado conflito com os gerentes
funcionais, pois, enquanto o Gerente de Projetos determina quando e
o que é necessário para a atividade do projeto, os gerentes funcionais,
que fornecem apoio para diferentes projetos, determinam como o
apoio será fornecido.

O poder e o controle exercido pelo mesmo podem estar completamente

divorciados de sua autoridade formal, de onde as alianças políticas
representam importante papel para preencher a lacuna existente em
sua autoridade. Esta, muitas vezes, estará mais afeta à sua habilidade
em formar um ambiente de reciprocidade em seu projeto. Esta espécie
de autoridade não pode ser delegada ao Gerente de Projetos, mas
deve ser conseguida por ele.

O Gerente de Projetos deve

possuir ampla autoridade sobre todos os participantes do projeto.
Sua autoridade deve ser suficiente para permitir que ele acione todas
as atitudes técnicas e administrativas necessárias para que o projeto
termine de forma bem-sucedida. A exata dimensão de sua autoridade
não pode ser quantificada, uma vez que ela varia de projeto para
projeto, de gerente para gerente, e em função do tempo necessário,
do custo envolvido, da complexidade e de inúmeras outras variáveis.

www.esab.edu.br 16
O Gerente de Projetos deve selecionar seu pessoal atentando
para a competência de cada um e sua capacidade de trabalhar
em equipe. Uma vez constituída, a equipe deve, sempre que
possível, zelar por sua continuidade, embora deva estar ciente de
que a realização de um projeto exige uma mistura de
especializações.

O Gerente de Projetos deve despender um considerável esforço

para aprender como comunicar-se adequadamente com seus
técnicos, afim de que estes entendam o porquê das tarefas sob
sua responsabilidade.

O Gerente de Projetos deve estar disposto a atacar problemas de

qualquer nível, embora deva selecionar o que é de sua competência
resolver. Dessa forma, ele deve controlar seus custos, procurando
acompanhar as atividades e o tamanho de sua equipe, formulando
planos simplificados, realizando frequentemente revisões de
custos, programando reuniões e fazendo prontas avaliações das
mudanças técnicas, para determinar se elas são realmente
necessárias ou se constituem meros refinamentos.

Problemas na atuação do gerente de projetos

Devido ao alto grau de dependência da organização quanto ao

sucesso do projeto, o Gerente de Projetos recebe considerável
“visibilidade” da cúpula da empresa e, por esse mesmo motivo,
fica muito exposto através dos relatórios que é obrigado a
apresentar e que monitoram o progresso de seu projeto.

www.esab.edu.br 17
 O Gerente de Projetos precisa estar
capacitado para enfrentar a ambiguidade de lidar com os
contribuintes do projeto e com uma equipe sobre os quais não tem
autoridade formal. E, quanto menor o grau de autoridade formal,
maior a sua necessidade de criar uma base de influência no
ambiente do projeto.

O desafio do Gerente de Projetos

O desafio a ser enfrentado na realização

de um projeto é conseguir atingir o seu
objetivo atendendo aos seus requisitos,
isto é, levando-se em consideração as
complexidades técnicas envolvidas, as
incertezas de execução e as restrições
de custo e prazo.

Para aumentar a chance de que um projeto seja completado com

sucesso a receita indicada é realizar um bom planejamento,
através da criação do plano do projeto, e um controle adequado
durante a sua execução.

A responsabilidade pela criação do plano do projeto e pelo controle

da sua execução é do gerente do projeto. Pela natureza das suas
responsabilidades, é importante que o gerente do projeto seja um

www.esab.edu.br 18
profissional com conhecimento e habilidades suficientes para lidar
com as diversas demandas competitivas relacionadas com o
projeto: escopo, custo, prazo, risco, qualidade, necessidades e
expectativas dos envolvidos.

Formalmente, um projeto é completado com sucesso se os

objetivos são atingidos dentro do prazo, dentro do orçamento e
com a qualidade desejada. Porém, numa definição mais
abrangente e atual, além de atender a esses requisitos, um projeto
é bem-sucedido se atende às necessidades e expectativas dos
stakeholders.

Stakeholders são todas as pessoas e organizações cujos

interesses são afetados do projeto. Os potenciais stakeholders
são: o cliente (quem utilizará os resultados do projeto), o
patrocinador do projeto (sponsor – quem provê os recursos
financeiros para a execução do projeto), o gerente do projeto (o
responsável pela gestão do projeto), a equipe do projeto (as
pessoas que irão executar o projeto), a organização executora do
projeto e a comunidade direta e indiretamente afetada pelos
resultados do projeto. A importância da identificação dos principais
stakeholders se deve ao fato de que o sucesso do projeto depende
da influência desses personagens no projeto.

www.esab.edu.br 19
 ESTUDO COMPLEMENTAR

Para entender melhor os conceitos iniciais sobre

Gerenciamento de Projetos indico a leitura dos
capítulos 1 e 3 do livro de Fábio Câmara Araújo de
Carvalho – Gestão de Projetos, disponível na nossa
Biblioteca Virtual.

www.esab.edu.br 20
O Ciclo de Vida dos Projetos

Muitas vezes ouvimos de um gerente de

projeto: “Este sistema nunca acaba”. Infelizmente, para gerentes
de projeto, esta é uma realidade cruel, porém perfeitamente
compreensível.

Para um GERENTE DE PROJETOS, um novo projeto é como se

fosse um novo romance. Um projeto em sua fase de manutenção
não oferece tantos atrativos ao seu gerenciador como quanto um
novo.

Um projeto é como um ser vivo: tem seu nascimento, crescimento,

maturidade e declínio. Este declínio pode ser representado pelo
desuso das atividades ou produtos que caracterizavam o projeto
ou pelo início de um novo ciclo de enriquecimento, retardando sua
desativação.
Porém, um projeto tem início e término, sempre. O gerente de
projeto deve considerar seu projeto encerrado, a rigor, quando do
término de seu escopo, independentemente das modificações ou
manutenções necessárias e solicitadas. Entretanto, encerrar o
projeto não significa que determinadas responsabilidades
acabaram, algumas provavelmente vão ainda persistir.

www.esab.edu.br 21
Uma fase do projeto em geral é concluída com uma revisão do
trabalho realizado e dos produtos para definir a aceitação, se
ainda é necessário algum trabalho adicional ou se a fase deve ser
considerada encerrada. Uma revisão de gerenciamento muitas
vezes é realizada para se chegar a uma decisão de iniciar as
atividades da próxima fase sem encerrar a fase atual, por exemplo,
quando o gerente de projetos escolhe o paralelismo como ação.

Conforme PMBOK (2013), “o ciclo de vida do projeto é a série de

fases pelas quais um projeto passa, do início ao término”. Por
exemplo, quando uma organização identifica uma oportunidade
que deseja aproveitar, em geral irá autorizar um estudo de
viabilidade para decidir se deve realizar o projeto. A definição do
ciclo de vida do projeto pode ajudar o gerente de projetos a
esclarecer se deve tratar o estudo de viabilidade como a primeira
fase do projeto ou como um projeto autônomo separado. Quando
o resultado desse esforço preliminar não é claramente identificável,
é melhor tratar esses esforços como um projeto separado.

www.esab.edu.br 22
Não existe uma única melhor maneira para definir um ciclo de vida
ideal do projeto. Algumas organizações estabelecem políticas que
padronizam todos os projetos com um único ciclo de vida, enquanto
outras permitem que a equipe de gerenciamento de projetos
escolha o ciclo de vida mais adequado para seu próprio projeto.
Além disso, as práticas comuns do setor frequentemente levarão
ao uso de um ciclo de vida preferencial dentro desse setor.

www.esab.edu.br 23
Os ciclos de vida do projeto geralmente definem:

• Que trabalho técnico deve ser realizado em cada fase (por

exemplo, em qual fase deve ser realizado o trabalho do
arquiteto?)

• Quando as entregas devem ser geradas, em cada fase, e como

cada entrega
revisada, verificada e validada

• Quem está envolvido em cada fase (por exemplo, a engenharia

simultânea exige que os implementadores estejam envolvidos
com os requisitos e o projeto)

• Como controlar e aprovar cada fase.

A maioria dos ciclos de vida do projeto compartilha diversas

características comuns:

As fases geralmente são sequenciais e normalmente são

definidas por algum formulário de transferência de informações
técnicas ou de entrega de componentes técnicos.

Os níveis de custos e de pessoal são baixos no início, atingem

o valor máximo durante as fases intermediárias e caem rapidamente
conforme o projeto é finalizado.

O nível de incertezas é o mais alto e, portanto, o risco de não

atingir os objetivos é o maior no início do projeto. A certeza de término
geralmente se torna cada vez maior conforme o projeto continua.

www.esab.edu.br 24
 A capacidade das partes interessadas de influenciarem as
características finais do produto do projeto e o custo final do projeto
é mais alta no início e torna-se cada vez menor conforme o projeto
continua. Contribui muito para esse fenômeno o fato de que o
custo das mudanças e da correção de erros geralmente aumenta
conforme o projeto continua.

Embora muitos ciclos de vida do projeto possuam nomes de fases

semelhantes com entregas semelhantes, poucos ciclos de vida
são idênticos. Alguns podem ter quatro ou cinco fases, mas outros
podem ter nove ou mais. Áreas de aplicação isoladas
reconhecidamente apresentam variações significativas. O ciclo
de vida de desenvolvimento de um projeto de uma organização
pode ter uma única fase de projeto, enquanto outro pode ter fases
diferentes.

Desta forma, baseando-se no Guia de Gerenciamento de Projetos

PMBOK, descreveremos nos próximos capítulos, as etapas
básicas para a Gestão de Projetos: Gerenciamento de integração,
escopo, tempo, custos, qualidade, recursos humanos,
comunicações, riscos, aquisições e as partes interessadas do
projeto.

www.esab.edu.br 25
Para o aluno se aprofundar no tema Gerenciamento, é essencial
que o aluno adquira o PMBOK e faça a leitura dos capítulos
referentes aos temas tratados nesta apostila. Para se manter
atualizado sobre o assunto, recomendamos frequentar o site do
PMI Brasil (https://brasil.pmi.org/). Caso o aluno deseje tirar a
certificação e se tornar um PMP, recomendamos o livro Preparatório
para o Exame PMP da Rita Mulcahy’s.

ESTUDO COMPLEMENTAR

Para se aprofundar sobre o assunto indico a leitura do

Artigo de João Carlos Boyadjian - Ciclo de vida de
Projetos Industriais.

www.esab.edu.br 26
Integração do projeto

Recomendamos a leitura dos textos e apresentações

complementares indicados ao longo da unidade, a participação no
fórum – postando comentários sobre os Estudos de Caso
apresentados, bem como a contribuição com exemplos práticos
de seu conhecimento. A compreensão desta unidade é fundamental
para prosseguimento dos estudos nas unidades subsequentes.

Gerenciamento de integração do projeto

A integração, no contexto do gerenciamento de um projeto,

consiste em fazer escolhas sobre em quais
pontos concentrar recursos e esforço e em qual
dia específico, antecipando possíveis problemas,
tratando-os antes de se tornarem críticos,
coordenando o trabalho visando o bem geral do
projeto. O esforço de integração também envolve fazer
compensações entre objetivos e alternativas conflitantes.

Conforme Valeriano (2005), o projeto tende a ser um

empreendimento altamente descentralizado. Sendo assim, torna-
se extremamente necessária a área de conhecimento de

www.esab.edu.br 27
Integração, permitindo sua execução de forma uniforme, ajustando
todas as atividades de modo que se observe o plano de projeto.

Os profissionais mais experientes em gerenciamento de projetos

sabem que não existe uma maneira única de gerenciar um projeto.
Eles aplicam o conhecimento, as habilidades e os processos de
gerenciamento de projetos em diferentes ordens e graus de rigor
para obter o desempenho desejado do projeto. No entanto, a
percepção de que um processo específico não é necessário não
significa que ele não deva ser abordado.

A integração trata principalmente da integração efetiva dos

processos entre os grupos de processos de gerenciamento de
projetos necessários para realizar os objetivos do projeto dentro
dos procedimentos definidos da organização.

1. Desenvolver o termo de abertura do projeto – desenvolvimento

do termo de abertura do projeto que autoriza formalmente um
projeto ou uma fase do projeto.

2. Desenvolver o plano de gerenciamento do projeto –

documentação das ações necessárias para definir, preparar,
integrar e coordenar todos os planos auxiliares em um plano de
gerenciamento do projeto.

3. Orientar e gerenciar o trabalho do projeto – Liberação e

realização do trabalho definido no plano de gerenciamento do
projeto e implementação das mudanças aprovadas para atingir os
objetivos do projeto.

www.esab.edu.br 28
4. Monitorar e controlar o trabalho do projeto – monitoramento
e controle dos processos usados para iniciar, planejar, executar e
encerrar um projeto para atender aos objetivos de desempenho
definidos no plano de gerenciamento do projeto.

5. Realizar o Controle integrado de mudanças – revisão de

todas as solicitações de mudança, aprovação de mudanças e
controle de mudanças nas entregas e nos ativos de processos
organizacionais.

6. Encerrar o projeto ou Fase – finalização de todas as atividades

em todos os grupos de processos de gerenciamento de projetos
para encerrar formalmente o projeto ou uma de suas fases.

Desenvolver o termo de abertura do projeto:

A declaração do trabalho (DT) é uma descrição

dos produtos ou serviços que serão fornecidos
pelo projeto. Para projetos internos, o iniciador ou
o patrocinador do projeto fornece a declaração do trabalho com
base nas necessidades de negócios, requisitos do serviço ou
produto. Para projetos externos, a declaração do trabalho pode
ser recebida do cliente como parte de um documento de licitação,
por exemplo, uma solicitação de proposta, uma solicitação de
informações, uma solicitação de preços ou como parte de um
contrato. A DT indica:

Necessidade de negócios – uma necessidade de negócios da

organização pode se basear em: treinamento necessário, demanda
de mercado, avanço tecnológico, requisito legal ou norma
governamental.

www.esab.edu.br 29
Descrição do escopo do produto – documenta os
requisitos do produto e as características do produto ou
serviço para os quais o projeto será realizado. Os
requisitos do produto serão normalmente menos
detalhados durante o processo de iniciação e mais
detalhados durante os processos seguintes, conforme as
características do produto forem progressivamente elaboradas.
Esses requisitos devem também documentar a relação entre os
produtos ou serviços que estão sendo criados e a necessidade de
negócios ou outro estímulo que provoca a necessidade. Embora a
forma e o conteúdo do documento de requisitos do produto variem,
ele deve ser sempre suficientemente detalhado para dar suporte
ao planejamento posterior do projeto.

Plano estratégico – todos os projetos devem dar suporte às

metas estratégicas da organização. O plano estratégico da
organização executora deve ser considerado como um fator
quando forem tomadas decisões de seleção de projetos.

Fatores ambientais da empresa

Durante o desenvolvimento do termo de abertura

do projeto, devem ser considerados todos e
quaisquer sistemas e fatores ambientais da empresa que cercam
e influenciam o sucesso do projeto. Isso inclui, mas não se limita
a itens como: Cultura e estrutura organizacional da empresa,
Normas governamentais ou do setor, Recursos humanos
existentes, Administração de pessoal, Sistema de autorização do

www.esab.edu.br 30
trabalho da empresa, Condições do mercado, Tolerância a risco
das partes interessadas, Bancos de dados comerciais e Sistemas
de informações do gerenciamento de projetos.

Ativos de processos organizacionais

Durante o desenvolvimento do termo de abertura do projeto e da

documentação subsequente do projeto, todos e quaisquer ativos
usados para influenciar o sucesso do projeto podem ser obtidos a
partir dos ativos de processos organizacionais. Todas e quaisquer
organizações envolvidas no projeto podem ter políticas,
procedimentos, planos e diretrizes formais e informais cujos
efeitos devem ser considerados. Os ativos de processos
organizacionais também representam o aprendizado e o
conhecimento das organizações, obtidos de projetos anteriores;

Metodologia

Uma metodologia de gerenciamento de projetos define um

conjunto de grupos de processos de gerenciamento de projetos,
seus processos relacionados e as funções de controle relacionadas
que são consolidados e combinados para formar um todo unificado
funcional. Uma metodologia de gerenciamento de projetos pode
ser, ou não, a elaboração de uma norma de gerenciamento de
projetos.

www.esab.edu.br 31
Desenvolver o Plano de Gerenciamento do Projeto

O processo Desenvolver o Plano de Gerenciamento do Projeto

inclui as ações necessárias para definir, coordenar e integrar todos
os planos auxiliares em um plano de gerenciamento do projeto. O
conteúdo do plano de gerenciamento do projeto irá variar
dependendo da área de aplicação e complexidade do projeto.
Esse processo resulta em um plano de gerenciamento do projeto
que é atualizado e revisado por meio do processo de controle
integrado das mudanças.

O plano de gerenciamento do projeto define:

• Como o projeto é executado, monitorado, controlado e

encerrado;
• Os processos de gerenciamento de projetos selecionados
pela equipe de gerenciamento de projetos;
• O nível de implementação de cada processo selecionado;
• As descrições das ferramentas e técnicas que serão usadas
para realizar esses processos;
• Como os processos selecionados serão usados para
gerenciar o projeto específico, inclusive as dependências e
interações entre esses processos e as entradas e saídas
essenciais.
• Como o trabalho será executado para realizar os objetivos
do projeto. Como as mudanças serão monitoradas e
controladas;
• Como o gerenciamento de configuração será realizado;
• Como a integridade das linhas de base da medição de
desempenho será mantida e utilizada;

www.esab.edu.br 32
 • A necessidade e as técnicas de comunicação entre as partes
interessadas;
• O ciclo de vida do projeto selecionado e, para projetos com
várias fases, as fases associadas do projeto;
• As principais revisões de gerenciamento em relação a
conteúdo, extensão e tempo para facilitar a abordagem de
problemas em aberto e de decisões pendentes.

Orientar e gerenciar a execução do projeto

O processo de orientar e gerenciar a execução do projeto exige

que o gerente de projetos e a equipe do projeto realizem várias
ações para executar o plano de gerenciamento do projeto a fim de
realizar o trabalho definido na declaração do escopo do projeto.

Conforme PMBOK (2013) as atividades de Orientar e Gerenciar a

Execução do Projeto incluem, mas não estão limitadas a:

• Executar as atividades para realizar os objetivos do projeto;

• Criar as entregas do projeto para atender o trabalho planejado
do projeto;
• Fornecer, treinar e gerenciar os membros da equipe alocados
no projeto;
• Obter, gerenciar e usar recursos, inclusive materiais,
ferramentas, equipamentos e instalações;
• Implementar os padrões e os métodos planejados;
• Estabelecer e gerenciar os canais de comunicação do
projeto, tanto externos como internos à equipe do projeto;
• Gerar dados de desempenho do trabalho, tais como custo,

www.esab.edu.br 33
 cronograma, progresso técnico e da qualidade e informações
sobre o andamento do projeto para facilitar previsões;
• Emitir solicitações de mudança e implementar as mudanças
aprovadas no escopo do projeto, nos planos, e no ambiente;
• Gerenciar riscos e implementar atividades de resposta a
riscos;
• Gerenciar vendedores e fornecedores e
• Gerenciar as partes interessadas e seu engajamento; e
• Coletar e documentar lições aprendidas e implementar as
atividades de melhorias nos processos aprovados.

Monitorar e controlar o trabalho do projeto

O processo de monitorar e controlar o trabalho

do projeto é realizado para monitorar os processos do projeto
associados com a iniciação, planejamento, execução e
encerramento. São tomadas ações preventivas ou corretivas para
controlar o desempenho do projeto. O monitoramento é um aspecto
do gerenciamento de projetos que é realizado durante todo o
projeto. Inclui a coleta, medição e disseminação das informações
sobre o desempenho e a avaliação das medições e tendências
para efetuar melhorias no processo. O monitoramento contínuo
permite que a equipe de gerenciamento de projetos tenha uma
visão clara da saúde do projeto e que se identifique as áreas que
exigem atenção especial. O processo de monitorar e idem controlar
o trabalho do projeto está relacionado a:

• Comparação do desempenho real do projeto com o plano de

gerenciamento do projeto;

www.esab.edu.br 34
 • Avaliação do desempenho para determinar se são indicadas
ações preventivas, ou corretivas, e recomendar essas ações
conforme necessário;
• Análise, acompanhamento e monitoramento de riscos do
projeto para garantir que os riscos sejam identificados, que
o andamento seja relatado e que os planos de respostas a
riscos adequados, estejam sendo executados;
• Manutenção de uma base de informações precisas e corretas
relativas ao(s) produto(s) do projeto e a sua documentação
associada até o término do projeto;
• Fornecimento de informações para dar suporte a relatórios
de andamento, medições de progresso e previsões;
• Fornecimento de previsões para atualizar o custo atual e as
informações sobre o cronograma atual;
• Monitoramento da implementação de mudanças aprovadas
quando e conforme ocorrem.

Controle integrado de mudanças

O processo de controle integrado de mudanças é realizado desde

o início do projeto até o seu término. O controle de mudanças é
necessário porque raramente a execução dos projetos segue com
exatidão o plano de gerenciamento do projeto. O plano de
gerenciamento do projeto, a declaração do escopo do projeto e
outras entregas precisam ser mantidos através do gerenciamento
contínuo e cuidadoso das mudanças, rejeitando ou aprovando
essas mudanças, de forma que as mudanças aprovadas sejam
incorporadas a uma linha de base revisada. O processo de controle

www.esab.edu.br 35
Integrado de Mudanças, inclui com base no término da execução
do projeto; as seguintes atividades de gerenciamentos:

• Identificação de que uma mudança precisa ocorrer ou

ocorreu.
• Controle dos fatores que poderiam dificultar o controle
integrado de mudanças de forma que somente mudanças
aprovadas sejam implementadas.
• Revisão e aprovação das mudanças solicitadas.
• Gerenciamento das mudanças aprovadas quando e
conforme ocorrem, regulando o fluxo de mudanças
solicitadas.
• Manutenção da integridade das linhas de base liberando
somente as mudanças aprovadas para serem incorporadas
aos produtos ou serviços do projeto e mantendo sua
configuração e sua documentação de planejamento
relacionada.
• Revisão e aprovação de todas as ações preventivas e
corretivas recomendadas.
• Controle e atualização do escopo, custo, orçamento,
cronograma e requisitos de qualidade, com base nas
mudanças aprovadas, por meio da coordenação das
mudanças em todo o projeto. Por exemplo, uma mudança
proposta do cronograma frequentemente afetará o custo, o
risco, a qualidade e o pessoal.
• Documentação do impacto total nas mudanças solicitadas.
• Validação do reparo de defeito.
• Controle da qualidade do projeto de acordo com as normas,
com base nos relatórios de qualidade.

www.esab.edu.br 36
As mudanças propostas podem exigir estimativas de custos,
sequências de atividades do cronograma, datas do cronograma,
recursos necessários e análise de alternativas de respostas a
riscos, novos ou revisados. Essas mudanças podem exigir ajustes
no plano de gerenciamento do projeto, na declaração do escopo
do projeto ou em outras entregas do projeto. O sistema de
gerenciamento de configuração com controle de mudanças
fornece um processo eficiente, eficaz e padronizado para gerenciar,
centralmente, mudanças dentro de um projeto. O gerenciamento
de configuração com controle de mudanças inclui a identificação,
documentação e controle das mudanças feitas na linha de base.

A aplicação em todo o projeto do sistema de gerenciamento de

configuração, incluindo os processos de controle de mudanças,
realiza três objetivos principais:

• Estabelece um método evolutivo para identificar e solicitar

mudanças nas linhas de base estabelecidas de forma
consistente e para avaliar o valor e a eficácia dessas
mudanças
• Oferece oportunidades para validar e melhorar continuamente
o projeto ao considerar o impacto de cada mudança
• Fornece o mecanismo para a equipe de gerenciamento de
projetos comunicar todas as mudanças de forma consistente
às partes interessadas.
•
Todas as mudanças solicitadas e documentadas precisam ser
aceitas ou rejeitadas por uma autoridade dentro da equipe de
gerenciamento de projetos ou por uma organização externa que
represente o iniciador, patrocinador ou cliente.

www.esab.edu.br 37
Encerrar o projeto ou Fase

O processo de encerrar o projeto envolve a realização da parte de

encerramento do projeto do plano de gerenciamento do projeto.
Em projetos com várias fases, o processo encerrar o projeto
finaliza a parte do escopo do projeto e as atividades associadas,
aplicáveis a uma determinada fase. Este processo inclui a
finalização de todas as atividades terminadas em todos os grupos
de processos de gerenciamento de projetos para encerrar
formalmente o projeto ou uma fase do projeto e transferir o projeto
terminado ou cancelado conforme adequado. O processo encerrar
o projeto também estabelece os procedimentos para coordenar as
atividades necessárias para verificar e documentar as entregas do
projeto, coordenar e interagir para formalizar a aceitação dessas
entregas pelo cliente ou patrocinador e investigar e documentar
as razões para as ações tomadas se um projeto for finalizado
antes do término (abortado).

Dois procedimentos são desenvolvidos para estabelecer as

interações necessárias para realizar as atividades de encerramento
em todo o projeto ou em uma fase do projeto:

Procedimento de encerramento administrativo. Este

procedimento detalha todas as atividades, interações, e funções
e responsabilidades relacionadas dos membros da equipe do
projeto e de outras partes interessadas envolvidas na execução
do procedimento de encerramento administrativo do projeto. A
realização do processo de encerramento administrativo também
inclui as atividades integradas, necessárias para coletar os

www.esab.edu.br 38
 registros do projeto, analisar o sucesso ou fracasso do projeto,
reunir as lições aprendidas e arquivar as informações sobre o
projeto para serem usadas futuramente pela organização.

Procedimento de encerramento de contratos. Inclui todas as

atividades e interações necessárias para resolver e encerrar
qualquer contrato estabelecido para o projeto, além de definir as
atividades relacionadas que dão suporte ao encerramento
administrativo formal do projeto. Este procedimento envolve a
verificação do produto (todo trabalho terminado correta e
satisfatoriamente) e o encerramento administrativo (atualização
dos registros de contratos para refletir os resultados finais e
arquivar essas informações para uso futuro). Os termos e
condições do contrato podem também definir especificações
para o encerramento do contrato que precisam ser parte deste
procedimento. A rescisão de um contrato é um caso especial de
encerramento do contrato que pode envolver, por exemplo, a
incapacidade de entregar um produto, um estouro do orçamento
ou uma falta de recursos necessários. Este procedimento é uma
entrada para o processo: Encerrar um contrato.

ESTUDO COMPLEMENTAR

Indico a leitura do Artigo de Alves, Guimarães e Tannus

(2012) intitulado Análise de Viabilidade de Projeto para
Implantação de uma Academia Esportiva Baseada no
Conjunto de Conhecimentos em Gerenciamento de Projetos
Guia PMBOK neste Artigo você visualizará um exemplo de
Termo de Abertura de Projeto.

www.esab.edu.br 39
Gerenciamento do escopo do projeto
Escopo – o que é?

Conforme Valeriano (2005) , a área

de conhecimento do escopo parte da
definição do produto desejado e da
exata delimitação do projeto.

O gerenciamento do escopo do projeto inclui os processos

necessários para garantir que o projeto inclua todo o trabalho
necessário, e somente ele, para terminar o projeto com sucesso.
O gerenciamento do escopo do projeto trata principalmente da
definição e controle do que está e do que não está incluído no
projeto.

O plano de gerenciamento do escopo do projeto é uma ferramenta

de planejamento que descreve como a equipe irá definir o escopo
do projeto, desenvolver a declaração do escopo detalhada do
projeto, definir e desenvolver a EAP - estrutura analítica do projeto,
verificar o escopo do projeto e controlar o escopo do projeto. O
desenvolvimento do plano de gerenciamento do escopo do projeto
e o detalhamento desse escopo do projeto se iniciam pela análise
das informações contidas no termo de abertura do projeto, pela
declaração do escopo preliminar do projeto, pela última versão

www.esab.edu.br 40
aprovada do plano de gerenciamento do projeto, pelas informações
históricas contidas nos ativos de processos organizacionais e por
quaisquer fatores ambientais relevantes para a empresa.

1. 1. Planejamento do Gerenciamento
do Escopo– criação de um plano de
gerenciamento do escopo do projeto
que documenta como o escopo do
projeto será definido, validado e
controlado e controlado.

2. Coletar Requisito- É o processo que

visa determinar, documentar e gerenciar os
requisitos de todas as partes interessadas
para atingir os objetivos do projeto.

3. Definição do escopo – desenvolvimento de uma declaração

do escopo detalhada do projeto como a base para futuras decisões
do projeto.

4. Criar EAP – subdivisão das principais entregas do projeto e do

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

A EAP é uma decomposição hierárquica orientada à entrega do

trabalho a ser executado pela equipe do projeto, para atingir os
objetivos do projeto e criar as entregas necessárias. A EAP
organiza e define o escopo total do projeto. A EAP subdivide o
trabalho do projeto em partes menores e mais facilmente
gerenciáveis, em que cada nível descendente da EAP representa

www.esab.edu.br 41
uma definição cada vez mais detalhada do trabalho do projeto. É
possível agendar, estimar custos, monitorar e controlar o trabalho
planejado contido nos componentes de nível mais baixo da EAP,
denominados pacotes de trabalho.

A EAP representa o trabalho especificado na declaração do escopo

do projeto atual aprovada. Os componentes que compõem a EAP
auxiliam as partes interessadas a visualizar as entregas do projeto.
Suas principais entradas são: Plano de gerenciamento do Escopo,
Especificação do escopo do projeto, Documentação dos requisitos,
fatores ambientais da empresa e ativos de processos
organizacionais.

5. Validação do escopo – formalização da aceitação das entregas

do projeto terminadas.

A validação do escopo é o processo de obtenção da aceitação

formal pelas partes interessadas do escopo do projeto terminado
e das entregas associadas. A validação do escopo do projeto inclui
a revisão das entregas para garantir que cada uma delas foi
terminada de forma satisfatória. Se o projeto foi finalizado antes
do término (abortado), o processo de validação do escopo do
projeto deve determinar e documentar o nível e a extensão do
término. A verificação do escopo difere do controle da qualidade
porque a verificação do escopo trata principalmente da aceitação
das entregas, enquanto o controle da qualidade trata principalmente
do atendimento aos requisitos de qualidade especificados para as
entregas.

6. Controle do escopo – controle das mudanças no escopo do

projeto.

www.esab.edu.br 42
O controle do escopo do projeto trata de influenciar os fatores que
criam mudanças no escopo do projeto e de controlar o impacto
dessas mudanças. O controle do escopo garante que todas as
mudanças solicitadas e ações corretivas recomendadas sejam
processadas por meio do processo Controle Integrado de
mudanças do projeto. O controle do escopo do projeto também é
usado para gerenciar as mudanças no momento em que
efetivamente ocorrem e é integrado a outros processos de controle.

As mudanças não controladas são frequentemente chamadas de

aumento do escopo do projeto.

Escopo do produto. As características e funções que descrevem

um produto, serviço ou resultado.

Escopo do projeto. O
trabalho que precisa ser
realizado para entregar um
produto, serviço ou resultado,
com as características e
funções especificadas.

www.esab.edu.br 43
Gerenciamento de Tempo do Projeto

Introdução

O gerenciamento de tempo do projeto inclui os processos

necessários para realizar o término do projeto no prazo. Os
processos de gerenciamento de tempo do projeto incluem os
seguintes tópicos:

1-Planejar o Gerenciamento do Cronograma-Estabelecer as

políticas, procedimentos e a documentação para o planejamento,
desenvolvimento, gerenciamento, execução e controle do
cronograma do projeto.

2- Definição da atividade – identificação das atividades

específicas do cronograma que precisam ser realizadas para
produzir as várias entregas do projeto.

3. Sequenciamento de atividades – identificação e documentação

das dependências entre as atividades do cronograma.

4.Estimativa de recursos da atividade – estimativa do tipo e das

quantidades de recursos necessários para realizar cada atividade
do cronograma.

5 Estimativa de duração da atividade – estimativa do número de

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

www.esab.edu.br 44
6 Desenvolvimento do cronograma – análise dos recursos
necessários, restrições do cronograma, durações e sequências
de atividades para criar o cronograma do projeto.

7. Controle do cronograma – controle das mudanças no

cronograma do projeto.

Esses processos interagem entre si e também com processos de

outras áreas de conhecimento. Cada processo pode envolver o
esforço de uma ou mais pessoas ou de grupos de pessoas, com
base nas necessidades do projeto. Cada processo ocorre, pelo
menos uma vez, em todos os projetos e ocorre em uma ou mais
fases do projeto, se o projeto estiver dividido em fases.

Em alguns projetos, especialmente nos de menor escopo, o

sequenciamento de atividades, a estimativa de recursos da
atividade, a estimativa de duração da atividade e o desenvolvimento
do cronograma estão tão estreitamente ligados que são
considerados um único processo, que pode ser realizado por uma
pessoa durante um período de tempo relativamente curto. Esses
processos são apresentados aqui como processos distintos
porque as ferramentas e técnicas para cada um deles são
diferentes.

Planejar o Gerenciamento do Cronograma

Conforme PMBOK (2013), planejar o Gerenciamento do

Cronograma é o processo de estabelecer as políticas, os

www.esab.edu.br 45
procedimentos e a documentação para o planejamento,
desenvolvimento, gerenciamento, execução e controle do
cronograma do projeto. Este processo tem como principal benefício
o fornecimento de orientação e instrução sobre o gerenciamento
do cronograma ao longo de todo o projeto.

Definição da atividade

A definição das atividades do cronograma envolve identificar e

documentar o trabalho planejado para ser realizado. O processo
Definição da atividade identificará as entregas no nível mais baixo
da estrutura analítica do projeto (EAP), a que chamamos de pacote
de trabalho. Os pacotes de trabalho do projeto são planejados
(decompostos) em componentes menores, chamados de
atividades do cronograma, para fornecer uma base para a
estimativa, elaboração de cronogramas, execução, e
monitoramento e controle do trabalho do projeto.

www.esab.edu.br 46
Sequenciamento de atividades

O sequenciamento de atividades
envolve a identificação e
documentação dos
relacionamentos lógicos entre as
atividades do cronograma. As atividades do cronograma podem
ser sequenciadas logicamente usando as relações de precedência
adequadas, além de antecipações e atrasos, para dar suporte ao
desenvolvimento posterior de um cronograma do projeto realista
e alcançável. O sequenciamento pode ser realizado usando um
software de gerenciamento de projetos ou técnicas manuais.

Estimativa de Recursos das atividades

É o processo que estima a quantidade e tipos de pessoas,

equipamentos ou suprimentos necessários para desenvolver cada
atividade.

Estimativa de duração da atividade

O processo de estimativa de durações

das atividades do cronograma usa as
informações sobre: escopo de trabalho da
atividade do cronograma, tipos de recursos
necessários, estimativas das quantidades de recursos e

www.esab.edu.br 47
calendários de recursos com as disponibilidades de recursos. As
entradas das estimativas de duração da atividade do cronograma
se originam da pessoa ou do grupo da equipe do projeto que está
mais familiarizado com a natureza do conteúdo do trabalho na
atividade do cronograma específica. A estimativa de duração é
progressivamente elaborada e o processo considera a qualidade
e disponibilidade dos dados de entrada. Por exemplo, conforme a
engenharia do projeto e o trabalho de design se desenvolvem,
dados mais precisos e detalhados ficam disponíveis e a exatidão
das estimativas de duração aumenta. Dessa forma, a estimativa
de duração pode se tornar cada vez mais exata e de melhor
qualidade.

Este processo exige estimativa quanto a quantidade de: esforço

de trabalho, que a quantidade de esforço de trabalho necessária
para terminar a atividade do cronograma seja estimada, que a
quantidade prevista de recursos a ser aplicada para terminar a
atividade do cronograma e ainda, que o número de períodos de
trabalho necessário para terminar a atividade do cronograma seja
determinado. Todos os dados e premissas que dão suporte à
estimativa de duração são documentados para cada estimativa de
duração da atividade.

A estimativa do número de períodos de trabalho necessário para

terminar a atividade do cronograma pode exigir que se considere
o tempo decorrido como um requisito relacionado ao tipo específico

www.esab.edu.br 48
de trabalho. A maioria dos softwares de gerenciamento de projetos
para elaboração de cronogramas lidará com essa questão usando
um calendário de projeto e calendários de recursos de período de
trabalho alternativos que geralmente são identificados pelos
recursos que exigem períodos de trabalho específicos. As
atividades do cronograma serão trabalhadas de acordo com o
calendário de projeto e as atividades do cronograma para as quais
os recursos estão atribuídos também serão trabalhadas de acordo
com os calendários de recursos adequados.

Desenvolvimento do cronograma

O desenvolvimento do cronograma do projeto, um processo

iterativo, determina as datas de início e término planejadas das
atividades do projeto. O desenvolvimento do cronograma pode
exigir que as estimativas de duração e as estimativas de recursos
sejam reexaminadas e revisadas para criar um cronograma do
projeto aprovado, que possa servir como uma linha de base em
relação a qual o progresso pode ser acompanhado. O
desenvolvimento do cronograma continua durante todo o projeto
conforme o trabalho se desenvolve, o plano de gerenciamento do
projeto se modifica e os eventos de risco esperados ocorrem ou
desaparecem à medida que novos riscos são identificados.

www.esab.edu.br 49
 ESTUDO COMPLEMENTAR

Recomendo a leitura do Artigo de Aline Alves de Medeiros

(2012), intitulado- O Processo de Definição de Escopo do
Projeto Segundo o PMBOK para se aprofundar no assunto
desta unidade.

www.esab.edu.br 50
Gerenciamento de Custos do Projeto

Introdução

O gerenciamento de custos do projeto inclui os

processos envolvidos em planejamento, estimativa,
orçamentação, financiamento e controle de custos,
de modo que seja possível terminar o projeto dentro do orçamento
aprovado.

1. Planejar o gerenciamento de Custos – estabelece

procedimentos, politicas, e documentação para o planejamento,
despesas, gestão e controles de custo.

2. Estimativa de custos – desenvolvimento de uma estimativa

dos custos dos recursos necessários para terminar as atividades
do projeto.

3. Orçamentação – agregação dos custos estimados de atividades

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

4. Controle de custos – controle dos fatores que criam as

variações de custos e controle das mudanças no orçamento do
projeto.

www.esab.edu.br 51
Em muitas áreas de aplicação, a previsão e a análise do
desempenho financeiro esperado do produto do projeto são
realizadas fora do projeto. Em outras, como em um projeto de
infraestrutura urbana, o gerenciamento de custos do projeto pode
incluir esse trabalho. Quando essas previsões e análises são
incluídas, o gerenciamento de custos o projeto irá abordar
processos adicionais e diversas técnicas de gerenciamento geral,
como retorno sobre o investimento, fluxo de caixa descontado e
análise de retorno de capital investido.

O gerenciamento de custos do projeto considera as necessidades

de informação das partes interessadas no projeto. Diferentes partes
interessadas irão medir os custos do projeto de diferentes maneiras
e em momentos diferentes. Por exemplo, o custo de um item
adquirido pode ser medido quando a decisão de aquisição é tomada
ou lançada, o pedido é colocado, o item é enviado e o custo real é
incorrido ou registrado para fins de contabilidade do projeto.
A Gestão de Custos é essencialmente interativa, pois todas as
atividades incorrem em custos e é uma das mais importantes para
todas as partes interessadas: quanto mais elevados e desregulados
estiverem os custos, mais preocupante se tornará o projeto
(VALERIANO, 2005).

www.esab.edu.br 52
Planejar o Gerenciamento de Custos

O Processo de planejamento do gerenciamento de custos

estabelece os procedimentos,
políticas e as documentações
necessárias para o
planeamento, gerenciamento,
despesas, e controle dos custos
do projeto. Este processo,
tempo como principal benefício o fornecimento de orientação e
instruções sobre como os custos do projeto serão gerenciados ao
longo de todo o projeto.

Este processo considera os seguintes itens:

• O Plano de gerenciamento de projeto (linha de base do
escopo, linha de base do cronograma e outras informações);
• Termo de abertura do projeto;
• Fatores ambientais da empresa;
• Ativos de processos organizacionais.

www.esab.edu.br 53
Estimativa de custos
A estimativa
de custos da
atividade do
cronograma
envolve o
desenvolvimento de uma aproximação dos custos dos recursos
necessários para terminar cada atividade do cronograma. Na
aproximação dos custos, o avaliador considera as possíveis
causas de variação das estimativas de custos, inclusive os
riscos.

A estimativa de custos inclui a identificação e a consideração de

diversas alternativas de custos. Por exemplo, na maior parte das
áreas de aplicação, aceita-se amplamente o fato de que o trabalho
adicional durante uma fase de projeto tem o potencial de reduzir
o custo da fase de execução e das operações de produtos. O
processo de Estimativa de Custos considera se a economia
esperada pode compensar o custo do trabalho de design adicional.

Em geral, as estimativas de custos são expressas em unidades de

moeda (dólares, euro, iene, etc.) para facilitar as comparações
dentro de projetos e entre eles.

Em alguns casos, o avaliador pode utilizar unidades de medida

para estimar os custos, como equipe-horas ou equipe-dias,
juntamente com suas estimativas de custos, para facilitar o controle
gerencial adequado.

www.esab.edu.br 54
O processo de estimativa de custos considera:

Condições do mercado. Quais produtos, serviços e resultados

estão disponíveis no mercado, de quem, e sob que termos e
condições.

Bancos de dados comerciais. Informações sobre valores de

custo de recursos frequentemente estão disponíveis a partir de
bancos de dados comerciais que acompanham custos de recursos
humanos e habilidades e fornecem custos padrão para materiais
e equipamentos. Outra fonte são as listas de preços de fornecedores
publicadas.

Ativos de processos organizacionais

As políticas, os procedimentos e as diretrizes relacionados às

estimativas de custos formais e informais existentes são
considerados no desenvolvimento do plano de gerenciamento de
custos, na seleção das ferramentas de estimativa de custos e nos
métodos de monitoramento e distribuição de informações a serem
usados.
Políticas de estimativa de custos. Algumas organizações
predefiniram abordagens para a estimativa de custos. Quando
elas existirem, o projeto irá operar dentro dos limites definidos por
essas políticas.

Modelos de estimativa de custos. Algumas organizações

desenvolveram modelos (um padrão genérico) para serem usados
pela equipe do projeto. A organização pode aprimorar o modelo

www.esab.edu.br 55
continuamente com base em sua aplicação e utilidade em projetos
anteriores.

Informações históricas. Informações que pertencem ao produto

ou serviço do projeto e são obtidas de várias fontes dentro da
organização podem influenciar o custo do projeto.

Arquivos do projeto. Uma ou mais organizações envolvidas no

projeto irão manter registros de desempenho de projetos anteriores
suficientemente detalhados para auxiliar no desenvolvimento das
estimativas de custos. Em algumas áreas de aplicação, membros
individuais da equipe podem manter esses registros.

Conhecimento da equipe do projeto. É possível que membros

da equipe do projeto se lembrem de custos reais ou estimativas
de custos anteriores. Embora essas recordações possam ser
úteis, em geral elas são muito menos confiáveis que o desempenho
documentado.

Lições aprendidas. Lições aprendidas poderiam incluir estimativas

de custos obtidas de projetos anteriores que são semelhantes em
escopo e tamanho.

Determinar Orçamento

Para estabelecer uma linha de base dos custos autorizada, este

processo agrega os custos estimados de atividades individuais ou
pacotes de trabalho. Este processo tem como principal benefício,
a determinação da linha de base dos custos para monitoramento
e controle do desempenho do projeto.
Este processo considera a linha de base o plano de gerenciamento
de custos, a linha de base do escopo (especificação do escopo do

www.esab.edu.br 56
projeto, EAP e seu dicionário), estimativa de custos das atividades,
base das estimativas, cronograma do projeto, calendário dos
recursos, registro de riscos, acordos e ativos de processos
organizacionais.

Controle de custos

O controle de custos do projeto inclui:

• Controlar os fatores que criam mudanças na linha de base dos

custos;
• Garantir que houve um acordo em relação às mudanças
solicitadas;
• Monitorar as mudanças reais quando e conforme ocorrem;
• Garantir que os possíveis estouros nos custos não ultrapassam
o financiamento autorizado periodicamente e no total para o
projeto;
• Monitorar o desempenho de custos para detectar e compreender
as variações em relação à linha de base dos custos;
• Registrar exatamente todas as mudanças adequadas em
relação à linha de base dos custos;
• Evitar que mudanças incorretas, inadequadas ou não aprovadas
sejam incluídas nos custos relatados ou na utilização de
recursos;
• Informar as partes interessadas sobre as mudanças aprovadas;
• Agir para manter os estouros nos custos esperados dentro dos
limites aceitáveis.

www.esab.edu.br 57
Gerenciamento da qualidade do projeto

Qualidade – abrangência

Os processos de gerenciamento da
qualidade do projeto incluem todas as atividades da organização
executora que determinam as responsabilidades, os objetivos e
as políticas de qualidade, de modo que o projeto atenda às
necessidades que motivaram sua realização.

Eles implementam o sistema de gerenciamento da qualidade

através da política, dos procedimentos e dos processos de
planejamento da qualidade, garantia da qualidade e controle da
qualidade, com atividades de melhoria contínua dos processos
conduzidos do início ao fim, conforme adequado.

O gerenciamento da qualidade do projeto deve abordar o

gerenciamento do projeto e do produto do projeto. Enquanto o
gerenciamento da qualidade do projeto se aplica a todos os
projetos, independentemente da natureza de seu produto, as
medidas e técnicas de qualidade do produto são específicas do
tipo particular de produto produzido pelo projeto.

Exemplo:

• Atender às necessidades do cliente sobrecarregando a

equipe do projeto pode trazer consequências negativas na
forma de esgotamento dos funcionários, erros sem motivo
aparente ou retrabalho.

www.esab.edu.br 58
 • Atender aos objetivos de cronograma do projeto apressando
as inspeções de qualidade planejadas pode trazer
consequências negativas quando os erros não são
detectados.

O moderno gerenciamento da qualidade complementa o

gerenciamento de projetos. Por exemplo, ambas as disciplinas
reconhecem a importância de:

Satisfação do cliente. Entendimento, avaliação, definição

e gerenciamento de expectativas de forma a atender às
necessidades do cliente. Isso exige uma combinação de
conformidade com os requisitos (o projeto deve produzir o que
afirmou que produziria) e adaptação ao uso (o produto ou serviço
deve satisfazer as necessidades reais).

Prevenção sobre inspeção. O custo de prevenção de erros

em geral é muito menor que o custo de corrigi-los, conforme
revelado pela inspeção.

Responsabilidade da gerência. O sucesso exige a

participação de todos os membros da equipe, mas é sempre
responsabilidade da gerência fornecer os recursos necessários
para que exista sucesso.

Melhoria contínua. O ciclo PDCA é a base da melhoria da

qualidade (conforme definido por Shewhart e modificado por
Deming, no ASQ Handbook, pág 13 e 14, American Society for
Quality, 1999). Além disso, as iniciativas de melhoria da qualidade
realizadas pela organização executora, como GQT e Seis Sigma,
podem melhorar a qualidade do gerenciamento do projeto e

www.esab.edu.br 59
também a qualidade do produto do projeto. Os modelos de
melhoria de processos incluem Malcolm Baldrige, CMM® e
CMMISM.

O custo da qualidade se refere ao custo total de todos os esforços

relacionados à qualidade. As decisões do projeto podem afetar os
custos operacionais da qualidade como resultado de devoluções
de produtos, reclamações em garantia e campanhas de recall.

Planejar o Gerenciamento da qualidade

O planejamento da qualidade envolve a identificação dos padrões

de qualidade relevantes para o projeto e a determinação de como
satisfazê-los. Ele é um dos principais processos durante a
execução do grupo de processos de planejamento e o
desenvolvimento do plano de gerenciamento do projeto e deve
ser realizado em paralelo com outros processos de planejamento
do projeto.

Realizar a garantia da Qualidade

Para garantir o uso de padrões de qualidade e definições

operacionais apropriados, o processo realizar a garantia da
qualidade realiza auditoria dos requisitos da qualidade e dos
resultados das medições de controle e qualidade. Este processo
tem como principal benefício a facilitação do aprimoramento dos
processos da qualidade.

www.esab.edu.br 60
Realizar o controle da qualidade

A realização do controle da qualidade (CQ) envolve o monitoramento

de resultados específicos do projeto a fim de determinar se eles
estão de acordo com os padrões relevantes de qualidade e a
identificação de maneiras de eliminar as causas de resultados
insatisfatórios. Ele deve ser realizado durante todo o projeto. Os
padrões de qualidade incluem metas de produtos e processos do
projeto. Os resultados do projeto incluem entregas e resultados de
gerenciamento de projetos, como desempenho de custos e de
prazos. O CQ muitas vezes é realizado por um departamento de
controle da qualidade ou uma unidade organizacional com nome
semelhante. O CQ pode incluir tomar ações para eliminar as
causas de um desempenho insatisfatório do projeto.

A equipe de gerenciamento de projetos deve ter um conhecimento

prático de controle estatístico da qualidade, especialmente de
amostragem e probabilidade, para ajudar a avaliar as saídas do
CQ.

Prevenção (manter os erros fora do processo) e inspeção (manter

os erros afastados das mãos do cliente).

Amostragem de atributos (o resultado está de acordo ou não) e

amostragem de variáveis (o resultado é classificado em uma
escala contínua que mede o grau de conformidade).

Causas especiais (eventos incomuns) e causas comuns (variação

normal do processo). As causas comuns também são chamadas
de causas aleatórias. Tolerâncias (o resultado será aceitável se
ficar dentro do intervalo especificado pela tolerância) e limites de

www.esab.edu.br 61
controle (o processo estará sob controle se o resultado ficar dentro
dos limites de controle).

ESTUDO COMPLEMENTAR
Para se aprofundar nos conceitos apresentados nesta Unidade,

sugiro a leitura dos capítulos do Guia PMBoK sobre Qualidade e

Custos.

Recomento a leitura do Artigo de Shobhit Shrotriya (2009) - O impacto

da Qualidade no Gerenciamento de Projeto para se aprofundar no

assunto desta unidade.

Após a leitura, recomendamos a participação no fórum, bem como

pesquisas independentes, objetivando ampliar a visão do estudante
sobre o tema: sistemas de qualidade e qualidade no desenvolvimento
de projetos. Lembramos ainda, que até a unidade XVIII estaremos
abordando as recomendações descritas no Guia PMBoK

www.esab.edu.br 62
Na Unidade 1 estudamos sobre o que são “Projetos” dentro de
uma organização, sua abrangência no trabalho de um profissional
de Gerenciamento de Projetos e ainda vimos sobre os desafios e
responsabilidades desses profissionais.

Já na Unidade 2 vislumbramos resumidamente as etapas

necessárias para a confecção de um projeto e os fatores que
geram a necessidade de um novo projeto. Também estudamos as
etapas necessárias para o desenvolvimento de um projeto, como
é seu encerramento e sua posterior manutenção.

Na Unidade 3 estudamos a primeira etapa necessária para a

confecção de um projeto. É esta fase que dá início ao projeto
propriamente dito, ou seja, a fase onde se documenta, atribui
tarefas, apresenta o problema, as metas e os processos envolvidos.

A Unidade 4 apresentou a segunda e a terceira etapas da confecção

de um projeto. A segunda etapa determina o escopo do projeto, ou
seja, a área de conhecimento conhecida como GERENCIAMENTO
DO ESCOPO, que garante que o projeto realize todo e somente o
trabalho necessário para o seu sucesso. A terceira etapa é uma
das mais críticas no gerenciamento de projetos denominada
GERENCIAMENTO DO TEMPO. Área importante, pois, qualquer
contratempo pode modificar o fator tempo, chegando muitas vezes

www.esab.edu.br 63
a inutilizar todo o controle desenvolvido até então. É um dos pontos
mais críticos para os Gerentes de Projeto.

Já na Unidade 5 vimos os processos de gerenciamento de custos

e qualidade do projeto, outras áreas do conhecimento que um
projeto exige O processo de custo está intimamente ligado à
estimativa de tempo (prazo) pois um aspecto influencia o outro
diretamente. O processo de qualidade discute sobre os fatores
que favorecem ou minimizam a garantia da qualidade do projeto
– procedimentos, políticas, gerenciamento, etc. É aspecto de
extrema importância para garantir o sucesso do empreendimento.

www.esab.edu.br 64
Continuando sobre a visão PMI - as Unidades VI – VII e VIII –
tratam das áreas de conhecimento e das problemáticas comuns
aos projetos e as diversas possibilidades de organização do
trabalho, tomando como referência o guia PMBOK. Cada unidade
detalha passo-a-passo as práticas do PMI.

Aqui também vamos iniciar o estudo sobre Projetos e Governança

de TI - a partir da unidade IX – procura-se enfocar metodologias
de gerenciamento de projetos visando à implementação de
projetos ligados à área de TI. A unidade IX trata sobre a Governança
em TI – uma preocupação crescente frente às áreas de
gerenciamento de projetos e gerenciamento de TI.

A unidade X - fornece uma visão geral sobre ITIL – cujas práticas

tornam-se uma ferramenta indispensável na área de serviços e TI.

www.esab.edu.br 65
Gerenciamento de Recursos Humanos do Projeto

Recursos Humanos

O gerenciamento de recursos humanos do projeto inclui os

processos que organizam e gerenciam a equipe do projeto. A
equipe do projeto é composta de pessoas com funções e
responsabilidades atribuídas para o término do projeto. Embora
seja comum falar-se em funções e responsabilidades atribuídas,
os membros da equipe devem estar envolvidos em grande parte
do planejamento e da tomada de decisões do projeto. O
envolvimento dos membros da equipe desde o início acrescenta
especialização durante o processo de planejamento e fortalece o
compromisso com o projeto. O tipo e o número de membros da
equipe do projeto muitas vezes podem mudar conforme o
desenvolvimento do projeto. Os membros da equipe do projeto
podem ser chamados de pessoal do projeto.

A equipe de gerenciamento de projetos é um subconjunto da

equipe do projeto responsável pelas atividades de gerenciamento
de projetos, como planejamento, controle e encerramento. Esse
grupo de pessoas pode ser chamado de equipe principal, executiva
ou de líderes. Em projetos menores, as responsabilidades de
gerenciamento de projetos podem ser compartilhadas por toda a
equipe ou administradas unicamente pelo gerente de projetos. O

www.esab.edu.br 66
patrocinador do projeto trabalha junto com a equipe de
gerenciamento de projetos, normalmente auxiliando com questões
como recursos financeiros do projeto, esclarecendo dúvidas sobre
o escopo e exercendo influência sobre outras pessoas para
beneficiar o projeto.

Processos de gerenciamento de recursos humanos do projeto

incluem:

1. Desenvolver o plano dos recursos humanos – Identificação

e documentação de funções, responsabilidades e relações
hierárquicas do projeto, além da criação do plano de gerenciamento
de pessoal.

2. Mobilizar a equipe do projeto – Obtenção dos recursos

humanos necessários para terminar o projeto.

3. Desenvolver a equipe do projeto – Melhoria de competências

e interação de membros da equipe para aprimorar o desempenho
do projeto.

4. Gerenciar a equipe do projeto – Acompanhamento do

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

Esses processos interagem entre si e também com processos nas

outras áreas de conhecimento. Cada processo pode envolver
esforço de uma ou mais pessoas ou grupos de pessoas,
dependendo das necessidades do projeto. Cada processo ocorre
pelo menos uma vez em todos os projetos e também em uma ou
mais fases do projeto, se ele estiver dividido em fases.

www.esab.edu.br 67
Planejamento de recursos humanos

O planejamento de recursos humanos determina funções,

responsabilidades e relações hierárquicas do projeto e cria o plano
de gerenciamento de pessoal. As funções do projeto podem ser
designadas para pessoas ou grupos. Essas pessoas ou grupos
podem ser internos ou externos à organização que executa o
projeto. O plano de gerenciamento de pessoal pode incluir
informações de como e quando os membros da equipe do projeto
serão contratados ou mobilizados, os critérios para sua liberação
do projeto, a identificação das necessidades de treinamento, os
planos de reconhecimento e premiação, as considerações sobre
conformidade, os problemas de segurança e o impacto do plano
de gerenciamento de pessoal na organização.

Mobilizar a equipe do projeto

Mobilizar a equipe do projeto envolve o acompanhamento do

desempenho de membros da equipe, o fornecimento de feedback,
a resolução de problemas e a coordenação de mudanças para
melhorar o desempenho do projeto. A equipe de gerenciamento
de projetos observa o comportamento da equipe, gerencia
conflitos, resolve problemas e avalia o desempenho de membros
da equipe. Como resultado do gerenciamento da equipe do projeto,
o plano de gerenciamento de pessoal é atualizado, as solicitações
de mudança são apresentadas, os problemas são resolvidos, são
fornecidas entradas para as avaliações de desempenho

www.esab.edu.br 68
organizacional e as lições aprendidas são adicionadas ao banco
de dados da organização.

Técnicas para gerenciamento da equipe:

Observação e conversas

As observações e as conversas são usadas para manter o contato

com o trabalho e as atitudes dos membros da equipe do projeto. A
equipe de gerenciamento de projetos monitora indicadores como
progresso em relação às entregas do projeto, realizações que são
fonte de orgulho para membros da equipe e problemas
interpessoais.

Avaliações de desempenho do projeto

A necessidade de avaliações formais ou informais de desempenho

do projeto depende da extensão do projeto, da complexidade do
projeto, da política organizacional, dos requisitos do contrato de
mão-de-obra e da quantidade e da qualidade da comunicação
regular. Os membros da equipe do projeto recebem feedback das
pessoas que supervisionam seu trabalho do projeto. As informações
de avaliação também podem ser coletadas de pessoas que

www.esab.edu.br 69
interagem com os membros da equipe do projeto usando os
princípios de feedback de 360º. O termo “360º” significa que o
feedback relativo ao desempenho é fornecido para a pessoa que
está sendo avaliada a partir de várias fontes, inclusive superiores,
pares e subordinados.

Os objetivos para a realização de avaliações de desempenho

durante o andamento de um projeto podem incluir um novo
esclarecimento de funções e responsabilidades, um tempo
estruturado para garantir que os membros da equipe recebam o
feedback positivo que não teriam condições de receber em um
ambiente de muita agitação, a descoberta de problemas
desconhecidos ou não resolvidos, o desenvolvimento de planos
de treinamento individuais e o estabelecimento de metas
específicas para futuros períodos de tempo.

Gerenciamento de conflitos

Um gerenciamento de conflitos bem-sucedido resulta em maior

produtividade e relações de trabalho positivas. Fontes de conflito
incluem recursos escassos, prioridades na elaboração de
cronogramas e estilos pessoais de trabalho. Regras básicas da
equipe, normas de grupo e práticas sólidas de gerenciamento de
projetos, como planejamento das comunicações e definição de
funções, reduzem a quantidade de conflitos. Quando gerenciadas
adequadamente, as diferenças de opinião são saudáveis e podem
aumentar a criatividade e melhorar a tomada de decisões. Quando
as diferenças se tornam um fator negativo, os membros da equipe
do projeto são inicialmente responsáveis pela resolução de seus
próprios conflitos. Se o conflito aumentar, o gerente de projetos

www.esab.edu.br 70
deverá ajudar a facilitar uma resolução satisfatória. O conflito
deverá ser tratado no início e geralmente em particular, usando
uma abordagem direta e colaborativa. Se o conflito prejudicial
continuar, será necessário usar procedimentos cada vez mais
formais, inclusive a possível utilização de ações disciplinares.

Registro de problemas
Conforme surgem problemas durante o gerenciamento da equipe
do projeto, um registro por escrito pode documentar pessoas
responsáveis pela resolução de problemas específicos até uma
data alvo. O registro ajuda a equipe do projeto a monitorar
problemas até o encerramento. A resolução de problemas aborda
obstáculos que podem impedir que a equipe atinja suas metas.
Esses obstáculos podem incluir fatores como diferenças de
opinião, situações a serem investigadas e responsabilidades
novas ou inesperadas que precisam ser atribuídas a alguém da
equipe do projeto.

Gerenciamento das Comunicações do Projeto

Comunicação é o centro. Esta unidade tem como objetivo
proporcionar ao estudante uma visão mais ampla sobre a
importância do Gerenciamento das comunicações do projeto.
O gerenciamento das comunicações do projeto é a área de
conhecimento que emprega os processos
necessários assegurar que as informações
do projeto sejam planejadas, coletadas,
criadas, distribuídas, armazenadas,
recuperadas, gerenciadas, controladas,
monitoradas e finalmente dispostas de
maneira oportuna e apropriada.

www.esab.edu.br 71
Os processos de gerenciamento das comunicações do projeto
fornecem as ligações críticas entre pessoas e informações que
são necessárias para comunicações bem-sucedidas. Os gerentes
de projetos podem gastar um tempo excessivo na comunicação
com a equipe do projeto, partes interessadas, cliente e patrocinador.
Todos os envolvidos no projeto devem entender como as
comunicações afetam o projeto como um todo.

Os processos de gerenciamento das comunicações do projeto

incluem:
1. Planejar o Gerenciamento das comunicações - com
base nas necessidades de informação e requisitos das
partes interessadas e nos ativos organizacionais
disponíveis, este processo desenvolve uma abordagem
apropriada e um plano de comunicações do projeto.

2. Gerenciar as Comunicações - De acordo com o plano de

gerenciamento de comunicações, este processo cria,
coleta, distribui, armazena, recupera e disponibiliza as
informações.

3. Controlar as Comunicações - Este processo monitora e

controla as comunicações ao longo do ciclo de vida do
projeto.
O plano de gerenciamento das comunicações pode também incluir
diretrizes para reuniões de andamento do projeto, reuniões da
equipe do projeto, reuniões eletrônicas e emails. O plano de
gerenciamento das comunicações pode ser formal ou informal,
bem detalhado ou genérico, e pode se basear nas necessidades
do projeto.

www.esab.edu.br 72
 • Item de comunicações. As informações que serão
distribuídas às partes interessadas.

• Objetivo. A razão da distribuição dessas informações.

• Frequência. Afrequência de distribuição dessas informações.

• Datas de início/conclusão. O prazo para a distribuição das

informações.

• Formato/meio físico. O layout das informações e o método

de transmissão.

• Responsabilidade. O membro da equipe encarregado da

distribuição das informações.

O planejamento das comunicações frequentemente envolve a

criação de entregas adicionais que, por sua vez, exigem mais
tempo e esforço. Portanto, a estrutura analítica do projeto, o
cronograma do projeto e o orçamento do projeto são atualizados
de acordo.

Distribuição das informações

A distribuição das informações envolve colocar as informações

à disposição das partes interessadas no projeto, no momento
oportuno. A distribuição das informações inclui implementar o
plano de gerenciamento das comunicações, além de responder
às solicitações de informações não previstas.

www.esab.edu.br 73
 A comunicação possui muitas dimensões:

Escrita e oral, ouvir e Interna (dentro do projeto) e externa (o cliente, os meios

falar de comunicação, o público)

Formal Relatórios, briefings

Informais Memorandos, conversas para fins específicos

Vertical Para cima e para baixo na organização

Horizontal Entre os pares

Distribuição das informações:

Ativos de processos organizacionais (atualizações)

Documentação das lições aprendidas. A documentação inclui

as causas dos problemas, as razões que motivaram as ações
corretivas escolhidas e outros tipos de lições aprendidas sobre
a distribuição das informações. As lições aprendidas são
documentadas de forma que integrem o banco de dados histórico
tanto para este projeto como para a organização executora.

Registros do projeto. Os registros do projeto podem incluir

correspondências, memorandos e documentos que descrevem
o projeto. Essas informações podem, conforme possível e
adequado, ser mantidas de uma forma organizada. Os membros
da equipe do projeto podem também manter registros em um
diário do projeto.

Relatórios do projeto. Os relatórios formais e informais do projeto

detalham o andamento do projeto e incluem lições aprendidas,
registros de problemas, relatórios de encerramento do projeto e
saídas de outras áreas de conhecimento.

www.esab.edu.br 74
Apresentações do projeto. A equipe do projeto fornece
informações, formal ou informalmente, a algumas ou a todas as
partes interessadas no projeto. Essas informações são relevantes
para as necessidades da audiência e o método de apresentação
é adequado.
Feedback das partes interessadas. As informações recebidas
das partes interessadas relativas às operações do projeto podem
ser distribuídas e usadas para modificar ou melhorar o desempenho
futuro do projeto.

Notificações das partes interessadas. É possível fornecer

informações às partes interessadas sobre problemas resolvidos,
mudanças aprovadas e andamento geral do projeto.

Relatório de desempenho

O processo de relatório de desempenho envolve a coleta de todos

os dados de linha de base e a distribuição das informações sobre
o desempenho às partes interessadas. Em geral, essas informações
sobre o desempenho incluem o modo como os recursos estão
sendo usados para atingir os objetivos do projeto. O relatório de
desempenho deve normalmente fornecer informações sobre
escopo, cronograma, custo e qualidade. Muitos projetos também
exigem informações sobre risco e aquisições.

Gerenciar as partes interessadas

O gerenciamento das partes interessadas se refere a gerenciar as

comunicações para satisfazer as necessidades das partes
interessadas no projeto e resolver problemas com elas. O

www.esab.edu.br 75
gerenciamento ativo das partes interessadas aumenta a
probabilidade de o projeto não se desviar do curso por causa de
problemas não resolvidos das partes interessadas, aumenta a
capacidade das pessoas operarem em sinergia e limita as
interrupções durante o projeto.

ESTUDO COMPLEMENTAR

Indico a leitura da entrevista: Desafios_do_Gerenciamento_de_

Recursos_Humanos na Revista FAE BUSINESS, n.3, de Setembro

de 2002 .

www.esab.edu.br 76
Gerenciamento de riscos do projeto

O que é?

O gerenciamento de riscos do projeto inclui os processos que

tratam da realização de
identificação, análise, respostas
e controle de riscos em um
projeto; a maioria desses
processos é atualizada durante
todo o projeto. Os objetivos do
gerenciamento de riscos do projeto são aumentar a probabilidade
e o impacto dos eventos positivos e diminuir a probabilidade e o
impacto dos eventos adversos ao projeto.

Planejamento do gerenciamento de riscos – decisão de como

abordar, planejar e executar as atividades de gerenciamento de
riscos de um projeto

Identificação de riscos – determinação dos riscos que podem

afetar o projeto e documentação de suas características.

Realizar a análise qualitativa de riscos – priorização dos riscos

para análise ou ação adicional subsequente através de avaliação
e combinação de sua probabilidade de ocorrência e impacto.

www.esab.edu.br 77
Realiza a análise quantitativa de riscos – análise numérica do
efeito dos riscos identificados nos objetivos gerais do projeto.

Planejamento de respostas a riscos – desenvolvimento de opções

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

Controlar os riscos – acompanhamento dos riscos identificados,

monitoramento dos riscos residuais, identificação dos novos riscos,
execução de planos de respostas a riscos e avaliação da sua eficácia
durante todo o ciclo de vida do projeto.

O risco do projeto é um evento ou condição incerta que, se ocorrer,

terá um efeito positivo ou negativo sobre pelo menos um objetivo do
projeto, como tempo, custo, escopo ou qualidade (ou seja, em que o
objetivo de tempo do projeto é a entrega de acordo com o cronograma
acordado; em que o objetivo de custo do projeto é a entrega de
acordo com o custo acordado, etc.). Um risco pode ter uma ou mais
causas e, se ocorrer, um ou mais impactos.

O risco do projeto se origina da incerteza que está presente em todos

os projetos. Os riscos conhecidos são
aqueles que foram identificados e
analisados, e esses riscos podem ser
considerados no planejamento usando os
processos descritos nesta unidade. Os
riscos desconhecidos não podem ser
gerenciados de forma proativa e uma
resposta prudente da equipe do projeto seria alocar contingência
geral contra esses riscos, e também contra todos os riscos conhecidos

www.esab.edu.br 78
para os quais pode não ser econômico ou possível desenvolver uma
resposta proativa.

As organizações percebem os riscos quando eles estão

relacionados a ameaças ao sucesso do projeto ou a oportunidades
para aumentar as chances de sucesso do projeto. É possível
aceitar os riscos que constituem ameaças ao projeto se eles forem
equivalentes à premiação que pode ser obtida ao se assumir
esses riscos.

Carvalho Júnior (2012) considera importante e necessário a

utilização de instrumentos que sejam capazes de gerar documentos
expressos para o monitoramento dos riscos. Afirma ainda que a
elaboração desses documentos é de vital importância pois serão
utilizados pelas equipes de planejamento e gestão nas principais
fases do projeto.

Planejamento do gerenciamento de riscos

Um planejamento cuidadoso e explícito aumenta a possibilidade

de sucesso dos outros cinco processos de gerenciamento de
riscos. O planejamento do gerenciamento de riscos é o processo
de decidir como abordar e executar as atividades de gerenciamento
de riscos de um projeto. O planejamento dos processos de
gerenciamento de riscos é importante para garantir que o nível,

www.esab.edu.br 79
tipo e visibilidade do gerenciamento de riscos estejam de acordo
com o risco e a importância do projeto em relação à organização,
para fornecer tempo e recursos suficientes para as atividades de
gerenciamento de riscos e para estabelecer uma base acordada
de avaliação de riscos.

Análise e reuniões de planejamento

As equipes de projetos realizam reuniões de planejamento para

desenvolver o plano de gerenciamento de riscos. Os participantes
dessas reuniões podem incluir o gerente de projetos, membros da
equipe do projeto selecionados e partes interessadas, qualquer
pessoa da organização que tenha responsabilidade no
gerenciamento das atividades de execução e planejamento de
riscos, e outras pessoas, conforme necessário.

Os planos básicos para executar as atividades de gerenciamento

de riscos são definidos nessas reuniões. Serão desenvolvidos os
elementos de custo de riscos e as atividades do cronograma de
riscos para serem incluídos no orçamento e cronograma do projeto,
respectivamente. Serão designadas as responsabilidades de
riscos.

Modelos organizacionais gerais para categorias de risco e

definições de termos como níveis de risco, probabilidade por tipo
de risco, impacto por tipo de objetivos, além da matriz de
probabilidade e impacto, serão adaptados para o projeto específico.
As saídas dessas atividades serão resumidas no plano de
gerenciamento de riscos.

www.esab.edu.br 80
Identificação de riscos

A identificação de riscos determina os riscos que podem afetar

o projeto e documenta suas características. Os
participantes das atividades de identificação de
riscos podem incluir os seguintes, quando
adequado: gerente de projetos, membros da
equipe do projeto, equipe de gerenciamento de
riscos (se designada), especialistas no assunto de fora da equipe
do projeto, clientes, usuários finais, outros gerentes de projetos,
partes interessadas e especialistas em gerenciamento de riscos.
Embora esse pessoal seja muitas vezes constituído pelos
principais participantes da identificação de riscos, todo o pessoal
do projeto deve ser incentivado a identificar riscos.

A identificação de riscos é um processo iterativo porque novos

riscos podem ser conhecidos conforme o projeto se desenvolve
durante todo o seu ciclo de vida. A frequência de iteração e quem
participa de cada ciclo irão variar de caso para caso. A equipe do
projeto deve ser envolvida no processo de forma que possa
desenvolver e manter um sentimento de propriedade e de
responsabilidade em relação aos riscos e às ações de respostas
a riscos associadas. As partes interessadas fora da equipe do
projeto podem fornecer informações adicionais sobre objetivo.

Técnicas de coleta de informações

Os exemplos de técnicas de coleta de informações usados na

identificação de riscos podem incluir:

www.esab.edu.br 81
 Brainstorming. A meta do brainstorming é obter uma lista
abrangente de riscos do projeto. A equipe do
projeto normalmente realiza o brainstorming,
frequentemente com um conjunto multidisciplinar
de especialistas que não fazem parte da equipe. Idéias sobre o
risco do projeto são geradas sob a liderança de um facilitador. As
categorias de risco, como uma estrutura analítica dos riscos,
podem ser usadas como uma referência. Em seguida, os riscos
são identificados e categorizados por tipo de risco e suas definições
são refinadas.

Técnica Delphi. A técnica Delphi é um meio de alcançar um

consenso entre especialistas. Nesta técnica, os
especialistas em riscos de projetos participam
anonimamente. Um facilitador usa um
questionário para solicitar idéias sobre os riscos
importantes do projeto. As respostas são
resumidas e então redistribuídas para os especialistas para
comentários adicionais. O consenso pode ser alcançado após
algumas rodadas desse processo. A técnica Delphi ajuda a reduzir
a parcialidade nos dados e evita que alguém possa indevidamente
influenciar o resultado.
Entrevistas. As entrevistas com participantes experientes
do projeto, partes interessadas no projeto e especialistas no
assunto podem identificar os riscos. As entrevistas são uma das
principais fontes de coleta de dados sobre identificação de riscos.

Identificação da causa-raiz. Esta é uma investigação das

www.esab.edu.br 82
causas essenciais dos riscos de um projeto. Ela refina a definição
do risco e permite o agrupamento dos riscos por causas. É possível
desenvolver respostas a riscos eficazes se a causa-raiz do risco
for abordada.

Análise dos pontos fortes e fracos, oportunidades e

ameaças (SWOT). Esta técnica garante o exame do projeto de
cada uma das perspectivas da análise SWOT, para aumentar a
amplitude dos riscos considerados.

Gerenciamento de riscos – Análise e Respostas

Análise qualitativa de riscos

A análise qualitativa de riscos inclui

métodos de priorização dos riscos
identificados para ação adicional, como
análise quantitativa de riscos ou
planejamento de respostas a riscos. As
organizações podem melhorar o
desempenho do projeto de modo eficaz se concentrando nos
riscos de alta prioridade. A análise qualitativa de riscos avalia a
prioridade dos riscos identificados usando a probabilidade deles
ocorrerem, o impacto correspondente nos objetivos do projeto se
os riscos realmente ocorrerem, além de outros fatores, como o
prazo e tolerância a risco das restrições de custo, cronograma,
escopo e qualidade do projeto.

As definições dos níveis de probabilidade e impacto, e as

www.esab.edu.br 83
entrevistas com especialistas, podem ajudar a corrigir desvios
sistemáticos frequentemente presentes nos dados usados neste
processo. O caráter crítico do prazo nas ações relacionadas ao
risco pode aumentar a importância de um risco. Uma avaliação da
qualidade das informações disponíveis sobre riscos do projeto
também ajuda a entender a avaliação da importância do risco para
o projeto.

Planejamento de respostas a riscos

O planejamento de respostas a riscos é o processo de desenvolver

opções e determinar ações para aumentar as oportunidades e reduzir
as ameaças aos objetivos do projeto. Ele vem após os processos
Análise qualitativa de riscos e Análise quantitativa de riscos inclui a
identificação e designação de uma ou mais pessoas (o(s)
“proprietário(s) das respostas a riscos”) que irão assumir a
responsabilidade sobre cada resposta a riscos acordada e financiada.
O planejamento de respostas a riscos aborda os riscos de acordo
com a sua prioridade, inserindo recursos e atividades no orçamento,
cronograma e plano de gerenciamento do projeto, conforme
necessário.

As respostas a riscos planejadas precisam ser

adequadas à importância do risco, econômicas
ao enfrentar o desafio, rápidas, realistas dentro
do contexto do projeto, acordadas por todas
as partes envolvidas, e ser de propriedade de
uma pessoa específica. É frequentemente
necessário selecionar a melhor resposta a
riscos a partir de diversas opções.

www.esab.edu.br 84
Estratégias para riscos negativos ou ameaças

Três estratégias lidam normalmente com ameaças ou riscos que,

se ocorrerem, podem ter impactos negativos nos objetivos do
projeto. Essas estratégias são prevenir, transferir ou mitigar:

Prevenir. A prevenção de riscos envolve mudanças no plano

de gerenciamento do projeto para eliminar a ameaça apresentada
por um risco adverso, para isolar os objetivos do projeto do impacto
do risco ou para flexibilizar o objetivo que está sendo ameaçado,
como extensão do cronograma ou redução do escopo. O
esclarecimento dos requisitos, obtenção de informações, melhoria
da comunicação ou aquisição de especialização podem prevenir
alguns riscos que surgem no início do projeto.

Transferir. A transferência de riscos exige a passagem do

impacto negativo de uma ameaça para terceiros, juntamente com
a propriedade da resposta. Essa transferência de riscos ,
simplesmente confere a uma outra parte a responsabilidade por
seu gerenciamento; ela não elimina os riscos. A transferência da
responsabilidade pelo risco é mais eficaz quando está relacionada
à exposição a riscos financeiros. A transferência de riscos quase
sempre envolve o pagamento de um prêmio de risco à parte que
assume o risco.

As ferramentas de transferência podem ser bem diferentes e

incluem, entre outros: seguros, seguros-desempenho, garantias,
etc. Os contratos podem ser usados para transferir responsabilidades
por riscos especificados para uma outra parte. Em muitos casos,

www.esab.edu.br 85
o uso de um contrato com base no custo pode transferir o risco do
custo para o comprador, enquanto um contrato de preço fixo pode
transferir o risco para o fornecedor, se o design do projeto estiver
estável.

Mitigar. A mitigação de riscos exige a redução da probabilidade

e/ou impacto de um evento de risco adverso até um limite aceitável.
A realização de ações no início para reduzir a probabilidade e/ou o
impacto de um risco que está ocorrendo no projeto é frequentemente
mais eficaz do que a tentativa de reparar os danos após a ocorrência
do risco. A adoção de processos menos complexos, realizando
mais testes, ou a escolha de um fornecedor mais estável constituem
exemplos de ações de mitigação. A mitigação pode exigir a
elaboração de protótipos para reduzir o risco decorrente do
incremento de escala a partir de um modelo de bancada, para um
dado processo ou produto. Quando não for possível reduzir a
probabilidade, uma resposta de mitigação poderá abordar o impacto
do risco se concentrando nas ligações que determinam a gravidade.
Por exemplo, o projeto de redundância em um subsistema pode
reduzir o impacto de uma falha do componente original.

Os aspectos positivos do risco

Um risco é qualquer evento ou condição em potencial que, em se

concretizando, pode afetar negativamente ou positivamente um
objetivo do projeto. O uso de uma tecnologia não comprovada, a
competição entre projetos pelo acesso aos recursos da
organização, mudanças na economia ou legislação são exemplos
de fatores que constituem riscos para projetos.

www.esab.edu.br 86
Um risco apresenta duas dimensões-chave: Probabilidade e
Impacto. A probabilidade é a sua chance de ocorrer. O impacto é
o seu efeito sobre o objetivo do projeto, caso o evento ou condição
de risco venha a manifestar-se.

O gerenciamento dos riscos no projeto tem por objetivo maximizar

os resultados dos eventos positivos e minimizar as consequências
dos eventos negativos. A análise conjugada das duas dimensões-
chave dos riscos permite qualificá-los em diferentes níveis de
importância ou gravidade para o projeto.

Um projeto é, por natureza, um ambiente de incertezas, o que

implica a necessidade de atenção com os riscos. As pressões
externas sobre os projetos, num ambiente de negócios cada vez
mais dinâmico e competitivo, reforçam esta necessidade. É neste
contexto que o balanceamento de eventos positivos e negativos
se torna peça chave para o sucesso do projeto. Com a Gerência
de Riscos é possível atuar nas ameaças minimizando seus
impactos negativos e promover as oportunidades de forma a
compensar os eventos negativos.

Abusca contínua pela maximização dos eventos positivos

associados a um projeto pode
recuperar um negócio fadado ao
prejuízo e se traduzir em uma
grande oportunidade de
crescimento para a sua empresa.
É ampliando a nossa visão de um
projeto ou negócio que
encontraremos os caminhos para o sucesso.

www.esab.edu.br 87
 ESTUDO COMPLEMENTAR

O Artigo de Robechini Junior e Carvalho (2012) fala sobre o-

relacionamento entre gerenciamento de risco e o sucesso de

projetos. Sugiro a leitura para aprofundamento sobre o assunto.

www.esab.edu.br 88
Concluída a unidade, recomendamos a leitura dos links adicionais
bem como a confecção dos exercícios propostos.

Gerenciamento de aquisições do projeto

O gerenciamento de aquisições do projeto
inclui os processos para comprar ou adquirir os
produtos, serviços ou resultados necessários,
de fora da equipe do projeto, para realizar o
trabalho. Inclui também os processos de
gerenciamento de contratos e de controle de mudanças
necessários para administrar os contratos ou pedidos de compra
emitidos por membros da equipe do projeto autorizados.

Abrange ainda, a administração de qualquer contrato emitido por uma

organização externa (o comprador) que está adquirindo o projeto da
organização executora (o fornecedor) e a administração de obrigações
contratuais estabelecidas para a equipe do projeto pelo contrato.

Faz parte desses processos:

Planejar o Gerenciamento das Aquisições – documentação

das decisões de compras, especificando as abordagens e
relacionando os potencias fornecedores.

Conduzir as aquisições – receber o retorno dos

fornecedores, seleção do fornecedor e realização do contrato.

www.esab.edu.br 89
 Controlar as Aquisições – gerenciamento das relações e
aquisições, monitoramento do desempenho do contrato, e
realizações de mudanças e correções nos contratos.
Encerrar as aquisições – terminar e liquidar cada contrato.
Carvalho (2012) afirma que uma das últimas atribuições da equipe
de gestão de aquisições diz respeito ao encerramento dos
contratos. Afirma inda que tão importante quanto identificar o bem
de interesse e adquiri-lo de um fornecedor é realizar por completo
o conteúdo de tal contrato, ou seja, observar se foi entregue
devidamente o bem ou serviço contratado e se foi paga a quantia
certa por esse bem conforme o combinado.

Esses processos interagem entre si e também com os processos

em outras áreas de conhecimento. Cada processo pode envolver
o esforço de uma ou mais pessoas ou de grupos de pessoas, com
base nas necessidades do projeto. Cada processo ocorre pelo
menos uma vez em todos os projetos e também em uma ou mais
fases do projeto, se ele estiver dividido em fases. Embora os
processos sejam apresentados aqui como componentes distintos
com interfaces bem definidas, na prática eles se sobrepõem e
interagem de maneiras não detalhadas aqui.

Os processos de gerenciamento de aquisições do projeto envolvem

contratos que são documentos legais entre um comprador e um
fornecedor. Um contrato é um acordo que gera obrigações para as
partes que obriga o fornecedor a fornecer os produtos, serviços ou
resultados especificados e obriga o comprador a fornecer
compensação monetária ou outra compensação de valor. Um
contrato é uma relação legal sujeita a remediação nos tribunais.

www.esab.edu.br 90
O acordo pode ser simples ou complexo e pode refletir a simplicidade
ou a complexidade das entregas. Um contrato inclui termos e
condições e pode incluir outros itens como a proposta ou publicações
de marketing do fornecedor e qualquer outra documentação em que
o comprador esteja se baseando para estabelecer o que o fornecedor
deve realizar ou fornecer. É responsabilidade da equipe de
gerenciamento de projetos ajudar a adaptar o contrato às necessidades
específicas do projeto. Dependendo da área de aplicação, os
contratos também podem ser chamados de acordo, subcontrato ou
pedido de compra. A maior parte das organizações possui políticas e
procedimentos documentados que definem especificamente quem
pode assinar e administrar esses acordos em nome da organização.

Planejar o gerenciamento de aquisições

Conforme PMBOK (2013) “o processo planejar o gerenciamento

das aquisições identifica também as necessidades do projeto que
podem, ou devem ser melhor atendidas com a aquisição de
produtos, serviços ou resultados fora da organização do projeto,
em comparação com as necessidades do projeto que podem ser
efetuadas pela equipe do projeto. Quando o projeto obtém os
produtos, serviços e resultados necessários ao seu desempenho
fora da organização executora, os processos desde Planejar o
Gerenciamento das Aquisições até Encerrar as Aquisições são
realizados para cada item a ser adquirido.

O processo de Gerenciamento de aquisições inclui as avaliações

de fornecedores em potenciais, avaliação dos riscos envolvidos

www.esab.edu.br 91
nas análises de desenvolver ou comprar e revisão do tipo de
contrato, verificando a possibilidade transferência dos riscos para
o fornecedor, a fim de reduzir ou mitigar os riscos.

O plano de gerenciamento de aquisições descreve como os

processos de aquisição serão gerenciados desde o desenvolvimento
da documentação de aquisição até o encerramento do contrato. O
plano de gerenciamento de aquisições pode incluir:

Para desenvolver o plano de gerenciamento de aquisições, temos

como entrada deste processo o plano de gerenciamento do projeto,
a documentação dos requisitos, o registro dos riscos, os requisitos
de recursos das atividades, o cronograma, as estimativas de custos
de cada atividade, o registro das partes interessadas, os fatores
ambientais da empresa e os ativos de processos organizacionais.

Conforme PMBOK (2013) “todas as relações contratuais legais

geralmente se encaixam em uma de duas famílias genéricas: de
preço fixo ou de custos reembolsáveis. Além disso, existe um terceiro
tipo híbrido comumente em uso chamado de contrato por tempo e
materiais”.

Os tipos de contratos mais comuns a serem utilizados são:

Contratos de preço fixo
• Contrato de preço fixo garantido (PFG);
• Contrato de preço fixo com remuneração de incentivo
(PFRI);
• Contrato de preço fixo com ajuste econômico do preço
(PF-AEP);

www.esab.edu.br 92
 Contratos de custos reembolsáveis
• Contratos de Custo Mais Remuneração Fixa (CMRF);
• Contratos de Custo Mais Remuneração de Incentivo
(CMRI);
• Contratos de Custo Mais Remuneração Concedida
(CMRC).
Contratos por Tempo e Material (T&M)

Temos com principais saídas deste processo o plano de

gerenciamento das aquisições, a especificação do trabalho das
aquisições, os documentos de aquisição, os critérios de seleção
de fontes, as decisões de fazer ou comprar, as solicitações de
mudanças e as atualizações nos documentos do projeto.

Conduzir as Aquisições

Este processo obtém as respostas dos fornecedores, seleção do

fornecedor e a realização do contrato. Seus principais benefícios
é o alinhamento das expectativas das partes interessadas através
dos acordos realizados.

Como entrada para este processo temos: o plano de gerenciamento

de aquisições, os documentos de aquisições, os critérios para
seleção das fontes, as propostas dos fornecedores, os documentos
do projeto, as decisões de comprar ou fazer, as especificações do
trabalho de aquisições e os ativos de processos organizacionais.

Como saída do processo de conduzir as aquisições temos a

seleção dos fornecedores que foram selecionados, os acordos
realizados, o calendário dos recursos, as solicitações de mudança,

www.esab.edu.br 93
as atualizações no plano de gerenciamento de Aquisições e
documentos do projeto.

Controlar as Aquisições

O Processo de controlar as aquisições realiza o gerenciamento

das relações e aquisições, monitora o desempenho dos contratos,
e em caso de necessidade, realiza mudanças e correções nos
contratos existentes. Seu principal benefício é garantir o
desempenho tanto do fornecedor quando do comprador em
relação aos requisitos de aquisição (de acordo com os termos
legais)

Como entrada para este processo temos o plano de gerenciamento

do projeto, os documentos de aquisição, os acordos, as solicitações
de mudança aprovadas, os relatórios de desempenho do trabalho
e os dados de desempenho do trabalho.

Com saída do processo de controlar as aquisições, temos as

informações sobre o desempenho do trabalho, as solicitações de
mudanças e as atualizações do plano de gerenciamento das
aquisições, nos documentos do projeto e nos ativos de processo
organizacionais.

Encerrar as Aquisições

O Processo de encerrar as aquisições finaliza todas as aquisições do

projeto. Seu benefício principal é a documentação dos acordos e de
documentos relacionados para futuras consultas.
Como entrada para este processo temos o plano de gerenciamento do
projeto e os documentos de aquisição.

www.esab.edu.br 94
Com saída do processo de encerrar as aquisições, temos as aquisições
encerradas e as atualizações nos ativos de processo organizacionais.

Quem são as partes interessadas?

Conforme PMBOK (2013) as partes interessadas no projeto são

todas as pessoas, grupos de pessoas ou organizações que podem
impactar ou serem impactadas pelo projeto. O Gerenciamento das
partes interessadas possui um conjunto de processos necessários
para identificar, planejar o gerenciamento, gerenciar o engajamento
e controlar o nível de engajamento das partes interessadas.

Este conjunto de processos também visa a comunicação das

partes interessadas, entendendo
suas expectativas, gerenciando
os conflitos e incentivando o a
participação das partes
interessadas nas decisões e
atividades do projeto.

Conforme Mulcahy (2013) o que o Gerente de Projetos, durante

todo o projeto, deve identificar as partes interessadas, determinar
seus requisitos, determinar suas expectativas, determinar seus
interesses, determinar seu nível de influência, planejar como você
irá gerencia-los, planejar como você irá se comunicar com elas,
gerenciar suas expectativas, influências e engajamento,
comunicar-se com elas e controlar as comunicações e o
engajamento das partes interessadas.

www.esab.edu.br 95
Todos os projetos possuem partes interessadas que afetam
positivo ou negativamente o projeto. Você como gerente de
projetos deverá ter habilidades para identificar as partes
interessadas desde o patrocinador até os usuários finais do
produto ou serviço, passando pelos membros da equipe,
especialistas, departamentos ou grupos da organização, gerentes
funcionais, gerentes operacionais, fornecedores, governo,
consultores, clientes, agências reguladoras e etc.

Identificar as partes interessadas

Conforme PMBOK (2013) este processo identifica as pessoas,

grupos ou organizações que podem ter impactos ou serem
impactados por uma decisão, atividade ou resultado do projeto, e
analisar e documentar informações relevantes relativas aos seus
interesses, nível de engajamento, interdependências, influência,
e seu impacto potencial no sucesso do projeto. O principal objetivo
deste processo é identificar para cada parte interessada o
direcionamento correto.
Como entrada para este processo temos o termo de abertura do
projeto, os documentos de aquisição, os fatores ambientais da
empresa e os ativos de processos organizacionais.

Neste processo, o PMBOK 2013 apresenta alguns modelos

classificatórios usados na análise das partes interessadas tais
como: Grau de poder/interesse, Grau de poder/influência, Grau
de influência/impacto e Modelo de relevância.

www.esab.edu.br 96
Com saída do processo de identificar as partes interessadas,
temos o registro das partes interessadas.

Planejar o gerenciamento das partes interessadas

Conforme PMBOK (2013) este processo desenvolve estratégias

apropriadas de gerenciamento para envolver as partes interessadas
de maneira eficaz no decorrer de todo o ciclo de vida do projeto,
com base na análise das suas necessidades, interesses, e impacto
potencial no êxito do projeto. O principal objetivo deste processo
é fornecer um plano de interação com as partes interessadas.

Como entrada para este processo temos o plano de gerenciamento

do projeto, o registro das partes interessadas, os fatores ambientais
da empresa e os ativos de processos organizacionais.

Com saída do processo de planejar o gerenciamento das partes

interessadas, temos o plano de gerenciamento das partes
interessadas e as atualizações nos documentos do projeto

Gerenciar o engajamento das partes interessadas

Conforme PMBOK (2013) este processo comunica e trabalha com

as partes interessadas para atender às suas necessidades/
expectativas, abordar as questões à medida que elas ocorrem, e
promover o engajamento apropriado das partes O principal objetivo
deste processo é aumentar o nível de apoio às partes interessadas
e minimizar suas resistências.

www.esab.edu.br 97
Como entrada para este processo temos o plano de gerenciamento
do projeto, plano de gerenciamento das comunicações, o registro
das mudanças e os ativos de processos organizacionais.

Com saída do processo de gerenciar o engajamento das partes

interessadas, temos os registros das questões, as solicitações de
mudanças, as atualizações no plano de gerenciamento do projeto,
nos documentos do projeto e nos ativos de processos
organizacionais.

Controlar o nível de comprometimento das partes

interessadas

Conforme PMBOK (2013) este processo monitora os

relacionamentos das partes interessadas no projeto em geral, e
ajusta as estratégias e planos para o engajamento das mesmas.
O principal objetivo deste processo é aumentar a eficiência e
eficácia das atividades de engajamento ao longo do ciclo de vida
do projeto.

Como entrada para este processo temos o plano de gerenciamento

do projeto, os requisitos das questões, os dados de desempenho
do trabalho e os documentos do projeto.

Com saída do processo de controlar o nível de comprometimento

das partes interessadas, temos as informações sobre o
desempenho do trabalho, as solicitações de mudança, as
atualizações no plano de gerenciamento do projeto, nos
documentos do projeto e nos ativos de processos organizacionais.

www.esab.edu.br 98
 ESTUDO COMPLEMENTAR

Para se aprofundar sobre os conceitos citados neste capítulo, indico a

leitura dos capítulos do PMBOK concernentes a essas áreas de

conhecimento.

O Artigo de Nate Solberg (2011) fala sobre o gerenciamento eficaz das

partes interessadas usando as equipes principais.Sugiro a leitura para

aprofundamento sobre o assunto.

www.esab.edu.br 99
Governança em TI

A partir de uma necessidade...

Controlar os objetivos da área de tecnologia, alinhar as estratégias,

definir expectativas e medidas de desempenho, viabilizar e
gerenciar recursos, definir prioridades, direcionar as atividades de
TI e gerenciar os riscos são algumas das possibilidades que a
Governança de TI traz para a empresa.

A Governança de TI
surgiu num quadro de
preocupações crescentes
com a governança
corporativa, decorrente de
escândalos administrativos
em empresas de grande
expressão. Em 2 de
dezembro de 2001, a gigante norte-americana do setor energético
Enron, com faturamento superior a US$ 100 bilhões, entrou em
falência. Deu início a uma série de escândalos corporativos (Tyco,
Global Crossing, Qwest, Merck, Halliburton, Lucent, Vivendi,
Xerox e Parmalat entre outras) que colocou na ordem do dia
questões como ética nos negócios, transparência, governança

www.esab.edu.br 100
corporativa, conflitos de interesse entre acionistas e gestores das
corporações, conflitos de interesse entre acionistas minoritários e
os controladores, conflitos de interesse entre as corporações e a
sociedade. Por fim, colocou em xeque os sistemas de gestão até
então vigentes.

A governança surgiu nesse

cenário visando garantir o
componente ético da
organização, representado
por seus diretores e outros
funcionários, na criação e
proteção dos benefícios
para todos os acionistas. Como alcançar isso de forma clara. O
mercado reagiu à onda de escândalos com várias iniciativas,
próprias ou derivadas de leis que obrigam a uma maior
transparência da gestão. O Acordo de Basiléia II, em 2001, voltado
para aspectos financeiros e de transparência das empresas, e a
Sarbanes-Oxley Act, de 2002, com leis voltadas para definição
de critérios de governança, criaram regras que se espalharam
pelas organizações e chegaram até as áreas de TI. Sarbanes-
Oxley tem artigos diretamente voltados para a área de TI, que faz
parte da governança corporativa.

www.esab.edu.br 101
Considerada por muitos como uma espécie de caixa preta, a área
de TI tem suas ações pouco
conhecidas dentro das
organizações. Na maioria
das empresas, não existe
alinhamento das estratégias
de TI com as estratégias de
negócios. É um setor com
enorme quantidade de recursos, linguagem própria, de difícil
entendimento pela organização. Só um novo sistema de gestão
pode trazer esse conhecimento mais amplo dos objetivos de TI.
Apenas com novas práticas de governança será possível fazer a
adequação de TI com a estratégia de negócios das organizações.
No Brasil, esse é um movimento que começou com as filiais das
empresas estrangeiras, mas tende a se ampliar para as empresas
nacionais de maior porte

Dividida em fases e processos, chamados de Domínios de TI, a

Governança de TI trabalha com metodologias de gerenciamento.
Uma das que mais se destacam atualmente é o CobIT (Control
Objectives for Information and Related Technology), um guia para
a gestão de TI que tem como objetivo auxiliar no gerenciamento e
controle das iniciativas tecnológicas, ajudando a otimizar os
investimentos da área e fornecendo métricas para avaliação de
resultados. Esta metodologia divide-se em quatro Domínios:
Planejamento e Organização; Aquisição e Implementação; Entrega
e Suporte; e Monitoração.

www.esab.edu.br 102
Criar estruturas de governança significa definir uma dinâmica de
papéis e interações entre membros da organização, de tal maneira
a desenvolver participação e engajamento dos membros no
processo decisório estratégico, valorizando estruturas
descentralizadas. Entretanto, em TI, este conceito tem servido de
guarda-chuva para uma lista de acrônimos. Entre eles, se destacam
ITIL, CobIT e CMM.

Para a implantação do
domínio de Entrega e
Suporte, por exemplo,
aplica-se a
metodologia BSM
(Business Service
Management), que
utiliza ferramentas e
promove mudanças
nos processos operacionais, permitindo à área de TI supervisionar
a entrega e suporte dos serviços oferecidos aos clientes. Isso é
feito através da monitoração prática dos indicadores de
performance e disponibilidade dos sistemas que suportam os
macroprocessos das empresas, em tempo real. A resolução de
problemas é baseada numa análise de impacto nos negócios e
nos ANS (Acordos de Níveis de Serviços) estabelecidos. O BSM
possibilita ainda o monitoramento do ambiente a partir de uma
perspectiva de negócio e serviço, permitindo isolar rapidamente o
problema e encontrar sua causa. Mais inteligente e prático
impossível.

www.esab.edu.br 103
Governança em TI - controles

Controles: o equilíbrio entre a eficácia e a eficiência

O grande desafio das empresas é encontrar o equilíbrio entre a

eficácia e a eficiência na adoção dos controles. Quanto maior o
número de controles maior será o controle das operações, porém
maiores serão os recursos exigidos. Os controles e procedimentos
não devem diminuir a criatividade e a capacidade de rápidas
mudanças nas empresas para superar a concorrência e se ajustar
às novas necessidades dos clientes (http://www.efagundes.com/).

Os mecanismos de Governança de TI, caso sigam a orientação

da arquitetura determinada para a organização, alinharão a gestão
de TI com os objetivos de negócio coordenando as decisões em
múltiplos níveis da organização.

Na definição do modelo operacional, é necessário especificar

exatamente o escopo dos serviços prestados ou produtos
disponibilizados e suas possíveis exceções. Uma análise baseada
na Engenharia de Produtos, para definição clara do que a
organização faz, é necessária. Com essa definição, a estratégia
da organização torna-se evidente para os colaboradores. É
possível identificar o que está dentro do escopo de atuação da
organização e, principalmente, o que ela não está.

A Engenharia de Processos de Negócio deve ser usada na

construção do modelo operacional e da arquitetura da empresa,
depois de definido o que a empresa realmente faz, qual é seu

www.esab.edu.br 104
escopo de atuação. Uma certificação como a NBR ISO 9001 pode
auxiliar essa iniciativa de identificação e modelagem dos processos
de negócio, garantindo o alinhamento da operação do negócio
com a estratégia da organização.

No caso da gestão dos serviços

de TI da organização, tenham
eles foco interno ou externo, o
modelo aberto, flexível e não-
proprietário, conhecido como
ITIL - Information Technology Infrastructure Library - pode ser
implementado por qualquer organização, independentemente do
porte ou área de atuação. Como modelo de referência para
gerenciamento de TI, certamente é capaz de atender aos anseios
dos gestores, no que se refere à melhoria da qualidade dos
serviços prestados pela área. Por isso, deve ser considerado em
conjunto com a Engenharia de Processos de Negócio.

A determinação dos controles de TI usados na arquitetura da

empresa deve considerar boas práticas já consagradas como o
modelo COBIT – Control Objectives for Information and related
Technology. A organização também pode optar por certificações
que atestam a presença e eficácia de controles internos de TI,
como a seção 404 da lei Sarbanes-Oxley representada pela
certificação Statement on Audit Standards no 70 (SAS 70).

A adoção de uma metodologia de gestão de projetos, customizada

para a organização, deve ser considerada para que, em conjunto
com os mecanismos de governança de TI, seja possível construir
e implantar a estrutura para execução do negócio, projeto por
projeto. As boas práticas consolidadas pelo Project Management

www.esab.edu.br 105
Institute - Project Management Body of Knowledge - e pelo Office
of Government Commerce, do Reino Unido, – PRINCE2 – devem
ser analisadas para criação da metodologia customizada. Essa
metodologia, se desenvolvida considerando todas as variáveis
envolvidas, fornecerá subsídios aos tomadores de decisão para
alinhamento dos projetos e iniciativas com a estratégia da
organização.

Todas essas iniciativas devem ser acompanhadas de uma eficiente

gestão de pessoas por parte da organização. É necessário
entender que o ambiente turbulento em que ela está inserida, na
maioria das vezes, exige a mudança de comportamento das
pessoas envolvidas: de funcionários ‘passivos’ – capazes de
cumprir suas tarefas sem questioná-las - para colaboradores da
organização – capazes e motivados para reinventar seus
processos. Para essa mudança acontecer, são necessárias
avaliações e análises constantes das necessidades do negócio e
orientação dos envolvidos para que as metas estabelecidas sejam
atingidas e que todos entendam seu papel no alcance das metas
da organização.

Colaboradores capazes e motivados são proativos. Essa postura

permite um acúmulo maior de responsabilidades com maior poder
na tomada de decisão nos processos da organização. Com cada
vez mais liberdade, que incentiva a busca por soluções de maior
qualidade e baixo custo, as melhorias são mais frequentes e
eficientes, pois partem da ‘linha de frente’.

www.esab.edu.br 106
Modelo Operacional

O modelo operacional é uma definição na maneira como a

organização executará o seu negócio. Sua definição deve ser
orientada pela estratégia da organização, pois esse modelo
influenciará os processos de negócio e a infraestrutura de TI.

A visão de como a organização operará e como ela se diferenciará

das outras determinará o grau de padronização e integração
necessários para execução da estratégia da organização e,
padronização possibilita maior eficiência no aproveitamento dos
recursos e maior produtividade, pois permite mensurar o processo
produtivo e compará-lo com os padrões existentes, permitindo um
trabalho de melhoria que diminui a variabilidade. A definição de
como um processo ou atividade pode ser executado,
independentemente de quem o executa, pode limitar a possibilidade
de inovação ou substituição das técnicas ou metodologias usadas
(redução da flexibilidade).

Existe um continuum em que as organizações devem se posicionar:

de um lado, a organização com alto grau de padronização em
todas as suas áreas ou unidades de negócio e, do outro,
organizações com maior liberdade, em seus setores ou unidades
de negócio, para executar sua estratégia. O sucesso da escolha
desse posicionamento depende diretamente do alinhamento com
a estratégia da organização, que considera o ambiente externo, e
influenciará a definição da arquitetura da empresa e dos
mecanismos de governança de TI.

www.esab.edu.br 107
O posicionamento poderá limitar as escolhas estratégicas
possíveis no futuro. No entanto, também permite um melhor
desenvolvimento das competências essenciais da organização.

A construção de uma fundação estável, focada, permite um

comportamento proativo, diferenciado, ausente em muitas das
organizações em qualquer ramo de atividade.

A integração trata do grau de compartilhamento da informação por

toda a organização, quem deve acessá-la e por que, nas áreas da
organização ou unidades de negócio. Dependendo do ramo de
atividade da organização, o compartilhamento de informações
sobre clientes, fornecedores ou concorrência pode ser de extrema
importância.

Um processo para tomada de decisão

Decisões são escolhas. Uma boa tomada de decisão é resultado

de uma boa escolha. O que caracteriza um bom administrador são
suas boas tomadas de decisões. Em minha opinião, todos nós
tomamos decisões baseadas em um processo, mesmo que
inconscientemente. Então temos que usar um processo o mais
estruturado possível para fazermos uma boa escolha.

Para se ter uma equipe competitiva não basta contratar pessoas

qualificadas e desenvolver os melhores profissionais da empresa,
é importante construir uma equipe onde as habilidades individuais
criem a sustentabilidade da organização e que seja capaz de
aprender continuamente para estar um passo a frente da
concorrência e enfrentar crises inesperadas.

www.esab.edu.br 108
Essa postura também facilita a adoção de um modelo de negócio
aberto, caso necessário, definido por Chesbrough (2007), em que
a inovação passa a ser um processo aberto. Ideias descartadas
em algumas organizações podem ser aproveitadas em outras,
que enxergam essa oportunidade em um ambiente caracterizado
pelo aumento nos custos de pesquisa e desenvolvimento e pela
redução no ciclo da vida dos produtos. O modelo de negócio
aberto, ao utilizar recursos externos de pesquisa e desenvolvimento,
diminui a necessidade de mobilização de recursos internos e
reduz o tempo necessário no processo de inovação.

Toda mudança causa um abalo em estruturas já consolidadas e

pode tornar frágil – principalmente frente à concorrência. Ter
consciência desse processo, e buscar mecanismos para conseguir
uma estabilidade diante das mudanças, pode transformar a
fraqueza em força: a Flexibilidade.

Gestão de mudanças em TI

O grande desafio dos líderes é construir equipes de alto

desempenho para enfrentar as constantes mudanças de mercado
e os ataques da concorrência. Para construir essas equipes temos
que buscar pessoas com comportamentos de liderança com as
seguintes características: ambição, direção e tenacidade,
autoconfiança, abertos a novas ideias, realismo e um insaciável
apetite para aprender.

www.esab.edu.br 109
Atuando em equipe essas pessoas devem moldar um espírito de
time de alto desempenho. Para atingir esse desempenho devem
existir certos princípios não negociáveis, tais como: comunicação
eficiente, coragem de enfrentar desafios, antecipar conflitos,
escolher as pessoas certas para as atividades, prover feedback e
coaching entre os membros da equipe e reconhecimento pelo
trabalho.

Gestão de Contratos com SLA

Cada vez mais as empresas estão contratando serviços baseados

em níveis de serviços, conhecidos pela sua sigla em inglês - SLAs
– Service Level Agreements. Para administrar esses contratos é
necessário que tanto as prestadoras de serviços como as empresas

www.esab.edu.br 110
contratantes possuam um gerenciamento dos parâmetros
contratos. Um gerenciamento eficiente não significa ser sofisticado,
com uma infinidade de parâmetros a serem acompanhados, onde
em alguns casos tornar-se o fim e não o meio, para atender os
requisitos do negócio que o serviço se propõe.

Guia rápido para gestão de mudanças em TI

Mauricio Aguiar, presidente do QAI Brasil, sugere um check list

com dez itens para gerenciamento de mudanças na área de TI.
Comunicação clara e visão de longo prazo são pontos funda-
mentais...

Mudar para uma nova tecnologia ou terceirizar áreas-chave de TI

traz benefícios para as empresas, mas nem sempre a implemen-
tação de mudanças é vista assim por todos, inclusive por profis-
sionais que não estejam diretamente envolvidos com as novas
funções. A opinião é de Mauricio Aguiar, presidente do QAI Brasil
(Quality Assurance Institute), líder em melhoria de qualidade,
produtividade e gerenciamento de processos na área de servi-
ços de TI, que acaba de desenvolver um check list com dez itens
para minimizar o impacto de mudanças.

“Na verdade, são algumas dicas sobre como sobreviver e, princi-

palmente, tirar vantagens de processos de mudanças”, afirma o
executivo. Os pontos são:

1. Divulgue a palavra – grandes mudanças nunca devem ser

secretas. Os responsáveis devem divulgar as novidades, mesmo
quando pequenas. É o que ajuda a minimizar rumores e conter o
fluxo de desinformação.

2. Fale em uma só voz – funcionários envolvidos em mudan-

ças devem ouvir mensagens consistentes, mesmo quando se
trata de más notícias. O script deve ser seguido e “eu não sei”
jamais deve ser dito no lugar de “eu sei, mas não estou autoriza-
do a dizer”.

www.esab.edu.br 111
3. Encoraje a participação – é sempre bom criar fóruns onde
os profissionais podem questionar as medidas e expor suas pre-
ocupações. É melhor ter descontentamentos externados do que
inflamando o ambiente.

4. Treine cedo e com frequência – na maior parte dos casos

é mais barato e eficiente treinar a equipe atual do que encontrar
novos profissionais. O treinamento deve ser um processo contí-
nuo, não um evento pontual.

5. Não deixe que o conhecimento se perca – os melhores

funcionários já estão na empresa, e devem ser mantidos mesmo
que suas funções sejam extintas. Quem percebe isso oferece
serviços de recolocação que facilitam aos funcionários encontrar
oportunidades dentro da própria organização.

6. Obtenha habilidades – se alguns membros da equipe não

contam com as habilidades interpessoais necessárias, a área
de RH, ou uma consultoria especializada em gerenciamento de
mudanças, podem ajudá-los nesta transição.

7. Entenda seu portfólio de TI – é preciso estabelecer uma vi-

são compartilhada da situação, para que todos, incluindo os altos
escalões, tenham a mesma visão do que está implementado e
como este parque será afetado pelas mudanças.

8. Pense estrategicamente – apenas uma em cada cinco em-

presas planeja seus orçamentos de TI com mais de 12 meses de
horizonte. De todo modo, companhias com visão de longo prazo
de seus portfólios passam por mudanças com menos traumas.

9. Seja realista – por mais que se diga o contrário, os projetos

são mais longos e mais caros do que o planejado. Não espere
que tudo volte ao normal em seis meses.

10. Pense na transformação – se a mudança é esperada, ela

não deve causar rupturas. Rupturas são causadas por incêndios
ou brechas na segurança. “Se uma empresa anuncia que está
adotando um programa de telecomutação para reduzir custos
nos escritórios, e isso é feito, o nome disto é; plano”, conclui
Aguiar.

www.esab.edu.br 112
 ESTUDO COMPLEMENTAR

Sugiro leitura do Artigo de Tarouco e Graem

(2011) sobre Governança de Tecnologia da
Informação. O Artigo sugere um panorama da
adoção de modelos de melhores práticas por
empresas brasileiras usuárias.

www.esab.edu.br 113
ITIL e a gestão de mudanças

São descritos os fundamentos básicos para utilização desse

modelo, como: classificação das mudanças; comitê de mudanças;
análise de risco; fluxos operacionais e cadeia de aprovação de
mudanças; calendário de mudanças; indicadores e relatórios de
desempenho. Por último, são apresentados fatores críticos para o
sucesso da implementação convergente.

O ambiente de mudanças

No ambiente de tecnologia da informação (TI), as mudanças no

ambiente de produção ocorrem em maior volume e são
originadas pela expansão do respectivo parque, pela
implantação de novos serviços e expansão da base de clientes
e, também, por ações preventivas ou corretivas. Entre os
exemplos mais comuns de mudanças, encontram-se:

• Alteração de código ou versões de software em operação

por natureza evolutiva ou corretiva (solução de um problema/
incidente);

• Instalação ou manutenção de hardware em equipamentos

nos data centers da empresa (servidores, rede LAN, firewall);

• Intervenções em sistemas de informação que suportam os

processos de negócio da empresa;

www.esab.edu.br 114
 • Migração de packages dos ambientes de homologação
para os ambientes de produção;

• Manutenções de infraestrutura de energia.

PUBLICAÇÕES PROCESSOS FUNÇÕES

- Gerenciamento Financei-
ro do TI;
Estratégia do - Gerenciamento do Portifó-
Serviço lio de Serviços;
- Gerenciamento da De-
manda.
- Gerenciamento do Catálo-
go de Serviços;
- Gerenciamento do Nível
de Serviços;
- Gerenciamento da Capa-
cidade;
- Gerenciamento da Dispo-
Desenho do nibilidade;
Serviço - Gerenciamento da Conti-
nuidade do
Serviço;
- Gerenciamento da Segu-
rança da
Informação;
- Gerenciamento de Forne-
cedores.

www.esab.edu.br 115
 - Gerenciamento de Mu-
danças;
- Gerenciamento de Ativos
de Serviço
e da Configuração;
- Gerenciamento da Libera-
Transição do
ção
Serviço
e Distribuição;
- Validação e Teste do Ser-
viço;
- Avaliação;
- Gerenciamento do Co-
nhecimento.
- Gerenciamentode Even- - Central de Ser-
tos; viços;
- Gerenciamento de Iniden- - Gerenciamento
tes; Técnico;
Operação do
- Execução de Requisições; - Gerenciamento
Serviço
- Gerenciamento de Proble- das Operações
mas; de TI;
- Gerenciamento do Aces- - Gerenciamento
so. de Aplicações.
Melhoria - Relato de Serviço;
Contínua do - Medição do Serviço.
Serviço

Em geral, o mercado e as áreas ligadas à tecnologia da informação

vêm adotando o conjunto de melhores práticas do ITIL (Information
Technology Infrastructure Library) como base para seus processos
de planejamento e controle de mudanças nos ambientes de
operação.

Isoladamente, cada um desses processos atende à respectiva

gestão de mudanças. Porém, dentro do novo cenário de
convergência tecnológica, organizacional e de serviços entre
tecnologia da informação e telecomunicações, faz-se necessária

www.esab.edu.br 116
a adoção de um processo de gestão de mudanças convergente
nas empresas prestadoras de serviço de telecomunicações. A
falta de integração simultânea entre processos de mudança da
tecnologia da informação e de mudança de telecomunicações
pode gerar conflitos que aumentarão os riscos de indisponibilidade
dos serviços. Para ilustrar, podemos imaginar uma situação na
qual, em uma mesma data, há duas mudanças agendadas: a
primeira, uma mudança de TI, na qual se faz necessária a troca de
informações (tráfego de dados) entre dois data centers; a segunda,
uma manutenção programada na rede de transmissão da
operadora, que gera indisponibilidade no circuito que interliga os
mesmos

Um pouco de história

O modelo ITIL foi desenvolvido pelo governo britânico no final da

década de 1980 e tem como foco principal a operação e a gestão
da infraestrutura de TI na organização, incluindo todos os pontos
importantes no fornecimento e manutenção de seus serviços
(OGC, 2000). O ITIL, composto por um conjunto das melhores
práticas para auxiliar a governança de TI, vem sendo um dos
modelos mais amplamente utilizados nos últimos tempos (RUDD,
2004). Seu princípio básico é o objeto de seu gerenciamento, isto
é, a infraestrutura de TI.

O ITIL descreve os processos necessários para suporte à utilização

e ao gerenciamento da infraestrutura de TI. Outro princípio
fundamental dele é o fornecimento de qualidade de serviço aos
clientes de TI a custos justificáveis, ou seja, relaciona os custos
dos serviços de tecnologia, de forma que se possa perceber como

www.esab.edu.br 117
eles agregam valor estratégico ao negócio. Através de processos
padronizados de Gerenciamento do Ambiente de TI, é possível
obter uma relação adequada entre custos e níveis de serviço
prestados pela área de TI. O ITIL consiste em um conjunto de
melhores práticas inter-relacionadas para minimizar o custo, ao
tempo em que aumenta a qualidade dos serviços de TI entregues
aos usuários.

A versão 2 do ITIL é organizada em cinco módulos principais: A

perspectiva de negócios, O gerenciamento de aplicações, A
entrega de serviços, O suporte a serviços e O gerenciamento de
infraestrutura.

Como o modelo não dispõe de um módulo dedicado à gerência

de mudanças, essa disciplina é abordada no módulo de suporte
a serviços.

O objetivo principal da disciplina Gerência de Mudanças é

assegurar o tratamento sistemático e padronizado de todas as
mudanças ocorridas no ambiente operacional, minimizando,
assim, os impactos decorrentes de incidentes e problemas
relacionados com essas mudanças na qualidade do serviço.
Consequentemente, melhora a rotina operacional da
organização.

A missão da Gerência de Mudanças é: “Gerenciar todas as

mudanças que possam causar impacto na capacidade da área de
TI de entregar serviços, através de um ponto único e centralizado
de aprovação, programação e controle da mudança, para assegurar
que a infraestrutura de TI permaneça alinhada aos requisitos do

www.esab.edu.br 118
negócio, com menor risco possível” (HP, 2004). Cumprir essa
missão requer uma cuidadosa e bem pensada avaliação de riscos,
de impactos e do processo de aprovação das mudanças.

Um gerenciamento de mudanças eficiente deve promover a

redução nos incidentes gerados pelas mudanças. Essa avaliação
pode ser feita através da comparação dos números de incidentes
antes e depois da mudança. O Gerenciamento de Mudanças deve
ser flexível e adaptável. Essa disciplina é considerada peça
fundamental para a saúde de qualquer empresa, independentemente
de seu tamanho ou setor de atuação. A Gerência de Mudanças
tem como tarefa implementar procedimentos e técnicas capazes
de acompanhar o desenvolvimento do negócio, sem interferir na
vida dos usuários internos e dos clientes.

O ITIL define mais alguns conceitos no Gerenciamento de

Mudanças, entre eles:

• Requisição de Mudança (RDM), mecanismo formal para a

solicitação de mudança;

• Comitê de Controle de Mudanças (CCM), responsável pela

avaliação do impacto das mudanças solicitadas, envolvendo
os recursos necessários;
• Comitê de Emergência (CE), que complementa a atuação
do CCM em casos nos quais a necessidade de mudança é
urgente e não há tempo para a atuação desse.
• Cronograma de Mudanças Futuras (CMF), que contém
detalhes de todas as mudanças aprovadas e suas datas de
implementação para um período combinado.

www.esab.edu.br 119
 • O Gerenciamento de Mudanças prevê planos de retorno
para o caso de mudanças que não possam ser concluídas
por algum motivo.

Em 2002, o TMF (TeleManagement Fórum) criou o eTOM (Enhanced

Telecom Operations Map), que é um aperfeiçoamento do TOM
(Telecom Operations Map), criado em 1998, o qual passou a
representar uma visão completa dos processos de uma prestadora
de serviços de telecomunicações. O objetivo do TMF, ao estabelecer
o eTOM, foi definir um modelo de processos que sirva de base à
criação de uma nova geração de sistemas e softwares de operação
e propicie a automação dos processos, integrando softwares
comerciais padrões. Esse programa do TM Fórum foi denominado
NGOSS (New Generation of Operations Systems and Software).

Estrutura do ITIL:

O framework de processos eTOM apresenta uma estrutura própria

para os processos de telecomunicações. Essa estrutura é dividida
em grupos de processos: processos operacionais, processos de
estratégia, infraestrutura, produto e conjunto de gestão empresarial.
Esses grupos foram divididos em horizontais e verticais.

Para representar melhor esse nível de observação, os processos

podem ser vistos sob duas perspectivas:

• Agrupamento vertical dos processos, que representa uma

visão dos processos fim a fim dentro de um negócio, como
por exemplo, tudo que estiver envolvido no fluxo de
bilhetagem para um cliente.

www.esab.edu.br 120
 • Agrupamento horizontal dos processos, representando uma
visão funcional dentro de um negócio, como por exemplo, a
gestão de canais de fornecimento.

O detalhamento dos processos horizontais decompõe o

macroprocesso em processos, que é o nível 2 do eTOM. Por sua
vez, a decomposição dos processos nível 2 mostra os sub-
processos daquela horizontal, o nível 3.

Os processos que tratam da Gerência de Mudanças no eTOM

estão cobertos pelo nível 2, nos seguintes itens:

• Configuração e Ativação de Serviço, da Vertical de

Aprovisionamento e Horizontal de Gerência e Operações de
Recursos;

• Suporte e Disponibilidade do Recurso, da Vertical de Suporte e

Disponibilidade de Operações e Horizontal de Gerência e
Operações de Recursos;

• Suporte e Disponibilização da Gerência e Operações de

Serviços, na Vertical de Suporte e Disponibilização de
Operação, Horizontal de Gerência e Operações de Recursos;

• Gerência de Problemas no Serviço, na Vertical de Garantia de

Qualidade, Horizontal de Gerência e Operações de Serviços;

• Aprovisionamento de Recursos, da vertical deAprovisionamento,

Horizontal de Gerência e Operações de Recursos;
• Gerência de Problema nos Recursos, na Vertical de Garantia
de Qualidade, Horizontal de Gerência e Operações de
Recursos;

www.esab.edu.br 121
 • Desenvolvimento e Retirada de Produto e Oferta, da Vertical
de Gerência do Ciclo de Vida de Produto e Vertical de
Gerência de Marketing e Oferta;

• Desenvolvimento e Retirada de Recurso, da Vertical de

Gerência do Ciclo de Vida de Produto e Vertical de
Desenvolvimento e Gerência de Recursos;

• Desenvolvimento e Gerenciamento de Mudança da Cadeia

de Suprimentos, da Vertical de Gerência do Ciclo de Vida de
Produto e Vertical de Desenvolvimento e Gerência da
Cadeia de Suprimentos.

O eTOM, embora considere o gerenciamento de mudanças no

nível 3, não particulariza os respectivos processos, ao contrário
do ITIL, que prevê uma gerência especifica para essa prática.

Com a introdução do conceito de NGN (Next Generation Network),

um novo paradigma de rede foi revelado. Sob a ótica desse novo
paradigma, a rede se divide em camadas funcionais horizontais.
Cada camada define o limite e o escopo de atuação do respectivo
nível funcional, sendo que a camada superior (a de serviços) é a
responsável pelo provimento de todos os recursos necessários
para a oferta de serviços de valor adicionado.

A arquitetura, cujo nome genérico é SDP (Service Delivery

Platform), criada a partir das redes NGN, possibilita a integração
na camada de serviços dos sistemas de TI e os recursos de rede,
permitindo seu controle, as aplicações, os conteúdos, o acesso,
recursos e bilhetagem. Essa arquitetura materializa, de fato, a

www.esab.edu.br 122
integração dos mundos de TI e Telecomunicações no provimento
de produtos e serviços.

A arquitetura SDP não está ainda definida por um padrão único,

nem possui uma arquitetura de referência que tenha consenso de
mercado. Trata-se, ainda, de um conceito que conta com ampla
aceitação de mercado e busca integrar tecnologias atuais e
emergentes, tais como Web Services, Parlay X e SOA (Arquitetura
Orientada a Serviço), em uma arquitetura concisa e flexível, com
capacidade de se adaptar aos ambientes heterogêneos de OSS
(Sistemas de Suporte a Operação)/BSS (Sistemas de Suporte ao
negócio) dentro das operadoras.

O provimento de serviços para as empresas de Telecomunicações

depende de processos convergentes entre TI e Telecomunicações.
A Gerência de Mudanças para essas empresas certamente deve
ser vista sob uma ótica de integração do serviço no seu fim a fim.

Proposta de processo convergente

Conforme apresentado, o item 3 deste artigo lista os itens que

demandam uma gerência de mudanças. A figura 2, a seguir, que
é parte do documento GB929 do eTOM, propõe a utilização
complementar do ITIL nos processos de Gerenciamento do Serviço
de Telecomunicações.

Embora o TMF defenda a utilização complementar do ITIL em

alguns processos, a proposta deste trabalho é aplicar a Gerência
de Mudanças do ITIL como disciplina formal no Gerenciamento de

www.esab.edu.br 123
Mudanças de Telecomunicações, não apenas para a infraestrutura
de TI, mas para todos os recursos de telecomunicações. As
justificativas são baseadas na formalização do estudo de impacto,
no entendimento de que os inventários, de telecomunicações e de
TI, precisam ser igualmente mantidos. Da mesma forma, baseia-
se na necessidade de um comitê de mudanças para
telecomunicações, considerando, principalmente, a abordagem
de serviços convergentes e de valor agregado.

Esta proposta vem ao encontro à necessidade de Gerenciamento

de Mudanças para empresas de telecomunicações, pois a
manutenção dos serviços no seu fim a fim depende de recursos
de TI e Telecom.

Um dos principais fundamentos do ITIL para o Gerenciamento de

Mudanças é assegurar que a infraestrutura de TI permaneça
alinhada aos requisitos do negócio. Pelo proposto neste tutorial,
considera-se que tal premissa seja estendida a toda a infraestrutura
de uma empresa de telecomunicações, sendo que ao entendimento
dessa infraestrutura deve ser adicionada a infraestrutura de TI,
quando essa é parte dos recursos necessários ao fornecimento
de serviços e geração de produtos.

A adoção de uma Gerência de Mudanças, baseada no que

apregoa o ITIL para o mundo de telecomunicações, traz, em sua
íntegra, todos os benefícios apregoados, isto é, as melhores
práticas do universo de TI. A revisão desses processos já ocorre
de forma natural, principalmente com o lançamento dos produtos
considerados convergentes.

www.esab.edu.br 124
De alguma forma, visando garantir a qualidade mínima exigida
pela competitividade e/ou mesmo pelo sistema regulatório, as
empresas já estão integrando os processos telecom e tecnologia
da informação. A convergência de ferramentas que suportam o
processo de Gerenciamento de Mudanças é uma consequência
do alinhamento desses processos. Os fornecedores de sistemas
eTI já estão se ajustando a esta nova realidade.

Atualmente, esse conceito de mudanças é visto de forma mais

ampla, não se restringindo às mudanças de TI e sim a todos os
recursos que possam impactar o negócio, o que vai além de
melhores práticas de TI e da padronização de processos de
telecomunicações.

O instituto de pesquisas Forrester Research desenvolveu uma

curva de maturidade para a convergência do gerenciamento de
serviços de TI e Telecom na entrega do serviço. Essa curva permite
uma avaliação do nível de maturidade desta convergência. O nível
de maturidade de padronização de serviços prevê uma junção dos
modelos eTOM e ITIL (eTOM and ITIL merge).A proposta de

www.esab.edu.br 125
Gerenciamento de Mudanças convergente entre TI e
telecomunicações é fundamental para suportar os serviços das
empresas de provimento de serviços de comunicação. Por sua
vez, essa abordagem dá suporte à evolução dessas empresas,
que passam de provedoras de circuitos de telecomunicações para
provedoras de comunicação, conteúdo e valor agregado.

ESTUDO COMPLEMENTAR

Para se manter atualizado sobre o assunto tratado nesta

unidade, recomendamos visitar regularmente o site www.
mundoitil.com.br
Para se aprofundar no assunto, indico a leitura do Artigo de
Ana Claudia Vaz Silva e Juliana Carla Carvalho dos santos
(2013) - Governança de TI Itil V3 no gerenciamento de serviços
das empresas.

www.esab.edu.br 126
Na Unidade 6 estudamos sobre Gerenciamento de Recursos Humanos do

Projeto. É uma unidade de grande importância, pois fornece embasamento para

o trabalho em equipe e destaca aspectos que comumente são ignorados por

Gerentes de Projetos, cujo perfil é técnico. Também estudamos sobre a

comunicação e como ela é a chave do bom andamento de praticamente todas

as atividades humanas.

Já na Unidade 7 conseguimos identificar os riscos implícitos na realização de

“Projetos”, o que pode fornecer instrumentos para o Gerente de Projetos

antecipar-se aos fatores negativos que podem afetar a execução das metas

propostas e apoiar-se nos aspectos positivos, minimizando os riscos.

A Unidade 8 nos forneceu condições para visualizarmos mais amplamente os

processos administrativos que envolvem as aquisições do projeto e as partes

interessadas nele.

A Unidade 9 iniciou o assunto Gerência de Projetos com foco em Tecnologia da

Informação, mais propriamente chamado de Governança em TI. A partir dos

processos de aperfeiçoamento e ampliação da tecnologia para negociações

entre os diversos países do mundo globalizado, é que ele vem se fortalecendo e

as empresas começam a enxergar os benefícios da utilização de técnicas

gerenciais para a Área de TI.

Na Unidade 10 nos trouxe conhecimento sobre ITIL, que reafirma as melhores

práticas para a Governança em TI, além de enriquecer o gerenciamento de

projetos.

www.esab.edu.br 127
Eixo 3: Projetos e Governança de TI

Continuando no nosso último êxito temático – Projetos e Governança de TI

- a partir da unidade IX procuramos enfocar metodologias de gerenciamento

de projetos visando à implementação de projetos ligados à área de TI. Na

unidade IX tratamos sobre a Governança em TI – uma preocupação crescente

frente às áreas de gerenciamento de projetos e gerenciamento de TI, e na

unidade X - fornece uma visão geral sobre ITIL – cujas práticas tornam-se

uma ferramenta indispensável na área de serviços e TI.

Agora vamos iniciar o eixo 3 com a unidade XI - aborda o modelo COBIT cuja

similaridade complementa o modelo ITIL estudado nas unidades anteriores e

aponta para a convergência entre ambos.

A unidade XII – detalha os processos para desenvolvimento de sistemas

mais comumente utilizados, sendo complementado na unidade XIII pelo

padrão CMMI, adotado mais recentemente para o mesmo fim.

Finalmente as unidades XIV e XV – Tratam sobre as normas de Qualidade

para o desenvolvimento e comercialização de Projetos de softwares.

www.esab.edu.br 128
COBIT – Uma Visão Geral

É necessário analisar, modificar, implantar e assegurar uma cultura

de controles internos a fim de assegurar a confiabilidade das
informações, realizar diagnósticos de adequação, eliminar
processos redundantes, gerar a confiabilidade de sistemas e
aplicações, manter a segurança das informações disponíveis e
garantir veracidade de dados de saída, evitando variadas fontes
de informações. Enfim, estabelecer um monitoramento contínuo e
rápido alinhado às regras contidas na SOX.

O COBIT é um modo para implementar a governança de TI,

desenvolvido pelo IT Governance Institute – ITGI, criado em 1998
para definir padrões no direcionamento e controle da tecnologia
da informação nas empresas. Uma efetiva governança de TI ajuda
a garantir que a tecnologia da informação apoia efetivamente os
objetivos de negócio (“Business Goals”), otimiza o investimento

www.esab.edu.br 129
de TI e gerencia as oportunidades e ameaças relacionadas a TI.
Basicamente, O Cobit é um framework que deve ser customizado
para empresa, devendo ser usado com outros recursos para
personalizar as melhores práticas para o seu uso específico em
cada empresa.

Estruturalmente, o COBIT consiste em um conjunto (318) de

Objetivos de Controle (ou “Control Objectives” ) para TI, desenhado
para permitir a auditoria. Estes objetivos de controle são as
orientações que descrevem o que deve ser cumprido para
governança de TI.
As práticas de gestão do COBIT são recomendadas pelos peritos
em gestão de TI que ajudam a otimizar os investimentos de TI e
fornecem métricas para avaliação dos resultados, independendo
das plataformas de TI adotadas nas organizações.

Com orientação para o negócio da organização, o modelo fornece

informações detalhadas para gerenciar processos baseados em
objetivos de negócios, auxiliando três audiências distintas:

• Gestores que necessitam avaliar o risco e controlar os

investimentos de TI em uma organização.
• Usuários que precisam ter garantias de que os serviços de
TI, fundamentais para o fornecimento dos seus produtos e
serviços para os clientes internos e externos, estão sendo
bem gerenciados.
• Auditores que podem se apoiar nas recomendações do
COBIT para avaliar o nível da gestão de TI e aconselhar o
controle interno da organização.

www.esab.edu.br 130
 O modelo vem sendo
desenvolvido desde o início da década de noventa, com a primeira
publicação em 1996, focando o controle e análise dos sistemas de
informação. Sua segunda edição, em 1998, ampliou a base de
recursos adicionando o guia prático de implementação e execução.
A terceira edição, já coordenada pelo IT Governance Institute,
introduz as recomendações de gerenciamento de ambientes de TI
dentro do modelo de maturidade de governança.

Cada organização deve compreender seu próprio desempenho e

deve medir seu progresso. O benchmarking com outras
organizações deve fazer parte da estratégia para conseguir os
melhores resultados na utilização dos recursos de TI. As
recomendações de gerenciamento do COBIT, com orientação no
modelo de maturidade em governança, auxiliam os gestores de TI
no cumprimento de seus objetivos alinhados com os objetivos da
organização.

Os modelos de maturidade de governança são usados para o

controle dos processos de TI e fornecem um método eficiente para
classificar o estágio em que a organização se encontra.
Trata-se de um programa de longo prazo que envolve vários
projetos simultâneos, devendo-se priorizar os planos conforme a

www.esab.edu.br 131
estratégia da empresa, procurando executar primeiramente os
planos de maior retorno sobre o investimento em termos de
satisfação para os clientes de

TI ou redução de exposição dos riscos nos processos de TI.

Processos
Nível Descrição Situação
Governça

Não existe a consciência da necessidade

Nível 0 Inexistente
de controles.
Existe o reconhecimento da necessidade
de governança; Não existem padrões; O
Inicial ou monitoramento de TI é implementado de
Nível 1
sobdemanda forma reativa devido a algum incidadente
que tenha causado perda ou dificuldade
para a organização.
Existe uma consciência global das ques-
tões de governança; Atividades de go-
vernança e Indicadores de Performance
Repetível
Nível 2 estão em desenvolvimento; A Genrência
mas intuitivo
identificou medidas de governança; Não
estão implementadas em toda organiza-
ção; São iniciativas isoladas.
Neste nível os processos foram padroni-
zados, documentados e implementados.
Existem um conjunto de indicadores de-
Processos finidos , ligando os resultados medidos
Nível 3
definidos com os direcionadores de performace.
Os procedimentos são medidos, porém
simples, sendo a formalização do que já
existe.

www.esab.edu.br 132
 Neste nível existe o entendimento em
todos os níveis da organização sobre a
necessidade da governança, suportada
através de treinamento formal.
Precessos
Responsabilidades são definidas e mo-
Nível 4 gerenciáveis
nitoradas através de níveis de serviço.
e medidos
Sãoinstituídos, de forma padronizada,
procedimentos de análise de causa de
problemas. Início do processo de melho-
ria contínua.
Neste nível, os riscos e retornos de TI são
identificados e devidamente gerenciados.
Processos Os processos são constantemente refi-
Nível 5
otimizados nados ao nível das melhores práticas de
mercado. A organização, pessoas e pro-
cessos são rapidamente adaptáveis.

Portanto, a implementação do COBIT não obedece necessariamente

a uma linearidade, pois os projetos que o compõe podem ter seus
escopos, prioridades, investimentos, e outras características
alteradas ao longo do tempo, cabendo uma gestão da mudança
ativa que garanta a continuidade do programa, a manutenção dos
resultados e do envolvimento dos gestores de TI por um longo
período.

O relacionamento entre os objetivos de negócio e os objetivos de

TI atendidos pelos processos de TI é efetuado usando uma
ferramenta de Check-up (questionários) em três etapas:

Componentes de Negócio, Sistemas e Infraestrutura.

Desta forma, o resultado da avaliação de maturidade pode ser

mapeado aos objetivos de TI e destes aos objetivos de negócio,

www.esab.edu.br 133
permitindo ao gestor definir o nível de atendimento aos objetivos
e garantindo a mensuração dos retornos de investimento nos
controles aplicados.

www.esab.edu.br 134
O COBIT é um instrumento útil que pode fornecer a uma organização
mecanismos efetivos para a solução de problemas de não
conseguir o serviço desejado. mais balanceados e um processo
SLM mais maduro com o objetivo final de atingir os objetivos de
negócio.

A convergência dos frameworks

COBIT – Aplicações

Entre ITIL, Cobit e PMI, fique com os três. Segundo os especialistas,

de maneira geral é passada a fase de reconhecimento primário
das melhores práticas e as companhias têm olhado com cada vez
mais atenção para o processo de intercâmbio de disciplinas dos
frameworks. “Muitas têm compreendido que talvez não seja
necessário implantar o ITIL por inteiro, mas adotar algumas áreas
que lhes pareçam mais adequadas e mesclá-las com outras do
Cobit, por exemplo. É chegada a fase da convergência na
governança”, comenta Sergio Rubinato Filho, vice-presidente do
itSMF Brasil. ITIL, Cobit, Six Sigma e PMI são apenas alguns dos
mais difundidos exemplos existentes, voltados notadamente para
a governança corporativa de empresas que atuam em ramos
diversos da tecnologia da informação. Entre as empresas de TI,
os modelos são outros, mas a ideia é a mesma: proporcionar ao
cliente (interno ou externo) meios para “enxergar” os resultados,
deficiências e potencialidades de uma estrutura.

www.esab.edu.br 135
Como as melhores práticas já são, ou devem ser, parte integrante
da rotina de uma empresa prestadora de serviços em TI, os
modelos de gestão não interferem diretamente no cotidiano.
Mesmo assim, modelos de produtividade, como o CMM (Capability
Maturity Model), funcionam como “cartão de visitas” do
compromisso de qualidade da empresa que se analisa. Modelos
de Gestão em TI entram na ordem do dia para empresas e
profissionais de tecnologia da informação no mundo inteiro. Os
motivos vão da racionalização de investimentos e demonstração
de resultados ao planejamento de segurança e controle de projetos

As tecnologias da informação se sofisticam para atender requisitos

de integração de dados e processos e para garantir maior
disponibilidade dos sistemas. As transações em tempo real entre
fornecedores e clientes trazem uma nova realidade para as empresas.
O uso da Internet como ferramenta de integração trouxe grandes
vantagens para as empresas, porém o fator segurança ameaça à
integridade das informações. A redução dos custos de comunicação
com o uso da Internet é compensada com os pesados investimentos
com ferramentas de segurança. Para que uma organização de TI
consiga desenvolver e operar as novas tecnologias é necessário um
batalhão de especialistas, um contínuo aperfeiçoamento da equipe e
um controle absoluto dos processos e do budget.

Para administrar essa complexidade multidisciplinar foram criados

vários padrões de gestão de TI, desenvolvidos por organizações
internacionais que fomentam a governança de TI. A partir do
modelo de governança corporativa – COSO – desenvolveu-se um
conjunto de padrões que ajudam as organizações de TI a desenhar
modelos de gestão.

www.esab.edu.br 136
Esses padrões devem ser adotados pelas organizações de TI, em
maior ou menor escala, dependendo da complexidade do negócio.
Quanto mais complexo o negócio mais formal devem ser a
implementação dos processos e seu controle. Se analisarmos as
técnicas e as práticas recomendadas por esses padrões
chegaremos à conclusão que são óbvias para uma boa gestão de
TI, entretanto se as ignorarmos colocaremos em risco a empresa.

A adoção de padrões requer um controle efetivo que avalie

continuamente o desempenho das práticas e das pessoas,
garantindo a eficiência da organização. Um método de
acompanhamento das metas pré-definidas pela organização é o
Balance Scorecard. Esse processo permite criar sinergia entre as
pessoas, assegurar que a estratégia seja implementada e avaliar
o desempenho da organização.

Sumarizando, para um CIO – Chief Information Officer - adotar

uma gestão eficiente de TI ele terá que focar em quatro dimensões:
Pessoas, Projetos, Processos e Métricas. Cada dimensão possui
um conjunto de práticas e técnicas para assegurar a eficiência da
gestão.

A dimensão mais importante no processo é a que envolve as

pessoas. Nessa dimensão é onde as habilidades do CIO serão
colocadas à prova. Aqui é onde se investe mais tempo, procurando
alinhar cada membro da equipe aos objetivos da organização e no
aperfeiçoamento das habilidades técnicas e de comportamento.
Além, de administrar os conflitos internos.

www.esab.edu.br 137
 ESTUDO COMPLEMENTAR

O artigo de Batista et al versa sobre a governança da tecnologia da

informação na atualidade e a importância da adoção de modelos de
melhores práticas nas organizações. Esta leitura te ajudará no
processo de construção de ensino e aprendizagem.Para se
aprofundar no assunto, indico a leitura do artigo de Andressa
Munhoz, Sonia Rosangela, Vander Batistoni, Valter Lima, Joana
Mata, Izabellitta Melo e Rodrigo Tamae - Governança em TI- Cobit
e Itil.

www.esab.edu.br 138
Aspectos Técnicos

No desenvolvimento de um sistema de informação computadorizado

geralmente o gerente de projeto faz frente a alguns problemas
técnicos que, se não forem previstos quando do início do projeto
e bem gerenciados, fatalmente levarão ao insucesso do projeto.

Evolução Tecnológica

Um dos problemas na implementação de sistemas é a questão de

absorver e implantar inovações tecnológicas de “hardware” e
“software”.

Novas tecnologias ou inovações devem ser introduzidas na

organização de forma administrada, com fases e etapas bem
definidas, envolvendo um conjunto de especialistas, tais como o
pessoal de suporte técnico, desenvolvimento, de produção,
planejamento, etc.

Projetos de sistemas que incorporam inovações de “hardware” e

“software” ainda não assimiladas totalmente pela equipe de
desenvolvimento, fatalmente não atingirão seus objetivos, em
termos de prazo, qualidade e custos.

www.esab.edu.br 139
Especificação do Sistema

“Definir o problema é o problema”. Especificar um sistema de

informação é uma ação que requer intensa interação entre os
analistas de sistemas e os usuários, ou seja, uma interação entre
pessoas com formação, objetivos e concepções de mundo,
realidade, muitas vezes divergentes.

As pessoas aprendem por agregação de conhecimento, por

tentativa e erro, num ciclo de aprendizagem evolutivo. O ato de
especificar um sistema requer a agregação de conhecimentos,
num ciclo evolutivo, tanto da parte do analista como do usuário,
até que a solução para um determinado problema seja satisfatória.

Entretanto, a realidade não é estática, seria muito simples se

assim o fosse, pois não haveria problemas de revisão das
especificações, que sempre ocorrem no desenvolvimento de
sistemas e que se constituem num dos fatores cruciais de atraso
em projetos.

Conforme este modelo, a aprendizagem pode ser visualizada

como um ciclo de estágios sucessivos. Experiências concreta e
imediata formam a base para observação e reflexão.

Estas observações são, então, assimiladas numa teoria da qual

novas implicações para a ação podem ser deduzidas.

Se observarmos com atenção este modelo, é fácil chegarmos à

conclusão dos motivos pelos quais a especificação de um sistema
é uma tarefa que requer grande habilidade de abstração e talvez
paciência.

www.esab.edu.br 140
A rigor, o desenvolvimento de um sistema de informação inicia
somente após a sua implantação, pois é neste momento que o
usuário terá sua experiência concreta, iniciando um novo ciclo de
aprendizagem.

Metodologias Inadequadas

Hoje assistimos a um esforço muito grande por parte de empresas

usuárias e de laboratórios de pesquisa (universidades, software-
house) para reduzir o hiato entre o grande avanço verificado, nesta
década, por parte do hardware em relação ao software.

No Brasil inicia-se, ainda de forma tímida, a utilização de

ferramentas automatizadas para a automação do desenvolvimento
de sistemas. Porém, a grande maioria das organizações não
utiliza, ainda, essas ferramentas. Em algumas, somente agora é
que as técnicas de análise estruturada e projeto estruturado estão
sendo assimiladas e postas efetivamente em prática.

Outro aspecto a considerar nesta discussão é que inexistem

diferenciações em função dos diferentes tipos de sistemas, ou
seja, geralmente são utilizadas técnicas e metodologias como se
fossem “receita de bolo” e panacéia para qualquer tipo de problema
ou sistema.

Ao considerarmos esta questão, devemos utilizar técnicas,

metodologias e abordagens diferenciadas para sistemas com
características também diferenciadas.

www.esab.edu.br 141
Ao iniciar um Projeto de Sistemas, o gerente do projeto deve
selecionar, criteriosamente, quais técnicas utilizará em função das
características do sistema que será desenvolvido.

Restrições de Hardware e Software

Frequentemente, ao planejarmos e especificarmos um sistema,

não avaliamos as condições de hardware e software existentes na
instalação. É comum vermos sistemas que, quando implantados,
degradam o hardware, a rede de teleprocessamento, se esgotam
em termos de expansão e assim sucessivamente.

Lembremo-nos que os usuários finais não estão preocupados com

questões técnicas, eles querem é resultado, que é a principal
missão do gerente de projeto. Se você é um gerente de projeto,
avalie, antes de iniciar o projeto, as condições de hardware e
software na instalação e faça somente o que for factível e viável.

Lembre-se que um objetivo maior pode ser alcançado por etapas

sucessivas.

Dificuldades de Aferir Progresso

Em projetos de sistemas, pode-se traduzir o tempo transcorrido

em custos realizados, mas não em progresso realizado.

Num projeto de engenharia, por exemplo, geralmente o esforço

despendido numa tarefa tem uma relação linear com o progresso
da tarefa. Se estimarmos em dois homens - mês uma tarefa e já
gastamos a metade, ou um homem- mês, supomos que

www.esab.edu.br 142
completamos a metade daquela tarefa. Em projetos de sistemas
sofremos a síndrome dos 99%. Quantas vezes já ouvimos dos
analistas e programadores: “só faltam 10% para concluir o sistema”,
ou “agora está quase tudo ok”.

Mas o que significam esses 10%? Serão 10% dos programas?

Serão 10% da codificação? E o tudo ok refere-se também ao
treinamento dos usuários e operadores, preparação da
documentação?

Às vezes nos deparamos com o fato de que esses 10% são, na

realidade, os programas ou tarefas mais pesados e complexos.

Ao aproximarmo-nos do fim
de um projeto, mesmo bem
gerenciado, sempre teremos
problemas de teste individual
de programa, teste integrado
do sistema, manutenções corretivas, novas solicitações por parte
dos usuários em termos de relatórios, etc., o que significa que
atingimos os 99%. A decisão inteligente é saber o momento
adequado para encerrarmos o projeto e passarmos o 1% restante
para a manutenção de sistemas.

Conflitos de Objetivos

Seria muito conveniente se pudéssemos estabelecer um objetivo

simples para um sistema de informação, de forma que, ao atingi-
lo, todos os desafios do processo estivessem resolvidos.

www.esab.edu.br 143
Infelizmente, a construção de um sistema não é tão simples. Um
grande número de desafios e objetivos estão sempre em conflito,
tais como desempenho do software, eficiência dos programas,
confiabilidade, facilidade de uso e manutenção. Se concentrarmos
nossa atenção somente em um objetivo, outros 05 provavelmente
sofrerão. Um bom exemplo deste conflito de objetivos é
proporcionado pelo experimento de WEINBERG.-.SCHULMAN
(25). Neste experimento, foram formadas cinco equipes de
programação para executar a mesma tarefa, porém, com objetivos
diferentes.

Os objetivos foram assim definidos:

• Completar a tarefa com o menor esforço possível;

• Minimizar o número de instruções;
• Minimizar a quantidade de memória requerida pelo programa;
• Produzir o programa mais inteligível;
• Produzir a saída mais inteligível.

A Tabela, a seguir, mostra os resultados do experimento. As

conclusões do experimento foram:

• Cada equipe atingiu primeiramente (e em segundo lugar,

em um dos casos) objetivo que lhe tinha sido atribuído
explicitamente;

• Nenhuma equipe atingiu de forma homogênea todos os

objetivos;

www.esab.edu.br 144
 • As equipes de desenvolvimento de software possuem um
sentimento bastante elevado de motivações técnicas;

• Diferentes objetivos no desenvolvimento de software

podem, na prática, conduzir a conflitos entre si;

• O desenvolvimento de software requer continuo ajuste/

resolução de objetivos importantes e conflitantes entre si.

TABELA 1 - EXPERIMENTO DE WEINBERG-SHULMAN

RESULTADO DE DESEMPENHO
Objetivo
Intelig.
da equipe: Esforço p/ Nº de Memória Intelig. do
da
Otimizar Completar Instruções Requerida program.
Saída
Esforço para
1 4 4 5 3
Completar
Nº de
2-3 1 2 3 5
Instruções
Memória 5 2 1 4 4
Requerida
Inteligibilidade
4 3 3 2 2
do Programa
Inteligibilidade
2-3 5 5 1 1
de Saída
Cultura das Organizações

Cremos que quase todos os profissionais experientes de informática

já perceberam isto, ou seja, quanto mais conscientes e participativos
são a alta administração e os usuários, de forma geral, no processo
de implantação de projetos, mais facilitada fica a tarefa de gerenciar
projetos.

www.esab.edu.br 145
 Todavia, esta “cultura” não nasce do dia para a noite, ela evolui,
conforme NOLAN (19), em estágios. Richard Nolan, pesquisando
instalações na América do Norte, concluiu que a evolução da
informática numa organização ocorre em estágios aos quais ele
denominou de INICIAÇÃO (estágio I), CONTÁGIO (estágio II),
CONTROLE (estágio III) e INTEGRAÇÃO (estágio IV). A figura a
seguir representa esta conclusão.

Pórtifolio de “Mecânização” Proliferação Consolidação Sistemas

Aplicações Gerênciais
Processos de Crescimento

Redução de
Custos Aplicações On-
line
Organização
das Funções Aprendizado Reorientação Atendimento
de Tecnológico Funcional à Média Estratificação e
Informática Gerência Adaptação

Planejamento
e Controle das Orçamento Orçamento Controles
atividades de Flexível Muito Flexível Formalizados Planejamento
Informática Gerêncial
e Controle
Gerêncial
“Por fora Do “Entusiasmado” Forçado a Ser
Papel dos Jogo” “Videomania” rsponsável Efetivamente
usuários “PapelMania” Responsável

I II III IV INTEGRAÇÃO
INÍCIO CONTÁGIO CONTROLE MATTURIDADE

Um Projeto de Sistemas é um esforço no sentido de construir um

sistema de informação ou de implantar algum serviço/atividade de
informatização. Na verdade, um Projeto de Sistemas é a junção de
OBJETIVOS + ATIVIDADES + PRAZOS + RECURSOS
ENVOLVIDOS + RISCOS E INCERTEZAS (às vezes mais riscos e
incertezas que objetivos).

www.esab.edu.br 146
Um Projeto de Sistemas é uma forma de organização do trabalho
que apresenta as seguintes características:

• É um esforço finito, com início e fim e a cujo término pretende-

se a entrega, a geração ou a finalização de um determinado
produto ou serviço, definido a priori;
• É um esforço que pode ser subdividido em unidades de
trabalho (fases, etapas, atividades) que ocorrem em uma
sequência predeterminada;
• O objetivo, a alocação de recursos e o progresso realizado
podem ser monitorados e avaliados.

Metodologia e Técnica

Uma metodologia é um conjunto de conceitos, normas e regras

destinadas a orientar um processo qualquer de trabalho.
Geralmente se baseia numa sequência (ou “Roteiro”) de
atividades destinadas a gerar produtos predeterminados e de
formato padronizado.

Uma metodologia pode englobar diversas técnicas. Sua ênfase é

sobre atividades, etapas, recursos, prazos, sob a ótica do
controle gerencial. As Metodologias de Desenvolvimento de
Sistemas, especificamente, além de incorporarem estes
conceitos, apresentam características adicionais:

• São baseadas no “ciclo de vida” de sistemas;

• Permitem aos projetos de sistemas serem descritos sob a
forma de uma “rede de precedência”;
• Podem englobar técnicas de modelagem de dados
(Diagramas Entidades x Relacionamento), análise

www.esab.edu.br 147
 estruturada (Gane & Sarson, Tom de Marco), projeto
estruturado (Warnier, Jackson etc.);
• Apresentam uma estrutura funcional sob a qual um projeto
pode ser subdividido em fases, atividades e etapas;
• Existem produtos-padrão, gerados ao final de cada fase
típica da metodologia.

Técnicas, por sua vez, são um conjunto de procedimentos

destinados à obtenção de um nível preestabelecido de
conhecimento sobre um problema ou uma situação especifica.
Geralmente visa a determinar, de forma mais rigorosa, o “conteúdo”
de determinados produtos ou estados de conhecimento. Sua
ênfase é sobre produtos.

Como podemos observar por essas definições, não se deve

confundir metodologia de desenvolvimento de sistemas com
técnicas de análise de sistemas.

A primeira constitui-se no principal instrumento de trabalho para o

gerente de projeto, enquanto que as técnicas de análise são
instrumentos que auxiliam a construção do software e que têm
relação direta com a questão da “Qualidade”.

A metodologia de desenvolvimento de sistemas pode compreender

abordagens de desenvolvimento distintas, cada qual, apropriada
a uma determinada situação em termos de características do
ambiente no qual o projeto será desenvolvido.

Além do mais, a metodologia de desenvolvimento de sistemas

pode ser orientada tanto para a construção de um software como
produto ou como serviço.

www.esab.edu.br 148
O software, considerado como produto, ao ser desenvolvido, não
considera o ambiente organizacional no qual será implantado e
operado. Neste caso,
geralmente, devem-se utilizar
conceitos de “Software
Engineering” que, de acordo
com BARRY BOREM (1), é a
aplicação da ciência e da
matemática pela qual as capacidades dos equipamentos
computacionais tornam-se úteis ao homem através de programas
de computador, procedimentos e da documentação associada.

O software considerado como um dos serviços prestados pelo

CPD aos demais órgãos de uma empresa, apesar de também
poder usar os conceitos de “Software Engineering” (em alguns
casos até deve), é substancialmente afetado pelo ambiente
organizacional que operará.

ESTUDO COMPLEMENTAR

Para ficar por dentro do que está acontecendo em Engenharia de

Software fica uma dica super legal: leia a Revista Engenharia de
Software Magazine (http://www.devmedia.com.br/revista-
engenharia-de-software-magazine) . Você encontrará
inúmeros artigos e ficará antenado com o que está acontecendo na
área.

www.esab.edu.br 149
CMMI - Capability Maturity Model Integrated

Apesar das metodologias de sistemas descritas na Unidade

anterior, há algum tempo, a produção de software era algo feito
sem que os processos fossem bem definidos e sem controle sobre
possíveis manutenções ou agregação de módulos aos mesmos.
Com isto os sistemas antigos tinham um ciclo de vida muito curto
e um custo muito alto.

À medida que a complexidade dos projetos aumentava, novas

tecnologias foram surgindo, e uma necessidade de mudança nos
processos de produção foi percebida por empresas que tinham
custos altíssimos no desenvolvimento de softwares. Nesta
unidade, pretendemos tratar do CMMI – que visa aprimorar esses
processos de modo seguro e organizado.

www.esab.edu.br 150
CMMI – Questão de necessidade

Buscando aprimorar o processo de desenvolvimento de projetos

nas áreas de tecnologia e software ou sistemas, o CMMI - Capability
Maturity Model Integrated que verifica o nível de maturidade da
empresa em relação
ao seu processo.
Esse modelo foi
baseado em
tecnologias de
Engenharia de
Software como o
RUP - um domínio
específico da
computação que
tinha como suporte a avaliação de uma empresa de desenvolvimento
de sistemas.

Esse modelo evoluiu em conjunto com as novas tecnologias

surgidas na computação, e se adequava às necessidades criadas
por esta evolução até atingir o CMMI (Capability Mature Model
Integration) que abrange um conjunto ainda maior de requisitos.

O CMMI define áreas de processo focadas, especialmente nas

áreas de processo Definição do Processo Organizacional (OPD) e
Foco no Processo Organizacional (OPF). O modelo compreende
objetivos e práticas específicas para estruturação da melhoria de
processo e da própria definição do processo da organização.

www.esab.edu.br 151
A área de processo OPD concentra-se na definição e documentação
do processo da organização. Segundo esta área, o processo da
organização é composto de ativos, organizados de várias formas,
que incluem descrições de ciclos de vida, descrições de processos,
um simples repositório contendo medições e documentações de
processo.

Podendo ser considerada uma área complementar a OPD, a área

de processo OPF define práticas para a estruturação da melhoria
de processo na organização, através do estabelecimento do grupo
responsável pelo processo de software entre outros.

Adicionalmente, todas as áreas de processos definidas pelo

modelo possuem práticas genéricas relacionadas com a definição
e gestão da área de processo em si.

Pode ser considerado um guia de boas práticas, que deverão

influenciar a maneira pela qual uma organização desenvolve seus
produtos e serviços. Funciona como conjunto de requisitos para
processos. O CMMI fornece um conjunto robusto de orientações,
que se bem interpretadas e adaptadas respeitando-se o contexto
de cada empresa, levam a melhorar a qualidade, produtividade e
eficácia das organizações que os aplicam.

Organizações também necessitam planejar a absorção de novos

conceitos, aprendê-los, interiorizá-los e praticá-los. Isso acontece
paulatinamente. E é por esse motivo que o CMMI tem, em uma de
suas representações, o conceito de “estágios”, ou de “níveis de
maturidade”. Os níveis de maturidade do CMMI são 5. Cada nível
demonstra o estágio do programa de melhoria de qualidade no
qual a organização se encontra:

www.esab.edu.br 152
 1 – INICIAL - Caracterizado pela imprevisibilidade – quando uma
organização não tem seus processos sob controle. A variação de
resultados é enorme, pela informalidade.

2 – GERENCIADO - Caracterizado pela gestão básica de

projetos – requisitos são gerenciados e os processos são planejados,
medidos e controlados.

3 – DEFINIDO - A organização aproveita suas boas práticas.

A retenção do conhecimento se dá a partir do aproveitamento
sistemático de boas experiências, e seu uso em projetos
subsequentes. A imprevisibilidade diminui pelo uso de experiências
que anteriormente foram bem-sucedidas.

4 – GERENCIADO QUANTITATIVAMENTE - O conhecimento

quantitativo dos processos organizacionais permite que o nível de
previsibilidade aumente e a variação dos resultados diminua. O foco
aqui é o estabelecimento de objetivos quantitativos para a qualidade
e a performance dos processos, e seu uso para a gestão eficaz.

5 – OTIMIZADO - O conceito de “inovação” e “melhoria

contínua” está enraizado na organização. Com base no conhecimento
quantitativo e baseado em estatística (nível 4), identificam-se
oportunidades de melhorias nos negócios que poderão ser
contempladas pela inovação.

Nesta fase, as organizações terão os instrumentos para melhorar

continuamente. Portanto, a diminuição da variação no uso dos
processos organizacionais, e o consequente aumento da visibilidade
gerencial são dois dos aspectos mais importantes que uma empresa
pode vislumbrar como resultado ao se implementar os conceitos do
CMMI.

www.esab.edu.br 153
É importante ressaltar, que não basta saber qual o objetivo a ser
alcançado; é necessário traçar o caminho a ser percorrido para
atingir o objetivo. Nesse sentido, a metodologia CMMI também
auxilia, dividindo cada estágio em áreas de processo e para cada
uma delas são definidos dois conjuntos de metas: as específicas
e as genéricas.

A essas metas, a definição do modelo recomenda práticas

genéricas divididas em um conjunto de características comuns
que por sua vez se divide em quatro categorias. São elas:

Categoria Caracteristicas

Comprometimento com a Agrupa práticas relacionadas à definição

Execução responsabilidades, descrevendo ações para

assegurar que o processo se estabeleça e

seja duradouro;

Habilitação para execução Agrupa práticas contendo pré-condições para

o projeto, de forma a implementação processo;

Direcionamento a Agrupa práticas relacionadas ao

implementação gerenciamento do desempenho do processo;

Verificação da implementação Agrupa práticas para revisão junto à alta

gerência e avaliação objetiva da conformidade

com processos, procedimentos e padrões.

Estas categorias, servem para direcionar as ações de forma a

garantir que o ciclo de evolução seja completado, possibilitando a
implementação de uma evolução contínua dos processos e do
produto como um todo.

“A metodologia CMMI é um guia para as pessoas de TI que já

estão cansadas de agir como bombeiros, trabalhando arduamente,

www.esab.edu.br 154
 e sem encontrar nenhum reconhecimento pelos usuários. Não é
de forma alguma um processo simples de ser realizado, exige
uma mudança de cultura voltada para o planejamento, a qualidade
e o controle dos processos de desenvolvimento dos softwares. Os
tópicos descritos acima são os passos iniciais a serem tomados
pelas empresas que desejam implementar uma cultura na Gestão
de Desenvolvimento. ”7
NTAR

7
Adilson Moreira de Souza – Analista de Sistemas – UNIMEP/
Fundação Getúlio Vargas

www.esab.edu.br 155
Qualidade em Projetos de Sistemas

O que é um Sistema de Qualidade ?

Aplicar os princípios da qualidade de software é o início

para o sucesso. O termo “sistema de qualidade” é utilizado
internacionalmente para descrever um processo na qual garanta
e demonstre a qualidade dos produtos e serviços ofertados pela
empresa.

A padronização ISO 9000 define e descreve o que é requerido ou

satisfatório em um sistema de qualidade contendo componentes
de desenho e desenvolvimento. As padronizações existentes para
garantir a qualidade de software serão estudadas mais à frente
neste trabalho.

Além das padronizações ISO, muitas outras organizações

nacionais e internacionais promovem padrões que descrevem
sistemas de qualidade para serem aplicados em sistemas de
desenvolvimento e suporte em certas circunstâncias, a exemplificar
o CMM (Code of maturity model).

Às vezes, o termo “gerenciamento de sistemas de qualidade”

enfatiza as necessidades do processo de qualidade para serem

www.esab.edu.br 156
gerenciados, de modo a garantir que continue de forma correta e
eficiente.

Tão importante quanto as práticas e ferramentas é o status da

pessoa que as usa. A qualidade deve garantir que as pessoas
envolvidas devem ter suas habilidades certas para cada tipo de
trabalho, de uma maneira profissional. Se as pessoas necessitam
de treinamento, então a empresa deverá treinar os seus usuários.
Deve-se garantir que as pessoas entendam suas responsabilidades
e como seu trabalho se relaciona com outras pessoas.
Um sistema de qualidade dá grande ênfase à correção de erros.
É muito útil corrigir os erros durante o início do ciclo de vida do
sistema.

Melhor ainda, é anular erros antes mesmo deles serem gerados.

Um sistema de qualidade de sucesso inclui maneiras de registrar
os erros para determinar as causas e agir de acordo com o erro
eliminando suas causas.

Em suma, um sistema de qualidade é tudo que o gerenciamento

utiliza para garantir e demonstrar a qualidade do software e do
serviço de suporte. O sistema de qualidade é o trabalho completo,
incluindo política, procedimentos, ferramentas e recursos, incluindo
humano e tecnológico.

Certificação da qualidade

Um aspecto interessante da qualidade é que não basta que ela

exista. Ela deve ser reconhecida pelo cliente. Por causa disso, é
necessário que exista algum tipo de certificação oficial , emitida

www.esab.edu.br 157
com base em um padrão. Alguns tipos de certificados são bastante
conhecidos, como:

• O selo do SIF de inspeção da carne

• O selo da ABIC nos pacotes de café
• O certificado da Secretaria de Saúde para restaurantes
(classe “A” são os melhores)
• A classificação em estrelas dos hotéis (hotéis com cinco
estrelas são ótimos).
• Os certificados de qualidade da série ISO-9000

Ouvimos muitas propagandas de empresas falando de sua

certificação ISO-9000. Isto nada mais é do que um padrão de
qualidade (reconhecido mundialmente) pelo qual esta empresa foi
avaliada e julgada. Para que seja possível realizar uma avaliação
e um julgamento, é necessário haver um padrão ou norma. Existem
alguns organismos normalizadores reconhecidos mundialmente:

• ISO - International Organization for Standardization

• IEEE - Instituto de Engenharia Elétrica e Eletrônica
• ABNT - Associação Brasileira de Normas Técnicas
A norma ISO-9000, por exemplo, foi criada pela ISO para permitir
que todas as empresas do mundo possam avaliar e julgar sua
qualidade. Existindo um padrão único mundial, uma empresa do
Brasil, mesmo não tendo nenhum contato com uma outra empresa
na Europa, pode garantir a ela a qualidade de seu trabalho.

A Certificação em uma norma ou padrão é a emissão de um

documento oficial indicando a conformidade com uma determinada
norma ou padrão. É claro que, antes da emissão do certificado, é
preciso realizar todo um processo de avaliação e julgamento de

www.esab.edu.br 158
acordo com uma determinada norma. Embora uma empresa
possa autoavaliar-se ou ser avaliada por seus próprios clientes, o
termo Certificação costuma ser aplicado apenas quando efetuado
por uma empresa independente e idônea, normalmente
especializada neste tipo de trabalho.

No Brasil, o INMETRO é o órgão do governo responsável pelo

credenciamento destas instituições que realizam a certificação de
sistemas de qualidade.

Qualidade Produto x Qualidade Processo

Uma das evoluções mais importantes no estudo da qualidade

está em notar que a qualidade do produto é algo bom, mas que
qualidade do processo de produção é ainda mais importante.
No caso do prato de comida, por exemplo, você pode dizer mais
sobre a qualidade observando como o prato foi preparado do
que analisando o produto final.

Afinal, você não consegue ter certeza da higiene ou o valor

nutricional apenas comendo o prato.

www.esab.edu.br 159
Esta descoberta aconteceu durante a própria evolução dos
conceitos de qualidade, ao longo dos anos. Observe na tabela
abaixo como aconteceu esta evolução:
1.Inspeção pós-produção Avalia o produto final, depois de pronto 1900

2.Controle estatístico da 1940

Avalia os subprodutos das etapas de
produção produção

3.Procedimento de 1950

produção Avalia todo o procedimento de produção

4.Educação das pessoas Avalia as pessoas envolvidas no processo 1960

5.Otimização dos 1970

processos Avalia e otimiza cada processo

6.Projeto robusto Avalia o projeto de produção 1980

7.Engenharia simultânea Avalia a própria concepção do produto 1990

Hoje em dia, você pode consultar normas e padrões tanto para

produtos quanto para processos. Obviamente, os certificados
mais valiosos são aqueles que certificam o processo de
produção de um produto e não aqueles que simplesmente
certificam o produto. Entretanto, é comum encontrar empresas
que perseguem os dois tipos de padrão de qualidade.

Qualidade em Projetos de Sistemas

Apesar das metodologias de sistemas descritas na Unidade

anterior, há algum tempo atrás, a produção de software era algo
feito sem que os processos fossem bem definidos e sem controle
sobre possíveis manutenções ou agregação de módulos aos
mesmos. Com isto os sistemas antigos tinham um ciclo de vida
muito curto e um custo muito alto.

www.esab.edu.br 160
Agora que já vimos o que é qualidade e como ela pode ser avaliada,
vamos tentar aplicar estes conceitos aos produtos de software e ao
processo de desenvolvimento de software.
Inicialmente, vamos encontrar um grande problema: muitas pessoas
acham que criar programas é uma arte que não pode seguir regras,
normas ou padrões. Isto acontece principalmente porque:
• Produtos de software são complexos, até mais do que o
hardware onde executam.
• Software não tem produção em série. Seu custo está no
projeto e desenvolvimento.
• Software não se desgasta e nem se modifica com o uso.
• Software é invisível. Sua representação em gráficos e
diagramas não é precisa.
• A Engenharia de Software ainda não está madura, é uma
tecnologia em evolução.
• Não há um acordo “pleno” entre os profissionais da área
sobre o que é Qualidade de Software.

Apesar de tudo isso é necessário entender que o problema não

está no Software em si, mas na forma como as pessoas têm
desenvolvido software até os dias de hoje. Precisamos nos
conscientizar que necessitamos aplicar na indústria de software
os conceitos de qualidade, urgentemente.

Atualmente, muitas instituições se preocupam em criar normas

para permitir a correta avaliação de qualidade tanto de produtos
de software quanto de processos de desenvolvimento de
software. Apenas para ter uma visão geral, observe o quadro a
seguir, com as principais normas nacionais e internacionais nesta
área:

www.esab.edu.br 161
 Norma Comentário

ISO 9126 Características da qualidade de produtos de software.

NBR 13596 Versão brasileira da ISO 9126

ISO 14598 Guias para a avaliação de produtos de software, baseados na

utilização prática da norma ISO 9126

ISO 12119 Características de qualidade de pacotes de software (software

de prateleira, vendido com um produto embalado)

IEEE Standard for Software Quality Metrics Methodology (produto de

P1061 software)

Software Life Cycle Process. Norma para a qualidade do

ISO 12207 processo de desenvolvimento de software.

Sistemas de qualidade - Modelo para garantia de qualidade em

NBR ISO Projeto, Desenvolvimento, Instalação e Assistência Técnica
9001 (processo)

Gestão de qualidade e garantia de qualidade. Aplicação da

NBR ISO norma ISO 9000 para o processo de desenvolvimento de
9000-3 software

NBR ISO

10011 Auditoria de Sistemas de Qualidade (processo)

CMM Capability Maturity Model. Modelo da SEI (Instituto de

Engenharia de Software do Departamento de Defesa dos EEUU)
para avaliação da qualidade do processo de desenvolvimento de
software. Não é uma norma ISO, mas é muito bem aceita no
mercado.

SPICE ISO Projeto da ISO/IEC para avaliação de processo de

desenvolvimento de software. Ainda não é uma norma oficial
15504 ISO, mas o processo está em andamento.

Qualidade de Produtos de Software - ISO 9126

Quando se pensa em qualidade de um “produto físico”, é fácil

imaginar padrões de comparação, provavelmente ligado às
dimensões do produto ou alguma outra característica física.
Quando se trata de software, como podemos definir exatamente
o que é a qualidade? Parece difícil...

www.esab.edu.br 162
 Felizmente, para nós, a ISO (Organização Internacional de
Padrões) já pensou bastante sobre o assunto. O suficiente
para publicar uma norma que representa a atual padronização
mundial para a qualidade de produtos de software. Esta norma
chama-se ISO/IEC 9126 e foi publicada em 1991. Ela é uma
das mais antigas da área de qualidade de software e já possui
sua tradução para o Brasil, publicada em agosto de 1996 como
NBR 13596.

Mas, afinal de contas, o que está escrito nesta norma ISO/IEC

9126 ou na NBR 13596? Bem, estas normas listam o conjunto
de características que devem ser verificadas em um software
para que ele seja considerado um “software de qualidade”. São
seis grandes grupos de características; cada um dividido em
algumas subcaracterísticas.

Os nomes dados pelo ISO/IEC para as características e

subcaracterísticas são um pouco complexos (para dizer a
verdade, acho até que os próprios termos «características» e
«subcaracterísticas” são mais complexos que o necessário).
Entretanto, uma pessoa que trabalha com software não terá
dificuldade em entendê-las. Exemplo:
Característica Subcaracterística Pergunta chave para a
subcaracterística

Adequação Propõe-se a fazer o que é apropriado?

Acurácia Faz o que foi proposto de forma

correta?

Funcionalidade Interoperbilidade Interage com os sistemas

(satisfaz as especificados?
necessidades?)
Conformidade Está de acordo com as normas, leis,
etc.?

Segurança de Evita acesso não autorizado aos

acesso dados?

www.esab.edu.br 163
 Confiabilidade Maturidade Com que frequência apresenta falhas?
(é imune a
falhas?) Tolerância a falhas Ocorrendo falhas, como ele reage?

Recuperabilidade É capaz de recuperar dados em caso

de falha?

Usabilidade Intelegibilidade É fácil entender o conceito e a

(é fácil de usar?) aplicação?

Apreensibilidade É fácil aprender a usar?

Operacionalidade É fácil de operar e controlar?

Tempo Qual é o tempo de resposta, a

Eficiência velocidade de execução?
(é rápido e
“enxuto”?) Recursos Quanto recurso usa? Durante quanto
tempo?

Analisabilidade É fácil de encontrar uma falha, quando

ocorre?

Manutenibilidade Modificabilidade É fácil modificar e adaptar?

(é fácil de
modificar?) Estabilidade Há grande risco quando se faz
alterações?

Testabilidade É fácil testar quando se faz

alterações?

Adaptabilidade É fácil adaptar a outros ambientes?

Capac. para ser É fácil instalar em outros ambientes?

Portabilidade instalado
(é fácil de usar
em outro Conformidade Está de acordo com padrões de
ambiente?) portabilidade?

Capac. Para É fácil usar para substituir outro?

substituir

Métricas De Software

Embora a atual norma ISO 9126/NBR 13596 e numere as

características e subcaracterísticas um software, ela ainda não
define como dar uma nota a um software em cada um destes
itens. Se você não está familiarizado com o processo de avaliação
de software, pode ter dificuldades em tentar utilizar a norma. Se

www.esab.edu.br 164
 você pretende avaliar um software segundo esta norma, deve
tentar atribuir valores (como se fossem notas ou conceitos) a
cada uma das subcaracterísticas.

Algumas características podem ser realmente medidas, como o

tempo de execução de um programa, número de linhas de código,
número de erros encontrados em uma sessão de teste ou o tempo
médio entre falhas. Nestes casos, é possível utilizar uma técnica,
uma ferramenta ou um software para realizar medições. Em outros
casos, a característica é tão subjetiva que não existe nenhuma
forma óbvia de medi-la.

Ficam, portanto, as questões: como dar uma nota, em valor

numérico, a uma característica inteiramente subjetiva? O que
representa, por exemplo, uma “nota 10” em termos de “Segurança
de Acesso”? Quando se pode dizer que a “Inteligibilidade” de um
software pode ser considerada “satisfatória”? Criou-se, então,
uma área de estudo à parte dentro da Qualidade de Software
conhecida como Métricas de Software . O que se pretende fazer é
definir, de forma precisa, como medir numericamente uma
determinada característica.

Para avaliar uma determinada subcaracterística subjetiva de forma

simplificada, por exemplo, você pode criar uma série de perguntas
do tipo “sim ou não”. Crie as perguntas de forma tal que as
respostas “sim” sejam aquelas que indicam uma melhor nota para
a característica. Depois que as perguntas estiverem prontas basta
avaliar o software, respondendo a cada pergunta. Se você
conseguir listar 10 perguntas e o software obtiver uma resposta
“sim” em 8 delas, terá obtido um valor de 80% nesta característica.

www.esab.edu.br 165
Exemplo:
Pergunta Sim Não

A interface de operação do software é intuitiva ?

Obviamente, a técnica acima não é muito eficiente. Para melhorá-

la, entretanto, você pode garantir um número mínimo perguntas
para cada característica. Além disso, algumas perguntas mais
importantes podem ter pesos maiores. É possível, ainda, criar
perguntas do tipo ABCDE, onde cada resposta indicaria um escore
diferenciado. Alguns estudiosos sugerem formas diferentes de
medir uma característica, baseada em conceitos do tipo “não
satisfaz”, “satisfaz parcialmente”, “satisfaz totalmente” e “excede
os padrões”. Estes conceitos, embora pareçam muito subjetivos
não deixam de ser uma forma eficiente de medir uma característica.

Exemplo:
Pergunta Satisfaz Satisfaz Não

Totalmente Parcialmente Satisfaz

Ao requisitar o sistema de

ajuda do software, ele:

Em todos os casos, um fato fica claro: nada ajuda mais a avaliar

características de um software do que um avaliador experiente
que já realizou esta tarefa diversas vezes e em diversas empresas
diferentes. Afinal, medir é comparar com padrões e um avaliador
experiente terá maior sensibilidade do que um profissional que
acaba de ler uma norma pela primeira vez.

www.esab.edu.br 166
O estudo da Qualidade do Processo de Software é uma área
ligada diretamente à Engenharia de Software. O estudo de um
ajuda a entender e aprimorar o outro. Em ambas disciplinas
estuda-se modelos do processo de desenvolvimento de software.
Estes modelos são uma tentativa de explicar em detalhes como
se desenvolve um software, quais são as etapas envolvidas. É
necessário compreender cada pequena tarefa envolvida no
desenvolvimento.

A SÉRIE ISO 9000 :

Esta série é um conjunto de normas da ISO que define padrões

para garantia e gerenciamento da qualidade. Veja algumas destas
normas abaixo:
Norma Comentário

Modelo para garantia da qualidade em projeto, desenvolvimento,

ISO 9001 produção,
instalação e assistência técnica.

ISO 9002 Modelo para garantia da qualidade em produção e instalação

ISO 9003 Modelo para garantia da qualidade em inspeção e ensaios finais

ISO 9000-1 Diretrizes para escolher entre as normas ISO 9001, 9002 e 9003

Entre as normas 9001, 9002 e 9003, a primeira é a que mais se

adequa ao desenvolvimento e manutenção de software. Como
toda norma deste grupo, ela é usada para garantir que um
fornecedor atende aos requisitos especificados nos diversos

www.esab.edu.br 167
 estados do desenvolvimento. Estes estágios incluem projeto,
desenvolvimento, produção, instalação e suporte.

A norma ISO 9000-3 (não confundir com a ISO 9003) traz os

roteiros para aplicar a ISO 9001 especificamente na área de
desenvolvimento, fornecimento e manutenção de software.
Todas as orientações giram em torno de uma “situação contratual”,
onde uma outra empresa contrata a empresa em questão para
desenvolver um produto de software.
Veja na tabela abaixo os processos definidos na ISO 9000-3:
Grupo Atividade

Responsabilidade do fornecedor
Estrutura do Sistema de Qualidade Responsabilidade do comprador
Análise crítica conjunta

Análise crítica do contrato

Especificação dos requisitos do
comprador
Planejamento do desenvolvimento
Atividades do Ciclo de Vida Projeto e implementação
Testes e validação
Aceitação
Cópia, entrega e instalação
Manutenção

Gerenciamento de configuração
Controle de documentos
Registros da qualidade
Atividades de Apoio Medição
Regras, convenções
Aquisição
Produto de software incluído
Treinamento

O processo de certificação de uma empresa de software

segundo as normas ISO 9001 / 9000-3 segue um conjunto de
passos bem definidos:

• A empresa estabelece o seu sistema de qualidade.

www.esab.edu.br 168
 • A empresa faz uma solicitação formal a um órgão certificador,
incluindo detalhes do negócio da empresa, escopo da
certificação solicitada e cópia do manual de qualidade.
• O órgão certificador faz uma visita à empresa, colhe mais
dados e explica o processo de certificação.
• O órgão certificador verifica se a documentação do sistema
de qualidade está de acordo com a norma ISO.
• O órgão certificador envia uma equipe à empresa com fins
de auditoria. Nesta visita, será verificado se todos na
empresa cumprem o que está documentado no manual de
qualidade.
• O órgão certificador emite o certificado de qualidade.
• O órgão certificador realiza visitas periódicas à empresa
para assegurar que o sistema

Qualidade de Processos de Software

Os estudos sobre qualidade mais recentes são na sua maioria

voltados para o melhoramento do processo de desenvolvimento
de software. Não é que a qualidade do produto não seja
importante, ela é. Mas o fato é que, ao garantir a qualidade do
processo, já se está dando um grande passo para garantir
também a qualidade do produto.

ISO 12207 – Processo de vida do ciclo de software

Este padrão formaliza a arquitetura do ciclo de vida do software,

que é um assunto básico em Engenharia de Software e também
em qualquer estudo sobre Qualidade do Processo de Software.

www.esab.edu.br 169
 Esta norma possui mais de 60 páginas e detalha os diversos
processos envolvidos no ciclo de vida do software.

Estes processos estão divididos em três classes: Processos

Fundamentais, Processos de Apoio e Processos Organizacionais.

Veja a lista completa dos processos na tabela abaixo:

Processo
Início e execução do desenvolvimento, operação ou
Fundamentais manutenção do software durante o seu ciclo de vida.

Atividades de quem um software. Inclui: definição da

Aquisição necessidade de adquirir um software (produto ou serviço),
pedido de proposta, seleção de fornecedor, gerência da
aquisição e aceitação do software

Atividades do fornecedor de software. Inclui preparar uma

Fornecimento proposta, assinatura de contrato, determinação recursos
necessários, planos de projeto e entrega do software.

. Atividades do desenvolvedor de software. Inclui: análise

Desenvolvimento de requisitos, projeto, codificação, integração, testes,
instalação e aceitação do software.

Operação Atividades do operador do software. Inclui: operação do

software e suporte operacional aos usuários.

Manutenção Atividades de quem faz a manutenção do software.

Processo de

Apoio Auxiliam um outro processo.

Registro de informações produzidas por um processo ou

atividade. Inclui planejamento, projeto, desenvolvimento,
Documentação produção, edição, distribuição e manutenção dos
documentos necessários a gerentes, engenheiros e
usuários do software.

Identificação e controle dos itens do software. Inclui:

Gerência de controle de armazenamento, liberações, manipulação,
Configuração distribuição e modificação de cada um dos itens que
compõem o software.

Garantia da Garante que os processos e produtos de software estejam

Qualidade em conformidade com os requisitos e os planos
estabelecidos.

Determina se os produtos de software de uma atividade

Verificação atendem completamente aos requisitos ou condições
impostas a eles.

www.esab.edu.br 170
 Validação Determina se os requisitos e o produto final (sistema ou
software) atendem ao uso específico proposto.

Define as atividades para avaliar a situação e produtos

Revisão Conjunta de uma atividade de um projeto, se apropriadas.

Determina adequação aos requisitos, planos e contrato,

Auditoria quando apropriado.

Analisar e resolução dos problemas de qualquer natureza

Resolução de ou fonte, a execução do desenvolvimento, operação,
Problemas descobertos durante manutenção ou outros processos.

Processo Implementam uma estrutura constituída de processos de

ciclo de vida e pessoal associados, melhorando
Organizacionais continuamente a estrutura e os processos.

Gerência Gerenciamento de processos.

Fornecimento de recursos para outros processos. Inclui:

Infraestrutura hardware, software, ferramentas, técnicas, padrões de
desenvolvimento, operação ou manutenção.

Melhoria Atividades para estabelecer, avaliar, medir, controlar e

melhorar um processo de ciclo de vida de software.

Treinamento Atividades para prover e manter pessoal treinado.

A norma detalha cada um dos processos acima. Ela define ainda

como eles podem ser usados de diferentes maneiras por
diferentes organizações (ou parte destas), representando
diversos pontos de vista para esta utilização. Cada uma destas
visões representa a forma como uma organização emprega
estes processos, agrupando-os de acordo com suas necessidades
e objetivos.

As visões têm o objetivo de organizar melhor a estrutura de uma

empresa, para definir suas gerências e atividades alocadas às
suas equipes. Existem cinco visões diferentes: contrato,
gerenciamento, operação, engenharia e apoio. Veja na figura
abaixo como estas visões se relacionam aos processos.

www.esab.edu.br 171
Já na unidade 11, demos uma visão geral sobre COBIT – que
define padrões para governança em TI. Além disto, fornecemos
uma introdução sobre o tema e recomendamos que o estudante
faça uma comparação entre os modelos – ITIL e COBIT para
melhor fixação de suas aplicações.

Na unidade 12, focamos no desenvolvimento de projetos nas

áreas de tecnologia e desenvolvimento de software/sistemas.

À medida que a complexidade dos projetos aumenta, novas

tecnologias foram surgindo, e uma necessidade de mudança nos
processos de produção foi percebida por empresas que tinham
custos altíssimos no desenvolvimento de softwares. Desta forma,
na unidade 13 tratamos do CMMI – que visa aprimorar esses
processos de modo seguro e organizado.

Na unidade 14 abordamos um tema muito importante nos dias de

hoje. A qualidade. Descrevemos o que é um Sistema de Qualidade,
as certificações da qualidade e a qualidade em projetos de
Software.

Os estudos sobre qualidade mais recentes são na sua maioria

voltados para o melhoramento do processo de desenvolvimento
de software. Não é que a qualidade do produto não seja importante,
ela é. Mas o fato é que, ao garantir a qualidade do processo, já se
está dando um grande passo para garantir também a qualidade
do produto. Desta forma, a unidade 15 abordou o tema da
qualidade de processos de Software.

www.esab.edu.br 172
Ciclo de vida de projeto: São as etapas a serem cumpridas desde a
concepção de um problema, até sua efetiva implantação num sistema
computacional. Existem vários modelos de ciclo de vida (top-down,
bottom-up, prototipagem). De uma maneira genérica podemos citar as
seguintes fases de um ciclo de vida: Entrevista/Coleta de Dados;
Análise (O Que Fazer); Projeto (Como Fazer); Implementação (A
fabricação, codificação e projeto de arquitetura); Testes; Aceitação e
Implantação; Manutenção. R

Coaching: Pode ser um processo, com início, meio e fim, definido

em comum acordo entre o coach (profissional) e o coachee (cliente)
de acordo com a meta desejada pelo cliente, onde o coach apoia o
cliente na busca de realizar metas de curto, médio e longo prazo,
através da identificação e uso das próprias competências
desenvolvidas, como também do reconhecimento e superação de
suas fragilidades.R

COBIT: é um modo para implementar a governança de TI, desenvolvido

pelo IT Governance Institute – ITGI (www.itgi.com), criado em 1998
para definir padrões no direcionamento e controle da tecnologia da
informação nas empresas. R

Convergência: Disposição de dois ou mais elementos lineares que se

dirigem para ou se encontram no mesmo ponto. R

www.esab.edu.br 173
Convergência Tecnológica: Designa a tendência de utilização de
uma única infraestrutura de tecnologia para prover serviços que,
anteriormente, requeriam equipamentos, canais de comunicação,
protocolos e padrões independentes. R

CMM: Capability Maturity Model. também conhecido como

Software CMM (SW-CMM) pode ser definido como sendo uma soma
de “melhores práticas” para diagnóstico e avaliação de maturidade
do desenvolvimento de softwares em uma organização. R

CMMI: Capability Maturity Model Integration. É um modelo de

referência que contém práticas (Genéricas ou Específicas)
necessárias à maturidade em disciplinas específicas (Systems
Engineering (SE), Software Engineering (SE), Integrated Product
and Process Development (IPPD), Supplier Sourcing (SS)).
Desenvolvido pelo SEI (Software Engineering Institute), o
CMMI é uma evolução do CMM e procura estabelecer um modelo
único para o processo de melhoria corporativo, integrando
diferentes modelos e disciplinas. R

EAP: Estrutura Analítica do Projeto. A EAP é uma decomposição

hierárquica orientada à entrega do trabalho a ser executado pela
equipe do projeto, para atingir os objetivos do projeto e criar as
entregas necessárias. A EAP subdivide o trabalho do projeto em
partes menores e mais facilmente gerenciáveis R

Escopo: Gama ou limite de operações. Abrangência ou

cronograma de trabalho. R

Framework: Framework ou arcabouço é uma estrutura de suporte

definida em que um outro projeto de software pode ser organizado

www.esab.edu.br 174
e desenvolvido. Framework se diferencia de uma simples biblioteca
(toolkit), pois esta se concentra apenas em oferecer implementação
de funcionalidades, sem definir a reutilização de uma solução de
arquitetura (design). R

Gerenciar: 1) dirigir (empresa, negócio, serviço) na condição de

gerente; administrar, gerir.
2) Gerência de projetos ou gestão de projetos é a aplicação de
conhecimentos, habilidades e técnicas na elaboração de atividades
relacionadas para atingir um conjunto de objetivos pré-definidos. R

Gerente: Aquele que gere e/ou administra negócios, bens ou serviços. R

Gerente de Projetos: É um indivíduo que trabalha para manter o

progresso e a interação mútua progressiva dos diversos
participantes do empreendimento, de modo a reduzir o risco de
fracasso do projeto. R

Governança em TI: É o sistema pelo qual as sociedades

empresariais são dirigidas e monitoradas pelo mercado de capitais,
envolvendo os relacionamentos entre acionistas, conselho,
diretoria e auditoria. Descreve o processo de tomada de decisão
e de implementação ou não implementação das decisões tomadas
em TI, de acordo com a estratégia corporativa. R
ITIL: Information Technology Infrastructure Library. é o modelo de
referência para gerenciamento de processos de TI mais aceito
mundialmente. A metodologia foi criada pela secretaria de comércio
(Office of Government Commerce, OGC) do governo Inglês, a
partir de pesquisas realizadas por Consultores, Especialistas e
Doutores, para desenvolver as melhores práticas para a gestão
da área de TI nas empresas privadas e públicas. R

www.esab.edu.br 175
Atualmente se tornou a norma BS-15000, sendo esta um anexo
da ISO 9000/2000. O foco deste modelo é descrever os processos
necessários para gerenciar a infra-estrutura de TI eficientemente
e eficazmente de modo a garantir os níveis de serviço acordados
com os clientes internos e externos. http://www.itil.org. R

Metodologia: corpo de regras e diligências estabelecidas para

realizar uma pesquisa; método. R

Multidisciplinar: que contém, envolve, distribui-se por várias

disciplinas e pesquisas. R

PDCA: O ciclo PDCA, ciclo de Shewhart ou ciclo de Deming,

foi introduzido no Japão após a guerra, idealizado por Shewhart e
divulgado por Deming, quem efetivamente o aplicou. O ciclo de
Deming tem por princípio tornar mais claros e ágeis os processos
envolvidos na execução da gestão, como por exemplo na gestão
da qualidade. O ciclo começa pelo planejamento, em seguida a
ação ou conjunto de ações planejadas são executadas, checa-se
o que foi feito, se estava de acordo com o planejado, constantemente
e repetidamente (ciclicamente) e toma-se uma ação para eliminar
ou ao menos mitigar defeitos no produto ou na execução. R

PMBOK: Project Management Body of Knowledge. é 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. Uma boa
prática não significa que o conhecimento e as práticas devem ser
aplicados uniformemente a todos os projetos sem considerar se é
apropriado. R

www.esab.edu.br 176
PMI: Project Management Institute. Instituto de Gerenciamento de
Projeto– foi fundado por Management Body of Knowledge –
Conjunto de Conhecimentos para Gerenciamento de Projeto.
www.pmi.org. R

Projeto: 1) Descrição escrita e detalhada de um empreendimento

a ser realizado; plano, delineamento, esquema.
2) E um esforço temporário empreendido para criar um produto,
serviço ou resultado exclusivo.
3) São empreendimentos temporários instituídos com a finalidade
de alcançar determinado objetivo. São executados por pessoas e
possuem recursos limitados. Precisam ser planejados, controlados
e executados. R

Requisito: Condição para se alcançar determinado fim. R

SeisSigma ou Six Sigma pode ser definido como muitas coisas

(metodologia, filosofia e cultura de trabalho entre outras), no entanto sua
melhor definição seria o fato de o Seis Sigma ser um nível otimizado de
performance que se aproxima a zero defeito em um processo de confecção
de um produto, serviço ou transação. www.isixsigma.com. R

Sarbanes-Oxley Lei criada em 30 de julho de 2002 pelo senador

Paul Sarbanes e o deputado Michael Oxley. Seu conjunto busca
garantir a criação de mecanismos de auditoria e segurança
confiáveis nas empresas, incluindo ainda regras para a criação de
comitês e comissões encarregados de supervisionar suas atividades
e operações de modo a mitigar riscos aos negócios, evitar a
ocorrência de fraudes ou ter meios de identificar quando elas
ocorrem, garantindo a transparência na gestão das empresas. R

www.esab.edu.br 177
SLA: Um Acordo de Nível de Serviço (ANS ou SLA, do inglês Service
Level Agreement) é a parte de contrato de serviços entre duas ou
mais entidades no qual o nível da prestação de serviço é definido
formalmente. Na prática, o termo é usado no contexto de tempo de
entregas de um serviço ou de um desempenho específico. R

Stakeholders: são todas as pessoas e organizações cujos

interesses são afetados durante o desenvolvimento de um projeto.
Podem ser: clientes, patrocinadores, gerente, equipe, organização,
etc. R

SWOT é uma ferramenta utilizada para fazer análise de cenário

(ou análise de ambiente), sendo usado como base para gestão e
planejamento estratégico de uma corporação ou empresa, mas
podendo, devido a sua simplicidade, ser utilizada para qualquer
tipo de análise de cenário, desde a criação de um blog à gestão
de uma multinacional. A Análise SWOT é um sistema simples para
posicionar ou verificar a posição estratégica da empresa no
ambiente em questão. R

TI: Tecnologia da Informação. Refere-se a todas as atividades

desenvolvidas para a sociedade pelos recursos da informática. R

www.esab.edu.br 178
CARVALHO JÚNIOR, Moacir Ribeiro de. Gestão de Projetos: da academia

à sociedade. Curitiba: Intersaberes, 2012.

FERNANDES, AGUINALDO ARAGON / ABREU, VLADIMIR FERRAZ DE

- IMPLANTANDO A GOVERNANÇA DE TI - BRASPORT - 2006

LAHTI, CHRISTIAN / PETERSON, RODERICK - SARBANES-OXLEY

COBIT E FERRAMENTAS OPEN SOURCE - ALTA BOOKS- 2006

MULCAHY, Rita. Preparatório para o Exame de PMP®: aprendizado

acelerado para passar no Exame de PMP do PMI®. 8.ed. EUA: RMC

Publications, 2013.

HELDMAN, KIM - GERENCIA DE PROJETOS – Ed. Campus- 2006

PROJECT MANAGEMENT INSTITUTE - PMBOK - GUIA DO CONJUNTO

DE CONHECIMENTOS EM - 2013

SCHMITZ, EBER ASSIS / ALENCAR, ANTONIO JUAREZ - ANALISE DE

RISCO EM

GERÊNCIA DE PROJETOS - BRASPORT – 2006

WEBER, KIVAL CHAVES / ROCHA, ANA REGINA CAVALCANTI DA /

MALDONADO, JOSE

CARLOS - QUALIDADE DE SOFTWARE - MAKRON – 2001

PRESSMAN, ROGER S. - ENGENHARIA DE SOFTWARE - MCGRAW-ILL 2006

www.esab.edu.br 179
VALERIANO, Dalton. Moderno Gerenciamento de Projetos. São Paulo:

Prentince Hall, 2005.

WEINBERG, G. M., AND SCHULMAN, E. L., 1974. Goals and performance

in computer programming. Human Factors

www.esab.edu.br 180