Rodrigo Oliveira Spínola

rodrigo.devmedia@gmail.com
Doutor e Mestre em Engenharia de Software pela COPPE/UFRJ. Realizou seu Pós-Doutorado na
University of Maryland Baltimore County e Centro Fraunhofer nos Estados Unidos. Atualmente é
Professor Titular do Programa de Pós-Graduação em Sistemas e Computação da Universidade
Salvador - UNIFACS.

Marco Antônio Pereira Araújo

maraujo@devmedia.com.br
69 ª Edição - 2014
Doutor e Mestre em Engenharia de Sistemas e Computação pela COPPE/UFRJ, Especialista em
Corpo Editorial Métodos Estatísticos Computacionais e Bacharel em Matemática com Habilitação em Infor-
mática pela UFJF.
Editor
Rodrigo Oliveira Spínola Eduardo Oliveira Spínola
eduspinola@gmail.com
Colaboradores
É Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Magazine. É
Marco Antônio Pereira Araújo
Eduardo Oliveira Spínola bacharel em Ciência da Computação pela Universidade Salvador (UNIFACS).
Nicolli Souza Rios Alves

Consultora Técnica
Daniella Costa
Nicolli Souza Rios Alves
nicolli.devmedia@gmail.com
Jornalista Responsável Bacharel em Ciência da Computação na Universidade Salvador (UNIFACS), Mestranda em Sistemas
Kaline Dolabella - JP24185 e Computação no Programa de Pós-Graduação em Sistemas e Computação da UNIFACS na linha de
Na Web Engenharia de Software. É editora da Engenharia de Software Magazine.
http://www.devmedia.com.br/revista-engenharia-de-software-magazine

Atendimento ao Leitor Fale com o Editor!

A DevMedia conta com um departamento exclusivo para o atendimento ao leitor. É muito importante para a equipe saber o que você está achando da revista: que tipo de artigo você

Se você tiver algum problema no recebimento do seu exemplar ou precisar de algum gostaria de ler, que artigo você mais gostou e qual artigo você menos gostou. Fique a vontade para

esclarecimento sobre assinaturas, exemplares anteriores, endereço de bancas de entrar em contato com os editores e dar a sua sugestão!

jornal, entre outros, entre em contato com: Se você estiver interessado em publicar um artigo na revista ou no site ES Magazine,
entre em contato com os editores, informando o título e mini-resumo do tema que você gostaria
www.devmedia.com.br/central
(21) 3382-5038 de publicar.

Publicidade
Para informações sobre veiculação de anúncio na revista ou no site entre em
contato com:
publicidade@devmedia.com.br
 Sumário
Conteúdo sobre Agilidade

06 – Scrum: uma visão prática do framework

[ Roberto Passani ]

Conteúdo sobre Boas Práticas

11 – PMBOK: Trabalhando com gerenciamento de custos

[ Fabiana de Lima ]

Conteúdo sobre Boas Práticas

18 – Riscos em projetos de software com PMBOK

[ Jhoney Lopes e José Luis Braga ]

Conteúdo sobre Boas Práticas

30 – Gerência de Projetos: Monitore e controle o desenvolvimento de software

[ Rommel Gabriel Gonçalves Ramos e Daniel Couto Gatti ]
Feedback
eu
s
Dê

Conteúdo sobre Boas Práticas

sobre e
35 – Gestão de Projetos: Usando processos de desenvolvimento
[ Rommel Gabriel Gonçalves Ramos e Daniel Couto Gatti ]
s
ta
edição

Artigo no estilo Prático

Dê seu feedback sobre esta edição!
43 – ITIL: Como implantar o gerenciamento de mudanças
[ Cristiane Aparecida Lana e Bruno Torres Satler ]
A Engenharia de Software Magazine tem que ser
feita ao seu gosto.
Para isso, precisamos saber o que você, leitor, acha
Conteúdo sobre Boas Práticas, Conteúdo sobre Arquitetura e desenvolvimento da revista!

55 – Boas práticas de programação www.devmedia.com.br/esmag/feedback

[ Leandro Tavares Siciliano ]
Edição 05 - Engenharia de Software Magazine 5
Agilidade
Nesta seção você encontra artigos voltados para as práticas e métodos ágeis.
Scrum: uma visão prática do framework
Roberto Passani
robertopassani@gmail.com
Quase oito anos de experiência com testes de
software, iniciado em qualidade de sistema
operacional de aparelhos celulares, depois
banco de dados, sistema de investimentos, pla-
taforma de e-commerce e atualmente atuando
com aplicativos móveis. Há pouco menos de um
ano atuando em projeto de aplicativos móveis.
Recentemente teve a oportunidade de conhe-
cer mais do processo Scrum na prática.
6 Engenharia de Software Magazine - Scrum: uma visão prática do framework
O
Scrum é uma abordagem ágil
que prima pela otimização e
objetividade no processo e em
todas suas etapas, costuma minimizar
burocracias, documentação e módulos
em relação a outros processos (como
RUP). Tudo é baseado nas reuniões do
processo (que são muitas). Entre uma
reunião e outra o trabalho é realizado.
Essas reuniões são importantes ao ponto
de algumas empresas não usarem ne-
nhuma documentação escrita, ou seja,
fazem Sprints semanais e reuniões às
segundas e sextas, de Planning e Review
respectivamente, onde fazem todo o tra-
cking das atividades e desenvolvimento
do produto.
Neste artigo usaremos o modelo de um
Sprint de 10 dias úteis, ou aproximada-
mente 14 dias corridos, sendo o Planning
no primeiro dia e o Review no último.
Após o Review ocorre a Retrospectiva
e no decorrer do Sprint o pré-planning.
Diariamente devem ocorrer as reuniões
Diárias (Daily Meetings). Todas essas
etapas são detalhadas no artigo.
Fique por dentro:
Esse artigo se propõe a mostrar uma abordagem
prática do Scrum da forma como é aplicado em
um projeto real, detalhando os papéis e funções
de cada participante, cada etapa do processo e
sua importância para que o projeto e a equipe
ganhem maturidade e evoluam de forma que
se obtenha um produto com qualidade e que
obedece às regras da plataforma utilizada.
A equipe na qual este artigo foi baseado
é constituída uma Product Owner, um
Scrum Master (que também acumula fun-
ções de Coordenador), um Analista de Tes-
tes (o autor do artigo), uma Designer, um
Analista de UX (User Experience) e quatro
desenvolvedores, que se dividem entre as
plataformas iOS e Android, fora outras
pessoas que auxiliam a equipe, como ana-
listas de produto, infraestrutura e outros.
A manutenção do processo é responsabi-
lidade do Scrum Master, ou seja, marcar
todas as reuniões, garantir a presença de
toda a equipe, comandar as reuniões em
si, escrever no sistema de gerenciamento
do processo, auxiliar no desenvolvimento
dos critérios de aceite, avaliar questões de
serviço, backend e etc.

Definição do Projeto
O primeiro passo para desenvolvimento de um sistema no
Scrum seria a reunião de pre-planning (pré-planejamento), onde
são definidos o objetivo principal do sistema, isto é, aquilo que
ele deseja atingir: o mercado, o público e a/as funcionalidade(s)
principal(ais) - para um aplicativo, por exemplo, seja trânsito,
notícias, compras ou futebol - onde são pré-planejadas as his-
tórias que iniciarão o desenvolvimento, e nelas são inseridos os
critérios de aceite ou entrega. Estes são basicamente os requisitos
do sistema, o detalhamento de todas as funcionalidades, desde
as mais simples àquelas principais.
O título das histórias devem ser escritos na perspectiva de
quem desejam atingir, por exemplo: “Eu, como cliente, quero
que o aplicativo faça…” ou “Eu, como área de negócios da em-
presa, quero inserir a logomarca de nosso patrocinador…”, ou
ainda, “Eu, como Product Owner, quero ver uma mensagem
de erro quando o usuário executar uma ação indevida…”. Isso
facilita analisar quem deve aprovar a história. Caso exista
alguém além do Product Owner, o Scrum Master consegue
analisar se há alguém além dos participantes diretos do projeto
que deva ser convidado para os ritos, como Planning e Review,
se há alguém externo à equipe que deseja inserir histórias ou
acrescentar algo ao sistema.
Todos devem participar desse processo, ajudar na definição
dos critérios, ajudar no levantamento de critérios de exceção,
mensagens de erro e possíveis cenários que faltam definição.
A equipe deve ser unida profissionalmente e ter o objetivo
comum de entregar o melhor sistema possível. E o analista de
testes já inicia a escrita dos testes baseado nesses requisitos,
criando todos os testes de validação, exceção, carga, perfor-
mance, e o que mais for necessário, muitas vezes já escrevendo
os testes (apenas com objetivo) na própria reunião, através de
um bloco de notas, caderno ou qualquer outra ferramenta. Já
a equipe de desenvolvimento pode começar a pensar em todo
o backend (serviços e servidores) necessário, e tudo que será
preciso para a implementação do sistema.
Faça-se um sistema
Uma vez estruturado o backend de serviços, a equipe pode
começar a implementação do software, e para priorizar as
histórias e analisar quais farão parte de um primeiro sprint
realiza-se uma primeira reunião de planning, onde as histó-
rias iniciais são colocadas no primeiro sprint e priorizadas na
ordem decrescente dentro dele. Primeiramente colocam-se
todas as histórias que precisam ser feitas e depois elas são
priorizadas. Em seguida, pontua-se cada história de acordo
com o critério utilizado no projeto (Fibonacci, por horas ou
outro), daí podemos analisar se ainda é possível inserir alguma
história, se a meta de pontos não estiver sido atingida, ou se
alguma história deverá sair se a meta estiver sido ultrapassada.
Caso a meta tenha sido ultrapassada e a quantidade de pontos
das histórias for maior do que os pontos ultrapassados, então
a última história, segundo os critérios de priorização, poderá
ser dividida em duas.
agilidade
Um Sprint nunca deve ser iniciado com a quantidade de
pontos excedida, com histórias que possuem critérios de aceite
não definidos, sem layout ou definição de UX incompleta. Por
isso, se a quantidade de pontos for excedida e não houver a
possibilidade de troca com outra história, então os critérios de
aceite devem ser divididos em duas histórias, sendo uma no
Sprint atual, fechando o sprint dentro da métrica de pontua-
ção e outra como a primeira história do próximo (segundo),
abrindo o próximo sprint com os pontos e critérios de aceite
que restaram, devendo ser devidamente entregue cada uma
em seu sprint.
No planning, todo o layout e definições de UX já devem estar
prontos e aprovados pelo “Product Owner”, tudo já deve estar
disponível para análise da equipe de testes e desenvolvimento.
No caso de aplicativos móveis é necessário ter a tela completa
e também cada botão separado, cada ícone, com todas as de-
finições de tela para iOS: retina e não-retina, e para Android:
LDPI, MDPI, HDPI, XHDPI, XXHDPI. O ideal é anexar todas
as imagens na história para facilitar o acesso para a equipe
otimizando o tempo e evitando ter que buscar em Drivers,
e-mail, e etc., ou em um sistema de pastas que nem sempre é
claro para todos. Portanto, para realizar o desenvolvimento,
todas as histórias do sprint que está para se iniciar precisam
ter status de definidas na ferramenta usada pela empresa, que
indica que todos os dados aqui descritos já foram detalhados,
anexados à história e/ou link tenha sido disponibilizado.
Iniciando o desenvolvimento
Logo após o planning, o Scrum Master deve marcar o pré-
planning, review e planning que estão por vir, para 10 dias
úteis após o primeiro planning, considerando que o planning
já ocorre no primeiro dia do sprint e o review no último. Neste
cenário, se o planning ocorre em uma segunda-feira dia 01,
então o pré-planning deve ser marcado para quarta-feira dia
10 (aproximadamente) e o Review exatamente para o dia 12,
sexta-feira. Tudo isso deve ser marcado com antecedência para
que as datas de todos os ritos sejam de conhecimento de todos
da equipe evitando atrasos por indisponibilidade de local ou
surpresa em sua realização.
No projeto é utilizado o TDD, ou seja, Test Driven Develop-
ment, porém um TDD um pouco diferente, não baseado em
testes unitários ou automatizados, mas baseado nos testes
funcionais escritos a partir dos critérios de aceite definidos
no pré-planning. Os testes da primeira história da ordem de
priorização devem ficar prontos antes do início do Sprint. O
desenvolvedor segue os casos de testes para criar o sistema.
Portanto, o analista de testes já deve ter todos os testes escritos
e detalhados a essa altura do processo com a maior cober-
tura possível de forma otimizada. Esses testes devem estar
disponíveis na ferramenta para análise dos desenvolvedores
evitando paradas e atrasos no desenvolvimento, pois todas as
perguntas já devem ter sido levantadas e respondidas, todas
as mensagens de erro, validação e exceção com a cobertura
adequada de forma que nenhuma demanda tenha que ser
coberta no meio processo.
Edição 69 - Engenharia de Software Magazine 7
 Conforme as histórias forem sendo iniciadas, elas vão ob-
tendo status de progresso na ferramenta. Após isso, quando
forem sendo completadas, já podem ser disponibilizadas para
teste. No caso de aplicativos móveis, é gerado um build que é
instalado no aparelho, e os analistas de testes podem analisar
as funcionalidades já implementadas. Uma vez encontrados
erros, eles devem ser registrados na ferramenta e, se bloquea-
rem a história e não forem recorrentes, devem ser corrigidos
no próprio sprint. Caso sejam erros recorrentes ou que não
bloqueiam a história ou seus critérios de aceite, eles podem
ser deixados no backlog para priorização posterior.
Uma vez registrados bugs que ficam no sprint, eles devem
então ser corrigidos em um novo build do sistema, e todos os
testes da nova funcionalidade devem ser reexecutados para
garantir que a correção de um defeito não gerou erros em
outras partes da nova funcionalidade. Esse processo é repe-
tido até que todos os testes sejam executados e nenhum erro
seja encontrado. Feito isso, a história poderá obter o status de
completa na ferramenta e poderá ser liberada para o Review
que ocorrerá no último dia do sprint.
Diariamente, na rotina do projeto e com horário fixo, sempre
com a presença de todos ou o máximo possível de compo-
nentes da equipe, deve ocorrer a “Daily Meeting” (Reunião
Diária), onde todos devem resumir suas atividades do projeto
desde a daily meeting anterior, tentando detalhar as ações
e que métodos usou para atingir seus objetivos, abrindo es-
paço para que os colegas possam auxiliar em dúvidas ou se
utilizar dos dados ali compartilhados como lições aprendidas
ou melhores práticas.
Na prática, sempre pode ocorrer de critérios de aceite ou ex-
ceção não terem sido definidos ou algum layout ou definição
de UX aparecer de última hora durante o Sprint. Nesse caso,
devem ser tratados com urgência, uma vez que o desenvol-
vimento pode ficar parado até que artefatos sejam criados.
O responsável pela experiência de usuário (UX) ou designer
precisam ser chamados com urgência e criar o material ne-
cessário com o menor impacto possível no sprint para evitar
atrasos na entrega e remarcação do review. Caso essa solução
se torne demasiadamente grande e o impacto inevitável, então
a história pode ter a prioridade reduzida para o fim do Sprint,
quando a definição ou artefatos necessários estarão prontos.
Caso isso ainda não seja o bastante, então podemos adiantar o
fim do Sprint e essa poderá ser a primeira história do próximo,
porém a Review nunca deve ser adiada e o Sprint alongado,
pois o impacto disso a longo prazo é muito negativo, salvo em
condições excepcionais.
A entrega – Versão 1.0
Após finalizado o processo de desenvolvimento, passadas
muitas daily meetings e muitas linhas de código, ocorre a
primeira reunião de Review. A primeira versão poderá ser en-
tregue, as funcionalidades devem ser preparadas e o ambiente
todo pronto para a análise do product owner.
Ao iniciar a reunião, o sistema sob análise deve estar disponí-
vel para o “Product Owner” e as histórias devem ser exibidas
8 Engenharia de Software Magazine - Scrum: uma visão prática do framework
para todos, de preferência no projetor, e os critérios de aceite
vão sendo passados ponto a ponto para análise do cliente. Ele
pode realizar os testes necessários e passar por seus critérios
de pronto. Quando finalizadas, as histórias obtêm status de
”approved” no sistema e o cliente passa a analisar a próxima.
Caso a história não seja completa e os critérios de aceite não
sejam todos atingidos, ela deve sofrer uma split, ser dividida
em duas, onde a segunda história poderá ser a primeira do
próximo Sprint e terá os critérios de aceite que faltam para
completar. Algumas ferramentas automaticamente repassam
as tarefas incompletas para a história do próximo sprint.
Caso os critérios de pronto do cliente é que não sejam atendi-
dos, ou seja, ele visualizar novos critérios de aceite que deve-
riam ser atingidos para que a história possa receber o deploy e
ficar disponível para o usuário final, o que geralmente ocorre
com critérios de exceção ou mensagens de erro, então deve
ser criada uma nova história para um sprint futuro e que será
priorizada no planning. Essa deve conter os novos critérios de
aceite que finalizam a nova funcionalidade.
Pré-Planning – Sprint 2
Durante o Sprint, deve ser realizada a reunião pré-planning.
Nela devem ser enriquecidas as histórias para o Sprint 2, inserir
critérios de aceite e priorizar histórias de UX, design e backend;
para que tudo esteja pronto quando houver o planning.
Retrospectiva do primeiro Sprint
Após o planning, logo após o fim do Sprint, deve ser feita
uma reunião de retrospectiva. Nela se deve relatar como foram
os últimos dias (do Sprint), todas as atividades de sucesso,
boas práticas, lições aprendidas e “à melhorar” para obter um
processo mais sólido e rico, satisfatório para todos.
Geralmente abordam-se primeiro os pontos positivos,
mas não é uma regra. Cada participante do projeto deve ter
oportunidade de colocar seu post-it no quadro, falar sobre
o que desejar, geralmente são questões que deram certo nas
atividades de uma pessoa e ela deseja compartilhar com os
outros membros, abrir discussão sobre o ponto apresentado e
detalhar melhor sobre o tópico.
Após essa etapa discutem-se os pontos de melhoria, que cos-
tumam gerar mais polêmica e deixar ânimos exaltados. Todos
devem se sentir à vontade para falar de qualquer tópico: desde
a internet no ambiente de trabalho, relacionamento com outras
equipes, ar-condicionado, assim como questões técnicas que
influenciam diretamente no projeto como design, UX, crité-
rios de aceite, formato de código, algoritmos, processo, links,
atuação de colegas; ou tudo aquilo que não foi satisfatório e
pode melhorar nas etapas futuras do processo.
Após apresentados e discutidos os dois lados do último
sprint, ações de melhoria devem ser tomadas, ou seja, Product
Owner, Scrum Master e Coordenador devem definir como e
onde podem agir para tentar resolver ou, ao menos, apaziguar
os pontos de melhoria do projeto que dependem de ação exter-
na. Relacionamento com outras equipes, ações com a gerência
da área ou até com as diretorias da empresa com o objetivo de
 agilidade

tornar o ambiente do projeto o melhor possível, ações internas,
como performance de um colaborador específico ou mudanças
no processo devem ser resolvidas internamente e monitoradas
durante as daily meetings do próximo sprint.
Muitos projetos não veem importância na retrospectiva,
principalmente com a evolução dos sprints onde o processo fica
mais sólido e as retrospectivas se tornam repetitivas. Porém,
só há evolução do projeto se houver reuniões de retrospectivas
bem feitas. É importante também estar atento ao fato de que
ninguém pode levar os pontos de melhoria para o lado pes-
soal. Essa é uma reunião para um processo de maturidade e
o conceito é altamente profissional com objetivo de fazer um
trabalho melhor.
Planning - Sprint #2
Após a retrospectiva, analisados os pontos positivos e defi-
nidos os pontos de melhoria, ocorre o Planning para definir
o segundo sprint. As ações de melhoria já devem começar a
ser adotadas imediatamente, e o processo se reinicia, histórias
devem ser priorizadas. Se houve história com split no sprint
anterior, então essas podem ser as primeiras, porém não é
obrigatório, por isso os branches devem estar bem organizados
para que uma história com menor prioridade possa ser conti-
nuada em um sprint posterior sem uma linha de aprendizado
muito longa. Após priorizadas as histórias, deve-se discutir a
pontuação, e definir as histórias que ficam no Sprint e quais
serão adiadas para os próximos sprints.
Devem ser evitadas discussões paralelas nas reuniões. No
Planning algumas pessoas tendem a sair do foco, gostam de
opinar, porém é o Product Owner quem define, as prioridades
são dele e da área de negócios. É necessário manter o objetivo
de construir o Sprint rapidamente para retornar ao desenvol-
vimento, porém sem deixar pontos indefinidos, como dito
antes, todo o design, UX, backend, serviços, etc., precisa estar
definido antes de iniciar o Sprint.
é realizada corretamente em cada reunião a que pertence,
garantir que todos estão executando suas atividades no mo-
mento certo do projeto, se o desenvolvimento segue padrões
de qualidade, testes unitários, design patterns, métricas, bus-
car novas formas de atingir metas assim como, analisar se o
analista de testes (ou qualidade) está seguindo corretamente
o processo, escrevendo os objetivos de testes no pré-planning,
se os testes da primeira história já estão prontos após o plan-
ning (para iniciar o desenvolvimento), se a cobertura dos
cenários de testes está adequada, coordenar se o processo é
corretamente seguido, bem próximo dos analistas que fazem
com que ele ocorra.
Seu excedente pode ser analisar o sistema e ver se há formas
diferentes e talvez melhores de fazer o mesmo, pesquisar,
procurar se inteirar nos documentos sobre sistemas similares
e analisar se há novos padrões sendo adotados, procurar o
que há de mais moderno, quais os caminhos que estão sendo
seguidos para obter o melhor desse modelo de sistema, assim
como também do processo. Seguir práticas, discussões em
fóruns, ler as revistas especializadas e obter dados de como
otimizar o processo sem denegrir a qualidade, ou seja, o
ScrumMaster deve ser sempre muito dedicado e proativo,
muito curioso e ciente das atividades diversas para ver falhas
onde não estão olhando, seja no desenvolvimento ou nos testes,
sempre com objetivo de aprimorar onde pode haver algum
tipo de evolução.

Descrição dos papéis

Para explicar melhor as atividades durante o processo de de-
senvolvimento de software, é interessante esclarecer as funções
e papéis de cada ator no processo, o que é esperado de cada um
e onde ele pode fazer algo mais, o “quilômetro extra” (versão
brasileira da “Extra Mile” americana, que é aquilo feito além do
esperado, além das responsabilidades) por onde se pode andar,
onde se pode auxiliar na melhoria do processo para obter mais
qualidade do sistema e mais satisfação do cliente. Eventual-
mente, em um processo de maturidade elevada e profissional,
as pessoas opinam na forma como os colegas atuam, ou seja, o
desenvolvedor tenta melhorar o processo de testes, o analista
de testes ajuda o Scrum Master e esse pode ajudar nas funções
do “Product Owner” ou coordenador, por exemplo.

Scrum Master
Sua função principal é definir e manter o processo sendo
seguido, marcar e manter os ritos, garantir a presença de to-
dos (ou o máximo possível) os participantes, ver se cada ação

Edição 69 - Engenharia de Software Magazine 9

