Você está na página 1de 54

magazine

engenharia
de software

Teste
Testes funcionais
de software

Edio 45 - Ano 04

Projeto
Dando foco ao
negcio com DDD

Gerenciamento
Ferramentas para
Gesto de Projetos
Segurana da Informao
Conhecendo a ISO 15408

Agilidade
PMI versus Scrum: O equilbrio
ser possvel?

Desenvolvimento
Conhea tcnicas para manter
seu cdigo limpo Parte 7

Rodrigo Oliveira Spnola


rodrigo.devmedia@gmail.com
Doutor e Mestre em Engenharia de Software pela COPPE/UFRJ. Autor de diversos artigos cientficos
sobre Engenharia de Software publicados em revistas e conferncias renomadas, dentro e fora do
pas. Experincia de participao em mais de 20 projetos de consultoria para diferentes empresas
tendo atuado com gerncia de projetos, requisitos e testes de software. Implementador certificado
do MPS.BR, tendo tambm experincia atuando junto a empresas certificadas CMMI.

Marco Antnio Pereira Arajo

Ano 4 - 45 Edio - 2012

maraujo@devmedia.com.br
Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ - Linha de Pesquisa
em Engenharia de Software, Especialista em Mtodos Estatsticos Computacionais e Bacharel em
Matemtica com Habilitao em Informtica pela UFJF, Professor e Coordenador do curso de Bacharelado em Sistemas de Informao do Centro de Ensino Superior de Juiz de Fora, Professor do
curso de Bacharelado em Sistemas de Informao da Faculdade Metodista Granbery, Professor e
Diretor do Curso Superior de Tecnologia em Anlise e Desenvolvimento de Sistemas da Fundao
Educacional D. Andr Arcoverde, Analista de Sistemas da Prefeitura de Juiz de Fora, Colaborador
da Engenharia de Software Magazine.

Corpo Editorial
Editor
Rodrigo Oliveira Spnola
Colaboradores
Marco Antnio Pereira Arajo
Eduardo Oliveira Spnola

Eduardo Oliveira Spnola

Jornalista Responsvel
Kaline Dolabella - JP24185

eduspinola@gmail.com
Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Magazine. bacharel em Cincias da Computao pela Universidade Salvador (UNIFACS) onde atualmente cursa o
mestrado em Sistemas e Computao na linha de Engenharia de Software, sendo membro do GESA
(Grupo de Engenharia de Software e Aplicaes).

Na Web
www.devmedia.com.br/central
(21) 3382-5038

Atendimento ao Leitor
A DevMedia conta com um departamento exclusivo para o atendimento ao leitor. Se
voc tiver algum problema no recebimento do seu exemplar ou precisar de algum
esclarecimento sobre assinaturas, exemplares anteriores, endereo de bancas de
jornal, entre outros, entre em contato com:
www.devmedia.com.br/mancad
(21) 3382-5038

Fale com o Editor!


muito importante para a equipe saber o que voc est achando da revista: que tipo de artigo voc
gostaria de ler, que artigo voc mais gostou e qual artigo voc menos gostou. Fique a vontade para
entrar em contato com os editores e dar a sua sugesto!
Se voc estiver interessado em publicar um artigo na revista ou no site SQL Magazine,
entre em contato com os editores, informando o ttulo e mini-resumo do tema que voc gostaria
de publicar.
Apoio

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

EDITORIAL

o h mais dvidas de que a indstria de software uma das mais im-

Neste contexto, esta edio da Engenharia de Software Magazine destaca

portantes atualmente. O mercado brasileiro de software e servios de

como tema de capa Kanban. Para isso, traz dois artigos muito interessantes so-

TI, segundo o ltimo relatrio da ABES, de US$ 19 bilhes e cresce

bre o tema: Kanban no desenvolvimento de projetos de software e Kanban:

de 25% a 30% ao ano desde 2004. Porm, grande parte do software produzido

o gil adaptativo.

ainda defeituoso, inadequado aos desejos do cliente, entregue fora do prazo

Alm destes dois artigos, teremos mais seis nesta edio:

e acima dos custos esperados.

PMI versus Scrum: O equilbrio ser possvel?

Neste cenrio, temos observado mais recentemente ao surgimento do Kan-

Ferramentas para Gesto de Projetos

ban. A histria do Kanban para desenvolvimento de software, assim como a

Conhecendo a ISO 15408

histria da grande maioria das metodologias, modelos de maturidade, proces-

Testes funcionais de software

sos de desenvolvimento e processos em geral, comea com um grande dese-

Dando foco ao negcio com DDD

jo, muitas ideias, testes (na prtica) e diversos ajustes at atingir os primeiros

Boas prticas para escrita de mtodos, funes e procedimentos Parte 7

casos de sucesso.
A principal diferena do Kanban para as demais metodologias de desenvol-

Desejamos uma tima leitura!

vimento de software atuais que ele foi um modelo adaptado de outra indstria, a de manufatura, mais especificamente da Toyota. Kanban (com K maisculo) um mtodo de mudana evolutivo para monitoramento e melhoria
de processos de produo, que utiliza kanban (com k minsculo) para auxiliar
na visualizao do fluxo e para permitir a criao de um sistema puxado de
trabalho alm de outras ferramentas para catalisar a introduo de ideias Lean
nas reas de desenvolvimento de software e operaes de TI.

Equipe Editorial Engenharia de Software Magazine

NDICE
Agilidade Fundamentos
06 - Kanban: o gil adaptativo
Flavio S. Mariotti

11 - Kanban no desenvolvimento de projetos de software


Thiago Ghisi

17 - PMI versus Scrum: O equilbrio ser possvel?


Luiz Carlos Vianna

Engenharia Fundamentos
23 - Ferramentas para Gesto de Projetos
Aline da Silva Tinoco e Marco Antnio Pereira Arajo

31 - Conhecendo a ISO 15408


Dayana Fernanda Trapp e Rodrigo Oliveira Spnola

37 - Testes funcionais de software


Elisngela Andrade Bruno, Paulo C. Barreto da Silva e Thiago Salhab Alves

Arquitetura e Desenvolvimento
42 - Dando foco ao negcio com DDD
Robson Castilho

49 - Boas prticas para escrita de mtodos, funes e procedimentos Parte 7


Jacimar Fernandes Tavares e Marco Antnio Pereira Arajo

Edio 05 - Engenharia de Software Magazine

Fundamentos da Agilidade
Nesta seo voc encontra artigos voltados para a prtica de mtodos geis.

Kanban: o gil adaptativo


Introduzindo Kanban na equipe gil

De que se trata o artigo?


Este artigo traz uma breve abordagem do modelo
Kanban. O objetivo apresentar o sistema Kanban e
explicar sua proposta. Entender o conceito de visualizao e o porqu algo to simples pode fazer uma
diferena to grande na qualidade dos resultados.

maduras e eficientes no que se prope? Como


identificar onde esto os gargalos que fazem as
equipes falharem nos seus sprints? Podemos dizer
com que o Kanban pode ajudar a identificar essas
falhas e solucion-las.

Resumo?
Em que situao o tema til?
Nos ltimos anos o conceito de metodologia gil
vem movimentando o mundo de desenvolvimento
de software. Metodologias mais populares como
Scrum e XP, criadas nas fabricas de software, vem
ganhando cada dia mais espao nas empresas
de tecnologia. Essas ferramentas surgiram com
a proposta de melhorar e agilizar os processos
envolvidos no desenvolvimento de software, porm no mundo real fica claro que os processos ainda no esto perfeitos. Mas o que fazer ento,
sendo que essas ferramentas esto, teoricamente,

O mtodo Kanban para desenvolvimento de software e processos geis tem como nfase no
sobrecarregar os membros que compe a equipe
de criao do produto. Por isso, o mtodo contem
princpios bsicos como: a equipe ou membro
deve iniciar uma nova tarefa quando capaz de
realiz-la agora, a equipe deve aceitar mudanas incrementais e evolutivas estimuladas pelo
mtodo Kanban e respeitar os atuais processos,
papis e responsabilidades. Neste sentido, este
artigo ir apresentar o sistema Kanban e explicar
sua proposta.

Flavio S. Mariotti
flaviomariotti@gmail.com

Especialista em Engenharia e Arquitetura


de Software. Ps Graduado pelo Instituto
de Pesquisa Avanada de Tecnologia IBTA
em Engenharia de Software baseado em
SOA. Bacharel em Sistemas de Informao
pela UNIUBE e tcnico em Processamento
de Dados pela FEB. Consultor independente
no desenvolvimento de software em arquitetura OO, SOA, GIS e Plataforma .NET.

Kanban baseado na ideia


onde atividades em andamento
devem ser limitadas. Um novo
item s pode ser iniciado quando o item
em andamento finalizado ou quando
uma funo automtica inicia o mesmo
instantaneamente.

Engenharia de Software Magazine - Kanban: o gil adaptativo

O Kanban, basicamente, tem como


principal objetivo transformar o trabalho em andamento visvel para toda
equipe, criando um sinal visual que
indica que o novo trabalho pode ou no
ser iniciado e se o limite acordado para
cada fase est sendo respeitado.

agilidade

Neste momento, provavelmente voc est se perguntando,


o que isso tem de interessante? David J. Anderson teve essa
mesma sensao e segundo ele A teoria do Kanban no soa
muito revolucionria nem parece afetar profundamente o
desempenho, cultura, capacidade e maturidade de uma equipe
e a organizao na qual est inserida. Mas o impressionante
que afeta! O Kanban parece uma mudana pequena e, no
entanto, muda tudo a respeito de uma empresa.
Portanto, o Kanban no um processo e nem descreve papeis
e faces para serem seguidos. Podemos dizer que o Kanban
uma abordagem para mudana gerencial do projeto, um conceito para introduzir alteraes em um ciclo de desenvolvimento
de software ou gerenciamento de projetos.
Os mtodos geis fornecem transparncia sobre as atividades em andamento e concludas, e reportam mtricas com
velocidade. O Kanban, no entanto, vai um passo alm e d
transparncia ao processo e seu fluxo, expondo gargalos, filas,
variabilidade e desperdcios. Portanto, tudo que impacta no
desempenho da equipe de produo e para entrega de valor,
fica explcito no modelo Kanban.

O que Kanban?
O nome Kanban de origem japonesa e sua traduo seria
como sinal ou carto. Portanto, vamos chamar de sinalizador ou melhor registro visual. O nome Kanban surgiu
dos sistemas de carto usados nas indstrias de produo, que
tinham como finalidade o gerenciamento do fluxo de trabalho
atravs da organizao de desenvolvimento.
O Kanban, com seu mecanismo de sinalizao, tem como
objetivo apresentar uma atividade de trabalho em processo,
ou seja, o nmero de atividades ou cartes em circulao
equivalente capacidade do sistema.
Uma outra caracterstica importante do modelo Kanban o
conceito de puxar tarefa quando h capacidade de processla. Esse recurso vai de encontro ao tradicional modelo de
empurrar tarefa conforme sua demanda, mantendo assim o
bom desempenho da equipe. Portanto, ao invs dos membros
que produzem o produto receberem atividades conforme suas
demandas, os requisitos so adicionados a lista de backlog e
puxados pelos membros que liberam suas atividades correntes e se tornam disponveis para iniciar uma nova tarefa.
Uma boa metfora que descreve essa regra imaginarmos
uma rodovia que suporta at 100 veculos para manter o fluxo
de trafego com um bom desempenho, porm em todos os
feriados essa rodovia recebe em torno de 200 veculos. Essa demanda no suportada pela rodovia gera um congestionamento
afetando consideravelmente o desempenho do trafego. Logo,
no adianta empurrar um numero de atividades no suportada
pela equipe, isso ir causar um congestionamento e afetar o
desempenho de produo.
A implementao do modelo Kanban se resume em trs
etapas que so:
Visualizar os processos;
Limitar o trabalho em processo do ingls WIP (work in
progress);

Gerenciamento do lead-time, ou seja, tempo que a atividade leva para passar por todas as fases at a sua entrega.

O sistemaKanban
Para entendermos a proposta desde conceito, vamos primeiro estudar o sistema Kanban. Vamos chamar as tarefas que
compe o painel Kanban de cartes. O nmero de cartes
representa a capacidade limite acordada em cada fase de um
sistema que so colocadas em circulao.
Cada carto funciona como um mecanismo de sinalizao e o
sistema s permite iniciar uma nova tarefa quando um carto
est disponvel. muito importante respeitar essa regra, e fazer
com que qualquer novo trabalho espere em uma fila at que
um carto se torne disponvel.
O sistema Kanban fornece um mtodo simples, barato e fcil
de implementar e rapidamente comea a apresentar resultados
permitindo gerenciar o limite de atividades em andamento e
garantindo o bom desempenho da equipe.

Afinal, por que usar umsistemaKanban?


Ao entender a proposta de um sistema Kanban, se torna
simples perceber que o uso de um sistema prepara e limita o
trabalho em andamento para uma capacidade suportada pela
equipe. Esse recurso proporciona o equilbrio da demanda de
uma equipe controlando o seu rendimento, e consequentemente,
acelerando sua produo.
simples deduzir que todas as pessoas produzem mais
quando conseguem equilibrar a vida pessoal e profissional.
O Kanban buscar atingir um ritmo sustentvel de desenvolvimento para que todos os indivduos possam alcanar esse
objetivo entre vida pessoal e profissional. Segundo David J.
Anderson, O Kanban rapidamente elimina as questes que
prejudicam o desempenho, e desafia uma equipe para se concentrar em resolver essas questes a fim de manter um fluxo
constante de trabalho.
O Kanban atua fornecendo visibilidade nos processos, deixando explcito os problemas e prendendo o foco da equipe em
qualidade. Portanto, este comportamento reflete os defeitos,
pontos de sobrecarga, custos econmicos sobre o fluxo de
rendimento e a variabilidade. A simples regra de limitar os
trabalhos em andamento no sistema Kanban estimula maior
qualidade e maior desempenho na execuo de cada tarefa.
O Kanban, com a combinao de fluxo, contribui para a reduo
do estresse da equipe e melhora a previsibilidade e colaborao,
refletindo com isso, nas datas de vencimento para entrega de tarefas. Com a equipe produzindo e cumprindo os prazos de liberao, o Kanban ajuda a fortalecer os laos de confiana dos clientes,
parceiros, fornecedores e outras entidades relacionadas.
Ao aplicar o Kanban, respeitando suas pequenas exigncias,
o sistema tende a contribuir para a maturidade da equipe,
podendo at afetar a cultura organizacional da empresa.
Com a identificao de falhas, a equipe consequentemente
concentra-se em uma fora tarefa para resolv-las, e por contar
com maior contribuio da equipe, a tendncia de prevenir
problemas futuros.

Edio 45 - Engenharia de Software Magazine

Por conta desta filosofia, o Kanban vem mostrando eficincia e ganhando diariamente diversos profissionais que se
renderam aos benefcios proporcionados por ele.

Aplicando o sistema Kanban no desenvolvimento de


software
Para o desenvolvimento de software, comum o uso de um
sistema Kanban digital. Porm, pode-se manter o conceito de
painel fsico e digital, isso reconhecido como boa prtica uma
vez que ele mantm o princpio de sinalizao visual.
Algumas empresas tem implementado o Kanban fsico utilizando lousas, painis, paredes ou tabuleiros. Na verdade, no
existe um objeto recomendado para usar, o importante que
este painel seja visvel, atingindo o conceito de sinalizador
visual. Ainda neste artigo sero apresentados alguns modelos
de painel Kanban.
importante lembrar a alguns profissionais que vem usando
paredes ou at mesmo portas do escritrio para sinalizar as atividades em andamento que, mesmo essa tcnica conseguindo
servir como sinalizador visual das atividades em andamento,
no podemos considerar isso um modelo Kanban. Para ser um
sistema Kanban necessrio existir a ideia de puxar tarefas,
conforme o limite acordado em cada fase, ou seja, para se tonar
um sistema Kanban necessrio aplicar as trs etapas cruciais
que so: criar o painel de visualizao, limitar os processos
WIP e gerenciar o lead-time, aplicando o conceito de puxar
uma nova tarefa quando um carto est disponvel.

Priorizao
Ao aplicar os trs primeiros passos para a implementao do
modelo Kanban, os resultados tendem a aparecer com: cdigos
de alta qualidade, lead-time de desenvolvimento relativamente
curto, e controle do desempenho de produo.
O gerenciamento do limite deve ser feito de forma rgida,
evitando a priorizao de excees imprevistas no negcio, e
focando no desenvolvimento dos itens conforme acordado na
estratgia do projeto. recomendado que a ateno da gesto
seja mais dedicada para melhorar a capacidade e previsibilidade de entrega.

Buscando a maturidade na produo


Para alcanar o adjetivo maturidade, fundamental que a
equipe primeiro busque aprender a construir cdigos de alta
qualidade e equilbrio no trabalho em andamento para cumprir
suas datas de entrega.
A busca pela qualidade est conectada com a velocidade no
nvel de produo. O desempenho da equipe de desenvolvimento pode ser fortemente beneficiada com a eliminao de
retrabalhos, com isso, a equipe pode alcanar um ritmo de
produo de alta performance.

Comportamentoemergente comKanban
O Kanban foi implementado na Corbis em 2007 pelo seu
idealizador David J. Anderson. Este trabalho resultou em
uma lista de comportamentos emergentes que vem crescendo

Engenharia de Software Magazine - Kanban: o gil adaptativo

rapidamente com novas implementaes Kanban. provvel, e


esperado, que esta lista cresa medida que aprendemos mais
sobre os efeitos do Kanban nas empresas. Os comportamentos
que preenchem a lista atualmente so:
1. Processos limitados e adequados para cada fluxo do
projeto;
2. Desenvolvimento sem a necessidade de iterao;
3. Gerenciamento do custo de implementao;
4. Valores otimizados para classes de servios;
5. Gerenciamento de risco com alocao de capacidade;
6. Gesto quantitativa;
7. Tende a atingir outros departamentos;
8. Mescla pequenas equipes e proporciona um maior grupo
de trabalho.

Sinalizador visual Kanban


O sinalizador visual Kanban funciona como uma ferramenta
de sinalizao de processos, deixando explcito o fluxo de valor
atravs do processo em andamento. Para os adeptos ao Scrum,
o quadro Kanban pode ser comparado ao recurso de quadro/
placa Scrum para visualizao de tarefas.
Assim como a sequncia de colunas que representam os
diferentes estados de uma tarefa existente durante o processo
de desenvolvimento, o carto ou sinalizador Kanban movido
de uma fase ou estado para outro, at que tenha sido aprovado
para entrega.
Um quadro simples representando o sistema Kanban
pode conter as seguintes etapas: anlise, desenvolvimento,
aceitao e implantao. Esse modelo, primeira vista,
pode lembrar o conceito da engenharia de cascata, porm
na prtica, o Kanban no atua como o cascata e evita os
problemas decorrente do conceito. O Kanban tem como
linha de produo a regra de limitar o processo em andamento, o WIP, essa regra evita as falhas apresentadas pela
engenharia cascata.
A teoria do sistema Kanban no quadro visual aplicada
com a regra em que cada coluna ter um WIP estabelecido
e representados pelo nmero mximo de cartes em cada
fase. O carto composto por uma breve histria do usurio, descrevendo seus requisitos. Todo carto entra na fila
de backlog e aguarda a liberao de capacidade para entrar
nas colunas seguintes. Quando as atividades envolvidas
com o carto na coluna em andamento so finalizadas, o
mesmo movido para a coluna seguinte, liberando espao
para entrada de um novo carto.
O procedimento aplicado acima gera o conceito de puxar
cartes para inicializao. A prioridade dos cartes a serem
iniciados deve seguir as exigncias e estratgias do projeto.

Exemplos de sinalizadores visuais Kanban


O quadro de sinalizao visual do Kanban uma das principais etapas propostas pela ferramenta, porm, cabe ressaltar
que ao aplicar o limite de trabalho em andamento e determinar
o lead-time, importante customizar o quadro conforme suas
necessidades.

agilidade

Nesta etapa do artigo, ser apresentado um modelo de quadro


Kanban. Este exemplo ser customizado conforme as necessidades da equipe. O importante respeitar as poucas polticas
exigidas pelo Kanban, e depois customizar na tentativa de
acelerar e aperfeioar o conceito de comunicador visual.
A Figura 1 ilustra um modelo simples de sinalizador visual
Kanban. Nesta representao, fica fcil identificar o limite de
cartes estabelecidos para cada fase. Este limite est representado pelos nmeros em vermelho no cabealho. Os cartes
ilustrados pelos retngulos representam uma breve histria
dos usurios, ou seja, as demandas. As imagens com formato
de rosto representam os responsveis pelos trabalhos em andamento. Portanto, este exemplo aplica as trs etapas cruciais
para obter os benefcios alcanados com o sistema Kanban.

o sprint. A entrega com atraso apresenta riscos e tende a afetar


o desempenho da produo, afetando significativamente o
resultado de valor entregue ao cliente.
O Scrum prope aos membros da equipe a trabalharem
juntos em apenas uma necessidade antes de iniciar um novo
item. O Kanban aplica essa orientao de forma implcita e
explcita, definindo um limite no nmero de itens em andamento. Ao limitar a quantidade de trabalho em andamento, a
equipe , consequentemente, forada a colaborar na busca por
soluo nos itens que apresentam riscos para o desempenho
do desenvolvimento.
Outro benefcio alcanado com a aplicao de limites de
trabalho em andamento o ganho do conceito de puxar novos
itens, o que garante que nunca a demanda excede a capacidade
de produo. recomendado que os limites sejam estabelecidos
pela equipe em colaborao e a equipe de administrao ou
gesto do projeto. Isso contribui para otimizao no fluxo de
trabalho. Essa colaborao tambm implica na gesto alinhada
com a estratgia do negcio e proteo do limite WIP.

Benefcios alcanados com o Kanban

Figura 1. Ilustrao de um sinalizador visual Kanban

importante ressaltar que o desenvolvimento de um quadro


Kanban ir evoluir conforme as necessidades de cada organizao. Algumas empresas vem incluindo uma coluna chamada
Refletir. Esta fase prope uma reflexo por cada carto que
chega ao estado final do processo. Esta coluna adicionada
ao quadro na tentativa de aplicar melhoria continuada em
todos os processos.
Mattias Skarin publicou recentemente em seu blog dez
diferentes quadros de visualizao. Na apresentao de cada
modelo proposto por Mattias Skarin, fica clara a evoluo dos
sinalizadores conforme a necessidade de cada equipe. Conhea
mais acessando o endereo: http://blog.crisp.se/2009/11/16/
henrikkniberg/1258359420000.

Trabalhando com processos limitados


O Kanban vai alm de rastrear e demonstrar visualmente
o progresso de uma atividade em andamento. No Kanban, o
conceito de limitar o que deve ser feito aplicado em todas
as colunas do quadro. Essa uma maneira rpida de reduzir
o lead-time.
Para os usurios do Scrum, essa uma diferena fundamental
entre o quadro Scrum e o quadro Kanban. Um dos desafios comuns enfrentados com o Scrum o atraso na entrega conforme

Alguns estudos vem mostrando os diversos benefcios alcanados pelas equipes que adotaram o Kanban. Algumas vantagens observadas so: falhas tornam-se claramente visveis
em tempo real; o benefcio de encontrar os gargalos faz com
que as pessoas passem a colaborar ainda mais para a cadeia
de valor em vez de apenas fazerem a sua parte.
Um outro aspecto interessante do modelo Kanban que
ele fornece uma evoluo gradual do processo cascata para o
modelo de desenvolvimento gil de software. Com isso, vem
conquistando as empresas que ainda no tinham se rendido
s metodologias geis. O fato de poder fazer desenvolvimento
de software gil, sem necessariamente ter que usar o time-box,
iteraes e sprints de Scrum, torna o modelo mais amigvel e
fcil de ser adotado.
Outro benefcio relevante observado com o uso do Kanban
que, naturalmente, o conceito tende a se espalhar para outros
departamentos da organizao, aumentando a visibilidade de
tudo o que est acontecendo na empresa.

Combinando mtodos geis


Uma dvida frequente nas discusses e fruns sobre metodologias geis : posso utilizar Kanban junto com meu processo
atual? A resposta simples e positiva, SIM. O Kanban vem com
a proposta de agregar. Portanto, o primeiro passo visualizar o
processo atual adotado pela empresa, e implementar os conceitos
Kanban para encontrar os gargalos existentes no processo.

Mitos e verdades do Kanban


Como toda metodologia, o Kanban j vem recebendo algumas
caractersticas que no condizem com a realidade. Uma delas
o mito que o Kanban no um processo com iteraes. Na
verdade, a iterao Kanban pode ser usada se necessria. Esse
recurso opcional, o importante faz-lo somente se existe
uma necessidade em seu contexto.

Edio 45 - Engenharia de Software Magazine

10

Engenharia de Software Magazine - Kanban: o gil adaptativo

Limited WIP Society


http://www.limitedwipsociety.org/
InfoQ - Kanban
http://www.infoq.com/Kanban
Kanban and Scrum making the most of both
http://www.infoq.com/minibooks/kanban-scrum-minibook
David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business, 2010.
Jim Benson; Tonianne DeMaria Barry, Personal Kanban, 2011.
John M. Gross; Kenneth R. McInnis, Kanban Made Simple, 2008.

D seu feedback sobre esta edio!


A Engenharia de Software Magazine tem que ser feita ao seu gosto.
Para isso, precisamos saber o que voc, leitor, acha da revista!
D seu voto sobre este artigo, atravs do link:
www.devmedia.com.br/esmag/feedback

Feedback
eu
sobre e
s

Com este artigo podemos concluir que o Kanban permite de


forma efetiva visualizar o fluxo de trabalho e dividir o trabalho
em partes, escrevendo cada item em um carto e incluindo
ele no painel de visualizao.
O uso de colunas nomeadas atua como sinalizador, ilustrando
onde cada item est no fluxo de trabalho. A aplicao de limite
de trabalho em progresso (WIP work-in-progress) em cada
coluna contribui para gesto e diminuio do lead-time.
provvel que diversas equipes de software adotem o
Kanban, sendo que algumas podem adotar o Kanban definitivamente, enquanto outras equipes usaro Kanban no nvel
de portflio de projetos, continuando a utilizar outras metodologias no nvel de equipes pequenas.
Kanban ainda uma ferramenta muito nova e vem se estendendo desde pequenas equipes para o projeto de portflio

Links

D
s

Concluso

at o fluxo de valor da organizao. A verdade que vrias


empresas vem buscando alinhar seus esforos e ganhar vantagens competitivas em seus mercados, e o Kanban, sem dvida,
pode ser uma ferramenta de auxilio na busca de uma produo
com alto desempenho.

edio
ta

Outro mito comum sobre o Kanban dizer que no se usa


estimativas, na verdade esse tambm um item opcional, e
requer cuidado com o uso desse recurso.
Um erro comum visto em debates sobre Kanban dizer que
esse modelo melhor que Scrum, XP, RUP e etc. O Kanban
apenas mais uma ferramenta do processo, e no h tal comparao para determinar qual melhor ou pior. Outro erro
dizer que o Kanban veio para substituir as tradicionais metodologias geis. Novamente cabe lembrar que o Kanban apenas
um recurso que interfere sobre o gerenciamento de fluxo de
trabalho, portanto, sua proposta no substituir nenhuma
ferramenta, e sim, implementar os conceitos de mudana de
unidade, aplicando o modelo visualizao, limites de WIP e
evoluir com seus resultados.

