Você está na página 1de 60

Rodrigo Oliveira Spnola

rodrigo.devmedia@gmail.com
Doutor e Mestre em Engenharia de Software pela COPPE/UFRJ. Realizou seu Ps-Doutorado na
University of Maryland Baltimore County e Centro Fraunhofer nos Estados Unidos. Atualmente
Professor Titular do Programa de Ps-Graduao em Sistemas e Computao da Universidade
Salvador - UNIFACS.

Marco Antnio Pereira Arajo


maraujo@devmedia.com.br
69 Edio - 2014
Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ, Especialista em
Corpo Editorial Mtodos Estatsticos Computacionais e Bacharel em Matemtica com Habilitao em Infor-
mtica pela UFJF.
Editor
Rodrigo Oliveira Spnola Eduardo Oliveira Spnola
eduspinola@gmail.com
Colaboradores
Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Magazine.
Marco Antnio Pereira Arajo
Eduardo Oliveira Spnola bacharel em Cincia da Computao pela Universidade Salvador (UNIFACS).
Nicolli Souza Rios Alves

Consultora Tcnica
Daniella Costa
Nicolli Souza Rios Alves
nicolli.devmedia@gmail.com
Jornalista Responsvel Bacharel em Cincia da Computao na Universidade Salvador (UNIFACS), Mestranda em Sistemas
Kaline Dolabella - JP24185 e Computao no Programa de Ps-Graduao em Sistemas e Computao 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, endereo de bancas de entrar em contato com os editores e dar a sua sugesto!

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 ttulo e mini-resumo do tema que voc gostaria
www.devmedia.com.br/central
(21) 3382-5038 de publicar.

Publicidade
Para informaes sobre veiculao de anncio na revista ou no site entre em
contato com:
publicidade@devmedia.com.br
Sumrio
Contedo sobre Agilidade

06 Scrum: uma viso prtica do framework


[ Roberto Passani ]

Contedo sobre Boas Prticas

11 PMBOK: Trabalhando com gerenciamento de custos


[ Fabiana de Lima ]

Contedo sobre Boas Prticas

18 Riscos em projetos de software com PMBOK


[ Jhoney Lopes e Jos Luis Braga ]

Contedo sobre Boas Prticas

30 Gerncia de Projetos: Monitore e controle o desenvolvimento de software


[ Rommel Gabriel Gonalves Ramos e Daniel Couto Gatti ]
Feedback
eu
s
D

Contedo sobre Boas Prticas

sobre e
35 Gesto de Projetos: Usando processos de desenvolvimento
[ Rommel Gabriel Gonalves Ramos e Daniel Couto Gatti ]
s
ta
edio

Artigo no estilo Prtico


D seu feedback sobre esta edio!
43 ITIL: Como implantar o gerenciamento de mudanas
[ 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
Contedo sobre Boas Prticas, Contedo sobre Arquitetura e desenvolvimento da revista!

55 Boas prticas de programao www.devmedia.com.br/esmag/feedback


[ Leandro Tavares Siciliano ]
Edio 05 - Engenharia de Software Magazine 5
Agilidade

Nesta seo voc encontra artigos voltados para as prticas e mtodos geis.

Scrum: uma viso prtica do framework

Fique por dentro:


Esse artigo se prope a mostrar uma abordagem
prtica do Scrum da forma como aplicado em

O
Scrum uma abordagem gil um projeto real, detalhando os papis e funes
que prima pela otimizao e de cada participante, cada etapa do processo e
objetividade no processo e em sua importncia para que o projeto e a equipe
todas suas etapas, costuma minimizar ganhem maturidade e evoluam de forma que
burocracias, documentao e mdulos se obtenha um produto com qualidade e que
em relao a outros processos (como obedece s regras da plataforma utilizada.
RUP). Tudo baseado nas reunies do
processo (que so muitas). Entre uma
reunio e outra o trabalho realizado. A equipe na qual este artigo foi baseado
Essas reunies so importantes ao ponto constituda uma Product Owner, um
de algumas empresas no usarem ne- Scrum Master (que tambm acumula fun-
nhuma documentao escrita, ou seja, es de Coordenador), um Analista de Tes-
fazem Sprints semanais e reunies s tes (o autor do artigo), uma Designer, um
segundas e sextas, de Planning e Review Analista de UX (User Experience) e quatro
respectivamente, onde fazem todo o tra- desenvolvedores, que se dividem entre as
cking das atividades e desenvolvimento plataformas iOS e Android, fora outras
do produto. pessoas que auxiliam a equipe, como ana-
Roberto Passani Neste artigo usaremos o modelo de um listas de produto, infraestrutura e outros.
robertopassani@gmail.com
Sprint de 10 dias teis, ou aproximada- A manuteno do processo responsabi-
Quase oito anos de experincia com testes de
software, iniciado em qualidade de sistema mente 14 dias corridos, sendo o Planning lidade do Scrum Master, ou seja, marcar
operacional de aparelhos celulares, depois no primeiro dia e o Review no ltimo. todas as reunies, garantir a presena de
banco de dados, sistema de investimentos, pla- Aps o Review ocorre a Retrospectiva toda a equipe, comandar as reunies em
taforma de e-commerce e atualmente atuando e no decorrer do Sprint o pr-planning. si, escrever no sistema de gerenciamento
com aplicativos mveis. H pouco menos de um
Diariamente devem ocorrer as reunies do processo, auxiliar no desenvolvimento
ano atuando em projeto de aplicativos mveis.
Recentemente teve a oportunidade de conhe- Dirias (Daily Meetings). Todas essas dos critrios de aceite, avaliar questes de
cer mais do processo Scrum na prtica. etapas so detalhadas no artigo. servio, backend e etc.

6 Engenharia de Software Magazine - Scrum: uma viso prtica do framework


agilidade

Um Sprint nunca deve ser iniciado com a quantidade de


Definio do Projeto pontos excedida, com histrias que possuem critrios de aceite
O primeiro passo para desenvolvimento de um sistema no no definidos, sem layout ou definio de UX incompleta. Por
Scrum seria a reunio de pre-planning (pr-planejamento), onde isso, se a quantidade de pontos for excedida e no houver a
so definidos o objetivo principal do sistema, isto , aquilo que possibilidade de troca com outra histria, ento os critrios de
ele deseja atingir: o mercado, o pblico e a/as funcionalidade(s) aceite devem ser divididos em duas histrias, sendo uma no
principal(ais) - para um aplicativo, por exemplo, seja trnsito, Sprint atual, fechando o sprint dentro da mtrica de pontua-
notcias, compras ou futebol - onde so pr-planejadas as his- o e outra como a primeira histria do prximo (segundo),
trias que iniciaro o desenvolvimento, e nelas so inseridos os abrindo o prximo sprint com os pontos e critrios de aceite
critrios de aceite ou entrega. Estes so basicamente os requisitos que restaram, devendo ser devidamente entregue cada uma
do sistema, o detalhamento de todas as funcionalidades, desde em seu sprint.
as mais simples quelas principais. No planning, todo o layout e definies de UX j devem estar
O ttulo das histrias devem ser escritos na perspectiva de prontos e aprovados pelo Product Owner, tudo j deve estar
quem desejam atingir, por exemplo: Eu, como cliente, quero disponvel para anlise da equipe de testes e desenvolvimento.
que o aplicativo faa ou Eu, como rea de negcios da em- No caso de aplicativos mveis necessrio ter a tela completa
presa, quero inserir a logomarca de nosso patrocinador, ou e tambm cada boto separado, cada cone, com todas as de-
ainda, Eu, como Product Owner, quero ver uma mensagem finies de tela para iOS: retina e no-retina, e para Android:
de erro quando o usurio executar uma ao indevida. Isso LDPI, MDPI, HDPI, XHDPI, XXHDPI. O ideal anexar todas
facilita analisar quem deve aprovar a histria. Caso exista as imagens na histria para facilitar o acesso para a equipe
algum alm do Product Owner, o Scrum Master consegue otimizando o tempo e evitando ter que buscar em Drivers,
analisar se h algum alm dos participantes diretos do projeto e-mail, e etc., ou em um sistema de pastas que nem sempre
que deva ser convidado para os ritos, como Planning e Review, claro para todos. Portanto, para realizar o desenvolvimento,
se h algum externo equipe que deseja inserir histrias ou todas as histrias do sprint que est para se iniciar precisam
acrescentar algo ao sistema. ter status de definidas na ferramenta usada pela empresa, que
Todos devem participar desse processo, ajudar na definio indica que todos os dados aqui descritos j foram detalhados,
dos critrios, ajudar no levantamento de critrios de exceo, anexados histria e/ou link tenha sido disponibilizado.
mensagens de erro e possveis cenrios que faltam definio.
A equipe deve ser unida profissionalmente e ter o objetivo Iniciando o desenvolvimento
comum de entregar o melhor sistema possvel. E o analista de Logo aps o planning, o Scrum Master deve marcar o pr-
testes j inicia a escrita dos testes baseado nesses requisitos, planning, review e planning que esto por vir, para 10 dias
criando todos os testes de validao, exceo, carga, perfor- teis aps o primeiro planning, considerando que o planning
mance, e o que mais for necessrio, muitas vezes j escrevendo j ocorre no primeiro dia do sprint e o review no ltimo. Neste
os testes (apenas com objetivo) na prpria reunio, atravs de cenrio, se o planning ocorre em uma segunda-feira dia 01,
um bloco de notas, caderno ou qualquer outra ferramenta. J ento o pr-planning deve ser marcado para quarta-feira dia
a equipe de desenvolvimento pode comear a pensar em todo 10 (aproximadamente) e o Review exatamente para o dia 12,
o backend (servios e servidores) necessrio, e tudo que ser sexta-feira. Tudo isso deve ser marcado com antecedncia para
preciso para a implementao do sistema. que as datas de todos os ritos sejam de conhecimento de todos
da equipe evitando atrasos por indisponibilidade de local ou
Faa-se um sistema surpresa em sua realizao.
Uma vez estruturado o backend de servios, a equipe pode No projeto utilizado o TDD, ou seja, Test Driven Develop-
comear a implementao do software, e para priorizar as ment, porm um TDD um pouco diferente, no baseado em
histrias e analisar quais faro parte de um primeiro sprint testes unitrios ou automatizados, mas baseado nos testes
realiza-se uma primeira reunio de planning, onde as hist- funcionais escritos a partir dos critrios de aceite definidos
rias iniciais so colocadas no primeiro sprint e priorizadas na no pr-planning. Os testes da primeira histria da ordem de
ordem decrescente dentro dele. Primeiramente colocam-se priorizao devem ficar prontos antes do incio do Sprint. O
todas as histrias que precisam ser feitas e depois elas so desenvolvedor segue os casos de testes para criar o sistema.
priorizadas. Em seguida, pontua-se cada histria de acordo Portanto, o analista de testes j deve ter todos os testes escritos
com o critrio utilizado no projeto (Fibonacci, por horas ou e detalhados a essa altura do processo com a maior cober-
outro), da podemos analisar se ainda possvel inserir alguma tura possvel de forma otimizada. Esses testes devem estar
histria, se a meta de pontos no estiver sido atingida, ou se disponveis na ferramenta para anlise dos desenvolvedores
alguma histria dever sair se a meta estiver sido ultrapassada. evitando paradas e atrasos no desenvolvimento, pois todas as
Caso a meta tenha sido ultrapassada e a quantidade de pontos perguntas j devem ter sido levantadas e respondidas, todas
das histrias for maior do que os pontos ultrapassados, ento as mensagens de erro, validao e exceo com a cobertura
a ltima histria, segundo os critrios de priorizao, poder adequada de forma que nenhuma demanda tenha que ser
ser dividida em duas. coberta no meio processo.

Edio 69 - Engenharia de Software Magazine 7


Conforme as histrias forem sendo iniciadas, elas vo ob- para todos, de preferncia no projetor, e os critrios de aceite
tendo status de progresso na ferramenta. Aps isso, quando vo sendo passados ponto a ponto para anlise do cliente. Ele
forem sendo completadas, j podem ser disponibilizadas para pode realizar os testes necessrios e passar por seus critrios
teste. No caso de aplicativos mveis, gerado um build que de pronto. Quando finalizadas, as histrias obtm status de
instalado no aparelho, e os analistas de testes podem analisar approved no sistema e o cliente passa a analisar a prxima.
as funcionalidades j implementadas. Uma vez encontrados Caso a histria no seja completa e os critrios de aceite no
erros, eles devem ser registrados na ferramenta e, se bloquea- sejam todos atingidos, ela deve sofrer uma split, ser dividida
rem a histria e no forem recorrentes, devem ser corrigidos em duas, onde a segunda histria poder ser a primeira do
no prprio sprint. Caso sejam erros recorrentes ou que no prximo Sprint e ter os critrios de aceite que faltam para
bloqueiam a histria ou seus critrios de aceite, eles podem completar. Algumas ferramentas automaticamente repassam
ser deixados no backlog para priorizao posterior. as tarefas incompletas para a histria do prximo sprint.
Uma vez registrados bugs que ficam no sprint, eles devem Caso os critrios de pronto do cliente que no sejam atendi-
ento ser corrigidos em um novo build do sistema, e todos os dos, ou seja, ele visualizar novos critrios de aceite que deve-
testes da nova funcionalidade devem ser reexecutados para riam ser atingidos para que a histria possa receber o deploy e
garantir que a correo de um defeito no gerou erros em ficar disponvel para o usurio final, o que geralmente ocorre
outras partes da nova funcionalidade. Esse processo repe- com critrios de exceo ou mensagens de erro, ento deve
tido at que todos os testes sejam executados e nenhum erro ser criada uma nova histria para um sprint futuro e que ser
seja encontrado. Feito isso, a histria poder obter o status de priorizada no planning. Essa deve conter os novos critrios de
completa na ferramenta e poder ser liberada para o Review aceite que finalizam a nova funcionalidade.
que ocorrer no ltimo dia do sprint.
Diariamente, na rotina do projeto e com horrio fixo, sempre Pr-Planning Sprint 2
com a presena de todos ou o mximo possvel de compo- Durante o Sprint, deve ser realizada a reunio pr-planning.
nentes da equipe, deve ocorrer a Daily Meeting (Reunio Nela devem ser enriquecidas as histrias para o Sprint 2, inserir
Diria), onde todos devem resumir suas atividades do projeto critrios de aceite e priorizar histrias de UX, design e backend;
desde a daily meeting anterior, tentando detalhar as aes para que tudo esteja pronto quando houver o planning.
e que mtodos usou para atingir seus objetivos, abrindo es-
pao para que os colegas possam auxiliar em dvidas ou se Retrospectiva do primeiro Sprint
utilizar dos dados ali compartilhados como lies aprendidas Aps o planning, logo aps o fim do Sprint, deve ser feita
ou melhores prticas. uma reunio de retrospectiva. Nela se deve relatar como foram
Na prtica, sempre pode ocorrer de critrios de aceite ou ex- os ltimos dias (do Sprint), todas as atividades de sucesso,
ceo no terem sido definidos ou algum layout ou definio boas prticas, lies aprendidas e melhorar para obter um
de UX aparecer de ltima hora durante o Sprint. Nesse caso, processo mais slido e rico, satisfatrio para todos.
devem ser tratados com urgncia, uma vez que o desenvol- Geralmente abordam-se primeiro os pontos positivos,
vimento pode ficar parado at que artefatos sejam criados. mas no uma regra. Cada participante do projeto deve ter
O responsvel pela experincia de usurio (UX) ou designer oportunidade de colocar seu post-it no quadro, falar sobre
precisam ser chamados com urgncia e criar o material ne- o que desejar, geralmente so questes que deram certo nas
cessrio com o menor impacto possvel no sprint para evitar atividades de uma pessoa e ela deseja compartilhar com os
atrasos na entrega e remarcao do review. Caso essa soluo outros membros, abrir discusso sobre o ponto apresentado e
se torne demasiadamente grande e o impacto inevitvel, ento detalhar melhor sobre o tpico.
a histria pode ter a prioridade reduzida para o fim do Sprint, Aps essa etapa discutem-se os pontos de melhoria, que cos-
quando a definio ou artefatos necessrios estaro prontos. tumam gerar mais polmica e deixar nimos exaltados. Todos
Caso isso ainda no seja o bastante, ento podemos adiantar o devem se sentir vontade para falar de qualquer tpico: desde
fim do Sprint e essa poder ser a primeira histria do prximo, a internet no ambiente de trabalho, relacionamento com outras
porm a Review nunca deve ser adiada e o Sprint alongado, equipes, ar-condicionado, assim como questes tcnicas que
pois o impacto disso a longo prazo muito negativo, salvo em influenciam diretamente no projeto como design, UX, crit-
condies excepcionais. rios de aceite, formato de cdigo, algoritmos, processo, links,
atuao de colegas; ou tudo aquilo que no foi satisfatrio e
A entrega Verso 1.0 pode melhorar nas etapas futuras do processo.
Aps finalizado o processo de desenvolvimento, passadas Aps apresentados e discutidos os dois lados do ltimo
muitas daily meetings e muitas linhas de cdigo, ocorre a sprint, aes de melhoria devem ser tomadas, ou seja, Product
primeira reunio de Review. A primeira verso poder ser en- Owner, Scrum Master e Coordenador devem definir como e
tregue, as funcionalidades devem ser preparadas e o ambiente onde podem agir para tentar resolver ou, ao menos, apaziguar
todo pronto para a anlise do product owner. os pontos de melhoria do projeto que dependem de ao exter-
Ao iniciar a reunio, o sistema sob anlise deve estar dispon- na. Relacionamento com outras equipes, aes com a gerncia
vel para o Product Owner e as histrias devem ser exibidas da rea ou at com as diretorias da empresa com o objetivo de

8 Engenharia de Software Magazine - Scrum: uma viso prtica do framework


agilidade

tornar o ambiente do projeto o melhor possvel, aes internas, realizada corretamente em cada reunio a que pertence,
como performance de um colaborador especfico ou mudanas garantir que todos esto executando suas atividades no mo-
no processo devem ser resolvidas internamente e monitoradas mento certo do projeto, se o desenvolvimento segue padres
durante as daily meetings do prximo sprint. de qualidade, testes unitrios, design patterns, mtricas, bus-
Muitos projetos no veem importncia na retrospectiva, car novas formas de atingir metas assim como, analisar se o
principalmente com a evoluo dos sprints onde o processo fica analista de testes (ou qualidade) est seguindo corretamente
mais slido e as retrospectivas se tornam repetitivas. Porm, o processo, escrevendo os objetivos de testes no pr-planning,
s h evoluo do projeto se houver reunies de retrospectivas se os testes da primeira histria j esto prontos aps o plan-
bem feitas. importante tambm estar atento ao fato de que ning (para iniciar o desenvolvimento), se a cobertura dos
ningum pode levar os pontos de melhoria para o lado pes- cenrios de testes est adequada, coordenar se o processo
soal. Essa uma reunio para um processo de maturidade e corretamente seguido, bem prximo dos analistas que fazem
o conceito altamente profissional com objetivo de fazer um com que ele ocorra.
trabalho melhor. Seu excedente pode ser analisar o sistema e ver se h formas
diferentes e talvez melhores de fazer o mesmo, pesquisar,
Planning - Sprint #2 procurar se inteirar nos documentos sobre sistemas similares
Aps a retrospectiva, analisados os pontos positivos e defi- e analisar se h novos padres sendo adotados, procurar o
nidos os pontos de melhoria, ocorre o Planning para definir que h de mais moderno, quais os caminhos que esto sendo
o segundo sprint. As aes de melhoria j devem comear a seguidos para obter o melhor desse modelo de sistema, assim
ser adotadas imediatamente, e o processo se reinicia, histrias como tambm do processo. Seguir prticas, discusses em
devem ser priorizadas. Se houve histria com split no sprint fruns, ler as revistas especializadas e obter dados de como
anterior, ento essas podem ser as primeiras, porm no otimizar o processo sem denegrir a qualidade, ou seja, o
obrigatrio, por isso os branches devem estar bem organizados ScrumMaster deve ser sempre muito dedicado e proativo,
para que uma histria com menor prioridade possa ser conti- muito curioso e ciente das atividades diversas para ver falhas
nuada em um sprint posterior sem uma linha de aprendizado onde no esto olhando, seja no desenvolvimento ou nos testes,
muito longa. Aps priorizadas as histrias, deve-se discutir a sempre com objetivo de aprimorar onde pode haver algum
pontuao, e definir as histrias que ficam no Sprint e quais tipo de evoluo.
sero adiadas para os prximos sprints.
Devem ser evitadas discusses paralelas nas reunies. No
Planning algumas pessoas tendem a sair do foco, gostam de
opinar, porm o Product Owner quem define, as prioridades
so dele e da rea de negcios. necessrio manter o objetivo
de construir o Sprint rapidamente para retornar ao desenvol-
vimento, porm sem deixar pontos indefinidos, como dito
antes, todo o design, UX, backend, servios, etc., precisa estar
definido antes de iniciar o Sprint.

Descrio dos papis


Para explicar melhor as atividades durante o processo de de-
senvolvimento de software, interessante esclarecer as funes
e papis de cada ator no processo, o que esperado de cada um
e onde ele pode fazer algo mais, o quilmetro extra (verso
brasileira da Extra Mile americana, que aquilo feito alm do
esperado, alm das responsabilidades) por onde se pode andar,
onde se pode auxiliar na melhoria do processo para obter mais
qualidade do sistema e mais satisfao 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 funes
do Product Owner ou coordenador, por exemplo.

Scrum Master
Sua funo principal definir e manter o processo sendo
seguido, marcar e manter os ritos, garantir a presena de to-
dos (ou o mximo possvel) os participantes, ver se cada ao

Edio 69 - Engenharia de Software Magazine 9


Analista de Testes formulrios, para descobrir quais so as funcionalidades que
responsvel por validar e garantir a qualidade do sistema, o usurio procura, e quais melhorias enriqueceriam o sistema
verificar que os critrios de aceite so devidamente atendidos, e trariam mais usurios.
nenhum bug escape ou deixe de ser registrado, que os testes
regressivos continuem aumentando, sendo atualizados, evo- Designer
luindo, sendo executados em todos os critrios corretamente, O designer de um sistema responsvel pelo layout, escolha
que o ambiente seja bem preparado para a Review, que os de cores, logomarca, por aplicar o que o analista de produto
testes sejam bem escritos e a cobertura seja adequada j no (UX) projetou.
Planning.
Outra funo que o analista de testes costuma ter for- Coordenador
necer dados para as mtricas do projeto, analisar quantos funo do coordenador do projeto dar toda estrutura de
defeitos so encontrados, quantos so corrigidos e quantos qualidade para que a equipe de forma adequada. Normalmen-
novos defeitos so encontrados a partir disso. Alm disso, te, associa-se ao Scrum Master para garantir a manuteno dos
deve fornecer esses dados para a equipe de qualidade que ir ritos e que o processo seja seguido. Alm disso, atua no sentido
analisar o desenvolvimento do sistema e a performance dos de auxiliar na correo dos pontos de melhoria.
desenvolvedores, a evoluo da equipe e se o processo est
sendo seguido corretamente. Product Owner
o dono do projeto, o cliente. por ele que tudo comea,
Desenvolvedor quem toma as decises, as histrias so priorizadas com a
responsvel por criar o sistema, elaborar as funcionalida- opinio de todos mas de acordo com a vontade do PO. ele
des, seguir corretamente os testes e critrios de aceite, analisar quem define os critrios de aceite, na funo de cliente ele
pontos de exceo, levantar questes sobre o planning para utiliza todos os estudos do designer e do analista de UX para
visualizar falhas de cobertura, pontuar com critrio as histrias definir quais melhor se encaixam com os objetivos de projeto,
inserindo tambm o tempo de testes de cada feature e o regres- e as necessidades de quem de fato utiliza o sistema. Tambm
sion ao final do Sprint. Precisam tambm seguir o processo de funo dele atuar prximo rea de negcio para ajudar a
testes unitrios definido e garantir que haja sempre evoluo trazer patrocinadores, verba ou investimento ao projeto.
na quantidade de testes e melhora na cobertura. No Scrum, tudo ocorre ao redor das reunies, por isso elas
so primordiais e precisam ser muito bem feitas. Essas etapas
Analista de UX (Experincia de Usurio) precisam ser bem obedecidas para garantir a qualidade do
responsvel pelo desenho do sistema, interfaces com usu- sistema e ter evoluo no processo e no produto. Sendo bem
rio, a localizao das funcionalidades, o resultado esperado definidas as reunies e ficando claras as funes e responsa-
de cada ao, que o sistema tenha a melhor usabilidade, que bilidades de cada ator, as chances de desenvolver um projeto
as funcionalidades sejam prticas, atendam padres dos de sucesso utilizando o Scrum sero maiores.
fabricantes (no caso de aplicativos mveis, por exemplo), que
mensagens de erro sejam evitadas, mas, caso necessrio,
responsvel pelo texto da mensagem, pelo nome (label) dos
Voc gostou deste artigo?
botes.
Alm disso, deve analisar estatsticas do aplicativo, uso de
funcionalidades e priorizar aquilo que o foco e que o usurio D seu voto em www.devmedia.com.br/esmag/feedback
mais procura no sistema. Tambm responsabilidade do ana- Ajude-nos a manter a qualidade da revista!
lista de UX pesquisar e fazer simulaes com usurios, passar

10 Engenharia de Software Magazine - Scrum: uma viso prtica do framework


Planejamento e Gerncia
Nesta seo voc encontra artigos voltados para o planejamento
e gerncia de seus projetos de software.

Riscos em projetos de software com PMBOK

Fique por dentro: utilizados nos processos que o compe, propostos


A tarefa de gerenciar os custos do projeto englo- pelo Guia PMBOK. O tema til, principalmente,
ba, alm do minucioso processo de planejamento para gerentes de projetos que buscam aprofundar
e definio dos custos e de seu gerenciamento, seus conhecimentos no gerenciamento de custos
a definio e escolha de bons oramentos que em projetos de desenvolvimento de software e
tragam valor agregado ao processo, e ainda, o outros relacionados rea de TI. Serve tambm
controle de tais recursos de forma a cumprir com para desenvolvedores de software que trabalhem
aquilo que foi definido inicialmente. Este artigo em equipes de projeto e que visem aprimorar
apresenta uma abordagem para o gerenciamento seus conhecimentos em busca de minimizao
de custos em projetos da rea de TI levando em de custos para suas tarefas dirias, bem como, co-
considerao os principais aspectos desse tipo de nhecer um pouco mais sobre como os recursos de
gerncia e mostra quais so os conhecimentos um projeto so distribudos e gerenciados.

A
rea de TI para uma empresa definir uma variao no gerenciamento
possui oramentos altos, a de custos do projeto. Por isso, essa
tecnologia custa caro e os ele- uma atividade extremamente dinmica,
mentos correspondentes tambm, um junto com o gerenciamento do escopo e
bom servidor, por exemplo, pode passar do tempo definem um trip principal
da casa dos R$ 15.000,00. Muitas vezes da gerncia de projetos na rea de TI.
Fabiana de Lima o custo no definido pela equipe de Ressalta-se aqui que outras reas como a
fabianadelima@gmail.com
Mestre em Cincia da Computao na sub-
projetos e sim pelo prprio cliente ou qualidade, por exemplo, so de extrema
rea de Engenharia de Software, atua como rea supervisora da TI na empresa, que importncia para um bom projeto.
professora e pesquisadora na rea. Exerceu possui uma necessidade pulsante e esta- A tarefa de gerenciar os custos do
funes de analista de sistemas em empresas belece limites de custos para resolv-la. projeto engloba, alm do minucioso
de desenvolvimento de software e de recru- Com isso, as caractersticas do software processo de planejamento e definio
tamento e seleo. Atualmente, atua como
professora formadora tambm em cursos de
ou das necessidades do cliente/rea su- dos custos e de seu gerenciamento, a
EAD em Maring - PR. pervisora podem, e geralmente o fazem, definio e escolha de bons oramentos

Edio 69 - Engenharia de Software Magazine 11


que tragam valor agregado ao processo, As entradas so mecanismos utilizados ou ainda, outras mtricas como a anlise
e ainda, o controle de tais recursos de em cada processo, os quais podem ofere- de pontos por funo ou por casos de
forma a cumprir com aquilo que foi cer informaes ou dados referentes ao uso. Esses mtodos auxiliam em muito
definido inicialmente. projeto, oriundos de fatores ambientais o gerenciamento de custos, baseado no
Um projeto que envolva o desenvolvi- da empresa (determinaes j estabele- escopo definido atravs deles.
mento de software inclui as dificuldades cidas e que devam ser observadas para Considera-se que, embora o guia traba-
em se manter os custos iniciais, baseados o trabalho), ou de fatores externos (como lhe com os processos definidos, outros
nos requisitos levantados no incio do calendrio dos recursos disponveis) ou mtodos prprios para projetos de TI e
projeto at o trmino dele. Nisso est a ainda, gerados a partir de outros proces- que no so tratados no PMBOK (j que
importncia, associada ao gerenciamen- sos de gerenciamento do projeto (como o objetivo do Guia outro), podem ser
to de custos, tambm do escopo e tempo a baseline do escopo do projeto, plano de manipulados em conjunto e durante o
em questo. riscos, dentre outros). prprio gerenciamento de custos, reali-
J as ferramentas e tcnicas utilizadas zado atravs dos processos estabelecidos
Os mecanismos necessrios para o podem ser um padro (utilizadas em no PMBOK.
gerenciamento de custos todos os projetos da empresa) ou ainda A seguir, encontram-se os processos
Segundo o Guia de conhecimento estarem sendo utilizadas pela primeira necessrios para o gerenciamento de
PMBOK, so quatro os elementos neces- vez no projeto em questo. Elas podem custos, exemplificados em sua maneira
srios para o gerenciamento de custos de ser desde estimativas de trs pontos e de coexistirem em projetos de desenvol-
um projeto: o plano de gerenciamento anlise de reservas, passando por custos vimento de software. Esses processos
de custos, a estimativa de custos, a de- relacionados qualidade, at uma fer- devem ocorrer pelo menos uma vez
terminao de oramentos e o controle ramenta de software de gerenciamento em cada projeto e serem repetidos em
de custos. de projetos. cada uma das fases em que um projeto
Em pequenos projetos de desenvolvi- Por sua vez, as sadas so produtos, for dividido. De maneira diversificada,
mento, alguns desses processos podem fornecidos durante o gerenciamento eles fazem uso dos mecanismos (entra-
estar sobrepostos, sendo executados de custos, relacionados execuo de das, ferramentas e tcnicas e sadas)
de uma s vez como, por exemplo, o um dos quatro processos, dentre esses apresentados.
planejamento do gerenciamento e a esto as estimativas de custos das ativi-
estimativa de custos, resultando no de- dades, previses oramentrias, dentre Plano de Gerenciamento de Custos
senvolvimento de oramentos a serem outros. As sadas so elementos que O processo de Planejar o Gerencia-
feitos. Neste artigo, eles sero mostrados tambm podem variar muito, desde mento de Custos envolve a definio e o
isoladamente, para que um entendi- atualizaes no plano de gerenciamen- destino dos recursos disponveis para o
mento amplo de cada processo possa to de projeto, passando por medidas projeto. Em projetos de TI, normalmente
ser obtido. Ressaltamos que existem de performance de trabalho, indo at esses recursos so destinados a pessoal e
outros detalhes e ferramentas utilizadas uma baseline de custos e necessidades infraestrutura, contando algumas vezes
que so muito importantes para o bom de financiamento do projeto. com elementos de treinamento e implan-
gerenciamento. Em relao aos processos que j foram tao do produto ou servio.
As tarefas de estimar custos e control- citados, devemos ressaltar que em todos A Figura 1, retirada do Guia PMBOK,
los so as que demandam maior esforo eles o gerenciamento de custos pode ser ilustra o conjunto de entradas, de ferra-
do gerente, j que, em projetos de desen- desenvolvido com mtodos prprios ou mentas e tcnicas e de sadas que esto
volvimento de software as medies so estabelecidos para determinada rea de presentes nesse primeiro processo de
complexas de serem feitas e tornam-se aplicao de um projeto. A rea de tec- gerenciamento de custos, Plano do Ge-
uma rea a parte de estudos para que nologia da informao possui uma vasta renciamento de Custos.
um bom gerenciamento de custos possa gama de mtodos de anlise e medies, A seguir apresentam-se as entradas
ser feito. Para a execuo dos processos por exemplo, estimativas utilizadas em pertencentes a esse processo, com um
referentes ao gerenciamento de custos, metodologias geis de desenvolvimento exemplo de como elas podem ser conse-
trs itens so importantes: as entradas, as de software, como a partio de pontu- guidas em projetos de desenvolvimento
ferramentas e tcnicas e as sadas. ao das estrias definidas pelo cliente, de software:
Plano de gerenciamento de projeto:
um documento que contm as diretrizes
iniciais para o projeto, levando em consi-
derao todas as reas de gerenciamento.
Ele serve como entrada, pois, contm as
principais definies feitas a partir das ne-
cessidades tambm iniciais apresentadas
Figura 1. Entradas, ferramentas e tcnicas e sadas para o Plano de Gerenciamento de custos pelo cliente/usurio no ato de contratao

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


planejamento

do projeto. Elementos como as formas


adotadas para o trabalho, paradigmas
de desenvolvimento, possibilidades de
infraestrutura, participao do usurio
no projeto, recursos humanos disponveis,
stakeholders, dentre outros so elementos
que podem ser definidos nesse processo
e documentados com maior preciso em
suas respectivas reas de processo;
Contrato do projeto: esse um docu-
mento formal que contm uma descrio
inicial sobre os requisitos do sistema, em Figura 2. Entradas, ferramentas e tcnicas e sadas para o processo Estimar os Custos
alto nvel, alm de recursos financeiros
disponveis, marcos e entregas, dentre utilizadas, dentre outras. Novamente, durao das atividades e do projeto
outros; ouvir e conhecer quais softwares e como um todo.
Fatores ambientais da empresa: so tcnicas so utilizadas no ambiente A Figura 2, retirada do Guia PMBOK,
elementos como normas, padres ou organizacional uma boa prtica para ilustra o conjunto de entradas, de ferra-
diretrizes estabelecidos que podem vir planejar a definio de custos que sero mentas e tcnicas e de sadas que esto
a influenciar nos custos de desenvolvi- produzidos no projeto; presentes nesse segundo processo de
mento do projeto; Reunies: a equipe de projeto deve planejamento, Estimar os Custos.
Ativos de processo organizacional: ser reunida para planejar como o geren- A seguir apresentam-se as entradas
so elementos conseguidos a partir da ciamento e a distribuio dos recursos pertencentes a esse processo, com um
realizao de outros projetos na empre- ser realizada. Podem participar dessa exemplo de como elas podem ser conse-
sa, que possam vir a direcionar melhor reunio, o gerente de projetos, o patro- guidas em projetos de desenvolvimento
o gerenciamento de custos do projeto. cinador, membros da equipe seleciona- de software:
Um exemplo claro so definies ante- dos, stakeholders selecionados, enfim, Plano de gerenciamento de custos:
riores de recursos necessrios X reas de qualquer membro do projeto que tenha produzido como sada no processo ante-
trabalho, ou ainda, recursos financeiros responsabilidade sobre a boa execuo rior, tem como principal objetivo nortear
X recursos humanos em outros projetos do gerenciamento de custos do mesmo. a forma como o gerenciamento de custos
da rea. ser realizado no projeto;
A partir da realizao dessas tarefas, Plano de gerenciamento de recursos
De posse desses elementos de entrada, para o Planejamento do Gerenciamento humanos: produzido durante o processo
a tarefa de Planejar o Gerenciamento de de Custos, deve ser produzido como de gerenciamento de recursos humanos
custos pode ser executada. A partir do sada: traz pessoas, papis e cargos referentes
uso das ferramentas e tcnicas a seguir, Plano de gerenciamento de custos: em ao desenvolvimento de todo o projeto.
exemplificamos de forma simples seu projetos de TI ele pode ser visto como Deve-se ressaltar que em todo o projeto
uso para o desenvolvimento de um um documento simples que contenha stakeholders das mais diferentes origens
software: as principais atividades representativas podem ter participao ativa;
Opinio especializada: qualquer opi- do gerenciamento de custo em questo. Linha de base do escopo: a espe-
nio de membros tcnicos pertencente ao Podendo conter uma anlise referente a cificao do escopo do projeto, com as
grupo de stakeholders ou que participa- quais recursos sero destinados a pes- principais entregas e os requisitos de
ram de projetos anteriores definindo e soal, como tcnicos, programadores, ge- aceitao. Os documentos que vo sendo
planejando custos destinados a ativida- rentes, possveis servios terceirizados, produzidos durante o planejamento do
des de projeto podem ser ouvidas, para e ainda, a forma como os recursos sero escopo fazem parte dessa base para o
que melhores estimativas dos recursos destinados infraestrutura necessria projeto;
possam ser feitas no projeto; para o projeto, dentre outras. Cronograma do projeto: este docu-
Tcnicas analticas: a experincia no mento produzido durante o processo
planejamento de quais tcnicas podero Estimativa de Custos de gerenciamento do tempo do projeto e
ser melhor aproveitadas para a defini- O processo de estimar os custos do deve conter no mnimo as datas (incio e
o e o gerenciamento de custos um projeto envolve uma anlise crtica de trmino) planejadas para as atividades,
importante fator para o planejamento quais sero as devidas necessidades as metas, os recursos necessrios e o
de ferramentas de auxlio ao gerencia- dentro da relao espao (atividade) X encadeamento natural das atividades de
mento de custos que se pode utilizar, tempo do projeto. Custos em relao a acordo com as restries empregadas;
qual(is) tcnica(s) de anlise e estimativa mo de obra podem ser feitos, porm, Registro de riscos: conseguidos a
de recursos para as atividades ser(o) necessrio que isto esteja alinhado partir do processo de gerenciamento de

Edio 69 - Engenharia de Software Magazine 13


riscos do projeto so eficientes para que fiquem claros quais estrutura para controle dos recursos e tempo das atividades
so os riscos de uma seleo ou de uma disponibilizao de em questo. Um exemplo de software livre com essa funo
determinado recurso do projeto, dentre outras; o OpenProject citado na seo Links;
Fatores ambientais da empresa: so elementos como normas, Anlise de proposta de fornecedor: de posse de propostas
padres ou diretrizes estabelecidos que podem vir a influen- de fornecedores para o que necessrio para a realizao do
ciar os custos de desenvolvimento do projeto; projeto, o gerente deve analisar as mesmas para adequar: ex-
Ativos de processo organizacional: so elementos consegui- pectativas, custos necessrios e valores agregados. Isso pode
dos a partir da realizao de outros projetos na empresa, que levar ao resultado total de quanto o projeto custaria para ser
possam vir a direcionar melhor o gerenciamento de custos realizado. Este ainda pode ser a soma de valores de entregas
do projeto. Um exemplo claro so as linhas de base (baselines) individuais do projeto, quando subprodutos do projeto devem
do projeto, ou ainda, definio de recursos produzidos em ser desenvolvidos de forma independente;
antigos projetos. Tcnicas de tomada de deciso em grupo: nessas tcni-
cas o envolvimento da equipe de projeto nas estimativas
De posse desses elementos de entrada, a tarefa de Estimati- proporcionam maior comprometimento da mesma com os
va dos Custos pode ser executada, a partir do uso das ferra- gastos previstos X realizados. Nesse contexto, tcnicas como
mentas e tcnicas a seguir, exemplificamos de forma simples Brainstorming ou o particionamento por pontuao de estrias
seu uso para o desenvolvimento de projetos em TI: do cliente, usados em metodologias geis, so boas formas de
Opinio especializada: qualquer membro tcnico perten- envolvimento da equipe nas estimativas.
cente ao grupo de stakeholders do projeto pode ser ouvido,
para que, a partir de dados e experincias em projetos ante- A partir da realizao dessas tarefas para a Estimativa dos
riores, decises possam ser tomadas com o intuito de reali- Custos deve ser produzido como sada:
zar estimativas consistentes para o projeto em questo; Estimativas de custos das atividades: as estimativas finais
Estimativa anloga: estimar utilizando essa tcnica sig- podem ser produzidas em detalhes ou de forma geral, de
nifica ter como base projetos anteriores semelhantes para acordo com a necessidade do projeto. Essas estimativas devem
o clculo dos recursos do atual projeto. Ela necessita de conter todos os custos necessrios para o desenvolvimento do
menos custos para ser aplicada, porm, tambm menos projeto, inclusive custos de possveis distores na prpria
precisa que outras tcnicas que podem ser utilizadas, como anlise dos custos;
as que seguem; Bases das estimativas: todas as suposies e critrios utili-
Estimativa paramtrica: essa tcnica se utiliza de dados zados para a estimativa dos custos devem estar claros para que
estatsticos de projetos anteriores para realizar uma estima- se possa verificar possveis erros com facilidade. Quando do
tiva para parmetros conhecidos. Exemplo de parmetros uso de intervalos, do tipo valor estar entre: x-10% e x+10%)
so oramento, durao, dentre outros; este deve estar bem especificado, no contendo somente o
Estimativas de trs pontos: se baseia em trs casos para valor mdio indicado. Enfim, tudo o que for considerado
estimar: a anlise do melhor cenrio, a do pior cenrio e a dever estar relatado nesse tpico, independente se haver
do cenrio mais realista possvel, determinado a partir das uma descrio sucinta ou detalhada dos motivos pelos quais
dependncias e expectativas de atividades provveis; adotou-se tal critrio;
Anlise de reservas: um esquema de identificao de Atualizao de documentos do projeto: so produzidos
percentual para reserva de trabalho, com o intuito de su- de acordo com as modificaes realizadas a partir do plane-
prir incertezas do cronograma pode ser utilizado. Nessa jamento de custos do projeto. elas podem ser de melhoria ou
tcnica, conforme os dados passam a ser mais reais, as adequaes e podem gerar modificaes em diversos docu-
reservas podem tambm ser melhoradas, reduzidas ou at mentos, dependendo de sua origem. Exemplo: uma definio
eliminadas; ou mudana nos custos do projeto, pode gerar mudanas de
Custo da qualidade: englobam os custos durante toda cronograma de atividades do projeto, mudanas no planeja-
a vida do produto, como os de atendimento aos requisitos mento dos riscos do projeto, ou ainda, definio para aquisio
de qualidade, de retrabalho, ou ainda de preveno do no ao invs de produo no projeto, dentre outros.
cumprimento dos requisitos. Como custos de atendimento
aos requisitos podemos citar: testes de aceitao do sistema; Determinar o oramento
j os de retrabalho podem ser gerados por: falhas internas O processo de determinar o oramento do projeto uma
de programao ou de documentao do software; e os tarefa que depende, alm dos produtos (sadas) dos processos
de preveno: como um treinamento de usurios antes de anteriores do gerenciamento de custos, tambm de produtos
colocar o sistema em operao; oferecidos por outros processos de gerenciamento, como o
Software de gerenciamento de projetos: existem diversas escopo e o tempo.
ferramentas de auxlio definio, monitoramento e contro- A Figura 3, retirada do Guia PMBOK, ilustra o conjunto de
le de recursos para as atividades de projetos. Ferramentas entradas, de ferramentas e tcnicas e de sadas que esto pre-
de controle de custos normalmente disponibilizam toda a sentes nesse terceiro processo de Determinar o oramento.

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