Analista de Testes
É responsável por validar e garantir a qualidade do sistema,
verificar que os critérios de aceite são devidamente atendidos,
nenhum bug escape ou deixe de ser registrado, que os testes
regressivos continuem aumentando, sendo atualizados, evo-
luindo, sendo executados em todos os critérios corretamente,
que o ambiente seja bem preparado para a Review, que os
testes sejam bem escritos e a cobertura seja adequada já no
Planning.
Outra função que o analista de testes costuma ter é for-
necer dados para as métricas do projeto, analisar quantos
defeitos são encontrados, quantos são corrigidos e quantos
novos defeitos são encontrados a partir disso. Além disso,
deve fornecer esses dados para a equipe de qualidade que irá
analisar o desenvolvimento do sistema e a performance dos
desenvolvedores, a evolução da equipe e se o processo está
sendo seguido corretamente.
Desenvolvedor
É responsável por criar o sistema, elaborar as funcionalida-
des, seguir corretamente os testes e critérios de aceite, analisar
pontos de exceção, levantar questões sobre o planning para
visualizar falhas de cobertura, pontuar com critério as histórias
inserindo também o tempo de testes de cada feature e o regres-
sion ao final do Sprint. Precisam também seguir o processo de
testes unitários definido e garantir que haja sempre evolução
na quantidade de testes e melhora na cobertura.
Analista de UX (Experiência de Usuário)
É responsável pelo desenho do sistema, interfaces com usu-
ário, a localização das funcionalidades, o resultado esperado
de cada ação, que o sistema tenha a melhor usabilidade, que
as funcionalidades sejam práticas, atendam padrões dos
fabricantes (no caso de aplicativos móveis, por exemplo), que
mensagens de erro sejam evitadas, mas, caso necessário, é
responsável pelo texto da mensagem, pelo nome (“label”) dos
botões.
Além disso, deve analisar estatísticas do aplicativo, uso de
funcionalidades e priorizar aquilo que é o foco e que o usuário
mais procura no sistema. Também é responsabilidade do ana-
lista de UX pesquisar e fazer simulações com usuários, passar
10 Engenharia de Software Magazine - Scrum: uma visão prática do framework
formulários, para descobrir quais são as funcionalidades que
o usuário procura, e quais melhorias enriqueceriam o sistema
e trariam mais usuários.
Designer
O designer de um sistema é responsável pelo layout, escolha
de cores, logomarca, por aplicar o que o analista de produto
(UX) projetou.
Coordenador
É função do coordenador do projeto dar toda estrutura de
qualidade para que a equipe de forma adequada. Normalmen-
te, associa-se ao Scrum Master para garantir a manutenção dos
ritos e que o processo seja seguido. Além disso, atua no sentido
de auxiliar na correção dos pontos de melhoria.
Product Owner
É o dono do projeto, o cliente. É por ele que tudo começa,
quem toma as decisões, as histórias são priorizadas com a
opinião de todos mas de acordo com a vontade do PO. É ele
quem define os critérios de aceite, na função de cliente ele
utiliza todos os estudos do designer e do analista de UX para
definir quais melhor se encaixam com os objetivos de projeto,
e as necessidades de quem de fato utiliza o sistema. Também
é função dele atuar próximo à área de negócio para ajudar a
trazer patrocinadores, verba ou investimento ao projeto.
No Scrum, tudo ocorre ao redor das reuniões, por isso elas
são primordiais e precisam ser muito bem feitas. Essas etapas
precisam ser bem obedecidas para garantir a qualidade do
sistema e ter evolução no processo e no produto. Sendo bem
definidas as reuniões e ficando claras as funções e responsa-
bilidades de cada ator, as chances de desenvolver um projeto
de sucesso utilizando o Scrum serão maiores.
Você gostou deste artigo?
Dê seu voto em www.devmedia.com.br/esmag/feedback
Ajude-nos a manter a qualidade da revista!
Planejamento e Gerência
Nesta seção você encontra artigos voltados para o planejamento
e gerência de seus projetos de software.
Riscos em projetos de software com PMBOK
Fabiana de Lima
fabianadelima@gmail.com
Mestre em Ciência da Computação na sub-
área de Engenharia de Software, atua como
professora e pesquisadora na área. Exerceu
funções de analista de sistemas em empresas
de desenvolvimento de software e de recru-
tamento e seleção. Atualmente, atua como
professora formadora também em cursos de
EAD em Maringá - PR.
Fique por dentro:
A tarefa de gerenciar os custos do projeto englo-
ba, além do minucioso processo de planejamento
e definição dos custos e de seu gerenciamento,
a definição e escolha de bons orçamentos que
tragam valor agregado ao processo, e ainda, o
controle de tais recursos de forma a cumprir com
aquilo que foi definido inicialmente. Este artigo
apresenta uma abordagem para o gerenciamento
de custos em projetos da área de TI levando em
consideração os principais aspectos desse tipo de
gerência e mostra quais são os conhecimentos
A
área de TI para uma empresa
possui orçamentos altos, a
tecnologia custa caro e os ele-
mentos correspondentes também, um
bom servidor, por exemplo, pode passar
da casa dos R$ 15.000,00. Muitas vezes
o custo não é definido pela equipe de
projetos e sim pelo próprio cliente ou
área supervisora da TI na empresa, que
possui uma necessidade pulsante e esta-
belece limites de custos para resolvê-la.
Com isso, as características do software
ou das necessidades do cliente/área su-
pervisora podem, e geralmente o fazem,
Edição 69 - Engenharia de Software Magazine
utilizados nos processos que o compõe, propostos
pelo Guia PMBOK. O tema é útil, principalmente,
para gerentes de projetos que buscam aprofundar
seus conhecimentos no gerenciamento de custos
em projetos de desenvolvimento de software e
outros relacionados à área de TI. Serve também
para desenvolvedores de software que trabalhem
em equipes de projeto e que visem aprimorar
seus conhecimentos em busca de minimização
de custos para suas tarefas diárias, bem como, co-
nhecer um pouco mais sobre como os recursos de
um projeto são distribuídos e gerenciados.
definir uma variação no gerenciamento
de custos do projeto. Por isso, essa é
uma atividade extremamente dinâmica,
junto com o gerenciamento do escopo e
do tempo definem um tripé principal
da gerência de projetos na área de TI.
Ressalta-se aqui que outras áreas como a
qualidade, por exemplo, são de extrema
importância para um bom projeto.
A tarefa de gerenciar os custos do
projeto engloba, além do minucioso
processo de planejamento e definição
dos custos e de seu gerenciamento, a
definição e escolha de bons orçamentos
11
que tragam valor agregado ao processo,
e ainda, o controle de tais recursos de
forma a cumprir com aquilo que foi
definido inicialmente.
Um projeto que envolva o desenvolvi-
mento de software inclui as dificuldades
em se manter os custos iniciais, baseados
nos requisitos levantados no início do
projeto até o término dele. Nisso está a
importância, associada ao gerenciamen-
to de custos, também do escopo e tempo
em questão.
Os mecanismos necessários para o
gerenciamento de custos
Segundo o Guia de conhecimento
PMBOK, são quatro os elementos neces-
sários para o gerenciamento de custos de
um projeto: o plano de gerenciamento
de custos, a estimativa de custos, a de-
terminação de orçamentos e o controle
de custos.
Em pequenos projetos de desenvolvi-
mento, alguns desses processos podem
estar sobrepostos, sendo executados
de uma só vez como, por exemplo, o
planejamento do gerenciamento e a
estimativa de custos, resultando no de-
senvolvimento de orçamentos a serem
feitos. Neste artigo, eles serão mostrados
isoladamente, para que um entendi-
mento amplo de cada processo possa
ser obtido. Ressaltamos que existem
outros detalhes e ferramentas utilizadas
que são muito importantes para o bom
gerenciamento.
As tarefas de estimar custos e controlá-
los são as que demandam maior esforço
do gerente, já que, em projetos de desen-
volvimento de software as medições são
complexas de serem feitas e tornam-se
uma área a parte de estudos para que
um bom gerenciamento de custos possa
ser feito. Para a execução dos processos
referentes ao gerenciamento de custos,
três itens são importantes: as entradas, as
ferramentas e técnicas e as saídas.
Figura 1. Entradas, ferramentas e técnicas e saídas para o Plano de Gerenciamento de custos
12 Engenharia de Software Magazine - Riscos em projetos de software com PMBOK
As entradas são mecanismos utilizados
em cada processo, os quais podem ofere-
cer informações ou dados referentes ao
projeto, oriundos de fatores ambientais
da empresa (determinações já estabele-
cidas e que devam ser observadas para
o trabalho), ou de fatores externos (como
calendário dos recursos disponíveis) ou
ainda, gerados a partir de outros proces-
sos de gerenciamento do projeto (como
a baseline do escopo do projeto, plano de
riscos, dentre outros).
Já as ferramentas e técnicas utilizadas
podem ser um padrão (utilizadas em
todos os projetos da empresa) ou ainda
estarem sendo utilizadas pela primeira
vez no projeto em questão. Elas podem
ser desde estimativas de três pontos e
análise de reservas, passando por custos
relacionados à qualidade, até uma fer-
ramenta de software de gerenciamento
de projetos.
Por sua vez, as saídas são produtos,
fornecidos durante o gerenciamento
de custos, relacionados à execução de
um dos quatro processos, dentre esses
estão as estimativas de custos das ativi-
dades, previsões orçamentárias, dentre
outros. As saídas são elementos que
também podem variar muito, desde
atualizações no plano de gerenciamen-
to de projeto, passando por medidas
de performance de trabalho, indo até
uma baseline de custos e necessidades
de financiamento do projeto.
Em relação aos processos que já foram
citados, devemos ressaltar que em todos
eles o gerenciamento de custos pode ser
desenvolvido com métodos próprios ou
estabelecidos para determinada área de
aplicação de um projeto. A área de tec-
nologia da informação possui uma vasta
gama de métodos de análise e medições,
por exemplo, estimativas utilizadas em
metodologias ágeis de desenvolvimento
de software, como a partição de pontu-
ação das estórias definidas pelo cliente,
ou ainda, outras métricas como a análise
de pontos por função ou por casos de
uso. Esses métodos auxiliam em muito
o gerenciamento de custos, baseado no
escopo definido através deles.
Considera-se que, embora o guia traba-
lhe com os processos definidos, outros
métodos próprios para projetos de TI e
que não são tratados no PMBOK (já que
o objetivo do Guia é outro), podem ser
manipulados em conjunto e durante o
próprio gerenciamento de custos, reali-
zado através dos processos estabelecidos
no PMBOK.
A seguir, encontram-se os processos
necessários para o gerenciamento de
custos, exemplificados em sua maneira
de coexistirem em projetos de desenvol-
vimento de software. Esses processos
devem ocorrer pelo menos uma vez
em cada projeto e serem repetidos em
cada uma das fases em que um projeto
for dividido. De maneira diversificada,
eles fazem uso dos mecanismos (entra-
das, ferramentas e técnicas e saídas)
apresentados.
Plano de Gerenciamento de Custos
O processo de Planejar o Gerencia-
mento de Custos envolve a definição e o
destino dos recursos disponíveis para o
projeto. Em projetos de TI, normalmente
esses recursos são destinados a pessoal e
infraestrutura, contando algumas vezes
com elementos de treinamento e implan-
tação do produto ou serviço.
A Figura 1, retirada do Guia PMBOK,
ilustra o conjunto de entradas, de ferra-
mentas e técnicas e de saídas que estão
presentes nesse primeiro processo de
gerenciamento de custos, Plano do Ge-
renciamento de Custos.
A seguir apresentam-se as entradas
pertencentes a esse processo, com um
exemplo de como elas podem ser conse-
guidas em projetos de desenvolvimento
de software:
• Plano de gerenciamento de projeto: é
um documento que contém as diretrizes
iniciais para o projeto, levando em consi-
deração todas as áreas de gerenciamento.
Ele serve como entrada, pois, contém as
principais definições feitas a partir das ne-
cessidades também iniciais apresentadas
pelo cliente/usuário no ato de contratação

do projeto. Elementos como as formas
adotadas para o trabalho, paradigmas
de desenvolvimento, possibilidades de
infraestrutura, participação do usuário
no projeto, recursos humanos disponíveis,
stakeholders, dentre outros são elementos
que podem ser definidos nesse processo
e documentados com maior precisão em
suas respectivas áreas de processo;
• Contrato do projeto: esse é um docu-
mento formal que contém uma descrição
inicial sobre os requisitos do sistema, em
alto nível, além de recursos financeiros
disponíveis, marcos e entregas, dentre
outros;
• Fatores ambientais da empresa: são
elementos como normas, padrões ou
diretrizes estabelecidos que podem vir
a influenciar nos custos de desenvolvi-
mento do projeto;
• Ativos de processo organizacional:
são elementos conseguidos a partir da
realização de outros projetos na empre-
sa, que possam vir a direcionar melhor
o gerenciamento de custos do projeto.
Um exemplo claro são definições ante-
riores de recursos necessários X áreas de
trabalho, ou ainda, recursos financeiros
X recursos humanos em outros projetos
da área.
De posse desses elementos de entrada,
a tarefa de Planejar o Gerenciamento de
custos pode ser executada. A partir do
uso das ferramentas e técnicas a seguir,
exemplificamos de forma simples seu
uso para o desenvolvimento de um
software:
• Opinião especializada: qualquer opi-
nião de membros técnicos pertencente ao
grupo de stakeholders ou que participa-
ram de projetos anteriores definindo e
planejando custos destinados a ativida-
des de projeto podem ser ouvidas, para
que melhores estimativas dos recursos
possam ser feitas no projeto;
• Técnicas analíticas: a experiência no
planejamento de quais técnicas poderão
ser melhor aproveitadas para a defini-
ção e o gerenciamento de custos é um
importante fator para o planejamento
de ferramentas de auxílio ao gerencia-
mento de custos que se pode utilizar,
qual(is) técnica(s) de análise e estimativa
de recursos para as atividades será(ão)
Figura 2. Entradas, ferramentas e técnicas e saídas para o processo Estimar os Custos
utilizadas, dentre outras. Novamente,
ouvir e conhecer quais softwares e
técnicas são utilizadas no ambiente
organizacional é uma boa prática para
planejar a definição de custos que serão
produzidos no projeto;
• Reuniões: a equipe de projeto deve
ser reunida para planejar como o geren-
ciamento e a distribuição dos recursos
será realizada. Podem participar dessa
reunião, o gerente de projetos, o patro-
cinador, membros da equipe seleciona-
dos, stakeholders selecionados, enfim,
qualquer membro do projeto que tenha
responsabilidade sobre a boa execução
do gerenciamento de custos do mesmo.
A partir da realização dessas tarefas,
para o Planejamento do Gerenciamento
de Custos, deve ser produzido como
saída:
• Plano de gerenciamento de custos: em
projetos de TI ele pode ser visto como
um documento simples que contenha
as principais atividades representativas
do gerenciamento de custo em questão.
Podendo conter uma análise referente a
quais recursos serão destinados a pes-
soal, como técnicos, programadores, ge-
rentes, possíveis serviços terceirizados,
e ainda, a forma como os recursos serão
destinados à infraestrutura necessária
para o projeto, dentre outras.
Estimativa de Custos
O processo de estimar os custos do
projeto envolve uma análise crítica de
quais serão as devidas necessidades
dentro da relação espaço (atividade) X
tempo do projeto. Custos em relação a
mão de obra podem ser feitos, porém,
é necessário que isto esteja alinhado
Edição 69 - Engenharia de Software Magazine
planejamento
à duração das atividades e do projeto
como um todo.
A Figura 2, retirada do Guia PMBOK,
ilustra o conjunto de entradas, de ferra-
mentas e técnicas e de saídas que estão
presentes nesse segundo processo de
planejamento, Estimar os Custos.
A seguir apresentam-se as entradas
pertencentes a esse processo, com um
exemplo de como elas podem ser conse-
guidas em projetos de desenvolvimento
de software:
• Plano de gerenciamento de custos:
produzido como saída no processo ante-
rior, tem como principal objetivo nortear
a forma como o gerenciamento de custos
será realizado no projeto;
• Plano de gerenciamento de recursos
humanos: produzido durante o processo
de gerenciamento de recursos humanos
traz pessoas, papéis e cargos referentes
ao desenvolvimento de todo o projeto.
Deve-se ressaltar que em todo o projeto
stakeholders das mais diferentes origens
podem ter participação ativa;
• Linha de base do escopo: é a espe-
cificação do escopo do projeto, com as
principais entregas e os requisitos de
aceitação. Os documentos que vão sendo
produzidos durante o planejamento do
escopo fazem parte dessa base para o
projeto;
• Cronograma do projeto: este docu-
mento é produzido durante o processo
de gerenciamento do tempo do projeto e
deve conter no mínimo as datas (início e
término) planejadas para as atividades,
as metas, os recursos necessários e o
encadeamento natural das atividades de
acordo com as restrições empregadas;
• Registro de riscos: conseguidos a
partir do processo de gerenciamento de
13
riscos do projeto são eficientes para que fiquem claros quais
são os riscos de uma seleção ou de uma disponibilização de
determinado recurso do projeto, dentre outras;
• Fatores ambientais da empresa: são elementos como normas,
padrões ou diretrizes estabelecidos que podem vir a influen-
ciar os custos de desenvolvimento do projeto;
• Ativos de processo organizacional: são elementos consegui-
dos a partir da realização de outros projetos na empresa, que
possam vir a direcionar melhor o gerenciamento de custos
do projeto. Um exemplo claro são as linhas de base (baselines)
do projeto, ou ainda, definição de recursos produzidos em
antigos projetos.
De posse desses elementos de entrada, a tarefa de Estimati-
va dos Custos pode ser executada, a partir do uso das ferra-
mentas e técnicas a seguir, exemplificamos de forma simples
seu uso para o desenvolvimento de projetos em TI:
• Opinião especializada: qualquer membro técnico perten-
cente ao grupo de stakeholders do projeto pode ser ouvido,
para que, a partir de dados e experiências em projetos ante-
riores, decisões possam ser tomadas com o intuito de reali-
zar estimativas consistentes para o projeto em questão;
• Estimativa análoga: estimar utilizando essa técnica sig-
nifica ter como base projetos anteriores semelhantes para
o cálculo dos recursos do atual projeto. Ela necessita de
menos custos para ser aplicada, porém, é também menos
precisa que outras técnicas que podem ser utilizadas, como
as que seguem;
• Estimativa paramétrica: essa técnica se utiliza de dados
estatísticos de projetos anteriores para realizar uma estima-
tiva para parâmetros conhecidos. Exemplo de parâmetros
são orçamento, duração, dentre outros;
• Estimativas de três pontos: se baseia em três casos para
estimar: a análise do melhor cenário, a do pior cenário e a
do cenário mais realista possível, determinado a partir das
dependências e expectativas de atividades prováveis;
• Análise de reservas: um esquema de identificação de
percentual para reserva de trabalho, com o intuito de su-
prir incertezas do cronograma pode ser utilizado. Nessa
técnica, conforme os dados passam a ser mais reais, as
reservas podem também ser melhoradas, reduzidas ou até
eliminadas;
• Custo da qualidade: englobam os custos durante toda
a vida do produto, como os de atendimento aos requisitos
de qualidade, de retrabalho, ou ainda de prevenção do não
cumprimento dos requisitos. Como custos de atendimento
aos requisitos podemos citar: testes de aceitação do sistema;
já os de retrabalho podem ser gerados por: falhas internas
de programação ou de documentação do software; e os
de prevenção: como um treinamento de usuários antes de
colocar o sistema em operação;
• Software de gerenciamento de projetos: existem diversas
ferramentas de auxílio à definição, monitoramento e contro-
le de recursos para as atividades de projetos. Ferramentas
de controle de custos normalmente disponibilizam toda a
14 Engenharia de Software Magazine - Riscos em projetos de software com PMBOK
estrutura para controle dos recursos e tempo das atividades
em questão. Um exemplo de software livre com essa função
é o OpenProject citado na seção Links;
• Análise de proposta de fornecedor: de posse de propostas
de fornecedores para o que é necessário para a realização do
projeto, o gerente deve analisar as mesmas para adequar: ex-
pectativas, custos necessários e valores agregados. Isso pode
levar ao resultado total de quanto o projeto custaria para ser
realizado. Este ainda pode ser a soma de valores de entregas
individuais do projeto, quando subprodutos do projeto devem
ser desenvolvidos de forma independente;
• Técnicas de tomada de decisão em grupo: nessas técni-
cas o envolvimento da equipe de projeto nas estimativas
proporcionam maior comprometimento da mesma com os
gastos previstos X realizados. Nesse contexto, técnicas como
Brainstorming ou o particionamento por pontuação de estórias
do cliente, usados em metodologias ágeis, são boas formas de
envolvimento da equipe nas estimativas.
A partir da realização dessas tarefas para a Estimativa dos
Custos deve ser produzido como saída:
• Estimativas de custos das atividades: as estimativas finais
podem ser produzidas em detalhes ou de forma geral, de
acordo com a necessidade do projeto. Essas estimativas devem
conter todos os custos necessários para o desenvolvimento do
projeto, inclusive custos de possíveis distorções na própria
análise dos custos;
• Bases das estimativas: todas as suposições e critérios utili-
zados para a estimativa dos custos devem estar claros para que
se possa verificar possíveis erros com facilidade. Quando do
uso de intervalos, do tipo valor estará entre: x-10% e x+10%)
este deve estar bem especificado, não contendo somente o
valor médio indicado. Enfim, tudo o que for considerado
deverá estar relatado nesse tópico, independente se haverá
uma descrição sucinta ou detalhada dos motivos pelos quais
adotou-se tal critério;
• Atualização de documentos do projeto: são produzidos
de acordo com as modificações realizadas a partir do plane-
jamento de custos do projeto. elas podem ser de melhoria ou
adequações e podem gerar modificações em diversos docu-
mentos, dependendo de sua origem. Exemplo: uma definição
ou mudança nos custos do projeto, pode gerar mudanças de
cronograma de atividades do projeto, mudanças no planeja-
mento dos riscos do projeto, ou ainda, definição para aquisição
ao invés de produção no projeto, dentre outros.
Determinar o orçamento
O processo de determinar o orçamento do projeto é uma
tarefa que depende, além dos produtos (saídas) dos processos
anteriores do gerenciamento de custos, também de produtos
oferecidos por outros processos de gerenciamento, como o
escopo e o tempo.
A Figura 3, retirada do Guia PMBOK, ilustra o conjunto de
entradas, de ferramentas e técnicas e de saídas que estão pre-
sentes nesse terceiro processo de Determinar o orçamento.

A seguir, apresenta-se as entradas
pertencentes a esse processo, com um
exemplo de como elas podem ser conse-
guidas em projetos de desenvolvimento
de software:
• Plano de gerenciamento de custos:
produzido como saída no inicial, tem
como principal objetivo nortear a forma
como o gerenciamento de custos será
realizado no projeto;
• Linha de base do escopo: é a especifica-
ção do escopo do projeto, com as principais
entregas e os requisitos de aceitação. Os
documentos que vão sendo produzidos
durante o planejamento do escopo fazem
parte dessa base para o projeto;
• Estimativas de Custo das atividades:
obtida como saída do processo anterior
traz uma visão da relação custo X ativi-
dades para os elementos do projeto;
• Bases de estimativas: que também são
obtidas a partir do processo anterior de
forma a oferecer suporte para o orçamen-
to total do projeto;
• Cronograma do projeto: este docu-
mento é produzido durante o processo
de gerenciamento do tempo do projeto e
deve conter no mínimo as datas (início e
término) planejadas para as atividades,
as metas, os recursos necessários e o
encadeamento natural das atividades de
acordo com as restrições empregadas;
• Calendár ios dos recursos: nele
estarão indicadas as datas em que os
recursos como materiais, pessoas ou
equipamentos estarão sendo usados
por outros projetos ou ainda liberados
para o uso. Nesse processo a obtenção
desse calendário é uma condição pri-
mordial para as estimativas. Além do
que essa informação é importante, para
identificar a possibilidade de trabalho
de determinado membro da equipe em
seu projeto; como para que o projeto es-
teja preparado para riscos de eventuais
atrasos quando se tratar de um recurso
advindo de outra região, ou que depende
de fatores ambientais ou temporais (final
de ano, recessos ou grandes feriados)
para serem adquiridos;
• Registro de riscos: conseguidos a
partir do processo de gerenciamento de
riscos do projeto são eficientes para que
fiquem claros quais são os riscos de uma
seleção ou de uma disponibilização de
determinado recurso do projeto, dentre
outras;
• Contratos: informações de contratos
e os custos dos mesmos sejam eles para
aquisições de bens ou de serviços devem
ser relatados para que os custos possam
fazer parte do orçamento total do proje-
to. Um exemplo é o contrato de serviço
para fornecimento de Internet em proje-
tos de desenvolvimento em TI;
• Fatores ambientais da empresa: são
elementos como normas, padrões ou
diretrizes estabelecidos que podem vir
a influenciar os custos de desenvolvi-
mento do projeto;
• Ativos de processo organizacional:
são elementos conseguidos a partir
da realização de outros projetos na
empresa, que possam vir a direcionar
melhor o gerenciamento de custos do
projeto. Um exemplo claro são as linhas
de base (baselines) do projeto, ou ainda,
definição de recursos produzidos em
antigos projetos.
De posse desses elementos de entrada,
a tarefa de Determinar o Orçamento
pode ser executada, a partir do uso das
ferramentas e técnicas. A seguir, exem-
plificamos de forma simples seu uso
para o desenvolvimento de um software:
• Agregação de custos: os custos devem
ser agregados de acordo com a estrutura
hierárquica da EAP. Assim, custos totais
de um pacote presente no nível final da
EAP são agregados aos custos de outros
pacotes no mesmo nível para formarem
o custo total do elemento presente no
EAP no nível superior a eles, consecuti-
vamente até que o custo total do projeto
possa ser calculado;
• Análise de reservas: um esquema de
identificação de percentual para reser-
va de custos, com o intuito de suprir
Figura 3. Entradas, ferramentas e técnicas e saídas para a Determinação do Orçamento
Edição 69 - Engenharia de Software Magazine
planejamento
incertezas no orçamento pode ser utili-
zado. Nessa técnica, conforme os dados
passam a ser mais reais, as reservas po-
dem também ser melhoradas, reduzidas
ou até eliminadas;
• Opinião especializada: qualquer opi-
nião de membros técnicos pertencente ao
grupo de stakeholders ou que participa-
ram de projetos anteriores definindo e
planejando custos destinados a ativida-
des de projeto podem ser ouvidas, para
que melhores estimativas dos recursos
possam ser feitas no projeto;
• Relações históricas: elas podem ser
utilizadas para a realização de análises
paramétricas ou análogas, de forma que
custos estimados em outros projetos pos-
sam servir de suporte para a definição
de custos de um novo projeto;
• Restrição de limites financeiros: o
cronograma de projeto pode auxiliar
muito na relação de definição das
restrições existentes para o projeto.
Tarefas em paralelo ou subsequên-
ciais podem dispensar mais ou menos
recursos.
A partir da realização dessas tarefas
para a Determinação do Orçamento as
seguintes saídas devem ser produzidas:
• Linha de base de custos: relaciona-se
ao orçamento total do projeto em função
do tempo e de pequenos orçamentos
intermediários de entregas e marcos
particulares.
• Requisitos de recursos financeiros do
projeto: produzidos para que os recur-
sos necessários para o projeto possam
ser adquiridos ao longo do desenvolvi-
mento do mesmo, sem perda de poder de
execução, antecipando os mesmos para
sua aplicação no tempo devido.
• Atualização de documentos do pro-
jeto: são produzidos de acordo com
15
as modificações realizadas a partir da
determinação do projeto. elas podem
ser de melhoria ou adequações e podem
gerar modificações em diversos docu-
mentos, dependendo de sua origem.
Exemplo: uma definição ou mudança
no orçamento do projeto, pode gerar
mudanças de cronograma de atividades
do projeto, mudanças no planejamento
dos riscos do projeto, ou ainda, definição
para aquisição ao invés de produção no
projeto, dentre outros.
Controlar os custos
O Controle de custos do projeto deve
ser realizado durante todo o projeto.
Assim, possíveis distorções encontradas
durante a execução do projeto podem
ser minimizadas em fases posteriores e
antes do término para que possam ser
recuperadas.
A Figura 4, retirada do Guia PMBOK,
ilustra o conjunto de entradas, de ferra-
mentas e técnicas e de saídas que estão
presentes nesse último processo de
Controlar os Custos.
A seguir, apresenta-se as entradas
pertencentes a esse processo, com um
exemplo de como elas podem ser conse-
guidas em projetos de desenvolvimento
de software:
• Plano de gerenciamento de projeto: é
um documento que contém as diretrizes
iniciais para o projeto, levando em consi-
deração todas as áreas de gerenciamento.
Ele serve como entrada, pois, contém
as principais definições feitas a partir
das necessidades também iniciais apre-
sentadas pelo cliente/usuário no ato de
contratação do projeto. Elementos como
as formas adotadas para o trabalho,
paradigmas de desenvolvimento, possi-
bilidades de infraestrutura, participação
Figura 4. Entradas, ferramentas e técnicas e saídas para o Controle dos Custos
16 Engenharia de Software Magazine - Riscos em projetos de software com PMBOK
do usuário no projeto, recursos humanos
disponíveis, stakeholders, dentre outros
são elementos que podem ser definidos
nesse processo e documentados com
maior precisão em suas respectivas áreas
de processo;
• Requisitos de recursos financeiros
do projeto: produzidos no processo an-
terior para que os recursos necessários
para o projeto possam ser adquiridos ao
longo do desenvolvimento do mesmo,
sem perda de poder de execução, ante-
cipando os mesmos para sua aplicação
no tempo devido;
• Dados de performance do trabalho:
é a forma de medir o andamento das
atividades verificando, por exemplo,
o cumprimento de tarefas e os custos
necessários para executá-las;
• Ativos de processo organizacional:
são elementos conseguidos a partir da
realização de outros projetos na empre-
sa, que possam vir a direcionar melhor
o gerenciamento de custos do projeto.
Um exemplo claro são definições ante-
riores de recursos necessários X áreas de
trabalho, ou ainda, recursos financeiros
X recursos humanos em outros projetos
da área.
De posse desses elementos de entrada,
a tarefa de Controle dos Custos pode ser
executada, a partir do uso das ferramen-
tas e técnicas a seguir, exemplificamos
de forma simples seu uso para o desen-
volvimento de um software:
• Gerenciamento do valor agregado:
deve ser usado, utilizando-se custos,
tempo e atividades, para cálculo de
performance do projeto;
• Previsões, índice de performance
para conclusão: baseado nos índices de
desempenho de projeto a equipe, ainda
durante a realização do mesmo, pode
prever melhorias no próprio orçamento
definido previamente, realizando, assim,
também as revisões de performance;
• Software de gerenciamento de pro-
jetos: existem diversas ferramentas de
auxílio à definição, monitoramento e
controle de recursos para as atividades
de projetos. Ferramentas de controle de
custos normalmente disponibilizam
toda a estrutura para controle dos recur-
sos e tempo das atividades em questão,
como citado anteriormente;
• Análise de reserva: um esquema
de identificação de percentual para
reserva de trabalho, com o intuito de
suprir incertezas do cronograma pode
ser utilizado. Nessa técnica, conforme
os dados passam a ser mais reais, as re-
servas podem também ser melhoradas,
reduzidas ou até eliminadas.
A partir da execução das tarefas neces-
sárias para o Controle dos Custos as se-
guintes saídas devem ser produzidas:
• Informação da performance do traba-
lho: serão geradas a partir das análises
feitas durante todo o processo de geren-
ciamento e devem ser mapeadas nos seus
respectivos documentos de projeto;
• Previsões de custo: os orçamentos rea-
lizados devem então serem comunicados
às partes necessárias para que possam
ser utilizados;
• Solicitações de mudanças: com base
na performance, na definição de orça-
mento e ainda em mudanças de escopo
e tempo, possíveis solicitações de mu-
danças podem vir a ocorrer de forma a
integrar novamente o projeto em suas
áreas de gerenciamento;
• Atualização do plano de gerencia-
mento do projeto: o plano de gerencia-
mento do projeto deve ser atualizado
para conter as definições necessárias que
estabelecidas a partir do gerenciamento
dos custos que foi realizado;
• Atualização do documento de pro-
jeto: o documento de projeto deve ser
atualizado para conter as definições
necessárias e que foram estabelecidas a
partir do gerenciamento dos custos que
foi realizado;
• Atualização dos ativos de proces-
sos organizacionais: atualizações nos