Fundamentos da Agilidade
Nesta seo voc encontra artigos voltados para a prtica de mtodos geis.

Kanban no desenvolvimento de projetos de


software
Entendendo os desafios e a receita para o sucesso
De que se trata o artigo?

Resumo?

Neste artigo ser apresentado o mtodo Kanban,


uma interessante e simples abordagem para monitoramento e melhoria de processos de software
que tem uma forte inspirao no Sistema Toyota de
Produo.

O mtodo Kanban para desenvolvimento de software a cada ano ganha mais destaque na indstria de TI, pois vem conseguindo promover a melhoria contnua no processo de trabalho de muitas
equipes de empresas das mais variadas reas de
negcio e tamanho. Nesse artigo apresentada
uma introduo ao mtodo Kanban, destacando
os seguintes tpicos:
Histrico e as motivaes que levaram David Anderson a fazer a adaptao do mtodo da indstria de
manufatura (Toyota) para a indstria de software;
As cinco propriedades centrais e o funcionamento do mtodo;
Kanban pode ser considerado um mtodo gil?
Um guideline para ter sucesso com o mtodo
Kanban, focando principalmente no que deve ser
priorizado para se obter as melhorias mais significativas mais cedo.

Em que situao o tema til?


Thiago Ghisi
thiago.ghisi@gmail.com / @thiagoghisi

Ps-graduando em Gesto de Negcios


(UNISUL). Bacharel em Cincia da Computao (UNISUL, 2011). Tcnico em Redes de
Computadores (SENAI, 2005).
consultor certificado para implementao do MPS.BR e Sun Certified Programmer for the Java Platform, SE 6. H 6 anos
no ramo de tecnologia e desenvolvimento
de software, j atuou como: Professor Voluntrio de Informtica, Tcnico em Informtica, Pesquisador de Iniciao Cientfica,
Desenvolvedor, QA, Gerente de Projetos,
Analista de Sistemas e de Requisitos, Auditor de Garantia da Qualidade (PPQA) e
Analista de Processos. Possui experincia
na definio e implantao de processos
aderentes ao CMMI e ao MPS.BR e, em avaliaes MA-MPS nvel F e SCAMPI Classe A
nvel 2. entusiasta em desenvolvimento
gil desde 2007. Atuamente, trabalha na
Nexxera Techpeople, em Tubaro, SC.

Se a sua empresa ou a sua equipe est com dificuldades para melhorar a forma de trabalho, no
importando se ela usa ou no mtodos geis, o
Kanban pode ser uma das melhores alternativas
para fazer isso com o mnimo de resistncia. Alm
de ser um mtodo muito simples, comparado
maioria das metodologias/frameworks de desenvolvimento atuais, suas propriedades promovem
a colaborao.

o h mais dvidas de que a indstria de software uma das


mais importantes atualmente.
O mercado brasileiro de software e servios de TI, segundo o ltimo relatrio
da ABES [9], de US$ 19 bilhes e cresce
de 25% a 30% ao ano desde 2004. Porm,
grande parte do software produzido

ainda defeituoso, inadequado aos desejos do cliente, entregue fora do prazo


e acima dos custos esperados.
Observando esses e muitos outros
problemas, h mais de 10 anos, 17
profissionais da rea escreveram e
assinaram um manifesto: o manifesto
para desenvolvimento gil de software.

Edio 45 - Engenharia de Software Magazine

11

Neste, todos concordaram com alguns valores comuns,


dentre eles:
As metodologias geis concentram-se nas pessoas envolvidas
na produo;
Os planejamentos em longo prazo so falhos;
mais importante aceitar e adaptar-se a mudanas do que
seguir planos rgidos;
Software funcionando o melhor indicador de progresso
nos projetos de software.
Tendo como base grande parte dos princpios desse manifesto, bem como a filosofia Lean do Sistema Toyota de Produo
(TPS Toyota Production System), surgiu o Kanban para
Desenvolvimento de Software.
A filosofia Lean tem como objetivo a constante identificao
e a eliminao de qualquer espcie de desperdcio no sistema
de produo.
A histria do Kanban para desenvolvimento de software,
assim como a histria da grande maioria das metodologias,
modelos de maturidade, processos de desenvolvimento e processos em geral, comea com um grande desejo, muitas ideias,
testes (na prtica) e diversos ajustes (o mtodo cientfico) at
atingir os primeiros casos de sucesso.
A principal diferena do Kanban para as demais metodologias de desenvolvimento de software atuais que ele foi um
modelo adaptado de outra indstria, a de manufatura, mais
especificamente da Toyota. David Anderson [1] foi o grande
responsvel por essa adaptao.
A histria comea em 2002, quando Anderson, cansado de ver
equipes de desenvolvimento e departamentos inteiros de TI
merc de outros departamentos, decide voltar seus esforos
para responder a duas perguntas [1]:
1. Como proteger a minha equipe da demanda incessante de
negcio e alcanar o que a comunidade gil chama de ritmo
sustentvel?
2. Como adotar uma abordagem gil em toda a empresa e
superar inevitveis resistncias mudana?
Como cita em seu ltimo livro, Kanban: Successful Evolutionary Change for Your Technology Business [1], publicado em
2010, Anderson tinha um grande desejo: encontrar no setor
de TI uma relao ganha-ganha entre o departamento de
negcio e as equipes de desenvolvimento de software e TI.
Na tentativa de atingir esses objetivos, David idealizou,
testou e falhou muitas vezes nas diversas organizaes em
que trabalhou. Ele notou que implantar um processo de desenvolvimento de software totalmente prescritivo, na maioria
das vezes, no funcionava. Assim, chegou concluso que
um processo precisava ser adaptado para cada situao, e que
para fazer isso, era necessria uma liderana ativa em cada
equipe. Porm, esta era muitas vezes inexistente. E, mesmo
com uma liderana certa, ele duvidava que mudanas significativas acontecessem sem uma metodologia ou, no mnimo,
sem orientaes de como adaptar o processo para atender a
diferentes situaes.

12

Para David, sem um conjunto mnimo de orientaes para


guiar o lder, treinador ou engenheiro de processo, qualquer
adaptao no processo estava susceptvel a ser aplicada subjetivamente. Novos times sempre iro resistir a mudanas se
voc empurrar para eles processos que foram feitos para outras
realidades e que tiveram bons resultados l.
A concluso que David chegou que preciso ter uma evoluo com o novo time de uma forma incremental, partindo
do processo que atualmente seguido. Isso porque: Cada
time diferente: diferentes conjuntos de habilidades tcnicas,
capacidades e experincia. Cada projeto diferente: oramento,
cronograma, escopo e riscos diferentes. E, cada organizao
diferente: o processo de produo de software diferente em
cada rea de negcio. [1].
Esse o principal motivo pelo qual o Kanban um framework
para melhorias. Isto , ele orienta que o processo de trabalho
deve ser customizado em cada time de cada projeto de cada
organizao. Ou seja, um processo no deve ter suas prticas
seguidas risca da mesma forma em todos os times, de todos
os projetos, de todas as organizaes do mundo, como a grande
maioria das metodologias do mercado prescreve.
Em 2005, o mtodo de trabalho de David Anderson era baseado principalmente na Teoria das Restries (TOC Theory of
Constraints) e na FDD (Feature Driven Development).
A Teoria das Restries foi apresentada pela primeira vez em
1984 por Eliyahu M. Goldratt, no famoso livro A Meta. Segundo David Anderson [1], a habilidade de identificar gargalos
em um sistema o primeiro passo para entender a Teoria das
Restries. O efeito dos sistemas puxados, ou, processo de
produo puxado so tpicos que tambm ajudam a compreender melhor a teoria. Nele, a sada de produtos acabados, tal
como o software pronto para ser usado, ao final do processo de
desenvolvimento, dita o ritmo da introduo de novos requisitos no sistema. Isso evita acmulos de produtos inacabados
ao longo da linha de montagem, diminuindo a quantidade de
trabalho em progresso. J a FDD uma famosa metodologia
gil que o prprio David ajudou a criar.
Mais tarde, em 2007, aps fazer algumas customizaes na
sua forma de trabalho inspiradas em prticas do Sistema Toyota
de Produo, David apresentou nas conferncias Lean New
Product Development e Agile 2007 os resultados preliminares do uso de Kanban na Corbis, uma empresa fundada por
Bill Gates, da Microsoft.
Durante certo perodo, David chegou a ter dvidas a respeito da eficincia do Sistema Toyota de Produo, mesmo com
muitas pessoas falando o contrrio. Porm, aps conhecer um
pouco mais a respeito do pensamento de TaiichiOhno, um dos
criadores de tal sistema, e a ideia por trs da cultura Kaizen
(a qual ser falada no prximo tpico), David reconheceu, [1]
atravs de experincias ao longo dos cinco anos posteriores a
eficincia desse sistema que originou o Kanban.
Kanban (com K maisculo) um mtodo de mudana
evolutivo para monitoramento e melhoria de processos de
produo, que utiliza kanban (com k minsculo) para auxiliar na visualizao do fluxo e para permitir a criao de

Engenharia de Software Magazine - Kanban no desenvolvimento de projetos de software

agilidade

um sistema puxado de trabalho alm de outras ferramentas


para catalisar a introduo de ideias Lean nas reas de desenvolvimento de software e operaes de TI. um processo
evolutivo e incremental. Kanban lhe permite atingir processos
otimizados para contextos muito especficos, com resistncia
mnima e mantendo um ritmo sustentvel para os trabalhadores envolvidos. [1].

O mtodo Kanban
Como implementar mudanas continuamente no processo
de trabalho da equipe com sucesso? Este um ponto fundamental e um dos motivadores centrais das cinco propriedades
do mtodo Kanban:
1. Visualizar o fluxo de trabalho;
2. Limitar a quantidade de trabalho em andamento;
3. Medir e otimizar o fluxo de trabalho;
4. Tornar explcitas as polticas do processo;
5. Gerenciar quantitativamente.
O Kanban no uma metodologia, mas sim um framework
para implementar mudanas de forma incremental. Esse um
conceito muito importante para que se entenda o Kanban como
um todo j que, quando se fala em metodologias, fala-se em
conjuntos de prticas e o Kanban no tem nenhuma prtica
prescrita. H, nele, somente propriedades que devem guiar a
melhoria no processo atual, no importando quais prticas
estejam sendo usadas.
Ao usar o Kanban, como veremos mais detalhes ao decorrer
do artigo, esperado que se consiga visualizar quais prticas
esto sendo positivas e quais esto sendo negativas e isso,
consequentemente, vai conduzir a mudanas, que, naturalmente adicionaro, eliminaro ou alteraro as prticas atuais
de trabalho.
A forma mais comum de se conseguir visualizar o fluxo de
trabalho atravs de um kanban. Esse uma espcie de quadro, que pode ser fsico, normalmente colocado em uma das
paredes do local onde a equipe trabalha, ou virtual. O uso do
quadro virtual tem alguns prs e contras. Os pontos fortes so
basicamente a facilidade de extrao de mtricas e o histrico.
O principal ponto fraco dessa abordagem a dificuldade que a
equipe ter para analisar e evoluir conjuntamente o processo
de trabalho.
Nesse quadro, inicialmente devem ser modeladas cada uma
das etapas necessrias para se produzir o software, isto , todo
o workflow de trabalho. E, em cada uma dessas etapas deve ser
colocado e mantido um carto, a fim de simbolizar um trabalho
que est em andamento, como podemos ver na Figura 1. Cada
um desses cartes deve conter informaes detalhadas sobre a
atividade, bem como quem est desenvolvendo o item, e quando
o mesmo foi iniciado.
No Kanban para desenvolvimento de software, o kanban
deve ser mantido e evoludo por toda a equipe, o tempo todo.
A proposta baseia-se em fazer a prpria equipe enxergar onde
est errando e deix-la tomar decises seguindo um framework
simples, que guiar grande parte dessas melhorias.

Figura 1. Kanban systems for software development [10]

Para Alisson Vale [5], em atividades que envolvem trabalho


criativo, como desenvolvimento de software, o propsito
do Kanban provocar conversaes sobre o sistema de
trabalho.
Para limitar a quantidade de trabalho em andamento
necessrio definir, monitorar e manter um limite mximo de
tarefas em andamento para cada uma das etapas de trabalho
mapeadas no quadro kanban, como visto na Figura 1.
Ao estabelecer os limites, a equipe comea a identificar
onde esto os principais gargalos do processo de produo
e comea a ter que terminar todo o trabalho inacabado na
linha de produo para conseguir puxar mais trabalho para
o gargalo. Com isso, o trabalho tende a ser finalizado de uma
forma incremental e no de uma forma cascata, tornando-se
assim um sistema puxado (TOC), onde a equipe que dita a
sua capacidade de produo.
O uso do sistema puxado, juntamente com a visualizao de
todo o processo de desenvolvimento por toda a equipe, permite
implementar mudanas no processo de modo incremental.
Consequentemente, h reduo significativa da resistncia, o
que facilita o alcance do ritmo sustentvel, teoria to comentada em desenvolvimento gil, mas para a qual poucas definies
existem alm das 40 horas semanais de trabalho.
Uma citao de David [1] sintetiza isso: Um interessante
efeito colateral de sistemas puxados que eles limitam o
trabalho em andamento (WIP Work In Progress) para certa
quantidade acordada, evitando assim que trabalhadores fiquem sobrecarregados..
Outro fator importante o ganho que se tem ao praticamente
impedir que uma mesma pessoa execute vrias tarefas no mesmo projeto em paralelo. Vale destacar tambm o processo Just in
time (JIT), que evita o acmulo de estoque ao longo do processo
de desenvolvimento, como se faz no ciclo de vida em cascata.
Nesse caso, software em estoque so todos os requisitos que
ainda no foram liberados para o cliente usar.
No desenvolvimento de um software, como em qualquer
outra atividade intelectual, por mais contra intuitivo que possa
parecer, executa-se com mais qualidade e mais rapidamente
duas tarefas fazendo-as uma de cada vez, do que as duas em
paralelo o tempo todo.

Edio 45 - Engenharia de Software Magazine

13

Segundo Rodrigo Yoshima [7], um dos grandes pontos fortes


desse mtodo o modelo embutido nele para trabalhar com a
melhoria de processos, o modelo Kaizen. Alm do modelo Kaizen, existe o modelo Kaikaku. Vamos s diferenas: Kaikaku
uma palavra que define mudanas de processos classificadas
como melhoria radical. [7].
Implantar o Scrum, por exemplo, exige esse cenrio [7], pois
o Scrum requer profundas mudanas organizacionais como
a gesto abdicar de muitos instrumentos de controle, quebrar
com a separao entre os grupos e mudar posies hierrquicas
estabelecidas.
Kaizen a palavra Lean para indicar mudanas de melhoria
menores e contnuas. Ao contrrio do Kaikaku, Kaizen no
to traumtico, melhor aceito por todos (gerentes inclusive) e
mais simples de implementar. Tudo a nossa volta est suscetvel
a um evento Kaizen. Kaizen simplesmente significa mudana
para melhor. [7].
Na abordagem Kanban, aplicando a cultura Kaizen, antes
de mudar qualquer coisa devemos entender o ambiente de
trabalho. Se filas, bloqueios, gargalos ou problemas entre
reas esto nos prejudicando, primeiro, vamos visualizar
isso, convencer o grupo dos problemas e usar Kaizen para a
melhoria do ambiente com pequenas mudanas incrementais
e constantes. Isso ir fortalecer a cultura da empresa, pois ela
compreender suas falhas com provas palpveis que sero a
motivao para as mudanas [7].
Segundo Jos Papo [8], alm disso, a filosofia e prticas Lean,
como o caso do Kanban, focam na auto-organizao do time, na
responsabilidade conjunta pelos objetivos de negcio do projeto e
na produtividade com qualidade e com ritmo sustentvel. Todas
elas so prticas de administrao consagradas e evidenciadas por
Peter Drucker para liderar trabalhadores do conhecimento.
As duas ltimas propriedades do Kanban citadas (tornar explcitas as polticas do processo e gerenciar quantitativamente)
so praticamente atendidas deixando claro para toda a equipe
as trs primeiras propriedades e reforando que toda sugesto
de otimizao no processo deve ter como base modelos matemticos que provem as mtricas.

Kanban uma metodologia gil?


Nos ltimos tempos, acompanhamos uma briga forte entre
Kanban e as demais metodologias geis, principalmente o
Scrum. A polmica central : quem usa Kanban gil?
Rodrigo Yoshima [9] explica que o maior objetivo do Kanban
melhorar um processo existente, por pior que ele seja. Ainda
segundo Yoshima, o Kanban permite melhorar at mesmo
processos que seguem o ciclo de vida em cascata, fazendo eles
se tornarem geis e podendo melhorar continuamente, e at
mesmo superarem o Agile. Isso tudo graas cultura Kaizen
que o Kanban quer trazer tona.
Outro ponto a ser destacado que para o Kanban, diferente
da grande maioria das metodologias geis, no importa quais
prticas voc ir aplicar para melhorar o seu processo, o importante que voc tenha argumentos, preferencialmente
estatsticos, que expliquem o porqu dessas decises.

14

Como David ressalta em seu livro [1], a abordagem evolutiva do


Kanban, que promove a implementao de mudanas no processo de forma incremental, tem sido controversa na comunidade
gil de desenvolvimento de software. Isso ocorre principalmente
porque se sugere que as equipes no adotem um mtodo ou
modelo de processo. Vale ressaltar que a atual indstria de
servios e ferramentas desenvolveu-se em torno de um pequeno
conjunto de prticas definidas em dois populares mtodos de
desenvolvimento gil: XP e Scrum. Depois, com o Kanban, os
indivduos e as equipes esto habilitados para desenvolver suas
prprias solues por meio de um processo nico que evitaria
a necessidade de tais servios e ferramentas. Isso porque os
mesmos requerem um novo conjunto de ferramentas e servios
muito especficos para cada realidade. Dessa forma, torna-se
mais complicado para essa indstria ganhar dinheiro.
Tanta discusso acerca do assunto fez o pessoal do Kanban
criar um logo de manifesto chamado: Yes We Kanban, que
David [1] explica: O slogan Yes We Kanban se destina a
enfatizarque voc tem permisso.Voc tempermisso para
tentarKanban.Voc tempermisso para modificaro seu processo.Voc tem permisso paraser diferente.Sua situao
nica e merece o desenvolvimento de um processo adaptadoe otimizado para o seu domnio, o seufluxo de valor, os
riscos que voc gerencia, as habilidades de sua equipe e as
demandasde seus clientes..
Portanto, podemos dizer que o objetivo de Kanban no
tornar a sua equipe gil, e sim, melhorar a forma de trabalho.
Ele tanto pode melhorar processos geis como tambm pode
melhorar processos tradicionais.

Qual a receita para ter sucesso com Kanban?


Para que qualquer pessoa que queira ser um agente de
mudana na sua organizao tenha sucesso rpido (ou, uma
melhoria rpida) e com baixa resistncia da equipe, com foco
na melhoria de processos em alguns pontos com o uso ou at
mesmo sem o uso do mtodo Kanban, preciso seguir algumas
etapas. De acordo com David, so elas:
1. Focar na qualidade;
2. Limitar a quantidade de trabalho em progresso;
3. Entregar frequentemente;
4. Balancear demanda com a capacidade mxima;
5. Priorizar tarefas;
6. Atacar fontes de variedade.
O autor orienta que essas etapas sejam seguidas na ordem em
que so apresentadas. A partir de agora, passa-se a discorrer
um pouco a respeito de cada uma delas.

Focando na qualidade
Como os agentes de mudanas nas empresas de TI so geralmente pessoas com um background tcnico, essa tende a
ser uma das etapas mais fceis de ser implementada, principalmente por ser um problema bem entendido por todos. As
outras etapas desse guia [1] tendem a ter uma implementao
mais difcil porque dependem da colaborao de outras reas

Engenharia de Software Magazine - Kanban no desenvolvimento de projetos de software

agilidade

e equipes. Com isso, exigem que o agente de mudana tenha


muitas habilidades de negociao, articulao e bastante inteligncia emocional [1].
Os maiores geradores de retrabalho em desenvolvimento de
software so os defeitos causados principalmente pela baixa
qualidade das entregas. E, alm de um gerador de retrabalho,
baixa qualidade faz os clientes ficarem inseguros e a equipe
desmotivada.
O incentivo qualidade das entregas tem um grande
impacto na produtividade das equipes com altas taxas de
defeitos. Segundo David [1], em equipes verdadeiramente
ruins, somente concentrando-se na qualidade pode-se obter
uma melhoria de produtividade de at dez vezes.
Para David [1], tanto as tcnicas de desenvolvimentogil
como as abordagens tradicionais tm seu mrito para a
melhoria da qualidade. As principais prticas incentivadas
por ele para a melhoria da qualidade so:
1. Escrever testes automatizados, preferencialmente antes;
2. Revisar cdigo (Verificao);
3. Fazer atividades de anlise e design do software de forma
colaborativa;
4. Usar Design Patterns;
5. Usar ferramentas modernas de desenvolvimento.
Parece haver uma vantagem psicolgica em pedir para os
desenvolvedores escreveremtestes antes, porm, importante
ressaltarque tambm existem inmeros casos de sucesso com a
escrita dos testes aps a codificao.
Inspees ou revises de cdigo ajudam a melhorar tanto a
qualidade externa como, notadamente, a qualidade interna do
software. Todas as tcnicas tm o seu valor. Programao em
par e reviso por pares so alguns exemplos. No entanto [1], inspees de cdigo so melhores quando so feitas em pequenas
quantidades vrias vezes. David menciona [1] que ele costuma
encorajar as suas equipes a inspecionar cdigo, todos os dias, por
pelo menos 30 minutos.
Sem dvidas, quando toda a equipe trabalha em conjunto na
anlise dos problemas para as solues de design, a qualidade
superior do que quando apenas uma pessoa faz isso. Assim como
as inspees de cdigo, atividades de modelagem de software
devem ser feitas em pequenas quantidades, todos os dias.
Os padres de projeto de software, mais conhecidos pelo termo
original em ingls Design Patterns, descrevem solues para
problemas j conhecidos e recorrentes no desenvolvimento de
software orientado a objetos. O uso de padres de projeto garante
que defeitos de design sejam eliminados j no incio do projeto.
O uso de ferramentas modernas de desenvolvimento melhora
a qualidade porque a grande maioria dessas inclui funes de
anlise de cdigo esttica e dinmica, que evitam que os desenvolvedores introduzam problemas bsicos e j bem compreendidos,
como falhas de segurana, no software.

Limitando a quantidade de trabalho em andamento


fcil especular porque limitar a quantidade de tarefas em
andamento aumenta a qualidade. A complexidade do trabalho

do conhecimento, como em desenvolvimento de software,


cresce exponencialmente com a quantidade de trabalhos em
andamento. Tanto a transferncia como a descoberta de informaes no desenvolvimento de software conhecimento tcito
por natureza e criado durante sesses de trabalho colaborativo, face a face. A informao verbal e visual, mas em um
formato casual, como um esboo em um quadro branco.
Nossas mentes tm uma capacidade limitada para armazenar
conhecimento tcito. E, quanto mais tempo passa, h mais
falhas para recordar detalhes precisos. Assim, uma srie de
erros cometida. Equipes que trabalham de um modo gil,
em um mesmo espao de trabalho, tm uma maior facilidade
em reter o conhecimento tcito.
Mas, independentemente da forma de trabalho da equipe, o
conhecimento tcito se deprecia com o passar do tempo. Por
isso, tempos de espera (lead time) menores so essenciais para
os processos que envolvem muito conhecimento tcito. O foco
da reduo de trabalho em andamento est diretamente relacionado com a reduo dos tempos de espera (lead time).
Assim, podemos deduzir que haver menor depreciao
de conhecimento tcito quando temos menos trabalho em
progresso o que resultar em maior qualidade. Em resumo,
reduzindo a quantidade de trabalho em andamento, melhorase a qualidade e possibilita-se entregas mais frequentes. Isso
aumenta a confiana externa na equipe.
Alm de reduzir a quantidade de trabalho em andamento,
importante reduzir o tempo de uma iterao, pois isso tambm
trar um impacto positivo significativo na qualidade.Segundo
David [1], parece que existe uma relao entre a quantidade
de trabalho em andamento e a qualidade, ou seja, defeitos vo
aumentar com o aumento da quantidade de WIP. Portanto, faz
sentido que iteraes de duas semanas sejam melhores do que
iteraes de quatro semanas e que iteraes de uma semana
sejam melhores ainda.Iteraes mais curtas iro resultar em
entregas de maior qualidade.
Seguindo a lgica das evidncias apresentadas, se sabido
que limitar o WIP ir melhorar a qualidade, por que no introduzir poltica explcita para isso, deixando assim os gerentes
livres para se concentrarem em outras atividades? Essa justamente uma das propriedades do Kanban. Entretanto David
afirma [1] que ainda no existe nenhuma evidncia cientfica
desse resultado que foi observado apenas empiricamente.

Entregando frequentemente
Para entendermos a importncia dessa etapa, David apresenta
uma excelente analogia em seu livro [1]: Quando euensino
issonas aulas, eu gosto deperguntar s mulheresda classeo
que elas pensam sobre duas situaes depois deter umprimeiro encontro comum cara:
Situao 1: Eles tiveram um bom encontro, mas depois
disso ele no d sinais de vida a ela durante duas semanas.
Mas, ento, ele aparece em sua porta com um ramo de floreseum pedido de desculpas;
Situao 2: Eles tiveram um bom encontro e na mesma noite
a caminho de casa ele envia uma mensagem de texto a ela

Edio 45 - Engenharia de Software Magazine

15

Balanceando a demanda com a capacidade mxima


Construir um consenso em torno da necessidade de equilibrar
a demanda contra a capacidade da equipe crucial. No entanto,
para isso, preciso resolver problemas como a disfuno entre
os papis e as responsabilidades dos membros da equipe.
Essa etapa implica definir a taxa em que a equipe aceita novos
requisitos no processo de desenvolvimento de software para
corresponder com a capacidade em que a equipe pode entregar
cdigo de qualidade.
Quando se faz isso, fixa-se efetivamente a quantidade de
trabalho em andamento, permitindo efetivamente que seja a
equipe que crie a demanda de acordo com a sua capacidade
(sistema puxado).

Priorizando tarefas
Priorizar trabalho da rea de negcios, e no da rea de
TI da organizao. Assim, no deveria ser da competncia
de um gerente tcnico fazer isso. Entretanto, infelizmente,
comum a rea de negcios delegar a responsabilidade e deixar
um gerente tcnico priorizar o trabalho e depois culpar que o
gerente fez escolhas erradas.
Neste ponto,a ateno da gernciadeve-se voltar paraotimizaro valor entregueao invs de meramentea quantidadede
cdigoentregue.

Atacando fontes de variedade

16

interessante conhecer as motivaes que levaram David