planejamento

A seguir, apresenta-se as entradas determinado recurso do projeto, dentre incertezas no oramento pode ser utili-
pertencentes a esse processo, com um outras; zado. Nessa tcnica, conforme os dados
exemplo de como elas podem ser conse- Contratos: informaes de contratos passam a ser mais reais, as reservas po-
guidas em projetos de desenvolvimento e os custos dos mesmos sejam eles para dem tambm ser melhoradas, reduzidas
de software: aquisies de bens ou de servios devem ou at eliminadas;
Plano de gerenciamento de custos: ser relatados para que os custos possam Opinio especializada: qualquer opi-
produzido como sada no inicial, tem fazer parte do oramento total do proje- nio de membros tcnicos pertencente ao
como principal objetivo nortear a forma to. Um exemplo o contrato de servio grupo de stakeholders ou que participa-
como o gerenciamento de custos ser para fornecimento de Internet em proje- ram de projetos anteriores definindo e
realizado no projeto; tos de desenvolvimento em TI; planejando custos destinados a ativida-
Linha de base do escopo: a especifica- Fatores ambientais da empresa: so des de projeto podem ser ouvidas, para
o do escopo do projeto, com as principais elementos como normas, padres ou que melhores estimativas dos recursos
entregas e os requisitos de aceitao. Os diretrizes estabelecidos que podem vir possam ser feitas no projeto;
documentos que vo sendo produzidos a influenciar os custos de desenvolvi- Relaes histricas: elas podem ser
durante o planejamento do escopo fazem mento do projeto; utilizadas para a realizao de anlises
parte dessa base para o projeto; Ativos de processo organizacional: paramtricas ou anlogas, de forma que
Estimativas de Custo das atividades: so elementos conseguidos a partir custos estimados em outros projetos pos-
obtida como sada do processo anterior da realizao de outros projetos na sam servir de suporte para a definio
traz uma viso da relao custo X ativi- empresa, que possam vir a direcionar de custos de um novo projeto;
dades para os elementos do projeto; melhor o gerenciamento de custos do Restrio de limites financeiros: o
Bases de estimativas: que tambm so projeto. Um exemplo claro so as linhas cronograma de projeto pode auxiliar
obtidas a partir do processo anterior de de base (baselines) do projeto, ou ainda, muito na relao de definio das
forma a oferecer suporte para o oramen- definio de recursos produzidos em restries existentes para o projeto.
to total do projeto; antigos projetos. Tarefas em paralelo ou subsequn-
Cronograma do projeto: este docu- ciais podem dispensar mais ou menos
mento produzido durante o processo De posse desses elementos de entrada, recursos.
de gerenciamento do tempo do projeto e a tarefa de Determinar o Oramento
deve conter no mnimo as datas (incio e pode ser executada, a partir do uso das A partir da realizao dessas tarefas
trmino) planejadas para as atividades, ferramentas e tcnicas. A seguir, exem- para a Determinao do Oramento as
as metas, os recursos necessrios e o plificamos de forma simples seu uso seguintes sadas devem ser produzidas:
encadeamento natural das atividades de para o desenvolvimento de um software: Linha de base de custos: relaciona-se
acordo com as restries empregadas; Agregao de custos: os custos devem ao oramento total do projeto em funo
Calendr ios dos recursos: nele ser agregados de acordo com a estrutura do tempo e de pequenos oramentos
estaro indicadas as datas em que os hierrquica da EAP. Assim, custos totais intermedirios de entregas e marcos
recursos como materiais, pessoas ou de um pacote presente no nvel final da particulares.
equipamentos estaro sendo usados EAP so agregados aos custos de outros Requisitos de recursos financeiros do
por outros projetos ou ainda liberados pacotes no mesmo nvel para formarem projeto: produzidos para que os recur-
para o uso. Nesse processo a obteno o custo total do elemento presente no sos necessrios para o projeto possam
desse calendrio uma condio pri- EAP no nvel superior a eles, consecuti- ser adquiridos ao longo do desenvolvi-
mordial para as estimativas. Alm do vamente at que o custo total do projeto mento do mesmo, sem perda de poder de
que essa informao importante, para possa ser calculado; execuo, antecipando os mesmos para
identificar a possibilidade de trabalho Anlise de reservas: um esquema de sua aplicao no tempo devido.
de determinado membro da equipe em identificao de percentual para reser- Atualizao de documentos do pro-
seu projeto; como para que o projeto es- va de custos, com o intuito de suprir jeto: so produzidos de acordo com
teja preparado para riscos de eventuais
atrasos quando se tratar de um recurso
advindo de outra regio, 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 so eficientes para que
fiquem claros quais so os riscos de uma
seleo ou de uma disponibilizao de Figura 3. Entradas, ferramentas e tcnicas e sadas para a Determinao do Oramento

Edio 69 - Engenharia de Software Magazine 15


as modificaes realizadas a partir da do usurio no projeto, recursos humanos durante a realizao do mesmo, pode
determinao do projeto. elas podem disponveis, stakeholders, dentre outros prever melhorias no prprio oramento
ser de melhoria ou adequaes e podem so elementos que podem ser definidos definido previamente, realizando, assim,
gerar modificaes em diversos docu- nesse processo e documentados com tambm as revises de performance;
mentos, dependendo de sua origem. maior preciso em suas respectivas reas Software de gerenciamento de pro-
Exemplo: uma definio ou mudana de processo; jetos: existem diversas ferramentas de
no oramento do projeto, pode gerar Requisitos de recursos financeiros auxlio definio, monitoramento e
mudanas de cronograma de atividades do projeto: produzidos no processo an- controle de recursos para as atividades
do projeto, mudanas no planejamento terior para que os recursos necessrios de projetos. Ferramentas de controle de
dos riscos do projeto, ou ainda, definio para o projeto possam ser adquiridos ao custos normalmente disponibilizam
para aquisio ao invs de produo no longo do desenvolvimento do mesmo, toda a estrutura para controle dos recur-
projeto, dentre outros. sem perda de poder de execuo, ante- sos e tempo das atividades em questo,
cipando os mesmos para sua aplicao como citado anteriormente;
Controlar os custos no tempo devido; Anlise de reserva: um esquema
O Controle de custos do projeto deve Dados de performance do trabalho: de identificao de percentual para
ser realizado durante todo o projeto. a forma de medir o andamento das reserva de trabalho, com o intuito de
Assim, possveis distores encontradas atividades verificando, por exemplo, suprir incertezas do cronograma pode
durante a execuo do projeto podem o cumprimento de tarefas e os custos ser utilizado. Nessa tcnica, conforme
ser minimizadas em fases posteriores e necessrios para execut-las; os dados passam a ser mais reais, as re-
antes do trmino para que possam ser Ativos de processo organizacional: servas podem tambm ser melhoradas,
recuperadas. so elementos conseguidos a partir da reduzidas ou at eliminadas.
A Figura 4, retirada do Guia PMBOK, realizao de outros projetos na empre-
ilustra o conjunto de entradas, de ferra- sa, que possam vir a direcionar melhor A partir da execuo das tarefas neces-
mentas e tcnicas e de sadas que esto o gerenciamento de custos do projeto. srias para o Controle dos Custos as se-
presentes nesse ltimo processo de Um exemplo claro so definies ante- guintes sadas devem ser produzidas:
Controlar os Custos. riores de recursos necessrios X reas de Informao da performance do traba-
A seguir, apresenta-se as entradas trabalho, ou ainda, recursos financeiros lho: sero geradas a partir das anlises
pertencentes a esse processo, com um X recursos humanos em outros projetos feitas durante todo o processo de geren-
exemplo de como elas podem ser conse- da rea. ciamento e devem ser mapeadas nos seus
guidas em projetos de desenvolvimento respectivos documentos de projeto;
de software: De posse desses elementos de entrada, Previses de custo: os oramentos rea-
Plano de gerenciamento de projeto: a tarefa de Controle dos Custos pode ser lizados devem ento serem comunicados
um documento que contm as diretrizes executada, a partir do uso das ferramen- s partes necessrias para que possam
iniciais para o projeto, levando em consi- tas e tcnicas a seguir, exemplificamos ser utilizados;
derao todas as reas de gerenciamento. de forma simples seu uso para o desen- Solicitaes de mudanas: com base
Ele serve como entrada, pois, contm volvimento de um software: na performance, na definio de ora-
as principais definies feitas a partir Gerenciamento do valor agregado: mento e ainda em mudanas de escopo
das necessidades tambm iniciais apre- deve ser usado, utilizando-se custos, e tempo, possveis solicitaes de mu-
sentadas pelo cliente/usurio no ato de tempo e atividades, para clculo de danas podem vir a ocorrer de forma a
contratao do projeto. Elementos como performance do projeto; integrar novamente o projeto em suas
as formas adotadas para o trabalho, Previses, ndice de performance reas de gerenciamento;
paradigmas de desenvolvimento, possi- para concluso: baseado nos ndices de Atualizao do plano de gerencia-
bilidades de infraestrutura, participao desempenho de projeto a equipe, ainda mento do projeto: o plano de gerencia-
mento do projeto deve ser atualizado
para conter as definies necessrias que
estabelecidas a partir do gerenciamento
dos custos que foi realizado;
Atualizao do documento de pro-
jeto: o documento de projeto deve ser
atualizado para conter as definies
necessrias e que foram estabelecidas a
partir do gerenciamento dos custos que
foi realizado;
Atualizao dos ativos de proces-
Figura 4. Entradas, ferramentas e tcnicas e sadas para o Controle dos Custos sos organizacionais: atualizaes nos

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


planejamento