documentos que contém dados, conseguidos a partir da
realização de outros projetos na empresa, devem ser atuali-
zados com os dados do projeto atual para possíveis futuras
experiências.
Sabemos que o gerenciamento deve ser iniciado com um pla-
nejamento para o mesmo tendo como base diversos elementos
do projeto, tais como, as atividades definidas no gerenciamento
do escopo e o cronograma do projeto. Essas três grandes áreas
do gerenciamento (trazidas pelo PMBOK) tempo, escopo e
custos estão intrinsecamente relacionadas, criando-se uma
dependência mútua entre as mesmas.
Os conhecimentos apresentados não fornecem um padrão,
eles se traduzem por um Guia, que pode ser modificado,
melhorado ou seguido em sua completude de acordo com o
projeto a ser gerenciado.
Ressalta-se aqui que esses processos possuem uma lógica
sequencial didática, porém, sua execução pode ter atividades
sobrepostas em muitos casos, durante o Gerenciamento dos
Custos, como por exemplo, as atividades de estimar os custos
e definir o orçamento.
planejamento
Os processos estabelecidos devem também se relacionar
com outras áreas de gerenciamento de projetos descritas no
PMBOK. Ora oferecendo entradas para outros processos, ora
recebendo como entrada elementos produzidos por eles e que
serão necessários para o desenvolvimento do Gerenciamento
dos Custos.
Links:
PMI no Brasil – a Maior Associação Mundial para Profissionais de Gerencia-
mento de Projetos
http://brasil.pmi.org/
Página do projeto OpenProject
http://sourceforge.net/projects/openproj/
Você gostou deste artigo?
Dê seu voto em www.devmedia.com.br/esmag/feedback
Ajude-nos a manter a qualidade da revista!
Edição 69 - Engenharia de Software Magazine 17
Planejamento e Gerência
Nesta seção você encontra artigos voltados para o planejamento
e gerência de seus projetos de software.
Riscos em projetos de software com PMBOK
Jhoney Lopes
jhoney.lopes@gmail.com
Bacharel e mestrando em Ciência da Com-
putação pela Universidade Federal de Viçosa.
Atua na área de Ciência da Computação, com
ênfase em Engenharia de Software. Desenvol-
vedor iOS, Embaixador certificado em Negócios
Sociais no Brasil e co-criador do Catálise Social
(www.catalisesocial.com). Áreas de interesse:
Engenharia de Software, Empreendedorismo,
Gerenciamento de Projetos e Risco.
José Luis Braga
zeluis@dpi.ufv.br
Pós-doutoramento em Tecnologias da Infor-
mação na University of Florida (1988-1999).
Doutor em Informática-Departamento de In-
formática da PUC-Rio (1990). Mestre em Ciên-
cias da Computação-Departamento de Ciência
da Computação da UFMG (1980). Atualmente
é Professor Titular do Departamento de Infor-
mática do Centro de Ciências Exatas e Tecno-
lógicas da Universidade Federal de Viçosa-MG.
Atua na área de Ciência da Computação, com
ênfase em Engenharia de Software e Sistemas
de Informação.
18 Engenharia de Software Magazine - Riscos em projetos de software com PMBOK
Fique por dentro:
A gerência de projetos é amplamente estudada e
possui diversas ferramentas que auxiliam na efici-
ência e eficácia da produção de software. Uma de
suas atribuições é o gerenciamento de riscos, pois
existem inúmeros riscos que envolvem o desen-
volvimento de software Riscos são situações de
incertezas que envolvem escolhas relacionadas
com decisões que estão ligadas diretamente aos
riscos. Uma vez conhecidos os riscos, as decisões
podem reduzir perdas, aumentar ganhos ou, o
contrário, levando a prejuízos.
R
isco é falta de informação, a
incerteza é a base do risco, por
essa razão ele está no futuro.
O passado é conhecido, logo é possí-
vel saber quais incertezas afetaram
positivamente ou negativamente. Por
mais que cada pessoa seja única e viva
experiências individuais, o cotidiano é
cercado de influências comuns, que for-
necem informações que são mapeadas e
utilizadas por todos como, por exemplo,
o melhor caminho para ir ao trabalho,
o melhor tipo de investimento, quanto
O objetivo principal do artigo é apresentar fato-
res de risco que impactam o desenvolvimento de
software, classificá-los em grupos e proporcio-
nar uma visão dos relacionamentos entre eles e
como essas informações auxiliam na tomada de
decisões. O tema é útil para auxiliar no geren-
ciamento de projetos de software, como método
de controle dos possíveis riscos que impactam
o desenvolvimento do projeto. O uso desse co-
nhecimento é indispensável para evitar perdas
financeiras, atrasos, erros, retrabalhos e perdas
de outros recursos.
tempo gasta-se de casa até o destino
final, e outros.
Risco não é associado com certeza,
sendo assim, quando uma ação é de ris-
co, não se pode definir a mesma sendo
ruim ou boa. Existem diversos esportes
de alto risco como, por exemplo, o pa-
raquedismo. Durante um salto, o para-
quedas pode desdobrar no ar da melhor
maneira possível, mas em outros casos
isso pode não acontecer. As pessoas não
deixaram de praticar o esporte por causa
desse perigo, elas mapearam as formas

indesejadas da abertura do paraquedas e desenvolveram téc-
nicas para lidar com cada uma delas.
Criar soluções para lidar com as incertezas não se restringe
ao esporte. Inovar é assumir riscos e é necessário arriscar
para quebrar o “status quo”. Sejam inovações disruptivas
(ver BOX 1), em processos, em modelos ou outros, a intenção
é aproveitar uma oportunidade para melhorar algo. Essa
busca pela melhoria constante obriga a esbarrar continua-
mente com o desconhecido. Todo caminho novo tem incer-
tezas associadas, mas muitas vezes possui características
que interceptam com outros já conhecidos. Gerenciar riscos
é utilizar de conhecimentos prévios para minimizar efeitos
indesejados. Este artigo fornece um conjunto de informações
para auxiliar o gerente de projetos a enxergar os pontos po-
sitivos e negativos das decisões em projetos de software.
BOX 1. Inovações disruptivas
Disruptivo é algo que quebra conceitos, ruptura ou rompimento de algo. Uma inovação
disruptiva é um produto, serviço ou tecnologia que rompe ideias preestabelecidas, ou seja, algo
que extrapola o até então conhecido.
O risco pode ser visto de várias formas. Primeiro, risco gira
em torno dos acontecimentos futuros. A questão é: pode-se
mudar ações hoje, a fim de criar oportunidades para uma
melhor situação amanhã? Segundo, risco envolve mudanças,
tais como mudança de mentalidade, opinião, ações, ou lugares.
Em um mundo estático, não existe risco, logo, esse é o terceiro
aspecto do risco. Risco envolve escolhas, e todas as incertezas
que essas escolhas trazem.
O gerenciamento dos riscos em áreas como administração,
economia, estatística e matemática financeira, além de ser muito
empregado é tratado como elemento chave para tomada de de-
cisão. O risco envolvido em projetos é uma condição ou evento
incerto que, se ocorrer, terá um efeito positivo ou negativo. Esses
efeitos podem ser no prazo, custo, esforço e qualidade. Um risco
pode ter diversas causas e, se ele acontecer, pode ter diversos im-
pactos. Uma causa é uma condição que favorece o acontecimento
de resultados positivos ou negativos. Por exemplo, a causa pode
ser uma mudança no escopo, a falta de conhecimento ou pessoas
insuficientes para executar um projeto, entre outros.
O processo de manipulação dos riscos é realizado com a análise
e gerenciamento. Na análise estão as etapas de identificação, esti-
mativa e avaliação, já o gerenciamento é entendido como controle
do planejamento e o monitoramento do sucesso dos mecanismos
de controle. Esse processo tem como objetivo básico observar o
que pode dar errado e auxiliar nas tomadas decisões.
A Figura 1 apresenta a visão geral do gerenciamento de riscos
apresentado no PMBOK e possui os seguintes itens:
• Planejamento do gerenciamento de risco: o processo de
definição de como conduzir as atividades do gerenciamento
de risco;
• Identificação dos riscos: processo de determinação de
quais riscos podem afetar o projeto e documentação de suas
características;
planejamento
• Análise qualitativa dos riscos: processo de priorização dos
riscos para análise ou ação adicional através da avaliação e
combinação de sua probabilidade de ocorrência e impacto;
• Análise quantitativa dos riscos: o processo de analisar
numericamente o efeito dos riscos identificados nos objetivos
gerais do projeto;
• Planejamento de respostas aos riscos: processo de desen-
volvimento de opções e ações para aumentar oportunidades
e reduzir ameaças aos objetivos do projeto;
• Monitoramento e controle de riscos: processo de imple-
mentação de planos de respostas aos riscos, acompanhamento
dos riscos identificados, monitoramento dos riscos residuais,
identificação de novos riscos, e avaliação da eficácia do pro-
cesso de risco durante todo o projeto.
Na figura são apresentadas as entradas, ferramentas técnicas
e saídas dos principais processos de gerenciamento de risco.
Para obter sucesso, uma organização deve estar compromis-
sada em realizar gerenciamento de risco de forma proativa e
consciente. Uma escolha consciente deve ser feita em todos
os níveis da organização para identificar e seguir um efetivo
gerenciamento de risco durante todo o ciclo de vida de um
projeto. O gerente de projetos pode utilizar a Figura 1 para
organizar um plano de ação de gerenciamento de risco.
A gestão de riscos tornou-se uma preocupação global, os
efeitos indesejados dos riscos se transformaram em uma
apreensão. Por esse motivo, em 2009, saiu a norma ISO 31000
e no Brasil foi lançada em 30/11/2009 a ABNT NBR ISO 31000
- Gestão de Riscos, Princípios e Diretrizes. A norma ISO 31000
tem reconhecimento internacional, não tem finalidade de
certificação, mas é uma ferramenta de auxílio às empresas,
trazendo uma forte vantagem competitiva.
Observa-se que os projetos de desenvolvimento de software, em
geral, apresentam atrasos de cronogramas, custos realizados além
do planejado e funcionalidades aquém das expectativas. Esses
problemas, embora considerados inerentes ao desenvolvimento
de software por muitos autores, podem ser minimizados e con-
trolados pelo contínuo gerenciamento de risco em projetos.
O tempo de reação aos riscos é um fator preponderante para a
economia, como pode ser visto na Figura 2. A reação imediata,
feita no momento da identificação e da análise dos riscos, na
fase inicial, é chamada de reação de prevenção, e acontece
antes da decisão final sobre o projeto, alterando as principais
variáveis de impacto no projeto, como escopo, qualidade,
tempo ou condições financeiras. O quanto antes ocorrerem
a identificação, prevenção e contingência relacionadas aos
riscos, menores serão os custos de impacto ao projeto. Em
contraposição, a estimativa de custo do projeto possui maior
nível de acerto com o passar do tempo.
A Figura 3 é conhecida como Cone de incerteza, sua leitura
mostra que, no início do projeto, a estimativa possui maior
taxa de erro. Estimativas realizadas na fase conceitual po-
dem ter um erro de quatro vezes, ou um-quarto do valor
estimado; o erro se reduz com o aumento do conhecimento
sobre o projeto.
Edição 69 - Engenharia de Software Magazine 19
Figura 1. Visão geral do gerenciamento de riscos do projeto

Figura 2. Momento da reação diante dos riscos

A figura apresenta de modo simples um direcionamento

do melhor momento para a determinação do custo real do
projeto, embora seja compreensível que o erro decresce com
o tempo, esse gráfico não leva em consideração a necessidade
do cliente em saber o mais rápido possível o valor do projeto.
Essa distância entre a assertividade e os interesses do mer-
cado, é que fazem surgir diversos riscos, e também indicam
momentos em que decisões precisam ser tomadas.
Figura 3. Cone de incerteza, melhoria da estimativa de custo ao longo do
tempo
Riscos podem ser considerados positivos ou negativos.
Alguns são oportunidades gerenciais, assim, encontrar essas
oportunidades e maximizar seus efeitos gera uma vanta-
gem ao gerente. Por exemplo, em uma equipe pequena de

20 Engenharia de Software Magazine - Riscos em projetos de software com PMBOK

 planejamento

desenvolvimento acarreta riscos a saída de um desenvolvedor, Existem diversos riscos negativos no desenvolvimento de
com grande impacto negativo no projeto mas, em contrapar- software. Estudos mostram que 25% dos sistemas de software
tida, uma equipe desse tamanho é mais fácil de ser alinhada, de larga escala em desenvolvimento são cancelados. Em média,
gerenciada e treinada; nessa situação cabe o gerenciamento projetos ultrapassam o prazo de desenvolvimento em mais
otimista para manter a equipe motivada e coibir saídas de da metade do tempo planejado, projetos maiores geralmente
colaboradores. são piores. Apenas 25% dos projetos de larga escala não são
considerados “falhas operacionais”, os outros 75%, ou não
Autores funcionam como previsto ou não são usados na íntegra.
Fatores de Risco a B c d
1. Mudança de Escopo/objetivos X X X X Riscos no desenvolvimento de software
A seguir é apresentada uma lista de riscos que impactam o
2. Falta de envolvimento adequado dos usuários X X X
desenvolvimento de software. Na Tabela 1 são listados trinta
3. Requisitos mal entendidos e/ou mal definidos X X X
e três fatores de risco, organizados por ordem de relevância.
4. Escopo/objetivos pouco claros ou equivocados X X X Essa lista é um trabalho exploratório com gerentes de projeto
5. Prazos e tempo para tarefas mal estimados X X X de software de diversas localidades no Brasil e em Hong Kong,
6. Gerenciamento impróprio de mudanças X X X Finlândia e Estados Unidos da América.
7. Volatilidade nos requisitos (falta de requisitos estáticos) X X X
Grupos de fatores de risco
8. Custos mal estimados X X X
A partir dos riscos listados na Tabela 1, é possível observar
9. Falta de poderes para o gerenciamento de projetos X que alguns possuem impactos semelhantes nos projetos de
10. Conflito entre departamentos de usuário X X software como, por exemplo, mudança de escopo/objetivos;
11. Falha em gerenciar as expectativas finais dos usuários X X escopo/objetivos pouco claros ou equivocados; requisitos mal
12. Planejamento inexistente ou inadequado X X entendidos e/ou mal definidos; volatilidade nos requisitos
(falta de requisitos estáticos). Na Tabela 2 é apresentada uma
13. Pessoal envolvido insuficiente/inapropriado X X X X
comparação entre diferentes grupos de fatores de risco.
14. Falta de conhecimento/competência dos envolvidos
X X X X
no projeto
Grupo 1 Grupo 2 Grupo 3
15. Falta de Cooperação dos usuários X X X
Novidade Tecnológica Tecnologia Conhecimento e incerteza tecnológica
16. Falta de metodologia efetiva em gerenciamento de
X X
projetos Complexidade da Aplicação Requisitos
Escopo e Requisitos
17. Controle pobre ou inexistente X X Tamanho da Aplicação Escopo
18. Adoção de novo método/tecnologia X X X Habilidades da Equipe
Equipe de desenvolvimento
Expertise Pessoas
19. Falha em obter comprometimento do cliente X X
Gestão de Projetos
20. Definição imprópria de papéis e responsabilidades X X - Financiamento
21. Falta de comprometimento da alta gerência X X X Processo de
-
22. Falta de motivação da equipe X desenvolvimento Gestão de projetos
- Planejamento
23. Falta de habilidade para o gerenciamento de projetos X X
Programação/
24. Assunto novo ou não familiar X X X -
Agendamento
25. Mudança no proprietário do projeto ou na alta - Patrocínio/Propriedade
X Relacionamento com cliente e usuário
gerência - Gestão de Relacionamentos
26. Rotatividade da equipe X Valor/importância atribuído ao
Ambiente Organizacional Ambiente Corporativo
27. Projeto com múltiplos fornecedores X projeto
28. Usar nova metodologia de desenvolvimento em Relacionamento com o ambiente
X - Dependências externas
projetos importantes externo

29. O sistema possui integração e interface com outros Tabela 2. Tabela comparativa entre os grupos de riscos propostos na
X X literatura
sistemas
30. Sistema complexo X
Tomando por base os dados apresentados na tabela anterior,
31. Tarefas complexas X X
é proposta uma nova lista de grupos de fatores de risco. Esses
32. Falta de tecnologias maduras/existentes X
conjuntos foram propostos para um melhor entendimento
33. Deficiência de execução em tempo real X acerca dos riscos. Segmentar os riscos em grupos facilita o
entendimento do gerente de projetos sobre o contexto de cada
Tabela 1. Levantamento dos fatores de risco do desenvolvimento de
software risco. Os seis grupos propostos são:

Edição 69 - Engenharia de Software Magazine 21

• Gestão de Dependências: relaciona-se com os riscos que
envolvem qualquer tipo de dependência, seja direta ou in-
direta com o software ou o projeto. As dependências podem
ser com relação a tecnologia, pessoas, fornecedor, outros
sistemas, etc.;
• Gestão de Escopos e Requisitos: todos os riscos que en-
volvem os escopos e os requisitos do projeto serão tratados
nesse grupo;
1. Gestão de Dependências
1.1. Gerenciamento impróprio de mudanças.
1.2. Falha em gerenciar as expectativas finais dos usuários.
1.3. O sistema possui integração e interface com outros sistemas.
1.4. Mudança no proprietário do projeto ou na alta gerência.
1.5. Projeto com múltiplos fornecedores.
1.6. Sistemas complexos.
2. Gestão de Escopo e Requisito
2.1. Mudança de Escopo/objetivos.
2.2. Requisitos mal entendidos e/ou mal definidos.
2.3. Volatilidade nos requisitos (falta de requisitos estáticos).
2.4. Escopo/objetivos pouco claros ou equivocados.
3. Gestão de Inovação e Tecnologias
3.1. Adoção de novo método/tecnologia.
3.2. Assunto novo ou não familiar.
3.3. Usar nova metodologia de desenvolvimento em projetos importantes.
3.4. Falta de tecnologias maduras/existentes.
3.5. Deficiência de execução em tempo real.
4. Gestão de Pessoas
4.1. Pessoal envolvido insuficiente/inapropriado.
4.2. Falta de conhecimento/competência dos envolvidos no projeto.
4.3. Falta de habilidade para o gerenciamento de projetos.
4.4. Falta de motivação da equipe.
4.5. Rotatividade da equipe.
5. Gestão de Projetos
5.1. Prazos e tempo para tarefas mal estimados.
5.2. Custos mal estimados.
5.3. Planejamento inexistente ou inadequado.
5.4. Falta de metodologia efetiva em gerenciamento de projetos.
5.5. Controle pobre ou inexistente.
5.6. Definição imprópria de papéis e responsabilidades.
5.7. Tarefas complexas.
6. Gestão de Relacionamentos
6.1. Falta de envolvimento adequado dos usuários.
6.2. Falta de comprometimento da alta gerência.
6.3. Falta de Cooperação dos usuários.
6.4. Conflito entre departamentos de usuário.
6.5. Falha em obter comprometimento do cliente.
6.6. Falta de poderes para o gerenciamento de projetos.
Tabela 3. Grupos propostos dos fatores de risco avaliados e selecionados
da literatura
22 Engenharia de Software Magazine - Riscos em projetos de software com PMBOK
• Gestão de Inovação e Tecnologias: é o grupo destinado
a lidar com as escolhas tomadas acerca das tecnologias e
inovações;
• Gestão de Pessoas: são todos os fatores que envolverem
pessoas no que tange conhecimentos, habilidades, capaci-
dades, motivação etc.;
• Gestão de Projetos: atributos comuns do gerenciamento
como prazo, custo, esforço e outros, são inseridos nesse
grupo;
• Gestão de Relacionamentos: aqui envolvem todos os
riscos atribuídos ao relacionamento entre os envolvidos no
projeto, sejam pessoas internas ou externas.
Fatores de risco no desenvolvimento de software
Nas seções anteriores foram realizados o mapeamento
e análise dos fatores de risco de maior impacto no desen-
volvimento de software. Em seguida, esses fatores foram
agrupados por contexto.
Os trinta e três fatores de risco foram distribuídos nos
grupos anteriormente definidos. Para a avaliação dos riscos,
segmentá-los em grupos facilita a compreensão do contexto,
ter os riscos distribuídos em blocos de mesmo assunto foi
importante para a realização do trabalho. No próximo tópico
será abordada a criação de modelos e utilização desses para
a realização de simulações. A Tabela 3 apresenta os grupos
e seus respectivos riscos associados.
Os riscos presentes em cada grupo estão organizados
pela ordem de impacto. O primeiro item de cada grupo é o
risco mais impactante daquele contexto e assim sucessiva-
mente. A Tabela 3 apresenta os grupos sugeridos com os
respectivos riscos. Como dito anteriormente, esses grupos
representam contextos e esses contextos foram utilizados
para simular a dinâmica entre os riscos.
Dinâmica entre riscos
O mundo é composto por variáveis e essas estão presentes
em todos os ciclos dos processos dos homens e da natureza.
O pensamento sistêmico é um conjunto de conhecimentos
e ferramentas desenvolvido nos últimos cinquenta anos
que visa nos auxiliar a reconhecer padrões e fornecer me-
canismos para modificá-los efetivamente. Ele é livre, não
possui uma tecnologia associada obrigatória e tem como
objetivo enxergar o todo, observar padrões, estruturas,
conexões e realizar uma reestruturação das inter-relações
de forma mais harmoniosa. É possível conectar variáveis
e analisar suas interferências através de um diagrama de
causalidade.
Os diagramas de causalidade, também conhecidos como
diagramas de influência, constituem a ferramenta princi-
pal do pensamento sistêmico. De acordo com esta visão, o
mundo opera em circuitos de retroalimentação de reforço
e balanceamento. O movimento desses ciclos em conjunto é
considerado o comportamento geral do fenômeno ou evento
sendo investigado. Na Figura 4 pode ser visto um exemplo
de diagrama de causalidade.

Figura 4. Esta figura é um exemplo de diagrama de causalidade
Os símbolos “+ e -”, simbolizam que, quando se altera deter-
minada variável, essa causa um impacto na variável adjacente
(ligada a ela) no mesmo sentido (sinal de mais) ou em sentido
oposto (sinal de menos). Na modelagem anterior, quando se
aumenta solução sintomática, seta com “+”, aumenta-se o efeito
de consequências não-intencionais e diminui-se, seta com
“-”, sintoma do problema. As consequências não-intencionais
quando crescem, aumentam os efeitos de sintoma do problema.
O arco cortado por duas linhas paralelas tem o significado de
que o efeito produzido não é imediato, ou seja, demanda um
tempo até ocorrer, possui um “delay”. As letras “R” e “E” sig-
nificam, respectivamente, que o caminho fechado tende a um
reforço ou equilíbrio, ou seja, sintoma do problema estimula
solução sintomática e solução sintomática desestimula sintoma
do problema, com isso tem-se um equilíbrio entre eles.
A Figura 5 apresenta um exemplo de diagrama de causalida-
de utilizando as variáveis de risco citadas neste artigo.
Figura 5. Esta figura é um exemplo de diagrama de causalidade no
desenvolvimento de software
planejamento
Saindo dos detalhes da ferramenta e observando as relações
entre os itens do diagrama, pode-se produzir várias infe-
rências. Primeiramente, para facilitar o entendimento, cada
variável considerada será explicada:
• Capacidade produtiva: é a capacidade de produzir o proje-
to, no caso, pode ser entendido como sendo a quantidade de
pontos de função que são produzidos;
• Software desenvolvido: é a quantidade de software que já
foi produzido;
• Tempo de entrega: esse item se refere ao tempo gasto para
desenvolver o projeto, ou seja, o tempo que é gasto para que o
software esteja completamente desenvolvido;
• Erro: quantidade de erro produzido;
• Retrabalho: quantidade de retrabalho que é gerado a partir
dos erros.
Pode ser iniciada uma leitura do diagrama a partir de qual-
quer item, por exemplo tomando como ponto inicial a capacidade
produtiva, quanto mais código é produzido, tem-se mais software
desenvolvido, e maior é a quantidade de erro gerado, em conse-
quência cresce também a quantidade de retrabalho que a equipe
terá que realizar e, com isso, menos software desenvolvido, uma vez
que retrabalho é refazer algo que a princípio já estava pronto. A
quantidade de software produzido é afetada tanto pela capacidade
produtiva quanto pelo retrabalho, e por sua vez, ele impacta o tempo
de entrega, que significa o tempo necessário para entregar o proje-
to, ou seja, se existe muito software pronto, precisa-se de menos
tempo para entregá-lo, de outro modo, se o desenvolvimento não
foi satisfatório o prazo de entrega cresce. O tempo de entrega afeta
diretamente a capacidade produtiva, quanto mais tempo é gasto
desenvolvendo algo, cresce também o conhecimento da equipe,
tanto na tecnologia utilizada para desenvolver o projeto, quanto
no projeto em si, com isso, a produção aumenta.
Uma nota importante: por mais que a produção aumente com
o passar do tempo, esse fator não infere em um crescimento
constante, a tendência é um aumento produtivo nos primeiros
meses e posteriormente uma estabilidade, sendo assim, tem-se
um estado de equilíbrio com o tempo. Esse equilíbrio pode
ser quebrado aumentando a equipe, melhorando os treina-
mentos, técnicas motivacionais e outros. Esses fatores podem
ser testados a partir de simulações, diagramas de causalidade
são convertidos em diagramas matemáticos que suportam
simulações de cenários.
A simulação é a avaliação numérica de um modelo mate-
mático que descreve um sistema. Muitos sistemas são muito
complexos para soluções analíticas fechadas, ou seja, planilhas,
fluxogramas, entre outros. Portanto, a simulação é usada
para exercitar modelos com entradas dadas para ver como o
sistema executa.
Existem diversas técnicas para realizar simulações com vari-
áveis dinâmicas. Uma dessas é conhecida como Dinâmica de
Sistemas – DS. Com a DS é possível analisar o comportamento
dinâmico dos riscos. Utilizando os contextos dos grupos de
riscos listados neste artigo, foram realizadas análises com
base em simulações.
Edição 69 - Engenharia de Software Magazine 23
 Para validar e produzir valores iniciais para as simulações, atribuídos aos três projetos de tamanhos diferentes os mesmos
foram utilizados os dados de uma pesquisa que adquiriu uma valores nos fatores de risco, permanecendo intacto somente o
base de dados de projetos de software do Grupo Internacio- tamanho do projeto e tamanho da equipe. A intenção dessa
nal de Padrões de Benchmarking em Software (International abordagem é apresentar o impacto da variação dos fatores de
Software Benchmarking Standards Group - ISBSG). Na Tabela 4 risco na mudança do tamanho do projeto, e o que ocorreria,
podem ser vistas algumas das informações. se os projetos tivessem atributos de risco iguais.
O primeiro retângulo da esquerda para a direita representa
Variáveis Média Mínimo Máximo um projeto pequeno, o segundo um projeto médio e o terceiro
Pontos de Função – PF 521,04 PF 11 9803 um projeto grande. No caso 1, os prazos de desenvolvimento
Esforço 5217,7 homem-horas 17,0 150.040,0 respectivamente foram: três, cinco e quatorze meses; no caso 2:
três, dois e quatro. Essa sequência é mantida para os dois
Tamanho da Equipe 8 pessoas 1 77
exemplos: “Caso 1” e “Caso 2”.
Tabela 4. Pontos de Função – PF (ver BOX 2)

BOX 2. Análise de Pontos de Função

Análise de Pontos de Função – APF, é uma técnica que visa medir o tamanho funcional de um
software, para, a partir desses dados, oferecer mecanismos para estimar esforço, prazo e custo.
Na edição de número 44 da Engenharia de Software Magazine é possível ter uma visão geral
acerca dessa técnica. Na tabela o esforço é dado na unidade de homem-horas, uma medida
que significa a quantidade de horas que um homem teria que trabalhar para realizar o projeto.
Tamanho da equipe é o número de pessoas envolvidas na realização do projeto.

Além desses dados, foram obtidos com uma microempresa