Anderson a chegar at o mtodo Kanban para o Desenvolvimento de Software e, atravs da sua receita, entender o
porque da maioria das propriedades por trs do Kanban.
Essa metodologia tem sido um assunto recorrente e tende a
continuar sendo, j que uma forma eficiente de melhorar
continuamente a rea.
Se a sua empresa est com dificuldades para melhorar, no
importa se ela adota mtodos geis ou no, o Kanban pode
ser uma das alternativas para fazer isso com o mnimo de
resistncia, pois, alm de toda a simplicidade do mtodo, suas
propriedades promovem a colaborao.
Referncias
1. Anderson, D. (2010) Kanban: Successful Evolutionary Change for Your Technology Business.
Washington, Blue Hole Press.
2. Martin, R. (2011) The Clean Coder: A Code of Conduct for Professional Programmers. Indiana,
Prentice Hall.
3. Anderson, D. (2003) Agile Management for Software Engineering: Applying the Theory of
Constraints for Business Results. New Jersey, Prentice Hall.
4. Bernab, J. (2011) Mais comprometimento = menos produtividade? http://www.teamware.
com.br/blog/mais-comprometimento-menos-produtividade/
5. Vale, A. (2011) Kanban Explicado. http://www.slideshare.net/alissonvale/kanban-explicado
6. Wikipdia. TOC. http://pt.wikipedia.org/wiki/Teoria_das_restri%C3%A7%C3%B5es
7. Yoshima, R. (2011) Kaikaku Kaizen, http://blog.aspercom.com.br/2011/09/09/kaikakukaizen/
8. Papo, J. (2010) Porque Lean/Agile funcionam? http://josepaulopapo.blogspot.com/2010/03/
agile-lean-funciona-por-que.html
9. ABES (2011). O Mercado Brasileiro de Software em 2011. http://www.abes.org.br/UserFiles/
Image/PDFs/Mercado_BR2011.pdf
10. Corey Ladas (2007). Kanban systems for software development (Imagem) http://
leansoftwareengineering.com/wp-content/uploads/2007/08/kanban1.png

D seu feedback sobre esta edio!


A Engenharia de Software Magazine tem que ser feita ao seu gosto.
Para isso, precisamos saber o que voc, leitor, acha da revista!
D seu voto sobre este artigo, atravs do link:
www.devmedia.com.br/esmag/feedback

Engenharia de Software Magazine - Kanban no desenvolvimento de projetos de software

Feedback
eu
sobre e
s

Podemos entender como fontes de variedade tudo aquilo


que de alguma forma prejudica o desempenho do processo
de produo.
Atacar as fontes de variedade a ltima etapa da receita
porque alguns tipos de variedade exigem profundas mudanas
de comportamento e, consequentemente, uma alta resistncia
da equipe.
A dica para implementar essa etapa focar nas fontes de variedade que requerem pequenas mudanas de comportamento
e que podem ser aceitas facilmente pela equipe.
Segundo David [1], no se deve focar nessa etapa sem antes
implementar e dominar as primeiras cinco etapas da receita.
Resumindo, essa receita a forma que David [1] acredita que
uma equipe de desenvolvimento de software deve amadurecer: Em primeiro lugar, aprender a construir cdigo de alta
qualidade. Em seguida, reduzir o trabalho em andamento,

Concluso

D
s

Pequenos e frequentes gestosno custam quase nada, entretanto, eles constroem maisconfiana do quegrandes ecaros
gestos ocasionalmente. Portanto, realizar frequentemente
pequenas entregasde alta qualidade constri maisconfiana
para asequipes parceirasdo que entregas maiores, mas com
menos frequncia.

encurtar os lead times, e entregar (software funcionando)


com frequncia. Em seguida, equilibrar a demanda contra
a capacidade mxima, limitar a quantidade de trabalho
em andamento, e criar folga para liberar capacidade, o que
permitir a melhoria contnua. Ento, com isso funcionando
razoavelmente e continuamente otimizando a capacidade de
desenvolvimento de software, melhore a priorizao para
otimizar a entrega de valor..
O Kanban permite que voc implemente todas as seis etapas
dessa receita.

edio
ta

dizendo: Eume diverti muitoesta noite.Eu realmentequero


me encontrar com voc novamente. Posso ligar para voc
amanh? E, esse mesmo cara, segue ligando e enviando
mensagens dia aps dia.
Qual cara vocs acham que elas preferem?.

Fundamentos da Agilidade
Nesta seo voc encontra artigos voltados para a prtica de mtodos geis.

PMI versus Scrum


O equilbrio ser possvel?

De que se trata o artigo?


O artigo trata da utilizao em conjunto do
PMI e do Scrum para o controle de projetos.
O artigo voltado mais para o ambiente de
empresas que no so de TI, mas que a utilizam para atingir os seus objetivos.

Q
Luiz Carlos Vianna
luizcvianna@hotmail.com

Atua h mais de 13 anos na rea de TI,


em diversas reas - desde gesto, apoio
tcnico para a equipe de vendas, anlise e
levantamento de requisitos, consultoria de
processos e metodologias, planejamento
de arquitetura, desenvolvimento e testes.
Engenheiro Eltrico de formao, com psgraduao em administrao e especializao em gesto de projetos. Certificado
ScrumMaster, PMP, ITIL e COBIT.

uando falamos de melhoria da


produtividade e qualidade na
rea de desenvolvimento de
software, temos visto um embate entre
duas grandes vertentes: defensores da
gesto de projetos (com maior nfase
ao PMI), e defensores de mtodos geis
de desenvolvimento (mais fortemente,
o Scrum).
Com o crescimento do nmero de empresas (e gerentes de projetos) utilizando-se de metodologias de desenvolvimento geis para ampliar o portflio de
ferramentas de gerenciamento, alguns
voluntrios do PMI criaram um grupo
de pesquisas a respeito da utilizao
dessas metodologias em projetos.
Um dos subprodutos foi a criao
de uma certificao voltada para os
gerentes de projetos que buscavam se
aproximar das prticas geis.

Em que situao o tema til?


Este artigo til a todos que desempenham
papel como lderes em projetos de TI; a todos
os gerentes de projetos que precisam se relacionar com a rea de TI em seus projetos; a
todos aqueles responsveis por reas de TI que
estejam buscando uma melhoria na produtividade de seus processos; e a todos que querem
conhecer um pouco mais sobre metodologias
geis em ambientes organizacionais.

Resumo?
Atualmente, bastante tem se falado a respeito da utilizao do PMI com metodologias geis sendo inclusive tpico de discusso dentro do prprio PMI. A ideia deste
artigo dar um overview a respeito tanto
do PMI quanto do Scrum, e tentar mostrar
como ambas as propostas se encaixariam
em um projeto que lida com TI.

Edio 45 - Engenharia de Software Magazine

17

Pode-se at questionar a criao de uma prova, mas isso demonstra o interesse que as metodologias geis tm despertado
em toda a comunidade que lida com software.
Uma boa parcela das pessoas que atuam na rea de TI j
deve ter ouvido comentrios de pessoas que dizem que ambos
so incompatveis, e que apenas uma jogada de marketing.
Outros comentrios dizem que sim, eles so totalmente compatveis, e que quem no consegue ver isso no entendeu
nada de ambas. Mas afinal, d ou no d para integrar PMI e
metodologias geis?
Neste artigo, iremos falar um pouco sobre PMI e Scrum, tentar
encontrar semelhanas e diferenas, e verificar a possibilidade
de construir um ponto de equilbrio na busca de melhores
processos de desenvolvimento.

Breve introduo ao Scrum


O Scrum um processo interativo para o desenvolvimento de
aplicaes. Como caractersticas, podemos destacar:
Integrao com o cliente A equipe deve estar sincronizada
sempre com o proprietrio do produto para no perder o
foco;
Priorizao das atividades Fazer o que mais importante
para o cliente;
Desenvolvimento incremental As entregas devem ser
constantes e funcionais, para que o proprietrio possa avaliar
o que foi feito e obter valor rapidamente;
Equipes auto gerenciadas Cabe equipe decidir como
fazer e o ritmo que deve seguir.
No Scrum, o cliente (representado pelo papel do Product Owner) inicialmente define quais so as suas necessidades e monta
uma lista chamada Product Backlog. Confira o fluxo do Scrum
na Figura 1. O Product Owner rene-se ento com a equipe, e
explica os itens para ela.
A equipe adiciona os itens necessrios do ponto de vista
tcnico (por exemplo, demandas de segurana obrigatrios),
e determina uma estimativa de tempo para a construo de
cada item.
Com base nessa estimativa de tempo e na importncia para o
negcio, o Product Owner prioriza os itens que devero seguir
no prximo ciclo (ou Sprint). No Scrum, todos os Sprints tm a
mesma quantidade de tempo pr-determinada (fixo, determinado em acordo, e em geral entre 15 a 21 dias).
A equipe agora tem uma lista de itens que devem ser realizados. Ela deve ento se organizar para a realizao das
atividades.
Neste Sprint, a equipe deve se esforar para entregar o que
combinou com o Product Owner. O produto do ciclo deve
ser um pedao de software inteiramente funcional caso
contrrio, o item no ser considerado completo, e ir para o
prximo Sprint.
Por fim, aps a entrega das novas funcionalidades, a equipe se
rene para analisar o que aconteceu no ciclo, e entender o que
poderia ser melhorado no processo. Esta reunio chamada
de Retrospectiva.

18

Engenharia de Software Magazine - PMI versus Scrum

Figura 1. Ciclo de desenvolvimento Scrum

Breve introduo gesto de projetos baseada no


PMBOK
Com o objetivo de estudar e difundir as melhores prticas de
gerenciamento de projetos, o Project Management Institute (PMI)
analisou projetos de diversas reas (engenharia, desenvolvimento de software, manufatura, etc.) e identificou um conjunto
de processos e prticas que, se bem trabalhados e monitorados,
costumam levar ao sucesso dos projetos. Ele ento agrupou
essas informaes em um livro, que ficou conhecido como
Project Management Book of Knowledge (PMBOK).
Antes de entendermos o que gesto de projetos, vamos entender qual a definio de projeto. Segundo o PMBOK, projeto
um esforo temporrio empreendido para criar um produto,
servio ou resultado exclusivo. Da, pode-se destacar:
Esforo temporrio Entenda que temporrio no significa
curto. Um projeto pode levar anos para ser feito. Entretanto, ele
deve ter comeo, meio e fim. Algo que se repete continuamente
NO caracteriza um projeto;
Cria um produto, servio ou resultado especfico Um
projeto deve sempre gerar um resultado nico, algo que no
existia antes. Sendo assim, construir um sistema que integra
a parte contbil da empresa um projeto. Garantir a operao
do software e responder ao chamado dos usurios no.
Vamos ilustrar esse conceito, dando trs exemplos:
1. Construo de um mdulo contbil em um ERP corporativo;
2. Criao de uma campanha de marketing, para promover a
marca da empresa. Essa campanha ir envolver a criao de
um portal para os clientes e uma campanha de divulgao
com os fornecedores;
3. Atendimento de um chamado para a correo de um bug
no ERP corporativo.
No primeiro exemplo, fcil identificar que um projeto, cujo
produto o prprio mdulo contbil. J no segundo exemplo, a
fronteira menos definida: O produto do projeto a campanha
de marketing. Tanto o portal quanto a elaborao do material
de divulgao so subprodutos do projeto (e podem, inclusive,
serem separados em subprojetos). A realizao da campanha
em si pode se tornar uma atividade de rotina na empresa e,
portanto, deixa de ser um projeto.

agilidade

Por fim, o ltimo exemplo NO considerado um projeto, j


que uma atividade rotineira (entretanto, em alguns casos, a
identificao de um bug pode trazer a necessidade de criao
de um projeto para corrigir o problema).
Agora que entendemos a definio do que seria um projeto,
vamos ver qual seria a definio de gerenciamento de projetos,
extrada do PMBOK: Aplicao de conhecimento, habilidades, tcnicas e ferramentas s atividades do projeto a fim de
alcanar os requisitos do projeto. Sendo assim, gerenciar um
projeto compe-se das seguintes atividades:
Identificar quais so os requisitos (aonde queremos chegar?);
Identificar as mtricas ou indicadores de sucesso (como saber
se chegamos?);
Traar planos (o que temos que fazer para chegar l?);
Adaptar os planos s mudanas nas necessidades e corrigir
os desvios (estamos na direo certa?).
Neste ponto, o PMBOK um guia para o gerente de projetos.
Ele traz um conjunto de processos e prticas que so aplicveis
a projetos bem sucedidos em diversas reas. Na verso atual
(4.0), ele traz um conjunto de 32 processos reunidos em cinco
grupos de processos. Cada um desses grupos est atrelado a
um momento dentro da fase do projeto. Esses grupos so:
Iniciao: Identifica tudo o que precisa ser feito ANTES de se
iniciar o projeto. Isso compreende: obter a aprovao do cliente
para o incio do projeto, identificar quais so os objetivos por
trs do projeto e mapear pessoas que possam impactar (positiva ou negativamente) o andamento do projeto;
Planejamento: Neste ponto, devemos traar um plano de
como vamos fazer o que deve ser feito;
Execuo: J temos tudo em mos, ento precisamos colocar
o que foi planejado em execuo;
Monitoramento e Controle: Precisamos garantir que no
ir haver desvios de rumo. Caso haja necessidade de corrigir alguma coisa, precisamos fazer as mudanas de rumo
apropriadas;
Encerramento: No podemos considerar que um projeto (ou
fase) foi entregue se no tivermos o aceite formal do projeto.
Alm disso, esse o ponto em que encerrarmos contratos (em
caso de subcontrataes), e fazemos uma reviso formal para
que possamos aprender com os nossos erros.
Para quem mais familiarizado com administrao, isso
nada mais que uma verso do modelo PDCA (Plan-DoCheck-Act).
Alm disso, esses momentos se intercalam, de forma que cada
parte do projeto pode estar em um momento diferente. Para
dar um exemplo: em um projeto de um grande site podemos
subcontratar uma empresa de design para fazer o layout do
mesmo. Assim que ela nos entrega o layout, validamos o que
foi entregue e finalizamos o contrato processos tpicos de
Encerramento mesmo quando ainda estamos no meio da
Execuo do desenvolvimento do cdigo.
Nem todo projeto composto, obrigatoriamente, de uma nica
fase. De acordo com a nossa necessidade, podemos ter uma ou

mais fases em um projeto. Podemos notar aqui certa semelhana


entre as entregas sequenciais do Scrum e as fases do PMBOK.
Alm disso, os processos tambm podem ser classificados
pelas reas de conhecimento ao qual eles se referem, que
podem ser vistas na Figura 2. Cada uma dessas reas de
conhecimento se refere a algo que o gerente de projetos deve
gerenciar durante o projeto.
Os processos da rea de integrao so comuns e integram
as demais reas. Nela temos os processos ligados a organizar
o planejamento, gerir mudanas, organizar indicadores de
progresso e atuar sobre eles, e como encerrar um projeto.
Considera-se que esta a funo primria de um gerente de
projetos (i.e. ser o integrador).

Figura 2. PMI reas de conhecimento

Isso no significa que os conhecimentos, as habilidades e os


processos descritos sempre devem ser aplicados de forma uniforme em todos os projetos. Para qualquer projeto especfico, o
gerente de projetos, em colaborao com a equipe do projeto,
sempre responsvel por determinar quais processos so
apropriados e o grau de rigor apropriado para cada um.
E agora, possvel mesmo compatibilizar ambos os mundos?
Afinal, d ou no d para integrar PMI e Scrum?

Foco no objetivo
A primeira coisa que precisamos entender que gerenciar
um projeto muito mais do que fazer software.
Muitas pessoas (e, infelizmente, alguns gerentes de projeto)
acreditam que o sucesso de um projeto depende apenas se ele
foi entregue atendendo s restries de tempo, prazo, custo e
qualidade.
Na realidade, a viso moderna de gesto nos diz que para que
possamos considerar um projeto como um sucesso, temos que
poder responder positivamente s duas perguntas abaixo:
O produto do projeto atendeu as necessidades do cliente?
O cliente est contente com o resultado pelo menos o suficiente para continuar pagando o seu salrio ou contratando
sua empresa?

Edio 45 - Engenharia de Software Magazine

19

Ou seja, no adianta construirmos um projeto que um case


do ponto de vista da metodologia, se o produto no agregar
valor ao cliente. Trazer valor para quem paga o que vai garantir que nos perpetuemos na empresa/mercado.
Para atendermos a esses objetivos, precisamos olhar muito
mais do que apenas o produto que construmos (seja uma casa,
um carro, ou um software). Para termos sucesso real, precisamos
olhar para os fatores externos ao projeto. Precisamos:
Identificar quem ser impactado pelo projeto (vulgos
stakeholders);
Garantir que o projeto tenha os recursos necessrios para
ser realizado (equipe, verba, sala, etc.);
Determinar e garantir a infraestrutura necessria para sua
operao (sejam, por exemplo, servidores, novos processos
operacionais, treinamento interno da equipe de operao);
Gerenciar as expectativas das pessoas (seja o time do projeto, reas
usurias, cliente, associaes externas como sindicatos, etc.);
Identificar a quem seria interessante auxiliar/prejudicar o
andamento do projeto, e atuar de forma proativa, visando
ampliar/minimizar o impacto de suas aes;
Entre outros fatores.
Claro que, grande parte dos projetos de TI so pequenos,
envolve um pequeno nmero de pessoas e recursos e utilizam
uma infraestrutura muitas vezes pr-existente. Assim sendo,
raramente nos preocupamos com esses fatores.
Mas uma anlise inadequada pode virar uma bomba relgio
na empresa. Podemos ter cenrios aonde, por planejamento
inadequado, podemos ter um problema nas mos.
Para citar um exemplo: por no termos realizado uma anlise
adequada de utilizao, ao colocarmos o nosso projeto no ar o
banco de dados da empresa (compartilhado com outros sistemas) fica sobrecarregado e para, comprometendo o fechamento
mensal. O problema pode at ser resolvido rapidamente, mas
o custo do impacto gerado j foi incorrido.
Nesse aspecto, podemos ver que as prticas do PMBOK
ampliam as ferramentas do Scrum trazendo uma viso mais
ampla do negcio.

O gerente de projetos no Scrum


Ken Schwaber, um dos pais do Scrum, define o Product Owner
como sendo o responsvel por representar os interesses de
todos que tenham algum interesse no projeto ou seu produto
resultante. Ele obtm os fundos para o projeto, cria a lista de
requisitos, os objetivos de retorno do investimento (ROI) e
planos de liberao..
Por aqui voc j pode notar que, dependendo do projeto, o
gerente de projetos tem uma grande afinidade com o papel
do Product Owner. Apesar dele no ser a pessoa que melhor
conhece o negcio, a pessoa que conhece a empresa e tem
o respaldo poltico para agir em nome do patrocinador do
projeto (poder este declarado no termo de abertura) e poder
para mobilizar a empresa em uma direo.
E com relao ao papel de ScrumMaster? Ser que ambos
podem se misturar? Novamente, citando Ken Schwaber, temos

20

Engenharia de Software Magazine - PMI versus Scrum

que O time uma estrutura auto gerenciada, auto organizada


e multi funcional, responsvel por descobrir como transformar
o Backlog do produto em um incremento de funcionalidades
dentro de uma interao. Os membros do time so responsveis, coletivamente, pelo sucesso de cada interao e do projeto
como um todo.
Destacamos o termo auto gerenciada porque no Scrum todos
os membros da equipe so responsveis pelas decises e pelos
planos de ao. E, assim sendo, so tambm corresponsveis
pelo sucesso de suas decises.
O lder (ScrumMaster) ento no visto como algum responsvel por tomar decises, montar planos de ao ou dar
ordens todas essas so responsabilidades da equipe. O lder
possui apenas um papel adicional: agir como facilitador tanto
dentro do time (para que a equipe no se perca em conflitos)
e entre a equipe e o ambiente externo (o ambiente externo
representado aqui pelo Product Owner). Ou seja, ele um
representante em uma equipe auto gerenciada.
Olhando sob o ponto de vista tradicional, gerentes esto em
outro grau hierrquico. Raramente as pessoas sero capazes de
separar esse fato de suas rotinas. Sendo assim, o fato de haver
dentro do time algum em uma hierarquia diferente pode
atrapalhar o auto gerenciamento do time e com isso perdermos
a prpria integrao que torna um grupo de pessoas um time
de desempenho diferenciado. Isso pode se transformar em um
desafio para o gerente de projetos, o que pode no trazer bons
resultados ao projeto.
Alm disso, em projetos grandes, raramente sobrar tempo
ao gerente de projetos para estar constantemente com a equipe,
j que em geral eles tm outras responsabilidades como: lidar
com fornecedores, reunir-se com os interessados, se envolver
com a poltica da organizao, identificar e enderear riscos
internos/externos ao projeto, cobrar recursos que foram prometidos, comunicar a diretoria sobre o andamento do projeto,
etc. Ou seja, como ele pode no estar disponvel para a equipe
sempre que necessrio, ao invs de tornar-se um facilitador
ele pode acabar atuando mais como um gargalo ao desenvolvimento do projeto.
Seria muito bom ento que o ScrumMaster fosse algum da
prpria equipe de desenvolvimento, algum que conhece a rotina diria da equipe e que tem o apoio desta. E para incentivar
a auto-organizao, um bom passo seria que este seja indicado
pela prpria equipe a qual ele ir representar.

Como controlar o escopo?


Um dos grandes pesadelos do gerente de projetos a mudana de escopo. Mudanas de escopo causam retrabalho,
atrasos, e aumentam o custo e os riscos do projeto. Precisamos
compreender que o antigo mantra do gerenciamento no prazo, no oramento, dentro do escopo no realista para um
ambiente dinmico.
Muito provavelmente iremos ter mudanas profundas
nos requisitos durante toda a vida do projeto. Seja porque
o cliente ainda no tem uma ideia completamente formada
sobre o que o produto (esse ponto ainda mais grave no

agilidade

desenvolvimento de produtos abstratos como software), porque ocorrem mudanas de legislao, polticas e de mercado
(cada vez mais comuns nos dias de hoje), ou o surgimento de
novas tecnologias.
O prprio PMBOK mostra sua preocupao com o inesperado. Em algumas situaes, ele nos sugere quebrar nosso
projeto em fases progressivamente mais detalhadas conforme
caminhamos (o chamado Planejamento por Ondas Sucessivas).
Alm disso, vrios processos de controle de mudanas so
apresentados.
Infelizmente, o PMBOK no explcito o bastante para nos
dizer COMO fazer. Sendo assim, vrios gestores e/ou crticos simplesmente deixam esse ponto para segundo plano, e
utilizam o PMBOK apenas como a velha cartilha do modelo
waterfall. Alm disso, a maioria das ferramentas auxiliares
usadas para o controle do projeto (como o WBS e o grfico de
Gantt) torna-se bastante difcil de ser atualizada, dependendo
do grau de detalhes que o gestor utilizar para controlar o seu
projeto.
Neste aspecto, o Scrum pode nos auxiliar bastante. Por sua
prpria natureza, como se o Scrum nos dissesse: Ei, como eu
posso te dizer o que eu vou te entregar a daqui a seis meses se
nem voc sabe o que vai precisar?. Ao invs de controlar o que
precisa ser feito a partir das TAREFAS (como construir a tela
XPTO), o Scrum sugere controlar o que precisa ser feito atravs
das FUNCIONALIDADES que devem ser agregadas.
Alm disso, ao invs de tentar congelar o escopo do projeto
por meses, o Scrum busca congelar pequenos trechos do projeto
por vez e atuar neles o chamado Sprint. O resto do projeto
ainda indefinido e, como tal, s nos preocupamos em defini-lo
melhor quando nos aproximarmos deste ponto.
Buscamos fazer, mais para o comeo, as atividades mais
prioritrias para o cliente. Para isso, o cliente (Product Owner)
o responsvel por priorizar as atividades. Para priorizar,
utilizamos sistemas de pesos e faixas de corte (por exemplo,
itens obrigatrios, itens que podem ser entregues em uma
segunda fase e itens opcionais).
Ao trabalharmos com entregas constantes e focando apenas
no que mais prioritrio para o cliente naquele momento,
tornamos visvel o que estamos fazendo e, caso as prioridades
mudem, iremos dispender menos tempo em replanejamento.
Alm disso, podemos reavaliar o produto de uma fase e, caso
necessrio, atuar em cima do nosso processo rapidamente para
corrigir/evitar problemas e reavaliar o prazo ou at mesmo
cancelar o projeto.

Como estimar prazos?


No devemos nos enganar: A primeira pergunta do diretor
comercial da sua empresa quando pedir um projeto quando
ele estar pronto (segunda, caso seja um projeto contratado
externo).
Isso tem relao, muitas vezes, com a prpria estrutura de
planejamento da empresa. Como dito anteriormente, o software muitas vezes apenas uma pequena parte de um projeto
como um todo. A empresa precisa treinar as pessoas, preparar

material de marketing, adequar normas e procedimentos manuais, e muitas outras atividades antes que o software possa
entrar no ar.
Claro que, em um primeiro momento, qualquer estimativa
que fizermos ser sempre uma estimativa de elevada incerteza.
As estimativas que temos no comeo do projeto s sero refinadas durante a vida do projeto, para refletir detalhes adicionais.
Entretanto, para quem melhor perguntar quanto tempo uma
tarefa ir durar? Para o gerente que tem centenas de atividades
na cabea, ou para a pessoa que ir realizar a tarefa?
Sendo assim, a forma mais precisa de fazer essa estimativa
definir o que deve ser feito (definido como funcionalidades,
como por exemplo permitir ao cliente agendar um voo)
e perguntar diretamente a quem vai fazer a tarefa quanto
tempo ir levar para cumprir uma atividade. No PMBOK isto
est previsto, e chama-se de estimativa bottom-up, e dentre as
alternativas ela considerada a mais precisa. J o Scrum nem
leva em conta as demais alternativas, sendo papel da equipe
definir estimativas para cada um dos itens do backlog necessrios para o desenvolvimento do produto.
De posse das estimativas de tempo de desenvolvimento e
da prioridade atribuda a cada funcionalidade pelo responsvel pelo produto, agrupamos as nossas atividades dentro
de Sprints, e temos uma ideia de quantos ciclos (ou Sprints) o
conjunto de atividades necessrio ir levar para ficar pronto.

Como estimar custos?


O Scrum no entra em detalhes na questo do custo do projeto,
mas precisamos lidar com os custos envolvidos no desenvolvimento principalmente quando produzimos sistemas para
um cliente.
Em um projeto de TI, na maior parte das vezes o principal
custo est relacionado aos gastos com mo-de-obra. Para os
demais custos (podemos ter gastos com servidores, contratao
de funcionrios, taxas, seguros e outros), podemos utilizar os
conceitos identificados no PMBOK.
No mundo ideal, estamos trabalhando em paralelo com a
empresa cliente (ou somos funcionrios do cliente) e cada
funcionalidade necessria orada em alguma unidade de
medida pela equipe, e o valor de cada ponto nesta unidade
multiplicado por um preo fixo. Caso haja alguma incoerncia
na estimativa, como uma estimativa incorreta, os dois lados
reveem os motivos e os custos adicionais so compartilhados
por ambas as partes.
Podemos discutir o quanto quisermos a respeito das virtudes
dos modelos de contrato a custo reembolsvel ou contrato por
tempo e material (bem semelhantes ao descrito acima) para
a estimativa de projetos de TI, mas muitas vezes ser difcil
convencer as empresas a aceitar tipos de contratos diferentes
de contratos de preo fixo. Esse o tipo de contrato mais usual
no mercado, e essa ser uma situao comum com a qual o
gerente de projetos ir se deparar.
Uma abordagem bastante comum na literatura fixar pacotes de pontos. Nesta abordagem, o comprador efetivamente
est comprando uma potencialidade de desenvolvimento.

Edio 45 - Engenharia de Software Magazine