documentos que contm dados, conseguidos a partir da Os processos estabelecidos devem tambm se relacionar
realizao de outros projetos na empresa, devem ser atuali- com outras reas de gerenciamento de projetos descritas no
zados com os dados do projeto atual para possveis futuras PMBOK. Ora oferecendo entradas para outros processos, ora
experincias. recebendo como entrada elementos produzidos por eles e que
sero necessrios para o desenvolvimento do Gerenciamento
Sabemos que o gerenciamento deve ser iniciado com um pla- dos Custos.
nejamento para o mesmo tendo como base diversos elementos
do projeto, tais como, as atividades definidas no gerenciamento Links:
do escopo e o cronograma do projeto. Essas trs grandes reas
do gerenciamento (trazidas pelo PMBOK) tempo, escopo e PMI no Brasil a Maior Associao Mundial para Profissionais de Gerencia-
custos esto intrinsecamente relacionadas, criando-se uma mento de Projetos
dependncia mtua entre as mesmas. http://brasil.pmi.org/
Os conhecimentos apresentados no fornecem um padro, Pgina do projeto OpenProject
eles se traduzem por um Guia, que pode ser modificado, http://sourceforge.net/projects/openproj/
melhorado ou seguido em sua completude de acordo com o
projeto a ser gerenciado.
Ressalta-se aqui que esses processos possuem uma lgica Voc gostou deste artigo?
sequencial didtica, porm, sua execuo pode ter atividades
sobrepostas em muitos casos, durante o Gerenciamento dos D seu voto em www.devmedia.com.br/esmag/feedback
Custos, como por exemplo, as atividades de estimar os custos
Ajude-nos a manter a qualidade da revista!
e definir o oramento.

Edio 69 - Engenharia de Software Magazine 17


Planejamento e Gerncia
Nesta seo voc encontra artigos voltados para o planejamento
e gerncia de seus projetos de software.

Riscos em projetos de software com PMBOK

Fique por dentro: O objetivo principal do artigo apresentar fato-


A gerncia de projetos amplamente estudada e res de risco que impactam o desenvolvimento de
possui diversas ferramentas que auxiliam na efici- software, classific-los em grupos e proporcio-
ncia e eficcia da produo de software. Uma de nar uma viso dos relacionamentos entre eles e
suas atribuies o gerenciamento de riscos, pois como essas informaes auxiliam na tomada de
existem inmeros riscos que envolvem o desen- decises. O tema til para auxiliar no geren-
Jhoney Lopes volvimento de software Riscos so situaes de ciamento de projetos de software, como mtodo
jhoney.lopes@gmail.com incertezas que envolvem escolhas relacionadas de controle dos possveis riscos que impactam
Bacharel e mestrando em Cincia da Com- com decises que esto ligadas diretamente aos o desenvolvimento do projeto. O uso desse co-
putao pela Universidade Federal de Viosa. nhecimento indispensvel para evitar perdas
riscos. Uma vez conhecidos os riscos, as decises
Atua na rea de Cincia da Computao, com
podem reduzir perdas, aumentar ganhos ou, o financeiras, atrasos, erros, retrabalhos e perdas
nfase em Engenharia de Software. Desenvol-
vedor iOS, Embaixador certificado em Negcios contrrio, levando a prejuzos. de outros recursos.
Sociais no Brasil e co-criador do Catlise Social
(www.catalisesocial.com). reas de interesse:
Engenharia de Software, Empreendedorismo,
Gerenciamento de Projetos e Risco.

R
isco falta de informao, a tempo gasta-se de casa at o destino
incerteza a base do risco, por final, e outros.
Jos Luis Braga
zeluis@dpi.ufv.br essa razo ele est no futuro. Risco no associado com certeza,
Ps-doutoramento em Tecnologias da Infor- O passado conhecido, logo poss- sendo assim, quando uma ao de ris-
mao na University of Florida (1988-1999). vel saber quais incertezas afetaram co, no se pode definir a mesma sendo
Doutor em Informtica-Departamento de In- positivamente ou negativamente. Por ruim ou boa. Existem diversos esportes
formtica da PUC-Rio (1990). Mestre em Cin-
mais que cada pessoa seja nica e viva de alto risco como, por exemplo, o pa-
cias da Computao-Departamento de Cincia
da Computao da UFMG (1980). Atualmente experincias individuais, o cotidiano raquedismo. Durante um salto, o para-
Professor Titular do Departamento de Infor- cercado de influncias comuns, que for- quedas pode desdobrar no ar da melhor
mtica do Centro de Cincias Exatas e Tecno- necem informaes que so mapeadas e maneira possvel, mas em outros casos
lgicas da Universidade Federal de Viosa-MG. utilizadas por todos como, por exemplo, isso pode no acontecer. As pessoas no
Atua na rea de Cincia da Computao, com
o melhor caminho para ir ao trabalho, deixaram de praticar o esporte por causa
nfase em Engenharia de Software e Sistemas
de Informao. o melhor tipo de investimento, quanto desse perigo, elas mapearam as formas

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


planejamento

indesejadas da abertura do paraquedas e desenvolveram tc- Anlise qualitativa dos riscos: processo de priorizao dos
nicas para lidar com cada uma delas. riscos para anlise ou ao adicional atravs da avaliao e
Criar solues para lidar com as incertezas no se restringe combinao de sua probabilidade de ocorrncia e impacto;
ao esporte. Inovar assumir riscos e necessrio arriscar Anlise quantitativa dos riscos: o processo de analisar
para quebrar o status quo. Sejam inovaes disruptivas numericamente o efeito dos riscos identificados nos objetivos
(ver BOX 1), em processos, em modelos ou outros, a inteno gerais do projeto;
aproveitar uma oportunidade para melhorar algo. Essa Planejamento de respostas aos riscos: processo de desen-
busca pela melhoria constante obriga a esbarrar continua- volvimento de opes e aes para aumentar oportunidades
mente com o desconhecido. Todo caminho novo tem incer- e reduzir ameaas aos objetivos do projeto;
tezas associadas, mas muitas vezes possui caractersticas Monitoramento e controle de riscos: processo de imple-
que interceptam com outros j conhecidos. Gerenciar riscos mentao de planos de respostas aos riscos, acompanhamento
utilizar de conhecimentos prvios para minimizar efeitos dos riscos identificados, monitoramento dos riscos residuais,
indesejados. Este artigo fornece um conjunto de informaes identificao de novos riscos, e avaliao da eficcia do pro-
para auxiliar o gerente de projetos a enxergar os pontos po- cesso de risco durante todo o projeto.
sitivos e negativos das decises em projetos de software.
Na figura so apresentadas as entradas, ferramentas tcnicas
BOX 1. Inovaes disruptivas e sadas dos principais processos de gerenciamento de risco.
Para obter sucesso, uma organizao deve estar compromis-
Disruptivo algo que quebra conceitos, ruptura ou rompimento de algo. Uma inovao
sada em realizar gerenciamento de risco de forma proativa e
disruptiva um produto, servio ou tecnologia que rompe ideias preestabelecidas, ou seja, algo
consciente. Uma escolha consciente deve ser feita em todos
que extrapola o at ento conhecido.
os nveis da organizao para identificar e seguir um efetivo
gerenciamento de risco durante todo o ciclo de vida de um
O risco pode ser visto de vrias formas. Primeiro, risco gira projeto. O gerente de projetos pode utilizar a Figura 1 para
em torno dos acontecimentos futuros. A questo : pode-se organizar um plano de ao de gerenciamento de risco.
mudar aes hoje, a fim de criar oportunidades para uma A gesto de riscos tornou-se uma preocupao global, os
melhor situao amanh? Segundo, risco envolve mudanas, efeitos indesejados dos riscos se transformaram em uma
tais como mudana de mentalidade, opinio, aes, ou lugares. apreenso. Por esse motivo, em 2009, saiu a norma ISO 31000
Em um mundo esttico, no existe risco, logo, esse o terceiro e no Brasil foi lanada em 30/11/2009 a ABNT NBR ISO 31000
aspecto do risco. Risco envolve escolhas, e todas as incertezas - Gesto de Riscos, Princpios e Diretrizes. A norma ISO 31000
que essas escolhas trazem. tem reconhecimento internacional, no tem finalidade de
O gerenciamento dos riscos em reas como administrao, certificao, mas uma ferramenta de auxlio s empresas,
economia, estatstica e matemtica financeira, alm de ser muito trazendo uma forte vantagem competitiva.
empregado tratado como elemento chave para tomada de de- Observa-se que os projetos de desenvolvimento de software, em
ciso. O risco envolvido em projetos uma condio ou evento geral, apresentam atrasos de cronogramas, custos realizados alm
incerto que, se ocorrer, ter um efeito positivo ou negativo. Esses do planejado e funcionalidades aqum das expectativas. Esses
efeitos podem ser no prazo, custo, esforo e qualidade. Um risco problemas, embora considerados inerentes ao desenvolvimento
pode ter diversas causas e, se ele acontecer, pode ter diversos im- de software por muitos autores, podem ser minimizados e con-
pactos. Uma causa uma condio que favorece o acontecimento trolados pelo contnuo gerenciamento de risco em projetos.
de resultados positivos ou negativos. Por exemplo, a causa pode O tempo de reao aos riscos um fator preponderante para a
ser uma mudana no escopo, a falta de conhecimento ou pessoas economia, como pode ser visto na Figura 2. A reao imediata,
insuficientes para executar um projeto, entre outros. feita no momento da identificao e da anlise dos riscos, na
O processo de manipulao dos riscos realizado com a anlise fase inicial, chamada de reao de preveno, e acontece
e gerenciamento. Na anlise esto as etapas de identificao, esti- antes da deciso final sobre o projeto, alterando as principais
mativa e avaliao, j o gerenciamento entendido como controle variveis de impacto no projeto, como escopo, qualidade,
do planejamento e o monitoramento do sucesso dos mecanismos tempo ou condies financeiras. O quanto antes ocorrerem
de controle. Esse processo tem como objetivo bsico observar o a identificao, preveno e contingncia relacionadas aos
que pode dar errado e auxiliar nas tomadas decises. riscos, menores sero os custos de impacto ao projeto. Em
A Figura 1 apresenta a viso geral do gerenciamento de riscos contraposio, a estimativa de custo do projeto possui maior
apresentado no PMBOK e possui os seguintes itens: nvel de acerto com o passar do tempo.
Planejamento do gerenciamento de risco: o processo de A Figura 3 conhecida como Cone de incerteza, sua leitura
definio de como conduzir as atividades do gerenciamento mostra que, no incio do projeto, a estimativa possui maior
de risco; taxa de erro. Estimativas realizadas na fase conceitual po-
Identificao dos riscos: processo de determinao de dem ter um erro de quatro vezes, ou um-quarto do valor
quais riscos podem afetar o projeto e documentao de suas estimado; o erro se reduz com o aumento do conhecimento
caractersticas; sobre o projeto.

Edio 69 - Engenharia de Software Magazine 19


Figura 1. Viso geral do gerenciamento de riscos do projeto

Figura 2. Momento da reao diante dos riscos

A figura apresenta de modo simples um direcionamento


do melhor momento para a determinao do custo real do Figura 3. Cone de incerteza, melhoria da estimativa de custo ao longo do
tempo
projeto, embora seja compreensvel que o erro decresce com
o tempo, esse grfico no leva em considerao a necessidade
do cliente em saber o mais rpido possvel o valor do projeto. Riscos podem ser considerados positivos ou negativos.
Essa distncia entre a assertividade e os interesses do mer- Alguns so oportunidades gerenciais, assim, encontrar essas
cado, que fazem surgir diversos riscos, e tambm indicam oportunidades e maximizar seus efeitos gera uma vanta-
momentos em que decises precisam ser tomadas. 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 sada 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 fcil de ser alinhada, de larga escala em desenvolvimento so cancelados. Em mdia,
gerenciada e treinada; nessa situao cabe o gerenciamento projetos ultrapassam o prazo de desenvolvimento em mais
otimista para manter a equipe motivada e coibir sadas de da metade do tempo planejado, projetos maiores geralmente
colaboradores. so piores. Apenas 25% dos projetos de larga escala no so
considerados falhas operacionais, os outros 75%, ou no
Autores funcionam como previsto ou no so usados na ntegra.
Fatores de Risco a B c d
1. Mudana 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 usurios X X X
desenvolvimento de software. Na Tabela 1 so listados trinta
3. Requisitos mal entendidos e/ou mal definidos X X X
e trs fatores de risco, organizados por ordem de relevncia.
4. Escopo/objetivos pouco claros ou equivocados X X X Essa lista um trabalho exploratrio 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 imprprio de mudanas X X X Finlndia e Estados Unidos da Amrica.
7. Volatilidade nos requisitos (falta de requisitos estticos) X X X
Grupos de fatores de risco
8. Custos mal estimados X X X
A partir dos riscos listados na Tabela 1, possvel observar
9. Falta de poderes para o gerenciamento de projetos X que alguns possuem impactos semelhantes nos projetos de
10. Conflito entre departamentos de usurio X X software como, por exemplo, mudana de escopo/objetivos;
11. Falha em gerenciar as expectativas finais dos usurios 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 estticos). Na Tabela 2 apresentada uma
13. Pessoal envolvido insuficiente/inapropriado X X X X
comparao entre diferentes grupos de fatores de risco.
14. Falta de conhecimento/competncia dos envolvidos
X X X X
no projeto
Grupo 1 Grupo 2 Grupo 3
15. Falta de Cooperao dos usurios X X X
Novidade Tecnolgica Tecnologia Conhecimento e incerteza tecnolgica
16. Falta de metodologia efetiva em gerenciamento de
X X
projetos Complexidade da Aplicao Requisitos
Escopo e Requisitos
17. Controle pobre ou inexistente X X Tamanho da Aplicao Escopo
18. Adoo de novo mtodo/tecnologia X X X Habilidades da Equipe
Equipe de desenvolvimento
Expertise Pessoas
19. Falha em obter comprometimento do cliente X X
Gesto de Projetos
20. Definio imprpria de papis e responsabilidades X X - Financiamento
21. Falta de comprometimento da alta gerncia X X X Processo de
-
22. Falta de motivao da equipe X desenvolvimento Gesto de projetos
- Planejamento
23. Falta de habilidade para o gerenciamento de projetos X X
Programao/
24. Assunto novo ou no familiar X X X -
Agendamento
25. Mudana no proprietrio do projeto ou na alta - Patrocnio/Propriedade
X Relacionamento com cliente e usurio
gerncia - Gesto de Relacionamentos
26. Rotatividade da equipe X Valor/importncia atribudo ao
Ambiente Organizacional Ambiente Corporativo
27. Projeto com mltiplos fornecedores X projeto
28. Usar nova metodologia de desenvolvimento em Relacionamento com o ambiente
X - Dependncias externas
projetos importantes externo

29. O sistema possui integrao 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. Deficincia de execuo 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 so:

Edio 69 - Engenharia de Software Magazine 21


Gesto de Dependncias: relaciona-se com os riscos que Gesto de Inovao e Tecnologias: o grupo destinado
envolvem qualquer tipo de dependncia, seja direta ou in- a lidar com as escolhas tomadas acerca das tecnologias e
direta com o software ou o projeto. As dependncias podem inovaes;
ser com relao a tecnologia, pessoas, fornecedor, outros Gesto de Pessoas: so todos os fatores que envolverem
sistemas, etc.; pessoas no que tange conhecimentos, habilidades, capaci-
Gesto de Escopos e Requisitos: todos os riscos que en- dades, motivao etc.;
volvem os escopos e os requisitos do projeto sero tratados Gesto de Projetos: atributos comuns do gerenciamento
nesse grupo; como prazo, custo, esforo e outros, so inseridos nesse
grupo;
1. Gesto de Dependncias Gesto de Relacionamentos: aqui envolvem todos os
1.1. Gerenciamento imprprio de mudanas. riscos atribudos ao relacionamento entre os envolvidos no
1.2. Falha em gerenciar as expectativas finais dos usurios. projeto, sejam pessoas internas ou externas.
1.3. O sistema possui integrao e interface com outros sistemas.
1.4. Mudana no proprietrio do projeto ou na alta gerncia. Fatores de risco no desenvolvimento de software
1.5. Projeto com mltiplos fornecedores. Nas sees anteriores foram realizados o mapeamento
1.6. Sistemas complexos. e anlise dos fatores de risco de maior impacto no desen-
volvimento de software. Em seguida, esses fatores foram
2. Gesto de Escopo e Requisito agrupados por contexto.
2.1. Mudana de Escopo/objetivos. Os trinta e trs fatores de risco foram distribudos nos
2.2. Requisitos mal entendidos e/ou mal definidos. grupos anteriormente definidos. Para a avaliao dos riscos,
2.3. Volatilidade nos requisitos (falta de requisitos estticos). segment-los em grupos facilita a compreenso do contexto,
2.4. Escopo/objetivos pouco claros ou equivocados. ter os riscos distribudos em blocos de mesmo assunto foi
importante para a realizao do trabalho. No prximo tpico
3. Gesto de Inovao e Tecnologias ser abordada a criao de modelos e utilizao desses para
3.1. Adoo de novo mtodo/tecnologia. a realizao de simulaes. A Tabela 3 apresenta os grupos
3.2. Assunto novo ou no familiar. e seus respectivos riscos associados.
3.3. Usar nova metodologia de desenvolvimento em projetos importantes. Os riscos presentes em cada grupo esto organizados
3.4. Falta de tecnologias maduras/existentes. pela ordem de impacto. O primeiro item de cada grupo o
3.5. Deficincia de execuo em tempo real. risco mais impactante daquele contexto e assim sucessiva-
mente. A Tabela 3 apresenta os grupos sugeridos com os
4. Gesto de Pessoas respectivos riscos. Como dito anteriormente, esses grupos
4.1. Pessoal envolvido insuficiente/inapropriado. representam contextos e esses contextos foram utilizados
4.2. Falta de conhecimento/competncia dos envolvidos no projeto. para simular a dinmica entre os riscos.
4.3. Falta de habilidade para o gerenciamento de projetos.
4.4. Falta de motivao da equipe. Dinmica entre riscos
4.5. Rotatividade da equipe. O mundo composto por variveis e essas esto presentes
em todos os ciclos dos processos dos homens e da natureza.
5. Gesto de Projetos O pensamento sistmico um conjunto de conhecimentos
5.1. Prazos e tempo para tarefas mal estimados. e ferramentas desenvolvido nos ltimos cinquenta anos
5.2. Custos mal estimados. que visa nos auxiliar a reconhecer padres e fornecer me-
5.3. Planejamento inexistente ou inadequado. canismos para modific-los efetivamente. Ele e livre, no
5.4. Falta de metodologia efetiva em gerenciamento de projetos. possui uma tecnologia associada obrigatria e tem como
5.5. Controle pobre ou inexistente. objetivo enxergar o todo, observar padres, estruturas,
5.6. Definio imprpria de papis e responsabilidades. conexes e realizar uma reestruturao das inter-relaes
5.7. Tarefas complexas. de forma mais harmoniosa. possvel conectar variveis
e analisar suas interferncias atravs de um diagrama de
6. Gesto de Relacionamentos causalidade.
6.1. Falta de envolvimento adequado dos usurios. Os diagramas de causalidade, tambm conhecidos como
6.2. Falta de comprometimento da alta gerncia. diagramas de influncia, constituem a ferramenta princi-
6.3. Falta de Cooperao dos usurios. pal do pensamento sistmico. De acordo com esta viso, o
6.4. Conflito entre departamentos de usurio. mundo opera em circuitos de retroalimentao de reforo
6.5. Falha em obter comprometimento do cliente. e balanceamento. O movimento desses ciclos em conjunto e
6.6. Falta de poderes para o gerenciamento de projetos. considerado o comportamento geral do fenmeno ou evento
sendo investigado. Na Figura 4 pode ser visto um exemplo
Tabela 3. Grupos propostos dos fatores de risco avaliados e selecionados
da literatura de diagrama de causalidade.

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


planejamento

Saindo dos detalhes da ferramenta e observando as relaes


entre os itens do diagrama, pode-se produzir vrias infe-
rncias. Primeiramente, para facilitar o entendimento, cada
varivel considerada ser explicada:
Capacidade produtiva: a capacidade de produzir o proje-
to, no caso, pode ser entendido como sendo a quantidade de
pontos de funo que so 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
Figura 4. Esta figura um exemplo de diagrama de causalidade dos erros.

Os smbolos + e -, simbolizam que, quando se altera deter- Pode ser iniciada uma leitura do diagrama a partir de qual-
minada varivel, essa causa um impacto na varivel adjacente quer item, por exemplo tomando como ponto inicial a capacidade
(ligada a ela) no mesmo sentido (sinal de mais) ou em sentido produtiva, quanto mais cdigo produzido, tem-se mais software
oposto (sinal de menos). Na modelagem anterior, quando se desenvolvido, e maior a quantidade de erro gerado, em conse-
aumenta soluo sintomtica, seta com +, aumenta-se o efeito quncia cresce tambm a quantidade de retrabalho que a equipe
de consequncias no-intencionais e diminui-se, seta com ter que realizar e, com isso, menos software desenvolvido, uma vez
-, sintoma do problema. As consequncias no-intencionais que retrabalho refazer algo que a princpio j estava pronto. A
quando crescem, aumentam os efeitos de sintoma do problema. quantidade de software produzido afetada tanto pela capacidade
O arco cortado por duas linhas paralelas tem o significado de produtiva quanto pelo retrabalho, e por sua vez, ele impacta o tempo
que o efeito produzido no imediato, ou seja, demanda um de entrega, que significa o tempo necessrio para entregar o proje-
tempo at ocorrer, possui um delay. As letras R e E sig- to, ou seja, se existe muito software pronto, precisa-se de menos
nificam, respectivamente, que o caminho fechado tende a um tempo para entreg-lo, de outro modo, se o desenvolvimento no
reforo ou equilbrio, ou seja, sintoma do problema estimula foi satisfatrio o prazo de entrega cresce. O tempo de entrega afeta
soluo sintomtica e soluo sintomtica desestimula sintoma diretamente a capacidade produtiva, quanto mais tempo gasto
do problema, com isso tem-se um equilbrio entre eles. desenvolvendo algo, cresce tambm o conhecimento da equipe,
A Figura 5 apresenta um exemplo de diagrama de causalida- tanto na tecnologia utilizada para desenvolver o projeto, quanto
de utilizando as variveis de risco citadas neste artigo. no projeto em si, com isso, a produo aumenta.
Uma nota importante: por mais que a produo aumente com
o passar do tempo, esse fator no infere em um crescimento
constante, a tendncia um aumento produtivo nos primeiros
meses e posteriormente uma estabilidade, sendo assim, tem-se
um estado de equilbrio com o tempo. Esse equilbrio pode
ser quebrado aumentando a equipe, melhorando os treina-
mentos, tcnicas motivacionais e outros. Esses fatores podem
ser testados a partir de simulaes, diagramas de causalidade
so convertidos em diagramas matemticos que suportam
simulaes de cenrios.
A simulao a avaliao numrica de um modelo mate-
mtico que descreve um sistema. Muitos sistemas so muito
complexos para solues analticas fechadas, ou seja, planilhas,
fluxogramas, entre outros. Portanto, a simulao usada
para exercitar modelos com entradas dadas para ver como o
sistema executa.
Existem diversas tcnicas para realizar simulaes com vari-
veis dinmicas. Uma dessas conhecida como Dinmica de
Sistemas DS. Com a DS possvel analisar o comportamento
dinmico dos riscos. Utilizando os contextos dos grupos de
Figura 5. Esta figura um exemplo de diagrama de causalidade no
riscos listados neste artigo, foram realizadas anlises com
desenvolvimento de software base em simulaes.

Edio 69 - Engenharia de Software Magazine 23


Para validar e produzir valores iniciais para as simulaes, atribudos aos trs 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 inteno dessa
nal de Padres de Benchmarking em Software (International abordagem apresentar o impacto da variao dos fatores de
Software Benchmarking Standards Group - ISBSG). Na Tabela 4 risco na mudana do tamanho do projeto, e o que ocorreria,
podem ser vistas algumas das informaes. se os projetos tivessem atributos de risco iguais.
O primeiro retngulo da esquerda para a direita representa
Variveis Mdia Mnimo Mximo um projeto pequeno, o segundo um projeto mdio e o terceiro
Pontos de Funo PF 521,04 PF 11 9803 um projeto grande. No caso 1, os prazos de desenvolvimento
Esforo 5217,7 homem-horas 17,0 150.040,0 respectivamente foram: trs, cinco e quatorze meses; no caso 2:
trs, dois e quatro. Essa sequncia mantida para os dois
Tamanho da Equipe 8 pessoas 1 77
exemplos: Caso 1 e Caso 2.
Tabela 4. Pontos de Funo PF (ver BOX 2)

BOX 2. Anlise de Pontos de Funo

Anlise de Pontos de Funo APF, uma tcnica que visa medir o tamanho funcional de um
software, para, a partir desses dados, oferecer mecanismos para estimar esforo, prazo e custo.
Na edio de nmero 44 da Engenharia de Software Magazine possvel ter uma viso geral
acerca dessa tcnica. Na tabela o esforo 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 nmero de pessoas envolvidas na realizao do projeto.

Alm desses dados, foram obtidos com uma microempresa