de software que utiliza a métrica em pontos de função, os da-
dos de um projeto da empresa. Para um projeto de duzentos
e setenta pontos de função realizado por uma equipe de três Figura 6. Impacto da variação dos fatores de risco
pessoas, foi fornecida a informação de que a empresa gasta o
prazo de três meses para o desenvolvimento. Com as informações apresentadas, pode ser observado que se
Com esses números em mãos, foi possível validar os testes. os impactos dos riscos fossem mantidos em qualquer tamanho
Na Tabela 5 podem ser vistos os valores dos fatores de risco de projeto, a dificuldade em executar um projeto grande ou
com os respectivos tamanhos dos projetos. pequeno seria praticamente a mesma. Os dados presentes na
figura e nas tabelas anteriores fornecem informações valiosas,
Tamanho Aproximado dos Projetos que serão tratadas a seguir.
270 PF 520 PF 9800 PF Algumas das variáveis apresentadas tiveram seus valores
Tamanho da equipe 3 pessoas 8 pessoas 77 pessoas retirados da literatura, essas foram: tamanho aproximado dos
Prazo de desenvolvimento 3 meses 5 meses 14 meses projetos, tamanho da equipe, prazo de desenvolvimento e porcen-
Conhecimento inicial sobre linguagem e projeto Alto Médio Baixo tagem de retrabalho. As demais variáveis foram ajustadas com
Porcentagem de erros encontrados 30% 50% 63% as simulações e utilizaram os seguintes parâmetros para
Porcentagem de erros eliminados com teste 20% 20% 20% ajustes, a quantidade de pessoas necessárias (tamanho da
Porcentagem de retrabalho 24% 40% 50,4% equipe) para realizar um projeto de um determinado tama-
Porcentagem de apoio do cliente 95% 90% 75% nho (tamanho do projeto) em um prazo determinado (prazo
Tabela 5. Variação de alguns fatores de risco para cada tamanho de de desenvolvimento).
projeto de software Cerca de 80% do sucesso do projeto está relacionado com 20%
do esforço (seguindo a conhecida relação “regra de Pareto”),
A seguir, uma discussão sobre os dados apresentados na tabe- aproximadamente 80% dos erros estão em 20% dos módulos
la é apresentada. Alguns dos valores representados na Tabela 5 do projeto. Para lidar com os valores médios de retrabalho,
foram retirados da literatura, outros foram obtidos através sem diferenciar a qualidade da equipe que executa o projeto,
de ajustes. Os ajustes realizados demonstram a existência do definiu-se um valor padrão para a capacidade de correções de
impacto dos riscos no tamanho dos projetos de software. erros (i.e., 20%). Como o retrabalho ocorre para corrigir os erros
A Figura 6 apresenta dois casos. No primeiro caso, foram que não foram capturados, foi observado que a quantidade de
realizadas simulações com os dados presentes na tabela ante- erros realmente cresce com o aumento do tamanho do proje-
rior. Como pode ser visto, cada projeto possui características to. Caso não houvesse o aumento do número de erros com a
diferentes como, por exemplo, a porcentagem de erros encontrados, elevação do tamanho do projeto, o prazo de desenvolvimento
porcentagem de apoio do cliente, e outros. No segundo caso, foram seria reduzido, como pode ser visto na Figura 7.

24 Engenharia de Software Magazine - Riscos em projetos de software com PMBOK


Figura 7. Queda no prazo de desenvolvimento com a redução da
porcentagem de retrabalho
A figura apresenta o impacto do retrabalho em um projeto.
De acordo com a literatura, em torno de 40% a 50% do esforço
no desenvolvimento de software é gasto em retrabalho. Esses
dados mostram como o retrabalho está altamente ligado ao
desenvolvimento de software, por mais que a redução do re-
trabalho a zero não seja uma realidade, a Figura 7 expõe como
a redução desse fator pode diminuir o prazo de desenvolvi-
mento e fortalece a relevância da realização de testes e uma
ótima análise de requisitos, para capturar e impedir erros no
software. Outras duas variáveis muito importantes estimadas
com as simulações foram: conhecimento inicial sobre a linguagem
e o projeto; porcentagem de apoio do cliente.
Quanto maior a equipe de trabalho, ter um conhecimento
inicial intensifica a produtividade (conhecimento inicial sobre
a linguagem e o projeto); com as simulações foi observado que,
com um conhecimento médio acerca de um projeto amplo,
pode-se reduzir em até 25% o prazo de desenvolvimento,
mas juntamente com o tamanho do projeto, cresce também a
dificuldade em possuir um conhecimento inicial. Embora essa
dificuldade exista, ela não exclui a possibilidade de utilizar um
conhecimento inicial maior, para aumentar a produtividade.
O suporte do cliente (porcentagem de apoio do cliente) não
aumenta a produtividade, mas reduz possíveis atrasos, uma
vez que cabe ao cliente aprovar as etapas do desenvolvimento.
Se em alguma etapa o cliente atrasar para confirmar algum
requisito, o projeto é afetado. Durante a pesquisa foi captura-
do o risco da falta de apoio do cliente, o qual impactava apenas
quando não havia o suporte dos clientes. Nos projetos maiores
foi necessário diminuir a porcentagem do apoio do cliente nas
simulações. Uma conclusão importante, não é que os clientes
ficam menos solícitos em grandes projetos, mas que o número
de processos que deverão ser aprovados aumenta, e com isso
aumenta o risco de o cliente falhar com o suporte necessário.
Após o modelo ter sido ajustado, foi possível estimar um
tamanho médio de equipe por tamanho de projeto de softwa-
re em ponto função. Com essa informação é possibilitado ao
gerente saber quantas pessoas ele necessita para realizar um
projeto. Os valores estimados foram colocados em comparação
com dados reais na Tabela 6. Sendo (a) os dados reais e (b) os
planejamento
dados estimados. O tamanho da equipe no projeto pequeno
se manteve e com isso o prazo também ficou igual, no projeto
de tamanho médio houve uma redução de duas pessoas e um
aumento de um mês no prazo de desenvolvimento e no projeto
de larga escala, houve um aumento de trinta e uma pessoas na
equipe e uma redução de dois meses no desenvolvimento.
Tamanho Aproximado dos Projetos
270 PF 520 PF 9800 PF
Tamanho Equipe (a) 3 pessoas 8 pessoas 77 pessoas
Prazo de Desenvolvimento (a) 3 meses 5 meses 14 meses
Tamanho Equipe (b) 3 Pessoas 6 pessoas 108 pessoas
Prazo de Desenvolvimento (b) 3 meses 6 meses 12 meses
Tabela 6. Dados reais X Dados estimados
O valor estimado são de noventa pontos função por pes-
soa. Esse valor foi estimado a partir da média entre a menor
produtividade por pessoa, quinhentos e vinte dividido por
oito (sessenta e cinco) e a maior produtividade, nove mil e
oitocentos dividido por setenta e sete (cento e vinte e sete).
O valor obtido foi de noventa e seis, o qual foi ajustado para
noventa pontos função utilizando as simulações. A fórmula a
seguir foi gerada a partir das simulações realizadas para este
trabalho e apresenta um cálculo simples que o gerente pode
fazer para estimar a equipe:
tamanho equipe = tamanho projeto (PF) / 90 (PF)
Essa fórmula pode ser usada para estimar o tamanho da equi-
pe quando o gerente não possui um histórico de desenvolvi-
mento, no caso de haver histórico, o ideal é seguir a capacidade
produtiva da equipe. O erro da fórmula cresce com o aumento
de tamanho do projeto, como pode ser observado na Tabela 6.
Cada equipe e projeto possuem características intrínsecas, mas
esses atributos não diminuem a utilização de fórmulas para
estimar dados que auxiliam nas tomadas de decisões. Cabe ao
gerente de projetos avaliar e criar mecanismos para lidar com
esses resultados obtidos.
Processo de qualidade e risco calculado
É necessário medir o preço que se paga por não realizar ge-
renciamento de riscos. Na maioria dos casos esses preços vão
além de fatores financeiros, estão também relacionados com
orgulho, prestígio, reputação, relacionamentos e outros.
Durante a pesquisa, foi observado que normalmente os
gerentes de projetos visualizam a necessidade do gerencia-
mento de riscos somente em projetos de larga escala, riscos
são vistos como algo extra e não como uma tarefa prioritária
em projetos menores.
A Melhoria de Processo do Software Brasileiro - MPS.BR
fornece um conhecimento acerca do gerenciamento de riscos,
e essa gestão pode ser realizada por empresas pequenas e em
crescimento. O MPS.BR possui um nível de maturidade (i.e.,
nível C) que exige lidar completamente com o gerenciamento
de riscos, mas já no nível G, nível inicial do programa de
Edição 69 - Engenharia de Software Magazine 25
qualidade, é requerido a utilização de mecanismos simples variação no tamanho da equipe em 50%, a Figura 8 apresenta
para lidar com os riscos. os resultados obtidos no prazo de desenvolvimento.
O nível parcialmente gerenciado (i.e., nível G) do guia geral
MPS.BR, possui como resultados esperados os seguintes itens
relativos a identificação e gerenciamento de riscos: os riscos do
projeto são identificados e o seu impacto, probabilidade de ocorrência e
prioridade de tratamento são determinados e documentados; os riscos
são monitorados em relação ao planejado. Esses itens articulam
ações iniciais na análise e gerenciamento de riscos.

Apoio à tomada de decisão

A tomada de decisão é envolvida por problemas classifica-
dos em: estruturados, semi-estruturados e não-estruturados
(desestruturados). Estruturados são aqueles que podem ser
completamente determinados, porque possuem soluções am-
plamente conhecidas. Para lidar com problemas estruturados,
é possível utilizar listas predefinidas como, por exemplo, ações Figura 8. Variação no prazo provocado a partir da alteração do tamanho
operacionais padronizadas, em que qualquer funcionário ou de uma equipe em um projeto de quinhentos e vinte pontos função
máquina pode tomar decisões seguindo um fluxograma. Semi-
estruturados estão em uma posição intermediária, possuem A figura apresenta uma visão do prazo de desenvolvimento
interseções com problemas estruturados, mas alguns pontos do considerando equipes com capacidades produtivas idênticas.
problema não são bem conhecidos. São desafios que necessitam Para os três casos apresentados anteriormente, o único fator
de um nível médio de julgamento humano e experiência para que foi alterado nas simulações de um caso para outro, foi o
serem solucionados. Já problemas desestruturados, são mais tamanho da equipe, todos os demais dados foram mantidos,
complexos, porque ocorrem ocasionalmente, suas estruturas com isso é possível comparar o efeito de alterar o tamanho da
não são bem definidas e exigem maior julgamento e experiên- equipe. Com as simulações foi observado que reduzir a equipe
cia para solucioná-los. Ou seja, não existem soluções prontas em 50% gerou mais impacto do que aumentá-la na mesma
para esse tipo de problema; experiências acumuladas com proporção, essa diferença será discutida juntamente com os
problemas similares, conhecimentos e ferramentas de apoio dados da Figura 9.
à decisão são utilizadas para esse tipo de desafio. No cenário anterior, as equipes possuíam um conhecimento
O gerente de projetos precisa descobrir quais tipos de desa- médio sobre a linguagem e o projeto. Na Figura 9 é exposta
fios está enfrentando. Modelos, tabelas e planilhas são ótimas uma comparação entre os tamanhos das equipes variando
ferramentas para problemas estruturados, para os demais não também o nível de conhecimento. A variação do conhecimento
é possível usar ferramentas que forneçam soluções diretas. foi de 60% para mais e para menos, variando-o de baixo a alto,
São necessárias tecnologias que auxiliem à tomada de deci- passando por médio.
são, como sistemas de apoio à decisão, simuladores, modelos
dinâmicos entre outros.
O impacto mais óbvio da utilização de ferramentas de apoio
à decisão é a melhoria da tomada de decisão. Informações e
ferramentas de apoio à decisão podem trazer diversos be-
nefícios: fornecer uma visão dos diversos cenários possíveis;
munir os gerentes de alternativas para lidar com os riscos do
projeto; aumentar a confiança nas tomadas de decisões; por
fim e não menos importante, intensificar a velocidade com
que as decisões são tomadas.
Nesta parte do artigo serão apresentados cenários de desafios
que o gerente de projetos de software pode enfrentar. Foram
realizadas diversas simulações e comparações, a fim de que
esses cenários auxiliem o gerente nas tomadas de decisões.
Foi utilizado como cenário base, o projeto de médio porte
Figura 9. Impacto no prazo gerado pela variação do conhecimento em
(i.e., 520 PF) descrito na Tabela 5, e levou-se em consideração equipes de desenvolvimento de software. Dados gerados a partir de
todos os valores dos atributos listados na tabela para o projeto simulações
desse porte.
Um desafio comum de um gerente de projetos é o tamanho da Podemos observar que o conhecimento gera maior resultado
equipe à sua disposição. Foram geradas simulações com uma na menor equipe, a diferença entre o pior caso e o melhor

26 Engenharia de Software Magazine - Riscos em projetos de software com PMBOK

 planejamento

nessa equipe, são de seis meses. Uma equipe menor bem

treinada consegue ter um rendimento melhor ou igual a
uma equipe de tamanho três vezes maior com conhecimento
baixo ou médio.
O impacto do conhecimento não é linear, ou seja, ele não
decresce ou aumenta na mesma proporção nos três casos, isto
é, nas equipes de quatro, oito e doze pessoas. Quanto maior
o número de pessoas, a comunicação interna acaba sendo
reduzida e os conflitos aumentados. Esses são alguns dos fa-
tores que não permitem que a expressão do conhecimento dos
desenvolvedores, sejam iguais independente da quantidade
de pessoas envolvidas.
Na próxima análise o tamanho do projeto será o foco, foi
mantida a variação do tamanho da equipe em 50% para mais
e menos, nas simulações o conhecimento inicial foi deixado Figura 10. Impacto da variação do tamanho do projeto no prazo de
médio para todas as equipes. Na Figura 10 é apresentado como desenvolvimento. Dados gerados a partir de simulações
o prazo de desenvolvimento de cada equipe variou reduzindo
e aumentando o tamanho do projeto em 50%. Veja que foi levantada no parágrafo anterior a questão da
A Figura 10 gera alguns questionamentos. Avaliando o equipe de doze pessoas reduzir apenas um mês do projeto
comportamento do gráfico, fica nítido o impacto do tamanho médio para o menor, e quando compara-se o prazo de desen-
do projeto em cada equipe, o questionamento gira em torno volvimento dela com a equipe de oito desenvolvedores, o prazo
do motivo de o comportamento ser diferente. Nos projetos de do projeto de duzentos e sessenta pontos função é igual.
quatro e oito pessoas, a diferença entre o projeto menor com As simulações deixam claro que aumentar o tamanho
o médio é de dois meses e, para a equipe de doze pessoas, a da equipe nem sempre é uma vantagem de produção.
diferença é de apenas um mês. Nas equações utilizadas para Sendo assim, o gerente precisa tomar cuidado para não colo-
realizar as simulações, quanto mais tempo uma equipe passa car menos pessoas que o necessário para realizar um projeto
desenvolvendo um projeto, melhor ela fica, uma vez que e nem ultrapassar demais o valor ideal. Em um dos casos da
o conhecimento aumenta com o passar do tempo, projetos Figura 10 isso ocorreu, doze desenvolvedores para realizar um
maiores dão mais tempo para a equipe melhorar e aumentar projeto de duzentos e sessenta pontos função mostrou-se uma
o alinhamento entre seus integrantes. decisão ruim, o número de processos concorrentes em projetos

Edição 69 - Engenharia de Software Magazine 27

pequenos são poucos, isso faz com que em certos momentos
desenvolvedores fiquem ociosos. Para fim de conhecimento,
para reduzir mais um mês no projeto de duzentos e sessenta
pontos função, foi necessário nas simulações colocar uma equi-
pe de quinze pessoas, uma equipe desse tamanho apresenta-
Figura 11. Impacto gerado no prazo, a partir da variação do
conhecimento da equipe de desenvolvimento, em projetos de duzentos e
sessenta pontos função
Figura 12. Impacto gerado no prazo, a partir da variação do
conhecimento da equipe de desenvolvimento, em projetos de
quinhentos e vinte pontos função
Figura 13. Impacto gerado no prazo, a partir da variação do
conhecimento da equipe de desenvolvimento, em projetos de setecentos
e oitenta pontos função
28 Engenharia de Software Magazine - Riscos em projetos de software com PMBOK
se inviável para um projeto desse porte, principalmente por
questões orçamentárias.
A seguir, serão apresentadas as Figuras 11 a 13, que re-
presentam o impacto da variação do conhecimento em cada
tamanho de projeto de software, os dados foram gerados com
simulações, cada barra do gráfico representa respectivamente
conhecimento baixo, médio e alto.
Na discussão da Figura 10 questionou-se o fato de um grupo
de oito e doze desenvolvedores obterem o mesmo desempe-
nho para um projeto de duzentos e sessenta pontos função.
Observando a Figura 11, pode ser visto que essas equipes
continuam obtendo resultados semelhantes mesmo quando
se aumenta o conhecimento de ambas. Todavia, quando o
projeto aumenta de tamanho, os resultados não permanecem
iguais, principalmente pelo já citado argumento de que proje-
tos maiores oferecem mais tempo para os desenvolvedores se
aperfeiçoarem e, quanto mais desenvolvedores, mais pessoas
estão se aperfeiçoando.
Observando os dados apresentados, pode-se concluir que
uma equipe pequena competente e bem treinada, em projetos
pequenos e médios, consegue obter resultados satisfatórios
quando comparados com uma equipe três vezes maior e de
mesma competência. Ter uma equipe menor e qualificada
mostrou-se, em alguns dos casos, uma decisão melhor do que
optar por uma equipe ampla.
Para finalizar esta seção, será apresentado um gráfico que
representa o ponto de equilíbrio entre os gráficos dos custos
aqui apresentados. O ponto de equilíbrio (do inglês, break even
point) é o ponto onde o cone de incerteza (Figura 3) intercepta
o momento da reação diante dos riscos (Figura 2). Conside-
rando que o comportamento dos dois gráficos sejam iguais, o
ponto de equilíbrio fornece o momento em que não vale mais
a pena esperar para estimar o custo e o ponto final para reagir
diante dos riscos.
Avaliando a Figura 14 fica claro que não vale a pena realizar
estimativas de custo após o ponto de cruzamento, porque é o
momento em que fica mais caro o preço que se paga por reagir
tarde demais aos riscos. A decisão do gerente sobre os custos
do projeto deve ocorrer entre o fim da fase inicial e o início da
fase intermediária do desenvolvimento.
Figura 14. Momento do ponto de equilíbrio entre o cone de incerteza e
momento de reação diante dos riscos
As informações apresentadas nessa seção foram organizadas para
prover aos gerentes de softwares, conhecimentos que possam lhes
auxiliar nas tomadas de decisões de projetos de softwares.

Como foi visto, os trinta e três fatores de risco agrupados
em seis conjuntos, formam uma base de conhecimento para
o gerente de projetos, que pode usar dessa ferramenta para
auxiliar em suas decisões. Além dessa base, é apresentada
uma tabela comparativa entre projetos de pequeno, médio e
grande porte e resultados gerados a partir de simulações para
fornecer aos gerentes de projetos de software, conhecimentos
para lhes auxiliar nas tomadas de decisões.
No gerenciamento de riscos deseja-se diminuir as incertezas.
Esse processo pode ser elaborado com um grande planejamen-
to de ações para lidar com cada situação adversa, ou pode ser
algo simples como, por exemplo, ter conhecimento dos proble-
mas que podem atrapalhar o fluxo desejado do projeto.
Gerenciar risco não é uma tarefa que deve ser executada ape-
nas em grandes projetos, mas sim uma atividade que deve ser
incorporada ao cotidiano do gerenciamento de projetos.
Existem inúmeros outros instrumentos que auxiliam na aná-
lise e gerenciamento dos riscos, uma dessas outras ferramentas,
a qual os resultados foram apresentados no artigo, é o uso de
simulações para estimar o impacto e relacionamento entre os
fatores de risco. Este artigo não visa ser um arcabouço completo
de conhecimento sobre o tema, mas sim uma estrutura inicial
para pesquisas posteriores sobre o assunto.
planejamento
Links:
1. Barki, H., Rivard, S., Talbot, J.: Toward an Assessment of Software De-
velopment Risk, J. Management Information Systems, Vol. 10, No. 2, pp.
203-225 (1993)
2. Boehm, B. W.: Software Engineering Economics, IEEE Transactions on
Software Engineering, Vol. SE-10, No. 1, January, pp. 4-21 (1984)
3. Boehm, B. W.: Software Risk Management: principles and practices, IEEE
Software, Vol. 8, No. 1, pp. 32-40 (1991)
4. Charette, R.N.: Software Engineering Risk Analysis and Management.
McGraw-Hill, New York (1989)
5. Leopoldino, C. B. Avaliação de Risco em Desenvolvimento de Software.
Dissertação de Mestrado – Escola de Administração do Rio Grande do Sul,
Porto Alegre (2004)
6. Madachy, R.: Software Process Dynamics, Wiley-IEEE Press, Washington
D.C. (2007)
7. Schimidt, R., Lyytinen, K., Keil, M., Cule, P.: Identifying Software Project
Risks: An International Delphi Study. Journal of Management Information
System. Vol. 17, No. 4, pp. 5-36 (2001)
Você gostou deste artigo?
Dê seu voto em www.devmedia.com.br/esmag/feedback
Ajude-nos a manter a qualidade da revista!
Edição 69 - Engenharia de Software Magazine 29
Planejamento e Gerência
Nesta seção você encontra artigos voltados para o planejamento
e gerência de seus projetos de software.
Gerência de Projetos: Monitore e controle o
desenvolvimento de software
Rommel Gabriel Gonçalves Ramos
Possui Graduação em Administração de Siste-
mas de Informação pelo Centro Universitário
Una (2004). Pós-graduação (especialização) em
Melhoria de Processo de Software pela Univer-
sidade Federal de Lavras (2007). Mestrado em
Tecnologias da Inteligência e Design Digital
(TIDD) na PUC/SP. (2013). Atualmente e Consul-
tor de TI na Caixa Econômica Federal. Professor
do SENAC/SP do Curso de Pós-Graduação (Espe-
cialização) em Gestão e Governança de Tecnolo-
gia da Informação).
Daniel Couto Gatti
Possui graduação em Ciência da Computação
pela Pontifícia Universidade Católica de São
Paulo (1995), Mestrado em Comunicação e
Semiótica pela Pontifícia Universidade Católica
de São Paulo (2002) e Doutorado em Educação
Matemática pela Pontifícia Universidade Cató-
lica de São Paulo (2009). Atualmente é Diretor
da Faculdade de Ciências Exatas e Tecnologia
da PUC/SP, professor da Faculdade de Tecnolo-
gia Bandeirantes, professor titular do Instituto
Brasileiro de Tecnologia Avançada e assistente
mestre da Pontifícia Universidade Católica de
São Paulo.
30 Engenharia de Software Magazine - Gerência de Projetos: Monitore e controle o desenvolvimento de software
A
gestão de projetos de software
tem se fortalecido ao longo dos
anos em razão da necessidade
de garantir a qualidade e o sucesso
dos projetos de software. Aliada aos
conceitos clássicos da área da adminis-
tração, tais como planejar, coordenar e
controlar, com os elementos específicos
da engenharia de software em relação
aos processos de software consegue in-
tegrar os aspectos tanto organizacionais
quanto técnicos.
As atividades organizacionais atribuí-
das à gestão de projetos de software vão
desde o atendimento às necessidades
do cliente em relação a um produto e/
ou serviço, até o relacionamento com
os envolvidos em todo o ciclo de vida
do projeto, já que as atividades técnicas
englobam desde as metodologias de de-
senvolvimento de software até a implan-
tação propriamente dita do software.
Decidir sobre a utilização de um
instrumento para aplicar as práticas
administrativas principalmente em
relação à gestão projetos de software
torna-se adequado, pois, os ganhos
que são obtidos com essa iniciativa
Fique por dentro:
Este artigo descreve a dificuldade existente
da aplicação da atividade de monitoramento
e controle nos processos de desenvolvimento
de software, apresentando como ferramentas
e indicadores podem auxiliar a sua utilização
constante em uma organização. Apesar dos
processos de desenvolvimentos de software in-
dicarem atividades ligadas ao monitoramento
e controle, na gestão de projetos ainda há uma
carência no uso efetivo dessas atividades.
acrescentam o aperfeiçoamento dos pro-
cessos, mas existem fatores que devem
ser observados.
O trabalho da gestão de projetos de
software é tentar cumprir o que foi
planejado. Muitos projetos fracassam
em seus objetivos ou não os alcançam
plenamente devido a diversos desvios
ou falhas que não foram identificados
no seu planejamento. Para obter mais
qualidade, não só no software, mas em
todo o seu processo, deve-se realizar um
planejamento minucioso.
O planejamento diz como e onde a
equipe deveria estar em determinado
momento. O monitoramento e controle,

por sua vez, consistem em acompanhar as atividades plane-
jadas com a finalidade de identificar possíveis problemas ou
desvios e deflagrar eventuais ajustes que possam ser necessá-
rios para fazer o projeto de volta ao seu caminho original.
Monitorar e Controlar é definido pelo o PMI (Instituto de
Gerenciamento de Projetos) como “coletar os dados do projeto
referente ao plano de gerenciamento, produzindo medições
de desempenho e divulgando essas informações por meio de
relatórios”. Dessa forma, podem ser tomadas ações corretivas
quando desvios forem identificados, garantindo o atendimento
dos objetivos do projeto.
Analisando o monitoramento e o controle, pode-se dizer que
enquanto no monitoramento estão às atividades envolvendo o
acompanhamento e a coleta de dados a respeito do andamento,
o controle consiste na tomada de ações frente aos desvios en-
contrados no monitoramento, e por isso é necessário que haja
uma medição e a apuração de indicadores com as informações
que serão reportadas à gestão de projetos de software.
O problema em realizar o monitoramento e controle nos pro-
cessos de desenvolvimento de software, pode estar relacionado
com as seguintes situações:
• A forma de utilização do monitoramento e controle nos
processos de desenvolvimento de software: nem sempre os
processos e metodologias de desenvolvimento de software
deixam explícito como deve ser feito o monitoramento e con-
trole. E normalmente cada metodologia aborda o processo de
software buscando a execução das suas fases e atividades sem
nenhum tipo de monitoramento e controle;
• As ferramentas não são suficientes para o suporte das
atividades de monitoramento e controle nos processos de
desenvolvimento de software: algumas ferramentas dispo-
níveis no mercado que são utilizadas como apoio à gestão de
projetos de software não oferecem opções suficientes para
realizar o monitoramento e controle no acompanhamento
das fases e/ou atividades no processo de desenvolvimento de
software, pois devem apresentar alguns pontos e ter opções
que permitam:
- selecionar projetos de software com alinhamento às estra-
tégias corporativas, analisando os seus impactos e riscos;
- gerenciar os recursos envolvidos em vários projetos de
software, compartilhando as suas informações de tempo,
custo e qualidade;
- gerenciar o retorno de investimento em pequenos, grandes
e complexos projetos de software;
- gerenciar o ciclo de vida dos projetos promovendo melho-
rias contínuas no processo de software;
• Existem falhas no papel dos gerentes de projetos em relação
ao monitoramento e controle nos processos de desenvolvi-
mento de software: o monitoramento e controle fornecem
insumos importantes para que o processo de desenvolvimento
de software possa ser melhorado nas suas fases e/ou ativida-
des, mas a atuação gerencial precisa ser mais eficaz e eficiente
em relação às ações preventivas e/ou corretivas, pois de nada
adianta ter instrumentos que auxiliam este processo se não
existe uma atuação assertiva;
planejamento
• A tomada de decisão da gestão de projetos sem considerar
os indicadores e relatórios de produtividade fornecidos pelo
monitoramento e controle nos processos de desenvolvimento
de software: os relatórios de desempenho extraídos dos indi-
cadores devem estar alinhados ao monitoramento e controle
sendo uma maneira de trazer mais visibilidade aos gestores
de projetos. Ainda que eles não sejam utilizados na sua totali-
dade, devem ser considerados em ações a serem tomadas não
somente pelo conhecimento empírico, mas em informações
consolidadas e confiáveis em relação aos problemas identifi-
cados nos processos de desenvolvimento de software.
Monitoramento e controle
Uma pesquisa do PMI realizada em 2012 revelou a frequência
com que as empresas brasileiras adotam atividades de mo-
nitoramento e controle em seus projetos. Nesta pesquisa
identificou-se que:
• 22% sempre adotam;
• 54% adotam na maioria das vezes;
• 24% nunca adotaram.
Com a análise desses dados, identificamos que 76% das
empresas de certa forma adotam alguma forma de acompa-
nhamento das fases e/ou atividades dos projetos porém, 24%
das empresas não se preocupam em fazer nenhum monitora-
mento e controle.
Esses dados não diferem do cenário quanto aos problemas
mais frequentes enfrentados pelas empresas em relação aos
seus projetos atribuídos a prazo (65,7%), escopo (61,7%) e custo
(41,3%).
Neste estudo, 18,4% dos problemas está relacionado à falta de
uma ferramenta para o monitoramento e controle, indicando
que 24,5% dos softwares mais utilizados são desenvolvidos
internamente por opção da empresa, o que mostra que as em-
presas não conseguem encontrar uma ferramenta adequada
devido às necessidades e particularidades internas.
Cabe destacar que, habitualmente, o monitoramento e contro-
le é considerado pelo nível operacional como uma ação de audi-
toria em que são tratadas as inconformidades das atividades e
dos processos. Esse pensamento dificulta a sua abordagem do
que deve ser entendido, pois não é apenas uma tarefa externa
que verifica como o processo está sendo conduzido, mas se ele
é realmente entendido pela equipe e principalmente se gera
valor aos envolvidos e responsáveis pelo processo.
O monitoramento e controle nos projetos de software busca
garantir a verificação do que deve ser realizado no projeto,
ou seja, acompanhar os processos que são executados com as
suas atividades, identificando ações corretivas e preventivas,
estabelecendo assim maneiras de tomada de decisão na gestão
de projetos de software.
Se a execução do projeto tem como objetivo entregar produtos
e/ou serviços planejados, o monitoramento e controle envol-
vem o acompanhamento destes resultados para garantir que
estejam de acordo com o planejado e que o projeto continue
seguindo o plano de gerenciamento do projeto.
Edição 69 - Engenharia de Software Magazine 31
 O monitoramento e controle fornecem subsídios para as