21

22

Engenharia de Software Magazine - PMI versus Scrum

Referncias
Project Management Institute. (2008). Um guia do conhecimento em gerenciamento de
projetos (PMBOK Guide) 4a Edio
Mike Cottmeyer. (2009). Agile PMP: Managing Software Projects in the Face of Uncertainty
Kelley Hunsberg. (2011). Change is Good
Michele Sliger. (2008). Agile Project Management and the PMBOK Guide
Ken Schwaber. (2004). Agile Project Management with Scrum
Mike Griffiths. (2004). Utilizing Agile Principles alongside A Guide to the Project Management
Body of Knowledge (PMBOK Guide) for better project execution and control in software
development projects.
Ron Armstrong Requirements of a Self-Managed Team Leader
http://www.leader-values.com/Content/detail.asp?ContentDetailID=1004

D seu feedback sobre esta edio!


A Engenharia de Software Magazine tem que ser feita ao seu gosto.
Para isso, precisamos saber o que voc, leitor, acha da revista!
D seu voto sobre este artigo, atravs do link:
www.devmedia.com.br/esmag/feedback

Feedback
eu
sobre e
s

Com relao gesto de mudanas, a abordagem tradicional


do PMBOK de buscar variaes em cima do plano no se encaixa bem em um cenrio dinmico. Isso porque se considera que
o plano est correto, e o que foge ao plano precisa ser analisado
e compreendido e a causa raiz deve ser determinada.
Em ambientes dinmicos, o plano representa apenas a melhor
previso que pudemos realizar, dados todos os fatores desconhecidos envolvidos. Sendo assim, assumir a mudana como norma
parece ser muito mais efetivo do que reagir mudana.
Entretanto, como conseguimos encaixar a adaptao
mudana ao nosso planejamento? Como saber o impacto que
uma mudana vai trazer ao nosso projeto? E como eu cobro
por isso?
Conforme comentado anteriormente, no Scrum o nico momento em que se congela as atividades durante um Sprint.
Fora deste perodo, o responsvel pelo produto possui liberdade para repriorizar, incluir ou excluir atividades.
Caso haja espao no cronograma, as alteraes so ento
absorvidas pelo cronograma e custos atuais. Mas na maior
parte dos casos no haver espao disponvel. Neste caso,
como devemos agir?
Neste caso, as atividades menos prioritrias so deslocadas
para baixo na escala, e caso no haja prazo suficiente ou outras
atividades levem mais tempo do que o previsto, as atividades
so canceladas de baixo para cima (ou seja, da menos importante para a mais importante). Como a lista de prioridades est
disponvel para todos, o gerente deve apenas comunicar aos
interessados at quais funcionalidades sero implementadas
na verso, e quais ficaro de fora.
Se analisarmos o PMBOK, este fluxo basicamente equivale ao
Comit de Mudanas, mas neste caso o rbitro responsvel pela
deciso do comit seria o prprio Product Owner, e as mudanas
solicitadas seriam consideradas pr-aprovadas se as alteraes
efetuadas no impactarem na quantidade total de trabalho
do projeto. Caso haja impacto no total de trabalho, acordos
comerciais podem ser revistos.

Neste artigo, pudemos ver como o Scrum pode ser utilizado


pelo gerente de projetos de forma a trazer ganhos de produtividade no desenvolvimento de software e como compatibilizar
a definio e a gesto de escopo, tempo e custo, alm de como
enxergar a gesto de mudanas sem ferir os padres de processo descritos no PMBOK.
Alm disso, vimos como a gesto de projetos acaba tendo
uma preocupao mais ampla que o Scrum quando nos prope
pensar no impacto do projeto como um todo na empresa, nos
usurios, clientes, fornecedores e comunidades. Sendo assim,
o que TI est fazendo muitas vezes apenas a ponta do iceberg, ou seja, apenas uma frao do trabalho total que ser
necessrio para atingir os objetivos da empresa.
Como precisamos ter algum capaz de advogar por isso no
dia-a-dia do desenvolvimento, o artigo prope que o gerente de projetos se afaste do controle das atividades, para se
aproximar mais do papel do responsvel pelo produto final,
aproximando-o do papel de Product Owner.

D
s

Como gerir mudanas?

Concluso

edio
ta

Caso sejam necessrias alteraes de escopo, caso o saldo de


pontos estejam dentro do definido em contrato, as alteraes
solicitadas pelo cliente podem ser feitas desde que outras
atividades sejam excludas. Este tipo de contrato uma abordagem interessante, e pode permitir empresa cliente se adaptar
para lidar com um fornecedor que trabalha sob este modelo
de desenvolvimento.

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

Ferramentas para Gesto de Projetos


Uma anlise comparativa das principais ferramentas

De que se trata o artigo?

Aline da Silva Tinoco


aline@alinetinoco.com

Ps Graduada em Gerncia de Projetos em


Engenharia de Software Centro de Ensino
Superior de Juiz de Fora.Tecnloga em Sistemas para Internet Faculdades Integradas
Vianna Jnior. Consultora de Marketing Digital - 8Ps . Atua como Gerente de Projetos na
Ato.interativo agncia digital.

Marco Antnio Pereira Arajo


maraujo@devmedia.com.br

Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ,


Especialista em Mtodos Estatsticos
Computacionais e Bacharel em Informtica
pela UFJF, professor dos Cursos de Bacharelado em Sistemas de Informao do CES/
JF, da FMG e da USS, professor do curso de
Bacharelado em Cincia da Computao da
FAGOC, professor do curso de Tecnologia
em Anlise e Desenvolvimento de Sistemas
da FAA, Analista de Sistemas da Prefeitura
de Juiz de Fora, Editor da Engenharia de
Software Magazine.

Aborda a importncia do uso de ferramentas para


gesto de projetos com o objetivo de mostrar as
principais funcionalidades das mais populares.
Neste contexto, o artigo destaca a importncia
do gerenciamento de um projeto e a utilizao
de ferramentas que podem auxiliar nessa tarefa,
alm de ressaltar suas principais caractersticas.

Em que situao o tema til?


O tema se torna fundamental para gerentes
e empresas que buscam aprimorar a gesto
de seus projetos levando em considerao
fatores como escopo, tempo, recursos, custos
e qualidade, entre outros.

dades, ferramentas e tcnicas. Com o uso de


metodologias, a implantao da cultura de
projetos pode ser realizada para garantir a
aplicao dos princpios de gerenciamento
de projetos de forma padronizada, buscando atender da melhor forma s necessidades
das organizaes. Neste sentido, este artigo
abordar cinco das principais ferramentas de
gesto de projetos, suas vantagens e desvantagens apresentadas. Alm disso, ir destacar
a importncia da gesto de projetos dentro
das organizaes, ressaltando as funes que
o gerente deve exercer, como o planejamento
de aes, a definio de processos e tcnicas,
o uso de ferramentas adequadas ao projeto e
suas principais funcionalidades.

Resumo?
O gerenciamento de projetos deve ser feito
com a aplicao de conhecimentos, habili-

cada dia cresce a necessidade


de adoo do gerenciamento de
projetos em pequenas, mdias
e grandes empresas. Sua importncia
est relacionada reduo de custos
no desenvolvimento de projetos, cumprimento de prazos, eficcia no resultado final e mensurao de resultados.

Alm disso, importante destacar que


o gerenciamento de projetos precisa
evoluir e se adaptar constantemente s
necessidades cada vez mais dinmicas
das organizaes.
O desenvolvimento de software uma
atividade complexa, envolvendo inmeros fatores que so imprevisveis e de

Edio 45 - Engenharia de Software Magazine

23

difcil controle, como volatilidade dos requisitos do software e


prazos. Esses fatores fazem com que o produto final no atenda
s expectativas ou, at mesmo, s necessidades do cliente, alm
de exceder o prazo e o oramento previsto. A partir disso, um
gerenciamento eficaz tem se tornado de fundamental importncia para se obter sucesso no desenvolvimento de software.
Para que um projeto de software seja bem sucedido, necessrio que alguns parmetros sejam analisados como, por
exemplo, o escopo do software, os riscos, os recursos necessrios s tarefas a serem realizadas, os marcos de referncia a
serem acompanhados, os esforos e custos aplicados, alm da
sistemtica a ser seguida, entre outros fatores.
Atualmente, a prtica do gerenciamento de projetos est em
crescimento, devido ao surgimento de ferramentas open source
(cdigo aberto de software). A principal funo dessas ferramentas administrar de forma mais organizada e eficiente os
processos de um projeto e sua gesto. Entretanto, nem sempre
essas ferramentas possuem os recursos necessrios para uma
gesto completa, que no permitem a visualizao de um projeto como um todo. O conhecimento e aplicao destas tcnicas
tm relao direta com a garantia de obteno das metas das
organizaes (PRADO, 2009).
Quando se aplica o gerenciamento de projetos ao desenvolvimento de um projeto de software, importante que o gerente
e a equipe visualizem todo o processo. Alm disso, alguns
parmetros precisam ser corretamente analisados, como por
exemplo, o escopo do projeto, riscos, recursos necessrios,
tarefas, indicadores para acompanhamento, esforos e custos,
e a linha de raciocnio a ser seguida.
Uma caracterstica necessria nos profissionais envolvidos
com gerncia de projetos o dinamismo, a sua capacidade
de lidar com mltiplas tarefas e a habilidade de no perder
nenhum detalhe. Muitas vezes organizar datas e contedo de
uma nica tarefa a ser realizada em longo prazo exige uma
viso estratgica do profissional (CIRIACO, 2009).
Para auxiliar na coordenao de todas as informaes que
envolvem o projeto do incio ao fim, surgem diversas ferramentas, tanto desktop quanto online, que oferecem recursos para a
organizao de suas tarefas, estipulando metas e, em alguns
casos, com suporte para trabalhos em equipe.
O uso de ferramentas de gesto de projetos torna-se indispensvel para garantir resultados positivos no desenvolvimento de
um projeto, pois permite saber quais mtodos e processos de
trabalhos utilizados, e visualizar informaes em tempo real ao
alcance de toda a equipe envolvida. Porm, preciso conhecer
os recursos tecnolgicos de cada ferramenta e analisar as reais
necessidades da implantao de acordo com o projeto.
Ao optar pelo uso de ferramentas de gesto de projetos,
as organizaes podem estar certas de que esto investindo
corretamente, executando projetos com sucesso e resultando
em vantagens planejadas, maximizando a utilizao de recursos, fornecendo ferramentas de colaborao para conectar
equipes dispersas e mantendo visibilidade e controle sobre
o projeto atravs de relatrios e mensurao de resultados
(PAUMGARTTEN, 2010).

24

O Gartner Group divulgou o resultado de uma pesquisa


realizada em 2010 sobre os problemas enfrentamos pelas organizaes quando no implantam ferramentas para auxiliar
na gesto de projetos. Os resultados foram:
51% de todos os projetos extrapolam o oramento ou ultrapassam o prazo final;
15% dos projetos falham completamente;
94% dos entrevistados reportaram que implementando uma
metodologia de gerenciamento de projetos, adicionou valor s
suas organizaes;
Software de gerenciamento de portflio de TI pode reduzir
custos de 2 a 5%, melhorar produtividade entre 20 e 25%, e
elevar de 10 a 15% a receita para projetos mais estratgicos.
Grande parte dos problemas acima poderia ser minimizada
no s com uma boa metodologia adaptada s necessidades das
organizaes. Alm disso, muito importante ter uma ferramenta
adequada a essa metodologia. A ferramenta deve ser realmente
adequada metodologia de acordo com suas necessidades e apoiar
a metodologia, e no o contrrio (PAUMGARTTEN, 2010).
A implementao de uma ferramenta de gesto de projetos
deve ser conduzida como um projeto, com incio, meio e fim.
Todas as reas do conhecimento com seus processos, entradas,
ferramentas e tcnicas, e sadas podem e devem ser utilizados
para gerenciar um projeto dessa natureza (VIEIRA, 2008).
Em 2009 foi realizado um Estudo de Benchmarking pelo PMI
Brasil sobre a prtica do gerenciamento de projetos e utilizao
de ferramentas em trezentas empresas brasileiras. As empresas
participantes responderam a um questionrio eletrnico na
Internet com pouco mais de cem perguntas, as quais foram
utilizadas como base para o desenvolvimento dessa pesquisa.
O resultado mostrou que 91% dessas organizaes possuem
baixo nvel de resistncia em relao prtica da gesto de
projetos, e que 80% dessas empresas utilizam ferramentas para
gerenciar projetos. A Figura 1 lista as principais ferramentas
utilizadas por essas empresas, de acordo com a pesquisa.
Dessas ferramentas, cinco foram selecionadas para descrever
seus principais recursos e funes.

Project Builder
De acordo com o site dessa ferramenta, a Project Builder foi
desenvolvida pela empresa homnima e baseada nas prticas
do PMI. Funciona em plataforma web e utilizada na gesto
de projetos, podendo ser acessada de qualquer lugar. Essa
ferramenta se encaixa em pequenas e mdias empresas de
diversos setores e possui recurso como soluo cloud computing
(computao em nuvem). O foco principal a integrao de
pessoas envolvidas (equipe, clientes e fornecedores), alm da
viso do plano estratgico, ttico e operacional dos projetos.
O software permite integrao com o MS Project, podendo
exportar e importar os projetos do software da Microsoft. Tambm permite exportao de seus relatrios e EAP (estrutura
analtica de projetos, Figura 2) para o Excel. A Figura 2 mostra
a tela inicial da ferramenta, com projetos, responsveis, prazo,
status e prioridades.

Engenharia de Software Magazine - Ferramentas para Gesto de Projetos

Gesto de Proje tos

As principais funes de apoio ao gerente de projetos so:


Funcionalidades configurveis de
acordo com a maturidade e caractersticas dos projetos;
Estrutura Analtica do Projeto (disponvel em formato grfico) e detalhamento dos componentes em Subprojetos,
fases, marcos, produtos, atividades;
Dependncia entre projetos;
Gesto de recursos;
Pessoas envolvidas e matriz de responsabilidades em todos os nveis da EAP;
Mapa de alocao e Histograma de
pessoas;
Definio de calendrios (projetos e
pessoas);
Cronograma Gantt;
Controle de receitas;
Metas e avaliao de resultados do
projeto e de seus componentes (metas
qualitativas e quantitativas);
Tratamento de Riscos (identificao,
anlise e respostas);
Indicadores de desempenho;
Registro histrico do projeto e de seus
componentes;
Integrao com email;
Envio de relatrios de progresso e
controle em diferentes formatos.
Na Project Builder, os colaboradores podem visualizar os projetos em que esto
alocados. Nessa rea, eles podem e devem informar tudo o que est ocorrendo,
como comentrios sobre reunies com o
cliente, incio e concluso de atividades,
esforo realizado, lies aprendidas.
Com isso, o gerente consegue saber
como os projetos esto se desenvolvendo
dentro da organizao.

Microsoft Project
A ferramenta Microsoft Project (ou MS
Project) foi criada pela Microsoft em 1985
(primeira verso). Veio sofrendo modificaes em seu layout at as verses atuais,
como mudanas funcionais, no intuito de
aumentar a oferta de servios e recursos
relacionados gesto de projetos. Os
focos da MS Project so: tempo (datas, durao do projeto, calendrio de trabalho),
Grfico de Gantt, modelo para clculos
relacionados a planejamento, Diagrama
da Rede, Custos (fixos, no fixos, outros)

Figura 1. Softwares de apoio ao Gerenciamento de Projetos mais utilizados

Figura 2. Estrutura analtica do projeto (EAP) no Project Builder

e uma srie de relatrios. Utiliza a mesma


interface e uso de outros softwares Microsoft Office (screenshot na Figura 3).
A MS Project pode ser utilizada para
gerenciar projetos simples ou complexos,
e permite planejar, organizar e gerenciar
as tarefas e recursos para alcanar um
objetivo final com restries de tempo,
custos e recursos.
Essa ferramenta oferece recursos para
auxiliar o usurio na gesto de projetos,
fornecendo a possibilidade de melhor
controle e suas atividades, segurana,
agilidade e eficcia nos processos, alm
de interface simples para uso, mesmo
para quem no est familiarizado com
a ferramenta. considerado por muitos
profissionais um bom software para gestores, administradores e coordenadores.

Segundo o site da Microsoft, a MS Project visa fornecer eficientes ferramentas


de gerenciamento de projeto com a combinao certa de usabilidade, eficincia
e flexibilidade, de modo que permite
o gerenciamento de projetos com mais
eficincia e eficcia. possvel manter
o gerente sempre informado, controlar
o trabalho, as agendas e as finanas do
projeto, manter as equipes de projeto
alinhadas e ser mais produtivo por meio
da integrao com programas conhecidos do Microsoft Office system, da gerao
avanada de relatrios, do planejamento
guiado e de ferramentas flexveis.
A MS Project destaca automaticamente
todos os itens que se deslocam como resultado da alterao mais recente realizada. Com a ajuda de realces de alteraes,

Edio 45 - Engenharia de Software Magazine

25

fcil de obter uma melhor compreenso


dos impactos das suas escolhas.
Outro recurso disponvel o desfazer e
refazer alteraes em modos de exibio,
dados e opes com vrios nveis de
desfazer. possvel desfazer aes ou
conjuntos de aes de iteraes macros
para testar vrios cenrios hipotticos e
compreender totalmente as implicaes
de cada escolha enquanto realiza alteraes de escopo.
As principais funcionalidades da MS
Project so:
Elaborar projetos e control-los atravs de agendamento das atividades
tornando possvel o progresso de cada
uma delas;

Acompanhar de forma gradual todo


o projeto;
Elaborar relatrios com qualidade,
discriminados por custo e trabalho dos
recursos e tarefas, durao das atividades
e sua distribuio de trabalho pelos dias
do ms ou ano, na forma de calendrio;
Montar rapidamente o plano do projeto
(agenda) definindo e organizando a lista
de tarefas, permitindo verificar detalhes
e ter uma viso geral do mesmo para
manter o seu controle;
Controlar quem faz as tarefas, montando seu conjunto de recursos e atribuir
em suas tarefas, bem como calcular o
tempo em que as tarefas precisam ser
concludas;

Figura 3. Visualizao da MS Project 2010

Figura 4. Visualizao dos grficos do projeto na Primavera

26

Engenharia de Software Magazine - Ferramentas para Gesto de Projetos

Ajuste rpido de sua agenda, pois havendo ajustes, interrupes no decorrer


do projeto, pode-se ajustar a agenda de
forma que fique organizada;
Coordenar o trabalho de pessoas em
qualquer lugar compartilhando informaes atravs de Intranet ou Internet,
utilizando email, por exemplo;
Ajuda durante o projeto, atravs do
assistente do Office;
Fcil integrao com programas do
pacote Office (Word, Excel, Access);
Impresso de relatrios personalizados;
Gerar Grfico de Gantt e outros tipos
como carga de trabalho e custos, seguindo a forma escolhida pelo usurio.

Primavera
A Primavera uma marca que comercializa pacotes de projetos de gerenciamento, cujo editor atual a Oracle Corporation. O principal pacote a Primavera P6
(Enterprise Management Project Portfolio),
desenvolvido pela Primavera Systems.
De acordo com o site da PMI Captulo
So Paulo (2009), a Primavera uma das
ferramentas mais completas e complexas
de gerenciamento de projetos, baseada
na metodologia do PMI. O software est
subdividido em pacotes de trabalho e
geralmente no necessrio adquirir
todo o produto. A possibilidade de
poder-se adquirir um determinado
pacote para suprir as necessidades da
empresa (por exemplo, Risk Manager),
constitui uma grande vantagem, pois
assim evita-se no utilizar de forma eficaz a ferramenta. Esta adequada para
ambientes de multi projetos, grandes e
complexos. A Figura 4 apresenta uma
tela da ferramenta.
As ferramentas de aplicao da Primavera software incluem:
Primavera P3 Project Planner e SureTrak
(descontinuado em 31 de dezembro de
2010, o uso continua no suportado pela
Oracle);
Primavera P6 Enterprise Management
Project Portfolio;
Primavera Project Management Professional P6;
Primavera P6 Analytics;
Primavera Portfolio Management;
Primavera de Gesto de Contratos;
Primavera de Anlise de Risco;

Gesto de Proje tos

Primavera Inspire for SAP;


Primavera Earned Value Management.
Dentre as principais funcionalidades
da Primavera esto:
Acompanhar o desempenho de cada
projeto de um mesmo cliente;
Possibilitar a colaborao com ideias
e solues dos mais diversos usurios
envolvidos no projeto;
Conciliar e administrar a disponibilidade de recursos e identificar os problemas de m utilizao de tais recursos
(Grfico de Gantt e Diagrama de Rede);
Definir a prioridade de projetos e
tarefas;
Identificar e selecionar as melhores
solues e estratgias para o sucesso de
um projeto;
Transmitir informaes aos gerentes
dos projetos, atravs de recursos avanados, fazendo uso de tabelas, grficos,
diagramas e histogramas;
Disponibilizar informaes em tempo
real para uma rpida e eficiente tomada
de decises;
Planejar e analisar a estratgia de recursos financeiros em projetos propostos;
Fornecer dados numricos para anlise
e comunicao do desempenho das diferentes fases de um mesmo projeto, baseadas em necessidades organizacionais;
Organizar e planejar portflio para
apresentaes aos mais diferentes perfis
de clientes e reas de atuao;
Organizar e disponibilizar formulrios para obteno de informaes necessrias para o sucesso das atividades
presentes em um projeto;
Disponibilizar dados de etapas do
projeto para aprovao;
Acesso via desktop, web e/ou intranet.

OpenProj
Conforme o site da ferramenta, o site
da OpenProj um software de gesto de
projetos de cdigo livre, com funes
similares ao MS Project, sendo capaz de
abrir arquivos Project. Ela foi desenvolvida pela Projity, em plataforma Java,
permitindo que seja executado em diferentes sistemas operacionais. A verso
1.0 foi liberada em janeiro de 2008. No
mesmo ano, a Projity foi adquirida pela
Serena Software.

Figura 5. Visualizao do planejamento de projetos no OpenProj

A OpenProj tem as seguintes funes


de gesto de projetos:
Gesto de recursos: cada tarefa precisa ter definido os recursos necessrios
para sua execuo (pelo menos um).
Esses recursos podem ser pessoas ou
materiais;
Calendrios: gerir datas das tarefas,
estabelecer datas previamente;
Ambiente de trabalho: permite atribuir datas de comeo e fim, horas de
trabalho de um recurso de uma tarefa,
planejamento;
Limitao de datas: durante o desenvolvimento de um projeto, podem
ocorrer situaes em que necessrio
terminar tarefas em uma data exata ou
aproximada. Quando se atribui uma
limitao de data de comeo ou fim
em uma tarefa, diminui a capacidade
desta para adaptar-se a mudanas na
programao.
Diviso de tarefas: uma tarefa pode
ser dividia ou reprogramada para interromper o trabalho e retomar o resto
do projeto do mesmo ou em um ponto
posterior da programao.
Filtros: ordenao de datas permitem mostrar informaes especficas
da programao do projeto. Os filtros

podem ser feitos por tarefas completas, tarefas de custo excessivo, tarefas
crticas, tarefas em progresso, tarefas
incompletas, tarefas atrasadas, tarefas
normais, resumo.
Impresso de documentos: Diagrama
de Gantt, visualizao de recursos, histograma, projetos e relatrios. O Grfico
de Gantt ilustra, na forma de barras, o
cronograma de um projeto, com as datas
de incio, fim e todas as tarefas atribudas devidamente registradas.
Alm disso, a OpenProj abre arquivos
da Microsoft Project e da Primavera, porm
possui formato de arquivo prprio. Os
relatrios e grficos podem ser exportados para xml ou pdf, facilitando assim
a migrao dos dados para outros programas do gnero. A Figura 5 mostra a
visualizao da tela do software.

dotProject
Atualmente, de acordo com o site da
dotProject, a ferramenta est em sua
verso 2.1.5 e apresenta uma srie de
funcionalidades teis para o trabalho de
gerenciamento de projetos. A verso atual
da dotProject foi lanada em janeiro de
2011, e houve pelo menos um lanamento

Edio 45 - Engenharia de Software Magazine

27

por ano, desde o incio da srie 2.x (2005),


sendo que o projeto nasceu em 2000.
Aps a disponibilizao da verso 2.1.5,
muitas correes e melhorias foram
disponibilizadas em uma verso beta e
j podem ser utilizadas.
A dotProject surgiu da necessidade de
se ter um software na rea de gesto de
projetos que no fosse necessrio o pagamento de licena e nem da utilizao
de um sistema operacional tambm
licenciado. A dotProject um sistema de
gerncia de projetos em software livre
de fcil utilizao, com um conjunto de
funcionalidades e caractersticas que o
tornam indicado para implementao

em ambientes corporativos, pois atende


a diversas necessidades de gerentes e
escritrios de projetos.
A ferramenta uma aplicao web e
seu acesso feito atravs de um navegador, assim sua utilizao independe de
sistema operacional e instalao na mquina do usurio, pois executado em
um servidor. Em termos mais tcnicos, a
dotProject um sistema escrito em PHP,
que utiliza banco de dados MySQL. Essa
ferramenta tambm pode ser instalada
em Windows, e utilizada em diferentes
sistemas operacionais.
Pelo site do dotProject Brasil possvel acessar a rea de demonstrao

Figura 6. Visualizao do projeto do dotProject

do software, conforme apresenta a


Figura 6.
O dotProject unifica, dentre outras
funes:
Informaes de empresas;
Informaes de projetos de cada
empresa;
Todas as tarefas necessrias execuo
de cada projeto;
Saber quanto de cada tarefa j foi
realizado;
Informao de usurios e colaboradores de cada tarefa;
Um modo fcil de informar usurios de
suas associaes a tarefas (via email);
Lembretes popup sobre prazos prximos ao fim;
Uma lista de contatos relacionados;
Calendrios com vises diferentes:
mensal, semanal e diria;
Fruns relacionados a projetos;
Repositrio de arquivos relacionados
a projetos.
Alm disso, a dotProject inclui mdulos
para companhias, projetos, tarefas (com
grfico de Gantt), fruns, repositrio de
arquivos, calendrio, contatos, bug report,
suporte multi-linguagem e gerenciamento de permisses de usurios.
Os participantes do projeto podem utilizar a ferramenta para visualizar suas
atividades, para reportar as realizaes
dirias, assim como cadastrar lies
aprendidas nos fruns. A limitao do
dotProject est em no possuir uma
comparao entre o que se estima de um
projeto e o que realmente acontece.

Comparativo entre as ferramentas

Figura 7. Funcionalidades fundamentais em um software de gerenciamento de projetos

28

Engenharia de Software Magazine - Ferramentas para Gesto de Projetos

A partir da apresentao das ferramentas de gesto de projetos e dos recursos


disponveis em cada uma delas, foi
realizada uma anlise comparativa com
os principais recursos para um gerenciamento eficaz de um projeto com o
objetivo de focar nos recursos tcnicos.
O critrio seguido para montar a tabela
comparativa foi o resultado do Estudo de
Benchmarking 2009 feito pela PMI Brasil,
que apresenta as funcionalidades mais
importantes para ferramentas de gesto
de projetos (ver Figura 7).
As funcionalidades citadas na tabela
foram tomadas como referncia para

Gesto de Proje tos

estabelecer uma comparao entre todas as ferramentas citadas