de software que utiliza a mtrica em pontos de funo, os da-
dos de um projeto da empresa. Para um projeto de duzentos
e setenta pontos de funo realizado por uma equipe de trs Figura 6. Impacto da variao dos fatores de risco
pessoas, foi fornecida a informao de que a empresa gasta o
prazo de trs meses para o desenvolvimento. Com as informaes apresentadas, pode ser observado que se
Com esses nmeros em mos, foi possvel 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 informaes valiosas,
Tamanho Aproximado dos Projetos que sero tratadas a seguir.
270 PF 520 PF 9800 PF Algumas das variveis 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 Mdio Baixo tagem de retrabalho. As demais variveis foram ajustadas com
Porcentagem de erros encontrados 30% 50% 63% as simulaes e utilizaram os seguintes parmetros para
Porcentagem de erros eliminados com teste 20% 20% 20% ajustes, a quantidade de pessoas necessrias (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. Variao 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 esforo (seguindo a conhecida relao regra de Pareto),
A seguir, uma discusso sobre os dados apresentados na tabe- aproximadamente 80% dos erros esto em 20% dos mdulos
la apresentada. Alguns dos valores representados na Tabela 5 do projeto. Para lidar com os valores mdios de retrabalho,
foram retirados da literatura, outros foram obtidos atravs sem diferenciar a qualidade da equipe que executa o projeto,
de ajustes. Os ajustes realizados demonstram a existncia do definiu-se um valor padro para a capacidade de correes 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 no foram capturados, foi observado que a quantidade de
realizadas simulaes 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 caractersticas to. Caso no houvesse o aumento do nmero de erros com a
diferentes como, por exemplo, a porcentagem de erros encontrados, elevao 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


planejamento

dados estimados. O tamanho da equipe no projeto pequeno


se manteve e com isso o prazo tambm ficou igual, no projeto
de tamanho mdio houve uma reduo de duas pessoas e um
aumento de um ms no prazo de desenvolvimento e no projeto
de larga escala, houve um aumento de trinta e uma pessoas na
equipe e uma reduo 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
Figura 7. Queda no prazo de desenvolvimento com a reduo da Tabela 6. Dados reais X Dados estimados
porcentagem de retrabalho
O valor estimado so de noventa pontos funo por pes-
A figura apresenta o impacto do retrabalho em um projeto. soa. Esse valor foi estimado a partir da mdia entre a menor
De acordo com a literatura, em torno de 40% a 50% do esforo produtividade por pessoa, quinhentos e vinte dividido por
no desenvolvimento de software e gasto em retrabalho. Esses oito (sessenta e cinco) e a maior produtividade, nove mil e
dados mostram como o retrabalho est altamente ligado ao oitocentos dividido por setenta e sete (cento e vinte e sete).
desenvolvimento de software, por mais que a reduo do re- O valor obtido foi de noventa e seis, o qual foi ajustado para
trabalho a zero no seja uma realidade, a Figura 7 expe como noventa pontos funo utilizando as simulaes. A frmula a
a reduo desse fator pode diminuir o prazo de desenvolvi- seguir foi gerada a partir das simulaes realizadas para este
mento e fortalece a relevncia da realizao de testes e uma trabalho e apresenta um clculo simples que o gerente pode
tima anlise de requisitos, para capturar e impedir erros no fazer para estimar a equipe:
software. Outras duas variveis muito importantes estimadas
com as simulaes foram: conhecimento inicial sobre a linguagem tamanho equipe = tamanho projeto (PF) / 90 (PF)
e o projeto; porcentagem de apoio do cliente.
Quanto maior a equipe de trabalho, ter um conhecimento Essa frmula pode ser usada para estimar o tamanho da equi-
inicial intensifica a produtividade (conhecimento inicial sobre pe quando o gerente no possui um histrico de desenvolvi-
a linguagem e o projeto); com as simulaes foi observado que, mento, no caso de haver histrico, o ideal seguir a capacidade
com um conhecimento mdio acerca de um projeto amplo, produtiva da equipe. O erro da frmula cresce com o aumento
pode-se reduzir em at 25% o prazo de desenvolvimento, de tamanho do projeto, como pode ser observado na Tabela 6.
mas juntamente com o tamanho do projeto, cresce tambm a Cada equipe e projeto possuem caractersticas intrnsecas, mas
dificuldade em possuir um conhecimento inicial. Embora essa esses atributos no diminuem a utilizao de frmulas para
dificuldade exista, ela no exclui a possibilidade de utilizar um estimar dados que auxiliam nas tomadas de decises. Cabe ao
conhecimento inicial maior, para aumentar a produtividade. gerente de projetos avaliar e criar mecanismos para lidar com
O suporte do cliente (porcentagem de apoio do cliente) no esses resultados obtidos.
aumenta a produtividade, mas reduz possveis atrasos, uma
vez que cabe ao cliente aprovar as etapas do desenvolvimento. Processo de qualidade e risco calculado
Se em alguma etapa o cliente atrasar para confirmar algum necessrio medir o preo que se paga por no realizar ge-
requisito, o projeto afetado. Durante a pesquisa foi captura- renciamento de riscos. Na maioria dos casos esses preos vo
do o risco da falta de apoio do cliente, o qual impactava apenas alm de fatores financeiros, esto tambm relacionados com
quando no havia o suporte dos clientes. Nos projetos maiores orgulho, prestgio, reputao, relacionamentos e outros.
foi necessrio diminuir a porcentagem do apoio do cliente nas Durante a pesquisa, foi observado que normalmente os
simulaes. Uma concluso importante, no que os clientes gerentes de projetos visualizam a necessidade do gerencia-
ficam menos solcitos em grandes projetos, mas que o nmero mento de riscos somente em projetos de larga escala, riscos
de processos que devero ser aprovados aumenta, e com isso so vistos como algo extra e no como uma tarefa prioritria
aumenta o risco de o cliente falhar com o suporte necessrio. em projetos menores.
Aps o modelo ter sido ajustado, foi possvel estimar um A Melhoria de Processo do Software Brasileiro - MPS.BR
tamanho mdio de equipe por tamanho de projeto de softwa- fornece um conhecimento acerca do gerenciamento de riscos,
re em ponto funo. Com essa informao possibilitado ao e essa gesto pode ser realizada por empresas pequenas e em
gerente saber quantas pessoas ele necessita para realizar um crescimento. O MPS.BR possui um nvel de maturidade (i.e.,
projeto. Os valores estimados foram colocados em comparao nvel C) que exige lidar completamente com o gerenciamento
com dados reais na Tabela 6. Sendo (a) os dados reais e (b) os de riscos, mas j no nvel G, nvel inicial do programa de

Edio 69 - Engenharia de Software Magazine 25


qualidade, requerido a utilizao de mecanismos simples variao no tamanho da equipe em 50%, a Figura 8 apresenta
para lidar com os riscos. os resultados obtidos no prazo de desenvolvimento.
O nvel parcialmente gerenciado (i.e., nvel G) do guia geral
MPS.BR, possui como resultados esperados os seguintes itens
relativos a identificao e gerenciamento de riscos: os riscos do
projeto so identificados e o seu impacto, probabilidade de ocorrncia e
prioridade de tratamento so determinados e documentados; os riscos
so monitorados em relao ao planejado. Esses itens articulam
aes iniciais na anlise e gerenciamento de riscos.

Apoio tomada de deciso


A tomada de deciso envolvida por problemas classifica-
dos em: estruturados, semi-estruturados e no-estruturados
(desestruturados). Estruturados so aqueles que podem ser
completamente determinados, porque possuem solues am-
plamente conhecidas. Para lidar com problemas estruturados,
possvel utilizar listas predefinidas como, por exemplo, aes Figura 8. Variao no prazo provocado a partir da alterao do tamanho
operacionais padronizadas, em que qualquer funcionrio ou de uma equipe em um projeto de quinhentos e vinte pontos funo
mquina pode tomar decises seguindo um fluxograma. Semi-
estruturados esto em uma posio intermediria, possuem A figura apresenta uma viso do prazo de desenvolvimento
intersees com problemas estruturados, mas alguns pontos do considerando equipes com capacidades produtivas idnticas.
problema no so bem conhecidos. So desafios que necessitam Para os trs casos apresentados anteriormente, o nico fator
de um nvel mdio de julgamento humano e experincia para que foi alterado nas simulaes de um caso para outro, foi o
serem solucionados. J problemas desestruturados, so mais tamanho da equipe, todos os demais dados foram mantidos,
complexos, porque ocorrem ocasionalmente, suas estruturas com isso possvel comparar o efeito de alterar o tamanho da
no so bem definidas e exigem maior julgamento e experin- equipe. Com as simulaes foi observado que reduzir a equipe
cia para solucion-los. Ou seja, no existem solues prontas em 50% gerou mais impacto do que aument-la na mesma
para esse tipo de problema; experincias acumuladas com proporo, essa diferena ser discutida juntamente com os
problemas similares, conhecimentos e ferramentas de apoio dados da Figura 9.
deciso so utilizadas para esse tipo de desafio. No cenrio anterior, as equipes possuam um conhecimento
O gerente de projetos precisa descobrir quais tipos de desa- mdio sobre a linguagem e o projeto. Na Figura 9 exposta
fios est enfrentando. Modelos, tabelas e planilhas so timas uma comparao entre os tamanhos das equipes variando
ferramentas para problemas estruturados, para os demais no tambm o nvel de conhecimento. A variao do conhecimento
possvel usar ferramentas que forneam solues diretas. foi de 60% para mais e para menos, variando-o de baixo a alto,
So necessrias tecnologias que auxiliem tomada de deci- passando por mdio.
so, como sistemas de apoio deciso, simuladores, modelos
dinmicos entre outros.
O impacto mais bvio da utilizao de ferramentas de apoio
deciso a melhoria da tomada de deciso. Informaes e
ferramentas de apoio deciso podem trazer diversos be-
nefcios: fornecer uma viso dos diversos cenrios possveis;
munir os gerentes de alternativas para lidar com os riscos do
projeto; aumentar a confiana nas tomadas de decises; por
fim e no menos importante, intensificar a velocidade com
que as decises so tomadas.
Nesta parte do artigo sero apresentados cenrios de desafios
que o gerente de projetos de software pode enfrentar. Foram
realizadas diversas simulaes e comparaes, a fim de que
esses cenrios auxiliem o gerente nas tomadas de decises.
Foi utilizado como cenrio base, o projeto de mdio porte
Figura 9. Impacto no prazo gerado pela variao do conhecimento em
(i.e., 520 PF) descrito na Tabela 5, e levou-se em considerao equipes de desenvolvimento de software. Dados gerados a partir de
todos os valores dos atributos listados na tabela para o projeto simulaes
desse porte.
Um desafio comum de um gerente de projetos o tamanho da Podemos observar que o conhecimento gera maior resultado
equipe sua disposio. Foram geradas simulaes com uma na menor equipe, a diferena entre o pior caso e o melhor

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


planejamento

nessa equipe, so de seis meses. Uma equipe menor bem


treinada consegue ter um rendimento melhor ou igual a
uma equipe de tamanho trs vezes maior com conhecimento
baixo ou mdio.
O impacto do conhecimento no linear, ou seja, ele no
decresce ou aumenta na mesma proporo nos trs casos, isto
, nas equipes de quatro, oito e doze pessoas. Quanto maior
o nmero de pessoas, a comunicao interna acaba sendo
reduzida e os conflitos aumentados. Esses so alguns dos fa-
tores que no permitem que a expresso do conhecimento dos
desenvolvedores, sejam iguais independente da quantidade
de pessoas envolvidas.
Na prxima anlise o tamanho do projeto ser o foco, foi
mantida a variao do tamanho da equipe em 50% para mais
e menos, nas simulaes o conhecimento inicial foi deixado Figura 10. Impacto da variao do tamanho do projeto no prazo de
mdio para todas as equipes. Na Figura 10 apresentado como desenvolvimento. Dados gerados a partir de simulaes
o prazo de desenvolvimento de cada equipe variou reduzindo
e aumentando o tamanho do projeto em 50%. Veja que foi levantada no pargrafo anterior a questo da
A Figura 10 gera alguns questionamentos. Avaliando o equipe de doze pessoas reduzir apenas um ms do projeto
comportamento do grfico, fica ntido o impacto do tamanho mdio 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 funo igual.
quatro e oito pessoas, a diferena entre o projeto menor com As simulaes deixam claro que aumentar o tamanho
o mdio de dois meses e, para a equipe de doze pessoas, a da equipe nem sempre uma vantagem de produo.
diferena de apenas um ms. Nas equaes utilizadas para Sendo assim, o gerente precisa tomar cuidado para no colo-
realizar as simulaes, quanto mais tempo uma equipe passa car menos pessoas que o necessrio 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 do mais tempo para a equipe melhorar e aumentar projeto de duzentos e sessenta pontos funo mostrou-se uma
o alinhamento entre seus integrantes. deciso ruim, o nmero de processos concorrentes em projetos

Edio 69 - Engenharia de Software Magazine 27


pequenos so poucos, isso faz com que em certos momentos se invivel para um projeto desse porte, principalmente por
desenvolvedores fiquem ociosos. Para fim de conhecimento, questes oramentrias.
para reduzir mais um ms no projeto de duzentos e sessenta A seguir, sero apresentadas as Figuras 11 a 13, que re-
pontos funo, foi necessrio nas simulaes colocar uma equi- presentam o impacto da variao do conhecimento em cada
pe de quinze pessoas, uma equipe desse tamanho apresenta- tamanho de projeto de software, os dados foram gerados com
simulaes, cada barra do grfico representa respectivamente
conhecimento baixo, mdio e alto.
Na discusso 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 funo.
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 no permanecem
iguais, principalmente pelo j citado argumento de que proje-
tos maiores oferecem mais tempo para os desenvolvedores se
aperfeioarem e, quanto mais desenvolvedores, mais pessoas
esto se aperfeioando.
Observando os dados apresentados, pode-se concluir que
Figura 11. Impacto gerado no prazo, a partir da variao do uma equipe pequena competente e bem treinada, em projetos
conhecimento da equipe de desenvolvimento, em projetos de duzentos e pequenos e mdios, consegue obter resultados satisfatrios
sessenta pontos funo quando comparados com uma equipe trs vezes maior e de
mesma competncia. Ter uma equipe menor e qualificada
mostrou-se, em alguns dos casos, uma deciso melhor do que
optar por uma equipe ampla.
Para finalizar esta seo, ser apresentado um grfico que
representa o ponto de equilbrio entre os grficos dos custos
aqui apresentados. O ponto de equilbrio (do ingls, break even
point) o ponto onde o cone de incerteza (Figura 3) intercepta
o momento da reao diante dos riscos (Figura 2). Conside-
rando que o comportamento dos dois grficos sejam iguais, o
ponto de equilbrio fornece o momento em que no 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 no vale a pena realizar
estimativas de custo aps o ponto de cruzamento, porque o
momento em que fica mais caro o preo que se paga por reagir
Figura 12. Impacto gerado no prazo, a partir da variao do tarde demais aos riscos. A deciso do gerente sobre os custos
conhecimento da equipe de desenvolvimento, em projetos de
quinhentos e vinte pontos funo do projeto deve ocorrer entre o fim da fase inicial e o incio da
fase intermediria do desenvolvimento.

Figura 14. Momento do ponto de equilbrio entre o cone de incerteza e


momento de reao diante dos riscos

As informaes apresentadas nessa seo foram organizadas para


Figura 13. Impacto gerado no prazo, a partir da variao do
prover aos gerentes de softwares, conhecimentos que possam lhes
conhecimento da equipe de desenvolvimento, em projetos de setecentos
e oitenta pontos funo auxiliar nas tomadas de decises de projetos de softwares.

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


planejamento

Como foi visto, os trinta e trs fatores de risco agrupados


Links:
em seis conjuntos, formam uma base de conhecimento para
o gerente de projetos, que pode usar dessa ferramenta para 1. Barki, H., Rivard, S., Talbot, J.: Toward an Assessment of Software De-
auxiliar em suas decises. Alm dessa base, apresentada velopment Risk, J. Management Information Systems, Vol. 10, No. 2, pp.
uma tabela comparativa entre projetos de pequeno, mdio e 203-225 (1993)
grande porte e resultados gerados a partir de simulaes para
2. Boehm, B. W.: Software Engineering Economics, IEEE Transactions on
fornecer aos gerentes de projetos de software, conhecimentos
Software Engineering, Vol. SE-10, No. 1, January, pp. 4-21 (1984)
para lhes auxiliar nas tomadas de decises.
No gerenciamento de riscos deseja-se diminuir as incertezas. 3. Boehm, B. W.: Software Risk Management: principles and practices, IEEE
Esse processo pode ser elaborado com um grande planejamen- Software, Vol. 8, No. 1, pp. 32-40 (1991)
to de aes para lidar com cada situao adversa, ou pode ser
4. Charette, R.N.: Software Engineering Risk Analysis and Management.
algo simples como, por exemplo, ter conhecimento dos proble- McGraw-Hill, New York (1989)
mas que podem atrapalhar o fluxo desejado do projeto.
Gerenciar risco no uma tarefa que deve ser executada ape- 5. Leopoldino, C. B. Avaliao de Risco em Desenvolvimento de Software.
nas em grandes projetos, mas sim uma atividade que deve ser Dissertao de Mestrado Escola de Administrao do Rio Grande do Sul,
incorporada ao cotidiano do gerenciamento de projetos. Porto Alegre (2004)
Existem inmeros outros instrumentos que auxiliam na an- 6. Madachy, R.: Software Process Dynamics, Wiley-IEEE Press, Washington
lise e gerenciamento dos riscos, uma dessas outras ferramentas, D.C. (2007)
a qual os resultados foram apresentados no artigo, o uso de
7. Schimidt, R., Lyytinen, K., Keil, M., Cule, P.: Identifying Software Project
simulaes para estimar o impacto e relacionamento entre os
Risks: An International Delphi Study. Journal of Management Information
fatores de risco. Este artigo no visa ser um arcabouo completo
System. Vol. 17, No. 4, pp. 5-36 (2001)
de conhecimento sobre o tema, mas sim uma estrutura inicial
para pesquisas posteriores sobre o assunto.
Voc gostou deste artigo?

D seu voto em www.devmedia.com.br/esmag/feedback


Ajude-nos a manter a qualidade da revista!

Edio 69 - Engenharia de Software Magazine 29


Planejamento e Gerncia
Nesta seo voc encontra artigos voltados para o planejamento
e gerncia de seus projetos de software.

Gerncia de Projetos: Monitore e controle o


desenvolvimento de software

Fique por dentro:

A
gesto de projetos de software Este artigo descreve a dificuldade existente
tem se fortalecido ao longo dos da aplicao da atividade de monitoramento
anos em razo da necessidade e controle nos processos de desenvolvimento
de garantir a qualidade e o sucesso de software, apresentando como ferramentas
dos projetos de software. Aliada aos e indicadores podem auxiliar a sua utilizao
Rommel Gabriel Gonalves Ramos conceitos clssicos da rea da adminis- constante em uma organizao. Apesar dos
Possui Graduao em Administrao de Siste-
mas de Informao pelo Centro Universitrio trao, tais como planejar, coordenar e processos de desenvolvimentos de software in-
Una (2004). Ps-graduao (especializao) em controlar, com os elementos especficos dicarem atividades ligadas ao monitoramento
Melhoria de Processo de Software pela Univer- da engenharia de software em relao e controle, na gesto de projetos ainda h uma
sidade Federal de Lavras (2007). Mestrado em aos processos de software consegue in- carncia no uso efetivo dessas atividades.
Tecnologias da Inteligncia e Design Digital
tegrar os aspectos tanto organizacionais
(TIDD) na PUC/SP. (2013). Atualmente e Consul-
tor de TI na Caixa Econmica Federal. Professor quanto tcnicos.
do SENAC/SP do Curso de Ps-Graduao (Espe- As atividades organizacionais atribu- acrescentam o aperfeioamento dos pro-
cializao) em Gesto e Governana de Tecnolo- das gesto de projetos de software vo cessos, mas existem fatores que devem
gia da Informao). desde o atendimento s necessidades ser observados.
do cliente em relao a um produto e/ O trabalho da gesto de projetos de
ou servio, at o relacionamento com software tentar cumprir o que foi
Daniel Couto Gatti
Possui graduao em Cincia da Computao os envolvidos em todo o ciclo de vida planejado. Muitos projetos fracassam
pela Pontifcia Universidade Catlica de So do projeto, j que as atividades tcnicas em seus objetivos ou no os alcanam
Paulo (1995), Mestrado em Comunicao e englobam desde as metodologias de de- plenamente devido a diversos desvios
Semitica pela Pontifcia Universidade Catlica senvolvimento de software at a implan- ou falhas que no foram identificados
de So Paulo (2002) e Doutorado em Educao
tao propriamente dita do software. no seu planejamento. Para obter mais
Matemtica pela Pontifcia Universidade Cat-
lica de So Paulo (2009). Atualmente Diretor Decidir sobre a utilizao de um qualidade, no s no software, mas em
da Faculdade de Cincias Exatas e Tecnologia instrumento para aplicar as prticas todo o seu processo, deve-se realizar um
da PUC/SP, professor da Faculdade de Tecnolo- administrativas principalmente em planejamento minucioso.
gia Bandeirantes, professor titular do Instituto relao gesto projetos de software O planejamento diz como e onde a
Brasileiro de Tecnologia Avanada e assistente
torna-se adequado, pois, os ganhos equipe deveria estar em determinado
mestre da Pontifcia Universidade Catlica de
So Paulo. que so obtidos com essa iniciativa momento. O monitoramento e controle,

30 Engenharia de Software Magazine - Gerncia de Projetos: Monitore e controle o desenvolvimento de software


planejamento

por sua vez, consistem em acompanhar as atividades plane- A tomada de deciso da gesto de projetos sem considerar
jadas com a finalidade de identificar possveis problemas ou os indicadores e relatrios de produtividade fornecidos pelo
desvios e deflagrar eventuais ajustes que possam ser necess- monitoramento e controle nos processos de desenvolvimento
rios para fazer o projeto de volta ao seu caminho original. de software: os relatrios de desempenho extrados dos indi-
Monitorar e Controlar definido pelo o PMI (Instituto de cadores devem estar alinhados ao monitoramento e controle
Gerenciamento de Projetos) como coletar os dados do projeto sendo uma maneira de trazer mais visibilidade aos gestores
referente ao plano de gerenciamento, produzindo medies de projetos. Ainda que eles no sejam utilizados na sua totali-
de desempenho e divulgando essas informaes por meio de dade, devem ser considerados em aes a serem tomadas no
relatrios. Dessa forma, podem ser tomadas aes corretivas somente pelo conhecimento emprico, mas em informaes
quando desvios forem identificados, garantindo o atendimento consolidadas e confiveis em relao aos problemas identifi-
dos objetivos do projeto. cados nos processos de desenvolvimento de software.
Analisando o monitoramento e o controle, pode-se dizer que
enquanto no monitoramento esto s atividades envolvendo o Monitoramento e controle
acompanhamento e a coleta de dados a respeito do andamento, Uma pesquisa do PMI realizada em 2012 revelou a frequncia
o controle consiste na tomada de aes frente aos desvios en- com que as empresas brasileiras adotam atividades de mo-
contrados no monitoramento, e por isso necessrio que haja nitoramento e controle em seus projetos. Nesta pesquisa
uma medio e a apurao de indicadores com as informaes identificou-se que:
que sero reportadas gesto de projetos de software. 22% sempre adotam;
O problema em realizar o monitoramento e controle nos pro- 54% adotam na maioria das vezes;
cessos de desenvolvimento de software, pode estar relacionado 24% nunca adotaram.
com as seguintes situaes:
A forma de utilizao do monitoramento e controle nos Com a anlise desses dados, identificamos que 76% das
processos de desenvolvimento de software: nem sempre os empresas de certa forma adotam alguma forma de acompa-
processos e metodologias de desenvolvimento de software nhamento das fases e/ou atividades dos projetos porm, 24%
deixam explcito como deve ser feito o monitoramento e con- das empresas no se preocupam em fazer nenhum monitora-
trole. E normalmente cada metodologia aborda o processo de mento e controle.
software buscando a execuo das suas fases e atividades sem Esses dados no diferem do cenrio quanto aos problemas
nenhum tipo de monitoramento e controle; mais frequentes enfrentados pelas empresas em relao aos
As ferramentas no so suficientes para o suporte das seus projetos atribudos a prazo (65,7%), escopo (61,7%) e custo
atividades de monitoramento e controle nos processos de (41,3%).
desenvolvimento de software: algumas ferramentas dispo- Neste estudo, 18,4% dos problemas est relacionado falta de
nveis no mercado que so utilizadas como apoio gesto de uma ferramenta para o monitoramento e controle, indicando
projetos de software no oferecem opes suficientes para que 24,5% dos softwares mais utilizados so desenvolvidos
realizar o monitoramento e controle no acompanhamento internamente por opo da empresa, o que mostra que as em-
das fases e/ou atividades no processo de desenvolvimento de presas no conseguem encontrar uma ferramenta adequada
software, pois devem apresentar alguns pontos e ter opes devido s necessidades e particularidades internas.
que permitam: Cabe destacar que, habitualmente, o monitoramento e contro-
- selecionar projetos de software com alinhamento s estra- le considerado pelo nvel operacional como uma ao de audi-
tgias corporativas, analisando os seus impactos e riscos; toria em que so tratadas as inconformidades das atividades e
- gerenciar os recursos envolvidos em vrios projetos de dos processos. Esse pensamento dificulta a sua abordagem do
software, compartilhando as suas informaes de tempo, que deve ser entendido, pois no apenas uma tarefa externa
custo e qualidade; que verifica como o processo est sendo conduzido, mas se ele
- gerenciar o retorno de investimento em pequenos, grandes realmente entendido pela equipe e principalmente se gera
e complexos projetos de software; valor aos envolvidos e responsveis pelo processo.
- gerenciar o ciclo de vida dos projetos promovendo melho- O monitoramento e controle nos projetos de software busca
rias contnuas no processo de software; garantir a verificao do que deve ser realizado no projeto,
Existem falhas no papel dos gerentes de projetos em relao ou seja, acompanhar os processos que so executados com as
ao monitoramento e controle nos processos de desenvolvi- suas atividades, identificando aes corretivas e preventivas,
mento de software: o monitoramento e controle fornecem estabelecendo assim maneiras de tomada de deciso na gesto
insumos importantes para que o processo de desenvolvimento de projetos de software.
de software possa ser melhorado nas suas fases e/ou ativida- Se a execuo do projeto tem como objetivo entregar produtos
des, mas a atuao gerencial precisa ser mais eficaz e eficiente e/ou servios planejados, o monitoramento e controle envol-
em relao s aes preventivas e/ou corretivas, pois de nada vem o acompanhamento destes resultados para garantir que
adianta ter instrumentos que auxiliam este processo se no estejam de acordo com o planejado e que o projeto continue
existe uma atuao assertiva; seguindo o plano de gerenciamento do projeto.

Edio 69 - Engenharia de Software Magazine 31