atividades nos processos de software. Com essas informações
disponíveis aos gerentes de projetos, tem-se a possibilidade de
atuação constante ao que deve ser desenvolvido e entregue por
sua equipe, proporcionando melhorias em relação à condução
do projeto de forma assertiva.
A finalidade do monitoramento e controle é determinar se
o projeto está prosseguindo conforme planejado. Essa fase
consiste em três etapas:
1. Monitoramento das atividades contínuas do projeto (onde
estamos);
2. Comparação das variáveis do projeto (custo, esforço, tempo,
recursos, etc.) com o plano real (onde deveríamos estar);
3. Identificação de ações corretivas (como voltamos ao cami-
nho certo).
Monitoramento e controle no RUP (Rational Unified
Process)
Na disciplina de gerenciamento de projetos do RUP, encon-
tramos uma tarefa “definir monitoramento e processos de
controle”, que tem o objetivo de definir as informações e os
Figura 1. Monitoramento e Controle no RUP
32 Engenharia de Software Magazine - Gerência de Projetos: Monitore e controle o desenvolvimento de software
processos que serão utilizados para monitorar e controlar o
progresso, a qualidade e os riscos do projeto.
Uma outra tarefa referente ao gerenciamento de projetos é
“monitorar status do projeto” que captura o trabalho diário
e contínuo, incluindo monitoramento de status do projeto,
relatório para envolvidos lidando com as situações atuais e
os problemas detectados.
No RUP, o monitorar e controlar o projeto permeiam todas as
tarefas essenciais até a finalização do projeto conforme pode
ser observado na Figura 1.
Com a utilização do RUP nas suas etapas e atividades, pode-
mos aplicar o monitoramento e controle para que o projeto te-
nha os resultados esperados e definidos desde a sua concepção
até a transição, buscando abordar todas as suas disciplinas e
aplicando indicadores que possam ajudar a gestão de projetos
de software por meio de ações corretivas e preventivas.
Monitoramento e controle no PMBOK
O monitoramento e controle de projetos segundo o PMBOK
têm o benefício de observar e mensurar o desempenho do pro-
jeto de forma periódica e uniforme para identificar variações
 planejamento

em relação ao plano de gerenciamento do projeto definido dos riscos residuais, identificação de novos riscos e avaliação
que inclui: do processo de risco durante todo o projeto.
• Controlar as mudanças e recomendar ações preventivas em • Administrar as requisições: gerenciamento das aquisições
antecipação a possíveis problemas; e monitoramento dos desempenhos dos contratos, fazendo
• Monitorar as atividades do projeto em relação ao plano de mudanças e correções conforme necessário.
gerenciamento e a linha de base de desempenho do mesmo;
• Influenciar os fatores que poderiam impedir o controle inte- A utilização do PMBOK no monitoramento e controle nos
grado de mudanças, para que somente as mudanças aprovadas processos de software explicita uma documentação em todas
sejam implementadas. as áreas, tornando esta atividade aderente ao que deseja a
gestão de projetos de software.
Este monitoramento contínuo oferece à equipe do projeto uma
visão melhor sobre a saúde do mesmo e identifica quaisquer Ferramentas para monitoramento e controle
áreas que requeiram atenção adicional. Não apenas monitora e Os softwares para o gerenciamento de projetos são usados
controla o trabalho que está sendo feito durante um grupo de com diversos fins como: planejar, monitorar, controlar, relatar
processos, mas também monitora e controla o projeto inteiro, e comunicar a situação dos projetos.
incluindo os seguintes processos (apresentados na Figura 2): Um software de monitoramento e controle implica em deter-
• Monitorar e controlar o trabalho no projeto: acompanhamento, minar quais dados coletar, como, quando e quem irá coletá-los,
avaliação e regulação do progresso para atender aos objetivos de analisa-los e relatar o progresso alcançado:
desempenho definidos no plano de gerenciamento do projeto; • Quais dados são coletados: dados coletados são determina-
• Realizar o controle integrado de mudanças: avaliação de dos por qual sistema de medição será usado para o controle
todas as solicitações de mudanças, aprovação de mudanças e do projeto.
gerenciamento das mesmas em entregas, ativos de processos • Coletar dados e fazer análise: com a definição de quais
organizacionais, documentos e plano de gerenciamento do dados são coletados, o próximo passo é estabelecer por quem,
projeto; quando e como os dados serão agregados;
• Verificar o escopo: formalização da aceitação das entregas • Relatórios e o modo de reportar: quem recebe os relatórios
terminadas no projeto; de desempenho? As partes interessadas e gerentes necessitam
• Controlar o escopo: monitoramento do andamento do escopo de diferentes tipos de informação relacionadas ao projeto.
do projeto e do produto e gerencia-
mento das mudanças feitas na linha
de base do escopo;
• Controlar o cronograma: monito-
ramento do andamento do projeto
para atualização do seu progresso e
gerenciamento de mudanças feitas na
linha de base do cronograma;
• Controlar os custos: monitoramen-
to do andamento do projeto para
a atualização do seu orçamento e
gerenciamento de mudanças feitas
na linha de base dos custos;
• Realizar o controle da qualidade:
monitoramento e registro dos re-
sultados da execução das atividades
de qualidade para avaliar o desem-
penho e recomendar as mudanças
necessárias;
• Reportar o desempenho: coleta e
distribuição de informações sobre o
desempenho, inclusive relatórios de
andamento, medições do progresso
e previsões;
• Monitorar e controlar os riscos:
implementação de planos de respos-
tas aos riscos, acompanhamento dos
riscos identificados, monitoramento Figura 2. Monitoramento e Controle no PMBOK

Edição 69 - Engenharia de Software Magazine 33

 A importância dos softwares no monitoramento e controle
de projetos é de fornecer insumos essenciais para o processo
de desenvolvimento de software dos projetos desenvolvidos
e, portanto, as informações que são coletadas, analisadas e
disponibilizadas ajudam na tomada de decisão quanto ao que
precisa ser apurado durante as etapas e atividades previstas e
concluídas em um projeto.
Indicadores para o monitoramento e controle
Podemos perceber certa resistência em se medir os processos
de desenvolvimento de software através de indicadores de de-
sempenho. Um dos motivos dessa resistência é a dificuldade de
se identificar indicadores que realmente ajudem na produção
de informações importantes.
Apesar de termos a possibilidade de utilizar estes indicado-
res de forma favorável em ações para melhorar os processos
de desenvolvimento de software, a gestão de projetos conti-
nua no “achismo” e no seu “feeling”, mas isso não é o ideal,
pois existem métricas e informações que não estão sendo
consideradas.
No desenvolvimento de software podemos aplicar três tipos
de indicadores que são os mais utilizados para medir o desem-
penho dos processos organizacionais:
• Indicador de qualidade: relação entre o que é produzido
(certo ou errado) pelo total produzido;
• Indicador de produtividade: relação entre o total produzido
sobre os recursos consumidos;
• Indicador de capacidade: mede a produção em um espaço
de tempo (capacidade da produção).
A utilização desses indicadores no monitoramento e controle,
considerando a sua documentação como os artefatos requeri-
dos, deve atentar para:
• Indicador de qualidade: total de artefatos que voltaram para
o retrabalho dividido pelo total de artefatos entregues;
• Indicador de produtividade: total de artefatos entregues
dividido pelo total de funcionários trabalhando no projeto;
• Indicador de capacidade: total de artefatos entregues divi-
dido pelo tempo total do projeto.
Em projetos, devemos contextualizar a utilização dos indi-
cadores como se fossem fotografias instantâneas, mas que
indicam tendências. Aconselha-se utilizar aqueles que con-
siderarem os mais adequados ao contexto que foram criados
na própria empresa, ou os mais usuais do mercado. Ter estes
indicadores atribuídos à gestão de projetos nos ajuda a:
• Ter uma visão melhor do processo de desenvolvimento de
software;
• Identificar os riscos;
• Identificar e resolver os problemas antes que se tornem
críticos;
• Melhorar a comunicação da equipe com a organização
• Avaliar o desempenho do projeto.
34 Engenharia de Software Magazine - Gerência de Projetos: Monitore e controle o desenvolvimento de software
Benefícios do monitoramento e controle
A aplicação do monitoramento e controle no processo de
desenvolvimento de software contribui e serve como um me-
canismo de aproximação entre as áreas gerenciais e técnicas,
gerando dados e indicadores que tornam mais previsíveis e
assertivos os planejamentos para a tomada de decisão na gestão
de projetos de software.
Podemos levar em consideração os processos de desenvolvi-
mento de software para o monitoramento e controle no aspecto
da gestão de projetos, as seguintes contribuições:
• A atividade de monitoramento e controle quando realizada
nos processos de software deve estabelecer processos, ativida-
des e tarefas que possam direcionar a sua utilização;
• As ferramentas que o monitoramento e controle utilizam para
o processo de software podem direcionar ações corretivas e
preventivas, que devem ser informadas à gestão de projetos
para que as devidas providências necessárias ao trabalho rea-
lizado pelo gerente de projetos e sua equipe sejam tomadas;
• A atuação gerencial tendo como uma das suas premissas a
execução da atividade de monitoramento e controle nos pro-
cessos de software como ferramenta diária de trabalho para
acompanhar os projetos e sistemas de uma organização;
Por fim, vale destacar que os indicadores de produtivida-
de atrelados ao monitoramento e controle nos processos de
desenvolvimento de software são subsídios fornecidos que
podem ter dados, informações atualizadas e consistentes
para a tomada de decisão na gestão de projetos. Portanto, é
necessário que possam ser diversificados de acordo com a
realidade da organização.
Links:
GRAY, Clifford F., Erik W. Larson: Gerenciamento de Projetos: O Processo
Gerencial; Tradução Dulce Cattunda, Frederico Fernandes – 4 ed. Porto
Alegre: AMGH, 2010.
KERZNER, H. Project Management - A System Approach to Planning,Scheduling,
and Controlling, 7º ed., New York, John Wiley & Sons Inc.,2001.
MENDONÇA, Mauro. TAM – Técnicas para Análise e Melhoria de Processos.
Curso em Fita de Vídeo, LinkQuality, 2002.
PMI-Project Management Institute. Pesquisa PMSURVEY.ORG 2012: PMI. 2012.
http://www.pmsurvey.org/
PMBOK. A Guide to the Proiject Management Body of Knowledge, PMI-Project
Management Institute, Newtown Square, Pennsylvania, USA, 2008.
Você gostou deste artigo?
Dê seu voto em www.devmedia.com.br/esmag/feedback
Ajude-nos a manter a qualidade da revista!
Engenharia
Nesta seção você encontra artigos voltados para testes, processo,
modelos, documentação, entre outros
Gestão de Projetos: Usando processos de
desenvolvimento
Rommel Gabriel Gonçalves Ramos
rommel.gabriel@gmail.com
Possui Graduação em Administração de Siste-
mas de Informação pelo Centro Universitário
Una (2004). Pós-graduação (especialização) em
Melhoria de Processo de Software pela Univer-
sidade Federal de Lavras (2007). Mestrado em
Tecnologias da Inteligência e Design Digital
(TIDD) na PUC/SP. (2013). Atualmente e consul-
tor de TI na Caixa Econômica Federal. Professor
do SENAC/SP do Curso de Pós-Graduação (Espe-
cialização) em Gestão e Governança de Tecnolo-
gia da Informação). Professor Assistente da FMU
- Faculdades Metropolitanas Unidas do Curso de
Análise e Desenvolvimento de Sistemas.
Daniel Couto Gatti
daniel@pucsp.br
Possui graduação em Ciência da Computação
pela Pontifícia Universidade Católica de São
Paulo (1995), Mestrado em Comunicação e
Semiótica pela Pontifícia Universidade Católica
de São Paulo (2002) e Doutorado em Educação
Matemática pela Pontifícia Universidade Cató-
lica de São Paulo (2009). Atualmente é Diretor
da Faculdade de Ciências Exatas e Tecnologia
da PUC/SP, professor da Faculdade de Tecnolo-
gia Bandeirantes, professor titular do Instituto
Brasileiro de Tecnologia Avançada e assistente
mestre da Pontifícia Universidade Católica de
São Paulo.
Fique por dentro:
Este artigo descreve como a gestão de projetos uti-
liza a engenharia de software para a modelagem
de produtos de software e, consequentemente,
as atribuições requeridas no gerenciamento de
projetos. O objetivo principal é apresentar a apli-
cação quanto às técnicas, modelos, metodologias
e ferramentas para a construção do produto de
software em um determinado cenário. O mode-
lo de desenvolvimento utilizado na empresa é
baseado em controles institucionais. Os cenários
apresentados neste artigo são os mais usados
atualmente em uma empresa de grande porte,
A
s empresas de desenvolvimento
de software buscam alguma
forma de gerenciar os seus
projetos de software, desejando ter um
modelo e/ou processo de “sucesso” que
possa atender todas as etapas, fases e ati-
vidades na produção do software. Entre-
tanto, não existe uma receita que garanta
à empresa alcançar este objetivo.
O SEI - Software Engineering Institute
constatou que o principal problema que
aflige as organizações de software é ge-
rencial e preconizou que as organizações
Edição 69 - Engenharia de Software Magazine
que não possui como atividade final o desenvol-
vimento de software, mas que necessita ter a vi-
sibilidade para as suas áreas gestoras de projetos
e negócios, verificando e acompanhando as fases,
etapas e atividades previstas nos processos de de-
senvolvimento, comumente utilizados em várias
empresas de desenvolvimento de software, ten-
do como premissa a construção e a manutenção
de produtos e serviços que são documentados e
aderentes aos normativos internos desta empre-
sa, estipulados pelas áreas gestoras de tecnologia
da informação.
precisam vencer o seu buraco negro que
é o seu estilo de gerenciar de maneira
informal, sem métodos e sem técnicas.
Constantemente são oferecidas em
diversos eventos de tecnologia da infor-
mação voltados para o gerenciamento
de projetos: ferramentas, metodologias,
modelos e melhores práticas que possam
tornar o desenvolvimento de software
mais eficaz e eficiente, tendo em vista
que hoje somos muito dependentes da
mão-de-obra técnica especializada para
o processo de produção de software.
35
 A gestão de projetos de software enfatiza e deixa evidente
que o gerenciamento de projetos deve ser melhorado, e por
isso, modelos e normas evoluíram principalmente com a
inclusão de práticas gerenciais para os projetos de software
como, por exemplo: o CMM para CMMI e a ISO 12207 para a
ISO 15504.
O problema da indústria de software é mais gerencial do
que técnico, todavia, o gerenciamento do projeto não está
sendo considerado como deveria. 75% de todos os sistemas de
software falham e a causa principal é o pobre gerenciamento
por parte do desenvolvedor e adquirente, deixando claro que
o problema não é de desempenho técnico.
Portanto, um fator preponderante ao processo de desen-
volvimento de software é a gestão, pois precisamos de mais
gerentes de projetos que possuam além da experiência técni-
ca, uma fundamentação teórica e prática maior na parte de
gerenciamento. Ou seja, para alcançar alguns resultados em
um determinado projeto são necessárias algumas habilidades
essenciais e decisivas. Uma empresa que desenvolve software
precisa ter além de bons profissionais, ferramentas, modelos,
técnicas e processos.
Toda empresa que desenvolve um software precisa de pro-
cessos que possam ser seguidos, acompanhados, monitorados
e controlados, como já preconiza algumas técnicas do gerencia-
mento de projetos e a própria gestão de processos. Os processos
devem ser utilizados por nossas equipes de projetos, sendo
essencial para alcançar aquilo que se espera de todo o produto
de software que é atender as necessidades dos usuários.
Engenharia de software na gestão de projetos
A engenharia de software tem por finalidade auxiliar na
construção de software da melhor maneira possível. Desde os
anos 1960, quando a frase “a crise de software” foi pronuncia-
da, muitos problemas desta área foram identificados, e muitos
deles ainda persistem, tais como:
• Previsão pobre - desenvolvedores não prevêem adequada-
mente quanto tempo e esforço serão necessários para produzir
um sistema de software que satisfaça às necessidades (requisi-
tos) dos clientes/usuários. Sistemas de software são geralmente
entregues muito tempo depois do que foram planejados;
• Programas de baixa qualidade - programas de software não
executam o que o cliente deseja como consequência, talvez,
da pressa para se entregar o produto. Os requisitos originais
podem não ter sido completamente especificados ou podem
apresentar contradições e isto pode ser descoberto muito tarde
durante o processo de desenvolvimento;
• Alto custo para manutenção - a manutenção pode ser cor-
retiva, quando ocorrem enganos (erros, falhas) no sistema
já entregue, ou evolutiva quando novas características são
adicionadas ao sistema de software. Ambas são caras quando
o sistema original foi construído sem uma arquitetura clara
e visível;
• Duplicação de esforços - é difícil compartilhar soluções ou
reusar códigos em função das características de algumas lin-
guagens adotadas, por falta de confiança no código feito por
36 Engenharia de Software Magazine - Gestão de Projetos: Usando processos de desenvolvimento
outra pessoa e até mesmo pela ausência/deficiência de docu-
mentação das rotinas e dos procedimentos já construídos.
Para solucionar alguns destes problemas, muitas empresas
de software têm adotado processos de desenvolvimento de
software. Todavia, os paradigmas metodológicos para desen-
volvimento de software têm sido considerados somente em
termos de “um método” de análise/projeto/implementação,
isto é, um conjunto de conceitos, técnicas e notações.
Contudo, a grande maioria das organizações que desen-
volvem software sente muita dificuldade em entender, de-
finir e gerenciar estes processos. As empresas de software
devem buscar os seus próprios ambientes para existirem
e operarem. Abordagens da indústria manufatureira, por
exemplo, não têm demonstrado serem adequadas à indústria
de software.
A utilização mais sistemática de processos foi iniciada nos
anos 30. Nesta época, iniciou-se um trabalho em melhoria de
processo com os princípios do controle estatístico. Nos anos
70, notou-se que as organizações de manufatura poderiam
ser estudadas de acordo com a qualidade de sua produção
e definiu-se cinco estágios sequenciais e cumulativos do
processo de produção, baseados principalmente nas atitudes
gerenciais encontradas em cada estágio. Estes estágios indi-
cam a qualidade do processo de produção.
Nos anos 80, começou-se a aplicar estes princípios de con-
troles estatísticos e os estágios de qualidade para software. Os
princípios e conceitos básicos que fundamentaram os modelos
de maturidade da capacidade foram descritos nesta época.
Pesquisas e estudos que foram realizados nos anos 90
demonstraram que o gerenciamento de projeto é a causa
mais evidente das falhas na execução e entrega de produtos
e serviços de software. Isso demonstra que a engenharia
de software torna-se essencial, pois busca a utilização dos
modelos que permitem especificar, projetar, implementar e
manter os softwares, aplicando as práticas de gerência de
projeto e demais disciplinas, com o objetivo de trazer para
as empresas produtividade e qualidade.
Gerenciamento de projetos
A gerência de projetos é a primeira camada do processo de
engenharia de software. O termo “camada” em vez de etapa,
fase ou atividade, é porque ela abrange todo o processo de
desenvolvimento do início ao fim.
Uma das tentativas iniciais de resolver falhas em projetos
foi incentivada e financiada pelo DOD (Departamento de
Defesa Americano). O Software Engineering Institute (SEI)
da Universidade Carnegie Mellon desenvolveu um modelo
de maturidade de desenvolvimento de software, o CMM
(Capability Maturity Model).
O CMM (Capability Model Maturity) indica que uma or-
ganização pode ser aferida ou avaliada comparando-se suas
práticas reais com aquelas que o modelo de maturidade de
capacitação prescreve ou recomenda. Essa aferição produz um
diagnóstico da organização quanto aos seus processos.

O diagnóstico serve de base para recomendações de melhoria
de processos, e estas recomendações podem ser consolidadas
em um plano de melhoria. Além dos benefícios naturais, como
produtividade e qualidade, acredita-se que em curto prazo as
certificações dos processos fabris será um pré-requisito básico
para contratações de produtos de software.
Por esses motivos, o CMM (Modelo de Capacidade e Maturida-
de) tornou-se ao longo de uma década o mais conhecido, usado
e respeitado pela comunidade de engenharia de software, com o
objetivo principal de estabelecer um padrão de qualidade para
software desenvolvido para as forças armadas. Atualmente, o
modelo de referência é o Capability Maturity Model Integration
- CMMI v1.3, lançado em 2002 como evolução do CMM.
As empresas de software que alcançam níveis de maturi-
dade mais elevados possuem processos capazes de produzir
produtos extremamente confiáveis dentro de limite de custo e
cronograma previsível. À medida que cresce o entendimento
dos níveis de maturidade mais elevados, as áreas de processos
existentes vão sendo redefinidas e outras ainda podem ser
adicionadas ao modelo.
Além dos modelos CMM/CMMI, outra publicação que in-
fluencia a abordagem de desenvolvimento de software é o Cor-
po de Conhecimentos em Gerência de Projetos - PMBOK.
O PMBOK descreve os conhecimentos necessários para uma
gerência de projetos não apenas de software, mas de outras
áreas de conhecimento, definindo como aplicar os conheci-
mentos, habilidades, ferramentas e técnicas às atividades do
projeto a fim de atender aos seus requisitos. Dentre algumas
das atividades de um gerente de projeto estão:
• Identificar as necessidades do projeto;
• Estabelecer objetivos claros e alcançáveis;
• Equilibrar as demandas conflitantes de qualidade, escopo,
tempo e custo;
• Adaptar as especificações, planos e a abordagem às diferentes
preocupações e expectativas das diversas partes interessadas; e;
• Minimizar os impactos negativos das incertezas dos
projetos.
Além da questão de conhecimentos em gerência de projetos,
a utilização de alguma ferramenta apropriada facilita o acom-
panhamento e o controle do projeto no sentido de atender as
demandas de desenvolvimento de software da área de negócio
de um determinado sistema dentro da organização, classifi-
cando assim as suas prioridades no seu atendimento.
Um processo de gerenciamento de projeto deve: identificar,
estabelecer, coordenar e monitorar as atividades, as tarefas e
os recursos necessários para um projeto produzir um produto
e/ou serviço, de acordo com seus requisitos. Todavia, gerenciar
projetos de software é uma atividade complexa devido a uma
série de fatores, tais como:
• Dinamicidade do processo;
• Grande número de variáveis envolvidas;
• Exigência de adaptabilidade ao ambiente de desenvol-
vimento;
• Constantes alterações no que foi planejado.
en gen haria
Estes fatores dificultam o trabalho das equipes de desenvolvi-
mento na medição do desempenho dos projetos, na verificação
de pontos falhos, no registro de problemas, na realização de
estimativas e planejamentos adequados.
De acordo com o PMBOK, “as atividades da organização
executora é que determinam as responsabilidades, os objetivos
e as políticas, de modo que o projeto atenda às necessidades
que motivaram sua realização, com as atividades dos processos
conduzidos do início ao fim, conforme adequado”.
Aplicação da gestão de projetos nas empresas de
software
As organizações devem buscar alternativas sobre como fazer
a gestão de seus projetos de software, visando a diminuição
dos fracassos e a melhoria na qualidade de seus produtos e
serviços. Os processos tradicionais de desenvolvimento e a
gerência de projetos têm sido caracterizados como uma des-
crição linear de um processo sequencial.
Qualquer projeto de software será beneficiado pelo uso de
algum tipo de modelo, inclusive no setor comercial, em que às
vezes é mais comum distribuir softwares inadequados devido
à produtividade oferecida pelas linguagens de programação
visual. A modelagem poderá auxiliar a equipe de desenvol-
vimento a visualizar melhor o planejamento do sistema e
permitir que o desenvolvedor seja mais rápido ajudando a
construir o item correto.
No desenvolvimento de um software, podemos utilizar
modelos existentes no mercado como referência de forma que
seja uma metodologia de sucesso.
Neste contexto, é essencial o uso da gestão de projetos para
descrever como um software deva ser construído e modelado
utilizando ferramentas, padrões e normas baseados em pro-
cessos e como eles serão aplicados em quem desenvolve e/ou
adquire soluções para conduzir o seu negócio no dia a dia.
Isto deve ser uma meta a se alcançar nas empresas que estão
em busca de benefícios e resultados, principalmente para esta-
belecer melhorias contínuas na mudança de paradigmas, e na
maneira de introduzir inovações tecnológicas para a resolução
de problemas rotineiros e complexos.
Contudo, as organizações precisam adaptar suas estruturas,
estratégias e políticas para satisfazerem os novos ambientes e a
crescente demanda da sociedade contemporânea por sistemas
de informação que são construídos a partir da iniciativa da
gestão de projetos.
A falha nos projetos é discutida em algumas pesquisas. Em uma
delas, realizada nos anos de 1992 e 1993, mais de 60% dos projetos
pesquisados nos Estados Unidos estavam atrasados e mais da
metade ultrapassava em 50% o prazo planejado. Um outro estudo
conduzido em 1999 indicou que somente 37% dos sistemas de
informação foram finalizados no prazo estipulado.
Adicionalmente, dos 63% dos projetos que atrasaram 42%
seriam finalizados acima do orçamento. O Standish Group,
através de um estudo chamado de relatório do “Chaos”, iden-
tificou que as empresas dos Estados Unidos gastaram US$81
milhões em projetos de software, sendo que 31% dos projetos
Edição 69 - Engenharia de Software Magazine 37
de software estudados foram cancelados antes de estarem con-
cluídos, 53% excederam mais do que 50% a sua estimativa de
custo e somente 9% dos projetos, em grandes empresas, foram
entregues no tempo e orçamento previstos; para empresas de
pequeno e médio porte, os números melhoraram de 50% para
28% e de 9% para 16%.
Tem-se tentado resolver essas falhas através de modelos de
melhoria e processo que estão baseados no Triângulo Mágico
da Força do Desenvolvimento de Software (Magic Triangle of
Software Development Greatness). Qualquer deficiência em
alguma área do triângulo se manifestará em riscos de falha
dos projetos (ver Figura 1).
Então, é evidente que temos que trabalhar em todos os
seus aspectos, sendo que uma força influencia na outra. Por
exemplo, processos imaturos fazem com que tenhamos uma
deficiência no estabelecimento do perfil técnico requerido
para exercer uma atividade e não se consiga obter o melhor
da tecnologia oferecida.
Figura 1. Triângulo Mágico da Força de Desenvolvimento de Software
O processo de software, portanto, é essencial para que tenha-
mos qualidade no produto de software e consigamos atender a
qualidade, orçamento, prazos e recursos definidos no projeto.
Organizações que sejam capazes de integrar, harmonizar e
acelerar seus processos de desenvolvimento e manutenção de
software tendem a ser mais bem sucedidas no mercado.
Geralmente um projeto de software requer a participação
de uma ou mais equipes, cooperando para a construção de
determinado produto de software. É necessário que exista
consenso sobre o processo a ser seguido desde a concepção até
a implantação do produto de software, para que interpretações
pessoais não desviem o foco do trabalho ou introduzam erros
durante o desenvolvimento.
Todos estes fatores levam as organizações desenvolvedoras de
softwares a atuar fortemente na qualidade de seus produtos,
que é um dos principais objetivos da engenharia de software.
Contudo, a qualidade dos produtos de software, que também
ficou evidente para a evolução da qualidade dos produtos
das indústrias, está fortemente relacionada à qualidade do
processo de software.
A utilização de software já faz parte do cotidiano de prati-
camente todas as pessoas. Mesmo aquelas que pensam que
nunca utilizaram um software, internet, ou um computador,
38 Engenharia de Software Magazine - Gestão de Projetos: Usando processos de desenvolvimento
na verdade já se beneficiam dos avanços das tecnologias de in-
formação e comunicação (TICs), que também poderão sofrer as
consequências de um erro, defeito ou falha de um software.
As empresas que utilizam modelos apropriados para a
construção e manutenção de um software demonstram ter um
nível de maturidade, adicionando mais produtividade com
competência técnica, operacional e gerencial, o que requer
delas o controle sobre seus processos imaturos, maduros e
institucionalizados.
Já em 1989, foi constatado que a ausência de práticas adminis-
trativas no desenvolvimento de software é a principal causa de
sérios problemas enfrentados pelas organizações, tais como:
atrasos em cronogramas, custo maior do que o esperado e pre-
sença de defeitos, ocasionando uma série de inconveniências
para os usuários e enorme perda de tempo e de recursos.
A meta da gestão de projetos é conseguir exceder as necessi-
dades e expectativas dos stakeholders. Todavia, satisfazer ou
exceder estas necessidades envolve um balanceamento entre as
várias demandas concorrentes em relação aos itens abaixo:
• escopo, tempo, custo e qualidade (objetivos do projeto);
• stakeholders com necessidades e expectativas diferenciadas; e
• requisitos identificados (necessidades) e requisitos não iden-
tificados (expectativas).
A gestão de projetos sendo conduzida pela gestão de proces-
sos pode trazer diversos benefícios à organização, tais como:
• Descrição precisa e não ambígua dos processos de negócio
existentes;
• Melhoria na definição de novos processos;
• Maior eficácia na coordenação do trabalho entre diferentes
agentes;
• Obtenção, em tempo real, de informações precisas sobre o
andamento dos processos e;
• Padronização dos processos executados, de forma manual
ou automatizados, pela organização.
Desde o começo da década de 1990, a corrida pela excelência
na gestão de projetos tem assumido uma importância cada vez
maior. Os benefícios da gestão de projetos são óbvios hoje tanto
para os clientes quanto para os fornecedores. De fato, a exce-
lência em gestão de projetos se tornou uma arma competitiva
que atrai novos negócios e mantém os clientes tradicionais.
Para atender a demanda de maneira eficaz em um ambiente
caracterizado pela velocidade das mudanças, torna-se indis-
pensável um modelo de gerenciamento baseado no foco em
prioridades e objetivos. Por essa razão, o gerenciamento de
projetos tem crescido de maneira tão acentuada no mundo
nos últimos anos.
Outro fator que impulsionou o gerenciamento de projetos
é o crescimento da competitividade. Quem for mais rápido e
competente certamente conseguirá melhores resultados.
Ainda hoje, esta afirmação tem sido confirmada por diversos
autores. Na atual cultura das organizações de software, o pla-
nejamento, quando ocorre, é feito de forma superficial. Muitos
projetos de software são realizados sem um planejamento de