neste artigo. A Tabela 1 apresenta o resultado.
Em relao s ferramentas citadas, percebe-se que a Project
Builder e a MS Project so ferramentas mais completas de acordo
com as funcionalidades disponveis. Apesar disso, a Primavera, OpenProj e dotProjet dispem de funes que atendem s
necessidades de um gerente de projetos, como dependncia
entre tarefas, relatrios e histogramas. Enquanto a Project
Builder e a MS Project possuem tipo de licena paga, as outras
trs possuem licena gratuita.
O cronograma, importante para o controle de prazos e planejamento de um projeto, foi a funo mais importante considerada pelas organizaes, e s no est presente na dotProject.
Depois dessa funo, o painel com indicadores de desempenho
tambm foi citado no resultado da pesquisa, mas apenas as
ferramentas com licena paga o disponibilizam.

Os relatrios, que so necessrios para a avaliao dos projetos, exibido na tabela com 56% de importncia nas ferramentas de gesto de projetos.
Analisando todas as funcionalidades e ferramentas, a MS
Project e a Project Builder disponibilizam 16 itens da tabela, a Primavera atende em 12 itens, a OpenProj em 10, a dotProject 8.

Concluso
Desenvolver habilidades e alcanar o nvel de profissionalismo compatvel com a funo de gerente de projetos necessita
no apenas aprendizado de conceitos bsicos e tcnicas, mas
tambm o aprendizado na utilizao de ferramentas de gerenciamento bem como sua prtica.
Logo, com o uso dessas ferramentas e implantao, a gesto
pode ser realizada para garantir a aplicao dos princpios de
gerenciamento de projetos de forma padronizada buscando
Ferramenta

Recursos

Project Builder

MS Project

Primavera

OpenProj

Cronograma

Painel com indicadores de desempenho

Relatrios

Estrutura analtica de dados (WBS)


Gerenciamento da documentao

Acesso via web

Oramento

Pool de recursos

Monitoramento do portiflio de projetos

dotProject

x
x

Acesso remoto

Milestones

Timesheet

Gerncia de riscos

Envio automtico de mensagem

Gesto do portflio

Ajuda para a metodologia (web)

Anlise de valor agregado (EVA)

Integrao com financeiro

Integrao com suprimentos

Tabela 1. Quadro comparativo de Ferramentas x Funcionalidades

Edio 45 - Engenharia de Software Magazine

29

www.devmedia.com.br/esmag/feedback

CIRIACO, Douglas. Ferramentas para gerenciar projetos. 2009. <http://www.tecmundo.com.


br/1927-ferramentas-para-gerenciar-projetos.htm>.
PAUMGARTTEN, Andr. Porque investir numa ferramenta para gesto de projetos e portfolios.
2010. <http://www.terraforum.com.br/blog/Lists/Postagens/Post.aspx?ID=90>.
PRADO, Darci. Gerenciamento de Portflios, Programas e Projetos nas Organizaes. So Paulo:
INDG, 2009.
ROCHA, P. C. e BELCHIOR, A. D. (2004) Mapeamento do Gerenciamento de Riscos no PMBOK,
CMMI-SW e RUP, In: VI Simpsio Internacional de Melhoria de Processos de Software
SIMPROS, So Paulo, Brasil.
SISK, T.History of Project Management. 1998. <http://office.microsoft.com/downloads/9798/
projhistory.aspx>
PEREIRA, Paulo; TORREO, Paula; MARAL, Ana Sofia. Entendendo Scrum para Gerenciar
Projetos de Forma gil. Revista Mundo PM, n. 14. Abril/Maio 2007. <http://pt.scribd.com/
doc/54957015/scrum-mundopm-abril-maio-2007>.
VAZQUEZ,C.E. , SIMES,G.S. , ALBERT,R.M. Anlise de ponto de funo medio, estimativa e
gerenciamento de projetos de software. So Paulo, Editora rica, 2009
Softex. MPS.BR - Melhoria de processo do software brasileiro - Guia geral, 2009
sobre e
s

A Engenharia de Software Magazine tem que ser feita ao seu gosto.


Para isso, precisamos saber o que voc, leitor, acha da revista!
D seu voto sobre este artigo, atravs do link:

Referncias

Feedback
eu

edio
ta

D seu feedback sobre esta edio!

D
s

atender da melhor forma s necessidades das organizaes.


O contexto histrico da prtica de gesto de projetos e as principais metodologias, como o PMBOK, so conhecimentos que
um gestor precisa ter para avaliar qual o melhor processo a
ser adotado no desenvolvimento de um projeto.
Foram citadas neste artigo cinco das principais ferramentas,
suas vantagens e desvantagens apresentadas, alm disso, outra
contribuio do artigo foi destacar a importncia da gesto de
projetos dentro das organizaes, ressaltando as funes que
o gerente deve exercer, como o planejamento de aes, a definio de processos e tcnicas, o uso de ferramentas adequadas
ao projeto e suas principais funcionalidades.
O gerenciamento de projetos deve ser feito com a aplicao
de conhecimentos, habilidades, ferramentas e tcnicas. Com
o uso de metodologias, a implantao da cultura de projetos
pode ser realizada para garantir a aplicao dos princpios de
gerenciamento de projetos de forma padronizada, buscando
atender da melhor forma s necessidades das organizaes.

IFPUG(International Function Point Users Group). <http://www.ifpug.org>.


BFPUG(Brazilian Function Point Users Group). Disponvel em: <http://www.bfpug.com.br>.
PMI (Project Management Institute). Um Guia do Conjunto de Conhecimentos em
Gerenciamentos de Projetos (PMBOK). Estados Unidos: PMI Publications, 2004
DEKKERS, C. Pontos de Funo e Medidas - O Que um Ponto de Funo?. QAI Journal, dez. 1998
DEKKERS, C. Desmistificando Pontos de Funo: Entendendo a Terminologia. IT Metrics
Strategies, out. 1998
HAZAN, Cludia Anlise de Pontos por Funo agosto , 2001 . http://www.inf.ufes.
br/~falbo/download/aulas/es-g/2005-1/APF.pdf.
ACINE. Anexo XVIII Tabelas de produtividade mnima, 2008. <http://www.ancine.gov.br/
media/concorrencia0012008/AnexoXVIII.pdf>
Philippe Kruchten. The Rational Unified Process: An Introduction. Boston, Editora Pearson
Education, 2003

30

Engenharia de Software Magazine - Ferramentas para Gesto de Projetos

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

Conhecendo a ISO 15408


Trabalhando com segurana da informao

De que se trata o artigo?


Este artigo apresenta um estudo sobre o assunto segurana no desenvolvimento de software.
Para isso, os seguintes tpicos sero abordados:
conceitos de segurana, importncia de se desenvolver um software seguro, norma de segurana ISO/IEC 15408 para o desenvolvimento de
software e, por fim, auditoria de software.

Em que situao o tema til?

O
Dayana Fernanda Trapp
dayanaft@gmail.com

Rodrigo Oliveira Spnola


rodrigo.devmedia@gmail.com

Editor Chefe SQL Magazine | WebMobile |


Engenharia de Software Magazine

desenvolvimento de sistemas
uma das reas mais afetadas
pelos aspectos da segurana.
Muitos dos problemas de segurana
existentes hoje no so, nem fsicos e
nem de procedimento, mas sim, devidos
a erros de programao ou de arquitetura. Muitas vezes, para no perder
muito tempo e entregar a soluo o
quanto antes para o cliente, os requisitos
de segurana so deixados de lado. Os
clientes por sua vez no possuem noo
sobre segurana de um sistema e s sabero mais tarde quando encontrada
uma vulnerabilidade. Isso acontece
porque poucos analistas preocupamse em especificar bem os requisitos de
segurana.

O entendimento deste assunto importante


para aqueles que trabalham com desenvolvimento de software e, em particular, para
aqueles que trabalham no sentido de aprimorar iniciativas de segurana da informao.

Resumo?
A segurana da informao tem como objetivo a
proteo da informao para reduzir a probabilidade e o impacto de incidentes de segurana. Para
saber se o sistema seguro, na dcada de 80 surgiu
o primeiro padro para avaliao de segurana
em softwares que ficou conhecido como Orange
Book. Mais tarde este padro foi homologado pela
International Standartization Organization (ISO)
como ISO/IEC 15408. Neste contexto, este artigo
apresenta um estudo sobre o assunto segurana
no desenvolvimento de software.

Edio 45 - Engenharia de Software Magazine

31

A segurana em sistemas sempre foi importante e com a


internet a segurana torna-se o foco, uma vez que os sistemas
tendem a ficar mais interconectados, facilitando acessos indevidos. Dessa forma, temos que a segurana ser cada vez mais
uma preocupao no desenvolvimento de sistemas.
Tem-se como premissa que nenhum software seguro [19].
A segurana de um software afetada porque ele pode executar outros procedimentos os quais no foram propostos. Se
ele fizesse exatamente o que foi destinado a fazer, a segurana
no seria uma preocupao [10]. Portanto, existe uma facilidade
para invasores investigarem vulnerabilidades desconhecidas
e dificuldade dos desenvolvedores em garantir que todos os
pontos de entrada do sistema estejam protegidos.
Para saber se um sistema seguro, na dcada de 80 surgiu o
primeiro padro para avaliao de segurana em softwares que
ficou conhecido como Orange Book. Mais tarde este padro foi
homologado pela International Standartization Organization
(ISO) como ISO/IEC 15408, que muitas vezes chamada apenas de Common Criteria (CC). De acordo com Albuquerque e
Ribeiro [1], a norma ISO/IEC 15408 o melhor ponto de partida
para o desenvolvimento de software seguro, pois ela descreve
conceitos necessrios para a segurana em sistemas.
A ISO/IEC 15408 determina que um sistema deva ter seu
Security Target (ST) (objetivo ou alvo de segurana) definido
para ser considerado seguro. O ST a especificao de segurana, ou seja, indica quais aspectos de segurana foram considerados importantes e porque o foram para aquele sistema
em particular.
Neste contexto, este artigo apresenta um estudo sobre o assunto segurana no desenvolvimento de software. Para isso, a partir
de agora apresentaremos os conceitos de segurana. Em seguida
abordaremos a importncia de se desenvolver um software
seguro. Posteriormente apresentaremos a norma de segurana
ISO/IEC 15408 para o desenvolvimento de software. E, por fim,
descreveremos os conceitos de uma auditoria de software.

Segurana da informao
A segurana da informao tem como objetivo a proteo
da informao para reduzir a probabilidade e o impacto de
incidentes de segurana. Segundo Lyra [17], um incidente de
segurana ocorre quando um evento pode causar interrupes nos processos de negcio em decorrncia da violao de
alguma propriedade de segurana. Neste contexto, temos as
trs propriedades bsicas da segurana:
confidencialidade: capacidade de um sistema permitir que
alguns usurios acessem determinadas informaes ao mesmo
tempo e impedir que outros, no autorizados, a vejam;
integridade: a informao deve estar correta, ser verdadeira
e no estar corrompida;
disponibilidade: a informao deve estar disponvel para
todos que precisarem dela para a realizao dos objetivos
empresariais.
Alm destas trs propriedades principais, tm-se tambm as
seguintes propriedades conceituadas em [3]:

32

Engenharia de Software Magazine - Conhecendo a ISO 15408

autenticao: capacidade de garantir que um usurio, sistema


ou informao mesmo quem alega ser;
no repdio: capacidade do sistema de provar que um usurio executou determinada ao no sistema;
legalidade: aderncia de um sistema a legislao;
privacidade: capacidade que um sistema tem em manter
incgnito um usurio, impossibilitado a ligao direta da
identidade do usurio com as aes por este realizadas;
auditoria: capacidade do sistema em verificar tudo o que foi
realizado pelos usurios, detectando fraudes ou tentativas de
ataque. Note que este um aspecto difcil de ser totalmente
conciliado com a privacidade.
Quando se tem a perda de qualquer propriedade da segurana importante para o sistema, tem-se um problema de
segurana. Assim, trabalha-se na preveno para manter as
propriedades de segurana dentro das necessidades do cliente
e evitar falhas. Por exemplo, um sistema que deve estar disponvel 24 horas, deve ter alta disponibilidade e no necessita
tanto tratar confidencialidade e privacidade dos dados. Nos
sistemas militares ou de segurana nacional, o ponto critico
a privacidade. J em sistemas bancrios, a integridade e a
auditoria so os pontos mais relevantes. Para cada tipo de
sistema a necessidade de segurana diferente, por isso, deve
ser tratada de forma distinta para cada caso.
As falhas de segurana em software podem ser consideradas
as grandes responsveis pelos ataques em sistemas. A exposio que vem com a conectividade global torna a informao
sensvel e o sistema mais vulnervel para o uso no autorizado
e intencional [2]. O crescimento da conectividade da internet
pelos computadores e a dependncia dos usurios de servios
on-line tem proporcionado um grande nmero de ataques.
O ataque ao sistema um problema de segurana grave,
pois o agente que est realizando o ataque visa obter alguma
vantagem, podendo com isso, provocar grandes prejuzos. H
sempre quatro elementos no ataque:
ataque: um tipo de problema de segurana caracterizado
pela existncia de um agente que busca obter algum tipo de
retorno, atingindo um ativo de valor, por exemplo, dinheiro;
ativo: algo de valor protegido pelo sistema. Geralmente est
aliado com uma propriedade de segurana, por exemplo, a
confidencialidade dos dados do oramento;
vulnerabilidade: uma falha no sistema que explorada
em todo o ataque. O ataque pode ser intencional ou pode
ocorrer por erros de operao e que permita que o ativo seja
atingido;
ameaa: um ataque a um ativo da informao. um agente
externo que, aproveitando-se da vulnerabilidade, poder quebrar um ou mais dos trs princpios de segurana.
O sistema est em risco quando apresenta vulnerabilidades que podem ser exploradas produzindo algum impacto
negativo. Neste contexto, pode-se ter um ativo com vrias
vulnerabilidades, mas sem ameaas de ataque, o que se leva
a ter uma probabilidade prxima de zero. Neste contexto, a

Segurana da Informa o

probabilidade significa a chance de uma falha de segurana


ocorrer, levando-se em conta as vulnerabilidades do ativo e as
ameaas que venham a explorar esta vulnerabilidade
A Figura 1 mostra um exemplo da probabilidade de ocorrncia dos ataques e qual o dano esperado. Perceba que no
exemplo deve-se priorizar a correo da ameaa 3 que a que
possui maior probabilidade de ocorrncia e impacto.

Howard e Leblanc [15] listam algumas razes para as pessoas


no se preocuparem com a segurana:
a segurana entediante;
a segurana costuma ser vista como um desativador de
funcionalidade, como algo que atrapalha;
a segurana difcil de medir;
normalmente, a segurana no a principal habilidade
ou interesse dos projetistas e desenvolvedores que criam o
produto;
a segurana no significa criar algo novo e animador.

Processos de desenvolvimento

Figura 1. Priorizao de ameaas

Por fim, importante termos em mente que o defensor pode


se defender somente de ataques conhecidos, j o invasor pode
investigar as vulnerabilidades desconhecidas.

Desenvolvimento de Software Seguro


A autenticidade, integridade, sigilo e aceitao, consistem
nos principais fundamentos para que os objetivos de segurana possam ser inteiramente aplicados. Neste contexto, ao
se trabalhar com o desenvolvimento de sistemas seguros, as
seguintes questes devem ser consideradas:
segurana do ambiente de desenvolvimento: ter o comprometimento da equipe e evitar roubo do cdigo-fonte;
segurana da aplicao desenvolvida: seguir a especificao
de segurana, evitar acessos ocultos (backdoor) e falhas que
comprometam a segurana;
garantia de segurana da aplicao desenvolvida: garantir
para o cliente que a aplicao em desenvolvimento segura.
Essas questes esto sempre interligadas uma com a outra,
no h como se conseguir uma aplicao segura sem um ambiente de desenvolvimento seguro.
Conforme Conallen [10], o maior responsvel por ataques
so as falhas de segurana contidas nos softwares. tarefa
dos arquitetos entenderem e administrarem as falhas, j que
possuem um bom conhecimento do sistema.
Algumas empresas no se preocupam com os profissionais que
iro desenvolver os sistemas colocando, por exemplo, funcionrios no especializados em programao, como web designers,
para programar. Pela falta de conhecimento, acabam gerando
falhas no cdigo e deixando o sistema vulnervel [22].

O risco de problemas com segurana sempre vai existir.


O dilema trazer o grau de risco a um nvel aceitvel, de
modo que se possa evoluir na utilizao da tecnologia at um
patamar mais confivel e eficaz.
De acordo com Oliveira [19], impossvel ter um sistema
totalmente seguro. Os riscos podem ser amenizados quando
so identificados, mas nunca totalmente eliminados. O sistema
seguro aquele que concentra suas defesas nos ataques mais
provveis e com maior perda esperada [1].
Para Lyra [17], as funcionalidades de segurana devem ser
representadas nos vrios nveis de abstrao, desde o projeto
lgico, at a implementao de seus produtos finais. Assim,
se uma empresa deseja comear a implementar segurana,
ela dever primeiro fazer o planejamento de segurana, e este
planejamento precisa contemplar as seguintes atividades:
definir planejamento de segurana e identificar seus
mecanismos;
atribuir responsabilidades de segurana no projeto;
implementar ambientes de processamento;
planejar o gerenciamento de incidentes de segurana.
Para as empresas que seguem algum tipo de processo de
desenvolvimento de software, Howard e Leblanc [15] sugerem a atualizao do processo, incluindo aprimoramentos
de segurana em cada etapa do ciclo de vida. Na Figura 2
exibido um modelo em cascata acrescentando as questes de
segurana em cada etapa do processo.

Figura 2. Melhorias incrementais da segurana no processo de desenvolvimento

Edio 45 - Engenharia de Software Magazine

33

Howard e Leblanc [15] afirmam que a preocupao j


deve vir na contratao do profissional que ir trabalhar
no projeto, verificar se ele possui habilidades de segurana. Treinar os profissionais em segurana tambm
uma boa prtica.
De acordo com Albuquerque e Ribeiro [1], existem ameaas ao negcio ou ao objeto da aplicao que precisam
ser eliminadas ou, ao menos, mitigadas. Neste sentido,
necessrio determinar quem o pblico-alvo e quais sero
os requisitos de segurana que o sistema conter e coloca
as seguintes questes:
quem o pblico do aplicativo?
o que a segurana significa para o pblico? H alguma distino entre diferentes membros do pblico? Os
requisitos de segurana so diferentes para diferentes
clientes?
onde o aplicativo ser executado? Na internet? Por trs
de um firewall? Em um telefone celular?
o que voc est tentando proteger?
quais so as implicaes para os usurios, se os objetos
que voc est protegendo forem comprometidos?
quem vai gerenciar o aplicativo? O usurio ou um administrador de Tecnologia da Informao (TI) corporativo?
quais so as necessidades de comunicao do produto? O
produto interno ou externo organizao, ou ambos?
quais servios da infra-estrutura de segurana que o
sistema operacional e o ambiente j fornecem e de que
voc pode tirar proveito?
como o usurio precisa ser protegido de suas prprias
aes?
Tendo feito o levantamento de ameaas, tem-se o objetivo de segurana. Cada ameaa est relacionada com um
objetivo de segurana. Porm, deve-se cuidar para no
gerar um plano muito caro, corrigindo todas as ameaas,
mas sim, tratar somente as ameaas significativas, ou com
maior probabilidade de impacto. Proteger o sistema das
principais ameaas dificulta os ataques.
Desta forma, so levantadas as mtricas para o desenvolvimento de software, medio de riscos, e quanto a
empresa dever investir em segurana. Levantadas as
mtricas, pode-se verificar qual o nvel de segurana que
o sistema deve atingir.

Boas prticas de programao


Os padres de desenvolvimento visam melhorar a estrutura interna de um programa, garantir maior legibilidade
do cdigo, padronizao da codificao, facilidade na
manuteno, maior produtividade, rapidez no desenvolvimento, reduo da quantidade de cdigos e facilidade
da deteco de erros.
Ao seguir as normas da boa programao, automaticamente so eliminados muitos dos erros e falhas de
segurana em uma aplicao. Algumas normas de boa
programao so [1]:

34

Engenharia de Software Magazine - Conhecendo a ISO 15408

funes intrinsecamente seguras: tratar todas as variveis


de entrada como no-confiveis, verificando sua validade
antes de us-las;
sempre verificar os cdigos de erro retornados por uma
funo, principalmente nas chamadas a Application Programming Interface (API) do sistema operacional;
atentar sempre para o tamanho dos buffers e arrays do
sistema;
documentar o cdigo: se for trabalho em equipe, indispensvel para que no ocorra falha de comunicao entre
a equipe.
Alm das boas prticas de programao, existem tambm
legislaes ou polticas de segurana que preciso obedecer. Para isso, foi criada a norma ISO/IEC 15408, que dita
um processo de desenvolvimento de software seguro, com
a realizao de testes e acompanhamento do projeto. Ela
tambm fornece base para certificar os produtos, avaliando
a sua segurana.

Norma ISO/IEC 15408


A norma ISO/IEC 15408 surgiu para unificar padres de
segurana e eliminar as diferenas de critrios. O primeiro
padro para avaliao da segurana surgiu nos EUA na
dcada 1980. Foi nomeado de Trusted Computer System
Evaluation Criteria (TCSEC), mais conhecido como Orange
Book devido a sua capa laranja.
Em 1991 foi criada a norma para certificao de segurana
chamada de Information Technology Security Evaluation
Criteria (ITSEC) por uma comisso europia envolvendo os
pases Alemanha, Frana. Holanda e Reino Unido. O ITSEC
se tornou um padro europeu voltado tanto para a avaliao
de produtos, como de sistemas.
Outros padres surgiram na dcada de 1990, como Canadian Trusted Computer Product Evaluation (CTCPEC) que
a juno das normas TCSEC e ITSEC e o Federal Criteria
(FC) desenvolvida pelos EUA.
Com o grande nmero de normas, as empresas internacionais comearam a ter problemas para certificarem seus
produtos. Assim, foi sugerida ISO a criao de um critrio
nico de avaliao de segurana, surgindo assim a norma
ISO 15408:1999, dando-lhe o nome de Common Criteria
(CC). Na Figura 3 representada a evoluo do critrio de
segurana mencionado acima.
A ISO 15408 um padro internacional de desenvolvimento
de produtos seguros, o qual descreve uma lista de critrios de
segurana que um produto deve ter. Assim, a norma desenvolve um critrio de avaliao de segurana da informao,
dando segurana aos clientes, testando e certificando seus
produtos e servios.
A ISO 15408 est dividida em trs partes:
Define o conceito e os princpios gerais da avaliao da
segurana da informao em TI e apresenta a lista de requisitos de segurana, que esto divididos em classe, famlia e
requisito;

Segurana da Informa o

Cataloga uma srie de requisitos funcionais e organizados


em famlias e classe para a avaliao do Target Of Evaluation (TOE sistema que est sendo avaliado). Os requisitos
para a classe Auditoria da Segurana esto apresentados
na Tabela 1.
Define o critrio de avaliao para o Protection Profile (PP)
e Security Target (ST) e apresenta sete pacotes de segurana
pr-definidos que so chamados de Evaluation Assurance
Level (EAL).

Figura 3. Evoluo do critrio de segurana

AUDITORIA DE SEGURANA
FAU_ARP - Resposta automtica a auditoria
FAU_ARP.1 - Alarmes de segurana
FAU_GEN - Gerao de dados para auditoria
FAU_GEN.1 - Gerao de dados para auditoria
FAU_GEN.2 - Associao do usurio ao evento de auditoria
FAU_SAA - Anlise da auditoria de segurana
FAU_SAA.1 - Anlise de violao potencial
FAU_SAR - Reviso de dados da auditoria
FAU_SAR.1 - Reviso de auditoria
FAU_SEL - Auditoria seletiva
FAU_SEL.1 - Auditoria seletiva
FAU_STG - Armazenamento da trilha de auditoria
FAU_STG.1 - Armazenamento protegido da trilha de auditoria
FAU_STG.2 - Garantia da disponibilidade dos dados para auditoria
Tabela 1. Classe auditoria de segurana

A ISO 15408 estabelece que qualquer sistema, para ser


considerado seguro, deve ter seu ST elaborado. O ST a especificao de segurana, ou seja, indica quais aspectos de
segurana foram considerados importantes e por que o foram
para aquele sistema em particular. Existe tambm o PP, que
um documento semelhante ao ST, com a diferena que no
especifica uma nica aplicao, podendo ser aplicao a toda
uma classe de sistema.
A ISO 15408 define sete nveis para garantir segurana, denominados de EAL. Para cada nvel, tem-se um maior nmero

de testes e, portanto, uma maior garantia de que o sistema


atende aos requisitos de segurana. Os nveis da norma ISO/
IEC 15408 so:
EAL1: certifica que o TOE teve seu funcionamento
testado;
EAL2: estabelece que o sistema teve sua estrutura testada. Envolve a cooperao do fabricante;
EAL3: certifica que o TOE foi metodicamente testado
e checado;
EAL4: define que o sistema foi metodicamente projetado,
testado e checado;
EAL5: prev que o sistema seja implementado e testado
de maneira no formal;
EAL6: certifica que o TOE foi projetado, verificado e
testado de maneira no formal;
EAL7: define que o sistema foi projetado, verificado e
testado de maneira formal.
fcil ver que atingir o nvel EAL7 de segurana leva
tempo e dinheiro. Para os sistemas comerciais, o nvel
EAL3 traz uma segurana significativa a um custo
menor.
Ao seguir os padres e a ideia da ISO 15408 j se pode
obter um nvel elevado de segurana no desenvolvimento
dos sistemas, pois aplicar a norma em sua totalidade exige
muitos detalhes, avaliaes por laboratrios internacionais
e o custo pode se tornar alto.

Auditoria de software
A auditoria uma atividade que engloba o exame das
operaes, processos, sistemas e responsabilidades gerenciais de uma determinada entidade, com intuito de
verificar sua conformidade com certos objetivos e polticas
institucionais, oramentos, regras, normas ou padres.
Dias [12] relata a existncia de trs modelos de auditoria
da segurana:
Auditoria da segurana de informaes: determina
a postura da organizao com relao segurana, que
geralmente envolve itens como controle de acesso lgico,
fsicos e ambientais;
Auditoria da tecnologia da informao: abrange toda
a segurana da informao, como tambm os controles
organizacionais, de operao de sistemas e sobre o banco
de dados;
Auditoria de aplicativos: determina a segurana em
aplicativos especficos tendo, como controles o desenvolvimento de sistemas aplicativos, de entrada processamento
de entrada e sada de dados, sobre o contedo e funcionamento do aplicativo.
Para ser um auditor na rea da tecnologia de informao,
deve-se ter um bom conhecimento na rea de sistemas computacionais, de preferncia j ter trabalhado nela. O nvel
de conhecimento varia de acordo com os requisitos que o
auditor ir avaliar.

Edio 45 - Engenharia de Software Magazine

35

A segurana hoje fundamental no desenvolvimento dos sistemas. Neste sentido, vimos neste artigo que a norma ISO/IEC
15408 surgiu com intuito de fornecer uma srie de requisitos de

A Engenharia de Software Magazine tem que ser feita ao seu gosto.


Para isso, precisamos saber o que voc, leitor, acha da revista!
D seu voto sobre este artigo, atravs do link:

D
s

D seu feedback sobre esta edio!

Feedback
eu

www.devmedia.com.br/esmag/feedback