O monitoramento e controle fornecem subsdios para as processos que sero utilizados para monitorar e controlar o
atividades nos processos de software. Com essas informaes progresso, a qualidade e os riscos do projeto.
disponveis aos gerentes de projetos, tem-se a possibilidade de Uma outra tarefa referente ao gerenciamento de projetos
atuao constante ao que deve ser desenvolvido e entregue por monitorar status do projeto que captura o trabalho dirio
sua equipe, proporcionando melhorias em relao conduo e contnuo, incluindo monitoramento de status do projeto,
do projeto de forma assertiva. relatrio para envolvidos lidando com as situaes atuais e
A finalidade do monitoramento e controle determinar se os problemas detectados.
o projeto est prosseguindo conforme planejado. Essa fase No RUP, o monitorar e controlar o projeto permeiam todas as
consiste em trs etapas: tarefas essenciais at a finalizao do projeto conforme pode
1. Monitoramento das atividades contnuas do projeto (onde ser observado na Figura 1.
estamos); Com a utilizao do RUP nas suas etapas e atividades, pode-
2. Comparao das variveis do projeto (custo, esforo, tempo, mos aplicar o monitoramento e controle para que o projeto te-
recursos, etc.) com o plano real (onde deveramos estar); nha os resultados esperados e definidos desde a sua concepo
3. Identificao de aes corretivas (como voltamos ao cami- at a transio, buscando abordar todas as suas disciplinas e
nho certo). aplicando indicadores que possam ajudar a gesto de projetos
de software por meio de aes corretivas e preventivas.
Monitoramento e controle no RUP (Rational Unified
Process) Monitoramento e controle no PMBOK
Na disciplina de gerenciamento de projetos do RUP, encon- O monitoramento e controle de projetos segundo o PMBOK
tramos uma tarefa definir monitoramento e processos de tm o benefcio de observar e mensurar o desempenho do pro-
controle, que tem o objetivo de definir as informaes e os jeto de forma peridica e uniforme para identificar variaes

Figura 1. Monitoramento e Controle no RUP

32 Engenharia de Software Magazine - Gerncia de Projetos: Monitore e controle o desenvolvimento de software


planejamento

em relao ao plano de gerenciamento do projeto definido dos riscos residuais, identificao de novos riscos e avaliao
que inclui: do processo de risco durante todo o projeto.
Controlar as mudanas e recomendar aes preventivas em Administrar as requisies: gerenciamento das aquisies
antecipao a possveis problemas; e monitoramento dos desempenhos dos contratos, fazendo
Monitorar as atividades do projeto em relao ao plano de mudanas e correes conforme necessrio.
gerenciamento e a linha de base de desempenho do mesmo;
Influenciar os fatores que poderiam impedir o controle inte- A utilizao do PMBOK no monitoramento e controle nos
grado de mudanas, para que somente as mudanas aprovadas processos de software explicita uma documentao em todas
sejam implementadas. as reas, tornando esta atividade aderente ao que deseja a
gesto de projetos de software.
Este monitoramento contnuo oferece equipe do projeto uma
viso melhor sobre a sade do mesmo e identifica quaisquer Ferramentas para monitoramento e controle
reas que requeiram ateno adicional. No apenas monitora e Os softwares para o gerenciamento de projetos so usados
controla o trabalho que est sendo feito durante um grupo de com diversos fins como: planejar, monitorar, controlar, relatar
processos, mas tambm monitora e controla o projeto inteiro, e comunicar a situao 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,
avaliao e regulao do progresso para atender aos objetivos de analisa-los e relatar o progresso alcanado:
desempenho definidos no plano de gerenciamento do projeto; Quais dados so coletados: dados coletados so determina-
Realizar o controle integrado de mudanas: avaliao de dos por qual sistema de medio ser usado para o controle
todas as solicitaes de mudanas, aprovao de mudanas e do projeto.
gerenciamento das mesmas em entregas, ativos de processos Coletar dados e fazer anlise: com a definio de quais
organizacionais, documentos e plano de gerenciamento do dados so coletados, o prximo passo estabelecer por quem,
projeto; quando e como os dados sero agregados;
Verificar o escopo: formalizao da aceitao das entregas Relatrios e o modo de reportar: quem recebe os relatrios
terminadas no projeto; de desempenho? As partes interessadas e gerentes necessitam
Controlar o escopo: monitoramento do andamento do escopo de diferentes tipos de informao relacionadas ao projeto.
do projeto e do produto e gerencia-
mento das mudanas feitas na linha
de base do escopo;
Controlar o cronograma: monito-
ramento do andamento do projeto
para atualizao do seu progresso e
gerenciamento de mudanas feitas na
linha de base do cronograma;
Controlar os custos: monitoramen-
to do andamento do projeto para
a atualizao do seu oramento e
gerenciamento de mudanas feitas
na linha de base dos custos;
Realizar o controle da qualidade:
monitoramento e registro dos re-
sultados da execuo das atividades
de qualidade para avaliar o desem-
penho e recomendar as mudanas
necessrias;
Reportar o desempenho: coleta e
distribuio de informaes sobre o
desempenho, inclusive relatrios de
andamento, medies do progresso
e previses;
Monitorar e controlar os riscos:
implementao de planos de respos-
tas aos riscos, acompanhamento dos
riscos identificados, monitoramento Figura 2. Monitoramento e Controle no PMBOK

Edio 69 - Engenharia de Software Magazine 33


A importncia dos softwares no monitoramento e controle Benefcios do monitoramento e controle
de projetos de fornecer insumos essenciais para o processo A aplicao do monitoramento e controle no processo de
de desenvolvimento de software dos projetos desenvolvidos desenvolvimento de software contribui e serve como um me-
e, portanto, as informaes que so coletadas, analisadas e canismo de aproximao entre as reas gerenciais e tcnicas,
disponibilizadas ajudam na tomada de deciso quanto ao que gerando dados e indicadores que tornam mais previsveis e
precisa ser apurado durante as etapas e atividades previstas e assertivos os planejamentos para a tomada de deciso na gesto
concludas em um projeto. de projetos de software.
Podemos levar em considerao os processos de desenvolvi-
Indicadores para o monitoramento e controle mento de software para o monitoramento e controle no aspecto
Podemos perceber certa resistncia em se medir os processos da gesto de projetos, as seguintes contribuies:
de desenvolvimento de software atravs de indicadores de de- A atividade de monitoramento e controle quando realizada
sempenho. Um dos motivos dessa resistncia a dificuldade de nos processos de software deve estabelecer processos, ativida-
se identificar indicadores que realmente ajudem na produo des e tarefas que possam direcionar a sua utilizao;
de informaes importantes. As ferramentas que o monitoramento e controle utilizam para
Apesar de termos a possibilidade de utilizar estes indicado- o processo de software podem direcionar aes corretivas e
res de forma favorvel em aes para melhorar os processos preventivas, que devem ser informadas gesto de projetos
de desenvolvimento de software, a gesto de projetos conti- para que as devidas providncias necessrias ao trabalho rea-
nua no achismo e no seu feeling, mas isso no o ideal, lizado pelo gerente de projetos e sua equipe sejam tomadas;
pois existem mtricas e informaes que no esto sendo A atuao gerencial tendo como uma das suas premissas a
consideradas. execuo da atividade de monitoramento e controle nos pro-
No desenvolvimento de software podemos aplicar trs tipos cessos de software como ferramenta diria de trabalho para
de indicadores que so os mais utilizados para medir o desem- acompanhar os projetos e sistemas de uma organizao;
penho dos processos organizacionais:
Indicador de qualidade: relao entre o que produzido Por fim, vale destacar que os indicadores de produtivida-
(certo ou errado) pelo total produzido; de atrelados ao monitoramento e controle nos processos de
Indicador de produtividade: relao entre o total produzido desenvolvimento de software so subsdios fornecidos que
sobre os recursos consumidos; podem ter dados, informaes atualizadas e consistentes
Indicador de capacidade: mede a produo em um espao para a tomada de deciso na gesto de projetos. Portanto,
de tempo (capacidade da produo). necessrio que possam ser diversificados de acordo com a
realidade da organizao.
A utilizao desses indicadores no monitoramento e controle,
considerando a sua documentao como os artefatos requeri- Links:
dos, deve atentar para:
Indicador de qualidade: total de artefatos que voltaram para GRAY, Clifford F., Erik W. Larson: Gerenciamento de Projetos: O Processo
o retrabalho dividido pelo total de artefatos entregues; Gerencial; Traduo Dulce Cattunda, Frederico Fernandes 4 ed. Porto
Indicador de produtividade: total de artefatos entregues Alegre: AMGH, 2010.
dividido pelo total de funcionrios trabalhando no projeto; KERZNER, H. Project Management - A System Approach to Planning,Scheduling,
Indicador de capacidade: total de artefatos entregues divi- and Controlling, 7 ed., New York, John Wiley & Sons Inc.,2001.
dido pelo tempo total do projeto.
MENDONA, Mauro. TAM Tcnicas para Anlise e Melhoria de Processos.
Curso em Fita de Vdeo, LinkQuality, 2002.
Em projetos, devemos contextualizar a utilizao dos indi-
cadores como se fossem fotografias instantneas, mas que PMI-Project Management Institute. Pesquisa PMSURVEY.ORG 2012: PMI. 2012.
indicam tendncias. Aconselha-se utilizar aqueles que con- http://www.pmsurvey.org/
siderarem os mais adequados ao contexto que foram criados
PMBOK. A Guide to the Proiject Management Body of Knowledge, PMI-Project
na prpria empresa, ou os mais usuais do mercado. Ter estes
Management Institute, Newtown Square, Pennsylvania, USA, 2008.
indicadores atribudos gesto de projetos nos ajuda a:
Ter uma viso melhor do processo de desenvolvimento de
software; Voc gostou deste artigo?
Identificar os riscos;
Identificar e resolver os problemas antes que se tornem D seu voto em www.devmedia.com.br/esmag/feedback
crticos;
Ajude-nos a manter a qualidade da revista!
Melhorar a comunicao da equipe com a organizao
Avaliar o desempenho do projeto.

34 Engenharia de Software Magazine - Gerncia de Projetos: Monitore e controle o desenvolvimento de software


Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros

Gesto de Projetos: Usando processos de


desenvolvimento

Fique por dentro: que no possui como atividade final o desenvol-


Este artigo descreve como a gesto de projetos uti- vimento de software, mas que necessita ter a vi-
Rommel Gabriel Gonalves Ramos liza a engenharia de software para a modelagem sibilidade para as suas reas gestoras de projetos
rommel.gabriel@gmail.com
de produtos de software e, consequentemente, e negcios, verificando e acompanhando as fases,
Possui Graduao em Administrao de Siste-
as atribuies requeridas no gerenciamento de etapas e atividades previstas nos processos de de-
mas de Informao pelo Centro Universitrio
Una (2004). Ps-graduao (especializao) em projetos. O objetivo principal apresentar a apli- senvolvimento, comumente utilizados em vrias
Melhoria de Processo de Software pela Univer- cao quanto s tcnicas, modelos, metodologias empresas de desenvolvimento de software, ten-
sidade Federal de Lavras (2007). Mestrado em e ferramentas para a construo do produto de do como premissa a construo e a manuteno
Tecnologias da Inteligncia e Design Digital software em um determinado cenrio. O mode- de produtos e servios que so documentados e
(TIDD) na PUC/SP. (2013). Atualmente e consul-
lo de desenvolvimento utilizado na empresa aderentes aos normativos internos desta empre-
tor de TI na Caixa Econmica Federal. Professor
do SENAC/SP do Curso de Ps-Graduao (Espe- baseado em controles institucionais. Os cenrios sa, estipulados pelas reas gestoras de tecnologia
cializao) em Gesto e Governana de Tecnolo- apresentados neste artigo so os mais usados da informao.
gia da Informao). Professor Assistente da FMU atualmente em uma empresa de grande porte,
- Faculdades Metropolitanas Unidas do Curso de
Anlise e Desenvolvimento de Sistemas.

A
s empresas de desenvolvimento precisam vencer o seu buraco negro que
Daniel Couto Gatti
daniel@pucsp.br
de software buscam alguma o seu estilo de gerenciar de maneira
Possui graduao em Cincia da Computao forma de gerenciar os seus informal, sem mtodos e sem tcnicas.
pela Pontifcia Universidade Catlica de So projetos de software, desejando ter um Constantemente so oferecidas em
Paulo (1995), Mestrado em Comunicao e modelo e/ou processo de sucesso que diversos eventos de tecnologia da infor-
Semitica pela Pontifcia Universidade Catlica
possa atender todas as etapas, fases e ati- mao voltados para o gerenciamento
de So Paulo (2002) e Doutorado em Educao
Matemtica pela Pontifcia Universidade Cat- vidades na produo do software. Entre- de projetos: ferramentas, metodologias,
lica de So Paulo (2009). Atualmente Diretor tanto, no existe uma receita que garanta modelos e melhores prticas que possam
da Faculdade de Cincias Exatas e Tecnologia empresa alcanar este objetivo. tornar o desenvolvimento de software
da PUC/SP, professor da Faculdade de Tecnolo- O SEI - Software Engineering Institute mais eficaz e eficiente, tendo em vista
gia Bandeirantes, professor titular do Instituto
constatou que o principal problema que que hoje somos muito dependentes da
Brasileiro de Tecnologia Avanada e assistente
mestre da Pontifcia Universidade Catlica de aflige as organizaes de software ge- mo-de-obra tcnica especializada para
So Paulo. rencial e preconizou que as organizaes o processo de produo de software.

Edio 69 - Engenharia de Software Magazine 35


A gesto de projetos de software enfatiza e deixa evidente outra pessoa e at mesmo pela ausncia/deficincia de docu-
que o gerenciamento de projetos deve ser melhorado, e por mentao das rotinas e dos procedimentos j construdos.
isso, modelos e normas evoluram principalmente com a
incluso de prticas gerenciais para os projetos de software Para solucionar alguns destes problemas, muitas empresas
como, por exemplo: o CMM para CMMI e a ISO 12207 para a de software tm adotado processos de desenvolvimento de
ISO 15504. software. Todavia, os paradigmas metodolgicos para desen-
O problema da indstria de software mais gerencial do volvimento de software tm sido considerados somente em
que tcnico, todavia, o gerenciamento do projeto no est termos de um mtodo de anlise/projeto/implementao,
sendo considerado como deveria. 75% de todos os sistemas de isto , um conjunto de conceitos, tcnicas e notaes.
software falham e a causa principal o pobre gerenciamento Contudo, a grande maioria das organizaes que desen-
por parte do desenvolvedor e adquirente, deixando claro que volvem software sente muita dificuldade em entender, de-
o problema no de desempenho tcnico. finir e gerenciar estes processos. As empresas de software
Portanto, um fator preponderante ao processo de desen- devem buscar os seus prprios ambientes para existirem
volvimento de software a gesto, pois precisamos de mais e operarem. Abordagens da indstria manufatureira, por
gerentes de projetos que possuam alm da experincia tcni- exemplo, no tm demonstrado serem adequadas indstria
ca, uma fundamentao terica e prtica maior na parte de de software.
gerenciamento. Ou seja, para alcanar alguns resultados em A utilizao mais sistemtica de processos foi iniciada nos
um determinado projeto so necessrias algumas habilidades anos 30. Nesta poca, iniciou-se um trabalho em melhoria de
essenciais e decisivas. Uma empresa que desenvolve software processo com os princpios do controle estatstico. Nos anos
precisa ter alm de bons profissionais, ferramentas, modelos, 70, notou-se que as organizaes de manufatura poderiam
tcnicas e processos. ser estudadas de acordo com a qualidade de sua produo
Toda empresa que desenvolve um software precisa de pro- e definiu-se cinco estgios sequenciais e cumulativos do
cessos que possam ser seguidos, acompanhados, monitorados processo de produo, baseados principalmente nas atitudes
e controlados, como j preconiza algumas tcnicas do gerencia- gerenciais encontradas em cada estgio. Estes estgios indi-
mento de projetos e a prpria gesto de processos. Os processos cam a qualidade do processo de produo.
devem ser utilizados por nossas equipes de projetos, sendo Nos anos 80, comeou-se a aplicar estes princpios de con-
essencial para alcanar aquilo que se espera de todo o produto troles estatsticos e os estgios de qualidade para software. Os
de software que atender as necessidades dos usurios. princpios e conceitos bsicos que fundamentaram os modelos
de maturidade da capacidade foram descritos nesta poca.
Engenharia de software na gesto de projetos Pesquisas e estudos que foram realizados nos anos 90
A engenharia de software tem por finalidade auxiliar na demonstraram que o gerenciamento de projeto a causa
construo de software da melhor maneira possvel. Desde os mais evidente das falhas na execuo e entrega de produtos
anos 1960, quando a frase a crise de software foi pronuncia- e servios de software. Isso demonstra que a engenharia
da, muitos problemas desta rea foram identificados, e muitos de software torna-se essencial, pois busca a utilizao dos
deles ainda persistem, tais como: modelos que permitem especificar, projetar, implementar e
Previso pobre - desenvolvedores no prevem adequada- manter os softwares, aplicando as prticas de gerncia de
mente quanto tempo e esforo sero necessrios para produzir projeto e demais disciplinas, com o objetivo de trazer para
um sistema de software que satisfaa s necessidades (requisi- as empresas produtividade e qualidade.
tos) dos clientes/usurios. Sistemas de software so geralmente
entregues muito tempo depois do que foram planejados; Gerenciamento de projetos
Programas de baixa qualidade - programas de software no A gerncia de projetos a primeira camada do processo de
executam o que o cliente deseja como consequncia, talvez, engenharia de software. O termo camada em vez de etapa,
da pressa para se entregar o produto. Os requisitos originais fase ou atividade, porque ela abrange todo o processo de
podem no ter sido completamente especificados ou podem desenvolvimento do incio ao fim.
apresentar contradies e isto pode ser descoberto muito tarde Uma das tentativas iniciais de resolver falhas em projetos
durante o processo de desenvolvimento; foi incentivada e financiada pelo DOD (Departamento de
Alto custo para manuteno - a manuteno pode ser cor- Defesa Americano). O Software Engineering Institute (SEI)
retiva, quando ocorrem enganos (erros, falhas) no sistema da Universidade Carnegie Mellon desenvolveu um modelo
j entregue, ou evolutiva quando novas caractersticas so de maturidade de desenvolvimento de software, o CMM
adicionadas ao sistema de software. Ambas so caras quando (Capability Maturity Model).
o sistema original foi construdo sem uma arquitetura clara O CMM (Capability Model Maturity) indica que uma or-
e visvel; ganizao pode ser aferida ou avaliada comparando-se suas
Duplicao de esforos - difcil compartilhar solues ou prticas reais com aquelas que o modelo de maturidade de
reusar cdigos em funo das caractersticas de algumas lin- capacitao prescreve ou recomenda. Essa aferio produz um
guagens adotadas, por falta de confiana no cdigo feito por diagnstico da organizao quanto aos seus processos.

36 Engenharia de Software Magazine - Gesto de Projetos: Usando processos de desenvolvimento


en gen haria

O diagnstico serve de base para recomendaes de melhoria Estes fatores dificultam o trabalho das equipes de desenvolvi-
de processos, e estas recomendaes podem ser consolidadas mento na medio do desempenho dos projetos, na verificao
em um plano de melhoria. Alm dos benefcios naturais, como de pontos falhos, no registro de problemas, na realizao de
produtividade e qualidade, acredita-se que em curto prazo as estimativas e planejamentos adequados.
certificaes dos processos fabris ser um pr-requisito bsico De acordo com o PMBOK, as atividades da organizao
para contrataes de produtos de software. executora que determinam as responsabilidades, os objetivos
Por esses motivos, o CMM (Modelo de Capacidade e Maturida- e as polticas, de modo que o projeto atenda s necessidades
de) tornou-se ao longo de uma dcada o mais conhecido, usado que motivaram sua realizao, com as atividades dos processos
e respeitado pela comunidade de engenharia de software, com o conduzidos do incio ao fim, conforme adequado.
objetivo principal de estabelecer um padro de qualidade para
software desenvolvido para as foras armadas. Atualmente, o Aplicao da gesto de projetos nas empresas de
modelo de referncia o Capability Maturity Model Integration software
- CMMI v1.3, lanado em 2002 como evoluo do CMM. As organizaes devem buscar alternativas sobre como fazer
As empresas de software que alcanam nveis de maturi- a gesto de seus projetos de software, visando a diminuio
dade mais elevados possuem processos capazes de produzir dos fracassos e a melhoria na qualidade de seus produtos e
produtos extremamente confiveis dentro de limite de custo e servios. Os processos tradicionais de desenvolvimento e a
cronograma previsvel. medida que cresce o entendimento gerncia de projetos tm sido caracterizados como uma des-
dos nveis de maturidade mais elevados, as reas de processos crio linear de um processo sequencial.
existentes vo sendo redefinidas e outras ainda podem ser Qualquer projeto de software ser beneficiado pelo uso de
adicionadas ao modelo. algum tipo de modelo, inclusive no setor comercial, em que s
Alm dos modelos CMM/CMMI, outra publicao que in- vezes mais comum distribuir softwares inadequados devido
fluencia a abordagem de desenvolvimento de software o Cor- produtividade oferecida pelas linguagens de programao
po de Conhecimentos em Gerncia de Projetos - PMBOK. visual. A modelagem poder auxiliar a equipe de desenvol-
O PMBOK descreve os conhecimentos necessrios para uma vimento a visualizar melhor o planejamento do sistema e
gerncia de projetos no apenas de software, mas de outras permitir que o desenvolvedor seja mais rpido ajudando a
reas de conhecimento, definindo como aplicar os conheci- construir o item correto.
mentos, habilidades, ferramentas e tcnicas s atividades do No desenvolvimento de um software, podemos utilizar
projeto a fim de atender aos seus requisitos. Dentre algumas modelos existentes no mercado como referncia de forma que
das atividades de um gerente de projeto esto: seja uma metodologia de sucesso.
Identificar as necessidades do projeto; Neste contexto, essencial o uso da gesto de projetos para
Estabelecer objetivos claros e alcanveis; descrever como um software deva ser construdo e modelado
Equilibrar as demandas conflitantes de qualidade, escopo, utilizando ferramentas, padres e normas baseados em pro-
tempo e custo; cessos e como eles sero aplicados em quem desenvolve e/ou
Adaptar as especificaes, planos e a abordagem s diferentes adquire solues para conduzir o seu negcio no dia a dia.
preocupaes e expectativas das diversas partes interessadas; e; Isto deve ser uma meta a se alcanar nas empresas que esto
Minimizar os impactos negativos das incertezas dos em busca de benefcios e resultados, principalmente para esta-
projetos. belecer melhorias contnuas na mudana de paradigmas, e na
maneira de introduzir inovaes tecnolgicas para a resoluo
Alm da questo de conhecimentos em gerncia de projetos, de problemas rotineiros e complexos.
a utilizao de alguma ferramenta apropriada facilita o acom- Contudo, as organizaes precisam adaptar suas estruturas,
panhamento e o controle do projeto no sentido de atender as estratgias e polticas para satisfazerem os novos ambientes e a
demandas de desenvolvimento de software da rea de negcio crescente demanda da sociedade contempornea por sistemas
de um determinado sistema dentro da organizao, classifi- de informao que so construdos a partir da iniciativa da
cando assim as suas prioridades no seu atendimento. gesto de projetos.
Um processo de gerenciamento de projeto deve: identificar, A falha nos projetos discutida em algumas pesquisas. Em uma
estabelecer, coordenar e monitorar as atividades, as tarefas e delas, realizada nos anos de 1992 e 1993, mais de 60% dos projetos
os recursos necessrios para um projeto produzir um produto pesquisados nos Estados Unidos estavam atrasados e mais da
e/ou servio, de acordo com seus requisitos. Todavia, gerenciar metade ultrapassava em 50% o prazo planejado. Um outro estudo
projetos de software uma atividade complexa devido a uma conduzido em 1999 indicou que somente 37% dos sistemas de
srie de fatores, tais como: informao foram finalizados no prazo estipulado.
Dinamicidade do processo; Adicionalmente, dos 63% dos projetos que atrasaram 42%
Grande nmero de variveis envolvidas; seriam finalizados acima do oramento. O Standish Group,
Exigncia de adaptabilidade ao ambiente de desenvol- atravs de um estudo chamado de relatrio do Chaos, iden-
vimento; tificou que as empresas dos Estados Unidos gastaram US$81
Constantes alteraes no que foi planejado. milhes em projetos de software, sendo que 31% dos projetos

Edio 69 - Engenharia de Software Magazine 37


de software estudados foram cancelados antes de estarem con- na verdade j se beneficiam dos avanos das tecnologias de in-
cludos, 53% excederam mais do que 50% a sua estimativa de formao e comunicao (TICs), que tambm podero sofrer as
custo e somente 9% dos projetos, em grandes empresas, foram consequncias de um erro, defeito ou falha de um software.
entregues no tempo e oramento previstos; para empresas de As empresas que utilizam modelos apropriados para a
pequeno e mdio porte, os nmeros melhoraram de 50% para construo e manuteno de um software demonstram ter um
28% e de 9% para 16%. nvel de maturidade, adicionando mais produtividade com
Tem-se tentado resolver essas falhas atravs de modelos de competncia tcnica, operacional e gerencial, o que requer
melhoria e processo que esto baseados no Tringulo Mgico delas o controle sobre seus processos imaturos, maduros e
da Fora do Desenvolvimento de Software (Magic Triangle of institucionalizados.
Software Development Greatness). Qualquer deficincia em J em 1989, foi constatado que a ausncia de prticas adminis-
alguma rea do tringulo se manifestar em riscos de falha trativas no desenvolvimento de software a principal causa de
dos projetos (ver Figura 1). srios problemas enfrentados pelas organizaes, tais como:
Ento, evidente que temos que trabalhar em todos os atrasos em cronogramas, custo maior do que o esperado e pre-
seus aspectos, sendo que uma fora influencia na outra. Por sena de defeitos, ocasionando uma srie de inconvenincias
exemplo, processos imaturos fazem com que tenhamos uma para os usurios e enorme perda de tempo e de recursos.
deficincia no estabelecimento do perfil tcnico requerido A meta da gesto de projetos conseguir exceder as necessi-
para exercer uma atividade e no se consiga obter o melhor dades e expectativas dos stakeholders. Todavia, satisfazer ou
da tecnologia oferecida. exceder estas necessidades envolve um balanceamento entre as
vrias demandas concorrentes em relao aos itens abaixo:
escopo, tempo, custo e qualidade (objetivos do projeto);
stakeholders com necessidades e expectativas diferenciadas; e
requisitos identificados (necessidades) e requisitos no iden-
tificados (expectativas).

A gesto de projetos sendo conduzida pela gesto de proces-