como a ideia modelada pelo levantamento de requisitos e ne-
cessidades dos clientes pode ser transformada em produto.
Os gerentes de projeto de software estão desacostumados a
estimar. Quando estimam, costumam basear-se em estimativas
passadas, mesmo sabendo que elas podem estar incorretas
(não sabem também precisar o quanto elas estão incorretas).
Há gerentes que se recusam a estimar somente por julgarem
perda de tempo, uma vez que correm o risco de obter resultados
incorretos e, portanto, estarem desperdiçando tempo.
Boas estimativas de custo, esforço e prazo de software reque-
rem um processo ordenado que defina a utilização de métricas
de software, método e ferramenta de estimativa. As empresas
de software, de forma geral, não detêm conhecimentos e re-
cursos para isso.
Estimar, medir e controlar um projeto de software são tarefas
difíceis, pois o desenvolvimento de software é uma atividade
criativa e intelectual, com muitas variáveis envolvidas (como
metodologias, modelos, técnicas, ferramentas, tecnologias,
recursos e atividades diversas). Os gerentes inexperientes
tentam cumprir prazos dando a máxima velocidade na fase
inicial e estão despreparados para os momentos de impasse,
quando os ajustes são inevitáveis.
A dinamicidade do processo de software dificulta também
o gerenciamento efetivo de projetos de software, devido às
alterações constantes nos planos de projetos, redistribuição
de atividades, inclusão/exclusão de atividades, adaptação de
cronogramas, realocação de recursos, novos acordos com os
clientes, entregas intermediárias não previstas etc. Um projeto
de software também deve se adaptar ao ambiente, dependendo
da disponibilidade de recursos, ferramentas e habilidades do
pessoal ou equipe.
Outros fatores ainda agravam os problemas da gestão de pro-
jetos de software em empresas, tais como: inexistência de um
processo definido, recursos pessoais e financeiros limitados,
falta e/ou pouca cultura em processos, pouco treinamento em
engenharia de software, imaturidade metodológica, cresci-
mento ocorrido por demanda, falta de experiência adminis-
trativa por parte dos gerentes e diretores e falta de definição
das metas organizacionais.
Tem-se também a persistência de um conhecido problema no
desenvolvimento de software: muitos projetos consomem mais
recursos do que o planejado e demoram mais tempo para serem
realizados, possuem menos funções e menor qualidade do que
o esperado. Relatos de insucesso na produção de sistemas de
software podem ser encontrados em diversos estudos de casos
e experimentos documentados ao longo dos últimos anos.
O modelo de desenvolvimento para a gestão de
projetos
Partindo do pressuposto de que uma organização de grande
porte utiliza um processo padrão de desenvolvimento de soft-
ware, e que nele são apresentados os controles institucionali-
zados com seus cenários, é possível ter a visão compartilhada
sobre como a gestão de projetos percebe os marcos que são
desenvolvidos para um novo produto de software, aferindo
en gen haria
também a sua manutenção com uma modelagem adequada.
O processo padrão estabelece o conjunto de elementos fun-
damentais que guia o desenvolvimento e a manutenção de
sistemas. Ele define uma estrutura única a ser seguida por
toda a equipe envolvida em projetos de software, independen-
temente das características do software a ser desenvolvido e
das técnicas a serem utilizadas.  
Essas técnicas são definidas de acordo com as necessidades
do projeto, ambiente, a preferência e competência da equipe
multidisciplinar envolvida. A inovação tecnológica é um di-
ferencial que deve ser incentivado. É o ponto de partida para
a instanciação dos processos de software adequados às dife-
rentes características de cada projeto, permitindo economia de
tempo e esforço na definição do processo a ser seguido.
As orientações sobre as técnicas mais utilizadas são apresen-
tadas como cenários e também compõem a metodologia de
sistemas que deu suporte à construção de grande parte dos sis-
temas. Os modelos instanciam os processos de desenvolvimen-
to que são associados a estas técnicas e são disponibilizados
dentro dos cenários através de casos de desenvolvimento.
Observe a Figura 2. Este modelo exemplifica a estrutura do
modelo de desenvolvimento dos sistemas. O processo padrão
está normatizado e estabelece controles rigorosos com o foco
na preservação institucional. Adicionalmente, a título de
orientação, são apresentados cenários direcionados a técni-
cas específicas, de acordo com a experiência anteriormente
adquirida (o conhecimento acumulado no desenvolvimento
de sistemas, cujo registro foi apropriado através do grupo
de trabalho).
O uso de abordagens como o RUP, conforme Figura 3, con-
templará atividades e artefatos efetivamente indispensáveis à
instituição, incluindo os controles institucionais, e que deverá
ser flexível o suficiente para atender às diversas situações co-
muns ao desenvolvimento, em qualquer tipo de projeto.
Se você depende de sua capacidade para desenvolver e im-
plantar software, que é essencial para o sucesso da instituição,
ele irá ajudá-lo, pois foi desenvolvido visando dois grupos
primários de usuários:
• Profissionais de desenvolvimento de software que trabalham
como parte de uma equipe de projeto, incluindo os investidores
desses projetos de desenvolvimento de software;
• Profissionais de engenharia de processo, especificamente
engenheiros de processo de software e gerentes.
Os profissionais de desenvolvimento de software podem
encontrar orientação sobre o que é exigido deles nas funções
definidas. Um profissional que trabalha em um projeto de
engenharia de software é designado a uma ou mais funções
definidas, e em que cada função particiona um conjunto
de tarefas e produtos de trabalho pelos quais essa função é
responsável.
Também é fornecida orientação sobre como essas funções
trabalham em conjunto, em termos das atividades requeridas
para representar o processo configurado, referenciado como
o processo de entrega. Além disso, são fornecidas várias
Edição 69 - Engenharia de Software Magazine 39
visualizações com o produto que são
focalizadas em diferentes grupos de pro-
fissionais de engenharia de software.
Para  um  profissional de desenvolvi-
mento de software, este ambiente forne-
ce uma definição de processo comum e
central, que todos os membros da equipe
de desenvolvimento de software podem
compartilhar, ajudando a assegurar uma
comunicação clara e sem ambiguidade
entre os membros da equipe.
Figura 2. Modelo de Desenvolvimento de Sistemas de Software
Figura 3. Rational Unified Process
40 Engenharia de Software Magazine - Gestão de Projetos: Usando processos de desenvolvimento
Isso ajuda você a desempenhar a
sua parte esperada na equipe de pro-
jeto, tornando claro quais são as suas
responsabilidades.
A técnica de análise estruturada baseia-
se na decomposição funcional estrutura-
da de sistemas através de Diagramas de
Fluxo de Dados (DFDs)  que descrevem o
sistema como um conjunto de processos
funcionais que realizam transformações
de informação e comunicam-se através
de fluxos de informação. Através do
Diagrama de Entidade e Relacionamen-
to (DER) são enfatizados os dados e os
relacionamentos entre eles.
Na análise estruturada os processos
mais complexos são decompostos em
subprocessos constituintes e seus fluxos
de informação, formando-se uma estru-
tura hierárquica de processos.  Esta me-
todologia fornece um conjunto coerente
e integrado de métodos e regras, que no
seu conjunto formam uma técnica estru-
turada de análise e projeto de sistemas
baseada nos seguintes conceitos: aborda-
gem top-down, modelagem funcional,
representação gráfica do modelo, dicio-
nário de dados e a descrição de processos
e procedimentos, além de trabalho em
equipe e documentação.
 Assim, o processo de desenvolvimento
de sistemas na análise e projeto estrutu-
rados baseia-se em (ver Figura 4):
• Definir os fluxos de dados recebidos
pelo sistema, entradas;
• Definir os fluxos de dados fornecidos
pelo sistema,  saídas; e
• Definir os dados que devem ser arma-
zenados e os processos que devem ser
executados para transformar os fluxos
de entrada nos fluxos de saída.
A exibição de dados, composto de
diagramas de entidade relacionamento,
é um registro do que está no sistema, ou
o que está fora do sistema que está sendo
monitorado. É a visão estática estrutural.
Sob o ponto de vista dinâmico, o diagra-
ma de transição de estado define quando
as coisas acontecem e as condições em
que eles acontecem.
A análise estruturada, de maneira
geral, compreende os processos: Levan-
tamento, Análise, Projeto, Codificação,
Teste, Implantação e Manutenção. Usu-
almente adota-se uma abordagem em
cascata. Esta abordagem é caracterizada
pela existência de um início e fim de
cada fase do processo de desenvolvimen-
to, sendo a formalização do término de
uma fase requerida  antes que se inicie
a próxima.
Pode ser utilizada quando for possível
adotar seus métodos, técnicas e ferra-
mentas, pelas equipes de desenvolvi-
mento, garantindo-se o rigor dos seus

resultados. Além disso, é recomendada quando for possível a
comunicação entre clientes e usuários e a equipe de desenvol-
vimento de forma a se garantir a clareza de ideias e o rigor da
especificação.  Isso pressupõe uma equipe de desenvolvimento
capaz, com expertise técnica e habilidade de comunicação.
 Deve ser aplicada preferencialmente na construção/manu-
tenção de sistemas de médio e grande porte, cujos requisitos se-
jam relativamente estáveis. A metodologia poderá ser utilizada
no início de um novo projeto de desenvolvimento de software
e também em manutenções e em ciclos de desenvolvimento
subsequentes após a implantação do sistema em produção.
Figura 4. Analise estruturada
Figura 5. Fluxo dos Controles Institucionais
en gen haria
Os controles institucionais definidos pela empresa que
tem como premissa a utilização de modelos de software são
eventos fundamentais para o processo de desenvolvimento,
e exigem algum tipo de aprovação de produto ou servem de
insumo para uma etapa seguinte e se não realizados, impedem
a continuidade do processo (ver Figura 5).
Esses controles podem significar ainda a geração de produto
explicitamente recomendado, normalmente ligados à política
de segurança da informação ou à gestão de conhecimento. Os
controles institucionais sempre necessitam de uma evidência
de sua realização.
Além dos controles instituições, no modelo de desenvol-
vimento existem guias de utilização padronizados por um
comitê de melhoria de processo voltadas para os gestores,
gerentes, desenvolvedores, usuários e demais envolvidos
no processo, trazendo diversas orientações da estrutura
que podem ser usadas em detrimento de um projeto e/ou
manutenção.
Toda documentação técnica e gerencial de um projeto e/ou
manutenção produzida durante o processo de desenvolvimen-
to é mantida pelas áreas de desenvolvimento em repositório
oficial. Os artefatos técnicos dos sistemas (ATS) são mantidos
durante todo o ciclo de vida, pois registram a inteligência do
sistema e serão utilizados e atualizados em todas as manuten-
ções e evoluções futuras.  
Edição 69 - Engenharia de Software Magazine 41
 Para a construção são utilizadas ferramentas homologadas
Referências:
pela empresa, a fim de possibilitar a integração dos modelos e a
visão sistêmica dos negócios. Ao longo do projeto/serviço, sem- 1. AUGUSTINE, S.; PAYNE, B.; SENCINDIVER, F.; WOODCOCK, S. (2005). Agile
pre que necessário, é refinado e validado junto às equipes. Project Management: Steering from the Edges. Communications of the
A integridade dos artefatos técnicos de sistema com os ACM, v. 48, n. 12, pp. 85 - 89.
requisitos é sempre mantida. Todo projeto/manutenção tem
2. Mary Beth Chrissis, Mike Konrad and Sandy Shrum, CMMI: Guidelines
um responsável pela gerência das diversas disciplinas/áreas
for Process Integration and Product Improvement, Addison-Wesley Pub
envolvidas, a fim de estabelecer e manter a integridade dos
co, 2003.
produtos ao longo do ciclo de vida. Além disso, deve-se pro-
mover a prática do paralelismo de atividades. 3. CMMI Model Componentes Derived from CMMI – SE/SW, Version 1.0
Ao longo do projeto e/ou manutenção compete ao líder de Technical report CMU/SEI-00-TR24. Pittsburgh, PA: Software Engineering
projeto, ou a quem ele delegar, acompanhar e revisar os re- Institute, Carnegie Mellon University, 2000.
sultados e as realizações do projeto, comparando o realizado 4. CURTIS, Bill; STATZ, Joyce. Building the case for software process impro-
com o previsto nos planos, acordos e estimativas documenta- vement. In: SEI NATIONAL CONFERENCE SOFTWARE ENGINEERING PROCESS
das. Nesse acompanhamento, todos os planos do projeto são GROUP, 1996, Atlanta. Proceeding…Atlanta, 1996.
atualizados e os compromissos assumidos revisados, sempre
5. DeMarco, T. Structured Analysis and System Specification. Prentice-Hall,
que necessário independente da atividade.
1979.
O objetivo é possibilitar que ações efetivas sejam tomados
para evitar que o projeto desvie significativamente dos pla-
nos ou que os planos se tornem obsoletos. Em qualquer etapa Você gostou deste artigo?
ocorrem novas validações/aprovações sempre que algum
produto, para o qual existam validações/aprovações previs- Dê seu voto em www.devmedia.com.br/esmag/feedback
tas, for atualizado. Os parceiros e o gestor da informação são
Ajude-nos a manter a qualidade da revista!
informados sobre a situação do projeto e/ou sua manutenção,
por meio de pontos de controle estabelecidos em cronograma,
independente da ocorrência de alterações.
A gestão de projetos de software tem buscado, através de
indicadores de desempenho estipulados pela instituição, a
constante melhoria em seus processos, principalmente os
associados às entregas dentro do prazo estipulado.

42 Engenharia de Software Magazine - Gestão de Projetos: Usando processos de desenvolvimento

Engenharia
Nesta seção você encontra artigos voltados para testes, processo,
modelos, documentação, entre outros
ITIL: Como implantar o gerenciamento de
mudanças
Cristiane Aparecida Lana
cristiane.lana@ufv.br
Mestranda em Ciência da Computação pela
Universidade Federal de Viçosa (UFV). Espe-
cialista em Gestão Estratégica de Pessoas pela
FACISA - UNIVIÇOSA (2012) e Bacharel em Sis-
temas de Informação pela Faculdade de Viçosa
(2008). Atualmente atua como orientadora de
trabalhos de Graduação na Faculdade de Viçosa
e pós-graduação Lato Senso pela FACISA - UNI-
VIÇOSA. Tem experiência na área de Sistemas
de Informação com ênfase em Engenharia de
Software, Engenharia de Requisitos e Repre-
sentação do Conhecimento, Sistemas de Apoio
à Decisão e Gestão de Pessoas.
Bruno Torres Satler
bruno@cientec.net
Mestre em Ciência da Computação - Engenha-
ria de Software pela Universidade Federal de
Viçosa (2010). Bacharel em Ciência da Com-
putação pela Universidade Federal de Viçosa
(2007). Consultor implementador Melhoria
de Processo de Software - MPS-Br. Professor
Assistente - FDV Faculdade de Viçosa. Professor
Assistente - FACISA Univiçosa. Gerente de Proje-
tos e Analista de Processos - Cientec Consultoria
e Desenvolvimento de Sistemas. Professor da
pós-graduação Lato Sensu em Sistemas de
Informação - FACISA-Univiçosa. Professor da
pós-graduação Lato Sensu Especialização em
Sistemas para Internet - UFV.
A
complexidade dentro da área
de Tecnologia da Informação
(TI) é crescente. Juntamente,
os números de mudanças oriundos das
alterações do mercado, das tecnologias
e das necessidades dos próprios clientes
e até mesmo da organização, vem au-
mentando proporcionalmente. Com essa
constante transformação a TI precisa ser
dinâmica, eficaz e eficiente e os serviços
relacionados precisam ser oferecidos
com qualidade, de forma estável e con-
fiável. Porém, o conhecimento detalhado
e a identificação das mudanças não é
uma tarefa simples de ser executada por
Microempresas e Empresas de Pequeno
Porte, que muitas vezes demonstram
falta de estruturação dos processos e
pouco conhecimento de metodologias
de governança de TI.
Os serviços de TI podem ser vistos
como um conjunto de recursos, TI e não
TI, mantidos por um provedor de TI, cujo
Edição 69 - Engenharia de Software Magazine
Fique por dentro:
Este artigo analisa o processo de Gerenciamen-
to de mudança da biblioteca ITIL (Information
Technology Infrastructure Library), elencando
os impactos e benefícios de sua implantação
em Microempresas e Empresas de Pequeno
Porte de Tecnologia da Informação. A ITIL for-
nece um conjunto coerente e compreensivo de
melhores práticas para gestão de serviços de
TI, provendo qualidade técnica para realizar
negócios com eficiência e efetividade no uso
de sistemas da informação. Este artigo é útil
para organizações que desejam implantar ou
aprimorar o processo de gerenciamento de mu-
danças utilizando as boas práticas da biblioteca
ITIL. Sua utilização irá assegurar que os proces-
sos sofram modificações planejadas, garantin-
do menor impacto nos serviços/processos que
passarão por modificações.
objetivo é satisfazer uma ou mais neces-
sidades da área de negócio e suportar
os objetivos estratégicos do negócio da
organização e do cliente.
Porém, para que a TI satisfaça as ne-
cessidades da organização é preciso
que ocorra um alinhamento entre os
recursos tecnológicos da TI com os
43
interesses da organização, onde um complemente o outro no
alcance de seus objetivos e principalmente no comprimento da
sua missão da organização. Para que este alinhamento ocorra
é necessário que a TI forneça serviços que estejam de acordo
com as necessidades estratégicas do negócio. Com isso, a TI
confronta as limitações ligadas às próprias operações do negó-
cio e respondendo com inovações que sejam ao mesmo tempo
eficientes e estratégicas. Com esse alinhamento, a TI passa a ser
considerado um parceiro estratégico dentro da organização, se
tornando um diferencial competitivo da empresa.
Assim, a governança de TI deixa a condição de desejável
para o status de essencial aos negócios da empresa. Devido
a isto, os auditores das corporações passaram a adotar algu-
mas metodologias de governança de TI, como a metodologia
ITIL – Information Technology Infrastructure Library, com a
finalidade de melhorar o desempenho desta área.
O ITIL foi desenvolvido na década de 1980, pelo Office Go-
vernment of Commerce Britsh - OGC, inicialmente como um
guia do governo britânico para gestão de serviços. Com suas
evoluções, atualmente a ITIL é parte da norma ISO 20000 (in-
ternational Organization for Standardization, ou Organização
Internacional para Padronização), um padrão internacional
para gestão de serviços de TI.
A ITIL fornece um conjunto coerente e compreensivo de
melhores práticas para gestão de serviços de TI, provendo
qualidade técnica para realizar negócios com eficiência e
efetividade no uso de sistemas da informação. As práticas
desta metodologia são baseadas na experiência de empresas
comerciais e governamentais de todo o mundo, as quais têm
se tornado cada vez mais dependente de TI.
Uma mudança pode aparecer devido a um incidente
ou devido a ações proativas para beneficiar o negócio da
organização, como a redução de custos ou a melhoria dos
serviços. Seu gerenciamento procura minimizar o impacto
das mudanças causadas por incidentes e melhorar as opera-
ções da organização através das mudanças proativas. Para
isso, padroniza métodos e procedimentos para um controle
eficiente das mudanças.
Gerenciamento de Serviços de TI
Antes de iniciar o processo de gerenciamento de serviços
de TI é preciso garantir o alinhamento entre o que será ofe-
recido pela TI com o negócio da organização. Essa tarefa não
é simples, pois é necessário garantir alinhamento estratégico
visando a geração de valor para a organização, maximizando
o aproveitamento de novas oportunidades e a redução dos
custos. Diante dessa necessidade, a área de TI precisa entender
que os clientes atuais querem mais que produtos, eles querem
serviços que agregam valor. Sendo assim, a área de TI precisa
ir além de prestação de serviço entregue às organizações, ela
precisa determinar qual o valor do serviço perante a estratégia
de negócio, garantir que os serviços serão entregues dentro do
padrão de qualidade exigido pelos clientes e pelos usuários.
A Tabela 1 mostra os principais conceitos que foram modifi-
cados e quais estão vigentes no cenário atual.
Cenário Anterior Cenário Atual
Atendimento do usuário Atendimento ao cliente
Perspectiva interna Perspectiva externa
Esforço pessoal Esforço repetitivo e medido
Foco na tecnologia Foco no processo
Processos ad-hoc Processos racionalizados
Recursos internos Recursos racionalizados
Comportamento reativo Comportamento proativo
Visão fragmentada Visão integrada
Sistema manual Sistema automatizado
Gestor de operações Gestor de serviços
Tabela 1. Modificações entre o cenário anterior versus o atual
Para que as modificações dos cenários ocorram com sucesso é
necessário que aconteça uma modificação, uma transformação
das convicções, do conhecimento e até mesmo da expectativa
do profissional de TI, o que pode proporcionar uma mudança
de comportamento e maior comprometimento.
O Gerenciamento de serviços de TI é uma série de conceitos
que identificam e inter-relacionam as várias atividades envolvi-
das no desenvolvimento de um ambiente que produz melhoria,
métricas e entrega de serviços de TI para os clientes e para a
comunidade de usuários de TI. Ele integra pessoas, processos
e tecnologias necessárias na busca de viabilizar a entrega do
serviço de TI garantindo o alinhamento estratégico de negócio
da organização. Contudo, é de extrema importância para as
organizações saber de onde estão saindo e onde querem che-
gar e como chegar. A Figura 1, conhecida como “Fronteira da
Eficiência”, mostra o curso do processo onde existe um ponto
de saída (ponto A) e um ponto de chagada desejado (ponto A),
para se locomover de um para o outro de forma apositiva é
necessário manter a prestação de serviço em um nível elevado
com um baixo custo. É esse equilíbrio aliada as estratégias e
metas que fará com que a organização saía de um gerencia-
mento de serviços caótico para um equilibrado.
Figura 1. Fronteira de Eficiência

44 Engenharia de Software Magazine - ITIL: Como implantar o gerenciamento de mudanças