Referncias
1. ALBUQUERQUE, Ricardo; RIBEIRO, Bruno. Segurana no desenvolvimento de software. Rio de
Janeiro: Campus, 2002. 310 p.

12. DIAS, Claudia. Segurana e auditoria da tecnologia da informao. Rio de Janeiro: Axcel Books,
2000. 218 p.

2. ALLEN, Julia H. et al. Software security engineering: a guide for project managers. Upper Saddle
River, NJ: Addison-Wesley, 2008. 334 p.

13. FRANZINI, Fernando. Java para web: autenticao e autorizao em aplicativos web 2. [S.I.]
2009. Disponvel em: <http://imasters.uol.com.br/artigo/14152/javaweb/autenticacao_e_
autorizacao_em_aplicativos_web.html>. Acesso em: 04 maio. 2010.

3. AZEVEDO, Denny. Metodologias de segurana de sistemas. So Paulo: IFSP, 2008. Disponvel em:
<http://gensys.eti.br/CEFET/Metodologias_Seguran%C3%A7a_Desenvolvimento_Sistemas.
pdf>. Acesso em: 19 mar. 2009.
4. BATISTA, Carlos F. A. Mtricas de segurana de software. 2007. 103 f. Dissertao (Mestrado em
Informtica) - Programa de Ps-Graduao em Informtica, Pontifcia Universidade Catlica do Rio
de Janeiro, Rio de Janeiro. Disponvel em: <http://www.dominiopublico.gov.br/download/texto/
cp040026.pdf>. Acesso em: 20 mar. 2009.
5. BRANDO, Jos E. M.S.; FRAGA, Joni da S. Gesto de riscos. In: SIMPSIO BRASILEIRO EM
SEGURANA DA INFORMAO E DE SISTEMAS COMPUTACIONAIS, 8., 2008, Porto Alegre. Anais...
Porto Alegre; SBC, 2008. p. 1-43.
6. BRAZ, Fabricio. Software seguro: O que esperar Fortify Souce Code Analyzer? Brasilia, 2008.
Disponvel em: <http://softwareseguro.blogspot.com/2008/03/o-que-esperar-fortify-soucecode.html>. Acesso em: 03 mar. 2010.
7. BURNETT, Steve; PAINE, Stephen. Criptografia e segurana: o guia oficial RSA. Rio de Janeiro:
Elsevier: Campus, 2002. 367 p.
8. CODEHOUSE. QDox. [S.l.]: 2010. Disponvel em: <http://qdox.codehaus.org/>.
9. COMMON CRITERIA. The Common Criteria portal. [S.l.][2009?]. Disponvel em: <http://www.
commoncriteriaportal.org/>. Acesso em: 21 mar. 2009.

14. GUERRA, Eduardo. Os sete pecados do controle de acesso em aplicaes Java EE. Mundojava,
Curitiba, n. 28, p. 26-36, abr. 2008.
15. HOWARD, Michael; LEBLANC, David. Escrevendo cdigo seguro: estratgias e tcnicas prticas para
codificao segura de aplicativos em um mundo de rede. Porto Alegre: Bookman, 2005. 701 p.
16. ITEXTPDF. your Java-PDF library. [S.l.], 2010. Disponvel em: <http://itextpdf.com/>. Acesso
em: 04 abr. 2010.
17. LYRA, Maurcio R. Segurana e auditoria em sistemas de informao. Rio de Janeiro: Cincia
Moderna, 2008. 253 p.
18. NUNES, Francisco J.; BELCHIOR, Arnaldo D. Processo seguro de desenvolvimento de software.
Cear, 2006. Disponvel em: <http://www.iadis.net/dl/final_uploads/200607C052.pdf>. Acesso
em: 20 mar. 2009.
19. OLIVEIRA, Wilson J. Segurana da informao: tcnicas e solues. Florianpolis: Visual Books,
2001. 182 p.
20. ROSEMANN, Douglas. Software para avaliao da segurana da informao de uma empresa
conforme a norma NBR ISO-IEC 17799. 2002. 93 f. Trabalho de Concluso de Curso (Bacharelado
em Cincias da Computao) - Centro de Cincias Exatas e Naturais, Universidade Regional de
Blumenau, Blumenau.

10. CONALLEN, Jim. Desenvolvendo aplicaes WEB com UML. Rio de Janeiro: Campus, 2003. 476 p.

21. SOURCEFORGE.NET. Welcome to dom4j 2.0. [S.l.], 2007. Disponvel em: <http://dom4j.
sourceforge.net/>. Acesso em: 21 mar. 2010.

11. CUGIK, Fernando L. Software livre para verificao de adequao de servidores Gnu/Linux

22. THOMPSON, Marco A. Proteo e segurana na internet. So Paulo: rica, 2002. 244 p.

norma de segurana NBR ISO/IEC 27002. 2007. 74 f. Trabalho de Concluso de Curso - (Bacharelado
em Cincias da Computao) - Centro de Cincias Exatas e Naturais, Universidade Regional de
Blumenau, Blumenau.

36

Engenharia de Software Magazine - Conhecendo a ISO 15408

sobre e
s

Concluses

segurana a serem seguidos. Com isso, pode-se medir o nvel


de segurana em que o sistema encontra-se, fornecendo-se
alguma garantia para o cliente.

edio
ta

Segundo Lyra [17], primeiro inicia-se o processo de levantamento das informaes relevantes sobre o sistema. Esse
levantamento deve ser feito de modo abrangente, de forma
que seja possvel o entendimento macro das caractersticas
do sistema.

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

Testes funcionais de software

Elisngela Andrade Bruno

De que se trata o artigo?

elisangela.a.bruno@gmail.com

Este artigo apresenta uma introduo aos conceitos de Testes Funcionais de Software durante
o processo de validao e medio da qualidade
do produto desenvolvido. Sendo assim, o artigo
serve para apresentar o conceito de qualidade e
demonstrar como mtodos de Testes de software,
utilizados no processo de desenvolvimento, podem auxiliar na validao e medio da qualidade
do produto.

Graduada em Cincia da Computao pela


Faculdade Anhanguera de Santa Brbara
(2009). Programadora na IST Sistemas Ltda.
Possui experincia de 4 anos na rea de Cincia da Computao, com nfase em Sistemas
de Informao, atuando como desenvolvimento de sistemas, programao orientada a
objetos e linguagem de programao .net.

Paulo C. Barreto da Silva


paulo.Barreto@unianhanguera.edu.br

Graduado em Anlise de Sistemas pelo


Centro Universitrio Salesiano de So Paulo (2003) e Ps-graduado pela UNICAMP
- na rea de Orientao a Objetos (2005).
Professor da Anhanguera Educacional SA e
Analista de Sistemas na Papirus Indstria
de Papel SA.

Thiago Salhab Alves


thiago.alves@unianhanguera.edu.br

Graduado em Cincia da Computao pela


Universidade Metodista de Piracicaba UNIMEP (2004) e Mestre em Cincia da
Computao pela Universidade Metodista
de Piracicaba - UNIMEP (2008). Professor e
Coordenador do curso de Cincia da Computao da Faculdade Anhanguera de Santa Brbara. Possui seis anos de experincia
na rea de Cincia da Computao com
nfase em Engenharia de Software.

tualmente os softwares so
empregados em todos os seguimentos da sociedade, tanto para
sistemas cujos requisitos sejam simples
quanto para aplicaes sofisticadas e de
grande complexidade. Um exemplo de
sistema complexo so os softwares de
uso exclusivo para a rea de medicina.
Com a ampla utilizao das tecnologias
da informao, a qualidade do produto
tem se tornado imprescindvel nos processos de desenvolvimento de aplicaes
e no momento de avaliao do projeto. O
teste de software, cujo objetivo revelar
a presena de defeitos e aumentar a confiana sobre o software, considerado
um elemento crtico para a garantia da
qualidade do produto.
As atividades de testes podem muitas
vezes se tornar exaustivas e trabalhosas,
dificultando assim a execuo dos testes
de forma adequada para a anlise de
qualidade. Com o objetivo de melhorar
a qualidade da anlise e o tempo de execuo dos testes, foram criados os testes

Em que situao o tema til?


Na elaborao de um padro de validao onde
constantemente seja necessria a validao do
desenvolvimento realizado, e testes complexos que exigem grande esforo da equipe de
desenvolvimento.

Resumo?
Os testes funcionais permitem que os testes
ocorram de uma forma mais eficiente e rpida, possibilitando encontrar as no conformidades do software em relao aos requisitos
do sistema. O presente artigo cita os principais conceitos dos Testes Funcionais de Software e apresenta alguns detalhes extrados
de sua forma de implementao.

Edio 45 - Engenharia de Software Magazine

37

automatizados, que proporcionam a execuo dos testes mais


rapidamente, e com maior cobertura do software.
De acordo com Pressman, autor do livro Engenharia de
Software, o principal objetivo dos testes de software a localizao de erros, falhas, defeitos (ler Nota do DevMan 1) e a
verificao das funcionalidades do software em desenvolvimento ou finalizado.

Nota do DevMan 1
Defeito, Erro e Falha: Defeito uma deficincia mecnica ou algortmica (deficincia no cdigo) que se ativada pode levar a uma falha.
Erro um estado de execuo que impede o software de continuar, pode ser causado
por algo externo ao software ou falhas na grafia do cdigo fontes, tais como ausncia
de ponto-e-virgula e parmetros.
Uma Falha um evento notvel onde o sistema viola suas especificaes, a existncia aparente de um defeito.

Atravs do processo de testes, busca-se avaliar se estas


funcionalidades esto aparentemente trabalhando de acordo
com as especificaes e requisitos do projeto, garantindo que
o software atinja o nvel de qualidade esperada pelos interessados no produto.

Principios dos Testes


Segundo Brunelli, os componentes essenciais para o teste de
software de um programa podem ser divididos em:
Executvel do programa (cdigo do programa compilado);
Relao dos comportamentos esperados;
Apresentao do mecanismo de avaliao dos comportamentos esperados;
Descrio das funes;
Descrio de como observar se uma ao resultou na execuo esperada.
O levantamento dos comportamentos esperados considerado uma das maiores dificuldades na elaborao dos testes,
portando sua elaborao deve ser feito de forma cautelosa e
de acordo com os requisitos do sistema. Isso se deve ao fato de
que os comportamentos do software nem sempre so previstos
na etapa de levantamento de requisitos, sendo necessria a
posterior elaborao da lista de comportamentos esperados
versus funes requeridas.
Segundo Sommerville, um caso de teste bem elaborado possibilita a identificao e soluo de erros inditos, tornando seu
processo muito mais eficiente.
Enfim, os testes de software visam mostrar aos clientes,
atravs da exibio de erros detectados, que o software est
funcional de acordo com as especificaes propostas e requisitos desejados.

38

Engenharia de Software Magazine - Testes funcionais de software

O processo de testes
O Processo de Teste, como qualquer outro processo, necessita
ser refinado continuamente, permitindo seu amadurecimento,
de maneira a ampliar sua atuao e permitir aos envolvidos
no projeto uma maior visibilidade e organizao dos seus
trabalhos. O que se deseja nesta etapa uma maior agilidade
e controle operacional dos projetos de testes.
Realizar testes de software uma tarefa bastante complexa
quando se desconhece o que qualidade. Nas indstrias automobilsticas, como o caso da maioria das grandes indstrias,
qualidade est intimamente associada a custo de retrabalho.
No incio da dcada de 60, por volta do ano de 1962, foi criado
no Brasil um comit especfico para trabalhar a normalizao
destas regras visando sua implantao nas empresas. A qualidade, muitas vezes associada a certificaes como ISO 9001,
CMMI e tantas outras que existem por a, no passam de formalizaes de boas prticas que com o passar do tempo foram
aperfeioadas e implementadas de forma comum.
O processo de Testes de Software deve contemplar, alm de
um roteiro com objetivos bastante claros, a declarao dos itens
a serem avaliados e quais so os ndices esperados, como por
exemplo, defeitos por nmero de funes.
Na rea de Engenharia de Software, desde Roger Pressman
e seu livro Engenharia de Software, que inclusive uma
das referncias deste artigo, muitas companhias passaram
a compreender que qualidade apenas pode ser obtida com
auditoria do processo e certificao dos itens que possuem
maior impacto no resultado do produto.
Falando especificamente de Testes, podemos citar como
principais tcnicas:
Teste Funcional;
Teste Estrutural;
Teste Baseado em Falha ou Erro;
Teste de Caixa Branca;
Teste de Regresso.
Veremos agora cada uma destas tcnicas e quais as suas
particularidades.

Teste funcional
O teste funcional, que tambm conhecido como teste caixa
- preta, so os testes definidos de acordo com os requisitos
funcionais do software. Como no h conhecimento sobre a
operao interna do programa, o analista concentra-se nas
funes que o software contemplar. Baseado na especificao
determina-se as sadas que so esperadas para um determinado conjunto de dados.
Esse tipo de teste reflete a tica do usurio, o stakeholder (ler
Nota do DevMan 2) interessado em utilizar o programa, sem
levar em conta os detalhes de sua construo. Comparado a
outros modelos, sua concepo relativamente simples.
Segundo Koscianski, o teste particularmente til para
revelar problemas como:
Funes incorretas ou omitidas;
Erros de interface;

Tes te d e Soft ware

Erros de comportamento ou desempenho;


Erros de iniciao e trmino.

Nota do DevMan 2
Stakeholder: Os interessados em um projeto (stakeholders) so todas as pessoas da
organizao que tm algum tipo de envolvimento direto ou indireto com o sistema,
como usurios, gerentes, clientes, patronos e financiadores.

A principal tcnica utilizada nos testes funcionais a de


particionamento de equivalncia, que visa uma diviso
em subconjuntos das entradas de valores de acordo com as
funcionalidades do software, por exemplo, a insero de
uma massa dados para validar o processo de insero. Seu
principio a escolha da melhor abordagem a ser utilizada e a
melhor maneira de se obter a validao dos erros e aumento
da confiabilidade (BRUNELI, 2006). Uma maneira muito eficaz analisar os dados resultantes e melhorar validaes e
verificaes de entrada.
Alm da tcnica de particionamento de equivalncia, existem
diversas outras tcnicas que podem ser adotadas como a de
Anlise do valor limite, Grafo Causa-Efeito e Error-Guessing.

Teste estrutural
O Teste estrutural, tambm conhecido como teste caixa
branca ou teste caixadevidro ou ainda teste caixa
clara, so os projetos de casos de testes onde seus testes so
desenvolvidos a partir dos conceitos de implementao do
software e da estrutura desenvolvida.
Os testes caixabranca possibilitam avaliar a estrutura interna do programa, sua codificao, mdulos, implementao e
execuo particionada do software, sendo que as informaes
obtidas deste processo de validao tambm so utilizadas
para a criao dos casos de testes.
Em geral, existem diversos critrios para a elaborao dos
testes estruturais, representados com o apoio dos Grafos
de Fluxo de Controle ou Grafos de Programa (ver Figura 1),
demonstrando de maneira clara o fluxo lgico da execuo
do programa. Os critrios dos testes estruturais podem ser
destacados como: Critrios Baseados em Fluxo de Controle,
Critrios Baseados na Complexidade e Critrios Baseados no
Fluxo de Controle.
Critrios Baseados em Fluxo de Controle: Segue de acordo
com as caractersticas de execuo do programa (comandos e
desvios). Para elaborao da lista de verificao so utilizados
critrios como:
- Todos Ns, mtodo que exige que cada comando da aplicao seja executado pelo menos uma vez, passando por cada
vrtice do grafo (ler Nota do DevMan 3);
- Todos Arcos (ler Nota do DevMan 4), mtodo que requer que
cada aresta do grafo seja executada pelo menos uma vez; e
- Todos Caminhos, que requer que todos os caminhos
possveis do programa sejam executados, criando assim um

teste completo, dado o grande numero de possibilidades


existentes.

Nota do DevMan 3
Ns: construdo atravs do cdigo-fonte, onde os seus comandos so os ns do Grafo,
ou seja, so os pontos do grafo, seguindo a sequncia dos comandos (VILELA c, 2005).

Nota do DevMan 4
Arcos: So os desvios que ocorrem no cdigo-fonte do programa, as linhas que ligam
os ns, ou seja, a transferncia de controle entre os blocos (VILELA c, 2005).

Critrios Baseados na Complexidade: So criados a partir


dos requisitos de testes e classificados de acordo com o seu
grau de complexidade. Um dos critrios que so utilizados o
Critrio de McCabe, que visa a execuo do programa atravs
de conjuntos lineares independentes, estabelecendo um nmero
de caminhos linearmente independentes do programa. Ou seja,
caminhos que introduzam pelo menos um novo conjunto de
instrues de processamento ou uma nova condio, utilizando
o conceito da complexidade ciclomtica (ler Nota do DevMan
5) para os requisitos de teste;

Nota do DevMan 5
Complexidade Ciclomtica: Tcnica utilizada para avaliao da complexidade de
altortmos. A frmula utilizada no clculo da Complexidade Ciclomtica CC = Nmero de arcos Nmero de ns + 2, e Server para determinar a quantidade de casos de
teste mnima para testar os caminhos independentes do programa.

Critrios Baseados no Fluxo de dados: Utiliza informaes do


fluxo de dados do programa para a criao dos requisitos dos
testes. Incluem critrios de adequao de controle de fluxo, que
analisam o grafo de execuo de um programa; critrios de adequao baseados no fluxo de dados, que analisam os caminhos
que o cdigo percorre entre a inicializao dos dados e os pontos
onde so alterados e lidos; e critrios de adequao baseados em
uma combinao dos dois tipos, que usam relaes de dependncia entre os comandos e os seus dados operandos.
Como foi dito, na identificao dos caminhos que devem ser
testados pode-se utilizar a tcnica Complexidade Ciclomtica.
Atravs dela possvel fazer a identificao da quantidade
de testes necessrios (ver Figura 1) garantindo que todas as
instrues sejam executadas ao menos uma vez.

Edio 45 - Engenharia de Software Magazine

39

Firme so realizadas alteraes no programa para a criao


do programa mutante, sendo que as comparaes acontecem
desde o incio at o trmino da execuo.

Testes de regresso

Figura 1. Exemplo de Grafo de Fluxo (VILELA C,2005)

A Figura 1 apresenta um exemplo de Grafo de Fluxo demonstrando, com a ajuda da complexidade ciclomtica, o cdigo
implementado, onde so separados os estados de acordo com
as decises do programa e obedecendo a sua ordem no decorrer
da execuo do software. A utilizao destes Grafos auxilia na
criao dos casos de testes.

Testes baseados em falha ou erro


Os Testes Baseados em Erros e Falhas so criados a partir das
informaes dos erros mais comuns que os desenvolvedores
cometem no processo de desenvolvimento, formando uma
base de conhecimento que auxilia na criao dos novos casos
de testes.
Para o desenvolvimento dos casos de testes, existem algumas
tcnicas que podem ser empregadas, como: Semeadura de
Erros e Anlise de Mutantes.
No critrio de Semeadura de Erros so inseridos artificialmente no programa alguns erros. Aps estas inseres so
analisados os erros encontrados e verificados quais so erros
provveis e improvveis, descartando apenas aqueles que
foram propositalmente inseridos para avaliarmos o comportamento da execuo. Atravs do conceito de probabilidade
pode se chegar quantidade provvel de erros naturais que
podem conter no software.
No critrio de Anlise de Mutantes so criados programas
com pequenas alteraes em cima daquele software que ser
testado. O objetivo avaliar a quantidade de testes necessrios
para o software em questo
Na Anlise de Mutantes o foco encontrar casos de testes
capazes de revelar diferenas de comportamentos entre o software original e os softwares cujos trechos foram modificados,
ou seja, nos softwares mutantes. Ao final, os resultados obtidos
da verso original so comparados com a verso modificada.
Os tipos de critrios existentes na Anlise de Mutantes so
a Mutao Fraca e a Mutao Firme. Na Mutao Fraca cria-se
o mutante inicialmente, antes do incio da execuo e aps
seu trmino quando os dados so comparados. Na Mutao

40

Engenharia de Software Magazine - Testes funcionais de software

Essa uma tcnica de teste aplicvel a uma nova verso de


software ou a uma verso em desenvolvimento. Ela consiste
em aplicar, a cada nova verso do software ou a cada ciclo,
todos os testes que j foram aplicados nas verses ou ciclos
de teste anteriores do sistema. Inclui-se nesse contexto a observao de fases e tcnicas de teste de acordo com o impacto
de alteraes provocado pela nova verso ou ciclo de teste.
Para efeito de aumento de produtividade e de viabilidade dos
testes, recomendada a utilizao de ferramentas de automao, de forma que, sobre a nova verso ou ciclo de teste, todos
os testes anteriores possam ser executados novamente com
maior agilidade.

Projeto de casos de testes


O projeto de casos de testes define as situaes que sero utilizadas como base tanto para validar os requisitos funcionais
quanto para avaliar a eficcia dos componentes.
No projeto de casos de testes so descritas suas entradas e
sadas (ver Nota do DevMan 6), de acordo com cada caracterstica do software, visando os requisitos e especificaes
do projeto. Os casos de testes so elaborados para exercitar
adequadamente as estruturas do programa.

Nota do DevMan 6
Entradas e Sadas: Dado de Entrada Conjunto de todos os valores que podem ser
usados como entrada para um programa.
Dado de Sada Conjunto de valores que podem ser obtidos como sadas do programa.

Os casos de teste podem ser utilizados em diversos seguimentos. Segundo Sommerville, os principais so:
Na criao e implementao de esquemas de scripts de testes,
fornecendo os pontoschaves de acordo com as implementaes dos requisitos no momento da codificao do software;
Utilizao de scripts para identificao dos melhores testes,
tanto para testes manuais quanto para testes automticos;
Um controle dos nmeros de teste especficos para abranger
todo o software.

Fases de teste
Os testes de software possuem estratgias que so utilizadas
na execuo dos testes, e podem ser divididos em etapas como:
Teste de Unidade, Teste de Integrao, Teste de Componentes,
Teste de Validao e Teste de Sistema.
As estratgias de testes permitem a verificao dos erros nos
diversos tipos de software, possibilitando uma maior cobertura
do software de acordo com o nvel do teste, podendo ocorrer

Tes te d e Soft ware

O teste de unidade a fase de teste que tem como finalidade


testar individualmente as funcionalidades do software em
questo, garantindo que todas as funcionalidades do software
sejam testadas pelo menos uma vez.
Uma das desvantagens do teste de unidade que sua implementao exaustiva e necessita de prazos maiores para realizao, sendo que para a realizao dos testes deve-se conhecer
os objetivos e especificaes dos requisitos de cada uma das
funcionalidades do software. Por outro lado, sua vantagem
a localizao e preveno de falhas por estar testando cada
uma das funcionalidades individualmente.

Teste de integrao
O teste de integrao a fase que testa a integrao dos
componentes do sistema, se esto de acordo com os requisitos
do software, levando em considerao a sua funcionalidade em
conjunto e no as suas regras de negcios, procurando assim
erros associados a interfaces. O teste de integrao pode ser
dividido em dois tipos:
No Incremental: Os mdulos do sistema so interligados e
combinados, e o software testado como um todo, dificultando
a localizao dos erros e a correo dos erros encontrados;
Incremental: O software testado em partes, possibilitando que as interfaces sejam testadas de forma incremental,
facilitando encontrar erros e isol-los para correo. O teste
incremental possui duas estratgias:
- Integrao descendente (top-down), onde os mdulos do
sistema so integrados de cima para baixo de acordo com a
hierarquia de controle do software; e
- Integrao ascendente (bottom-up), onde a construo e
os testes dos mdulos so iniciados da parte mais baixa da
estrutura do software.

Teste de componentes
No teste de componentes os componentes do software so
testados separadamente de acordo com a especificao e estrutura das funcionalidades. Estes componentes so as integraes
de interface e unidades do software, com diversas classes no
seu desenvolvimento.

Teste de validao

Teste de sistema

Os testes automatizados so desenvolvidos como programas


ou scripts que tm como principal objetivo exercitar o sistema,
testando as funcionalidades e verificando se esto de acordo
com as especificaes dos requisitos do sistema e os objetivos
esperados.
Existem diversas vantagens para a utilizao dos testes automatizados, dentre elas destacam-se:
Menor tempo na execuo dos testes;
Verificao do sistema durante o processo de desenvolvimento;
Alcanar melhor qualidade do software;
Casos de testes mais elaborados.
A grande vantagem dos testes automatizados que podem
ser repetidos a qualquer momento, seja em uma nova funcionalidade ou alguma modificao em uma funcionalidade
especfica. Sua implementao reduz os esforos e o tempo
gasto, reduzindo as chances de que ocorram falhas humanas
na execuo dos testes.
Os testes automatizados reduzem o tempo no processo de
testes, porm, precisa ser complementado por outros tipos
de testes.

Concluso
A utilizao de testes ao longo do projeto de desenvolvimento e implementao do software permite que tenhamos uma
ampla viso sobre o comportamento do mesmo, eliminando
falhas e erros que poderiam causar divergncia em seu funcionamento. Como foi apresentado, um plano de testes possibilita
encontrarmos as no conformidades do software em relao
aos requisitos do sistema e resolve-las de uma forma rpida
e eficaz.
Vimos que existem vrias maneiras de se aplicar Testes em
um projeto de desenvolvimento, e que todas possuem o mesmo
objetivo: reduzir a chance de entregarmos software contendo
defeitos para o cliente.
D seu feedback sobre esta edio!
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
Para isso, precisamos saber o que voc, leitor, acha da revista!
D seu voto sobre este artigo, atravs do link:

Feedback
eu

www.devmedia.com.br/esmag/feedback

O teste de sistema realizado aps o sistema estar pronto,


sendo avaliados todos os componentes e funcionalidades.

Edio 45 - Engenharia de Software Magazine

41

sobre e
s

O teste de validao tem como objetivo avaliar se o sistema


desenvolvido funciona de maneira que atenda a todas as especificaes dos requisitos do software e o processo de regras
de negcios estabelecidas na sua elaborao.

Testes automatizados

D
s

Teste de unidade

O objetivo do teste de sistema exercitar todo o software,


assegurando que todos os elementos que compem o sistema
esto de acordo com as especificaes dos requisitos, incluindo
todos os itens de hardware e software que compem a regra
de negcio. Existem vrios tipos de teste de sistema, tais como:
Teste de Desempenho (agilidade), Teste de Segurana (confiabilidade), Teste de Recuperao (recuperao de dados) e Teste
de Inicializao (insero).

edio
ta

em baixo nvel ou em alto nvel. Os testes de baixo nvel focam


uma funcionalidade especfica que se deseja testar, enquanto
os testes de alto nvel tm o objetivo de verificar as funes do
software de acordo com os requisitos do sistema.

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

Dando foco ao negcio com DDD


Entendendo o domnio do software

De que se trata o artigo?


Este artigo apresenta o Domain-Driven Design (DDD),
abordagem de desenvolvimento de software que
mostra uma srie de prticas e padres para se construir um software dando foco principal ao domnio.

N
Robson Castilho
robsoncastilho@yahoo.com.br

Trabalha com desenvolvimento de software h 12 anos, tendo desenvolvido sistemas


desktop e web para empresas de diversos
ramos de atividade. Bacharel em Cincia
da Computao, pela UFMS, e possui as
certificaes MCTS (Windows/Web), PSD
(Professional Scrum Developer) e PSM I
(Professional Scrum Master Nvel I). Mantm o blog tcnico http://robsoncastilho.
wordpress.com.