sos pode trazer diversos benefcios organizao, tais como:
Descrio precisa e no ambgua dos processos de negcio
existentes;
Melhoria na definio de novos processos;
Maior eficcia na coordenao do trabalho entre diferentes
Figura 1. Tringulo Mgico da Fora de Desenvolvimento de Software agentes;
Obteno, em tempo real, de informaes precisas sobre o
O processo de software, portanto, essencial para que tenha- andamento dos processos e;
mos qualidade no produto de software e consigamos atender a Padronizao dos processos executados, de forma manual
qualidade, oramento, prazos e recursos definidos no projeto. ou automatizados, pela organizao.
Organizaes que sejam capazes de integrar, harmonizar e
acelerar seus processos de desenvolvimento e manuteno de Desde o comeo da dcada de 1990, a corrida pela excelncia
software tendem a ser mais bem sucedidas no mercado. na gesto de projetos tem assumido uma importncia cada vez
Geralmente um projeto de software requer a participao maior. Os benefcios da gesto de projetos so bvios hoje tanto
de uma ou mais equipes, cooperando para a construo de para os clientes quanto para os fornecedores. De fato, a exce-
determinado produto de software. necessrio que exista lncia em gesto de projetos se tornou uma arma competitiva
consenso sobre o processo a ser seguido desde a concepo at que atrai novos negcios e mantm os clientes tradicionais.
a implantao do produto de software, para que interpretaes Para atender a demanda de maneira eficaz em um ambiente
pessoais no desviem o foco do trabalho ou introduzam erros caracterizado pela velocidade das mudanas, torna-se indis-
durante o desenvolvimento. pensvel um modelo de gerenciamento baseado no foco em
Todos estes fatores levam as organizaes desenvolvedoras de prioridades e objetivos. Por essa razo, o gerenciamento de
softwares a atuar fortemente na qualidade de seus produtos, projetos tem crescido de maneira to acentuada no mundo
que um dos principais objetivos da engenharia de software. nos ltimos anos.
Contudo, a qualidade dos produtos de software, que tambm Outro fator que impulsionou o gerenciamento de projetos
ficou evidente para a evoluo da qualidade dos produtos o crescimento da competitividade. Quem for mais rpido e
das indstrias, est fortemente relacionada qualidade do competente certamente conseguir melhores resultados.
processo de software. Ainda hoje, esta afirmao tem sido confirmada por diversos
A utilizao de software j faz parte do cotidiano de prati- autores. Na atual cultura das organizaes de software, o pla-
camente todas as pessoas. Mesmo aquelas que pensam que nejamento, quando ocorre, feito de forma superficial. Muitos
nunca utilizaram um software, internet, ou um computador, projetos de software so realizados sem um planejamento de

38 Engenharia de Software Magazine - Gesto de Projetos: Usando processos de desenvolvimento


en gen haria

como a ideia modelada pelo levantamento de requisitos e ne- tambm a sua manuteno com uma modelagem adequada.
cessidades dos clientes pode ser transformada em produto. O processo padro estabelece o conjunto de elementos fun-
Os gerentes de projeto de software esto desacostumados a damentais que guia o desenvolvimento e a manuteno de
estimar. Quando estimam, costumam basear-se em estimativas sistemas. Ele define uma estrutura nica a ser seguida por
passadas, mesmo sabendo que elas podem estar incorretas toda a equipe envolvida em projetos de software, independen-
(no sabem tambm precisar o quanto elas esto incorretas). temente das caractersticas do software a ser desenvolvido e
H gerentes que se recusam a estimar somente por julgarem das tcnicas a serem utilizadas.
perda de tempo, uma vez que correm o risco de obter resultados Essas tcnicas so definidas de acordo com as necessidades
incorretos e, portanto, estarem desperdiando tempo. do projeto, ambiente, a preferncia e competncia da equipe
Boas estimativas de custo, esforo e prazo de software reque- multidisciplinar envolvida. A inovao tecnolgica um di-
rem um processo ordenado que defina a utilizao de mtricas ferencial que deve ser incentivado. o ponto de partida para
de software, mtodo e ferramenta de estimativa. As empresas a instanciao dos processos de software adequados s dife-
de software, de forma geral, no detm conhecimentos e re- rentes caractersticas de cada projeto, permitindo economia de
cursos para isso. tempo e esforo na definio do processo a ser seguido.
Estimar, medir e controlar um projeto de software so tarefas As orientaes sobre as tcnicas mais utilizadas so apresen-
difceis, pois o desenvolvimento de software uma atividade tadas como cenrios e tambm compem a metodologia de
criativa e intelectual, com muitas variveis envolvidas (como sistemas que deu suporte construo de grande parte dos sis-
metodologias, modelos, tcnicas, ferramentas, tecnologias, temas. Os modelos instanciam os processos de desenvolvimen-
recursos e atividades diversas). Os gerentes inexperientes to que so associados a estas tcnicas e so disponibilizados
tentam cumprir prazos dando a mxima velocidade na fase dentro dos cenrios atravs de casos de desenvolvimento.
inicial e esto despreparados para os momentos de impasse, Observe a Figura 2. Este modelo exemplifica a estrutura do
quando os ajustes so inevitveis. modelo de desenvolvimento dos sistemas. O processo padro
A dinamicidade do processo de software dificulta tambm est normatizadoe estabelece controles rigorosos com o foco
o gerenciamento efetivo de projetos de software, devido s na preservao institucional. Adicionalmente, a ttulo de
alteraes constantes nos planos de projetos, redistribuio orientao, so apresentados cenrios direcionados a tcni-
de atividades, incluso/excluso de atividades, adaptao de cas especficas, de acordo com a experincia anteriormente
cronogramas, realocao de recursos, novos acordos com os adquirida (o conhecimento acumulado no desenvolvimento
clientes, entregas intermedirias no previstas etc. Um projeto de sistemas, cujo registro foi apropriado atravs do grupo
de software tambm deve se adaptar ao ambiente, dependendo de trabalho).
da disponibilidade de recursos, ferramentas e habilidades do O uso de abordagens como o RUP, conforme Figura 3, con-
pessoal ou equipe. templar atividades e artefatos efetivamente indispensveis
Outros fatores ainda agravam os problemas da gesto de pro- instituio, incluindo os controles institucionais, e que dever
jetos de software em empresas, tais como: inexistncia de um ser flexvel o suficiente para atender s diversas situaes co-
processo definido, recursos pessoais e financeiros limitados, muns ao desenvolvimento, em qualquer tipo de projeto.
falta e/ou pouca cultura em processos, pouco treinamento em Se voc depende de sua capacidade para desenvolver e im-
engenharia de software, imaturidade metodolgica, cresci- plantar software, que essencial para o sucesso da instituio,
mento ocorrido por demanda, falta de experincia adminis- ele ir ajud-lo, pois foi desenvolvido visando dois grupos
trativa por parte dos gerentes e diretores e falta de definio primrios de usurios:
das metas organizacionais. Profissionais de desenvolvimento de software que trabalham
Tem-se tambm a persistncia de um conhecido problema no como parte de uma equipe de projeto, incluindo os investidores
desenvolvimento de software: muitos projetos consomem mais desses projetos de desenvolvimento de software;
recursos do que o planejado e demoram mais tempo para serem Profissionais de engenharia de processo, especificamente
realizados, possuem menos funes e menor qualidade do que engenheiros de processo de software e gerentes.
o esperado. Relatos de insucesso na produo de sistemas de
software podem ser encontrados em diversos estudos de casos Os profissionais de desenvolvimento de software podem
e experimentos documentados ao longo dos ltimos anos. encontrar orientao sobre o que exigido deles nas funes
definidas. Um profissional que trabalha em um projeto de
O modelo de desenvolvimento para a gesto de engenharia de software designado a uma ou mais funes
projetos definidas, e em que cada funo particiona um conjunto
Partindo do pressuposto de que uma organizao de grande de tarefas e produtos de trabalho pelos quais essa funo
porte utiliza um processo padro de desenvolvimento de soft- responsvel.
ware, e que nele so apresentados os controles institucionali- Tambm fornecida orientao sobre como essas funes
zados com seus cenrios, possvel ter a viso compartilhada trabalham em conjunto, em termos das atividades requeridas
sobre como a gesto de projetos percebe os marcos que so para representar o processo configurado, referenciado como
desenvolvidos para um novo produto de software, aferindo o processo de entrega. Alm disso, so fornecidas vrias

Edio 69 - Engenharia de Software Magazine 39


visualizaes com o produto que so Isso ajuda voc a desempenhar a de fluxos de informao. Atravs do
focalizadas em diferentes grupos de pro- sua parte esperada na equipe de pro- Diagrama de Entidade e Relacionamen-
fissionais de engenharia de software. jeto, tornando claro quais so as suas to (DER) so enfatizados os dados e os
Para um profissional de desenvolvi- responsabilidades. relacionamentos entre eles.
mento de software, este ambiente forne- A tcnica de anlise estruturada baseia- Na anlise estruturada os processos
ce uma definio de processo comum e se na decomposio funcional estrutura- mais complexos so decompostos em
central, que todos os membros da equipe da de sistemas atravs de Diagramas de subprocessos constituintes e seus fluxos
de desenvolvimento de software podem Fluxo de Dados (DFDs) que descrevem o de informao, formando-se uma estru-
compartilhar, ajudando a assegurar uma sistema como um conjunto de processos tura hierrquica de processos. Esta me-
comunicao clara e sem ambiguidade funcionais que realizam transformaes todologia fornece um conjunto coerente
entre os membros da equipe. de informao e comunicam-se atravs e integrado de mtodos e regras, que no
seu conjunto formam uma tcnica estru-
turada de anlise e projeto de sistemas
baseada nos seguintes conceitos: aborda-
gem top-down, modelagem funcional,
representao grfica do modelo, dicio-
nrio de dados e a descrio de processos
e procedimentos, alm de trabalho em
equipe e documentao.
Assim, o processo de desenvolvimento
de sistemas na anlise 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, sadas; 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 sada.

Figura 2. Modelo de Desenvolvimento de Sistemas de Software A exibio 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 viso esttica estrutural.
Sob o ponto de vista dinmico, o diagra-
ma de transio de estado define quando
as coisas acontecem e as condies em
que eles acontecem.
A anlise estruturada, de maneira
geral, compreende os processos: Levan-
tamento, Anlise,Projeto, Codificao,
Teste, Implantao e Manuteno. Usu-
almente adota-se uma abordagem em
cascata. Esta abordagem caracterizada
pela existncia de um incio e fim de
cada fase do processo de desenvolvimen-
to, sendo a formalizao do trmino de
uma fase requerida antes que se inicie
a prxima.
Pode ser utilizada quando for possvel
adotar seus mtodos, tcnicas e ferra-
mentas, pelas equipes de desenvolvi-
Figura 3. Rational Unified Process mento, garantindo-se o rigor dos seus

40 Engenharia de Software Magazine - Gesto de Projetos: Usando processos de desenvolvimento


en gen haria

resultados. Alm disso, recomendada quando for possvel a Os controles institucionais definidos pela empresa que
comunicao entre clientes e usurios e a equipe de desenvol- tem como premissa a utilizao de modelos de software so
vimento de forma a se garantir a clareza de ideias e o rigor da eventos fundamentais para o processo de desenvolvimento,
especificao. Isso pressupe uma equipe de desenvolvimento e exigem algum tipo de aprovao de produto ou servem de
capaz, com expertise tcnica e habilidade de comunicao. insumo para uma etapa seguinte e se no realizados, impedem
Deve ser aplicada preferencialmente na construo/manu- a continuidade do processo (ver Figura 5).
teno de sistemas de mdio e grande porte, cujos requisitos se- Esses controles podem significar ainda a gerao de produto
jam relativamente estveis. A metodologia poder ser utilizada explicitamente recomendado, normalmente ligados poltica
no incio de um novo projeto de desenvolvimento de software de segurana da informao ou gesto de conhecimento. Os
e tambm em manutenes eem ciclos de desenvolvimento controles institucionais sempre necessitam de uma evidncia
subsequentes aps a implantao do sistema em produo. de sua realizao.
Alm dos controles instituies, no modelo de desenvol-
vimento existem guias de utilizao padronizados por um
comit de melhoria de processo voltadas para os gestores,
gerentes, desenvolvedores, usurios e demais envolvidos
no processo, trazendo diversas orientaes da estrutura
que podem ser usadas em detrimento de um projeto e/ou
manuteno.
Toda documentao tcnica e gerencial de um projeto e/ou
manuteno produzida durante o processo de desenvolvimen-
to mantida pelas reas de desenvolvimento em repositrio
oficial. Os artefatos tcnicos dos sistemas (ATS) so mantidos
durante todo o ciclo de vida, pois registram a inteligncia do
sistema e sero utilizados e atualizados em todas as manuten-
Figura 4. Analise estruturada es e evolues futuras.

Figura 5. Fluxo dos Controles Institucionais

Edio 69 - Engenharia de Software Magazine 41


Para a construo so utilizadas ferramentas homologadas
Referncias:
pela empresa, a fim de possibilitar a integrao dos modelos e a
viso sistmica dos negcios. Ao longo do projeto/servio, sem- 1. AUGUSTINE, S.; PAYNE, B.; SENCINDIVER, F.; WOODCOCK, S. (2005). Agile
pre que necessrio, refinado e validado junto s equipes. Project Management: Steering from the Edges. Communications of the
A integridade dos artefatos tcnicos de sistema com os ACM, v. 48, n. 12, pp. 85 - 89.
requisitos sempre mantida. Todo projeto/manuteno tem
2. Mary Beth Chrissis, Mike Konrad and Sandy Shrum, CMMI: Guidelines
um responsvel pela gerncia 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. Alm disso, deve-se pro-
mover a prtica do paralelismo de atividades. 3. CMMI Model Componentes Derived from CMMI SE/SW, Version 1.0
Ao longo do projeto e/ou manuteno compete ao lder 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 realizaes 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 so GROUP, 1996, Atlanta. ProceedingAtlanta, 1996.
atualizados e os compromissos assumidos revisados, sempre
5. DeMarco, T. Structured Analysis and System Specification. Prentice-Hall,
que necessrio independente da atividade.
1979.
O objetivo possibilitar que aes 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 validaes/aprovaes sempre que algum
produto, para o qual existam validaes/aprovaes previs- D seu voto em www.devmedia.com.br/esmag/feedback
tas, for atualizado. Os parceiros e o gestor da informao so
Ajude-nos a manter a qualidade da revista!
informados sobre a situao do projeto e/ou sua manuteno,
por meio de pontos de controle estabelecidos em cronograma,
independente da ocorrncia de alteraes.
A gesto de projetos de software tem buscado, atravs de
indicadores de desempenho estipulados pela instituio, a
constante melhoria em seus processos, principalmente os
associados s entregas dentro do prazo estipulado.

42 Engenharia de Software Magazine - Gesto de Projetos: Usando processos de desenvolvimento


Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros

ITIL: Como implantar o gerenciamento de


mudanas

Fique por dentro:


Este artigo analisa o processo de Gerenciamen-
Cristiane Aparecida Lana
to de mudana da biblioteca ITIL (Information
cristiane.lana@ufv.br
Mestranda em Cincia da Computao pela Technology Infrastructure Library), elencando
Universidade Federal de Viosa (UFV). Espe- os impactos e benefcios de sua implantao
cialista em Gesto Estratgica de Pessoas pela em Microempresas e Empresas de Pequeno

A
FACISA - UNIVIOSA (2012) e Bacharel em Sis- complexidade dentro da rea Porte de Tecnologia da Informao. A ITIL for-
temas de Informao pela Faculdade de Viosa
de Tecnologia da Informao nece um conjunto coerente e compreensivo de
(2008). Atualmente atua como orientadora de
trabalhos de Graduao na Faculdade de Viosa (TI) crescente. Juntamente, melhores prticas para gesto de servios de
e ps-graduao Lato Senso pela FACISA - UNI- os nmeros de mudanas oriundos das TI, provendo qualidade tcnica para realizar
VIOSA. Tem experincia na rea de Sistemas alteraes do mercado, das tecnologias negcios com eficincia e efetividade no uso
de Informao com nfase em Engenharia de e das necessidades dos prprios clientes de sistemas da informao. Este artigo til
Software, Engenharia de Requisitos e Repre-
e at mesmo da organizao, vem au- para organizaes que desejam implantar ou
sentao do Conhecimento, Sistemas de Apoio
Deciso e Gesto de Pessoas. mentando proporcionalmente. Com essa aprimorar o processo de gerenciamento de mu-
constante transformao a TI precisa ser danas utilizando as boas prticas da biblioteca
dinmica, eficaz e eficiente e os servios ITIL. Sua utilizao ir assegurar que os proces-
Bruno Torres Satler relacionados precisam ser oferecidos sos sofram modificaes planejadas, garantin-
bruno@cientec.net
com qualidade, de forma estvel e con- do menor impacto nos servios/processos que
Mestre em Cincia da Computao - Engenha-
ria de Software pela Universidade Federal de fivel. Porm, o conhecimento detalhado passaro por modificaes.
Viosa (2010). Bacharel em Cincia da Com- e a identificao das mudanas no
putao pela Universidade Federal de Viosa uma tarefa simples de ser executada por
(2007). Consultor implementador Melhoria Microempresas e Empresas de Pequeno objetivo satisfazer uma ou mais neces-
de Processo de Software - MPS-Br. Professor
Porte, que muitas vezes demonstram sidades da rea de negcio e suportar
Assistente - FDV Faculdade de Viosa. Professor
Assistente - FACISA Univiosa. Gerente de Proje- falta de estruturao dos processos e os objetivos estratgicos do negcio da
tos e Analista de Processos - Cientec Consultoria pouco conhecimento de metodologias organizao e do cliente.
e Desenvolvimento de Sistemas. Professor da de governana de TI. Porm, para que a TI satisfaa as ne-
ps-graduao Lato Sensu em Sistemas de Os servios de TI podem ser vistos cessidades da organizao preciso
Informao - FACISA-Univiosa. Professor da
como um conjunto de recursos, TI e no que ocorra um alinhamento entre os
ps-graduao Lato Sensu Especializao em
Sistemas para Internet - UFV. TI, mantidos por um provedor de TI, cujo recursos tecnolgicos da TI com os

Edio 69 - Engenharia de Software Magazine 43


interesses da organizao, onde um complemente o outro no
Cenrio Anterior Cenrio Atual
alcance de seus objetivos e principalmente no comprimento da
sua misso da organizao. Para que este alinhamento ocorra Atendimento do usurio Atendimento ao cliente
necessrio que a TI fornea servios que estejam de acordo Perspectiva interna Perspectiva externa
com as necessidades estratgicas do negcio. Com isso, a TI Esforo pessoal Esforo repetitivo e medido
confronta as limitaes ligadas s prprias operaes do neg-
Foco na tecnologia Foco no processo
cio e respondendo com inovaes que sejam ao mesmo tempo
eficientes e estratgicas. Com esse alinhamento, a TI passa a ser Processos ad-hoc Processos racionalizados
considerado um parceiro estratgico dentro da organizao, se Recursos internos Recursos racionalizados
tornando um diferencial competitivo da empresa. Comportamento reativo Comportamento proativo
Assim, a governana de TI deixa a condio de desejvel
Viso fragmentada Viso integrada
para o status de essencial aos negcios da empresa. Devido
a isto, os auditores das corporaes passaram a adotar algu- Sistema manual Sistema automatizado
mas metodologias de governana de TI, como a metodologia Gestor de operaes Gestor de servios
ITIL Information Technology Infrastructure Library, com a
finalidade de melhorar o desempenho desta rea. Tabela 1. Modificaes entre o cenrio anterior versus o atual
O ITIL foi desenvolvido na dcada de 1980, pelo Office Go-
vernment of Commerce Britsh - OGC, inicialmente como um Para que as modificaes dos cenrios ocorram com sucesso
guia do governo britnico para gesto de servios. Com suas necessrio que acontea uma modificao, uma transformao
evolues, atualmente a ITIL parte da norma ISO 20000 (in- das convices, do conhecimento e at mesmo da expectativa
ternational Organization for Standardization, ou Organizao do profissional de TI, o que pode proporcionar uma mudana
Internacional para Padronizao), um padro internacional de comportamento e maior comprometimento.
para gesto de servios de TI. O Gerenciamento de servios de TI uma srie de conceitos
A ITIL fornece um conjunto coerente e compreensivo de que identificam e inter-relacionam as vrias atividades envolvi-
melhores prticas para gesto de servios de TI, provendo das no desenvolvimento de um ambiente que produz melhoria,
qualidade tcnica para realizar negcios com eficincia e mtricas e entrega de servios de TI para os clientes e para a
efetividade no uso de sistemas da informao. As prticas comunidade de usurios de TI. Ele integra pessoas, processos
desta metodologia so baseadas na experincia de empresas e tecnologias necessrias na busca de viabilizar a entrega do
comerciais e governamentais de todo o mundo, as quais tm servio de TI garantindo o alinhamento estratgico de negcio
se tornado cada vez mais dependente de TI. da organizao. Contudo, de extrema importncia para as
Uma mudana pode aparecer devido a um incidente organizaes saber de onde esto saindo e onde querem che-
ou devido a aes proativas para beneficiar o negcio da gar e como chegar. A Figura 1, conhecida como Fronteira da
organizao, como a reduo de custos ou a melhoria dos Eficincia, mostra o curso do processo onde existe um ponto
servios. Seu gerenciamento procura minimizar o impacto de sada (ponto A) e um ponto de chagada desejado (ponto A),
das mudanas causadas por incidentes e melhorar as opera- para se locomover de um para o outro de forma apositiva
es da organizao atravs das mudanas proativas. Para necessrio manter a prestao de servio em um nvel elevado
isso, padroniza mtodos e procedimentos para um controle com um baixo custo. esse equilbrio aliada as estratgias e
eficiente das mudanas. metas que far com que a organizao saa de um gerencia-
mento de servios catico para um equilibrado.
Gerenciamento de Servios de TI
Antes de iniciar o processo de gerenciamento de servios
de TI preciso garantir o alinhamento entre o que ser ofe-
recido pela TI com o negcio da organizao. Essa tarefa no
simples, pois necessrio garantir alinhamento estratgico
visando a gerao de valor para a organizao, maximizando
o aproveitamento de novas oportunidades e a reduo dos
custos. Diante dessa necessidade, a rea de TI precisa entender
que os clientes atuais querem mais que produtos, eles querem
servios que agregam valor. Sendo assim, a rea de TI precisa
ir alm de prestao de servio entregue s organizaes, ela
precisa determinar qual o valor do servio perante a estratgia
de negcio, garantir que os servios sero entregues dentro do
padro de qualidade exigido pelos clientes e pelos usurios.
A Tabela 1 mostra os principais conceitos que foram modifi-
cados e quais esto vigentes no cenrio atual. Figura 1. Fronteira de Eficincia

44 Engenharia de Software Magazine - ITIL: Como implantar o gerenciamento de mudanas


en gen haria

O gerenciamento de mudanas pode


ser aplicado a qualquer tipo de orga-
nizao, pequena ou grande, pblica
ou privada, com servios de TI, cen-
tralizado ou descentralizado, interno
ou outsourced, permitindo coordenar
o fornecimento e suporte de servios
de TI destinados a preencher as neces-
sidades da organizao. Alm disso, a
abordagem mais conhecida para se fazer
o gerenciamento de servios em TI a
ITIL, pois esta explora as relaes entre
as atividades nos processos pertinentes
a qualquer organizao.

Information Technology
Infraestructure Library - ITIL
A ITIL (Information Technology In-
frastructure Library) um conjunto de
padres de melhores prticas para o Figura 2. Processo do ITIL
gerenciamento de servios de Tecnologia
da Informao. Esta metodologia oferece os processos do ITIL subdivididos em: 3. Gerenciamento de Configurao:
uma descrio detalhada das importan- Gerenciamento de Aplicaes, Gerencia- responsvel por fornecer organizao
tes prticas de TI, incluindo checklists, mento de Servios, Gerenciamento da de TI um controle maior sobre todos os
tarefas, procedimentos e responsabi- Infraestrutura, Gerenciamento de Ca- seus ativos;
lidades. Estas prticas so definidas nais de Suprimento, Gerenciamento de 4. Gerenciamento de Incidente: seu foco
como processos e podem ser adaptadas Segurana e Gerenciamento de Infraes- principal restabelecer o servio o mais
a qualquer organizao de TI cobrindo trutura de Tecnologia de Comunicaes rpido possvel, minimizando o impacto
a maioria de suas atividades. e de Informao (TCI). negativo no negcio;
Criada na dcada de 80 pelo Centro Como pode ser visto na figura, alm da 5. Gerenciamento de Liberao: respon-
de Computadores e Agncia de Teleco- definio do negcio, dos parceiros e da svel pela implementao das mudanas
municaes CCTA do Reino Unido, tecnologia a ser usada ou implementada, no ambiente de infraestrutura de TI;
atualmente conhecido como Office of existem diversos processos que devem 6. Gerenciamento do Nvel de Servio:
Governamment Commerce OGC, teve ser analisados e implementados que responsvel por gerenciar o nvel dos
por objetivo padronizar e comparar as so indispensveis para o sucesso do servios prestados pela equipe de TI,
diversas propostas de prestadores de processo. com o objetivo de definir o tempo de
servios de TI ao governo Britnico. A Alm do processo de Gerenciamento de resoluo para cada solicitao realizada
metodologia foi desenvolvida a partir Mudanas, que abordaremos neste arti- pelos clientes e tempo para restabeleci-
de pesquisas realizadas por consultores, go, a ITIL conta com mais dez processos mento de cada indisponibilidade ocor-
especialistas e doutores na rea, para que podem ser implementados de forma rida na operao;
desenvolver as melhores prticas para isolada nas organizaes, so eles: 7. Gerenciamento de Capacidades: dese-
a gesto de TI nas empresas pblicas e 1. Service Desk: ponto nico de contato nhado para assegurar que a capacidade
privadas. Seu foco est na descrio dos entre usurios/clientes e o departamento da infraestrutura de TI esteja alinhada
processos necessrios para gerenciar de TI; com as necessidades do negcio;
eficientemente e eficazmente a infra- 2. Gerenciamento de Problemas: res- 8. Gerenciamento de Disponibilidade:
estrutura de TI garantindo os nveis ponsvel por minimizar a interrupo visa otimizar a capacidade da infraestru-
de servio acordados com os clientes nos servios de TI por meio da organi- tura de TI ajudando a organizao a en-
internos e externos. zao dos recursos para solucionar pro- tregar um nvel sustentado de disponibi-
Na dcada de 90, a ISO 9000 e o modelo blemas de acordo com as necessidades lidade a um custo aceitvel, garantindo
de referncia da EFQM (European Foun- de negcio, prevenindo a recorrncia e que os servios estaro disposio dos
tation for Quality Management) passam garantindo o registro de informaes clientes e usurios sempre que for preci-
a adotar as melhores prticas da ITIL que melhore a maneira pela qual a so e permitindo assim que os objetivos
tornando-a um padro mundialmente organizao de TI trata os problemas, do negcio sejam alcanados;
conhecido e a metodologia de servios de resultando em nveis mais altos de dis- 9. Gerenciamento da Continuidade
TI mais utilizada. A Figura 2 apresenta ponibilidade e produtividade; dos Servios de TI: tem por objetivo