O gerenciamento de mudanças pode
ser aplicado a qualquer tipo de orga-
nização, pequena ou grande, pública
ou privada, com serviços de TI, cen-
tralizado ou descentralizado, interno
ou outsourced, permitindo coordenar
o fornecimento e suporte de serviços
de TI destinados a preencher as neces-
sidades da organização. Além disso, a
abordagem mais conhecida para se fazer
o gerenciamento de serviços em TI é a
ITIL, pois esta explora as relações entre
as atividades nos processos pertinentes
a qualquer organização.
Information Technology
Infraestructure Library - ITIL
A ITIL (Information Technology In-
frastructure Library) é um conjunto de
padrões de melhores práticas para o
gerenciamento de serviços de Tecnologia
da Informação. Esta metodologia oferece
uma descrição detalhada das importan-
tes práticas de TI, incluindo checklists,
tarefas, procedimentos e responsabi-
lidades. Estas práticas são definidas
como processos e podem ser adaptadas
a qualquer organização de TI cobrindo
a maioria de suas atividades.
Criada na década de 80 pelo Centro
de Computadores e Agência de Teleco-
municações – CCTA do Reino Unido,
atualmente conhecido como Office of
Governamment Commerce – OGC, teve
por objetivo padronizar e comparar as
diversas propostas de prestadores de
serviços de TI ao governo Britânico. A
metodologia foi desenvolvida a partir
de pesquisas realizadas por consultores,
especialistas e doutores na área, para
desenvolver as melhores práticas para
a gestão de TI nas empresas públicas e
privadas. Seu foco está na descrição dos
processos necessários para gerenciar
eficientemente e eficazmente a infra-
estrutura de TI garantindo os níveis
de serviço acordados com os clientes
internos e externos.
Na década de 90, a ISO 9000 e o modelo
de referência da EFQM (European Foun-
tation for Quality Management) passam
a adotar as melhores práticas da ITIL
tornando-a um padrão mundialmente
conhecido e a metodologia de serviços de
TI mais utilizada. A Figura 2 apresenta
Figura 2. Processo do ITIL
os processos do ITIL subdivididos em:
Gerenciamento de Aplicações, Gerencia-
mento de Serviços, Gerenciamento da
Infraestrutura, Gerenciamento de Ca-
nais de Suprimento, Gerenciamento de
Segurança e Gerenciamento de Infraes-
trutura de Tecnologia de Comunicações
e de Informação (TCI).
Como pode ser visto na figura, além da
definição do negócio, dos parceiros e da
tecnologia a ser usada ou implementada,
existem diversos processos que devem
ser analisados e implementados que
são indispensáveis para o sucesso do
processo.
Além do processo de Gerenciamento de
Mudanças, que abordaremos neste arti-
go, a ITIL conta com mais dez processos
que podem ser implementados de forma
isolada nas organizações, são eles:
1. Service Desk: ponto único de contato
entre usuários/clientes e o departamento
de TI;
2. Gerenciamento de Problemas: res-
ponsável por minimizar a interrupção
nos serviços de TI por meio da organi-
zação dos recursos para solucionar pro-
blemas de acordo com as necessidades
de negócio, prevenindo a recorrência e
garantindo o registro de informações
que melhore a maneira pela qual a
organização de TI trata os problemas,
resultando em níveis mais altos de dis-
ponibilidade e produtividade;
Edição 69 - Engenharia de Software Magazine
en gen haria
3. Gerenciamento de Configuração:
responsável por fornecer à organização
de TI um controle maior sobre todos os
seus ativos;
4. Gerenciamento de Incidente: seu foco
principal é restabelecer o serviço o mais
rápido possível, minimizando o impacto
negativo no negócio;
5. Gerenciamento de Liberação: respon-
sável pela implementação das mudanças
no ambiente de infraestrutura de TI;
6. Gerenciamento do Nível de Serviço:
é responsável por gerenciar o nível dos
serviços prestados pela equipe de TI,
com o objetivo de definir o tempo de
resolução para cada solicitação realizada
pelos clientes e tempo para restabeleci-
mento de cada indisponibilidade ocor-
rida na operação;
7. Gerenciamento de Capacidades: dese-
nhado para assegurar que a capacidade
da infraestrutura de TI esteja alinhada
com as necessidades do negócio;
8. Gerenciamento de Disponibilidade:
visa otimizar a capacidade da infraestru-
tura de TI ajudando a organização a en-
tregar um nível sustentado de disponibi-
lidade a um custo aceitável, garantindo
que os serviços estarão à disposição dos
clientes e usuários sempre que for preci-
so e permitindo assim que os objetivos
do negócio sejam alcançados;
9. Gerenciamento da Continuidade
dos Serviços de TI: tem por objetivo
45
suportar de forma geral o Gerenciamento de Negócios, as-
segurando que os requisitos técnicos da TI e facilidades de
determinados serviços possam ser recuperados dentro de
escalas de tempo requeridas e acordadas; e
10. Gerenciamento Financeiro: é responsável por determinar
o verdadeiro custo de todos os serviços de TI e demonstrá-lo
de maneira que a organização possa entendê-lo e utilizá-lo
para o processo de tomada de decisão.
Fica fácil entender que as melhores práticas adotadas pelo
ITIL abrangem todas as atividades da área de TI. Usando
uma abordagem de processo, a ITIL define principalmente
o que deve ser incluído no Gerenciamento em Serviços
em TI para que se ofereça um serviço de qualidade (veja a
seção Links).
Gerenciamento de Mudanças
Comumente, as mudanças surgem como resultado para os
problemas, embora muitas mudanças possam ser efetivadas
com o objetivo de trazer benefícios empresariais ou melhorar
os serviços oferecidos. A finalidade da realização do processo
de Gerenciamento de Mudanças é alcançar esses objetivos uni-
ficando métodos e procedimentos com o intuito de controlar
e manipular de forma eficiente todas as mudanças, minimi-
zando o impacto de incidentes que já tenham sido vivenciados
anteriormente, e consequentemente melhorar as operações do
dia a dia da organização.
O aumento da importância da área de TI vem crescendo
aceleradamente e junto com ela as exigências de qualidade,
redução de tempo de atendimento e custo, etc. visando alcan-
çar os objetivos do negócio. Dentro deste contexto, é preciso
vislumbrar uma forma de acompanhar as mudanças da área
de TI e a evolução do cenário de negócios.
Todas as mudanças, incluindo as de emergência e aplicação
de patches, relacionadas à infraestrutura e aplicações dentro
do ambiente de produção, devem ser gerenciadas formal-
mente de maneira controlada. Estas mudanças (incluindo
procedimentos, processos, sistemas e parâmetros de servi-
ço) devem ser registradas, avaliadas e autorizadas antes da
implementação.
O Gerenciamento de Mudanças é considerado um tanto
quanto burocrático. Isso se deve a exigência de todos os in-
cidentes ser identificados, antes de serem corrigidos, devem
ser filtrados, analisados e testados para depois ser implemen-
tada as correções no ambiente de produção. Para isso, se faz
necessário uma mudança de cultura e um comprometimento
de todos para o processo lograr êxito.
Sua missão é gerenciar todas as mudanças que de alguma
forma possam causar impacto na entrega de serviços pela
área de TI, através de um processo único e centralizado de
aprovação, programação e controle da mudança, assegurando
que a infraestrutura e a área de TI permaneçam alinhadas aos
requisitos do negócio, com o menor risco possível.
A seguir estão listados os principais objetivos do Gerencia-
mento de Mudanças, de acordo:
46 Engenharia de Software Magazine - ITIL: Como implantar o gerenciamento de mudanças
• Garantir a utilização dos métodos padronizados para o
tratamento eficiente de todas as mudanças, reduzindo seus
riscos e impactos;
• Minimizar o surgimento de incidentes que tenham relação
com alguma mudança;
• Realizar o balanço entre a necessidade e o impacto.
Segundo a própria OGC, este processo tem foco nas mu-
danças que afetam Hardware, Software, Equipamentos e
Software de Comunicação; aplicações em produção e toda
documentação e procedimentos associados com a operação,
suporte e manutenção da Infraestrutura de TI. Além disso,
ficam fora do escopo do gerenciamento, mas relacionados com
este as mudanças em projetos; a identificação de componentes
afetados na mudança ou atualização de registro (Gerencia-
mento de Configuração) e a liberação de novos componentes
(Gerenciamento de Liberações).
A Solicitação de Mudança (Request for Change – RFCs) é
o ponto de partida de todo o processo de Gerenciamento de
Mudança. Ela consiste da solicitação inicial da mudança,
por parte dos usuários, áreas de negócio e membros das
equipes dos processos de Gerenciamento de Incidente e de
Gerenciamento de Problema, sendo estes dois últimos os
principais promotores de mudanças em um ambiente de
infraestrutura de TI.
Todas as mudanças devem ser revistas após um período
pré-estabelecido a fim de garantir que os resultados foram
alcançados e analisar o grau de eficiência na estimativa de
recursos utilizados.
Benefícios do sistema de Gerenciamento de Mudanças
Os benefícios específicos do processo de Gerenciamento de
Mudanças descritos pela ITIL são:
• Melhor alinhamento dos serviços de TI com os negócios.
• Aumento da visibilidade e comunicação das mudanças entre
seus atores.
• Melhoria no processo de avaliação de riscos, reduzindo o
impacto negativo da mudança.
• Melhor avaliação de custos das mudanças.
• Redução do número de mudanças que necessitem da execu-
ção dos seus planos de retorno ao original (backout).
• Melhor identificação dos problemas.
• Aumento na produtividade dos usuários, com a redução das
paradas de serviços de TI.
• Aumento de produtividade de pessoal da área de TI, pela
maior fidelidade às ações que são planejadas.
• Habilidade de absorver um grande volume de mudanças.
• Um aumento da percepção dos valores do negócio, por parte
da equipe de TI, resultando em melhoria na qualidade dos
serviços de TI.
Detalhamento do Processo
O processo de Gerenciamento de Mudanças é responsável por
decidir e coordenar as mudanças não tendo como objetivo dire-
to executar a implementação. A implementação será realizada
 en gen haria

por uma equipe técnica responsável pela

área de mudança, como a área de redes,
sistemas, hardware.
Este processo controlará as mudanças
para que elas sejam implementadas de
forma eficaz, no que se refere ao custo,
com um mínimo de riscos para os servi-
ços mantidos. Para a elaboração de uma
análise de riscos adequada é importante
o uso de uma Base de Dados do Geren-
ciamento de Configuração, pois este irá
fornecer todos os serviços e recursos
relacionados ao item de configuração
que sofrerá a mudança.
As principais entradas e saídas do pro-
cesso de Gerenciamento de Mudanças
são mostradas na Figura 3.
Como pode ser visto na figura, as Figura 3. Entradas e Saídas do Processo de Gerenciamento de Mudanças
principais entradas dos processos RFCs
(Request for Change) é o Requisições de
Mudanças - RDM, FSC (Forward Sche-
dule of Changes) é a Programação Futura
de Mudanças - PFM, o agendamento das
próximas mudanças; e por fim o CMDB
que recebe informações do processo de
Gerenciamento de Capacidade, Con-
figuração e Liberações para realizar a
análise de riscos, planejamento e custos.
No que tange às saídas tem-se a PFM –
Programação Futura de Mudanças, RDM
– Requisições de Mudanças Aprovadas
e Atas da Reunião do CCM – Conselho
de Controle de Mudanças.
Apesar do Gerenciamento de Mudan-
ça possuir uma estrutura sólida, não é
possível que ele seja implementado sem
considerar o entorno, principalmente os
projetos que podem sofrer alterações ao Figura 4. Integração dos Processos de Gerenciamento de Mudanças e Gerenciamento de Projetos
longo de seu percurso. Sendo assim, a
Figura 4 mostra como ocorre a interação
entre o Gerenciamento de Mudanças e o em processos anteriores, como o Geren- • Aprovação
de Projetos. ciamento de Problemas, por exemplo. Todos os RDMs devem ser filtrados e
É possível perceber que em todas as fa- A RDM poderá ser em papel ou ele- aprovados mas alguns fatores podem
ses do projeto podem ocorrer mudanças trônica através de algum software de determinar que uma mudança seja
e que o gerenciamento intervém de for- Gerenciamento de Serviços. recusada, por exemplo, se o custo da
ma a minimizar os impactos e controlar mudança é mais alto que o benefício que
os pontos de mudanças existentes que • Registro e Classificação ela pode oferecer.
modificaram o projeto original. Diversas informações para a tomada
de decisão devem estar contidas em • Coordenação do Desenvolvimento
Registro de Requisição de um RDM, tais como categoria, impacto Após aprovada a mudança, a RDM
Mudança – RDM e custo. A partir destas será elaborado deve ser passada a um grupo técnico
O Registro de Requisição de Mudanças o relatório gerencial e a cada mudança que será responsável pelo desenvolvi-
(RDM) pode ser levantado a partir de deve ser associada ou alocada sua priori- mento da mudança. O Gerenciamento
uma necessidade do setor de TI, ou sur- dade para definir a agenda de mudanças de Mudanças deve coordenar todo este
gir em virtude de um erro identificado programadas. processo, garantindo assim, a existência

Edição 69 - Engenharia de Software Magazine 47

dos recursos necessários, monitorando os riscos e acompa-
nhando os testes.
• Autorização e Implementação
Após passar pela fase de desenvolvimento, as mudanças
devem ser testadas antes de ir para o ambiente de produção.
É aconselhável que exista um grupo de testes independente
neste processo, que tenha condições técnicas para elaborar o
plano de testes avaliando todos os requisitos para o funcio-
namento da mudança no ambiente de produção e só após o
resultado dos testes que a mudança será autorizada para ser
implementada.
• Implementação
O Gerenciamento de Mudanças deve garantir que as mudan-
ças sejam implementadas seguindo um programa definido. A
execução da implementação não é de responsabilidade deste
processo, ficando o seu cargo apenas a coordenação. O processo
de Gerenciamento de Liberações poderá ser coordenado pelo
processo de Gerenciamento de Mudanças, pois as mudanças
de fato acabam gerando novas liberações de software ou de
hardware.
• Avaliação
O Gerenciamento de Mudanças deve avaliar todas as mudan-
ças implementadas depois de determinado período, chamada
de Revisão Pós-Implementação. O processo de Gerenciamento
Figura 5. Exemplo do processo de Gerenciamento de Mudança
48 Engenharia de Software Magazine - ITIL: Como implantar o gerenciamento de mudanças
de Problemas também pode vir a acompanhar este processo.
Esta revisão se destina a verificar se a mudança trouxe os resul-
tados esperados, ou caso haja algum problema ou ineficiência,
ações devem ser tomadas para a sua correção.
A Figura 5 mostra o fluxograma que explica o que ocorre
numa RDM, mostrando o inicio da requisição ate a avaliação
final fechando a mudança requisitada.
Comitê de Controle de Mudança – CCM
O Comitê de Controle de Mudança (CCM) é responsável pela
avaliação do impacto das mudanças. Este grupo será compos-
to de pessoas técnicas e até mesmo clientes, que fornecerão
assessoria ao Gerente de Mudanças sobre quais mudanças
devem ser aprovadas e auxiliarão na programação das mu-
danças. Normalmente, o CCM se reúne com uma determina
frequência para discutir todas as mudanças novas e que ainda
estão em andamento.
Comitê de Emergência – CCM/CE
Quando surgem problemas mais graves é necessário iden-
tificar uma configuração menor com autoridade para tomar
decisões emergenciais, pois pode não haver tempo para se
criar um CCM completo, sendo o presidente deste comitê o
Gerente de Mudanças, que são os técnicos responsáveis pela
implementação da mudança. Dependendo da criticidade da
mudança, é determinada por essa equipe uma rápida alteração
no ambiente para que a solução seja imediata.

Programação de Futuras Mudanças
– FPM
A Programação Futura de Mudanças
(FPM) é responsável por manter atu-
alizados os detalhes de todas as mu-
danças que têm sido autorizadas para
implementação dentro de um período
previamente estabelecido, ou seja, o
cronograma para alteração no ambiente
equivale ao grau de risco que a mudança
pode oferecer. Se a mudança tiver um ní-
vel crítico muito alto, o tempo para pla-
nejamento será maior. Um bom exemplo
seria uma empresa que por problemas
técnicos precisa trocar o seu servidor, e Figura 6. Relacionamento do processo de Gerenciamento de Mudança com outros processos da ITIL
no momento da troca serão desligados
todos os computadores, neste caso, serão envolvidas várias
áreas da empresa, tais como: infraestrutura e TI. Haverá um
tempo para cada área planejar sua execução, no entanto um
tempo maior é exigido para execução da Mudança.
Relacionamento com outros Processos
O processo de Gerenciamento de Mudanças está relacio-
nado com outros processos da ITIL, como pode ser visto na
dependência da precisão dos dados de configuração com a
precisão do processo de Gerenciamento de Liberação para
assegurar o conhecimento sobre o impacto completo em se
aplicar a mudança no ambiente de trabalho.
Outros processos podem relacionar-se com o Gerenciamento
de Mudanças, pois eles podem requisitar também mudanças
(Gerenciamento de Disponibilidade) ou podem ser consulta-
dos para determinar o impacto da mudança (Gerenciamento
da Continuidade dos Serviços de TI, Gerenciamento do Nível
de Serviço e Gerenciamento da Capacidade - Figura 6).
A Figura 6 mostra que o processo de mudança ocorre de
forma interativa, sendo que a qualquer momento pode surgir
uma necessidade específica nos mais diferentes módulos do
processo geral do ITIL e este deve ser analisado e suprido de
acordo com as diretrizes aprovadas pela organização.
Indicadores de Desempenho – KIP (Key Performance
Indicator)
O processo de Gerenciamento de Mudanças deve conter
mecanismos de controle que permitam avaliar sua eficiência,
eficácia, efetividade e economicidade. Para isso, são utilizados
os Indicadores de desempenho, também chamados de Indica-
dores Chave de Desempenho (ou Key Performance Indicator
– KPI – em inglês) que servem para avaliar e medir o nível de
desempenho de processos chaves para a empresa.
O KIP é uma medida quantificável que tem como função
refletir os fatores críticos de sucesso da organização que varia
de uma organização para outra. Uma empresa pode ter como
KIP os percentuais de sua receita que vem do retorno dos
clientes, uma escola pode set seu KIP no número de alunos
graduados, etc. Independente do KIP selecionado é preciso
en gen haria
garantir que ele reflita os objetivos organizacionais, além de
serem quantificáveis (veja a seção Links).
Problemas Potenciais do Gerenciamento de Mudanças
A seguir, estão descritos possíveis problemas que podem ser
enfrentados pelo processo de Gerenciamento de Mudança:
• O escopo de uma mudança pode ser muito grande para os
recursos disponíveis, pode sobrecarregar os recursos e gerar
atrasos;
• Falta de clareza nas propriedades dos sistemas impac-
tados;
• Caso o processo de Gerenciamento de Mudanças seja imple-
mentado sem o processo de Gerenciamento de Configuração,
possivelmente a solução será menos efetiva;
• A burocratização do processo, fazendo com que não seja
seguido;
• Dados sobre os CIs (Itens de configurações) incorretos podem
resultar em avaliação de impacto incorreta;
• Deficiência na atualização entre plataformas e localidades faz
com que seja difícil ou quase impossível agendar mudanças;
• Procedimentos de contingência que não existem ou não
foram testados;
• O acompanhamento de progresso das mudanças é manual,
o que gera sobrecarga em quem o executa;
• As faltas de acompanhamento da alta e média gerência fazem
os tempos de implementação crescer, e há uma resistência
aos novos controles, a menos que veja comprometimento dos
gerentes;
• Mudanças de emergência frequentemente provocam a falha
do processo
Detalhamento das Fases
As  mudanças podem ocorrer de forma  programada, ace-
lerada ou emergencial. Para efeito de definição, mudanças
“Programadas”, “Aceleradas” ou “Emergenciais” seguem o
mesmo procedimento, sendo que, os parâmetros de tempo
devem atender as necessidades específicas de cada tipo.
A programada exige um conhecimento prévio da necessidade
não exigindo urgência para sua execução.
Edição 69 - Engenharia de Software Magazine 49
 Portanto, segue o processo normal de Gerência de Mudanças.
Aceleradas, as mudanças que necessitam ser executadas o mais
rápido possível seguindo o processo normal da solicitação, por
necessidade técnica ou de negócios da empresa estudada.
Emergencial, a mudança vital para atender uma necessida-
de de negócio, normalmente para correção de um problema,
e que não pode aguardar o processo normal de mudanças,
particularmente na revisão e fase de aprovação, onde existe
o risco iminente para os negócios, ativo ou processos da em-
presa estudada
Qualquer evento que ocorra no ambiente de tecnologia e que
não possua uma “Mudança” registrada deve ser enquadrado
como “Incidente Técnico” não controlado e o processo de
comunicação devem abranger as áreas de negócio de toda a
empresa estudada.
A metodologia recomentada pela ITIL para realização do pro-
cesso de melhoria contínua dos serviços de TI é PDCA ((P(Plan
= Planejar) D(Do = Executar) C(Check = Verificar) A (Action
= Agir)) que se baseia no controle de processos. Desenvolvido
na década de 30 e utilizado pela indústria manufatureira,
o PDCA é composto por quatro passos: 1) Plan – Planeja as
ações a serem executadas; 2) Do – realiza as ações que foram
planejadas; 3) Check – Verifica se o que foi feito esta de acordo
com o planejado; e por fim 4) Act – que Atua corretivamente
sobre a diferença identificada. Seu maior objetivo é manter os
clientes e mantê-los satisfeitos.
Descrição do Estudo de Caso : A organização
Para análise do processo de gerenciamento de mudanças,
buscou-se um estudo de caso: uma Empresa de Pequeno Porte
do ramo de tecnologia de informação situada na Zona da Mata
Mineira. Sua missão é Transformar conhecimentos gerados
em universidades e centros de pesquisas em soluções para a
sociedade e assim busca ser reconhecida pelo mercado como
empresa inovadora que desenvolve produtos e soluções com
qualidade mundial.
Fundada em 1997 na incubadora da base tecnológica do
CENTEV da Universidade Federal de Viçosa (MG), a empresa
se posiciona no mercado como um elo importante entre a pes-
quisa científica e a sociedade, buscando propor soluções para
o gerenciamento de informações para diversos profissionais
que buscam a otimização do tempo e capacitação profissional
de qualidade.
Na busca de melhorar a qualidade de seus produtos e serviços
e desejando aprimorar, a cada dia seus conhecimentos, a em-
presa implantou o programa “SEBRAE de Gestão da Qualidade
(PSGQ)”, processo no qual obteve 100% de aprovação.
Em 2010, a empresa passou por novas expansões, iniciando o
desenvolvimento de cursos online para capacitação profissio-
nal em diversas áreas de atuação, aplicativos móveis e forman-
do uma importante parceria com a empresa Aoki Sistemas para
a comercialização do E2corp, que é um promissor Sistema de
Gestão Empresarial (ERP - Enterprise Resource Planning).
Com o sucesso dos cursos online, a empresa iniciou, em 2012,
o desenvolvimento e comercialização de e-books, contando
50 Engenharia de Software Magazine - ITIL: Como implantar o gerenciamento de mudanças
com parcerias para distribuição nacional e internacional. Após
15 anos de existência, a empresa vem fidelizando, de forma
progressiva, seu mercado consumidor e sua linha de produtos,
oferecendo sempre aos seus clientes produtos de qualidade e
que os auxiliem em sua trajetória de sucesso.
Cenário Atual
Atualmente a empresa possui um gerente para cada setor
(administrativo, vendas, suporte pós-vendas, departamento
de TI e nutricional) e um gerente geral.
Toda e qualquer solicitação de mudanças é feita sem passar
por qualquer processo. O solicitante interessado em uma mu-
dança entra em contato com o membro da equipe de TI e infor-
ma seu interesse solicitando sua execução. Este procedimento
em sua maioria das vezes acarreta a realização de mudanças
sem retorno e com altos índices de impactos negativos.
Tais solicitações por serem feitas sem nenhum monitoramen-
to, podem propiciar o não atendimento de uma mudança que
seja prioritária para a organização, por exemplo, para a organi-
zação em análise todas as aplicações web são de fundamental
importância, tais como: instabilidade do servidor, necessidade
de melhoria de uma aplicação para atendimento de um dado
setor, como busca e listagem de cursos no sistema. Contudo,
por não possuírem um sistema de gerenciamento de mudanças
a aplicação web pode deixar de ser atendida em detrimento de
outra solicitação de menor importância. Isso ocorre porque não
existe nenhum software de controle de solicitações implantado.
Assim, as solicitações de mudança chegam por e-mail, telefone
ou por meio do famoso “boca a boca”, que na maioria não ficam
registrados, afetando o planejamento do gerente de projetos,
gerente de TI que somente fica sabendo que a solicitação existe
após a sua execução. Desta forma, os problemas que existem
no cenário atual são:
• Ausência de documentação para formalizar uma solicitação
de mudança;
• Descentralização das solicitações de mudanças;
• Ausência de filtro de prioridade para execução de
mudanças;
• Falta de prazo limite para aprovação da solicitação.
Gerenciamento de Mudança na Organização
O processo de Gerenciamento de Mudança na organização
tem por objetivo manter o controle das mudanças na área de TI,
de uma forma documentada, processual e controlada, visando
minimizar ao máximo os impactos negativos. Com isso, faz-se
necessário o apoio de um processo de Gerenciamento de Con-
figuração eficiente, que ofereça uma CMDB (Banco de Dados
do Gerenciamento da Configuração) atualizada, uma vez que
o registro dos CIs (Item de Configuração) compõem quais ser-
viços de TI são de responsabilidade daquele processo.
Analisando a empresa, verificou-se que a mesma possui
um software para a realização das interações pertinentes aos
processos, chamado de Help Desk. Todos os setores da em-
presa podem se comunicar através desse software com envio
de chamados específico para cada setor. Porém, atualmente a