42

o processo waterfall tradicional, toda a fase de desenvolvimento do software guiada


pela parte tecnolgica, com pouco ou
nenhum foco no negcio. Isto porque
toda a anlise feita previamente por
um analista de sistemas e passada, em
forma de muita documentao, para o
time de desenvolvedores, cabendo a eles
simplesmente implementar com base nos
requisitos recebidos.
J nas metodologias geis, embasadas
no Manifesto gil e seus princpios, a
presena constante dos especialistas
de negcio junto dos desenvolvedores
algo essencial. O software entregue
aos poucos, sendo assim, anlise, implementao e testes so realizados iterativamente, de forma a entregar pedaos
de software o mais cedo possvel.
Neste contexto de agilidade, Eric
Evans, especialista em modelagem de

Engenharia de Software Magazine - Dando foco ao negcio com DDD

Em que situao o tema til?


As prticas do DDD auxiliam no desenvolvimento de
um software mais coerente com a rea de negcio
qual voltado e, portanto, um software de mais
valor para o cliente, fcil de ser mantido e estendido. As tcnicas de Design Estratgico facilitam no
relacionamento entre diversos times de desenvolvedores, trabalhando em mdulos diferentes de um
sistema complexo (que podem inclusive terem sido
desenvolvidos em diferentes tecnologias).

Resumo?
Este artigo introduz o Domain-Driven Design e
suas premissas (domnio e modelo), dando bastante enfoque comunicao com os especialistas de negcio e modelagem do domnio. So
explicados conceitos-chave como a Linguagem
Ubqua e o Model-Driven Design, com seus principais padres para expressar o modelo no cdigo. Por fim, so mostrados os padres do Design
Estratgico, como formas de comunicao entre
times/sistemas diferentes.

DDD

domnios complexos, escreveu o livro Domain-Driven Design


Tackling Complexity in the Heart of Software (lanado em
2003), com uma srie de conceitos e prticas dando foco ao
domnio do software.
Evans percebeu, ao longo de anos de experincia trabalhando em projetos complexos, que os projetos bem-sucedidos
tinham em comum um modelo rico do domnio, que evolua
incrementalmente iterao aps iterao. Seguindo este
pensamento, seu livro deu nfase justamente na modelagem
do domnio enquanto a maioria dos livros dava nfase na
resoluo de problemas tecnolgicos, como redes e bancos de
dados tornando-se assim um clssico do gnero.
Neste contexto, neste artigo abordaremos alguns dos principais conceitos e prticas do Domain-Driven Design, como a
linguagem ubqua e a comunicao constante com os especialistas de negcio, a modelagem e a implementao como uma
nica atividade, e as prticas do Design Estratgico.

DDD e suas premissas


O Domain-Driven Design (DDD) uma abordagem de desenvolvimento de software fundamentada em duas premissas:
O foco principal deve ser o domnio;
Domnios complexos devem estar baseados em um
modelo.
O domnio de um software a rea de ao, conhecimento
e influncia do software. Sendo assim, focar no domnio dar
mais ateno rea de negcio que o software pretende cobrir
do que a detalhes sobre tecnologias a serem empregadas em
seu desenvolvimento.
Quando estamos trabalhando em domnios complexos e
normalmente estamos bastante til trabalharmos em cima
de um modelo.
Ao falarmos de modelo, geralmente associamos o termo a
algum tipo de diagrama, como um diagrama de classes UML.
No entanto, um modelo mais do que um diagrama, ele uma
traduo do conhecimento dos especialistas de negcio para
algo mais padronizado, uma espcie de molde do domnio.
Para a construo deste modelo, so aplicados padres do
MDD (Model-Driven Design) que sero vistos na seo correspondente ao mesmo.
Um diagrama, seja ele UML ou seguindo qualquer notao
que voc achar til, pode ser uma tima ferramenta para
comunicar e registrar alguns aspectos do modelo, enquanto
outros aspectos so transmitidos de forma mais clara diretamente pelo cdigo.

Modelagem efetiva
Projetar um software orientado ao domnio uma tarefa muito mais difcil do que simplesmente ir fazendo, uma vez que
trazer o conhecimento da cabea de um especialista de negcio
para um software, de forma organizada, algo complexo.
A tentativa de se colocar todo o mundo real dentro do software acaba gerando um software confuso, de difcil extenso
e com recursos que no agregam valor ao usurio final.

Para nos ajudar a organizar um domnio complexo, DDD


apresenta uma srie de prticas, sendo a modelagem do domnio um conceito-chave para essa tarefa.
Deste modo, com o intuito de obtermos sucesso na modelagem, devemos:
Ligar diretamente o modelo implementao;
Estabelecer uma linguagem baseada no modelo, que propicie a comunicao entre desenvolvedores e especialistas de
negcio;
Desenvolver um modelo rico, onde os objetos tenham comportamento, resolvam problemas complexos e deixem explcitos conceitos importantes do domnio;
Destilar o modelo, de forma que somente o que importa
permanea no mesmo;
Realizar brainstorming e experimentar diferentes alternativas para o modelo.
Falaremos mais sobre modelagem nos tpicos seguintes,
entrando em mais detalhes sobre alguns dos itens acima.

Linguagem Ubqua
Todos ns sabemos que especialistas de negcio no entendem
linguagem tcnica, no entanto, comum presenciarmos desenvolvedores conversando com eles justamente em termos tcnicos, ou seja, falando sobre tabelas, ndices, servidores, etc.
Isto faz com que acabemos por acostumar os especialistas com
essa linguagem e, como consequncia, eles acabam tentando definir como fazer tecnicamente ao invs de focarem em explicar
o domnio, o que pode ser trgico para um projeto de software.
O ideal, portanto, que ns desenvolvedores cultivemos uma
linguagem comum junto aos especialistas de negcio, totalmente focada no domnio, afinal, a parte tcnica conosco!
Surge ento um dos conceitos mais importantes em DDD: a
linguagem ubqua (Ubiquitous Language), que a linguagem
presente em todas as etapas do processo de desenvolvimento
do software, por exemplo: na conversa com os especialistas, na
documentao, nos diagramas e no cdigo. A linguagem ubqua , portanto, parte integral do processo de desenvolvimento
do software, sendo essencial para uma melhor comunicao
entre desenvolvedores e especialistas de negcio.
Como consequncia do uso da linguagem ubqua, quaisquer
alteraes na linguagem implicaro em mudanas no modelo e
no cdigo. Alm disso, desenvolvedores sero capazes de identificar com mais facilidade pontos contraditrios no modelo.

Obteno de conhecimento
No incio de um projeto de software, ns desenvolvedores
nunca temos total conhecimento sobre o domnio. Por mais
que j tenhamos lidado com situaes semelhantes em outros
projetos, preciso conhecer as peculiaridades de cada cliente,
mantendo contato direto com os especialistas de negcio.
medida que o projeto avana, uma srie de fatores pode
prejudicar o conhecimento do domnio, tais como troca de
membros do time, terceirizao de partes do sistema e mudanas de escopo.

Edio 45 - Engenharia de Software Magazine

43

Sendo assim, necessrio que os desenvolvedores estejam


empenhados em manter o conhecimento, praticando o aprendizado contnuo. Para os desenvolvedores, aprendizado contnuo significa evoluir constantemente tanto o conhecimento
tcnico quanto o conhecimento sobre o domnio no qual eles
esto trabalhando.
O processo de aprendizado pode ser resumido em uma
palavra: EXPLORAO. Esse processo se d por meio de
conversas constantes com os especialistas de negcio, que so
fundamentais para se trabalhar com DDD.
preciso ter cuidado com os especialistas que entram em um
nvel muito profundo de detalhamento, perdendo o foco da
conversa, e tambm com aqueles que omitem muitos detalhes,
por acharem que j esto subentendidos ou que os desenvolvedores no iro entend-los.
Cabe aos desenvolvedores conduzir os especialistas, de modo
que estes forneam os detalhes necessrios para o entendimento de certa funcionalidade, sem, claro, tirar-lhes a liberdade
para que apontem algo de importante.

Documentao
DDD no prescreve nenhuma forma especfica de documentao do software. Quanto aos diagramas, DDD sugere
a utilizao deles para auxiliar na comunicao e facilitar
brainstormings com os especialistas. Algumas pessoas so
totalmente visuais e desenhar uma forma de transmitir uma
ideia de modo mais objetivo.
Para que os diagramas sirvam aos propsitos mencionados
acima, eles devem ser enxutos, focados em um determinado
assunto. Entretanto, muitos desenvolvedores tentam transmitir
todo o modelo em apenas um diagrama, normalmente UML, o
que sobrecarrega de informaes o leitor, alm de no conseguirem mostrar facilmente o comportamento dos objetos.
Alm da UML, DDD sugere outros tipos de diagramas (mais
simples e muitas vezes feitos mo), como o apresentado na
Figura 1.

Figura 1. Diagrama simples para comunicao

Quanto documentao escrita, deve-se notar quando os


termos usados comeam a desaparecer das conversas e do
cdigo, deixando de fazer parte da linguagem ubqua. A documentao passa, ento, a ser ignorada e mant-la torna-se um
verdadeiro desperdcio de esforo (restando ao time arquiv-la
como histrico ou exclu-la).
Portanto, DDD fornece algumas diretrizes para avaliar a
necessidade de se documentar:
Documentos devem complementar a fala e o cdigo. Todos
os detalhes essenciais do design devem estar presentes no
cdigo, por meio de prticas do MDD (Model-Driven Design),
que veremos mais adiante;
Documentos devem estar envolvidos nas atividades do projeto, estando sincronizados com a linguagem ubqua.

44

Engenharia de Software Magazine - Dando foco ao negcio com DDD

Sinergia com Agile


Embora DDD no esteja vinculado a nenhum processo ou
framework especfico, notrio que seus ideais vo ao encontro
do manifesto gil. Maior interao entre as pessoas, menos
documentao e modelagem evolutiva so alguns pontos a
mencionar.
Vejamos a proximidade entre desenvolvedores e especialistas de negcio. No processo waterfall tradicional, no h
colaborao entre eles. Fica a cargo do analista de sistema
conversar com o especialista, abstrair e passar as informaes
aos desenvolvedores, que simplesmente codificam.
Sobre a modelagem evolutiva: iterao aps iterao, o modelo constantemente refinado, uma vez que o aprendizado
sobre o domnio vai progredindo. Em uma abordagem waterfall, toda a modelagem feita antes da codificao, sendo
assim, o analista perde a oportunidade de obter feedback dos
desenvolvedores.
Porm, vale alertar que, mesmo trabalhando com uma metodologia gil, pode haver falha na obteno de conhecimento se
os desenvolvedores no tiverem interesse em discutir sobre o
domnio. Desenvolvedores alheios ao domnio simplesmente
obtm dos especialistas o que o software deve fazer e implementam a funcionalidade sem saber os motivos por trs daquilo. Assim, perde-se a oportunidade de se criar um software
mais atrativo e que agregue mais valor para o cliente.

Model-Driven Design
Um dos pontos mencionados no incio deste artigo sobre
modelagem efetiva foi: ligar o modelo diretamente implementao. Em outras palavras, o cdigo deve expressar os
detalhes do domnio de forma clara. Isto impraticvel se
estivermos utilizando um modelo de anlise previamente
definido e passado aos desenvolvedores.
Tal modelo criado com o propsito de entendimento do
domnio, sem considerar detalhes de design. E neste ponto
que ele falho, pois vrias descobertas sobre o domnio surgem exatamente no momento do design/implementao. Na
prtica, se o modelo no expressa conceitos-chave do domnio
e se implement-lo complicado, ou simplesmente, impossvel,
os desenvolvedores acabam abandonando o mesmo e criando
um modelo prprio.
neste contexto que surge o Model-Driven Design (MDD),
uma abordagem de modelagem com o propsito de unir o
modelo de anlise e o design em um nico modelo.
Para que seja possvel uma correspondncia entre o modelo
e o design, necessria a utilizao de um paradigma de programao que tenha um bom suporte de ferramentas. Neste
ponto, a OOP mostra-se um paradigma maduro, bem conhecido entre a comunidade de desenvolvedores, e que permite
a construo de um modelo rico, com objetos representando
conceitos do domnio.
Outro fator importante para a prtica do MDD que os desenvolvedores devem ser responsveis pela modelagem do
software. Por mais que algumas pessoas do time tenham mais
habilidades de codificao e outras de modelagem, preciso

DDD

que os desenvolvedores estejam envolvidos em algum nvel de


discusso sobre o modelo e em contato com os especialistas de
negcio. Assim como pessoas mais aptas modelagem devem
passar algum tempo codificando. Em outras palavras, modelagem
e codificao no devem ser separadas em tarefas distintas.
Trabalhando desta forma, possvel transferir conhecimento
do domnio e habilidades tcnicas dos desenvolvedores mais
experientes para outros desenvolvedores, facilitando na criao
de softwares coerentes com o domnio, de fcil compreenso
e extenso.

Blocos de construo do MDD


O MDD composto por um conjunto de padres, com o
propsito de auxiliar na representao do domnio atravs do
cdigo. Esses padres formam o alicerce, ou blocos de construo do MDD, uma vez que do sustentao para organizar
o design e melhorar a compreenso do cdigo.
O primeiro padro a arquitetura em camadas, que proposta pelo MDD conforme a Figura 2.

Figura 2. Camadas propostas pelo MDD

Cada camada tem uma responsabilidade especfica:


Interface com Usurio (UI) responsvel por mostrar informaes ao usurio, bem como interpretar comandos do usurio. Algumas vezes, o usurio pode ser um sistema externo;
Aplicao responsvel por coordenar tarefas, utilizando
objetos das camadas inferiores. Trata da converso de dados,
segurana e controle de transaes. E serve como uma fachada,
expondo dados do domnio para diversos tipos de UI;
Domnio contm todas as informaes do domnio. DDD
est totalmente focado nesta camada. Como diz Eric Evans,
esta camada o corao do software;
Infraestrutura fornece suporte tcnico s camadas superiores, como: log, persistncia de dados, autenticao/
autorizao, etc.
De acordo com o tipo e complexidade do projeto, pode haver
variaes de camadas, como por exemplo, a existncia de uma

camada de servios distribudos e vrias camadas de infraestrutura. Por outro lado, projetos que possuam apenas um tipo
de UI podem abrir mo da camada de aplicao.
No entanto, para permitir a aplicao do MDD, crucial a
existncia da camada de domnio. Isolar o domnio traz clareza sobre o que faz parte dele e o que no faz, e o deixa livre
de outras responsabilidades (como exibio e persistncia),
permitindo que o modelo evolua de forma que capture o
conhecimento essencial do negcio.
Para expressarmos o modelo no cdigo, o MDD sugere trs
padres: Entidades, Objetos de Valor e Servios.
Entidades (Entities) so objetos que possuem uma identidade
conceitual dentro da aplicao. Por exemplo, duas transaes
bancrias de mesmo valor, feitas no mesmo dia, ainda so duas
transaes distintas, logo possuem identidade e so Entidades.
No entanto, para distinguirmos essas duas transaes,
necessrio que cada uma delas possua um atributo nico (ou
conjunto de atributos nicos). Este atributo pode surgir do
domnio ou ainda ser um ID gerado pela aplicao.
Entidades tambm possuem um ciclo de vida na aplicao.
Por exemplo, em um software para uma clnica mdica, desejamos acompanhar cada paciente da clnica: cadastr-lo,
atualizar seus dados, registrar as consultas, inativ-lo ou
exclu-lo.
Objetos de Valor (Value Objects) so objetos que representam algum aspecto do domnio sem nenhuma identidade
conceitual. Normalmente, so objetos que do caracterstica
a alguma entidade. Por exemplo, para uma entidade Carro,
o pneu poderia ser um objeto de valor, caso no houvesse o
menor interesse para o domnio em diferenciarmos um pneu
de outro.
Um objeto de valor normalmente imutvel, ou seja, criamos
um objeto de valor com certos atributos e nunca mais alteramos. No exemplo do pneu, caso quisssemos trocar o pneu do
carro, simplesmente criaramos um pneu novo e colocaramos
no lugar do velho.
Servios (Services) so objetos que realizam alguma operao do domnio que no se aplica a nenhuma entidade ou objeto
de valor. Muitas vezes, podem aparecer conceitos do domnio
que so meramente aes e no dados. Essas aes utilizam
outros objetos do domnio para executar alguma operao de
negcio. Tomemos, como exemplo, uma transferncia bancria.
Ela uma operao do domnio que utiliza duas contas bancrias e gera duas movimentaes (crdito e dbito).
Um bom servio no deve possuir estado (ou seja, toda chamada ao mesmo, dadas as mesmas entradas, deve retornar o
mesmo resultado), deve fazer sentido para o domnio (seu nome
faz parte da linguagem ubqua) e seus parmetros e resultados
devem ser objetos do domnio.
Outros trs padres sugeridos pelo MDD esto diretamente
relacionados ao ciclo de vida dos objetos do domnio. So eles:
Agregados, Fbricas e Repositrios.
Agregados (Aggregates) so grupos de objetos associados
(entidades e objetos de valor), tratados como uma unidade do
ponto de vista de alterao dos dados. Todo agregado possui

Edio 45 - Engenharia de Software Magazine

45

um limite e uma raiz. O limite define quais objetos esto dentro


do agregado. E a raiz uma entidade que constitui o nico
ponto de acesso de objetos fora do agregado.
Um exemplo de agregado ilustrado na Figura 3.

de armazenamento (normalmente, um banco de dados). Em


se tratando de um agregado, s haver um repositrio para a
raiz do mesmo, uma vez que os demais objetos sero obtidos
via associao.
Repositrios e fbricas se relacionam ao modelo de forma
similar, cuidando do ciclo de vida dos objetos. Enquanto uma
fbrica cuida da criao de objetos, um repositrio cuida de
objetos j existentes.

Em busca de um modelo profundo

Figura 3. Exemplo de agregado Carro

Como visto no exemplo, o agregado Carro composto de


duas entidades: Carro e Pneu. Objetos fora do agregado (no
exemplo, Cliente) s podem fazer referncia raiz. Alm disso,
permitido que objetos dentro do agregado faam referncias
uns aos outros e tambm s razes de outros agregados.
Um agregado tem o propsito de garantir a integridade dos
dados, por meio de um conjunto de regras como as ilustradas no exemplo anterior - que simplificam a associao entre
objetos.
Outras regras importantes de consistncia dos dados dizem
respeito a operaes de excluso e invariantes. Em uma operao de excluso, todos os objetos do agregado devem ser
excludos de uma s vez. Quanto s invariantes (regras de
consistncia que devem ser mantidas sempre que os dados
so alterados), ao salvarmos uma alterao em qualquer
objeto do agregado, todas as invariantes do agregado devem
permanecer atendidas.
Para facilitar no entendimento das invariantes, tomemos, por
exemplo, um agregado Pedido que contenha duas entidades:
Pedido (raiz) e ItemDoPedido. Uma invariante poderia dizer
que a soma de todos os itens do pedido no deve ultrapassar
um limite mximo aprovado para o pedido. Assim, devemos
garantir que, sempre que formos salvar o pedido, esta invariante permanea atendida, mesmo que tenhamos alterado o limite
aprovado do pedido ou qualquer um dos itens do pedido. Se o
agregado tivesse outros objetos com outras invariantes, todas
deveriam estar satisfeitas ao salvar o pedido.
Fbricas (Factories) so objetos responsveis pela criao de
objetos. Devem ser utilizadas quando a criao de um objeto
de domnio for muito complexa, envolvendo, por exemplo, a
criao de um agregado com vrios objetos.
Repositrios (Repositories) so responsveis por abstrair o
local onde so armazenados os objetos de domnio. Eles apresentam uma forma simples de obter objetos e salv-los, alm
de desacoplar o domnio da tecnologia de persistncia.
Um repositrio de clientes, por exemplo, funciona como uma
coleo de clientes e permite salvar e recuperar clientes do local

46

Engenharia de Software Magazine - Dando foco ao negcio com DDD

Desenvolvedores devem estar constantemente em busca de


aprendizado sobre conceitos do domnio, expondo conceitos
antes implcitos. Um conceito pode estar implcito na forma de
um conjunto de informaes vindas de diversos objetos e que
aparecem com frequncia no software. Deste modo, pode-se
concluir, aps vrias conversas, que essas informaes so
um conceito importante, transformando-as em um objeto e
agregando este conceito linguagem ubqua.
A busca por um modelo profundo (deep model, como denominado pelo Eric Evans) se d por meio de muita conversa
com os especialistas de negcio, esclarecendo e validando
determinados pontos. Pode ser vlido tambm que os desenvolvedores leiam algum livro sobre o negcio em questo, com
a finalidade de ganharem maior conhecimento e dialogarem
em um nvel melhor com os especialistas.
Esta evoluo para um modelo mais profundo ocorre normalmente aps um evento descrito por Evans como breakthrough
(o que em uma traduo livre seria algo como uma importante descoberta). um momento durante o processo onde
os desenvolvedores finalmente percebem ou entendem algum
conceito importante, o que leva a uma srie de mudanas no
design.
No entanto, um breakthrough no deve ser algo forado. Para
que surja uma oportunidade para um breakthrough, preciso
focar na explorao do domnio, fazer refinamentos constantes
no design e cultivar uma linguagem ubqua robusta.

Design Estratgico (Strategic Design)


comum que sistemas muito grandes e complexos tentem ser
desenvolvidos como um nico projeto, utilizando um nico
modelo. Esse tipo de estratgia muito arriscado e pode ser
totalmente impraticvel.
Imagine uma classe Cliente do modelo. Em determinado
contexto, por exemplo no mdulo de Cobrana, Cliente poderia precisar de certas informaes que em outro(s) contexto(s)
no fazem sentido. Situaes como esta contribuiriam para tornar o modelo muito difcil de entender, uma vez que teramos
desenvolvedores brigando para satisfazer as necessidades
do contexto em que esto trabalhando, e, em consequncia,
causando bugs em outras partes do sistema, gerando cdigo
duplicado, etc.
Dentro deste cenrio, o Design Estratgico apresenta uma
srie de prticas voltadas modularidade de sistemas grandes
e integrao entre os mdulos (e entre os respectivos times
trabalhando neles).

DDD

No Design Estratgico, o conceito de Contexto Delimitado


(Bounded Context) o mais importante. Um contexto define
uma fronteira clara de um modelo. Ao explicitarmos todos os
contextos, cada time pode trabalhar em seu modelo de forma
isolada, mantendo sua prpria linguagem ubqua, sem se
preocupar com o que est fora de seu contexto.
Em um sistema muito grande, certamente teremos mais de um
contexto compondo o mesmo, com um time de desenvolvedores
responsvel por cada contexto. Para facilitar a visualizao do
sistema como um todo, podemos fazer uso de um Mapa de
Contextos (Context Map), como o apresentado na Figura 4.

Figura 4. Mapa de Contextos

Por meio do mapa de contextos, temos uma viso dos vrios


contextos do sistema e quais so os pontos de acesso de cada
um deles.
Para que todos os contextos sejam integrados com eficincia, ou
seja, preservando a integridade de seus respectivos modelos, o
Design Estratgico apresenta alguns padres, descritos a seguir.
O Ncleo Compartilhado (Shared Kernel) uma forma de
relacionamento entre contextos onde dois ou mais times definem um subconjunto do modelo onde iro trabalhar juntos.
mais aplicvel quando h muita necessidade de comunicao
entre os times, pois seus contextos possuem muitas similaridades. Com isso, reduz-se muito a duplicao de cdigo.
O ncleo compartilhado no deve ser alterado sem comum
acordo entre os times. Tcnicas como integrao contnua e
testes automatizados garantem a integridade do ncleo.
O padro Cliente/Fornecedor (Customer/Supplier) se aplica
quando claramente temos um contexto que alimenta outro.
Um time faz o papel de cliente, solicitando tarefas para o time
fornecedor. comum que nesta situao tenhamos contextos
implementados com diferentes tecnologias, tornando invivel
o uso de um ncleo compartilhado.
A necessidade de comunicao entre os times, assim como no
ncleo compartilhado, grande, com reunies constantes para se
definir o que poder ser entregue pelo fornecedor e quando.
Em alguns casos, a comunicao entre dois times pode ser
muito difcil, mesmo que faam parte da mesma empresa. Isso

pode ocorrer por vrios fatores: mudana de foco de mercado


por parte de um dos times, times pertencentes a hierarquias
diferentes dentro da empresa, etc.
Quando no h motivao para um time atender as necessidades do outro, este fica de mos atadas. Neste caso, h trs
caminhos a seguir. Um deles adotar o padro Conformista
(Conformist). Ele seguido quando o modelo do time upstream de qualidade razovel e o time downstream ainda
consegue algum tipo de ajuda, por menor que seja.
O padro Conformista assemelha-se ao Ncleo Compartilhado, uma vez que h uma rea compartilhada entre ambos os
times. Porm as semelhanas param por a. No Ncleo Compartilhado, h muita colaborao entre os times, enquanto no
Conformista, um dos times apenas aceita o modelo vindo do
outro time, que no possui muito interesse em colaborar.
Outro caminho a ser seguido a adoo do padro Camada
Anti-Corrupo (Anti-corruption Layer). Neste cenrio, ainda
h o interesse de se utilizar o contexto do outro time, porm a
qualidade do cdigo muito ruim e fora dos padres do time
downstream. Sendo assim, para no contaminar o contexto do
mesmo, criada uma camada intermediria, responsvel pela
traduo das informaes de um contexto para outro.
H ocasies mais extremas onde integrar simplesmente
invivel. Sendo assim, adota-se o padro Caminhos Separados
(Separated Ways). Nele, um time trabalha isoladamente em seu
contexto, sem integrao qualquer com outros contextos.
Retornando aos relacionamentos mais cooperativos, imagine
um contexto que precise se integrar a diversos outros sistemas.
Tais sistemas precisam consumir informaes do contexto e podem estar dentro do prprio time, com outro time da empresa ou
at mesmo fora da empresa. Neste caso, adota-se o padro Servio
de Host Aberto (Open Host Service), expondo um conjunto de
servios que podem ser consumidos por vrios clientes.
Por fim, pode ser til publicar, ou seja, formalizar um Open
Host Service por meio de uma Linguagem Publicada (Published Language), para que os consumidores do servio
conheam todas as suas operaes e saibam como execut-las
(como feito hoje em dia por vrios fornecedores, como Google,
Twitter e Amazon).

Concluso
Domain-Driven Design apresenta uma srie de conceitos e
padres com o intuito de direcionar o desenvolvimento do
software para o que h de mais importante nele: o domnio.
Seguindo essa abordagem, somos capazes de desenvolver
software mais coerente com a rea de negcio em questo,
software de mais valor para o cliente e que possa ser expandido
com maior facilidade.
DDD apresenta vrios outros conceitos no contidos neste
artigo. Para um melhor entendimento e maior aprofundamento
no assunto, altamente recomendada a leitura do livro de Eric
Evans, Domain-Driven Design Tackling Complexity in the
Heart of Software, que deu origem ao DDD.
Para que o DDD seja utilizado de forma efetiva, no basta a aplicao de um ou outro padro. So obrigatrios: a

Edio 45 - Engenharia de Software Magazine

47