Edio 69 - Engenharia de Software Magazine 45


suportar de forma geral o Gerenciamento de Negcios, as- Garantir a utilizao dos mtodos padronizados para o
segurando que os requisitos tcnicos da TI e facilidades de tratamento eficiente de todas as mudanas, reduzindo seus
determinados servios possam ser recuperados dentro de riscos e impactos;
escalas de tempo requeridas e acordadas; e Minimizar o surgimento de incidentes que tenham relao
10. Gerenciamento Financeiro: responsvel por determinar com alguma mudana;
o verdadeiro custo de todos os servios de TI e demonstr-lo Realizar o balano entre a necessidade e o impacto.
de maneira que a organizao possa entend-lo e utiliz-lo
para o processo de tomada de deciso. Segundo a prpria OGC, este processo tem foco nas mu-
danas que afetam Hardware, Software, Equipamentos e
Fica fcil entender que as melhores prticas adotadas pelo Software de Comunicao; aplicaes em produo e toda
ITIL abrangem todas as atividades da rea de TI. Usando documentao e procedimentos associados com a operao,
uma abordagem de processo, a ITIL define principalmente suporte e manuteno da Infraestrutura de TI. Alm disso,
o que deve ser includo no Gerenciamento em Servios ficam fora do escopo do gerenciamento, mas relacionados com
em TI para que se oferea um servio de qualidade (veja a este as mudanas em projetos; a identificao de componentes
seo Links). afetados na mudana ou atualizao de registro (Gerencia-
mento de Configurao) e a liberao de novos componentes
Gerenciamento de Mudanas (Gerenciamento de Liberaes).
Comumente, as mudanas surgem como resultado para os A Solicitao de Mudana (Request for Change RFCs)
problemas, embora muitas mudanas possam ser efetivadas o ponto de partida de todo o processo de Gerenciamento de
com o objetivo de trazer benefcios empresariais ou melhorar Mudana. Ela consiste da solicitao inicial da mudana,
os servios oferecidos. A finalidade da realizao do processo por parte dos usurios, reas de negcio e membros das
de Gerenciamento de Mudanas alcanar esses objetivos uni- equipes dos processos de Gerenciamento de Incidente e de
ficando mtodos e procedimentos com o intuito de controlar Gerenciamento de Problema, sendo estes dois ltimos os
e manipular de forma eficiente todas as mudanas, minimi- principais promotores de mudanas em um ambiente de
zando o impacto de incidentes que j tenham sido vivenciados infraestrutura de TI.
anteriormente, e consequentemente melhorar as operaes do Todas as mudanas devem ser revistas aps um perodo
dia a dia da organizao. pr-estabelecido a fim de garantir que os resultados foram
O aumento da importncia da rea de TI vem crescendo alcanados e analisar o grau de eficincia na estimativa de
aceleradamente e junto com ela as exigncias de qualidade, recursos utilizados.
reduo de tempo de atendimento e custo, etc. visando alcan-
ar os objetivos do negcio. Dentro deste contexto, preciso Benefcios do sistema de Gerenciamento de Mudanas
vislumbrar uma forma de acompanhar as mudanas da rea Os benefcios especficos do processo de Gerenciamento de
de TI e a evoluo do cenrio de negcios. Mudanas descritos pela ITIL so:
Todas as mudanas, incluindo as de emergncia e aplicao Melhor alinhamento dos servios de TI com os negcios.
de patches, relacionadas infraestrutura e aplicaes dentro Aumento da visibilidade e comunicao das mudanas entre
do ambiente de produo, devem ser gerenciadas formal- seus atores.
mente de maneira controlada. Estas mudanas (incluindo Melhoria no processo de avaliao de riscos, reduzindo o
procedimentos, processos, sistemas e parmetros de servi- impacto negativo da mudana.
o) devem ser registradas, avaliadas e autorizadas antes da Melhor avaliao de custos das mudanas.
implementao. Reduo do nmero de mudanas que necessitem da execu-
O Gerenciamento de Mudanas considerado um tanto o dos seus planos de retorno ao original (backout).
quanto burocrtico. Isso se deve a exigncia de todos os in- Melhor identificao dos problemas.
cidentes ser identificados, antes de serem corrigidos, devem Aumento na produtividade dos usurios, com a reduo das
ser filtrados, analisados e testados para depois ser implemen- paradas de servios de TI.
tada as correes no ambiente de produo. Para isso, se faz Aumento de produtividade de pessoal da rea de TI, pela
necessrio uma mudana de cultura e um comprometimento maior fidelidade s aes que so planejadas.
de todos para o processo lograr xito. Habilidade de absorver um grande volume de mudanas.
Sua misso gerenciar todas as mudanas que de alguma Um aumento da percepo dos valores do negcio, por parte
forma possam causar impacto na entrega de servios pela da equipe de TI, resultando em melhoria na qualidade dos
rea de TI, atravs de um processo nico e centralizado de servios de TI.
aprovao, programao e controle da mudana, assegurando
que a infraestrutura e a rea de TI permaneam alinhadas aos Detalhamento do Processo
requisitos do negcio, com o menor risco possvel. O processo de Gerenciamento de Mudanas responsvel por
A seguir esto listados os principais objetivos do Gerencia- decidir e coordenar as mudanas no tendo como objetivo dire-
mento de Mudanas, de acordo: to executar a implementao. A implementao ser realizada

46 Engenharia de Software Magazine - ITIL: Como implantar o gerenciamento de mudanas


en gen haria

por uma equipe tcnica responsvel pela


rea de mudana, como a rea de redes,
sistemas, hardware.
Este processo controlar as mudanas
para que elas sejam implementadas de
forma eficaz, no que se refere ao custo,
com um mnimo de riscos para os servi-
os mantidos. Para a elaborao de uma
anlise de riscos adequada importante
o uso de uma Base de Dados do Geren-
ciamento de Configurao, pois este ir
fornecer todos os servios e recursos
relacionados ao item de configurao
que sofrer a mudana.
As principais entradas e sadas do pro-
cesso de Gerenciamento de Mudanas
so mostradas na Figura 3.
Como pode ser visto na figura, as Figura 3. Entradas e Sadas do Processo de Gerenciamento de Mudanas
principais entradas dos processos RFCs
(Request for Change) o Requisies de
Mudanas - RDM, FSC (Forward Sche-
dule of Changes) a Programao Futura
de Mudanas - PFM, o agendamento das
prximas mudanas; e por fim o CMDB
que recebe informaes do processo de
Gerenciamento de Capacidade, Con-
figurao e Liberaes para realizar a
anlise de riscos, planejamento e custos.
No que tange s sadas tem-se a PFM
Programao Futura de Mudanas, RDM
Requisies de Mudanas Aprovadas
e Atas da Reunio do CCM Conselho
de Controle de Mudanas.
Apesar do Gerenciamento de Mudan-
a possuir uma estrutura slida, no
possvel que ele seja implementado sem
considerar o entorno, principalmente os
projetos que podem sofrer alteraes ao Figura 4. Integrao dos Processos de Gerenciamento de Mudanas e Gerenciamento de Projetos
longo de seu percurso. Sendo assim, a
Figura 4 mostra como ocorre a interao
entre o Gerenciamento de Mudanas e o em processos anteriores, como o Geren- Aprovao
de Projetos. ciamento de Problemas, por exemplo. Todos os RDMs devem ser filtrados e
possvel perceber que em todas as fa- A RDM poder ser em papel ou ele- aprovados mas alguns fatores podem
ses do projeto podem ocorrer mudanas trnica atravs de algum software de determinar que uma mudana seja
e que o gerenciamento intervm de for- Gerenciamento de Servios. recusada, por exemplo, se o custo da
ma a minimizar os impactos e controlar mudana mais alto que o benefcio que
os pontos de mudanas existentes que Registro e Classificao ela pode oferecer.
modificaram o projeto original. Diversas informaes para a tomada
de deciso devem estar contidas em Coordenao do Desenvolvimento
Registro de Requisio de um RDM, tais como categoria, impacto Aps aprovada a mudana, a RDM
Mudana RDM e custo. A partir destas ser elaborado deve ser passada a um grupo tcnico
O Registro de Requisio de Mudanas o relatrio gerencial e a cada mudana que ser responsvel pelo desenvolvi-
(RDM) pode ser levantado a partir de deve ser associada ou alocada sua priori- mento da mudana. O Gerenciamento
uma necessidade do setor de TI, ou sur- dade para definir a agenda de mudanas de Mudanas deve coordenar todo este
gir em virtude de um erro identificado programadas. processo, garantindo assim, a existncia

Edio 69 - Engenharia de Software Magazine 47


dos recursos necessrios, monitorando os riscos e acompa- de Problemas tambm pode vir a acompanhar este processo.
nhando os testes. Esta reviso se destina a verificar se a mudana trouxe os resul-
tados esperados, ou caso haja algum problema ou ineficincia,
Autorizao e Implementao aes devem ser tomadas para a sua correo.
Aps passar pela fase de desenvolvimento, as mudanas A Figura 5 mostra o fluxograma que explica o que ocorre
devem ser testadas antes de ir para o ambiente de produo. numa RDM, mostrando o inicio da requisio ate a avaliao
aconselhvel que exista um grupo de testes independente final fechando a mudana requisitada.
neste processo, que tenha condies tcnicas para elaborar o
plano de testes avaliando todos os requisitos para o funcio- Comit de Controle de Mudana CCM
namento da mudana no ambiente de produo e s aps o O Comit de Controle de Mudana (CCM) responsvel pela
resultado dos testes que a mudana ser autorizada para ser avaliao do impacto das mudanas. Este grupo ser compos-
implementada. to de pessoas tcnicas e at mesmo clientes, que fornecero
assessoria ao Gerente de Mudanas sobre quais mudanas
Implementao devem ser aprovadas e auxiliaro na programao das mu-
O Gerenciamento de Mudanas deve garantir que as mudan- danas. Normalmente, o CCM se rene com uma determina
as sejam implementadas seguindo um programa definido. A frequncia para discutir todas as mudanas novas e que ainda
execuo da implementao no de responsabilidade deste esto em andamento.
processo, ficando o seu cargo apenas a coordenao. O processo
de Gerenciamento de Liberaes poder ser coordenado pelo Comit de Emergncia CCM/CE
processo de Gerenciamento de Mudanas, pois as mudanas Quando surgem problemas mais graves necessrio iden-
de fato acabam gerando novas liberaes de software ou de tificar uma configurao menor com autoridade para tomar
hardware. decises emergenciais, pois pode no haver tempo para se
criar um CCM completo, sendo o presidente deste comit o
Avaliao Gerente de Mudanas, que so os tcnicos responsveis pela
O Gerenciamento de Mudanas deve avaliar todas as mudan- implementao da mudana. Dependendo da criticidade da
as implementadas depois de determinado perodo, chamada mudana, determinada por essa equipe uma rpida alterao
de Reviso Ps-Implementao. O processo de Gerenciamento no ambiente para que a soluo seja imediata.

Figura 5. Exemplo do processo de Gerenciamento de Mudana

48 Engenharia de Software Magazine - ITIL: Como implantar o gerenciamento de mudanas


en gen haria

Programao de Futuras Mudanas


FPM
A Programao Futura de Mudanas
(FPM) responsvel por manter atu-
alizados os detalhes de todas as mu-
danas que tm sido autorizadas para
implementao dentro de um perodo
previamente estabelecido, ou seja, o
cronograma para alterao no ambiente
equivale ao grau de risco que a mudana
pode oferecer. Se a mudana tiver um n-
vel crtico muito alto, o tempo para pla-
nejamento ser maior. Um bom exemplo
seria uma empresa que por problemas
tcnicos precisa trocar o seu servidor, e Figura 6. Relacionamento do processo de Gerenciamento de Mudana com outros processos da ITIL
no momento da troca sero desligados
todos os computadores, neste caso, sero envolvidas vrias garantir que ele reflita os objetivos organizacionais, alm de
reas da empresa, tais como: infraestrutura e TI. Haver um serem quantificveis (veja a seo Links).
tempo para cada rea planejar sua execuo, no entanto um
tempo maior exigido para execuo da Mudana. Problemas Potenciais do Gerenciamento de Mudanas
A seguir, esto descritos possveis problemas que podem ser
Relacionamento com outros Processos enfrentados pelo processo de Gerenciamento de Mudana:
O processo de Gerenciamento de Mudanas est relacio- O escopo de uma mudana pode ser muito grande para os
nado com outros processos da ITIL, como pode ser visto na recursos disponveis, pode sobrecarregar os recursos e gerar
dependncia da preciso dos dados de configurao com a atrasos;
preciso do processo de Gerenciamento de Liberao para Falta de clareza nas propriedades dos sistemas impac-
assegurar o conhecimento sobre o impacto completo em se tados;
aplicar a mudana no ambiente de trabalho. Caso o processo de Gerenciamento de Mudanas seja imple-
Outros processos podem relacionar-se com o Gerenciamento mentado sem o processo de Gerenciamento de Configurao,
de Mudanas, pois eles podem requisitar tambm mudanas possivelmente a soluo ser menos efetiva;
(Gerenciamento de Disponibilidade) ou podem ser consulta- A burocratizao do processo, fazendo com que no seja
dos para determinar o impacto da mudana (Gerenciamento seguido;
da Continuidade dos Servios de TI, Gerenciamento do Nvel Dados sobre os CIs (Itens de configuraes) incorretos podem
de Servio e Gerenciamento da Capacidade - Figura 6). resultar em avaliao de impacto incorreta;
A Figura 6 mostra que o processo de mudana ocorre de Deficincia na atualizao entre plataformas e localidades faz
forma interativa, sendo que a qualquer momento pode surgir com que seja difcil ou quase impossvel agendar mudanas;
uma necessidade especfica nos mais diferentes mdulos do Procedimentos de contingncia que no existem ou no
processo geral do ITIL e este deve ser analisado e suprido de foram testados;
acordo com as diretrizes aprovadas pela organizao. O acompanhamento de progresso das mudanas manual,
o que gera sobrecarga em quem o executa;
Indicadores de Desempenho KIP (Key Performance As faltas de acompanhamento da alta e mdia gerncia fazem
Indicator) os tempos de implementao crescer, e h uma resistncia
O processo de Gerenciamento de Mudanas deve conter aos novos controles, a menos que veja comprometimento dos
mecanismos de controle que permitam avaliar sua eficincia, gerentes;
eficcia, efetividade e economicidade. Para isso, so utilizados Mudanas de emergncia frequentemente provocam a falha
os Indicadores de desempenho, tambm chamados de Indica- do processo
dores Chave de Desempenho (ou Key Performance Indicator
KPI em ingls) que servem para avaliar e medir o nvel de Detalhamento das Fases
desempenho de processos chaves para a empresa. As mudanas podem ocorrer de forma programada, ace-
O KIP uma medida quantificvel que tem como funo lerada ou emergencial. Para efeito de definio, mudanas
refletir os fatores crticos de sucesso da organizao que varia Programadas, Aceleradas ou Emergenciais seguem o
de uma organizao para outra. Uma empresa pode ter como mesmo procedimento, sendo que, os parmetros de tempo
KIP os percentuais de sua receita que vem do retorno dos devem atender as necessidades especficas de cada tipo.
clientes, uma escola pode set seu KIP no nmero de alunos A programada exige um conhecimento prvio da necessidade
graduados, etc. Independente do KIP selecionado preciso no exigindo urgncia para sua execuo.

Edio 69 - Engenharia de Software Magazine 49


Portanto, segue o processo normal de Gerncia de Mudanas. com parcerias para distribuio nacional e internacional. Aps
Aceleradas, as mudanas que necessitam ser executadas o mais 15 anos de existncia, a empresa vem fidelizando, de forma
rpido possvel seguindo o processo normal da solicitao, por progressiva, seu mercado consumidor e sua linha de produtos,
necessidade tcnica ou de negcios da empresa estudada. oferecendo sempre aos seus clientes produtos de qualidade e
Emergencial, a mudana vital para atender uma necessida- que os auxiliem em sua trajetria de sucesso.
de de negcio, normalmente para correo de um problema,
e que no pode aguardar o processo normal de mudanas, Cenrio Atual
particularmente na reviso e fase de aprovao, onde existe Atualmente a empresa possui um gerente para cada setor
o risco iminente para os negcios, ativo ou processos da em- (administrativo, vendas, suporte ps-vendas, departamento
presa estudada de TI e nutricional) e um gerente geral.
Qualquer evento que ocorra no ambiente de tecnologia e que Toda e qualquer solicitao de mudanas feita sem passar
no possua uma Mudana registrada deve ser enquadrado por qualquer processo. O solicitante interessado em uma mu-
como Incidente Tcnico no controlado e o processo de dana entra em contato com o membro da equipe de TI e infor-
comunicao devem abranger as reas de negcio de toda a ma seu interesse solicitando sua execuo. Este procedimento
empresa estudada. em sua maioria das vezes acarreta a realizao de mudanas
A metodologia recomentada pela ITIL para realizao do pro- sem retorno e com altos ndices de impactos negativos.
cesso de melhoria contnua dos servios de TI PDCA ((P(Plan Tais solicitaes por serem feitas sem nenhum monitoramen-
= Planejar) D(Do = Executar) C(Check = Verificar) A (Action to, podem propiciar o no atendimento de uma mudana que
= Agir)) que se baseia no controle de processos. Desenvolvido seja prioritria para a organizao, por exemplo, para a organi-
na dcada de 30 e utilizado pela indstria manufatureira, zao em anlise todas as aplicaes web so de fundamental
o PDCA composto por quatro passos: 1) Plan Planeja as importncia, tais como: instabilidade do servidor, necessidade
aes a serem executadas; 2) Do realiza as aes que foram de melhoria de uma aplicao para atendimento de um dado
planejadas; 3) Check Verifica se o que foi feito esta de acordo setor, como busca e listagem de cursos no sistema. Contudo,
com o planejado; e por fim 4) Act que Atua corretivamente por no possurem um sistema de gerenciamento de mudanas
sobre a diferena identificada. Seu maior objetivo manter os a aplicao web pode deixar de ser atendida em detrimento de
clientes e mant-los satisfeitos. outra solicitao de menor importncia. Isso ocorre porque no
existe nenhum software de controle de solicitaes implantado.
Descrio do Estudo de Caso : A organizao Assim, as solicitaes de mudana chegam por e-mail, telefone
Para anlise do processo de gerenciamento de mudanas, ou por meio do famoso boca a boca, que na maioria no ficam
buscou-se um estudo de caso: uma Empresa de Pequeno Porte registrados, afetando o planejamento do gerente de projetos,
do ramo de tecnologia de informao situada na Zona da Mata gerente de TI que somente fica sabendo que a solicitao existe
Mineira. Sua misso Transformar conhecimentos gerados aps a sua execuo. Desta forma, os problemas que existem
em universidades e centros de pesquisas em solues para a no cenrio atual so:
sociedade e assim busca ser reconhecida pelo mercado como Ausncia de documentao para formalizar uma solicitao
empresa inovadora que desenvolve produtos e solues com de mudana;
qualidade mundial. Descentralizao das solicitaes de mudanas;
Fundada em 1997 na incubadora da base tecnolgica do Ausncia de filtro de prioridade para execuo de
CENTEV da Universidade Federal de Viosa (MG), a empresa mudanas;
se posiciona no mercado como um elo importante entre a pes- Falta de prazo limite para aprovao da solicitao.
quisa cientfica e a sociedade, buscando propor solues para
o gerenciamento de informaes para diversos profissionais Gerenciamento de Mudana na Organizao
que buscam a otimizao do tempo e capacitao profissional O processo de Gerenciamento de Mudana na organizao
de qualidade. tem por objetivo manter o controle das mudanas na rea de TI,
Na busca de melhorar a qualidade de seus produtos e servios de uma forma documentada, processual e controlada, visando
e desejando aprimorar, a cada dia seus conhecimentos, a em- minimizar ao mximo os impactos negativos. Com isso, faz-se
presa implantou o programa SEBRAE de Gesto da Qualidade necessrio o apoio de um processo de Gerenciamento de Con-
(PSGQ), processo no qual obteve 100% de aprovao. figurao eficiente, que oferea uma CMDB (Banco de Dados
Em 2010, a empresa passou por novas expanses, iniciando o do Gerenciamento da Configurao) atualizada, uma vez que
desenvolvimento de cursos online para capacitao profissio- o registro dos CIs (Item de Configurao) compem quais ser-
nal em diversas reas de atuao, aplicativos mveis e forman- vios de TI so de responsabilidade daquele processo.
do uma importante parceria com a empresa Aoki Sistemas para Analisando a empresa, verificou-se que a mesma possui
a comercializao do E2corp, que um promissor Sistema de um software para a realizao das interaes pertinentes aos
Gesto Empresarial (ERP - Enterprise Resource Planning). processos, chamado de Help Desk. Todos os setores da em-
Com o sucesso dos cursos online, a empresa iniciou, em 2012, presa podem se comunicar atravs desse software com envio
o desenvolvimento e comercializao de e-books, contando de chamados especfico para cada setor. Porm, atualmente a

50 Engenharia de Software Magazine - ITIL: Como implantar o gerenciamento de mudanas


en gen haria

organizao no possui um Service Desk estruturado, ficando requisio de mudanas, agora aprovada, chega novamente s
sem um ponto central de contato entre os usurios e a rea mos do gerente de mudanas que inicia a fase de coordenao
de TI. e desenvolvimento.
O objetivo do processo definir os papis e responsabilida- Na fase inicial de coordenao e desenvolvimento, deve-se
des, processos e o fluxo padro a serem utilizados para todas identificar se a RDM tem urgncia alta ou impacto mnimo.
as solicitaes, para que haja o controle integrado de mudanas. Caso a RDM se enquadre em uma destas duas formas, a fase
O controle integrado de mudanas compreender a identifi- de autorizao pode ser deixada de lado e passar direto para
cao, documentao, anlise e autorizao das mudanas, a fase de implementao.
tendo como critrios de avaliao para aprovao o escopo, Toda mudana deve ser testada nas atividades ao final da fase
custo de execuo e prazo previamente autorizados para cada de autorizao e na atividade de avaliao, antes de ser enviada
solicitao de mudanas, sendo classificadas em trs tipos de para o ambiente de produo. importante que exista uma
mudanas, normal, padro e emergencial. equipe de testes para elaborao do plano de testes avaliando
A normal a mudana planejada com antecedncia. A padro o funcionamento aps realizao da mudana.
por sua vez uma mudana rotineira e de baixo impacto, por Na fase de autorizao a equipe de testes ir acompanhar
exemplo, a mudana de senhas, alterao de cursos, modifi- como est o planejamento de execuo das mudanas e, ao
cao de arquivos para licitao. J a emergencial, aquela obter resultados satisfatrios por meio de testes, a mudana
mudana vital que surge para atender uma necessidade ou ser autorizada a passar para a fase de implementao que
sanar um incidente ocorrido. Esse tipo de mudana no ne- tem como objetivo apenas executar a solicitao de mudanas
cessita passar pela fase de autorizao indo direto para a fase conforme a coordenao do gerente de mudanas. Nesta fase
de implementao. so gerados os relatrios de testes realizados.
O enquadramento de cada solicitao de mudanas auxilia O gerente de mudanas ir coordenar a execuo durante a
na coordenao da implementao. O plano de gerenciamento fase de implementao, ficando a cargo da equipe de desen-
de mudanas no tem como objetivo executar a implementa- volvimento executar o plano de desenvolvimento informar se
o das mudanas sendo apenas responsvel por decidir e existem alteraes crticas para que elas sejam autorizadas e
coordenar o processo de mudanas. A implementao ser novamente implementadas. No havendo alteraes inicia-se
realizada pela equipe de desenvolvimento. Assim, necessrio a fase de avaliao.
a definio dos papis e responsabilidades de cada participante A fase de avaliao tem como objetivo, revisar todo o escopo
da equipe. de acordo com o que foi implementado. Assim, ser possvel
As solicitaes de mudanas devem seguir um roteiro padro, verificar se a mudana foi realizada como esperado ou se re-
onde cada solicitante deve registrar sua solicitao por meio de sultou outros erros inesperados e quais aes a serem tomadas
um formulrio que por sua vez deve ser enviado ao gerente de para a correo. No ocorrendo a rejeio, a mudana entra em
mudanas. Neste momento cria-se o registro de solicitao de produo e formalizada a entrega da solicitao de mudana
mudanas RDM, o qual fica a cargo do gerente de mudanas, como executada e aprovada para o solicitante.
atribuir uma identificao nica para cada solicitao. O ideal
que esses registros sejam individuais evitando a sobreposio Planejamento de Mudana
de registros. O primeiro passo do planejamento para implantao do
Na fase de registro e classificao vrias informaes sero processo de Gerenciamento de Mudanas da ITIL escrever
utilizadas para a tomada de deciso, tais como categoria, im- o documento da metodologia no qual ser formalizado: Solici-
pacto, custo. Estas informaes tambm sero utilizadas para taes de Mudanas, Planejamento das Atividades, Avaliao
produzir relatrios gerenciais, onde a RDM ser classificada de Riscos, Avaliao de Impacto, Registro de Envolvidos, Fluxo
de acordo com a prioridade para cada mudana para definir de Comunicao, Definio e Homologao das Contingncias,
o tipo de mudana a qual se encaixa. Definio e Homologao de Planos de Retorno entre outros.
O comit, por meio do relatrio gerencial, deve filtrar a soli- Esse documento ter que ser escrito pelo gerente responsvel
citao no incio da atividade de classificao, para saber se a pelas mudanas, juntamente com outros gerentes de outros
solicitao pertinente. Caso no seja, ser encaminhada para setores da empresa.
o gerente de mudanas para que possa informar a recusa da Para implantar o plano de gerenciamento, a fase inicial ser
solicitao ao solicitante por meio do documento de registro de composta de reunies com todos os membros para explicar
encerramento da solicitao. Caso a solicitao seja pertinente, os objetivos esperados, quais sero os papis de cada um e
o comit deve classific-la em um dos trs tipos de mudanas: suas respectivas responsabilidades, alm de inserir o fluxo de
normal, padro ou emergencial. gerenciamento de mudanas. Aps as definies iniciais, ser
Aps as RDMs serem classificadas e filtradas, elas devem disponibilizado o treinamento sobre a nova forma de gesto
ser aprovadas. Na fase de aprovao o comit se rene com o de mudanas, detalhando o objetivo e execuo das fases que
gerente de mudanas para avaliar os possveis impactos, que compem cada solicitao de mudanas.
podem ser gerados pela solicitao de mudana, baseados em O treinamento importante para que a equipe esteja pre-
custo, cronograma e escopo para sua realizao. Em seguida, a parada para receber, registrar e dar prioridade a todas as