organização não possui um Service Desk estruturado, ficando
sem um ponto central de contato entre os usuários e a área
de TI.
O objetivo do processo é definir os papéis e responsabilida-
des, processos e o fluxo padrão a serem utilizados para todas
as solicitações, para que haja o controle integrado de mudanças.
O controle integrado de mudanças compreenderá a identifi-
cação, documentação, análise e autorização das mudanças,
tendo como critérios de avaliação para aprovação o escopo,
custo de execução e prazo previamente autorizados para cada
solicitação de mudanças, sendo classificadas em três tipos de
mudanças, normal, padrão e emergencial.
A normal é a mudança planejada com antecedência. A padrão
por sua vez é uma mudança rotineira e de baixo impacto, por
exemplo, a mudança de senhas, alteração de cursos, modifi-
cação de arquivos para licitação. Já a emergencial, é aquela
mudança vital que surge para atender uma necessidade ou
sanar um incidente ocorrido. Esse tipo de mudança não ne-
cessita passar pela fase de autorização indo direto para a fase
de implementação.
O enquadramento de cada solicitação de mudanças auxilia
na coordenação da implementação. O plano de gerenciamento
de mudanças não tem como objetivo executar a implementa-
ção das mudanças sendo apenas responsável por decidir e
coordenar o processo de mudanças. A implementação será
realizada pela equipe de desenvolvimento. Assim, é necessário
a definição dos papéis e responsabilidades de cada participante
da equipe.
As solicitações de mudanças devem seguir um roteiro padrão,
onde cada solicitante deve registrar sua solicitação por meio de
um formulário que por sua vez deve ser enviado ao gerente de
mudanças. Neste momento cria-se o registro de solicitação de
mudanças – RDM, o qual fica a cargo do gerente de mudanças,
atribuir uma identificação única para cada solicitação. O ideal
é que esses registros sejam individuais evitando a sobreposição
de registros.
Na fase de registro e classificação várias informações serão
utilizadas para a tomada de decisão, tais como categoria, im-
pacto, custo. Estas informações também serão utilizadas para
produzir relatórios gerenciais, onde a RDM será classificada
de acordo com a prioridade para cada mudança para definir
o tipo de mudança a qual se encaixa.
O comitê, por meio do relatório gerencial, deve filtrar a soli-
citação no início da atividade de classificação, para saber se a
solicitação é pertinente. Caso não seja, será encaminhada para
o gerente de mudanças para que possa informar a recusa da
solicitação ao solicitante por meio do documento de registro de
encerramento da solicitação. Caso a solicitação seja pertinente,
o comitê deve classificá-la em um dos três tipos de mudanças:
normal, padrão ou emergencial.
Após as RDMs serem classificadas e filtradas, elas devem
ser aprovadas. Na fase de aprovação o comitê se reúne com o
gerente de mudanças para avaliar os possíveis impactos, que
podem ser gerados pela solicitação de mudança, baseados em
custo, cronograma e escopo para sua realização. Em seguida, a
en gen haria
requisição de mudanças, agora aprovada, chega novamente às
mãos do gerente de mudanças que inicia a fase de coordenação
e desenvolvimento.
Na fase inicial de coordenação e desenvolvimento, deve-se
identificar se a RDM tem urgência alta ou impacto mínimo.
Caso a RDM se enquadre em uma destas duas formas, a fase
de autorização pode ser deixada de lado e passar direto para
a fase de implementação.
Toda mudança deve ser testada nas atividades ao final da fase
de autorização e na atividade de avaliação, antes de ser enviada
para o ambiente de produção. É importante que exista uma
equipe de testes para elaboração do plano de testes avaliando
o funcionamento após realização da mudança.
Na fase de autorização a equipe de testes irá acompanhar
como está o planejamento de execução das mudanças e, ao
obter resultados satisfatórios por meio de testes, a mudança
será autorizada a passar para a fase de implementação que
tem como objetivo apenas executar a solicitação de mudanças
conforme a coordenação do gerente de mudanças. Nesta fase
são gerados os relatórios de testes realizados.
O gerente de mudanças irá coordenar a execução durante a
fase de implementação, ficando a cargo da equipe de desen-
volvimento executar o plano de desenvolvimento informar se
existem alterações críticas para que elas sejam autorizadas e
novamente implementadas. Não havendo alterações inicia-se
a fase de avaliação.
A fase de avaliação tem como objetivo, revisar todo o escopo
de acordo com o que foi implementado. Assim, será possível
verificar se a mudança foi realizada como esperado ou se re-
sultou outros erros inesperados e quais ações a serem tomadas
para a correção. Não ocorrendo a rejeição, a mudança entra em
produção e é formalizada a entrega da solicitação de mudança
como executada e aprovada para o solicitante.
Planejamento de Mudança
O primeiro passo do planejamento para implantação do
processo de Gerenciamento de Mudanças da ITIL é escrever
o documento da metodologia no qual será formalizado: Solici-
tações de Mudanças, Planejamento das Atividades, Avaliação
de Riscos, Avaliação de Impacto, Registro de Envolvidos, Fluxo
de Comunicação, Definição e Homologação das Contingências,
Definição e Homologação de Planos de Retorno entre outros.
Esse documento terá que ser escrito pelo gerente responsável
pelas mudanças, juntamente com outros gerentes de outros
setores da empresa.
Para implantar o plano de gerenciamento, a fase inicial será
composta de reuniões com todos os membros para explicar
os objetivos esperados, quais serão os papéis de cada um e
suas respectivas responsabilidades, além de inserir o fluxo de
gerenciamento de mudanças. Após as definições iniciais, será
disponibilizado o treinamento sobre a nova forma de gestão
de mudanças, detalhando o objetivo e execução das fases que
compõem cada solicitação de mudanças.
O treinamento é importante para que a equipe esteja pre-
parada para receber, registrar e dar prioridade a todas as
Edição 69 - Engenharia de Software Magazine 51
requisições de mudanças (RDMs), criar uma agenda de ativi-
dades e publicar RDMs para o comitê de controle de mudanças,
convocar reuniões de emergência, coordenar a construção, o
teste e a implementação das mudanças, manter os registros
de mudanças atualizados com o progresso, revisar todas as
mudanças implementadas para garantir que tenham atingido
seu objetivo, revisar RDMs pendentes para depois fechá-las e
finalmente fazer relatórios gerenciais.
A ferramenta Help Desk passa a ser utilizada para realizar
solicitações de mudanças e planejamento das atividades
necessárias para a implementação. É preciso manter de for-
ma controlada todos os registros do planejamento inicial,
das dificuldades encontradas, das mudanças de rota e das
decisões tomadas (quem, quando, por que). Quanto melhor
planejado o projeto, menos problemas e necessidades de re-
visões futuras, porém dificilmente o projeto será cumprido
Tabela 2. Cronograma de Implantação do Gerenciamento de Mudanças
do início ao fim sem qualquer mudança ou adaptação e por
mais insignificantes que pareçam, essas mudanças devem
ser documentadas.
Definido os papéis de cada integrante da equipe, o plano de
gerenciamento de mudanças entra em estado experimental.
Neste estado uma grande porcentagem da equipe de TI deverá
estar operando de acordo com o novo fluxo de trabalho e a
outra porcentagem restante estará executando as atividades
remanescentes. O estado experimental irá perdurar até que
toda a equipe esteja totalmente alinhada com a nova forma de
gestão e os solicitantes já estiverem em um nível de maturida-
de suficiente para centralizar suas solicitações apenas para o
gerente de mudanças.
O risco envolvido no processo de  forma geral é uma análise
de fundamental importância, onde deve existir um mapeamen-
to de  todas as possibilidades de insucesso, pois este documento
será utilizado como  referência para determinação das contin-
gências necessárias, quanto mais detalhes (sob   a   perspectiva
do negócio) forem catalogados, mais fácil será determinar os
riscos envolvidos na operação.
A implantação do gerenciamento de mudanças deverá ocorrer
em três passos sendo eles:
1. Inserção da cultura organizacional por meio de reuniões;
2. Disponibilizar um treinamento para toda a equipe de acordo
o plano de execução de mudanças; e
3. Execução da nova gestão de mudanças em estado experimen-
tal com uma parte da equipe até chegar à maturidade suficiente
para que toda a equipe esteja alinhada com o gerenciamento
de mudanças.
A Tabela 2 apresenta o cronograma de atividades de implan-
tação do Gerenciamento de Mudanças na empresa estudada.
Para executar cada solicitação de mudanças é necessário
seguir os prazos do fluxo de atividades que compõem a ter-
ceira fase.
A implantação irá ocorrer em três fases, onde o término
de uma é o início da outra. Na terceira fase a execução das
mudanças irá acontecer em estado experimental durante um
tempo pré-determinado.
52 Engenharia de Software Magazine - ITIL: Como implantar o gerenciamento de mudanças
Fases Período
1- Inserção da cultura organizacional por meio de reuniões diárias. 4 semanas
2- Treinamento da equipe de acordo o plano de execução de mudanças. 3 semanas
3- Execução da nova gestão de mudanças em estado experimental. 12 semanas
Cada solicitação de mudanças percorre as próximas sete atividades
3.1- Registro de Requisição de Mudanças – RDM Início
3.2- Registro e Classificação 3hs
3.3- Aprovação 3hs
3.4- Coordenação do Desenvolvimento 3h
3.5- Autorização 3h
Depende de
3.6- Implementação
cada tipo de solicitação
3.7- Avaliação 24h
Assim, após deixar o ambiente estável, pode-se iniciar o
segundo passo que poderá ser a implantação do processo de
Gestão de Incidente. Depois poderão vir outros processos:
Gerenciamento de Problemas, Gestão de Nível de Serviço,
Gestão de Configuração, Gestão de Capacidade, Gestão de
Disponibilidade, Gerenciamento Financeiro e Gestão de Con-
tinuidade dos Serviços de TI.
Com a proposta de implantação do gerenciamento de mu-
danças estima-se como principais benefícios uma melhora
no alinhamento das solicitações com o negócio, maior índice
de assertividade, maior disponibilidade do tempo da equipe
de desenvolvimento, melhora na produtividade, redução de
transtornos e serviços de alta qualidade. Estes benefícios
podem ser alcançados, desde que sua equipe seja capaz de
filtrar e priorizar as mudanças, ocasionando na redução da
quantidade de solicitações a serem realizadas. Deste modo
estima-se que a disponibilidade da equipe de desenvolvimento
irá ser maior possibilitando uma melhora na qualidade dos
serviços prestados.
Plano de Reversão
Esta atividade deve prever quais passos, se possível, devem
ser aplicados para que mudança retorne ao seu estado de ori-
gem, ou seja, em uma situação limite onde o procedimento deve
ser abortado, o que se deve fazer para minimizar os impactos
e “voltar” na situação pré-mudança.
Estimativa de Custos Operacionais
A estimativa de custo tem como objetivo mensurar quais
custos diretos está envolvido na mudança e os ganhos finan-
ceiros, se existirem.
Classificação dos Resultados
Quanto aos resultados, o gerenciamento da mudança pode
ser classificada em:
• Sucesso: Quando a mudança foi bem sucedida, ou seja, o
objetivo proposto foi alcançado dentro do tempo planejado.

• Impacto: Quando a mudança foi realizada, no entanto, ultra-
passou o tempo planejado, causando impacto para o mesmo.
• Falha: Quando a mudança não pôde ser concluída devido
a algum problema durante sua execução e que a mudança foi
abortada, porém dentro da janela acordada com o cliente.
Prevenção
As prevenções que seguem são fundamentais para a definição
do escopo do Processo Gerência de Mudanças:
• Cabe ao Solicitante da mudança fazer seu planejamento
técnico.
• Quando um pedido de mudança é feito, todas as informações
técnicas e de planejamento devem ser acompanhadas desde
o início do pedido.
• O processo de Gerência de Mudanças não possui envolvi-
mento direto com a fase de implementação da mudança, porém
deverá monitorá-la e registrar sua implementação
Aprovação: Processo e responsável
Durante a Reunião de mudanças, todas as mudanças
apresentadas serão aprovadas ou não pelo grupo técnico
participante da reunião. Se não houver o consenso do grupo
para sua aprovação, essa mudança será levada para outra reu-
nião mais técnica e específica (mudança crítica), onde serão
en gen haria
discutidas com mais detalhes. Estando a mudança acordada
na reunião, será buscada a aprovação formal dos coordena-
dores. Essa aprovação significa que a mudança foi negociada
e autorizada, sendo assim cabe ao Coordenador de Mudanças
da empresa que será o gerente de Projetos que também é o
gerente de TI, aprovar somente as mudanças requisitadas
pelos analistas e/ou outros solicitantes e ao Coordenador
Geral da empresa que será o gerente geral, sinalizar que a
mudança foi negociada.
Mudanças Emergenciais
Desde que sejam registradas adequadamente e negociadas
com a Gerência de Mudanças, mudanças de emergência
poderão ocorrer a qualquer momento, passando antes por
uma triagem onde deverá ser comunicado e esclarecido o
motivo da emergência, cabendo ao coordenador avaliar a real
necessidade.
As responsabilidades do setor responsável pelas mudanças
são:
• Coordenar todas as mudanças solicitadas;
• Garantir a existência de planos de retorno para as mudan-
ças;
• Em caso de falhas, garantir a implementação do plano de
retorno para as mudanças executadas pela empresa;
Edição 69 - Engenharia de Software Magazine 53
• Aprovar ou rejeitar as mudanças apresentadas que tenham
impacto no negócio, custo ou afetem o ambiente de TI da
empresa;
• Identificar e informar as mudanças e apresentar as informa-
ções necessárias para o seu perfeito entendimento;
• Detalhar o cronograma e o planejamento das mudanças;
• Produzir toda a documentação necessária para a mudança;
• Cancelar ou reprogramar as mudanças quando necessário,
justificando motivo da ação;
• Avaliar os impactos das mudanças planejadas junto aos soli-
citantes e representantes técnicos das várias áreas envolvidas,
garantindo que todos estejam cientes e em concordância com
a mudança;
• Executar as mudanças conforme o cronograma e atividades
definidas pelo solicitante das mudanças;
• Fornecer informações sobre qualquer problema ocorrido
durante a execução das mudanças;
• Interagir com o “Solicitante” para garantir que o requeri-
mento de mudança foi atendido, informando-lhe o status final
e os detalhes da execução;
Investimento de Implantação
A implantação da metodologia na empresa não terá muitos
investimentos financeiros, somente o de implementação e
documentação. Os funcionários que irão atuar diretamente na
implantação da mudança terão que realizar cursos de certifi-
cação ITIL. Esses cursos podem ser feitos online. A empresa
pode comprar apenas um pacote de cursos que tem um custo
aproximado de R$ 600,00 e colocar os funcionários para realizar
os cursos numa sala usando um Datashow, assim, o gasto será
menor. Caso a empresa queira que os funcionários envolvidos
tenham a certificação ITIL, terá um gasto de aproximadamente
R$370,00 para cada diploma, ou seja, por cada funcionário que
realizar a prova de certificação.
Observando a grande dificuldade de obtenção de ferramentas
e informações para melhor gerir uma organização da área de
TI, observa-se a grande importância de se ter um mecanismo
eficaz para gerenciar e auxiliar os processos de tomada de
decisão.
A implementação dos processos baseados na ITIL está re-
lacionada diretamente a um profundo e extenso programa
54 Engenharia de Software Magazine - ITIL: Como implantar o gerenciamento de mudanças
de mudança, fazendo com que a equipe da área de TI adote
um novo comportamento. Assim, a governança de TI serve
para controlar os objetivos da área de tecnologia, alinhar as
estratégias, definir expectativas e medidas de desempenho,
viabilizando e gerenciando recursos, definindo prioridades,
direcionando as atividades de TI e gerenciando riscos.
Para uma implementação eficaz de ITIL, não basta conhecer
as melhores práticas, especialmente no que se refere aos
benefícios de longo prazo para o negócio e o alcance de uma
situação de excelência dentro da organização de TI. Ideal-
mente, uma implementação de ITIL com sucesso significa
que as pessoas da organização assimilaram na sua cultura,
os processos e procedimentos da ITIL. O fundamental é
que a adoção da ITIL permitirá a adoção de uma cultura
de melhoria contínua de qualidade dos serviços prestados
pela área de TI que, no mínimo, garantirá a manutenção
dos ganhos já obtidos.
Referências e Links:
[1] MAGALHAES, Ivan Luizio; PINHEIRO, Walfrido Brito. Gerenciamento de
Serviços de TI na Prática: Uma abordagem com base na ITIL. São Paulo.
Novatec, 2007.
[2] MANSUR, Ricardo. Governança de TI. 2004
http://www.profissionaisdetecnologia.com.br/modules. php?name=News&file=art
icle&sid=63
Para mais informações sobre o ITIL
http://www.itil-officialsite.com/
Key Performance Indicators
http://management.about.com/cs/generalmanagement/a/keyperfindic.htm
Você gostou deste artigo?
Dê seu voto em www.devmedia.com.br/esmag/feedback
Ajude-nos a manter a qualidade da revista!
Desenvolvimento
Nesta seção você encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software
Boas práticas de programação
Leandro Tavares Siciliano
ltsiciliano@gmail.com
Formado em Análise de Sistemas UNESA com
MBA na UFRJ. Experiência de 17 anos de mer-
cado. Atualmente atuando como desenvolvedor
desenvolvedor Java e Lotus Notes. Certificações:
Certified Lotus Professional e Scrum Master.
A
vida de um programador não
é fácil. A tecnologia é algo
que não para de evoluir e a
cada dia surge uma forma diferente de
escrever um código. A carreira de um
profissional de informática é algo de sua
responsabilidade. O código produzido
por esse profissional também é de sua
responsabilidade. Um bom código não
é somente aquele que é funcional, mas
também aquele que não tem valores
exorbitantes para ser mantido. A maior
parte dos programadores não gostam de
alterar códigos mal escritos. Isso é algo
que traz muita frustração e muitas vezes
um retrabalho desnecessário.
Clean Code
Um código limpo deve ser:
• Simples: código fácil de entender;
• Direto: vai direto ao ponto, não dá
“voltas” para atingir seu objetivo;
Edição 69 - Engenharia de Software Magazine
Fique por dentro:
Este artigo apresenta um conjunto de boas prá-
ticas de programação com o objetivo de mostrar
como pequenas modificações podem ajudar no
dia a dia dos programadores e profissionais de
TI. As boas práticas aqui apresentadas podem
ajudar no desenvolvimento profissional daque-
les que trabalham envolvidos em atividades de
programação.
• Eficiente: código que faz o que é
proposto;
• Sem duplicidade: não faz o que outra
parte do código já faz;
• Elegante: porque é diferente dos outros
códigos;
• Feito com cuidado: quem fez teve preo-
cupação em produzir aquele código.
Antes de falarmos sobre como fazer
para atingir esse nível de qualidade,
vamos falar um pouco sobre testes.
Importância dos testes
Construir um software não é somente
escrever código e vê-lo funcionar, é você
saber que aquele código será manutení-
vel e que outras pessoas vão alterá-lo.
55
 Para isso, teste é fundamental! Você tem que ser responsável
por aquilo que escreve e saber que seu sistema tem que con-
tinuar funcionando. Neste contexto, temos a primeira dica
sobre um código limpo: “Toda linha que você escrever deve estar
testada e ponto final !”
Muitas empresas veem testes como gastos maiores no pro-
jeto, o que de fato acontece, porém a qualidade do software
produzido é algo significante. Quando não se produz teste
automatizado, a quantidade de testes manuais são maiores e
muitas vezes o custo desses testes também é maior.
Nomes significativos
Métodos, nomes de variáveis e etc. devem possuir nomes que
significam alguma coisa em relação ao seu objetivo. Os nomes
utilizados devem responder todas as questões a seguir:
• Porque existem?
• O que fazem?
• Como são usadas?
Vamos imaginar que um sistema de um motor de um carro
tenha um método com o nome de “run” ao invés de “acelerar”.
Se você pegar um código com esse nome você terá que estudar
todo o método para saber o que ele faz.
Algo muito comum encontrado nos códigos é o tipo de de-
claração apresentado na Listagem 1.
Se um nome de classe, método ou atributo requer um comen-
tário, ele não está revelando sua real intenção.
Listagem 1. Exemplo de declaração
public class NotaFiscal {
private Date d1;//Data da compra
private Date d2;//Data de vencimento
private boolean validaDatas(){
//Valida se data do vencimento é maior que a data de compra
if(d1.after(d2))){
return true;
} A regra para métodos é: “A primeira regra dos métodos é que
return false;
} ser menores ainda.”
//getters e setters
}
Quando colocamos uma linha em nosso código com um co-
mentário ao lado não estamos dando o nome correto ao atributo
ou método. O código quando bem escrito deve ser algo que
seja de fácil leitura, algo que uma pessoa leiga conseguiria ao
menos saber o que o mesmo faz. Os nomes utilizados devem
ser pronunciáveis, algo que você entenda.
Observe no exemplo da Listagem 2 como essa prática torna
o código mais fácil de ser entendido.
56 Engenharia de Software Magazine - Boas práticas de programação
Listagem 2. Exemplo de declaração considerando boas práticas
public class NotaFiscal {
private Date dataCompra;
private Date dataVencimento;
private boolean isDataVencimentoMaiorDataCompra(){
return dataCompra.after(dataVencimento);
}
//getters e setters
}
Evite notação húngara
A notação Húngara visa facilitar o reconhecimento do tipo
de variável em um programa colocando em seu nome um su-
fixo descrevendo seu tipo (ver Listagem 3). Entretanto, com o
advento de novas linguagens, técnicas mostradas aqui e testes
automatizados, a notação húngara se mostra desnecessária.
Existe uma certa tendência para a criação de classes e méto-
dos menores de modo que as pessoas possam ver onde cada
variável que estão usando foi declarada. Além disso, os testes
indicam os tipos e maneiras de usar, validando o comporta-
mento esperado do método.
Listagem 3. Exemplo de uso de notação húngara
public class Pessoa {
private String nomeString;
// Não existe aqui a necessidade de se colocar a palavra ‘String’,
// pode-se somente ficar ‘nome’
//getters e setters
}
Classes e métodos
Nome de classes devem ser substantivos e não conter verbos.
Já nomes de métodos devem conter verbos, pois eles indicam
ações.
eles devem ser pequenos. A segunda regra é que eles devem
Métodos e classes menores são mais fáceis de ler e entender,
além de manter é claro. Segundo o livro, podemos considerar
as seguintes métricas:
• Métodos <= 20 linhas;
• Linha <= 100 caracteres;
• Classe = 200 a 500 linhas.
Claro que toda regra tem sua exceção. Se você tem uma clas-
se que vai precisar de mais linhas, um método que também
precise de mais linhas, isso não é um problema.
“Métodos e funções devem fazer somente uma coisa, fazê-la
certa e somente fazê-la”.

Poderíamos analisar essa frase como um princípio da coesão
no seu código. Muitas vezes não é fácil saber se aquele método
está fazendo somente uma coisa. Uma dica para isso é: você
deve tentar extrair parte do seu código para um método, se
você conseguir é porque aquele seu método realmente não
está tendo uma função apenas.
Imagine que você tenha um método onde quiséssemos mos-
trar os detalhes de um usuário:
private void mostrarDadosUsuario(Usuario usuario){
mostrarCabecalhoUsuario();
System.out.print(“Nome: “, usuario.getNome());
S ystem.out.print(“Sobrenome: “, usuario.getSobrenome());
}
Neste exemplo, as linhas do System.out.print são os detalhes
do usuário. Mas será que isso não ficaria melhor escrito se
estivesse de acordo com o código da Listagem 4?
Listagem 4. Separando métodos
private void mostrarDadosUsuario(Usuario usuario){
mostrarCabecalhoUsuario();
mostrarDetalhesUsuario();
}
private void mostrarDetalhesUsuario{
System.out.print(“Nome: “, usuario.getNome());
System.out.print(“Sobrenome: “, usuario.getSobrenome());
}
Se um dia você quiser apenas listar os dados de um usuário
ficará mais fácil. Agora temos os métodos separados. Essa
prática também é um bom exemplo do tipo de refatoração
chamada “Extract Method”.
Um outro item que deve ser observado é a quantidade de pa-
râmetros de um método. Você deve ter uma justificativa muito
boa para ter uma quantidade tão grande de parâmetros em um
método. Um agravante de um método com vários parâmetros
é a dificuldade de se testar uma vez que você deverá testar
todas as combinações possíveis.
Outra situação a que você deve estar atento é com um método
que informa que irá fazer uma determinada ação e faz outra.
Observe a Listagem 5.
O objetivo do método é verificar a senha, porém, se a
senha estiver correta o mesmo inicia uma sessão, ou seja,
o método já não tem a coesão esperada, pois possui duas
responsabilidades.
Uma solução melhor para esse cenário pode ser observada
na Listagem 6.
Comentários nos códigos
Comentários, apesar de importantes, podem trazer desin-
formação. Por que podemos afirmar isso? Alguém conhece
programadores que atualizam comentários? Há vários códigos
desen volvimento
com vários comentários que não serviam para nada e, pior,
confundiam. Se um método ou uma classe estiver bem escrito,
a importância do comentário é minimizada.
Listagem 5. Métodos com objetivos mal definidos
public boolean verificarSenha(String senha){
if(senha.equals(“zzz”)){
Session.initialize();
return true;
}
return false;
}
Listagem 6. Ajuste do objetivo do método
if(verificaSenha(“zzz”){
Session.initialize();
}
public boolean verificarSenha(String senha){
if(senha.equals(“zzz”)){
return true;
}
return false;
}
Outro ponto importante, um comentário não irá esconder
um código ruim. Observe o exemplo a seguir:
Date d1;
Esse código já está ruim, de nada adianta mudarmos para:
Date d1; //dia da semana
Esse comentário não irá se propagar para todo o código e sem-
pre que você se deparar com uma linha como “d1.after(d2);”
você vai continuar não entendendo o propósito do código.
Podemos tentar colocar uma regra nisso. Muitas vezes quan-
do se comenta um código, pode ser que o mesmo precise ser
refatorado. Lembra dos exemplos anteriores onde “d1” passou
a ser “dataCompra”? Com essa mudança seu código pode ser
entendido por todos e se fizermos essa refatoração o código
passa a não precisar mais de comentário.
Observe agora o exemplo a seguir:
//Verifica se o usuário tem direito ao benefício
if(usuario.getIdade() > 10 && usuario.getIdade() < 20){
….
}
Observe agora o exemplo ajustado na Listagem 7.
Note que tiramos o comentário, melhoramos o código e o
tornamos mais legível. Agora a leitura do código é suficiente
para saber o que ele realmente faz.
Outro tipo de comentário que deve ser evitado é apresentado
no exemplo a seguir:
Edição 69 - Engenharia de Software Magazine 57
private boolean isUsuarioTemDireitoAoBeneficio(Usuario usuario){
if(usuario.getIdade() > 10 && usuario.getIdade() < 20){
return true; //Retorna verdadeiro
}
return false; //Retorna falso
} porquê o desenvolvedor tomou aquela decisão.
Listagem 7. Eliminando o comentário do código
if(isUsuarioTemDireitoAoBeneficio(usuario)){
….
} de desenvolvimento vai se comunicar. Uma pessoa não gostaria
private boolean isUsuarioTemDireitoAoBeneficio(Usuario usuario){
if(usuario.getIdade() > 10 && usuario.getIdade() < 20){
return true;
} Outra ponto importante é que se você pega um código
return false;
}
O return do método é lógico, não há necessidade de indicar
o que o mesmo está retornando.
Em relação a comentários, podemos dizer que: “Qualquer
comentário que faça você olhar para outras partes do seu código para
entendê-lo não valem os bits que consomem.”
Por outro lado, existem momentos em que o comentário
é importante. Digamos que você tenha um trecho em seu
58 Engenharia de Software Magazine - Boas práticas de programação
código que vai demandar um tempo de processamento alto
ou a disponibilidade de um recurso. Nesses casos, comen-
tários acabam sendo úteis. Algumas vezes também não se
consegue colocar um nome em um método que explique o
Formatação
“Formatação é importante, pois se trata de comunicação.”
Temos que considerar que o código é a maneira que a equipe
de receber uma carta cifrada onde tivesse que interpretar o que
está escrito nela, podemos pensar assim na hora de escrever
um código.
bem estruturado, você vai querer mantê-lo bem estruturado.
É ruim para qualquer desenvolvedor ter acesso a um código
sem formatação, sem endentação e ter que fazer sua leitura
como se fosse um texto sem qualquer pontuação.
Além disso, métodos com conceitos relacionados devem ficar
verticalmente próximos e a ordem dos métodos deve criar um
fluxo de leitura melhorando a legibilidade do código.
Uma boa endentação é fundamental, mas não podemos ter
muitos níveis. Observe como o trecho a seguir poderia se tornar
confuso caso a lógica implementada fosse complexa:

if(a>1){
if(b>1){
if(c>1){
if(z>1){
… • *I (Independent): não podem depender um do outro pois se
} um falha o outro vai falhar também;
}
}
} retornar sempre o mesmo resultado;
Tratamento de erros
“Quando estamos programando devemos tratar os possíveis
erros que nossa aplicação poderá lançar, as coisas podem dar
errado e temos que estar certos que nosso código fará o que
deve fazer.”
Tratamento de erro é de responsabilidade do desenvolvedor.
É preciso garantir que o código vai ter um tratamento para
cada situação. Prefira lançar uma exception ao invés de retornar
um código de erro. Estes retornos desorganizam a chamada do
método e pode-se facilmente esquecer de verificá-los.
Dentro do seu método você já pode ver o erro que está sendo
retornado e tratá-lo ali. Defina o fluxo do método separando
as regras de negócio de erros ou outras situações. Para seus
erros, crie mensagens informativas mencionando a operação
que falhou e o tipo de falha.
Procure utilizar exceptions para situações inesperadas, por
exemplo: seu código está lendo um arquivo e a rede se tornou
indisponível.
TDD
TDD nada mais é que o desenvolvimento guiado por testes.
As três regras do TDD são:
• Você não pode escrever um código até que tenha criado um
teste falhando;
• Você não pode escrever mais teste do que seja suficiente
para falhar;
• Você não pode escrever mais código do que o suficiente para
passar no teste que está falhando.
Assim, se você tiver que testar se um CPF é válido, por exem-
plo, você deve criar alguns testes tais como:
• se o CPF for em branco;
• se o CPF estiver com menos caracteres.
desen volvimento
Os testes devem considerar as características F.I.R.S.T:
• *F (Fast): deve ser rápido. Testes demorados tiram a motivação
dos profissionais responsáveis por sua execução;
• *R (Reapetable): executando mais de uma vez eles devem
• *S (Self-Validating): devem se autovalidar;
• *T (Timely): devem ser feitos antes do código.
Refatoração
Escrever um bom código muitas vezes pode não parecer uma
missão tão simples. Considere o trecho de código a seguir:
private boolean isStringVazia(String texto){
    if (!StringUtils.isNullOrEmpty(texto) && !texto.equals(“”)) {
        //...
   }
}
Concorda que o “!texto.equals(“”)” não serve para nada? Se fi-
zermos a refatoração a seguir obteremos o mesmo resultado:
private boolean isStringVazia(String texto){
    if (!StringUtils.isNullOrEmpty(texto)) {
        //...
  }
}
Agora, digamos que ainda assim estivéssemos com receio
de fazer essa refatoração. Neste caso, a presença de um sim-
ples teste unitário poderia eliminar a dúvida referente ao
fato da funcionalidade continuar desempenhando seu papel
corretamente.
A refatoração é uma das melhores práticas para melhorarmos
nosso código. Seu código pode ser eficaz, ou seja, fazer o que
se deseja, mas também pode ser eficiente, fazer o que se deseja
da melhor maneira possível.
Você gostou deste artigo?
Dê seu voto em www.devmedia.com.br/esmag/feedback
Ajude-nos a manter a qualidade da revista!
Edição 69 - Engenharia de Software Magazine 59
60 Engenharia de Software Magazine - Boas práticas de programação