Evans, E. Domain-Driven Design:Tackling Complexity in the Heart of Software. Addison Wesley, 2004.
Domain Language Empresa de Eric Evans.
www.domainlanguage.com
Domain-Driven Design Community.
www.domaindrivendesign.org
sobre e
s

A Engenharia de Software Magazine tem que ser feita ao seu gosto.


Para isso, precisamos saber o que voc, leitor, acha da revista!
D seu voto sobre este artigo, atravs do link:

Links

Feedback
eu

edio
ta

D seu feedback sobre esta edio!

D
s

comunicao constante entre desenvolvedores e especialistas


de negcio, cultivando uma linguagem ubqua; e o desenvolvimento iterativo, para que o modelo possa ir evoluindo ao
longo do projeto.

www.devmedia.com.br/esmag/feedback

48

Engenharia de Software Magazine - Dando foco ao negcio com DDD

Domain-Driven Design Quickly (mini-book InfoQ).


www.infoq.com/minibooks/domain-driven-design-quickly
Artigos, Palestras e Entrevistas com Eric Evans (InfoQ).
www.infoq.com/author/Eric-Evans

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

Boas prticas para escrita de mtodos,


funes e procedimentos Parte 7
Tornando limpa a viso macro do sistema

Jacimar Fernandes Tavares

De que se trata o artigo?

Resumo?

Aborda o tema Cdigo Limpo com o objetivo de mostrar como o desenvolvedor pode us-lo para melhorar
a qualidade do cdigo-fonte de suas aplicaes. Neste
sentido, este artigo prov conhecimento ao desenvolvedor sobre como transformar cdigos considerados
ruins em bons cdigos demonstrando, atravs de
exemplos prticos, as teorias abordadas.

Esta srie de artigos tem discutido os aspectos


que permeiam o assunto Cdigo Limpo, seguindo
a linha de raciocnio que prope um aumento na
qualidade do cdigo das aplicaes existentes ou
proporcionar conhecimento de como criar projetos
de cdigo melhores quando se est iniciando um
novo projeto. Neste contexto, cdigo limpo se refere a um conjunto de caractersticas desejveis de
serem encontradas no cdigo de nossa aplicao.
Algumas dessas caractersticas so: ter um cdigo
que atenda os requisitos de eficincia, lgica do
negcio bem modelada e definida em forma de
cdigo fonte, mecanismos de tratamento de erro
bem definidos e cdigo que no d margem necessidade da realizao de novas otimizaes.

jacimar.tavares@hotmail.com

Ps Graduando em Gesto de Projetos de


TI Universidade Federal de Juiz de Fora
UFJF
Bacharel em Cincia da Computao FAGOC
- Faculdade Governador Ozanam Coelho,
Atua como administrador financeiro na
empresa Transporte JR.

Em que situao o tema til?


O tema se torna fundamental para desenvolvedores que buscam cada vez mais melhorar suas
aplicaes ao focar em qualidade de cdigo. Essa
tarefa ser possvel graas ao conhecimento adquirido sobre limpeza de cdigo.

Marco Antnio Pereira Arajo


maraujo@devmedia.com.br

Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ,


Especialista em Mtodos Estatsticos Computacionais e Bacharel em Informtica pela
UFJF, professor do curso de Bacharelado em
Cincia da Computao da FAGOC, professor
dos Cursos de Bacharelado em Sistemas de
Informao do Centro de Ensino Superior
de Juiz de Fora e da Faculdade Metodista
Granbery, Analista de Sistemas da Prefeitura de Juiz de Fora, Editor da Engenharia de
Software Magazine.

t este momento, a srie de artigos sobre cdigo limpo abordou importantes teorias que
envolvem a construo ou modificao
do projeto de cdigo existente com o
objetivo de ter estruturas de cdigo cada
vez mais limpas.
No primeiro artigo da srie foi abordado o tema nomes significativos, com objetivo de auxiliar e expor as teorias que
sero teis para a concepo de nomes

que refletem o objetivo de variveis e


objetos. No segundo artigo, o tema funes foi abordado, provendo ao desenvolvedor importantes informaes sobre
como definir mtodos, procedimentos e
funes limpos. Alm disso, tambm foi
abordado como o desenvolvedor pode
implementar tais estruturas seguindo
alguns parmetros que permitiro que
suas estruturas reflitam melhor seus
propsitos.

Edio 45 - Engenharia de Software Magazine

49

No terceiro artigo da srie foi tratado o assunto comentrios


em cdigo fonte. O que acontece que alguns desenvolvedores
desconhecem as boas praticas que devem ser seguidas para a
concepo de um comentrio, o que leva a criao desses de
forma descontrolada, fazendo com que ao invs de se obter benefcios, os comentrios agreguem valor negativo ao cdigo.
Quando o assunto foi formatao de cdigo, o quarto artigo
da srie mostrou como essa tarefa pode ser realizada seguindo as recomendaes de Cdigo Limpo. J no quinto artigo
da srie passou-se a se preocupar com estruturas de dados e
objetos. Nesse momento foram abordadas as tcnicas para se
construir estruturas de dados e instanciar objetos que podem
ser considerados limpos.
O sexto artigo exps o tema limites da aplicao, isto , como
manter limpo o cdigo que est nos limites da aplicao, seja
de componentes de terceiros ou sobre a comunicao com um
recurso externo aplicao. Nesse mesmo artigo, outro ponto
muito interessante foi considerado: como manter o cdigo de
teste da aplicao limpo? Alm de abordar a importncia do cdigo de teste, foi mostrado como mant-lo em algum repositrio
sem que esse cdigo perca sua legibilidade. Para isso, tcnicas
de limpeza de cdigo de teste unitrio foram mostradas.
chegado o momento de conhecer o contedo do ltimo artigo
desta srie, que ir tratar da viso macro da aplicao. Primeiramente sero apresentadas tcnicas e teorias fundamentais
para a concepo de classes limpas. Isso envolve conhecer o
tamanho que as classes devem possuir, responsabilidades, como
a relao dela com a aplicao, dentre outras coisas. Na continuao deste artigo ser discutido como implementar sistemas
que podem ser mais facilmente entendidos se analisados em
uma viso macro. Esta seo apresentar formas de se dividir
o sistema em partes que, se analisadas, revelam a organizao
do sistema e de que partes ele constitudo. Finalizando, tem-se
a seo Emergncia que tratar de teorias acerca da concepo
de projetos de cdigo considerados simples.
Muitos desenvolvedores implementam alguns projetos, mas
no sabem classificar se o projeto implementado simples ou
complexo, analisando sob ponto de vista das manutenes
futuras. Sistemas com projeto de cdigo mais simples tendem
a ser mais fceis de manter, enquanto sistemas com estruturas
de cdigo com muita duplicao, por exemplo, tendem a dificultar o processo de manuteno. Todos estes pontos sero
discutidos nas sees deste artigo.

Classes
Esta seo aborda as caractersticas fundamentais para que
uma classe possa ser considerada limpa. Implementar classes
limpas um processo que passa por conceitos importantes que
vo desde a necessidade de se definir nomes que condizem
com o que elas representam at definies do posicionamento
dos atributos na classe relacionados por seus tipos.
Definindo a estrutura de uma classe
Segundo Cdigo Limpo (MARTIN, 2009), uma classe deve ser
organizada de forma que, aps a declarao da classe, venham os

50

atributos, nesta ordem: pblicos, estticos, constantes, privados


e, por ltimo, os atributos privados que so instncias de outras
classes, criados para permitir a associao entre classes.
Cdigo Limpo sugere que no sejam criados mtodos de
acesso, os gets e sets por entender que no so a melhor opo
para acessar atributos de uma classe. Sendo assim, outros
mecanismos devem ser criados para substituir os mtodos de
acesso (ver Nota do DevMan 1).

Nota do DevMan 1
Como definir objetos, estruturas de dados e mecanismos de tratamento de
erros segundo cdigo limpo
O artigo Como definir objetos, estruturas de dados e mecanismos de tratamento de
erros segundo cdigo limpo, foi apresentado na edio de nmero 43 da Engenharia
de Software Magazine. Nele possvel aprender como so implementados mecanismos que substituem os mtodos de acesso.

Quando surgir a necessidade de se testar um mtodo que


privado, deve-se fazer com que a classe de teste herde da classe
que possui o mtodo a ser testado. O mtodo a ser testado deve ter
seu atributo modificado, de privado para protegido. Sendo assim,
o mtodo ainda continuar invisvel fora da classe, mas com a
diferena de poder ser acessado pela classe de testes. Alguns desenvolvedores, ao implementarem casos de teste, para acessarem
um mtodo, alteram seus modificadores de acesso para pblicos, o
que no recomendado. Um exemplo de mudana de modificador
de acesso para pblico foi utilizado no artigo sobre Testes Unitrios
com NUnit (ver Nota do DevMan 2), mas deve-se considerar as
recomendaes de Cdigo Limpo (MARTIN, 2009).

Nota do DevMan 2
Artigo sobre Teste Unitrio com NUnit.
Artigo Teste Unitrio com NUnit: uma abordagem prtica, foi apresentado na edio
de nmero 43 da Engenharia de Software Magazine.

Definindo o tamanho de uma classe


A sugesto que uma classe deva ser o menor possvel, no
sentido da quantidade de responsabilidades que possui.
Classes devem ser bem definidas, com propsito nico. No
se deve criar uma classe que resolva todos os problemas da
aplicao. Um exemplo a criao de uma classe que funciona como um arquivo de cdigo fonte, criada para receber
todos os mtodos que a aplicao deve possuir. Estratgias
semelhantes eram muito utilizadas por desenvolvedores no
paradigma estruturado. No paradigma orientado a objetos,
deve-se ter classes com nomes precisos, isto , que revelem
claramente a inteno da classe. Definido um nome, a classe
deve se limitar a possuir apenas cdigo que seja do mesmo

Engenharia de Software Magazine - Boas prticas para escrita de mtodos, funes e procedimentos Parte 7

ESC RITA DE C DIGOS

contexto que o nome definido para a classe. Isso, na prtica,


quer dizer que uma classe com nome Aluno no poder ter
mtodos referentes a professores. Tais mtodos devem estar
em uma classe com nome Professor. A distribuio correta das
responsabilidades o primeiro passo para se obter uma classe
de tamanho considerado bom.
Um importante conceito e que deve sempre ser lembrado e
aplicado refere-se coeso e ao acoplamento.
Para cada classe desenvolvida em um sistema deve-se cuidar
para que no desempenhe mais funes do que naturalmente
deve desempenhar. interessante que cada classe desempenhe
apenas suas funes e no carregue funcionalidades que deveriam ser atribudas a outros mdulos ou classes do software.
A esse problema d-se o nome de baixa coeso, que indica
que algo deveria ser feito para melhorar o projeto de cdigo
existente. A alta coeso uma meta a ser alcanada em todos
os softwares, pois indica que os mdulos ou classes do sistema
esto desempenhando apenas as suas respectivas funcionalidades. Portanto, conhecer os tipos de coeso existentes se torna
fundamental. Os tipos de coeso conhecidos so:
Coeso funcional: o mais alto nvel de coeso. Neste
ponto o software realiza apenas a funo que de sua
responsabilidade;
Coeso em camadas: encontrada nas camadas do sistema,
onde as camadas mais altas se comunicam com as mais baixas,
e nunca o contrrio;
Coeso comunicacional: onde a comunicao do sistema
ocorre quando vrias partes do cdigo manipulam os mesmos
dados;
Coeso sequencial: ocorre quando h uma sequncia de
operaes, onde uma invoca e passa dados para a outra. A
sada de uma operao a entrada de outra;
Coeso procedural: ocorre quando h uma sequncia de
operaes onde, por exemplo, um mtodo chama outro, mas
no h passagem de dados;
Coeso temporal: est presente em cdigo que executa
em determinadas situaes atpicas. Como exemplo, podese destacar cdigo criado para levantamento de excees e
deteco de erros;
Coeso de utilidade: presente em classes, componentes ou
operaes que contm mais responsabilidades que normalmente
deveriam ter. Como exemplo, pode-se destacar uma classe que
carrega cdigo que deveria estar presente em outra classe.
A criao de classes em um sistema que reflitam a necessidade do negcio do cliente um dos recursos que o desenvolvedor
pode utilizar ao projetar um sistema. Quando se escreve uma
classe, possivelmente essa se comunicar com outra classe do
software. A comunicao entre mdulos, classes, mtodos ou
componentes comum em um projeto orientado a objetos mas,
se esta comunicao for complicada demais, ao ponto de que
mudanas em uma classe gerem diversos impactos em outras,
possivelmente o desenvolvedor ter problemas em manter esse
cdigo, pois o acoplamento entre essas classes, ou seja, a ligao
entre elas, pode comprometer o sucesso das mudanas.

O alto acoplamento refere-se intensidade da comunicao


entre classes, mtodos ou componentes do sistema. Alto acoplamento pode indicar que a comunicao pode ser um pouco
complexa, e que possivelmente o desenvolvedor ter que ter
cuidados extras na hora de manter o cdigo, levando em conta o
fato de que as alteraes feitas em um determinado ponto podem
impactar outros pontos do software.
inevitvel que haja algum tipo de acoplamento em um software, mas o desenvolvedor deve estar ciente da importncia
de manter o acoplamento o mais baixo que puder, pois assim os
impactos ocasionados pelas mudanas no software podero ser
minimizados.
Alguns tipos de acoplamento foram definidos, para que o
desenvolvedor possa identificar quais tipos esto presentes no
software, e assim possa minimizar o acoplamento (PRESSMAN,
2006). Entre eles tem-se:
Acoplamento por contedo: encontrado em cdigo que
modifica os dados de outra parte do cdigo. Como exemplo,
tem-se um componente que modifica os dados internos de outro
componente em tempo de execuo;
Acoplamento comum: encontra-se em cdigo onde h variveis
globais sendo usadas por todo o sistema. Nesse caso, a modificao dessa varivel pode afetar vrias partes da aplicao;
Acoplamento por controle: esse tipo de acoplamento pode ser
encontrado em mtodos. Quando o corpo de um mtodo modificado, pode haver a necessidade de alterar o corpo de outro mtodo
que tem a responsabilidade de trocar informaes com ele;
Acoplamento carimbado: nesse caso, quando h uma dependncia entre classes, do tipo que as informaes necessrias a
uma classe dependem das informaes vindas de outra classe, o
sistema torna-se mais difcil manter dado que alteraes na classe
fornecedora de dados dever ser planejada para que no afete a
classe que ir receber os dados.
Acoplamento por dados: encontrado em cdigo que manipula
vrios parmetros de uma s vez. Nesse caso, a complexidade
do cdigo aumenta consideravelmente devido manipulao de
grandes quantidades de dados;
Acoplamento por chamada de rotinas: tipo de acoplamento
normalmente encontrado em mtodos que chamam outros
mtodos;
Acoplamento por uso de tipo: um tipo de dados definido por uma classe pode ser usado por outras, mas se esse
modificar-se, as classes que o usam possivelmente devero
ser modificadas;
Acoplamento por incluso: encontrado em cdigo que faz
importao de contedo de outras partes do sistema;
Acoplamento externo: tipo de acoplamento encontrado quando
o sistema estabelece um tipo de comunicao com o ambiente
externo aplicao, como comunicao com sistema operacional,
banco de dados, entre outros.
responsabilidade do desenvolvedor manter a qualidade do
cdigo que cria, e esta tarefa necessita do entendimento sobre
as teorias de coeso e acoplamento. Para reduzir o tamanho de
uma classe, o ideal dividi-la em outras classes, por quantidade

Edio 45 - Engenharia de Software Magazine

51

de responsabilidades, e ento mover da classe grande o cdigo


que dever pertencer s classes recm-criadas.
fato que a maioria dos sistemas tende a ter seu cdigo modificado e aumentado ao longo do ciclo de vida da aplicao. Isso,
na prtica, quer dizer que as classes sero afetadas, e manter uma
nica responsabilidade por classe uma tarefa contnua.

Sistemas
As sees anteriores visam manter limpas partes de um
sistema, mas ter o sistema limpo como um todo, numa viso
geral, tambm importante, pois as partes devem coexistir em
harmonia no sistema. Esta seo visa abordar as teorias que
possibilitaro que um sistema como um todo se torne limpo, ao
passo que suas divises estiverem claras, como por exemplo,
a conexo com o banco no deve estar misturada ao cdigo
responsvel por instanciar os objetos das classes de negcio,
nem o cdigo de tratamento de erros misturado ao cdigo de
persistncia de objetos. Um sistema considerado limpo pode
ser visto como um todo, mas tendo suas partes bem definidas
e visveis em suas divises.
Viso geral sobre a estrutura de um sistema
Nesse ponto do aperfeioamento do cdigo de um sistema,
alm das boas prticas descritas para se obter cdigo limpo,
deve-se se preocupar tambm com uma viso do sistema que
vai alm da qualidade das linhas de cdigo escritas. Deve-se se
preocupar tambm com a forma com que o sistema est organizado e como suas partes esto dispostas a fim de se relacionar.
Nesse sentido, a preocupao deve girar em torno da separao
de trechos de cdigo de construo de objetos, trechos de cdigo
responsvel pelas regras de negcio, trechos de cdigo relativo
a configuraes do prprio sistema, entre outros pontos.
Uma analogia que se pode fazer nesse momento referente a
uma linha de produo de uma fbrica. Nela pode-se observar
claramente que no incio da produo tem-se a matria prima,
como madeira por exemplo. Nesse ponto existe o setor de corte,
responsvel por criar as partes necessrias para a concepo
de um produto. Essas partes criadas vo para outro setor que
o responsvel pela pintura das peas. Ao sair do setor de
pintura, as peas vo para o setor de embalagem, que pega um
conjunto de peas especficas e as embala, constituindo um
produto. O setor de carregamento responsvel por despachar
estes produtos para seus respectivos destinos. Neste cenrio
fcil perceber que a fbrica o todo, assim como o software e
os setores so partes do sistema, como mdulos ou conjunto
de classes de objetivos especficos. Cada setor da indstria
responsvel por uma parte da gerao do produto desejado,
assim como no software tambm deve ocorrer. Para que essa
diviso clara e objetiva, assim como na indstria, tambm
ocorra no software, necessrio seguir alguns princpios.
O ponto de partida usado para iniciar operaes em um software o mtodo main. Atravs dele alguns procedimentos so
invocados e tais procedimentos podem encadear a execuo
de vrios outros procedimentos. interessante que a ordem
de chamada dos procedimentos pelo mtodo main seja feita de

52

uma forma que apresente uma sequncia de leitura, onde quem


for ler o cdigo posteriormente saiba simplesmente identificar
qual o ponto de partida da inicializao do software bem como
os caminhos por onde ele passa.
Se aps a inicializao do mtodo main houver a necessidade de executar mtodos que so responsveis por construir
algum objeto ou formar algum tipo de informao referente
ao negcio modelado pela aplicao, fundamental que esse
cdigo no esteja misturado a cdigos que so responsveis
por prover algum tipo de servio para o software, como abrir
conexes com bancos de dados ou testar se algum dispositivo
est conectado ao computador, por exemplo.
Prevendo o futuro do software
Alguns desenvolvedores insistem em criar grandes arquiteturas para um sistema que pequeno, mas o fazem com o
intuito de preparar o projeto para futuras funcionalidades que
ele acredita que podem um dia vir fazer parte do sistema, mas
que no se tem certeza ainda.
Esse um problema que atinge alguns projetos de software
e que no devia acontecer. Quando se implementa algo pensando em funcionalidades que no se tem certeza que um
dia existiro, se gasta muito tempo, e com isso dinheiro, aumentando o custo do projeto. Em contrapartida, se uma nova
funcionalidade ser em breve inserida e se faz um projeto que,
para acomodar a nova funcionalidade, dever sofrer grandes
modificaes, tambm se corre o risco de ter um aumento no
custo do projeto. Mas ento o que fazer? Implementar pensando no futuro ou desconsiderar o que est por vir. A resposta
est no meio termo.
importante que o desenvolvedor escreva cdigo sempre visando a qualidade da escrita, seguindo os princpios de Cdigo
Limpo. Nesse sentido, ele dever trabalhar com as informaes
que tem em mos e criar a arquitetura com base no que se tem
de concreto no que diz respeito especificao dos requisitos.
Uma vez implementada a arquitetura do sistema visando sempre aplicar as boas prticas de cdigo limpo, quando houver a
necessidade de implementar novas funcionalidades o sistema
tender a ser mais fcil de modificar, visto que o cdigo estar
mais legvel.
Viso macro do sistema
importante que quem estiver analisando um software implementado por outro desenvolvedor consiga facilmente ter uma viso
macro sobre como a diviso do sistema (lembrando-se da analogia
com a indstria, onde as sees so facilmente identificadas, cada
uma com propsito especfico). Nesse sentido, deve-se fornecer
uma viso macro sobre as classes que implementam persistncia
de objetos (mapeamento objeto-relacional), o mecanismo que trata
os erros da aplicao, o mecanismo que abre as conexes com o
banco de dados, as classes que instanciam objetos para o negcio
modelado na aplicao, os mecanismos que configuram os formulrios da aplicao como, por exemplo, determinar quando um
boto deve estar habilitado ou no, cores de algum componente
devem ser alteradas, entre outras coisas. Fornecer essa viso faz

Engenharia de Software Magazine - Boas prticas para escrita de mtodos, funes e procedimentos Parte 7

ESC RITA DE C DIGOS

Esta seo visa abordar teorias e regras que podem ser utilizadas no processo de tornar o cdigo fonte existente limpo ou
conceber novos projetos cujo cdigo fonte possa ser considerado
limpo. As teorias e regras desta seo mostraro informaes
de como o desenvolvedor poder conciliar as teorias abordadas
nas sees anteriores com o objetivo de facilitar a concepo
de novos projetos. Considerando as regras bsicas desta seo,
pode-se obter um software limpo desde a sua criao.

At este ponto, a srie sobre cdigo limpo preocupou-se em


tornar limpas pequenas partes da aplicao, como nomes,
mtodos, objetos, estruturas de dados, limites e os mtodos de
teste. Este artigo trouxe a mesma forma de se limpar cdigos,
que vinha sendo utilizada nos artigos anteriores, mas desta
vez em partes maiores do sistema, com uma viso macro. Com
a teoria e prtica sobre como limpar cdigo abordadas em outros artigos, o desenvolvedor se torna capaz de manter limpo
pequenos trechos de cdigo, e com o conhecimento adquirido
neste artigo, o desenvolvedor teve contato com uma forma de
considerar em conjunto todo conhecimento sobre limpeza de
cdigo e utiliz-lo numa viso maior.
Esta srie de artigos sobre cdigo limpo finaliza aqui. Quem
leu todos os artigos percebeu que h uma forma de se escrever
cdigo com qualidade, evitando problemas futuros. Assim,
apresentamos uma base de referncia para melhorar o projeto
de cdigo de suas aplicaes e cada vez mais levar produtos
de qualidade ao mercado. Provavelmente seu cliente no ver
a qualidade do seu cdigo, mas certamente ela trar outros
tipos de benefcios para ele.

D seu feedback sobre esta edio!


A Engenharia de Software Magazine tem que ser feita ao seu gosto.
Para isso, precisamos saber o que voc, leitor, acha da revista!
D seu voto sobre este artigo, atravs do link:

Feedback
eu

www.devmedia.com.br/esmag/feedback

Edio 45 - Engenharia de Software Magazine

53

sobre e
s

Caractersticas de um projeto simples


Cdigo Limpo (MARTIN, 2009) se baseia nas teorias de outros
autores para afirmar que um projeto considerado simples quando baseado em quatro pilares, que so: est totalmente testado,
no possui duplicao de cdigo, reflete o objetivo do programador ao escrever aquele cdigo, e possui um nmero mnimo
quanto possvel de classes e mtodos, seguindo essa ordem.
A primeira dessas caractersticas leva a crer que um software
que no foi testado devidamente no pode ser considerado
simples, visto que se no se testou, no se sabe bem os efeitos da
execuo daquele cdigo em todos os seus pontos e caminhos.
Implementar uma soluo j pensando que o mtodo dever ser
passvel de teste uma boa prtica. Outra abordagem sugere
at que o teste seja escrito antes do mtodo a ser testado.
A segunda caracterstica leva a uma reflexo. O que pode ser
considerado cdigo duplicado? Cdigo duplicado somente o
cdigo copiado e colado em outro ponto do software? Como
identificar um cdigo duplicado? Como eliminar um cdigo
duplicado sem afetar as outras partes do sistema? A resposta
para todas estas perguntas est nos demais artigos que foram
escritos sobre cdigo limpo e nos artigos escritos sobre refatorao de cdigo. O objetivo aqui frisar a importncia de se ter
um cdigo sem duplicaes: torn-lo simples. Caso o projeto
tenha cdigo duplicado, ele no pode ser considerado simples,
visto que uma alterao em um ponto poder causar efeitos colaterais em outro ponto duplicado, ou at mesmo a manuteno

Concluso

D
s

Emergncia

programada ser efetuada em um trecho de cdigo que no o


que se deve manter, dada a semelhana que possui.
A terceira caracterstica gira em torno de outro ponto conhecido pela maioria dos desenvolvedores, mas que s vezes no
colocado em prtica, a questo da escrita do cdigo e sua
anlise posterior. Quando se est escrevendo um cdigo, se
possui conhecimento sobre o que se quer expressar em forma
de cdigo, mas nem sempre quem est analisando o cdigo
pela primeira vez saber distinguir do que se trata. Isso ocorre
porque, com o tempo, tende-se a esquecer do que se trata o
trecho de cdigo implementado. Portanto, escrev-lo o mais
legvel possvel, em sequncia de leitura, o indicado.
O ltimo ponto, porm importante, deve ser analisado atentamente. Ter um sistema com muitas classes no sinal de que
o projeto est simples. Pode ser que o desenvolvedor quebrou
demais o problema e acabou dividindo responsabilidades
que deveriam estar em uma nica classe. Porm, existe outro
cenrio onde existem poucas classes, mas as que existem so
grandes e complexas de se entender e manter. Isso ocorre porque alguns desenvolvedores atribuem mais responsabilidades
a uma classe do que deveria. Sendo assim, um sistema s poder ser considerado limpo se as classes e mtodos tiverem o
tamanho necessrio. Nem maiores nem menores do que devem
ser. Seguir estas recomendaes garantir a concepo de um
projeto considerado simples.

edio
ta

com que o sistema na viso macro seja limpo. No adianta somente


se preocupar com a qualidade do cdigo implementado, isto ,
implementar todas as teorias descritas nos artigos passados desta
srie, se a viso macro do sistema ainda estiver confusa.
Um ponto importante ao se limpar o cdigo para se ter uma
viso macro do sistema bem definida est no quesito reaproveitamento de cdigo. Quando se tem uma diviso dos mecanismos
que compem uma aplicao, como os descritos anteriormente,
pode-se ter um reaproveitamento de partes do sistema de modo
mais simples. Pode-se, por exemplo, usar o mesmo mecanismo
de conexo ao banco de dados em diversas aplicaes que se est
desenvolvendo. Isso reduziria o custo de ter que implementar
o mesmo mecanismo todas as vezes que um novo software for
concebido. Outro recurso importante que pode ser usado para
contribuir na formao da viso macro a utilizao de padres
de projeto, que permitem uma visualizao rpida do que se
trata um trecho de cdigo caso a pessoa que o esteja analisando
entenda de padres de projeto tambm.

54

Engenharia de Software Magazine - Boas prticas para escrita de mtodos, funes e procedimentos Parte 7