Edio 69 - Engenharia de Software Magazine 51


requisies de mudanas (RDMs), criar uma agenda de ativi- Fases Perodo
dades e publicar RDMs para o comit de controle de mudanas, 1- Insero da cultura organizacional por meio de reunies dirias. 4 semanas
convocar reunies de emergncia, coordenar a construo, o
2- Treinamento da equipe de acordo o plano de execuo de mudanas. 3 semanas
teste e a implementao das mudanas, manter os registros
de mudanas atualizados com o progresso, revisar todas as 3- Execuo da nova gesto de mudanas em estado experimental. 12 semanas
mudanas implementadas para garantir que tenham atingido Cada solicitao de mudanas percorre as prximas sete atividades
seu objetivo, revisar RDMs pendentes para depois fech-las e 3.1- Registro de Requisio de Mudanas RDM Incio
finalmente fazer relatrios gerenciais. 3.2- Registro e Classificao 3hs
A ferramenta Help Desk passa a ser utilizada para realizar
3.3- Aprovao 3hs
solicitaes de mudanas e planejamento das atividades
3.4- Coordenao do Desenvolvimento 3h
necessrias para a implementao. preciso manter de for-
ma controlada todos os registros do planejamento inicial, 3.5- Autorizao 3h
das dificuldades encontradas, das mudanas de rota e das Depende de
3.6- Implementao
decises tomadas (quem, quando, por que). Quanto melhor cada tipo de solicitao
planejado o projeto, menos problemas e necessidades de re- 3.7- Avaliao 24h
vises futuras, porm dificilmente o projeto ser cumprido
Tabela 2. Cronograma de Implantao do Gerenciamento de Mudanas
do incio ao fim sem qualquer mudana ou adaptao e por
mais insignificantes que paream, essas mudanas devem
ser documentadas. Assim, aps deixar o ambiente estvel, pode-se iniciar o
Definido os papis de cada integrante da equipe, o plano de segundo passo que poder ser a implantao do processo de
gerenciamento de mudanas entra em estado experimental. Gesto de Incidente. Depois podero vir outros processos:
Neste estado uma grande porcentagem da equipe de TI dever Gerenciamento de Problemas, Gesto de Nvel de Servio,
estar operando de acordo com o novo fluxo de trabalho e a Gesto de Configurao, Gesto de Capacidade, Gesto de
outra porcentagem restante estar executando as atividades Disponibilidade, Gerenciamento Financeiro e Gesto de Con-
remanescentes. O estado experimental ir perdurar at que tinuidade dos Servios de TI.
toda a equipe esteja totalmente alinhada com a nova forma de Com a proposta de implantao do gerenciamento de mu-
gesto e os solicitantes j estiverem em um nvel de maturida- danas estima-se como principais benefcios uma melhora
de suficiente para centralizar suas solicitaes apenas para o no alinhamento das solicitaes com o negcio, maior ndice
gerente de mudanas. de assertividade, maior disponibilidade do tempo da equipe
O risco envolvido no processo de forma geral uma anlise de desenvolvimento, melhora na produtividade, reduo de
de fundamental importncia, onde deve existir um mapeamen- transtornos e servios de alta qualidade. Estes benefcios
to de todas as possibilidades de insucesso, pois este documento podem ser alcanados, desde que sua equipe seja capaz de
ser utilizado como referncia para determinao das contin- filtrar e priorizar as mudanas, ocasionando na reduo da
gncias necessrias, quanto mais detalhes (sob a perspectiva quantidade de solicitaes a serem realizadas. Deste modo
do negcio) forem catalogados, mais fcil ser determinar os estima-se que a disponibilidade da equipe de desenvolvimento
riscos envolvidos na operao. ir ser maior possibilitando uma melhora na qualidade dos
A implantao do gerenciamento de mudanas dever ocorrer servios prestados.
em trs passos sendo eles:
1. Insero da cultura organizacional por meio de reunies; Plano de Reverso
2. Disponibilizar um treinamento para toda a equipe de acordo Esta atividade deve prever quais passos, se possvel, devem
o plano de execuo de mudanas; e ser aplicados para que mudana retorne ao seu estado de ori-
3. Execuo da nova gesto de mudanas em estado experimen- gem, ou seja, em uma situao limite onde o procedimento deve
tal com uma parte da equipe at chegar maturidade suficiente ser abortado, o que se deve fazer para minimizar os impactos
para que toda a equipe esteja alinhada com o gerenciamento e voltar na situao pr-mudana.
de mudanas.
Estimativa de Custos Operacionais
A Tabela 2 apresenta o cronograma de atividades de implan- A estimativa de custo tem como objetivo mensurar quais
tao do Gerenciamento de Mudanas na empresa estudada. custos diretos est envolvido na mudana e os ganhos finan-
Para executar cada solicitao de mudanas necessrio ceiros, se existirem.
seguir os prazos do fluxo de atividades que compem a ter-
ceira fase. Classificao dos Resultados
A implantao ir ocorrer em trs fases, onde o trmino Quanto aos resultados, o gerenciamento da mudana pode
de uma o incio da outra. Na terceira fase a execuo das ser classificada em:
mudanas ir acontecer em estado experimental durante um Sucesso: Quando a mudana foi bem sucedida, ou seja, o
tempo pr-determinado. objetivo proposto foi alcanado dentro do tempo planejado.

52 Engenharia de Software Magazine - ITIL: Como implantar o gerenciamento de mudanas


en gen haria

Impacto: Quando a mudana foi realizada, no entanto, ultra- discutidas com mais detalhes. Estando a mudana acordada
passou o tempo planejado, causando impacto para o mesmo. na reunio, ser buscada a aprovao formal dos coordena-
Falha: Quando a mudana no pde ser concluda devido dores. Essa aprovao significa que a mudana foi negociada
a algum problema durante sua execuo e que a mudana foi e autorizada, sendo assim cabe ao Coordenador de Mudanas
abortada, porm dentro da janela acordada com o cliente. da empresa que ser o gerente de Projetos que tambm o
gerente de TI, aprovar somente as mudanas requisitadas
Preveno pelos analistas e/ou outros solicitantes e ao Coordenador
As prevenes que seguem so fundamentais para a definio Geral da empresa que ser o gerente geral, sinalizar que a
do escopo do Processo Gerncia de Mudanas: mudana foi negociada.
Cabe ao Solicitante da mudana fazer seu planejamento
tcnico. Mudanas Emergenciais
Quando um pedido de mudana feito, todas as informaes Desde que sejam registradas adequadamente e negociadas
tcnicas e de planejamento devem ser acompanhadas desde com a Gerncia de Mudanas, mudanas de emergncia
o incio do pedido. podero ocorrer a qualquer momento, passando antes por
O processo de Gerncia de Mudanas no possui envolvi- uma triagem onde dever ser comunicado e esclarecido o
mento direto com a fase de implementao da mudana, porm motivo da emergncia, cabendo ao coordenador avaliar a real
dever monitor-la e registrar sua implementao necessidade.
As responsabilidades do setor responsvel pelas mudanas
Aprovao: Processo e responsvel so:
Durante a Reunio de mudanas, todas as mudanas Coordenar todas as mudanas solicitadas;
apresentadas sero aprovadas ou no pelo grupo tcnico Garantir a existncia de planos de retorno para as mudan-
participante da reunio. Se no houver o consenso do grupo as;
para sua aprovao, essa mudana ser levada para outra reu- Em caso de falhas, garantir a implementao do plano de
nio mais tcnica e especfica (mudana crtica), onde sero retorno para as mudanas executadas pela empresa;

Edio 69 - Engenharia de Software Magazine 53


Aprovar ou rejeitar as mudanas apresentadas que tenham de mudana, fazendo com que a equipe da rea de TI adote
impacto no negcio, custo ou afetem o ambiente de TI da um novo comportamento. Assim, a governana de TI serve
empresa; para controlar os objetivos da rea de tecnologia, alinhar as
Identificar e informar as mudanas e apresentar as informa- estratgias, definir expectativas e medidas de desempenho,
es necessrias para o seu perfeito entendimento; viabilizando e gerenciando recursos, definindo prioridades,
Detalhar o cronograma e o planejamento das mudanas; direcionando as atividades de TI e gerenciando riscos.
Produzir toda a documentao necessria para a mudana; Para uma implementao eficaz de ITIL, no basta conhecer
Cancelar ou reprogramar as mudanas quando necessrio, as melhores prticas, especialmente no que se refere aos
justificando motivo da ao; benefcios de longo prazo para o negcio e o alcance de uma
Avaliar os impactos das mudanas planejadas junto aos soli- situao de excelncia dentro da organizao de TI. Ideal-
citantes e representantes tcnicos das vrias reas envolvidas, mente, uma implementao de ITIL com sucesso significa
garantindo que todos estejam cientes e em concordncia com que as pessoas da organizao assimilaram na sua cultura,
a mudana; os processos e procedimentos da ITIL. O fundamental
Executar as mudanas conforme o cronograma e atividades que a adoo da ITIL permitir a adoo de uma cultura
definidas pelo solicitante das mudanas; de melhoria contnua de qualidade dos servios prestados
Fornecer informaes sobre qualquer problema ocorrido pela rea de TI que, no mnimo, garantir a manuteno
durante a execuo das mudanas; dos ganhos j obtidos.
Interagir com o Solicitante para garantir que o requeri-
mento de mudana foi atendido, informando-lhe o status final
e os detalhes da execuo;
Referncias e Links:
Investimento de Implantao
A implantao da metodologia na empresa no ter muitos [1] MAGALHAES, Ivan Luizio; PINHEIRO, Walfrido Brito. Gerenciamento de
investimentos financeiros, somente o de implementao e Servios de TI na Prtica: Uma abordagem com base na ITIL. So Paulo.
documentao. Os funcionrios que iro atuar diretamente na Novatec, 2007.
implantao da mudana tero que realizar cursos de certifi- [2] MANSUR, Ricardo. Governana de TI. 2004
cao ITIL. Esses cursos podem ser feitos online. A empresa http://www.profissionaisdetecnologia.com.br/modules. php?name=News&file=art
pode comprar apenas um pacote de cursos que tem um custo icle&sid=63
aproximado de R$ 600,00 e colocar os funcionrios para realizar
Para mais informaes sobre o ITIL
os cursos numa sala usando um Datashow, assim, o gasto ser
http://www.itil-officialsite.com/
menor. Caso a empresa queira que os funcionrios envolvidos
tenham a certificao ITIL, ter um gasto de aproximadamente Key Performance Indicators
R$370,00 para cada diploma, ou seja, por cada funcionrio que http://management.about.com/cs/generalmanagement/a/keyperfindic.htm
realizar a prova de certificao.
Observando a grande dificuldade de obteno de ferramentas
e informaes para melhor gerir uma organizao da rea de Voc gostou deste artigo?
TI, observa-se a grande importncia de se ter um mecanismo
eficaz para gerenciar e auxiliar os processos de tomada de
D seu voto em www.devmedia.com.br/esmag/feedback
deciso.
A implementao dos processos baseados na ITIL est re- Ajude-nos a manter a qualidade da revista!
lacionada diretamente a um profundo e extenso programa

54 Engenharia de Software Magazine - ITIL: Como implantar o gerenciamento de mudanas


Desenvolvimento
Nesta seo voc encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software

Boas prticas de programao

Fique por dentro:


Este artigo apresenta um conjunto de boas pr-
ticas de programao com o objetivo de mostrar
como pequenas modificaes podem ajudar no
dia a dia dos programadores e profissionais de
TI. As boas prticas aqui apresentadas podem
ajudar no desenvolvimento profissional daque-

A
vida de um programador no les que trabalham envolvidos em atividades de
fcil. A tecnologia algo programao.
que no para de evoluir e a
cada dia surge uma forma diferente de
escrever um cdigo. A carreira de um Eficiente: cdigo que faz o que
profissional de informtica algo de sua proposto;
responsabilidade. O cdigo produzido Sem duplicidade: no faz o que outra
por esse profissional tambm de sua parte do cdigo j faz;
responsabilidade. Um bom cdigo no Elegante: porque diferente dos outros
somente aquele que funcional, mas cdigos;
tambm aquele que no tem valores Feito com cuidado: quem fez teve preo-
exorbitantes para ser mantido. A maior cupao em produzir aquele cdigo.
parte dos programadores no gostam de
alterar cdigos mal escritos. Isso algo Antes de falarmos sobre como fazer
que traz muita frustrao e muitas vezes para atingir esse nvel de qualidade,
um retrabalho desnecessrio. vamos falar um pouco sobre testes.
Leandro Tavares Siciliano
ltsiciliano@gmail.com Clean Code Importncia dos testes
Formado em Anlise de Sistemas UNESA com Um cdigo limpo deve ser: Construir um software no somente
MBA na UFRJ. Experincia de 17 anos de mer-
Simples: cdigo fcil de entender; escrever cdigo e v-lo funcionar, voc
cado. Atualmente atuando como desenvolvedor
desenvolvedor Java e Lotus Notes. Certificaes: Direto: vai direto ao ponto, no d saber que aquele cdigo ser manuten-
Certified Lotus Professional e Scrum Master. voltas para atingir seu objetivo; vel e que outras pessoas vo alter-lo.

Edio 69 - Engenharia de Software Magazine 55


Para isso, teste fundamental! Voc tem que ser responsvel
Listagem 2. Exemplo de declarao considerando boas prticas
por aquilo que escreve e saber que seu sistema tem que con-
tinuar funcionando. Neste contexto, temos a primeira dica public class NotaFiscal {
sobre um cdigo limpo: Toda linha que voc escrever deve estar
private Date dataCompra;
testada e ponto final ! private Date dataVencimento;
Muitas empresas veem testes como gastos maiores no pro- private boolean isDataVencimentoMaiorDataCompra(){
jeto, o que de fato acontece, porm a qualidade do software
return dataCompra.after(dataVencimento);
produzido algo significante. Quando no se produz teste
automatizado, a quantidade de testes manuais so maiores e }
muitas vezes o custo desses testes tambm maior.
//getters e setters
}
Nomes significativos
Mtodos, nomes de variveis e etc. devem possuir nomes que
significam alguma coisa em relao ao seu objetivo. Os nomes Evite notao hngara
utilizados devem responder todas as questes a seguir: A notao Hngara visa facilitar o reconhecimento do tipo
Porque existem? de varivel em um programa colocando em seu nome um su-
O que fazem? fixo descrevendo seu tipo (ver Listagem 3). Entretanto, com o
Como so usadas? advento de novas linguagens, tcnicas mostradas aqui e testes
automatizados, a notao hngara se mostra desnecessria.
Vamos imaginar que um sistema de um motor de um carro Existe uma certa tendncia para a criao de classes e mto-
tenha um mtodo com o nome de run ao invs de acelerar. dos menores de modo que as pessoas possam ver onde cada
Se voc pegar um cdigo com esse nome voc ter que estudar varivel que esto usando foi declarada. Alm disso, os testes
todo o mtodo para saber o que ele faz. indicam os tipos e maneiras de usar, validando o comporta-
Algo muito comum encontrado nos cdigos o tipo de de- mento esperado do mtodo.
clarao apresentado na Listagem 1.
Se um nome de classe, mtodo ou atributo requer um comen- Listagem 3. Exemplo de uso de notao hngara
trio, ele no est revelando sua real inteno.
public class Pessoa {

private String nomeString;


Listagem 1. Exemplo de declarao
// No existe aqui a necessidade de se colocar a palavra String,
public class NotaFiscal { // pode-se somente ficar nome
private Date d1;//Data da compra //getters e setters
private Date d2;//Data de vencimento }
private boolean validaDatas(){

//Valida se data do vencimento maior que a data de compra


Classes e mtodos
Nome de classes devem ser substantivos e no conter verbos.
if(d1.after(d2))){
J nomes de mtodos devem conter verbos, pois eles indicam
return true; aes.
} A regra para mtodos : A primeira regra dos mtodos que
return false; eles devem ser pequenos. A segunda regra que eles devem
} ser menores ainda.
//getters e setters
Mtodos e classes menores so mais fceis de ler e entender,
}
alm de manter claro. Segundo o livro, podemos considerar
as seguintes mtricas:
Mtodos <= 20 linhas;
Quando colocamos uma linha em nosso cdigo com um co- Linha <= 100 caracteres;
mentrio ao lado no estamos dando o nome correto ao atributo Classe = 200 a 500 linhas.
ou mtodo. O cdigo quando bem escrito deve ser algo que
seja de fcil leitura, algo que uma pessoa leiga conseguiria ao Claro que toda regra tem sua exceo. Se voc tem uma clas-
menos saber o que o mesmo faz. Os nomes utilizados devem se que vai precisar de mais linhas, um mtodo que tambm
ser pronunciveis, algo que voc entenda. precise de mais linhas, isso no um problema.
Observe no exemplo da Listagem 2 como essa prtica torna Mtodos e funes devem fazer somente uma coisa, faz-la
o cdigo mais fcil de ser entendido. certa e somente faz-la.

56 Engenharia de Software Magazine - Boas prticas de programao


desen volvimento

Poderamos analisar essa frase como um princpio da coeso com vrios comentrios que no serviam para nada e, pior,
no seu cdigo. Muitas vezes no fcil saber se aquele mtodo confundiam. Se um mtodo ou uma classe estiver bem escrito,
est fazendo somente uma coisa. Uma dica para isso : voc a importncia do comentrio minimizada.
deve tentar extrair parte do seu cdigo para um mtodo, se
voc conseguir porque aquele seu mtodo realmente no
Listagem 5. Mtodos com objetivos mal definidos
est tendo uma funo apenas.
Imagine que voc tenha um mtodo onde quisssemos mos- public boolean verificarSenha(String senha){
if(senha.equals(zzz)){
trar os detalhes de um usurio:
Session.initialize();
return true;
private void mostrarDadosUsuario(Usuario usuario){ }
return false;
mostrarCabecalhoUsuario();
}
System.out.print(Nome: , usuario.getNome());
S ystem.out.print(Sobrenome: , usuario.getSobrenome()); Listagem 6. Ajuste do objetivo do mtodo
}
if(verificaSenha(zzz){
Session.initialize();
Neste exemplo, as linhas do System.out.print so os detalhes }
do usurio. Mas ser que isso no ficaria melhor escrito se
public boolean verificarSenha(String senha){
estivesse de acordo com o cdigo da Listagem 4?
if(senha.equals(zzz)){
return true;
Listagem 4. Separando mtodos }
return false;
private void mostrarDadosUsuario(Usuario usuario){ }
mostrarCabecalhoUsuario();
mostrarDetalhesUsuario();
}

private void mostrarDetalhesUsuario{


Outro ponto importante, um comentrio no ir esconder
um cdigo ruim. Observe o exemplo a seguir:
System.out.print(Nome: , usuario.getNome());
System.out.print(Sobrenome: , usuario.getSobrenome());
Date d1;
}
Esse cdigo j est ruim, de nada adianta mudarmos para:

Se um dia voc quiser apenas listar os dados de um usurio Date d1; //dia da semana
ficar mais fcil. Agora temos os mtodos separados. Essa
prtica tambm um bom exemplo do tipo de refatorao Esse comentrio no ir se propagar para todo o cdigo e sem-
chamada Extract Method. pre que voc se deparar com uma linha como d1.after(d2);
Um outro item que deve ser observado a quantidade de pa- voc vai continuar no entendendo o propsito do cdigo.
rmetros de um mtodo. Voc deve ter uma justificativa muito Podemos tentar colocar uma regra nisso. Muitas vezes quan-
boa para ter uma quantidade to grande de parmetros em um do se comenta um cdigo, pode ser que o mesmo precise ser
mtodo. Um agravante de um mtodo com vrios parmetros refatorado. Lembra dos exemplos anteriores onde d1 passou
a dificuldade de se testar uma vez que voc dever testar a ser dataCompra? Com essa mudana seu cdigo pode ser
todas as combinaes possveis. entendido por todos e se fizermos essa refatorao o cdigo
Outra situao a que voc deve estar atento com um mtodo passa a no precisar mais de comentrio.
que informa que ir fazer uma determinada ao e faz outra. Observe agora o exemplo a seguir:
Observe a Listagem 5.
O objetivo do mtodo verificar a senha, porm, se a //Verifica se o usurio tem direito ao benefcio
senha estiver correta o mesmo inicia uma sesso, ou seja, if(usuario.getIdade() > 10 && usuario.getIdade() < 20){
o mtodo j no tem a coeso esperada, pois possui duas .
responsabilidades. }
Uma soluo melhor para esse cenrio pode ser observada
na Listagem 6. Observe agora o exemplo ajustado na Listagem 7.
Note que tiramos o comentrio, melhoramos o cdigo e o
Comentrios nos cdigos tornamos mais legvel. Agora a leitura do cdigo suficiente
Comentrios, apesar de importantes, podem trazer desin- para saber o que ele realmente faz.
formao. Por que podemos afirmar isso? Algum conhece Outro tipo de comentrio que deve ser evitado apresentado
programadores que atualizam comentrios? H vrios cdigos no exemplo a seguir:

Edio 69 - Engenharia de Software Magazine 57


private boolean isUsuarioTemDireitoAoBeneficio(Usuario usuario){ cdigo que vai demandar um tempo de processamento alto
if(usuario.getIdade() > 10 && usuario.getIdade() < 20){ ou a disponibilidade de um recurso. Nesses casos, comen-
return true; //Retorna verdadeiro
}
trios acabam sendo teis. Algumas vezes tambm no se
return false; //Retorna falso consegue colocar um nome em um mtodo que explique o
} porqu o desenvolvedor tomou aquela deciso.

Listagem 7. Eliminando o comentrio do cdigo Formatao


Formatao importante, pois se trata de comunicao.
if(isUsuarioTemDireitoAoBeneficio(usuario)){
.
Temos que considerar que o cdigo a maneira que a equipe
} de desenvolvimento vai se comunicar. Uma pessoa no gostaria
de receber uma carta cifrada onde tivesse que interpretar o que
private boolean isUsuarioTemDireitoAoBeneficio(Usuario usuario){
if(usuario.getIdade() > 10 && usuario.getIdade() < 20){
est escrito nela, podemos pensar assim na hora de escrever
return true; um cdigo.
} Outra ponto importante que se voc pega um cdigo
return false;
}
bem estruturado, voc vai querer mant-lo bem estruturado.
ruim para qualquer desenvolvedor ter acesso a um cdigo
sem formatao, sem endentao e ter que fazer sua leitura
O return do mtodo lgico, no h necessidade de indicar como se fosse um texto sem qualquer pontuao.
o que o mesmo est retornando. Alm disso, mtodos com conceitos relacionados devem ficar
Em relao a comentrios, podemos dizer que: Qualquer verticalmente prximos e a ordem dos mtodos deve criar um
comentrio que faa voc olhar para outras partes do seu cdigo para fluxo de leitura melhorando a legibilidade do cdigo.
entend-lo no valem os bits que consomem. Uma boa endentao fundamental, mas no podemos ter
Por outro lado, existem momentos em que o comentrio muitos nveis. Observe como o trecho a seguir poderia se tornar
importante. Digamos que voc tenha um trecho em seu confuso caso a lgica implementada fosse complexa:

58 Engenharia de Software Magazine - Boas prticas de programao


desen volvimento

if(a>1){ Os testes devem considerar as caractersticas F.I.R.S.T:


if(b>1){ *F (Fast): deve ser rpido. Testes demorados tiram a motivao
if(c>1){
if(z>1){
dos profissionais responsveis por sua execuo;
*I (Independent): no podem depender um do outro pois se
} um falha o outro vai falhar tambm;
}
}
*R (Reapetable): executando mais de uma vez eles devem
} retornar sempre o mesmo resultado;
*S (Self-Validating): devem se autovalidar;
Tratamento de erros *T (Timely): devem ser feitos antes do cdigo.
Quando estamos programando devemos tratar os possveis
erros que nossa aplicao poder lanar, as coisas podem dar Refatorao
errado e temos que estar certos que nosso cdigo far o que Escrever um bom cdigo muitas vezes pode no parecer uma
deve fazer. misso to simples. Considere o trecho de cdigo a seguir:
Tratamento de erro de responsabilidade do desenvolvedor.
preciso garantir que o cdigo vai ter um tratamento para private boolean isStringVazia(String texto){
if (!StringUtils.isNullOrEmpty(texto) && !texto.equals()) {
cada situao. Prefira lanar uma exception ao invs de retornar //...
um cdigo de erro. Estes retornos desorganizam a chamada do }
mtodo e pode-se facilmente esquecer de verific-los. }

Dentro do seu mtodo voc j pode ver o erro que est sendo
retornado e trat-lo ali. Defina o fluxo do mtodo separando Concorda que o !texto.equals() no serve para nada? Se fi-
as regras de negcio de erros ou outras situaes. Para seus zermos a refatorao a seguir obteremos o mesmo resultado:
erros, crie mensagens informativas mencionando a operao
que falhou e o tipo de falha. private boolean isStringVazia(String texto){
if (!StringUtils.isNullOrEmpty(texto)) {
Procure utilizar exceptions para situaes inesperadas, por //...
exemplo: seu cdigo est lendo um arquivo e a rede se tornou }
indisponvel. }

TDD Agora, digamos que ainda assim estivssemos com receio


TDD nada mais que o desenvolvimento guiado por testes. de fazer essa refatorao. Neste caso, a presena de um sim-
As trs regras do TDD so: ples teste unitrio poderia eliminar a dvida referente ao
Voc no pode escrever um cdigo at que tenha criado um fato da funcionalidade continuar desempenhando seu papel
teste falhando; corretamente.
Voc no pode escrever mais teste do que seja suficiente A refatorao uma das melhores prticas para melhorarmos
para falhar; nosso cdigo. Seu cdigo pode ser eficaz, ou seja, fazer o que
Voc no pode escrever mais cdigo do que o suficiente para se deseja, mas tambm pode ser eficiente, fazer o que se deseja
passar no teste que est falhando. da melhor maneira possvel.

Assim, se voc tiver que testar se um CPF vlido, por exem- Voc gostou deste artigo?
plo, voc deve criar alguns testes tais como:
se o CPF for em branco; D seu voto em www.devmedia.com.br/esmag/feedback
se o CPF estiver com menos caracteres. Ajude-nos a manter a qualidade da revista!

Edio 69 - Engenharia de Software Magazine 59


60 Engenharia de Software Magazine - Boas prticas de programao