Edição42 2011

magazine
engenharia
de software
Edio 42 - Ano 04
Teste
Testes exploratrios
Teoria e Prtica
Planejamento
Anlise de pontos
de funo na prtica
AGILIDADE NA MEDIDA CERTA

Agilidade
Scrum e MPS.BR na implantao de
um modelo de desenvolvimento
Qualidade de Software - Uma viso geral
http://www.devmedia.com.br/post-22733-Qualidade-de-software.html
Processo
Fatores de influncia na melhoria
de processo de software
Desenvolvimento
Conhea tcnicas para manter seu
cdigo limpo Parte 4
Com quantas
mentes se
revoluciona
o mundo?
6 a 12 de fevereiro de 2012
Anhembi (SP)
Inovao
Cultura Digital
Cincia
Entretenimento Digital
Unimos talento Criamos futuro

www.campus-party.com.br
@CampusPartyBRA
www.facebook.com/campuspartybrasil
Rodrigo Oliveira Spnola

rodrigo.devmedia@gmail.com
Doutorando em Engenharia de Sistemas e Computao (COPPE/UFRJ). Mestre em Engenharia de
Software (COPPE/UFRJ, 2004). Bacharel em Cincias da Computao (UNIFACS, 2001). Colaborador
da Kali Software (www.kalisoftware.com), tendo ministrado cursos na rea de Qualidade de Produtos e Processos de Software, Requisitos e Desenvolvimento Orientado a Objetos. Consultor para
implementao do MPS.BR. Atua como Gerente de Projeto e Analista de Requisitos em projetos de
consultoria na COPPE/UFRJ. Colaborador da Engenharia de Software Magazine.
Marco Antnio Pereira Arajo
Ano 4 - 42 Edio - 2011
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
Colaboradores
Rodrigo Oliveira Spnola
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/esmag
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) 2220-5338
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.
Publicidade
Para informaes sobre veiculao de anncio na revista ou no site entre em
contato com:
publicidade@devmedia.com.br
EDITORIAL
necessidade de aproximar a rea de TI com o negcio torna-se cada vez
inverter a ordem ou colocar tudo na devida ordem na produo de um novo
mais relevante medida que os altos executivos das grandes corpora-
sistema. Os novos produtos de software passaram a possuir verses baseadas no
es mundo a fora compreendem o quanto as solues desenvolvidas
ciclo de mudana do negcio. A cada nova necessidade, um novo produto. Este
por este departamento, at ento, restritamente tcnico, poderiam alavancar

seus negcios.
o novo ciclo da Engenharia de Software.

Neste contexto, esta edio da Engenharia de Software Magazine destaca
Muitos fatores foram responsveis por estimular os gestores das mais diver-
como tema de capa Agilidade na Medida Certa com FDD. Para isto, trazemos um
sas corporaes a procurarem racionalizar seu modelo de negcio com base no
artigo em que sero apresentadas a estrutura e as foras da metodologia gil
uso das solues oriundas da TI. Mas, sem dvida, a necessidade de se manter
denominada FDD (Future Driven Development) ou Desenvolvimento Guiado
atual em relao s constantes mudanas nas regras do negcio, originrias de
por Funcionalidades que, apesar de valorizar os processos e a forma de se fazer,
um novo mundo mais integrado e dinmico, o fator mais relevante. Por isso,
tem sua nfase nos valores e princpios do manifesto gil.
a mudana nos requisitos do sistema durante o seu desenvolvimento deve ser
Alm deste artigo, teremos mais seis nesta edio:
encarada com naturalidade. Este um fator de alta relevncia para um projeto
Scrum e MPS.BR na implantao de um modelo de desenvolvimento colaborativo
de Software!
Fatores de influncia na iniciativa de melhoria de processo de software no
Essas mudanas esto associadas reconstruo do modelo de negcio da
Amazonas
empresa, da constante necessidade de inovar e atender a diversos pblicos com
Qualidade de software na viso dos Papas da Qualidade
nveis distintos de exigncia e comportamento. E como no poderia ser diferen-
Testes exploratrios: Teoria e Prtica
te, o ciclo de vida de um modelo de negcio teve seu tempo reduzido, o que faz
Anlise de pontos de funo na prtica
as organizaes atuais a implantarem ciclos de melhoria contnua que impul-
Boas prticas para escrita de mtodos, funes e procedimentos Parte 4
sionam, de forma constante, a empresa a buscar o novo. Estes fatores servem

como motivao para uma nova linha de produo de software, que acabou por
Desejamos uma tima leitura!
NDICE
Caro Leitor,
Agilidade
06 - FDD: agilidade na medida certa
Marcelo Liberato Souza
Para esta edio, temos um conjunto de 4 vdeo aulas. Estas vdeo aulas
esto disponveis para download no Portal da Engenharia de Software Magazine e certamente traro uma significativa contribuio para seu aprendizado. A lista de aulas publicadas pode ser vista abaixo:
13 - Scrum e MPS.BR: Um caso prtico do uso em conjunto destas abordagens

Andr Luiz Banki
Engenharia
22 - Fatores que influenciam a melhoria de processos
Davi Viana dos Santos e Tayana Conte
Tipo: Processo
Ttulo: Curso Scrum Product Owner Partes 17 a 20
Autor: Rodrigo Oliveira Spnola
Mini-Resumo: Esta uma srie de aulas de um treinamento voltado exclusivamente para Product Owners. O Product Owner um papel prescrito
pelo mtodo gil SCRUM responsvel pelo sucesso ou fracasso do desenvolvimento de um produto. Este um papel complexo de ser exercido no
dia-a-dia e, este curso, distribudo em uma sequncia de vdeo-aulas, tem
como objetivo tornar mais fcil a transio para aqueles que pretendem
ou necessitam trabalhar como Product Owner.
artigo
28 - Testes exploratrios: Teoria e Prtica

Carlos de Sousa, Luana de Menezes, Roberta Bezerra,. Rodrigo Lopes e A. Csar C. Frana
Planejamento
32 - Anlise de pontos de funo na prtica
Andrey Abreu
Desenvolvimento
39 - Boas prticas para escrita de mtodos, funes e procedimentos Parte 4
Jacimar Fernandes Tavares e Marco Antnio Pereira Arajo
Brinde na web desta edio

1 artigo sobre Qualidade de Software: uma viso geral
Para visualizar acesse o link:
http://www.devmedia.com.br/post-22733-Qualidade-de-software-uma-visao-geral.html
Modstia parte, sua

melhor opo para
se destacar no mercado!
A Escola Superior da Tecnologia da
Informao oferece as melhores
opes em cursos, formaes,
graduaes e ps-graduaes para
profissionais de desenvolvimento
e programao.
PS- GRADUAO
Engenharia de Software:
Desenvolvimento Java
Engenharia de Software:
Desenvolvimento .NET
GRADUAO
Engenharia de Computao
Anlise e Desenv. de Sistemas
So programas voltados para a

formao de profissionais de elite,
com aulas 100% prticas, corpo
docente atuante no mercado,
acesso mais atualizada biblioteca
de TI do Rio, laboratrios equipados
com tecnologia de ponta, salas de
estudo e exames.
FORMAES
Desenvolvedor Java
Desenv. Java: Sist. Distribudos
Gestor de TI
Desenvolvedor Web .NET 2008
MCITP Server Administrator
SQL Server 2008
r/esti
Acesse nosso site e conhea todos os nossos programas: www.infnet.edu.br/esti
TURMAS
NO RIO DE
JANEIRO
www.infnet.edu.br - cursos@infnet.edu.br - Central de Atendimento: (21) 2122-8800
EDUCAO SUPERIOR ORIENTADA AO MERCADO
Edio 05 - Engenharia de Software Magazine
Agilidade
Nesta seo voc encontra artigos voltados para as prticas e mtodos geis.
FDD: agilidade na medida certa

A metodologia da transio entre os paradgimas tradicional e gil
De que se trata o artigo?

O artigo apresenta a estrutura e a fora da aplicao da metodologia gil FDD (Desenvolvimento
Guiado por Funcionalidades) em ambientes que
exigem priorizao no desenvolvimento de requisitos de Softwares e agilidade em suportar a
mudana nos requisitos funcionais do produto em
desenvolvimento.
A
Marcelo Liberato Souza,
marcelo.liberato@gmail.com
Trabalha com gerenciamentos de projetos

de TI, especialmente aqueles relacionados
Engenharia de Software, h 12 anos.
Gestor do blog marceloliberato.wordpress.
com, atualmente gerente de projetos da
Agncia de Desenvolvimento do DF, TERRACAP. Bacharel em Anlise de Sistemas de
Informao, especialista em Gerenciamento de Projetos pela FGV e em Planejamento
e Gesto Empresarial pela UCB. Certificado
PMP, j desenvolveu projetos para o Banco
do Brasil, Gerdau, ANATEL entre outros rgos do governo brasileiro.
necessidade de aproximar a
rea de TI (Tecnologia da Informao) com o negcio torna-se
cada vez mais relevante medida que os
altos executivos das grandes corporaes
mundo a fora compreendem o quanto as
solues desenvolvidas por este departamento, at ento, restritamente tcnico,
poderiam alavancar seus negcios.
Muitos fatores foram responsveis por
estimular os gestores das mais diversas
corporaes a procurarem racionalizar
seu modelo de negcio com base no uso
das solues oriundas da TI. Mas, sem
dvida, a necessidade de se manter atual
em relao s constantes mudanas nas
regras do negcio, originrias de um
novo mundo mais integrado e dinmico, o fator mais relevante. Por isso, a
Engenharia de Software Magazine - FDD: agilidade na medida certa
Em que situao o tema til?

A metodologia FDD til em organizaes que
necessitam desenvolver projetos de Software
complexos em curto espao de tempo, de forma a
suportar as necessidades mais prioritrias da organizao. A metodologia tambm se apresenta
como opo para aquelas empresas que desejam
migrar seus processos de desenvolvimento tradicionais para os considerados geis.
Resumo:
Este artigo demonstra a importncia do manifesto
gil para as organizaes atuais e descreve como a
metodologia gil denominada Desenvolvimento
Guiado por Funcionalidades (FDD) pode ser adequada s empresas que desenvolvem projetos
complexos e que tem a necessidade de responderem rapidamente s novas demandas negociais.
Agilidade
mudana nos requisitos do sistema durante o seu desenvolvimento deve ser encarada com naturalidade. Este um fator
de alta relevncia para um projeto de Software!
Neste contexto, a grande revoluo provocada pela modernizao dos sistemas de comunicao, que passaram a integrar
diversas culturas do mundo, acabou por criar novas necessidades globais. As solues de TI, principalmente os softwares,
no eram mais um produto de prateleira que possua verses a
cada ciclo tecnolgico ou a cada iniciativa do fabricante. Os fatores externos, provenientes dos novos mercados em expanso,
dos concorrentes cada vez mais agressivos e do consumidor
mais seletivo, despertaram para a necessidade das organizaes de se adequarem e anteciparem rapidamente s mudanas
exigidas por um mundo globalizado e integrado.
Essas mudanas esto associadas reconstruo do modelo
de negcio da empresa, da constante necessidade de inovar e
atender a diversos pblicos com nveis distintos de exigncia
e comportamento. E como no poderia ser diferente, o ciclo de
vida de um modelo de negcio teve seu tempo reduzido, o que
faz as organizaes atuais a implantarem ciclos de melhoria
contnua que impulsionam, de forma constante, a empresa a
buscar o novo. Estes fatores servem como motivao para uma
nova linha de produo de software, que acabou por inverter
a ordem ou colocar tudo na devida ordem na produo de
um novo sistema. Os novos produtos de software passaram a
possuir verses baseadas no ciclo de mudana do negcio. A
cada nova necessidade, um novo produto. Este o novo ciclo
da Engenharia de Software.
Como consequncia disso, a cultura da mudana passou a
estar cada vez mais enraizada no dia-a-dia das organizaes
e a TI deixou de ser um mero setor de suporte para fazer
parte do negcio. Este o grande ponto de transformao
para desenvolvedores, engenheiros, analistas de software e
gerentes de projetos de TI. Para estes profissionais envolvidos
na concepo, no planejamento e construo de novos projetos, passa a ser evidente que o usurio e o cliente digam suas
expectativas e necessidades e, tambm, participem de todo
o processo de Engenharia de Software. Mas, apesar disso,
muitos profissionais ligados rea de TI ainda resistem em
compreender esta nova ordem.
Com este cenrio, o modelo em cascata muitas vezes injustamente criticado passou a no ser mais adequado, j que a sua
estrutura metodolgica no tolera a necessidade de produzir,
utilizar e suportar novos requisitos ao mesmo tempo em que
se constri. O cliente at ajuda a construir um novo software,
se em contra partida ele conseguir utilizar, em um pequeno
espao de tempo, alguma funcionalidade produzida. Esta
funcionalidade no significa ser o produto completo e perfeito,
mas deve atender as necessidades mais crticas da organizao.
E, assim, surgem as metodologias geis baseadas nos valores
e princpios do manifesto gil de 2001.
Os valores do manifesto gil comprovam o que foi dito:
Indivduos e iteraes mais que processo e ferramentas;
Software em funcionamento mais que documentao
abrangente;
Colaborao com o cliente mais que negociao de

contratos;
Responder a mudanas mais que seguir um plano.
Neste sentido, ao longo deste texto sero apresentadas a
estrutura e as foras da metodologia gil denominada FDD
(Future Driven Development) ou Desenvolvimento Guiado por
Funcionalidades que, apesar de valorizar os processos e a
forma de se fazer, tem sua nfase nos valores e princpios do
manifesto gil.
A origem do FDD
O site featuredrivendevelopment.com publicou, em um de
seus artigos, que o FDD surgiu antes do manifesto gil ser
publicado no ano de 2001. Devido a isto e a outros pontos
tcnicos da metodologia, que sero elucidados adiante, muitos
renomados autores acreditam que o FDD no pode ser enquadrado como uma metodologia gil.
Quanto data de criao do FDD, ela se torna relevante
apenas para efeitos de comparao com outras metodologias
da famlia gil, como eXtreme Programming (XP), SCRUM,
Agile RUP, entre outras. Muitas destas metodologias foram
concebidas com aspectos similares aos pregados pelo FDD.
Mas o que realmente importa verificar se os princpios e os
valores do manifesto gil esto presentes na metodologia e,
sem dvidas, neste aspecto, no h o que questionar.
No entanto, talvez por ser uma metodologia que tenha surgido antes da publicao do manifesto gil que ela possua
mais requisitos formais e mais etapas do que o XP, por exemplo.
Mas isto no desmerece a proposta do FDD, tanto que ela foi
reconhecida como uma metodologia gil e extremamente
valiosa quando a organizao no est madura para receber
metodologias como XP e Scrum, consideradas mais radicais.
O mrito por ser a mais antiga, no universo das metodologias geis, est no fato do FDD possuir a caracterstica de
combinar o melhor das metodologias tradicionais e das mais
atuais. No ser difcil encontrar experincias de fracassos em
organizaes que romperam repentinamente com as metodologias tradicionais para adotar modelos mais radicais. Certo
que no h simplicidade de utilizao em nenhuma metodologia, ainda mais, aquelas que propem o rompimento com
paradigmas j consolidados, mesmo que j ultrapassadas do
ponto de vista negocial. O FDD pode ser uma excelente escolha
para aquelas organizaes que buscam essa transio.
Os criadores do FDD so Jeff de Luca e Peter Coad, que
tiveram o reconhecimento da metodologia em 1997 graas ao
projeto que eles conduziram para o United Overseas Bank.
Assim, surgia uma metodologia, que sem muito alarde e no
to propagada como as coirms, se consolidaria como uma boa
e simples metodologia de Engenharia de Software.
Apresentando o FDD
O FDD uma metodologia que serve tanto para o gerenciamento de projetos quanto para a Engenharia de Software.
Isto a torna mais complexa quando comparada com outras
metodologias geis. Por exemplo, o RUP (Rational Unified Process) da IBM, uma metodologia considerada tradicional, trata o
gerenciamento de projetos como uma disciplina dentro do seu
framework, j que o seu foco est na Engenharia de Software
em si. J o SCRUM, tem no papel do Scrum Master, uma figura
parecida com a de um Gerente de Projetos formal, mas que
tem seu foco na facilitao dos trabalhos por parte da equipe
tcnica. O foco dessa metodologia est na auto-organizao da
equipe e, para isso, so necessrios analistas seniores.
As trs metodologias citadas (RUP, SCRUM e FDD) tm
caractersticas fundamentais para serem consideradas geis:
so iterativas e incrementais. No entanto, o RUP no pertence
famlia gil, por ter seu foco em documentao abrangente,
processos e ferramentas. Isto contrrio ao que diz os valores
citados acima.
Como apresentado anteriormente, muito se discutia se o
FDD deveria ser gil, porque alm dos motivos cronolgicos
j apresentados, ele oferece processos e fases bem definidas
assim como o RUP e tambm possui caractersticas de uma
metodologia de gerenciamento de projetos. Boehm, citado por
Peter Schuh (2005), diz que esta combinao de gerenciamento
de projetos (com um planejamento inicial para o projeto) com
a Engenharia de Software leva o FDD a no ser uma metodologia gil. Entretanto, a origem do FDD no a condenou a
uma metodologia tradicional. De acordo com a publicao do
site www.heptagon.com.br/fdd, o lema do FDD : resultados
frequentes, tangveis e funcionais.
Peter Schuh (2005) apresenta o FDD como altamente incremental, alm de destacar que a metodologia executa, na
mesma interao, atividades de baixo nvel e design, que complementam a funcionalidade identificada nos estgios iniciais
do processo e, tambm, possui a capacidade de envolver seus
clientes por meio de todo o ciclo de vida do projeto. Mais do
que isso, ela est ajustada para reconhecer e responder a mudanas nos requisitos do sistema. O fato de prover um plano
inicial para o projeto e um design, igualmente inicial, para as
features, traz o benefcio de alinhar clientes e programadores,
que desenvolvem partes especficas do cdigo. Isto positivo
e gil. No restam dvidas disso.
Muitos tm o sentimento que qualquer metodologia gil
avessa documentao. Isto no verdade, mito! Um dos
valores do manifesto diz que se privilegia o produto ao invs
da documentao, como o RUP faz. A documentao de um
projeto essencial para qualquer projeto. O que no pode acontecer gastar 60% do tempo com a produo de documentos,
sem que o cliente tenha alguma funcionalidade que j atenda
sua necessidade de negcio mais emergencial. Muitos gestores
questionam os custos de TI exatamente por ela no entregar
o que eles querem com qualidade e no momento oportuno. O
manifesto gil prega o alinhamento das prioridades de negcio
com a TI. E quanto documentao, no problema ser gil e
prover um plano inicial de gerenciamento de projetos.
O ponto forte da metodologia FDD est na capacidade de
realizar features. Para esta metodologia, uma pequena feature
possui um alto valor para o cliente. O exemplo de uma feature
est em um caso de uso com a funo de calcular a mdia de

salrio dos gestores, ou de realizar um relatrio integrado de
vendas e assim por diante. Veja que no estranha a meno
do termo caso de uso para exemplificar uma feature, j que
a ideia similar. Essa descrio do requisito que o FDD chama
de feature so os casos de uso no RUP e as estrias utilizadas
no XP. O site www.agilemodeling.com/essays/fdd.htm destaca
que uma lista de features inicialmente indicada para que seja
elaborado o planejamento do projeto com estimativas de esforo
para sua execuo. Basicamente, esta a proposta do FDD.
A fora do FDD
Com o FDD devidamente contextualizado, pode-se aprofundar no estudo da metodologia.
De acordo com Schuh (2005), o FDD apresenta oito melhores
prticas para um projeto de Software que justificam o seu
sucesso:
Modelagem do Domnio de Objetos descrever um mapa
geral do software que ser desenvolvido. Geralmente utiliza-se
o relacionamento entre o diagrama de classes e o de sequncia,
que demonstra o comportamento do sistema;
Desenvolvimento por Feature desenvolver o sistema de
forma iterativa e incremental e por pequenos blocos de funcionalidade que forneam uma nova e valorada experincia
para o usurio;
Propriedade das Classes esta prtica muito utilizada
na tcnica de encapsulamento quando se desenvolve orientado-objetos. Cada classe assinada por um programador
especfico;
Features Teams ao contrrio do XP, o FDD no prega a
propriedade coletiva sobre o cdigo desenvolvido. Por desenvolver as funcionalidades individualmente, o programador
considerado o proprietrio da funcionalidade implementada. Com isso, os vrios programadores da equipe formam o
conceito de Feature Team e so os responsveis por coordenar
os trabalhos de design, integrao e implementao de cada
nova funcionalidade;
Inspees foco em identificar defeitos e no em intimidar
o programador que desenvolve determinada feature. Busca
prover a melhoria na transferncia do conhecimento e maior
conformidade com os padres de cdigo e design;
Agenda regular de Construo (Build) as equipes codificaro as features baseadas em intervalos regulares de tempo.
Assim, pode-se completar o sistema e identificar erros de integrao o quanto antes e tambm prover uma verso atualizada
do sistema sempre que um novo release esteja disponvel;
Gerenciamento da Configurao os cdigos necessitam
ser armazenados e versionados em um determinado nvel que
rena todas as demandas do time. Os trabalhos de anlise,
design e testes tambm precisam ser versionados;
Relatrios/Visibilidade dos Resultados o status do projeto
deve ser regularmente atualizado e de fcil entendimento para
que possa guiar o projeto. O cliente e os stakeholders devem
estar cientes do andamento do projeto, para que possam planejar e agir da forma acordada.
Agilidade
Na Figura 1, elaborada por Peter Schuh (2005), podem ser

retratados os cinco principais processos do FD.
Figura 1. Processo simplificado do FDD
Para Anderson (2004), basicamente os cinco processos do

FDD so caracterizados da seguinte forma:
Desenvolver um Modelo Abrangente (DMA) o FDD promove a modelagem de parte dos requisitos descobertos durante o
processo de levantamento, no qual inclui o cliente e a equipe
do projeto. Basicamente o Diagrama de Classes oriundo da
UML (Unified Modeling Language) utilizado. Vale ressaltar
que no apenas os requisitos funcionais so modelados, mas
tambm os requisitos no funcionais e a proposta do modelo
de arquitetura recomendada para o sistema;
Listar Features (CLF) com o modelo geral criado e os artefatos UML em mos ou um escopo bsico do projeto definido
e alinhado com os requisitos do negcio parte-se para a
definio da lista refinada de features a ser desenvolvida. Esta
pequena lista dever ser tratada como o escopo inicial para
o release. O desenvolvimento dever ser orientado com base
nesta lista de features;
Planejar por Feature (PPF) Este processo envolve planejar
o projeto por grupos de features definidas na lista de features
priorizadas pelo cliente e funcionalmente relacionadas. Com
isso, o cronograma de entrega estabelecido;
Design por Feature (DPF) Envolve a produo de um design
para um conjunto de features. O domnio do problema conhecido como Atividades do Negcio. Outros diagramas UML so
desenvolvidos com o objetivo de detalhar as funcionalidades,
e isto inclui: o diagrama de classes e o diagrama de sequncia
para cada feature definida na atividade;
Construir por Feature (CPF) Isto envolve desenvolver
(codificar) um pequeno pacote funcional conforme modelado
no passo anterior. Este pequeno pacote de funcionalidades
codificadas passam por testes unitrios, testes de integrao,
testes de sistema e reviso do cdigo. Geralmente, esta etapa
dura at duas semanas.
Como se pode perceber, a proposta do FDD bastante simples
quando comparada com outras metodologias tradicionais.
Tambm fica evidente a preocupao dos seus autores para

que haja um entendimento prvio das necessidades do cliente
com a equipe do projeto e um planejamento que indique como
sero desenvolvidas as principais features do sistema.
1. Para Schuh (2005), cada processo construdo conforme
a abordagem EVTX, que pode ser traduzido como EntradaTarefa-Verificao-Sada (veja Nota do DevMan 1). Isto
leva as equipes do projeto a terem atividades especficas
que devem ser realizadas antes de entrar e sair de cada
processo. Este autor ainda d duas preciosas informaes
quanto ao processo do FDD, que a torna diferente das demais
metodologias geis:
2. A iterao representada por trs quadrantes. Isto indica
que mltiplas features so trabalhadas no FDD simultaneamente por diferentes equipes e que nem todos os seus integrantes estaro no mesmo ritmo da iterao (feature team).
Cada equipe alocada para o desenvolvimento de uma feature
inicia e completa uma iterao baseado no plano criado pelo
desenvolvedor chefe;
Nota do DevMan 1
EVTX: EVTX (Entry criteria, Task, Verification, and eXit criteria): Por definio, o
processo contm uma sequncia de passos que devem ser orientados a critrios
de entrada e sada. Esses critrios indicam quando a atividade dentro do processo
comea e termina. Os critrios de entrada, para alguma fase/etapa do processo,
especificam quais as condies de entrada devero ser satisfeitas para que o trabalho de uma atividade seja iniciado. Por sua vez, os critrios de sada especificam
as condies que o trabalho produzido de uma fase/etapa dever satisfazer para
terminar as atividades da fase. Estes critrios especificam restries de quando iniciar ou parar uma atividade e devem ser suficientemente claros para que ela possa
ser verificada e, desta forma, possibilitar a identificao de erros antes de iniciar a
prxima atividade.
O fluxo do FDD pode ser flexibilizado. Necessariamente,

na primeira vez que o processo executado, ele dever
seguir os cinco processos apontados na Figura 1. Contudo,
para cada release aprovada, um fluxo alternativo, representado pela seta pontilhada, pode ser executado. Isto facilita
e aperfeioa o processo do FDD, alm de permitir que um
time do projeto desenvolva pequenos releases em curtas
iteraes.
Com esta breve explicao dos processos e das melhores
prticas do FDD, pode-se verificar o poder desta metodologia. Resumidamente, o site www.heptagon.com.br/fdd-oque,
demonstra que o FDD tem suas foras baseadas em:
Resultados teis para o cliente a cada duas semanas ou
menos;
Blocos bem pequenos de funcionalidade valorizada pelo
cliente, chamados Features;
Pla neja mento deta l hado e g u ia pa ra med io de
desempenho;
Rastreabilidade e relatrios com incrvel preciso, j que se

planeja por iteraes;
Monitoramento detalhado dentro do projeto, com resumos de
alto nvel para clientes e gerentes, tudo em termos de negcio.
O Gerenciamento do Projeto no FDD

As boas prticas do guia PMBOK do PMI (Project Management Institute) traz ao gerente e equipe de projeto uma
forte percepo de planejamento e controle sobre o projeto. As
prticas divulgadas por esse instituto apresentam processos
e atividades que podem ser desempenhadas no mbito da
gerncia do projeto. Estas boas prticas so completamente
genricas, ou seja, no so destinadas a uma indstria especfica, como a de Engenharia de Software. Ao contrrio, o FDD
uma metodologia de Engenharia de Software que carrega no
seu escopo a gerncia de projetos voltada para este segmento.
Portanto, no h o que comparar com o guia PMBOK. Neste
caso, caso seja realmente necessrio para o gerente do projeto
e o cliente, vale ser agregado metodologia as boas prticas
pregadas por este guia ou outros padres como, por exemplo,
o PRINCE2 (Nota do DevMan 2).
Nota do DevMan 2
PRINCE2: A abordagem PRINCE2 baseada em processos para gerenciamento
de projetos, em que so fornecidos mtodos, facilmente adaptveis e escalveis,
para a gesto de todos os tipos de projetos. A abordagem um padro de fato
para gerenciamento de projetos no Reino Unido e praticada em todo o mundo.
Adaptado de: www.prince2.com/what-is-prince2.asp
Como se pode perceber, a base do FDD est na criao de uma

lista de features que servem como base para a modelagem do
sistema e os investimentos que necessitam ser realizados para
sua construo. Para ANDERSON (2004), esta lista requisito
necessrio para o projeto FDD. Ainda de acordo com este
autor, o custo de operao com o plano, design e construo
so conhecidos como despesas de operao. J as features
entregues ao longo do tempo so mensuradas a partir de uma
taxa de produo. Desta forma, se consegue mensurar o custo
x desempenho de custo do projeto.
Conforme descrito a partir da Figura 1, pode-se concluir que
h uma priorizao da lista de features que sero desenvolvidas e que, consequentemente, outras ficaro aguardando o
momento de serem realizadas. Para se alcanar uma estimativa
de tempo para projetos baseados no FDD, so considerados os
tempos das atividades envolvidas em todo o processo e, para
isso, a estimativa dividida conforme demonstra a Figura 2.
Os trs primeiros estgios que envolvem o tempo de configurao determinam uma espcie de linha de base de desenvolvimento das atividades. Essa linha responsvel por
controlar todas as verses entregues do produto. a linha
central do processo.
10
Figura 2. Estimativa de Tempo no FDD.
J o tempo do processo serve para mensurar o tempo de

construo de builds baseados nas features priorizadas pelo
cliente e pelo chefe do desenvolvimento. Vale observar que
aps a concluso de um determinado build, ela passa pelas
diversas etapas de testes at ser efetivamente entregue ao
cliente. Este perodo que compreende a efetivao dos testes
e o recebimento do pequeno pacote pelo cliente chamado de
tempo de espera.
O prazo para a realizao de determinas iteraes baseado
na soma da atividade de tempo de espera que antecede os
estgios da configurao, denominado de Queue, o tempo
de configurao, o tempo de processo e o tempo de espera.
importante lembrar que o FDD, assim como todas as metodologias geis, prega o desenvolvimento de um pequeno grupo de
funcionalidades por vez. O plano estabelecido para o projeto
deve ser seguido a cada release entregue para o cliente. Este
plano atualizado ao final de cada ciclo.
O ponto chave para estimar o tempo no FDD est na definio
do nvel de arquitetura de uma feature. Essa arquitetura pode
possuir um nvel baixo, mdio ou alto de complexidade. O FDD
particiona a arquitetura do sistema e percorre o fluxo diversas
vezes at a soluo estar concluda. O dimensionamento de
tempo realizado desta forma. Para Anderson (2004), a preciso das estimativas do FDD est na refinada lista de features
que gerada e o uso da repetio da frmula para estimar o
que ser realizado. Outro ponto destacado por este autor est
no particionamento da arquitetura por sua complexidade, o
que ajuda a compreender melhor os atrasos no cronograma e
as necessidades da equipe.
A equipe FDD
Como o FDD uma abordagem utilizada para o paradigma
de sistemas orientados a objetos, no de se estranhar que
alguns papis previstos na metodologia requeiram habilidades
de UML e cheguem a ser parecidos com o framework RUP. Em
sua estrutura, o FDD define seis papis principais, que esto
envolvidos diretamente com a realizao dos processos da
metodologia. Outros papis tambm so alocados ao projeto
para realizar atividades de suporte, tais como: gerente do domnio, gerente de releases, expert da linguagem, engenheiro
de build, administrador de sistemas, testers, desenvolvedor
e redator tcnico. Destaca-se ainda que uma pessoa possa
assumir uma ou mais funes em um projeto, assim como o
framework RUP.
Agilidade
Papis
Programador(es) Chefe(s)
Proprietrios das Classes
Gerente do Projeto
Arquiteto Chefe
Gerente de Desenvolvimento
Especialista do Domnio
Funo
Realiza o planejamento das entregas das features;
Aloca os proprietrios das classes;
Entrega um conjunto de features para os clientes e interessados;
Garante a qualidade de todos os releases;
Lidera o time de features.
Pode estar, simultaneamente, em mais de uma equipe de Features;
Responsvel por modelar, codificar, testar e documentar as novas features nos cdigos em que so os proprietrios;
Lder administrativo do projeto;
Relata o progresso do projeto;
Gerencia oramentos;
Busca e gerencia recursos de qualquer tipo e que sejam necessrios ao bom desenvolvimento do projeto.
Responsvel por toda a modelagem do sistema (design);
Realiza oficinas de modelagem junto equipe.
Responsvel pelo dia-a-dia das atividades de desenvolvimento;
Resolve conflitos de recursos.
Qualquer pessoa que conhea do negcio para o qual o produto esta sendo desenvolvido.
Tabela 1. Principais papis no FDD
A Tabela 1 indica os principais papis e suas responsabilidades.

Importante ressaltar que, ao contrrio do Scrum e do XP
que definem o tamanho ideal da equipe, o FDD no prega um
nmero fixo de profissionais para executar as suas atividades.
Como a metodologia aplicada a projetos de vrios tamanhos,
necessrio apenas que o tamanho da equipe garanta uma
escalabilidade do processo.
Os principios geis e o FDD

O FDD como metodologia gil, deve estar alinhado com os
valores e princpios do manifesto gil publicado em 2001. A
estrutura da metodologia demonstrada anteriormente faz
constatar que o FDD busca atender aos valores deste manifesto de forma absoluta, mesmo que em alguns momentos a
metodologia passe a impresso de ser excessivamente formal
para os padres geis.
De acordo com o manifesto gil, publicado no site agilemanifesto.org, enumeram-se doze princpios no qual o software
gil deve se basear, sendo eles:
Nossa maior prioridade satisfazer o cliente atravs
da entrega contnua e adiantada de software com valor
agregado.
1. O FDD tem seu foco neste aspecto: satisfazer o cliente. Tanto
verdade que o cliente indica o que prioritrio e a lista refinada de features orienta o desenvolvimento de forma a realizar
pequenas entregas com algum valor para o cliente;
Mudanas nos requisitos so bem-vindas, mesmo tardiamente no desenvolvimento. Processos geis tiram vantagem das
mudanas visando vantagem competitiva para o cliente.
2. O desenvolvimento incremental e iterativo so caractersticas
essenciais das metodologias geis. No FDD estas caractersticas
so explicitadas no desenvolvimento por pequenos pacotes de
funcionalidades, de forma a permitir que o cliente materialize
os requisitos do sistema e do negcio e permita indicar quais
mudanas sero necessrias para o prximo release, sem que,

para isso, todo o sistema precise ser refeito;
Entregar frequentemente software funcionando, de poucas
semanas a poucos meses, com preferncia menor escala de
tempo.
3. O FDD faz isso conforme libera releases. O tempo de construo
de cada release varia conforme a complexidade da arquitetura de
features proposta para aquelas iteraes;
Pessoas de negcio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.
4. O cliente fundamental para estabelecer suas prioridades, definir o modelo geral do sistema, definir a lista de features, aprovar
os releases desenvolvidos e testados e planejar o projeto. O FDD
no exige a presena do cliente diariamente. Inclusive este ponto
torna o FDD mais factvel do que outras metodologias geis que
exigem tal presena;
Construa projetos em torno de indivduos motivados. D a
eles o ambiente e o suporte necessrio e confie neles para fazer
o trabalho.
5. A equipe de projeto trabalha de forma integrada em todas as
fases do projeto. O processo do FDD, apesar de indicar claramente
o que cada um deve fazer, d autonomia para a equipe planejar
e executar o projeto da melhor forma possvel;
O mtodo mais eficiente e eficaz de transmitir informaes
para e entre uma equipe de desenvolvimento atravs de conversa face a face.
6. As equipes trabalham em um mesmo local e as conversas so
dirias. A equipe tcnica participa das decises do projeto, que
no ficam a cargo exclusivamente do gerente de projeto;
Software funcionando a medida primria de progresso.
7. Como o tempo do projeto estimado com base na complexidade das releases e elas so produzidas em perodos curto de
tempo, o cliente tem a percepo exata do andamento do projeto.
O cliente, a cada perodo, detm em suas mos uma pequena, mas
poderosa, funcionalidade para utilizar. O gerente do projeto tem
11
Concluso
12
Esta imagem retrata a fora das metodologias geis, especialmente, a do FDD. O FDD deve ser adotado por organizaes
que procuram migrar de processos exclusivamente iterativos ou
em cascata (waterfall) para o paradigma gil. Esta metodologia
prov mecanismos que garantem a qualidade, documentao,
reteno do conhecimento e atendimento s expectativas do
cliente. Apesar de ela utilizar artefatos da UML, que so amplamente utilizados pela Rational Unified Process (RUP), ela os
utiliza de maneira simplificada e inteligente. O foco do FDD est
no equilbrio entre os requisitos e o cdigo, entre a tcnica e o
negcio. Este o FDD, uma metodologia que equilibra as foras
e torna-se altamente poderosa para quem quer escalabilidade,
integridade, melhoria contnua e aprendizagem constante.
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
evidente que no grande universo de metodologias que envolvem a Engenharia de Software, apontar uma como a mais
adequada correr risco desnecessrio. Cada organizao tem
suas necessidades de mudana e seu tempo de mudana. A
Engenharia de Software tem que estar disposio de cada
necessidade, de forma a melhor desempenhar o seu papel de
apoio ao desenvolvimento do negcio.
Figura 3. Pesquisa sobre uso de metodologias de Engenharia de Software
D
s
Os pontos de validao, testes, refatorao e a utilizao da

abordagem EVTX garantem um produto mais adequado. O
gerenciamento de projeto previsto na metodologia provoca
a melhoria contnua no processo. O cliente, por sua vez, o
grande motivador da equipe, j que ele faz parte dela.
A famlia de metodologias geis, que ao longo dos anos

recebeu diversas crticas dos mais tradicionalistas, vem comprovando sua fora por meio dos clientes e organizaes. Em
trabalho publicado no ano de 2010, Dave West e Tom Grand,
demonstraram o crescimento destas metodologias. O FDD,
como no poderia deixar de ser, est entre as principais metodologias utilizadas no mundo da Engenharia de Software.
Na pesquisa realizada pela Forrester/Dr. Dobbs Global Developer Technographics Survey em 2009, 35% das pessoas
afirmaram que as geis refletiam melhor seu processo de
desenvolvimento, com o nmero aumentando para 45% das
organizaes entrevistadas que disseram que gostariam de
adotar os valores e princpios geis.
A Figura 3 retrata a pesquisa realizada e o crescimento das
metodologis geis
edio
ta
a funo bsica de manter todos informados sobre o andamento

do projeto, e o(s) programador(es) chefe tem a funo de remover
as dificuldades encontradas pela equipe;
Os processos geis promovem desenvolvimento sustentvel.
Os patrocinadores, desenvolvedores e usurios devem ser capazes
de manter um ritmo constante indefinidamente.
8. O FDD tem a natureza de projetos e como tais h um trmino
previsto. O manifesto gil prev que o software seja construdo
de forma contnua, sempre atendendo ao cliente quando ele assim
necessitar. O FDD tem seu foco em projeto;
Contnua ateno a excelncia tcnica e bom design aumenta
a agilidade.
9. O FDD tem dois estgios que trabalham com entendimento da
soluo e modelagem das funcionalidades. Neste aspecto, o FDD
utiliza o que h de melhor do RUP, por exemplo. Veja quantos
diagramas UML so exigidos pela metodologia FDD. Este o
ponto forte desta metodologia, que conseguiu agregar o melhor
dos dois paradigmas;
Simplicidade-- a arte de maximizar a quantidade de trabalho
no realizado-- essencial.
10. A simplicidade inerente ao processo do FDD. A produo
de artefatos caractersticos da UML, como os Diagramas de
Sequncia e de Classes, nos quais so utilizados exclusivamente
para compreenso dos requisitos principais e crticos que sero
desenvolvidos de forma prioritria, no retiram a simplicidade
do processo. O foco est em minimizar o desenvolvimento dos
requisitos que no foram solicitados pelo cliente e que pouco
agregam valor ao seu negcio. Os releases baseados em pequenos
pacotes de funcionalidades tambm atendem a este princpio do
manifesto gil;
As melhores arquiteturas, requisitos e designs emergem de
equipes auto organizveis.
11. No FDD os papis so bem definidos, mas no exclusivos. Uma
pessoa pode realizar mais de um papel ao longo do projeto. A
equipe, por ser adequada complexidade do projeto, consegue
prover a escalabilidade necessria para se produzir e atender s
necessidades do cliente;
Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e ento refina e ajusta seu comportamento de
acordo.
Agilidade
Nesta seo voc encontra artigos voltados para as prticas e mtodos geis.
Scrum e MPS.BR: Um caso prtico do uso em

conjunto destas abordagens
O caso da AltoQi
Andr Luiz Banki

banki@altoqi.com.br
Engenheiro Civil pela Universidade Federal de Santa Catarina (UFSC), Mestre em

Engenharia Civil (na rea de Estruturas),
tambm pela UFSC, e Especialista em Engenharia de Software pelo SENAI/Florianpolis. Trabalha como Gerente de Desenvolvimento na empresa AltoQi Tecnologia
Aplicada Engenharia, com mais de 15
anos de experincia no gerenciamento de
projetos de desenvolvimento de software,
incluindo atividades de pesquisa tcnica,
levantamento de requisitos e coordenao de equipes. Responsvel por todo o
processo criativo no desenvolvimento de
complexas ferramentas de software para
Engenharia em ambiente CAD, adotadas
por mais de 15.000 profissionais em todo o
territrio nacional, bem como pela concepo e implantao de um processo de desenvolvimento baseado em metodologias
geis e pela adequao desse processo ao
nvel G do modelo MPS.BR. Possui certificao PMP, RUP e Scrum.
Relato de experincia, englobando quatro anos de

investimento de uma empresa nacional de desenvolvimento de software na implantao de tcnicas de
Engenharia de Software, com destaque para a automao de testes, e de uma metodologia de desenvolvimento iterativo baseada no Scrum e avaliada pelo
modelo MPS.BR. Est focado na aplicao prtica
desses conceitos em um modelo de desenvolvimento
colaborativo e apresenta os resultados alcanados
pela empresa com esse projeto.

A escolha da metodologia mais adequada para o
desenvolvimento de software em uma organizao, levando em considerao os inmeros fatores
envolvidos, no uma tarefa trivial. A publicao
de estudos de caso, como este, procura apontar
algumas dificuldades prticas envolvidas com a
implantao de processos e auxiliar as empresas a
traar o seu caminho rumo melhoria contnua.
Resumo:
A AltoQi uma empresa no mercado brasileiro de
software para Engenharia, com mais de 20 anos
de experincia tanto no desenvolvimento como na
comercializao de seus produtos. Ainda assim, a
partir de um dado momento, o custo de manuten-
o desses sistemas tornou-se elevado, comprometendo a sua capacidade de desenvolvimento. Neste

contexto, neste artigo ser abordado o investimento que a empresa efetuou para controlar o desenvolvimento dos seus sistemas legados, iniciando
pelo controle de solicitaes, controle de verses e
automao de testes. Ser discutida a necessidade
de investimento em boas prticas de Engenharia de
Software como subsdio a uma efetiva implantao
de metodologias geis de desenvolvimento.
A partir desse investimento em infra-estrutura, a
aplicao de uma metodologia de desenvolvimento iterativo, baseada no Scrum, permitiu empresa retomar o seu ritmo de crescimento e estender
esse conceito a uma nova forma de interao com
seus usurios. Com seus mais de 20.000 clientes,
a empresa precisava de uma forma de levantar
as reais necessidades dos seus clientes para criar
uma nova verso de seu principal produto.
O conceito do desenvolvimento iterativo foi aplicado na prtica, em um projeto de oito Releases,
no qual cada um dos recursos foi discutido com os
clientes em um blog de desenvolvimento. Com
esse feedback, os requisitos desse produto puderam ser definidos com mais clareza e refinados
a cada release liberado. O resultado foi positivo
para os clientes, para a equipe de desenvolvimento e, especialmente, para a empresa.
13
AltoQi (www.altoqi.com.br) atua desde 1989 no desenvolvimento e comercializao de software para

projetos de Engenharia, possuindo mais de 23 mil
clientes no Brasil e no exterior. O mercado da construo civil engloba mais de 12 especialidades diferentes, sendo que,
destas, as principais so atendidas pelos produtos da empresa: AltoQi Eberick (para projeto de estruturas em concreto
armado), AltoQi Hydros (para projeto de instalaes prediais
hidrulicas, sanitrias, de gs e de preveno e combate a
incndio), AltoQi Lumine (para projeto de instalaes eltricas prediais e de infra-estrutura para cabeamento) e QiCAD
(plataforma independente de CAD, voltada complementao
dos desenhos gerados).
Alm dos produtos de software e dos servios de suporte
tcnico e especializado aos seus usurios, a AltoQi tambm
atua, atravs do seu canal QiSat (Sistema Integrado de Ensino
a Distncia, Presencial e de Servios Dirigidos ao Mercado da
Construo Civil, www.qisat.com.br), para prover os profissionais ligados rea de construo civil de um mecanismo de
acesso constante e atualizado ao conhecimento, capacitao,
outras oportunidades e servios.
A AltoQi est presente em todos os Estados da Federao,
totalizando uma base de relacionamento com mais de 400 mil
profissionais, atravs de atendimento comercial, convnios
com mais de 100 universidades e com os principais CREAs
do pas, e dos mais de 6.000 alunos atendidos no canal de
ensino do QiSat.
Clientes interagindo com a equipe de Suporte Tcnico, para

sanar suas dvidas. Eventuais problemas e sugestes so
levantados para futura anlise.
Interao do Suporte com a equipe de Produto, responsvel
por analisar os problemas e sugestes reportados e convertlos em requisitos para os prximos projetos.
Interface entre a equipe de Produto, aps priorizar as necessidades para o programa, com o departamento de Desenvolvimento, para planejar e executar os projetos relacionados a
esses recursos.
Figura 1. Relacionamento entre os departamentos e o cliente
Forma de atuao
A organizao AltoQi tem como objetivo principal de negcio o desenvolvimento e comercializao de produtos de
software para o mercado da Construo Civil. Esses produtos
de software organizam-se em Linhas de desenvolvimento,
representadas por um Produto principal e seus diversos Mdulos opcionais.
Os produtos desenvolvidos pela AltoQi so pacotes fechados, cuja customizao pelo cliente limitada escolha dos
mdulos a serem adquiridos. Por isso, no h um cliente
definido em nenhum projeto de desenvolvimento. No seu
lugar, cabe ao Departamento de Produtos e Servios (DPS)
representar o cliente, exercendo o papel de Product Owner
em relao ao Departamento de Desenvolvimento. O DPS
o responsvel pelas atividades de anlise dos produtos da
empresa e do seu posicionamento no mercado, avaliao de
novos produtos e novos recursos para os produtos atuais da
empresa, suporte tcnico aos clientes externos e treinamento
tcnico para clientes externos e internos. O Departamento
de Desenvolvimento responsvel por planejar, executar e
controlar as atividades que tero como resultado o produto
de software selecionado pelo DPS. Cabe ao Departamento de
Desenvolvimento a criao de novos produtos ou verses, as
quais possam vir a ser comercializadas pela empresa, junto
sua extensa base de clientes.
A relao entre os dois departamentos e os clientes pode ser
observada na Figura 1 a qual ilustra:
14
Nesse cenrio, um fator que diferencia a AltoQi de outras empresas de software a forte necessidade do desenvolvimento
interno dos requisitos. As necessidades dos clientes referem-se
a problemas no campo de conhecimento da Engenharia Civil
e, especialmente pela natureza grfica e tridimensional das
aplicaes envolvidas, no so descritas adequadamente nem
pelos prprios clientes. A empresa precisa ter, em sua equipe,
corpo tcnico adequado para entender as necessidades dos
clientes, convert-las em requisitos de software, detalh-las em
grau adequado para permitir a sua implementao e conferir
cada um dos resultados apresentados.
Implantao de processos
Atualmente, o Departamento de Desenvolvimento da AltoQi
possui o nvel G do MPS.BR, o Modelo de Melhoria de Processos de Software Brasileiro, mas nem sempre este foi o cenrio.
Durante muitos anos, os quais englobaram o desenvolvimento
dos produtos da empresa que so mantidos at hoje, o processo
poderia ser descrito apenas como programar e corrigir. Existia uma separao entre os Departamentos de Desenvolvimento e de Suporte Tcnico, isolando a equipe de desenvolvimento
de um contato direto com a base de clientes, mas no havia
um trabalho sistematizado de Produto nem a aplicao de
tcnicas adequadas da Engenharia de Software. Cabe explicar
que os produtos da empresa sofreram manuteno evolutiva
desde sua criao, com o lanamento de Verses comerciais,
Engenharia de Software Magazine - Scrum e MPS.BR: Um caso prtico do uso em conjunto destas abordagens
agilidade
a intervalos de um a dois anos, e manuteno corretiva entre

cada uma dessas verses, com a liberao de Revises sem
custo para os clientes. A mesma equipe de desenvolvimento
sempre esteve responsvel tanto pelo desenvolvimento das
novas verses como pela manuteno das verses existentes.
Esse trabalho de evoluo do programa era conduzido
apenas com o apoio de testes exploratrios manuais, executados pela equipe de Suporte Tcnico. Os resultados
obtidos foram satisfatrios at 2006, quando o lanamento
de uma nova verso do AltoQi Eberick, contendo mudanas muito significativas em relao sua verso anterior,
provou que essa sistemtica era insuficiente para lidar
com uma alterao daquela magnitude. A verso lanada
apresentou um elevado ndice de defeitos e, pelos dois anos
seguintes, a maior parte do esforo de desenvolvimento teve
que ser direcionada para a correo de problemas. Aps
vrias Revises, o produto foi estabilizado, mas esse custo
de manuteno causou um atraso significativo no ciclo de
desenvolvimento da empresa.
Para entender esse problema, importante avaliar que, em
2007, a equipe de desenvolvimento lidava com um sistema
que possua uma elevada complexidade tcnica (envolvendo computao grfica, anlise estrutural, prescries
normativas de Engenharia e um grande leque de conceitos
tcnicos inacessveis aos programadores), sobre uma base
de cdigo legado desenvolvida continuamente desde 1994
e contendo um elevado grau de acoplamento entre todas as
suas partes, sem o apoio de tcnicas adequadas para lidar
com essa situao.
A reverso dessa situao pde ser obtida apenas por um
investimento da empresa na melhoria do seu processo de
desenvolvimento, comeando pelos testes, problema primrio
da empresa na poca. Existem duas estratgias principais para
teste de software: os testes de caixa preta e os testes de caixa
branca. Os testes de caixa branca, ou testes estruturais, so
utilizados para avaliar o comportamento interno do software,
usualmente para verificar funcionalidades individuais, atravs de testes unitrios. Essa abordagem foi descartada, pelo
grande volume de cdigo legado e reduzido prazo disponvel
para a obteno de resultados.
No seu lugar, a empresa investiu nos testes de caixa preta,
ou testes funcionais, utilizados para avaliar o comportamento
externo do sistema, ignorando detalhes especficos de sua
implementao e procurando testar o sistema como um todo,
ao representar a interao do usurio com o software. Para
isso, implantou um sistema prprio de automao de testes e
instituiu, dentro do Desenvolvimento, o papel especfico de
Engenheiro de Testes, responsvel por planejar e construir
a base de testes que viria a garantir uma regresso completa
do sistema a cada modificao efetuada. Esse trabalho foi
transferido da equipe de Suporte para uma nova equipe
dedicada apenas a essa tarefa. Hoje, cerca de metade da
equipe de desenvolvimento composta por profissionais da
rea da Computao e a outra metade por profissionais da
rea de Engenharia.
Em paralelo a isso, a equipe implantou um sistema e poltica

de controle de verses (antes feito apenas informalmente) e um
sistema para controle das solicitaes (voltado, inicialmente,
para gerenciamento dos problemas reportados pelos clientes e
das correes efetuadas). Quando foi possvel combinar as trs
tcnicas (controle de verses, controle de mudanas e testes automatizados), a equipe finalmente pde estabelecer um conceito
fundamental para apoiar o gerenciamento do projeto: a rastreabilidade. Segundo o MPS.BR, a rastreabilidade deve ser estabelecida
desde um requisito fonte, passando pelos seus requisitos de baixo
nvel, at o nvel de decomposio mais baixo do produto (cdigo
fonte) e vice-versa. Isso permite associar qualquer modificao
efetuada no programa aos requisitos que a motivaram e, com
isso, avaliar com muito mais rapidez qualquer defeito que tenha
sido inserido por essa modificao (ver Figura 2).
Figura 2. Tcnicas da Engenharia de Software
Antes disso, dada a grande complexidade tcnica do sistema, a equipe de desenvolvimento lidava com cada problema
reportado pelos clientes apenas investigando-o diretamente,
o que podia gerar impactos em outras partes do programa
que no eram detectados rapidamente, pela dificuldade
do teste. Com a automao dos testes, essa propagao de
defeitos pde ser limitada e o custo de cada correo foi
reduzido drasticamente, uma vez que o defeito podia ser
detectado rapidamente e rastreado at a sua origem.
Esse ciclo de melhoria levou dois anos para ser implementado. Com ele, a empresa pde retomar o controle
sobre o seu processo de desenvolvimento, recuperar o seu
principal produto e passar da manuteno para a melhoria
no processo de desenvolvimento de novos produtos. Para
que isso pudesse ocorrer, importante destacar tambm a
necessidade de capacitao, exercida principalmente pela
especializao do Gerente de Desenvolvimento, responsvel
pela definio de todo o processo e capacitao, por sua vez,
de toda a equipe. Retirar o foco do dia-a-dia das atividades
e estudar as melhores prticas do mercado fundamental
para entender como aplic-las corretamente no seu ambiente
de desenvolvimento.
A migrao para um modelo de desenvolvimento iterativo,
assunto do tpico a seguir, foi possvel apenas tendo por base a
correta aplicao de boas prticas da Engenharia de Software.
15
Modelo iterativo
Pode-se definir um Projeto como um esforo temporrio
realizado com o objetivo de produzir um produto ou servio
nico. Temporrio significa que todo projeto tem incio e fim
explicitamente definidos e nico indica o fato de que cada projeto possui caractersticas prprias e seu produto resultante
distinto em um ou mais aspectos de outros projetos existentes.
Como caractersticas comuns para qualquer Projeto, so realizados por pessoas, possuem alguma restrio de recursos,
so planejados, executados e controlados.
Embora as empresas de desenvolvimento de software, de forma
geral, trabalhem na criao de Produtos, nem todas organizam
efetivamente isso na forma de Projetos. O estabelecimento desse
conceito, tendo por base a definio sistematizada do Escopo de
um projeto antes do incio do mesmo, bem como o controle sobre
as mudanas nesse escopo ao longo do projeto, foi o primeiro
passo na implantao de um modelo de desenvolvimento na
AltoQi. O Departamento de Produtos e Servios (DPS) foi criado
nessa etapa, para separar as atividades de definio do escopo
do projeto (necessidades dos clientes) das atividades de execuo
desse escopo (desenvolvimento de software).
No perodo 2009 / 2010, correspondente implantao do
processo de desenvolvimento descrito neste artigo, culminando com a avaliao nvel G do MPS.BR em Dezembro /
2010, foram concludos 20 projetos, em um total superior a
79000 horas de desenvolvimento. Esses projetos validaram o
processo proposto e fornecem importante base histrica para
o planejamento de projetos futuros.
O modelo de ciclo de vida adotado pela AltoQi, de natureza
iterativa e incremental, se baseia no aumento e refinamento
sucessivo de um sistema atravs de mltiplos ciclos de anlise,
projeto, implementao e teste, conforme colocado na Figura 3.
Est fundamentado no Scrum, uma metodologia que tem
alcanado reconhecimento como uma ferramenta eficaz para
desenvolvimento produtivo de software. Segundo Sutherland, mesmo quando padres de Scrum so combinados com
outros padres organizacionais existentes, eles so altamente
adaptveis, ainda que em organizaes de desenvolvimento
de software bem estruturadas.
O Scrum utiliza um conjunto de artefatos que suportam o
processo de desenvolvimento e controlam o seu progresso.
Para iniciar um projeto Scrum bastam uma Viso do produto,
descrevendo a motivao do projeto e o seu resultado final esperado, e um Project Backlog (Lista de Recursos), documento que
contm a lista completa dos requisitos do projeto, necessrios
para atender a Viso do produto. Na AltoQi, tambm usado
o termo Release Backlog, visto que cada Release de um Produto
gerenciado como um Projeto independente.
O processo apresenta trs fases distintas: Preparao, Desenvolvimento e Fechamento. A fase de Preparao, tambm
chamada iterao zero, tem o objetivo de definir o Plano
do Projeto, incluindo seu Escopo (recursos a serem desenvolvidos), Prazo e Custo, encerrando-se quando o sistema a ser
desenvolvido est definido, sua viabilidade est confirmada e
as ferramentas necessrias esto disposio da equipe.
16
Figura 3. Diagrama simplificado do modelo iterativo
As estimativas de software fornecem subsdios para a definio de aspectos fundamentais dessa fase. Uma estimativa
aproximada de tamanho das atividades que fazem parte do
escopo permite que oGerente de Projetosdefina qual o cronograma do projeto, o esforo necessrio, seu custo e os recursos
que sero necessrios para desenvolv-lo. Esse assunto ser
tratado com mais detalhe no prximo tpico.
A fase de Desenvolvimento, dividida em iteraes, contm a
execuo das atividades tcnicas necessrias ao cumprimento
do escopo do projeto. Encerra-se quando todos os itens presentes no Release Backlog tenham sido implementados. Cada
iterao definida como uma time box, com durao de duas
semanas, na qual so executados parte dos itens definidos no
Release Backlog (formando o Iteration Backlog). O resultado do
item do trabalho a ser desenvolvido um incremento do produto. A Figura 4 ilustra o ciclo de desenvolvimento, no qual os
requisitos so apresentados no Iteration Backlog e desenvolvidos
na iterao, gerando um novo incremento que ser entregue
para a fase final do processo.
Ao final de cada iterao, deve-se ter um sistema completo,
testado e documentado. Para isso, fundamental o apoio de
um programa de testes automatizados. A abordagem iterativa
permite considerar a alterao nos requisitos, uma vez que eles
normalmente sero alterados durante o processo. A abordagem
tradicional, na qual todos os requisitos so determinados, de
uma vez, no incio do projeto, vlida apenas para projetos
bastante triviais (KRUCHTEN, 2000). O ponto chave est na
produo de verses do sistema final, de forma que, em cada
uma, esteja presente um conjunto crescente de funcionalidades,
j completamente integrada e testada. importante frisar que
as alteraes nos requisitos devem ser controladas, mantendose o rumo do projeto.
A fase de Fechamento se inicia aps a concluso de todas
as atividades tcnicas do projeto (ou seja, aps a finalizao
do escopo do projeto). Contm uma avaliao organizacional
do resultado do projeto, com a coleta de lies aprendidas e
informaes histricas que sero teis para o desenvolvimento
dos prximos projetos (ver Figura 5).
Estimativas de software
Dentre os aspectos que foram importantes para a definio de um processo de desenvolvimento na AltoQi, o mais
complexo deles foi a estimativa dos produtos de software.
agilidade
Estimar e planejar so atividades crticas

para o sucesso de qualquer projeto de
desenvolvimento de software. Permitem guiar os investimentos no projeto,
definir que equipe precisar ser alocada
ao projeto em cada perodo e saber se o
projeto est no caminho correto para
entregar a funcionalidade desejada ao
seu final.
Dentro do cenrio especfico da AltoQi,
importante relembrar que, em 2009,
o Departamento de Desenvolvimento
estava saindo de um ciclo vicioso de
manuteno do seu principal produto,
durante o qual a capacidade da empresa
de entregar novos produtos, no prazo
definido e com a qualidade necessria,
estava sendo questionado. No aspecto da
qualidade, a implantao das prticas j
discutidas, com destaque para os testes
automatizados, foi fundamental. No
aspecto do cumprimento dos cronogramas, era preciso estabelecer uma forma
adequada de estimar os projetos a serem
desenvolvidos.
Vasquez (2009) destaca algumas dificuldadesno ato de estimar:
Ambiguidade, volatidade, falta de
clareza: no possvel realizar uma
estimativa adequada sobre um requisito
que no esteja corretamente definido.
Falta de clareza ou ambigidade nos
requisitos resultam em estimativas mal
formuladas.
Falta de medies adequadas: sem um
acompanhamento do projeto, com a comparao entre os valores estimados e os
valores realizados, no h retorno para
a equipe quanto qualidade e utilidade
das suas estimativas.
Falta de referncias vlidas: em termos
de software, usual tratar-se as estimativas em uma base comparativa, um
critrio que pode levar ao erro se forem
adotadas referncias inadequadas em
relao ao projeto corrente.
Viso distorcida do que seja estimar:
comum que se tenha dificuldade em
diferenciar a estimativa dos conceitos de
meta e compromisso. Uma estimativa
uma avaliao aproximada de algo (fornecer uma estimativa, para software,
o ato tcnico de atribuir um tamanho a
uma determinada grandeza). Com base
nela, pode-se estabelecer uma meta, um
Figura 4. O papel das estimativas no desenvolvimento do plano de projeto
Figura 5. Ciclo de vida
objetivo relacionado a tempo e valor (estipular uma meta um ato gerencial ou

poltico) e assumir um compromisso, ou
seja, o acordo final e responsabilidade,
adquirida de forma verbal ou escrita,
sobre o resultado do projeto. So trs
variveis diferentes (ver Figura 6).
Existem vrios procedimentos disponveis em bibliografia para estimativa
de software. Quando o processo foi
inicialmente estabelecido, no incio de
2009, foi concebido para basear-se no
Scrum e utilizar o procedimento mais
comum nas metodologias geis, os

Story Points. Uma User Story (estria de
usurio) uma breve descrio de uma
funcionalidade a ser desenvolvida no
projeto, do ponto de vista de um usurio
do sistema, escrita de forma livre. Os
Story Points so uma unidade de medida
aplicada para representar o tamanho /
complexidade de cada User Story, na
qual o valor isolado de uma estimativa
no tem qualquer importncia, mas sim
o tamanho relativo entre os diversos
recursos do projeto. Costuma-se atribuir
uma escala no linear de valores, como
17
a sequncia de Fibonacci (1, 2, 3, 5, 8, 13...) ou a progresso

geomtrica (1, 2, 4, 8, 16...). Isso importante para ressaltar o
fato de que, quanto maior o tamanho da tarefa sendo estimada,
menor a preciso da medida. Por exemplo, no h sentido em
estimar uma tarefa com 8 e outra com 9 pontos.
Nas trs tcnicas, o principal conceito comum o de utilizar

otamanhoe no oesforocomo estimativa de qualquer tarefa.
O tamanho representa uma medida da atividade que deve ser
independente do profissional que a executa. Para que se obtenha o esforo estimado (nmero de horas necessrias), deve-se
conhecer a produtividadedo profissional ou da equipe, valor
que s pode ser obtido na execuo de atividades anteriores
que tenham sido estimadas da mesma forma (ver Figura 7).
Figura 7. Estimativa por tamanho
Figura 6. Meta, estimativa e compromisso
Esse critrio foi usado durante o primeiro ano de implantao do

processo, gerando resultados interessantes e trazendo bom grau de
controle ao projeto no qual estava sendo aplicado, mas apresentou
algumas deficincias. Em primeiro lugar, mesmo mantendo a
mesma equipe na execuo de uma sequncia de projetos, esse
procedimento permitia definir uma escala relativa de tamanho
adequada entre as Stories desse projeto, mas apresentava dificuldades na comparao de um projeto com o outro, reduzindo a eficcia
das informaes histricas disponveis. Em segundo lugar, e mais
importante, como a empresa possua outras equipes trabalhando
em outras linhas de desenvolvimento, o critrio das Story Points
utilizava referncias diferentes em cada equipe, inviabilizando um
controle organizacional do desempenho dos diversos projetos.
Para melhorar o processo, foram avaliadas duas outras importantes tcnicas de estimativa de software:
Pontos de funo (Function Points): tcnica mais utilizada
pelo mercado para mensurao do tamanho de projetos de
desenvolvimento e melhoria de sistemas. Objetiva a determinao do tamanho funcional do sistema atravs da viso
do usurio, independentemente da tecnologia utilizada. O
mtodo mais usado para contagem dos pontos de funo
a Contagem Indicativa proposta pela NESMA (Netherlands
Software Metrics Association), na qual as funcionalidades so
separadas em cinco tipos: entradas, sadas, consultas, arquivos
internos e interfaces externas.
Pontos por casos de uso (Use Case Points): mtrica apresentada
ao mercado como uma soluo mais simples para as estimativas de tamanho, baseada na contagem dos casos de uso utilizados para representar os requisitos de sistema e dos atores
envolvidos com os mesmos, obtendo o nmero de pontos por
caso de uso no ajustados. A esse valor so aplicados fatores
de complexidade tcnica e complexidade ambiental, obtendo
o nmero de pontos por caso de uso ajustados.
18
medida que as estimativas so realizadas, elas podem ser

adicionadas em umabase histrica de estimativas, servindo
de referncia para novos projetos. Esse histrico de estimativas
permite o refinamento das mesmas e a consistncia entre as
estimativas realizadas. Isso vlido desde que se use o mesmo
critrio de medida consistente para as diversas estimativas
(ver Figura 8).
Figura 8. Processo de estimativas alimentando a base histrica
Na AltoQi, nenhuma das trs tcnicas pde ser aplicada

diretamente. Os Story Points apresentavam a dificuldade de
comparar os resultados entre equipes diferentes. A mtrica
dos Pontos de Funo objetiva justamente definir um critrio
de medida que seja vlido entre diferentes organizaes,
mas o processo de contagem proposto pela NESMA (2004)
no bem definido para aplicaes baseadas em computao
grfica, dificultando a adoo desse mtodo. A aplicao dos
Pontos por Caso de Uso est limitada a projetos de software
agilidade
cuja especificao seja feita na forma de casos de uso. Alm

disso, no existe um padro nico para a escrita do caso de
uso, deixando o resultado da contagem dependente da forma
como cada profissional escreve os casos de uso. Essa definio
tambm no seria suficientemente consistente entre equipes
diferentes.
Procurando aproveitar o melhor de cada tcnica, a equipe
criou uma escala prpria de decomposio funcional (pontos
de funo) para seus requisitos. Ao invs de estimar diretamente uma User Story, a mesma dividida em quantos aspectos
funcionais possam ser identificados (ferramentas grficas,
algoritmos de dimensionamento, gerao de desenhos, etc.) e
cada uma dessas partes estimada. Ao reduzir um problema
a aspectos mais genricos, tornou-se possvel manter uma
consistncia entre diversos projetos e mesmo entre as equipes
que lidam com Produtos diferentes. Os resultados obtidos com
as estimativas nunca so totalmente precisos, mas so teis
e servem ao propsito estabelecido pela organizao. com
base neles que o desempenho de cada um dos projetos pode
ser acompanhado e o conceito de desenvolvimento colaborativo, exposto a seguir, pde ser aplicado com a confiabilidade
necessria.
Desenvolvimento colaborativo
No incio de 2009, a empresa preparava-se para iniciar o desenvolvimento de uma nova verso de seu principal produto,
o AltoQi Eberick V6. O processo de desenvolvimento a ser
adotado havia sido concebido e uma ferramenta para gerenciamento dos projetos havia sido pesquisada, customizada
e implantada, suportando o processo definido. O escopo do
produto estava sendo selecionado pelo DPS, dentre uma lista
de cerca de 300 sugestes reportadas pelos clientes ao longo dos
ltimos anos. Era sabido que havia tempo e equipe disponvel
para atender apenas a uma pequena parte dessa demanda.
O foco desse projeto, conforme definido pela Direo da
empresa, deveria ser o de fornecer aos seus clientes recursos
que maximizassem a sua produtividade e melhorassem a sua
experincia com o produto.
Alm de partir dessa definio bastante abrangente, era esperado um ciclo de desenvolvimento de 18 a 24 meses. Como
a ltima verso do produto havia sido lanada havia mais de
dois anos, o ciclo total superaria os quatro anos, uma demora
que vinha sido percebida pelos clientes como incapacidade da
empresa de criar novos produtos. Esperar o final do projeto
para fazer a sua divulgao, como havia sido feito nos lanamentos anteriores, poderia causar uma evaso expressiva da
base de clientes.
Nesse cenrio, a empresa resolveu aplicar o conceito do
desenvolvimento iterativo, concebido apenas para controlar
internamente o andamento dos projetos, tambm para definir o produto junto aos seus clientes. Para isso, foi criado o
programa AltoQi Eberick Next, um conjunto de 8 Releases,
com durao de 2 a 3 meses cada. O conjunto desses projetos
tinha por objetivo a criao da nova verso do produto AltoQi
Eberick, atravs de um modelo de planejamento progressivo.
Foi definido, apenas em alto nvel, o escopo do produto completo. Foi planejado o primeiro Release, contendo os recursos
considerados mais prioritrios pela equipe, e pr-definido o
escopo do Release 2 mas, para os demais, ainda seria aguardado o retorno dos clientes (ver Figura 9).
Figura 9. Planejamento progressivo
Cada um desses Releases deveria ser concebido como um

projeto independente, ao final do qual o incremento do produto estaria completo, com os recursos selecionados tendo
sido completamente especificados, implementados e testados.
Ao final de cada Release, deveria existir um Produto parcial
completamente estabilizado, de forma a poder ser enviado para
a base de usurios participantes do programa Eberick Next.
Cada cliente participante desse programa estaria habilitado a
receber as verses intermedirias do produto, com a possibilidade de aplic-las imediatamente nos seus projetos, sem as
restries de uma verso beta. Essa proposta, evidentemente,
s foi viabilizada pelo investimento que havia sido feito pela
empresa, nos dois anos anteriores, na criao da sua base de
testes automatizados.
Alm da liberao de verses intermedirias do produto, a
empresa decidiu criar um ambiente de colaborao com seus
usurios, na forma de um blog de desenvolvimento, o Blog
Eberick Next. Nesse blog, eram publicados os recursos do projeto, conforme eram desenvolvidos, permitindo o feedback dos
clientes mesmo antes do fechamento do Release. Isso permitia
discutir com os clientes acerca dos critrios adotados e coletar
opinies a respeito de recursos que estavam planejados para
os prximos releases (ver Figura 10).
No perodo de Abril/ 2009 a Novembro/ 2010, o Blog do
Eberick Next teve 150 posts publicados, os quais foram acompanhados por 826 profissionais registrados, em mais de 72.000
visualizaes, os quais deixaram mais de 5.600 comentrios,
todos tratados pela equipe de desenvolvimento do produto.
Resultados obtidos
Pode-se afirmar que o projeto Eberick Next foi um sucesso.
A iniciativa de dividir o produto em Releases funcionais,
disponveis para os usurios, bem como o estabelecimento
do Blog de desenvolvimento, pode ser avaliada sob diversas
perspectivas:
Do ponto de vista dos clientes, a oportunidade de participar
da definio dos rumos do projeto foi muito bem acolhida.
19
Figura 10. Blog do Eberick Next
Mesmo os clientes que no participaram

diretamente do projeto Next reportaram
sentir-se mais confiantes com a empresa
e com o produto, por saber que teve a
contribuio de outros usurios.
Do ponto de vista da equipe de Desenvolvimento, garantiu um feedback
antecipado para o projeto, resultando em
um produto de qualidade superior e uma
elevao do moral do grupo.
Do ponto de vista da equipe Comercial, a divulgao prvia e continuada
do produto, ao longo do seu desenvolvimento, facilitou bastante o posterior
trabalho de argumentao comercial,
mesmo junto a clientes que no haviam
participado do projeto Next.
Do ponto de vista da equipe de Marketing, essa iniciativa levou a um fortalecimento da marca e da imagem da
empresa perante os seus clientes.
muito melhor essas necessidades depois

de experimentar parte do produto j
concludo.
Ao final, mais importante do que demonstrar a aplicao dos conceitos do
desenvolvimento iterativo para a Direo da empresa, com o feedback positivo
dos clientes participantes dessa iniciativa, foi o resultado comercial obtido pelo
produto. Aps completar os oito Releases, o produto foi oficialmente fechado
como AltoQi Eberick V7 e lanado
comercialmente a toda a base de clientes
da empresa. Dos 826 profissionais que
participaram, mais de 600 efetuaram
imediatamente a migrao para a verso
V7. Outros 220 profissionais que no
participaram do projeto Next tambm
adquiriram a licena no lanamento,
apenas pelo histrico desse projeto.
interessante comentar que o desenvolvimento desse produto partiu de

um banco de cerca de 300 solicitaes
registradas e pde materializar 60
novos recursos no programa mas, ao
final, a lista de solicitaes registradas
j superava 650. Cerca de metade dos recursos desenvolvidos nem estava na lista
original de necessidades. Isso ressalta
a importncia de conhecer as necessidades atuais dos clientes e ilustra o fato
de que os clientes conseguem expressar
O projeto Eberick Next teve como foco

a preocupao da empresa pela melhoria dos produtos e servios oferecidos.
Como apoio melhoria interna do processo de desenvolvimento, a empresa
optou por alinhar essa iniciativa com
um modelo destinado especificamente
ao mercado de desenvolvimento de software brasileiro, o MPS.BR (modelo de
Melhoria de Processos de Software Brasileiro), baseado nas normas NBR ISO/
IEC 12207, ISO/IEC 15504 e no modelo
20
Avaliao MPS.BR
internacional de melhoria de processos

de software CMMI-DEV, com o objetivo
de guiar a melhoria dos processos das
micro, pequenas e mdias empresas do
mercado de software brasileiro.
O modelo MPS.BR define 7 nveis de
maturidade de processos: A (em otimizao), B (gerenciado quantitativamente),
C (definido), D (largamente definido), E
(parcialmente definido), F (gerenciado)
e G (parcialmente gerenciado). A escala
de maturidade se inicia no nvel G e
progride at o nvel A. Em cada um dos
nveis, h um conjunto de processos que
indicam onde deve ser feito o esforo de
melhoria. Os nveis so cumulativos,
o que significa dizer que uma organizao aprovada no nvel F possui as
capacidades de ambos os nveis F e G
(ver Figura 11).
Conforme colocado no decorrer deste artigo, a melhoria de processos no
Departamento de Desenvolvimento da
AltoQi algo que vem sido trabalhado
desde 2007, at chegar ao modelo de
desenvolvimento iterativo implantado
em 2009, o qual ganhou destaque com
o desenvolvimento do Blog do Eberick
Next. A formalizao dos procedimentos foi uma necessidade que a empresa
observou no caminho de ampliao
da sua equipe e fortalecimento do
Departamento.
No final do ano de 2009, usando
como piloto o prprio projeto Next, a
empresa resolveu buscar para si essa
certificao de qualidade, validando
o investimento em processo que havia sido feito e visando posicionar a
empresa no incio dessa jornada em
direo excelncia. O primeiro passo
foi a implantao do nvel G do MPS.
BR, o qual envolve as reas de Gerncia
de Projetos e Gerncia de Requisitos.
Esse trabalho transcorreu durante um
ano e culminou em uma avaliao
impecvel, ao final de 2010.
O sucesso nessa avaliao vem trazendo diversos benefcios empresa, mas o
atendimento s melhores prticas do desenvolvimento de software o principal
fator a ser considerado, resultando em
projetos mais eficientes e organizados,
com benefcios diretos para os usurios
dos produtos AltoQi.
agilidade
O mesmo processo que permitiu empresa a adoo de um

modelo de desenvolvimento colaborativo pde ser avaliado,
com sucesso, no nvel G do MPS.BR.
Espera-se que este relato de experincia possa auxiliar outras
empresas a definir seu prprio caminho rumo melhoria contnua no seu processo de desenvolvimento e na maximizao
dos resultados dos seus projetos.
Referncias
BONA,Cristina. Avaliao de Processos de Software:Um Estudo de Caso em XP e ICONIX. Dissertao
de Mestrado em Cincias da Computao. Universidade Federal de Santa Catarina, 2002.
COHN, Mike. Agile Estimating and Planning. Prentice Hall, 2005.
KRUCHTEN, Philippe. The Rational Unified Process, An Introduction. 2 ed. Reading,

Massachusetts: Addison-Wesley, 2000.
MPS.BR (Melhoria de Processo do Software Brasileiro). Guia Geral. Sociedade SOFTEX, 2009.
_____. Guia de Implementao Parte 1: Fundamentao para Implementao do Nvel G
do MR-MPS. Sociedade SOFTEX, 2009.
MYERS, Glenford J. et al. The Art of Software Testing. 2 ed. John Wiley & Sons, 2004.
NESMA (Netherlands Software Metrics Association). Definitions and counting guidelines for
the application of function point analysis. NESMA Manuals, 2004.
PMI (Project Management Institute). PMBOK (Project Management Body of Knowledge) - Um
Guia do Conjunto de Conhecimentos em Gerenciamentos de Projetos. 2004.
SCHWABER, Ken. Agile Project Management with Scrum. Redmond, Washington: Microsoft
Press, 2004.
VASQUEZ, Carlos Eduardo. Estimativas de Software Fundamentos, Tcnicas e Modelos... e o
principal, integrando tudo isso. Apresentao realizada na Engenharia de Software Conference.
DevMedia, 2009.

Feedback
eu
21
sobre e
s
Na rea de desenvolvimento de software, muitos so os

fatores que determinam o sucesso de um empreendimento.
Certamente, sem a inspirao para a criao de um produto
ou servio diferenciado, ou sem contar com as pessoas adequadas e motivadas para o desenvolvimento do produto, no
provvel que a empresa possa colher bons resultados. Mesmo
o melhor dos processos no garantiria o sucesso dos projetos.
Por outro lado, a adoo de um processo inadequado pode,
certamente, minar a produtividade de uma equipe, desvi-la
dos objetivos do negcio e reduzir a moral da empresa como
um todo.
Neste artigo, foi mostrado como a aplicao de uma metodologia de desenvolvimento bem estruturada permitiu AltoQi
retomar o seu ritmo de crescimento e estabelecer uma nova
forma de interao com seus usurios. Todavia, adotar apenas
uma metodologia de gerenciamento como o Scrum no seria
suficiente. Para que isso fosse possvel, um investimento inicial
na adoo de boas prticas de Engenharia de Software, com
destaque para a automao dos testes, foi imprescindvel. Essa
experincia bem-sucedida validou o incio de um novo projeto,
nos mesmos moldes, e est sendo usada como base para todas
as demais linhas de produto da empresa.
Alm disso, comentou-se o fato de que, embora o processo de
desenvolvimento adotado tenha se baseado em metodologias
geis, isso no limitou, de forma alguma, a possibilidade de
certificar esse processo em relao a um modelo de maturidade.
JAKOBSEN, Carsten e JOHNSON, Kent. Mature Agile with a twist of CMMI. 2011.
http://jeffsutherland.com/scrumpapers.pdf
D
s
Concluses
edio
ta
Figura 11. Modelo MPS.BR
HAZAN, Cludia e VON STAA, Arndt. Anlise e Melhoria de um Processo de Estimativas de

Tamanho de Projetos de Software. 2005.
http://www.dbd.puc-rio.br/depto_informatica/05_04_hazan.pdf>
Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros
Fatores que influenciam a melhoria de processos

Um estudo sobre a primeira implementao e avaliao do modelo MPS do
Amazonas
Davi Viana dos Santos
davi.viana@gmail.com
Atua no ramo de implementao de programas de melhoria de processo de software tendo como base o programa MPS.
BR. Bacharel em Cincia da Computao
pela Universidade Federal do Amazonas
(UFAM), Mestre e Doutorando em Informtica pelo Programa de Ps-Graduao
em Informtica (PPGI) da mesma Universidade. Suas pesquisas so focadas em Engenharia de Software, principalmente em
Qualidade de Processo de Software.
Tayana Conte
tayanaconte@gmail.com
doutora em Engenharia de Sistemas e

Computao pela Universidade Federal do
Rio de Janeiro (2009) e Professora Adjunto da Universidade Federal do Amazonas,
onde atua em cursos de graduao e psgraduao. implementadora e avaliadora
oficial do modelo de Melhoria do Processo
de Software Brasileiro (MPS.BR), participando tambm da Equipe Tcnica do
Modelo (ETM). Tem experincia na rea
de Cincia da Computao, com nfase em
Engenharia de Software, atuando principalmente nos seguintes temas: Engenharia
de Aplicaes Web, Avaliao de Usabilidade, Engenharia de Software Experimental,
Usabilidade de Aplicaes Web e Qualidade
de Software.
22
Resumo:
O objetivo do artigo apresentar como ocorreu a primeira implementao e avaliao de uma iniciativa
de programa de Melhoria de Processo de Software
no Estado do Amazonas, assim como apresentar os
principais Fatores Crticos de Sucesso que influenciaram esta iniciativa pioneira no Estado.
No artigo discute-se como foi realizada a primeira

implementao e avaliao de um programa de
Melhoria no Amazonas. Ao apresentar o contexto destas empresas e seus fatores de influncia,
espera-se que mais empresas se sintam motivadas
a realizar este tipo de iniciativa, uma vez que traz
benefcios para as organizaes, como a maior competitividade. Os fatores de influncia apresentados
neste artigo devem ser utilizados cuidadosamente
durante a implementao de novos programas de
Melhoria, visando sempre melhorar o desempenho
das organizaes.

Os fatores que influenciaram na implementao e
avaliao da iniciativa de MPS podem ser utilizados como parte da estratgia de implementao
de iniciativas de melhoria em empresas de contexto semelhante, de modo que a verificao desses
fatores pode ajudar na rpida execuo do programa de melhoria.
uando h uma preocupao

maior com a qualidade do processo possvel ter mais produtividade na organizao, maior competitividade em relao s outras empresas
do mesmo segmento, diminuir o esforo
e custo dos projetos e lidar com questes
crticas relacionadas ao tempo de lanamento de produtos comerciais [7].
Porm, o sucesso de programas de MPS
depende de diversos fatores tcnicos
Engenharia de Software Magazine - Fatores que influenciam a melhoria de processos
e fatores sociais que, segundo [8], so

questes socio-tcnicas, relativas
conduo das iniciativas de melhoria e
interao entre seus participantes (ver
Figura 1).
Para auxiliar no direcionamento de
adoo de programas de MPS, de
grande relevncia o desenvolvimento
de pesquisas que apresentem condues de estudos qualitativos. Pesquisas
qualitativas possibilitam identificar e
processo
Figura 1. Fatores tcnicas e sociais
compreender, em detalhes, os diversos fatores que influenciam diretamente iniciativas de melhoria de processo de
software e da relao dos colaboradores com esses fatores,
pois todo o processo de desenvolvimento dependente do
comprometimento humano [10]. Apesar de haver diversos
estudos abordando fatores em MPS [5], o nmero de pesquisas que visam analisar qualitativamente as influncias
nos programas de melhoria ainda est aqum do necessrio
para permitir uma ampla compreenso desses fatores em
diversos contextos [4].
Este artigo descreve um estudo qualitativo da primeira
iniciativa de implementao e avaliao de MPS no Estado do
Amazonas, com o propsito de identificar quais os fatores de
influncia no programa de MPS, do ponto de vista dos colaboradores das organizaes envolvidas. O principal objetivo
deste artigo discutir os resultados do estudo proposto, na
qual se usou procedimentos de anlise qualitativa onde foram
analisados os dados das entrevistas.
Fatores de influncia na literatura

As questes que exercem influncia sobre as iniciativas de
implementao de melhoria de processos de software vm
sendo objeto de estudos nas ltimas dcadas [6]. O propsito
desses estudos obter um melhor entendimento sobre as questes que influenciam iniciativas de melhoria de processo de
software, bem como suas interaes, causas, efeitos e formas
de tratamento. Essas questes so comumente denominadas
de Fatores Crticos de Sucesso (FCS).
Montoni e Rocha (2007) apresentam uma metodologia para
identificao de fatores crticos de sucesso em iniciativas de MPS,
com esta metodologia eles conseguiram perceber os seguintes
fatores: (1) os fatores de ambiente (a capacidade dos ambientes
organizacionais de estabelecer e manter iniciativas de MPS, onde
essa medida pode ter dois pontos de vista: o indivduo e a organizao); (2) o fator de eficincia da estratgia de implementao
do MPS (garantir que os colaboradores da organizao tenham
conhecimento a respeito dos potenciais benefcios que podem
ser alcanados); (3) o fator correspondente do quo slido o
programa de MPS implementada (se realmente houve mudana
na cultura da organizao); (4) o fator do quanto a alta gerncia
est comprometida com o programa de MPS; e (5) medido o
fator de aceitao do programa de MPS e o quanto os colaboradores esto motivados com o mesmo.
A importncia da cultura organizacional como fator de
influncia nos processos de software em organizaes
analisada em [3]. Segundo os autores, a cultura organizacional

reconhecida como um fator crtico de sucesso, porm pouco
explorada qualitativamente. Como resultado do estudo de caso
executado, os autores apontaram que o perfil cultural de uma
organizao influencia a institucionalizao dos processos de
software. O mesmo estudo identificou e avaliou a aplicao
de recomendaes para mudana de cultura organizacional
de forma a aprimorar a institucionalizao de processos de
software.
A aplicao prtica de processo de software e a adoo de
modelos de melhoria de processo de software so discutidas
em [2]. Os pesquisadores utilizam GT (grounded theory) para
apresentar que os processos de software empregados na indstria Irlandesa so processos proprietrios e, normalmente, so
adaptados ao contexto da empresa. Por fim, observado que
h certo tipo de resistncia na implementao de programas
de MPS, por parte dos gerentes, devido aos custos que essas
atividades podem gerar, alm de aumentar a documentao
e burocracia.
A investigao de fatores socioculturais de influncia em programas de melhoria abordada em [6], do ponto de vista dos
consultores das organizaes de consultoria. Utilizando GT,
foi possvel identificar trs contextos que exercem diferentes
tipos de influncia no programa de MPS, so eles: Contexto
individual; Contexto Organizacional e Contexto Tecnolgico.
Por fim, tambm foram identificadas as aes que representam
as interaes entre os colaboradores e os diferentes contextos
abordados no trabalho.
Estratgia de implementao das iniciativas de

Melhoria de Processo no Amazonas
Embora no Brasil j existam mais de 200 empresas avaliadas
pelo Programa MPS.BR (Figura 2), somente em 2010 o estado
do Amazonas teve suas trs primeiras organizaes avaliadas,
atravs de incentivos do Programa AmazonSoft.
Figura 2. O programa MPS.BR em nmeros.
23
A estratgia de implementao do programa de melhoria foi

definido de acordo com as etapas descritas na Figura 3.
Inicialmente foram selecionadas cinco empresas que iriam
compor o grupo do programa de implementao do MPS. Estas empresas esto incubadas no Centro de Desenvolvimento
e Incubao Empresarial (CIDE) pertencente ao programa
prioritrio AmazonSoft.
A etapa do diagnstico inicial visou verificar a aderncia do
processo de desenvolvimento atual das empresas em relao
ao exigido pelo nvel G do MPS.BR. Em seguida foi realizada
uma apresentao da situao atual de todas as empresas, de
modo a analisar quais os principais resultados que deveriam
ser trabalhados.
Na fase de gesto do processo atual, os consultores definidos
pelo programa de melhoria juntamente com os responsveis
pelas empresas verificaram a melhor forma de adaptar o processo corrente para contemplar todos os requisitos necessrios,
de maneira que o impacto na forma de trabalho conhecida
fosse o mnimo possvel.
Para que os processos fossem empregados por todos os colaboradores das empresas foi necessrio fornecer treinamentos
para os mesmos a fim de diminuir o esforo na abordagem dos
processos nas empresas. Nesta etapa os consultores tambm
realizavam visitas peridicas nas empresas para verificar se
a adequao e gerao dos artefatos estavam sendo realizadas
para o projeto de desenvolvimento piloto.
empresas necessitavam de mais um projeto, pois indicadores

importantes foram coletados de maneira equivocada, logo uma
empresa voltou para a fase de abordagem dos processos e a segunda empresa decidiu no realizar a avaliao at o momento.
A empresa que havia voltado para a fase de abordagem dos
processos tambm decidiu por sair do programa de melhoria
pelo fato de faltar projeto para utilizar na avaliao. Por fim,
apenas trs empresas continuaram a preparao para a avaliao oficial. Na fase final, foram realizados os ltimos ajustes
necessrios para a avaliao oficial, tais como: contratao da
avaliao e preparao da planilha de indicadores.
Na prxima seo apresentado como foi conduzido o estudo qualitativo que teve a finalidade de verificar os possveis
fatores de influncia no programa de melhoria realizado nas
trs empresas que realizaram a avaliao oficial.
Estudo qualitativo
Atravs de um estudo qualitativo identificou-se os fatores
crticos de sucesso deste tipo de iniciativa com a finalidade de
obter uma maior compreenso das influncias desses fatores
para um programa de melhoria. Este tipo de anlise se faz
necessria, pois a implementao de iniciativas de melhoria
de processo de software representa um grande desafio devido
aos diversos fatores que influenciam no processo [8].
O estudo qualitativo foi realizado junto aos colaboradores
das trs empresas. Os papis desempenhados pelos mesmos
foram de programadores, analistas e gerentes dos projetos
utilizados na avaliao. Analistas e gerentes de projeto tinham
mais potencial de explorao de fatores devido aos processos
que foram implementados nas empresas (gerncia de projetos
e gerncia de requisitos). Por fim, o estudo foi dividido em trs
grandes etapas: Planejamento, Execuo e Anlise/Resultados,
conforme descrito na Figura 4.
Planejamento do Estudo
Figura 3. Etapas do programa de implementao do MPS.BR pelo

AmazonSoft
Na etapa de maturao, a empresa possua um acompanhamento mais direcionado dos consultores, pois todas as
atividades realizadas iriam compor a planilha de avaliao
e o processo de institucionalizao do processo em toda a
organizao. Cada empresa definiu seu processo de desenvolvimento, desta maneira foi possvel diminuir a resistncia
por parte dos colaboradores.
A avaliao simulada foi realizada com a finalidade de verificar quais empresas possuam indicadores suficientes para
uma avaliao oficial. Nesta fase, foi possvel verificar que duas
24
Na primeira etapa, tem-se a atividade de caracterizao do

estudo qualitativo que corresponde anlise dos fatores de
influncia no primeiro programa de melhoria realizado no
Amazonas. Os resultados deste estudo podem servir de auxlio
para futuras implementaes de MPS que possuem um contexto
semelhante. No Planejamento tambm especificado o objetivo
do estudo que diz respeito a cerca de analisar o programa de Melhoria de Processo de Software em relao aos fatores crticos de
sucesso. Por fim, a ltima atividade desta etapa, descreve sobre
a definio os instrumentos de coleta e anlise de dados.
Para realizar a coleta de dados optou-se por utilizar entrevistas semi-estruturadas baseadas questes abertas, pois
segundo Yin (2001), Entrevistas semi-estruturadas tem como
objetivo principal compreender os significados que os entrevistados atribuem s questes e situaes relativas aos temas
de interesse. Desta forma, pode-se investigar o ponto de vista
do colaborador a partir de suas afirmaes e compreender
os fatores que influenciaram o programa de melhoria. Nesta
atividade, definiram-se as questes iniciais do questionrio a
ser utilizado nas entrevistas.
processo
O mtodo de anlise qualitativa utilizado est baseado nos procedimentos

do mtodo Grounded Theory (ou Teoria
Fundamentada em Dados), que visa criar
uma teoria a partir dos dados coletados.
O mtodo GT descreve um conjunto de
procedimentos sistemticos de coleta e
anlise dos dados para gerar, elaborar
e validar teorias substantivas sobre
fenmenos essencialmente sociais, ou
processos sociais abrangentes [1].
Execuo do Estudo
A etapa de execuo corresponde
conduo das entrevistas nas empresas.
A Figura 5 apresenta um exemplo de
questo utilizada no estudo. Esta etapa
foi divida em duas fases: Durante a implementao do programa de melhoria
e Aps a avaliao oficial. Desta forma,
foi possvel obter dados referentes aos
dois momentos importantes do programa de melhoria.
Para as entrevistas, selecionaram-se
colaboradores que estavam envolvidos
com o programa de melhoria. Foi criado
um Termo de Consentimento Livre e Esclarecido (TCLE) para informar a respeito do procedimento e confidencialidade
da pesquisa e foram estimulados a falar
o mais livremente possvel. Os mesmos
foram entrevistados em relao definio e implementao do programa de
melhoria do processo de software em
suas organizaes. As entrevistas foram
realizadas individualmente e gravadas.
As questes utilizadas nas entrevistas
deste estudo foram baseadas nas questes definidas em [4]. Na 2 rodada de
entrevistas, o questionrio foi modificado com o propsito de aperfeioar o
questionrio para obter novos dados.
Aps a execuo das entrevistas, foi
realizada a transcrio na ntegra das
mesmas. Foram gerados documentos
individuais com todos os contedos gravados nas entrevistas, esses documentos
foram descaracterizados para preservar
a identidade dos colaboradores e utilizados na etapa de anlise e resultado.
Figura 4. Processo seguido para Planejamento, Execuo e Anlise do Estudo Qualitativo
questionrio como fonte inicial. Ao se

analisar os dados deste questionrio,
criou-se cdigos relacionados a trechos
do texto referentes implementao e
avaliao do programa de MPS (Figura 6).
Vrias interaes de comparaes foram
realizadas para a seleo de cdigos que
indicavam relatos representativos em
citaes no texto. Esta anlise refere-se
segunda rodada de entrevistas realizada, ocorrendo aps a avaliao oficial
do modelo MPS.
Iniciou-se ento a identificao dos
relacionamentos entre cdigos gerados,
gerando inter-relaes que agrupam
a natureza dos fatores envolvidos em
programas de MPS.
Anlise e Resultado
Resultados da anlise dos dados

qualitativos
Na ltima etapa do processo, os dados qualitativos desta pesquisa foram

analisados. Para isto, foi eleito um
Nas Figuras 7 e 8 so apresentados os

agrupamentos dos cdigos de acordo
com suas propriedades, formando assim
Figura 5. Exemplo de questo utilizada no estudo
conceitos que representam as categorias

(assinalados com [FCS]). Estas categorias
foram analisadas em conjunto com outros pesquisadores do grupo de pesquisa
Usabilidade e Engenharia de Software
25
(USES-UFAM) com o objetivo de proporcionar uma maior clareza sobre o

fenmeno em questo. Para a anlise dos
dados qualitativos, usou-se a ferramenta
Atlas.Ti (www.atlasti.com).
Na Figura 7 pode-se observar que
houve melhoria no processo de software
a partir da padronizao do processo
de desenvolvimento, pois todas as atividades para o programa de melhoria e
a documentao necessria foram bem
definidas pelos responsveis do programa de melhoria e do apoio da consultoria
externa. Esta padronizao possibilitou
a visualizao mais completa dos objetivos a serem alcanados com os projetos
de software.
Tambm pode ser observado que houve melhoria na qualidade do servio
prestado a partir da organizao dos

artefatos de software, assim como
melhoria na comunicao interna e na
interao com o cliente. Segundo um colaborador, isto foi percebido pelo cliente
a partir do momento que ele precisava
validar informaes para dar seguimento ao processo.
A resistncia em relao ao programa de melhoria por ser observada na
Figura 8. Os colaboradores julgaram as
atividades do programa de melhoria
muito trabalhosas e complicadas de
forma a necessitar de treinamento em
diversas atividades necessrias para o
programa de MPS. Um ponto importante
a ser notado que algumas decises da
diretoria desagradavam aos colaboradores envolvidos com o programa de
Figura 6. Codificao do trecho de uma entrevista
Figura 7. Representao grfica do FCS relacionado Padronizao do Processo
melhoria, como a definio estratgica

dos projetos/clientes utilizados para
ser apresentados na avaliao. Por fim,
os colaboradores tambm tinham que
desenvolver as atividades do dia-adia da empresa, desta forma algumas
atividades do programa de melhoria
se tornavam atividades secundrias,
como por exemplo, ter que atender uma
solicitao de mudana de requisito do
cliente sem antes realizar todo o registro de solicitao de mudana. Estas
influncias negativas foram superadas
com a determinao dos colaboradores
em alcanar o objetivo do programa de
melhoria.
Alm dos fatores j expostos, a seguir
sero apresentados outros fatores de
influncia identificados na pesquisa:
Apoio da consultoria externa A consultoria a responsvel por ministrar
os treinamentos, alm de auxiliar na
definio das atividades e de verificar
os artefatos gerados nos projetos;
Foco no programa de melhoria A
empresa disponibilizou uma pessoa
para ficar dedicada ao programa de
MPS dentro da organizao, alm disso,
a iniciativa se tornou um desafio, pois
nenhuma empresa no Estado ainda tinha
obtido o nvel, o que traria grande repercusso para as empresas avaliadas;
Conhecimento em qualidade de processo o conhecimento anterior que
determinados colaboradores possuam
em relao aos processos (GPR e GRE)
auxiliaram tambm na definio das
atividades;
Comprometimento da Equipe Tcnica
Devido ao foco dado ao programa de
MPS, percebeu-se o comprometimento
da equipe que estava executando a iniciativa dentro da organizao;
Organizao dos artefatos de software
Devido padronizao do processo, os
artefatos gerados ficavam mais organizados e de fcil acesso pelos interessados, isto mostrou aos colaboradores os
benefcios do programa de melhoria.
Consideraes finais
Figura 8. O FCS relacionado resistncia ao programa de melhoria
26
Esta pesquisa apresentou a conduo de

um estudo qualitativo com a finalidade
de identificar FCS no programa de MPS.
Para a realizao deste trabalho, foram
processo
sobre e
s

Feedback
eu
edio
ta
D
s
conduzidas entrevistas em organizaes de software pioneiras

na implementao do nvel G do MPS.BR no Amazonas.
Os procedimentos de anlise qualitativa so teis no sentido de buscar a essncia de determinado evento que, neste
trabalho, refere-se aos fatores de influncia relacionados a
iniciativas de programa de melhoria. Um programa de melhoria apresenta diversos fatores que podem influenciar no
sucesso ao final da implantao. Neste trabalho foi possvel
obter, atravs da anlise qualitativa, a compreenso de alguns
fatores que influenciaram a implementao e a avaliao do
modelo adotado.
A generalizao dos resultados dos trabalhos qualitativos
limitada pelo fato dos achados estarem relacionados diretamente ao contexto onde o estudo foi aplicado. Contudo, este
tipo de estudo relevante para o entendimento mais preciso
dos fatores de influncia estudados. Os fatores apresentados
podem ser utilizados durante a estratgia de programa de MPS
que possuem caractersticas semelhantes.
Referncias
Bandeira-de-Mello, R., Cunha, C. (2003).Operacionalizando o mtodo da Grounded Theory nas
Pesquisas em Estratgia: tcnicas e procedimentos de anlise com apoio do software ATLAS/TI.
Encontro de Estudos em Estratgia. Curitiba.
Coleman, G., OConnor, R. (2008).Investigating software process in practice: A grounded theory
perspective, Journal of Systems and Software, v. 81, n. 5
Fernandes, P. G., Oliveira, J. L. (2010). Perfil Cultural e Institucionalizao de Processos de
Software: Estudo de Caso em Duas Organizaes de Software.WOSES 2010.
Matos, O., Secatti, V., Santos, D., Oliveira, H., Conte, T. (2010). Aplicando Grounded Theory
para Compreender os Fatores Crticos de Sucesso em Iniciativas de Melhoria de Processo de
Software.WOSES 2010.
Montoni, M, Rocha, A. (2007). A Methodology for Identifying Critical Success Factors that
Influence Software Process Improvement Initiatives: An Application in the Brazilian Software
Industry, EuroSPI 2007, LNCS 4764, pp. 175-186.
Montoni, M, Rocha, A. (2010). Aplicao de Grounded Theory para Investigar Iniciativas de
Implementao de Melhorias em Processos de Software. In: Anais do IX SBQS, pp 167-181
Rocha, A. R. et al. (2005). Fatores de Sucesso e Dificuldades na Implementao de Processos de
Software Utilizando o MR-MPS e o CMMI, Pro Quality Qualidade na Produo de Software.
Santana, A. (2007).Problemas em Iniciativas de Melhoria de Processos de Software sob a tica
de uma Teoria de Interveno. Dissertao de Mestrado. Universidade Federal de Pernanbuco.
Maro 2007.
Santos, D., Rabelo, J., Mar, C., Aguiar, E., Wagner, P., Vilela, D., Conte, T., 2010, Resultados de
um Estudo Qualitativo sobre a implementao do modelo MPS em empresas do programa
AmazonSoft. In: VI Workshop Anual do MPS (WAMPS 2010), pp. 138-147, Campinas, SP, 2010.
Seaman, C. B., 2008, Qualitative Methods. In: SHULL et al. (eds.), Guide to Advanced Empirical
Software Engineering, Chapter 2, Springer
27
Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros
Testes exploratrios: Teoria e Prtica

Carlos E. L. de Sousa
carlos.eduleal@gmail.com
Graduando em Anlise e Desenvolvimento

de Sistemas na Faculdade de Cincias, Letras e Filosofia de Caruaru (FAFICA). Estagirio do Escritrio de Projetos da FAFICA,
atuando na rea de Engenharia de Teste e
Anlise de Requisitos.
A atividade de teste de software um dos meios utilizados para garantir a qualidade do sistema, evitando
assim surpresas desagradveis em relao ao resultado final da aplicao. O teste parece ser uma coisa
simples e emprica, mas na verdade no . E as falhas,
muitas vezes, acontecem por no darmos a devida
importncia a esse fato. Neste contexto, abordamos
neste artigo a definio e utilizao de testes exploratrios, mostrando suas vantagens e desvantagens.
Luana P. F. de Menezes
luanapfmenezes@gmail.com
Graduanda em Anlise e Desenvolvimento

de Sistemas na Faculdade de Cincias, Letras e Filosofia de Caruaru (FAFICA). Estagirio do Escritrio de Projetos da FAFICA,
atuando na rea de Engenharia de Teste e
Anlise de Requisitos.
Rodrigo F. Lopes
digolopes@gmail.com
Mestre em Cincia da Computao pelo

Centro de Estudos e Sistemas Avanados
do Recife (C.E.S.A.R). Integrante do grupo
de pesquisa HASE Human Aspects in Software Engineering. Na FAFICA, professorcoordenador dos cursos de graduao e psgraduao em Tecnologia da Informao.
Roberta M. M. Bezerra
roberta_moraes5@hotmail.com
Graduanda em Sistemas de Informao pela
Universidade de Pernambuco (UPE), desde
2008. Estagiria do Escritrio de Projetos da
Faculdade de Filosofia, Cincias e Letras de
Caruaru (FAFICA), atuando nas reas de Engenharia de Software e Anlise de Requisitos.
28

Testes exploratrios so extremamente teis para
encontrar bugs rapidamente, e quando o projeto
no tem uma documentao bem definida ou a
mesma encontra-se desatualizada. O que precisamos, hoje, mostrar a importncia desses testes,
A. Csar C. Frana
cesarfranca@gmail.com
Mestre em Cincia da Computao pela Universidade Federal de Pernambuco e Doutorando em Cincia da Computao pela mesma
instituio, bolsista CNPq. Integrante do grupo
de pesquisa HASE Human Aspects in Software Engineering. Autor do livro Um estudo
sobre motivao em integrantes de equipes
de desenvolvimento de software, da Ed. UFPE,
2010. Na FAFICA, professor-pesquisador de
diversas disciplinas relacionadas Engenharia
de Software.
Engenharia de Software Magazine - Testes exploratrios: Teoria e Prtica
para garantia de qualidade dos sistemas. E isso s

possvel introduzindo-se mtodos para auxiliar
no planejamento e especificao dos mesmos,
pois o teste um item fundamental para o desenvolvimento de sistemas.
Resumo
A atividade de teste muitas vezes vista como uma
fase de crtica aos analistas e programadores, fazendo com que estes se sintam constrangidos. Mas,
se os erros existem, o fato de no se fazer os devidos
testes no quer dizer que eles iro desaparecer e,
muitas vezes, se esses erros so detectados tardiamente podem causar prejuzo e danos incontrolveis aos sistemas. Dentre os vrios tipos de testes
existentes, neste artigo vamos definir, contextualizar, citar as vantagens e desvantagens e mostrar a
aplicabilidade dos testes exploratrios.
este de software uma disciplina

reconhecidamente importante da
engenharia de software. Mesmo
cientes da importncia desta disciplina,
alguns desenvolvedores acabam ignorando propositalmente as atividades
de testes, ou relegando-as para o final
do projeto. Isto pode acontecer simplesmente por estes desenvolvedores no
compreenderem bem os procedimentos
relacionados disciplina de testes.
Em organizaes maduras as atividades
Teste d e Software
de testes so realizadas com muito cuidado, pois a qualidade

do produto final est diretamente associada a como os testes
sero executados. O processo de testes deve ser a base para as
atividades de garantia da qualidade do produto em uma organizao, coordenando assim a forma como todas as atividades
de testes sero executadas.
Existem vrias definies para este conceito de teste de software. Segundo Patton (2005), por exemplo, teste de software
a ao de encontrar bugs, encontr-los o mais rpido possvel
e garantir que os mesmos sejam corrigidos. Naturalmente,
devemos entender que um bug um defeito, falha ou algo
que no est se comportando como esperado. Em outras palavras, testar um processo que engloba todas as atividades
do ciclo de vida voltadas para o planejamento, preparao e
avaliao dos produtos de software e produtos de trabalhos
relacionados, a fim de determinar se eles satisfazem os requisitos especificados.
A partir destes conceitos, possvel perceber a importncia
dos testes no ciclo de vida de um software. ele quem avalia
se requisitos relacionados a escopo e qualidade do projeto
foram satisfeitos e, consequentemente, se o produto est apto
para ser utilizado. Dentre os tipos de testes mais conhecidos,
destacam-se os testes de usabilidade, testes unitrios e os testes
de carga e de desempenho.
O objetivo deste artigo aprofundar-se no uso dos testes
exploratrios. Embora no definidos nos planos de testes,
importante deixar claro que os testes exploratrios tambm
seguem um processo, e representam uma estratgia til para
encontrar rapidamente os defeitos quando se sabe pouco sobre
o produto, existe pouca documentao ou esta est desatualizada. Seus riscos, desvantagens e deficincias tambm sero
tratados ao longo deste artigo.
Sero apresentados os principais conceitos, tcnicas e dificuldades encontradas nos testes exploratrios. Para isso,
inicialmente teremos uma discusso sobre o estado da arte
de testes exploratrios. Em seguida apresentado um estudo
comparativo entre testes exploratrios e testes ad-hoc. Dando
prosseguimento discusso, abordaremos a importncia de
testes exploratrios em metodologias geis e, por fim, algumas
concluses gerais so apresentadas.
Testes exploratrios
Um teste exploratrio de software uma poderosa e abrangente abordagem, mas por vezes, confundido com o teste adhoc. Testes so executados naturalmente e involuntariamente
por qualquer usurio de um determinado software. Porm,
para estes testes serem considerados exploratrios, deve-se
existir um propsito para tal execuo. Tipos de teste como este
requerem bastante prtica dos envolvidos no projeto. Como
citaram (Braga e Pretz) o teste exploratrio se baseia na intuio
e depende do conhecimento, habilidade e experincia do testador.
Criatividade tambm uma caracterstica necessria para
a execuo de testes exploratrios, pois este no segue uma
padronizao, roteiro, ou passo-a-passo pr-definido em documentaes. Uma vez que iniciado o teste, o testador precisa ter
originalidade para execut-los simultaneamente no momento

em que explora o produto.
Percebe-se geralmente que o uso de testes exploratrios presente em projetos sem documentao bem definida, ou projetos
geis, onde no existem documentos formais de requisitos e
quando no existe um conhecimento prvio sobre o aplicativo
que ser testado. Dentre as razes existentes para a realizao
de testes exploratrios, destacam-se as seguintes:
Realizao de testes quando no existem requisitos;
Rea l i zao de testes qua ndo ex iste pouco tempo
disponvel;
Realizao de testes quando no se conhece o aplicativo a
ser testado;
Realizao de testes em ambientes pouco testados pelos
testes convencionais;
Identificao dos passos para tentar reproduzir um defeito
aleatrio;
Diagnstico de comportamentos inesperados;
Investigao de efeitos colaterais;
Investigao de defeitos semelhantes;
Medio de riscos;
Determinao de defeitos crticos rapidamente.
Os elementos de testes exploratrios so:
Explorao do produto: Descobrir e registrar os objetivos e
funes do produto, tipos de dados processados e as reas de
instabilidade. Sua capacidade de realizar explorao depende
de sua compreenso geral da tecnologia, a informao que voc
tem sobre o produto e seus usurios pretendidos e a quantidade
de tempo que voc tem que fazer o trabalho.
Design de Teste: Determinar estratgias de funcionamento,
observando e avaliando o produto.
Execuo de um teste: Operar o produto, observar seu comportamento, e usar essa informao para formular hipteses
sobre como o produto funciona.
Heurstica: Heursticas so diretrizes ou regras que o ajudam
a decidir o que fazer. Este procedimento emprega um nmero
de heursticas que ajudam a decidir o que deve ser testado e
como test-lo.
Resultados de reviso: Teste exploratrio um processo
orientado para resultados. Tudo est consumado uma vez
que voc tem produzido resultados que atendam os requisitos
especificados.
Como testador, voc deve estar preparado para explicar
qualquer aspecto do seu trabalho para o Gerente de teste,
mostrando como eles atendem aos requisitos documentados
no procedimento.
O resultado de uma sesso de teste exploratrio um conjunto
de notas sobre o produto, falhas encontradas, e o registro de
como o produto foi testado.
Testes Ad-hoc versus Testes exploratrios

Considere as situaes descritas na Tabela 1. Em alto nvel,
os exemplos retratam bem a diferena entre esses dois tipos
29
Situao A
Um turista resolve visitar uma cidade qualquer, escolhida arbitrariamente, sem qualquer planejamento
prvio.
Ao chegar nela, comea a explor-la superficialmente.
Passado certo tempo, o turista acabaria descobrindo acidentalmente os seus locais preferidos.
Situao B
Outro turista decide visitar a mesma cidade, mas este planejou detalhadamente a sua visita,
contando com dados prvios sobre a cidade, e a explorando por partes, uma de cada vez.
Este turista tambm determinou um tempo limitado para conhecer cada um dos pontos, para evitar
o cansao, e ao mesmo tempo estimular a ateno em cada detalhe.
Passado certo tempo, o turista pode eleger os seus locais preferidos entre todos os pontos da cidade.
Tabela 1. Situaes de exemplo
de teste. A Situao A representa uma metfora para os testes

ad-hoc, enquanto a Situao B representa uma metfora para os
testes exploratrios. Muitos testadores realizam testes ad-hoc
acreditando se tratarem de testes exploratrios, e vice-versa.
Graas a limitaes de tempo para o estudo do sistema e dos
planejamentos, eles acabam utilizando uma forma desorganizada de teste exploratrio. Por isso, comum observar algumas
crticas ao teste exploratrio.
Em outras palavras, o teste ad-hoc trata-se de um processo
improvisado, onde no existe nenhuma diretriz ou misso, e o
papel do testador interagir arbitrariamente com o software,
produto, ou o que quer que seja. A sua maior ferramenta a
liberdade do testador para conhecer e explorar o software.
Desta forma, os bugs vo sendo encontrados acidentalmente,
por acaso, de acordo com o entendimento do usurio sobre a
aplicao.
J no teste exploratrio, o processo deve ser fundamentado
em dados e planejamento. O testador deve realizar um estudo
antecipado do software, recolhendo os requisitos e/ou consultando outras fontes sobre o mesmo domnio da aplicao. Desta
forma, o testador poder predizer as reas de concentrao que
sero estabelecidas no planejamento, assim como o tempo para
a realizao dos testes. De forma estruturada e metdica, as
falhas caadas sero descobertas rapidamente. Porm, mesmo
que seja um teste exploratrio, a arbitrariedade e a criatividade
do testador no devem ser inibidas.
Teste exploratrio em metodologias geis

Em razo do rpido crescimento da indstria de software,
juntamente com o aumento da demanda por solues cada
vez mais robustas e, ainda, com requisitos mutveis, a busca
pela excelncia e melhoria contnua da qualidade de software tem sido aprimorada ao longo do tempo (Sommerville,
2007). Por isso, diversos mtodos, tcnicas e ferramentas
tm sido propostos e utilizados, buscando o aumento da
produtividade no desenvolvimento de software (Teixeira
e Delamaro, 2008).
Desse modo, a busca por melhores processos, visando o aumento da qualidade de software e a satisfao do cliente, fez
surgir as Metodologias geis, com a dinmica de processos
flexveis e adaptativos, abraando as mudanas como parte
inseparvel do seu processo de desenvolvimento. O conceito
de metodologias geis relativamente recente na engenharia
de software. A partir do Manifesto gil diversas metodologias e processos esto sendo criados e utilizados na indstria
seguindo os princpios e prticas geis. Segundo Ferreira e
Cohen (2008), as metodologias geis tm um grande suporte na
30
literatura, que defende que essas diminuem a taxa de insucesso

no desenvolvimento de software. Mesmo assim, nenhuma
metodologia gil deve ser utilizada sem que a equipe saiba o
que est fazendo e acredite nesse propsito. Caso contrrio,
usar metodologia gil ser apenas uma desculpa para no
utilizar metodologia alguma.
Na maioria das metodologias geis a documentao possui
foco mnimo. Por isso, teste de software sempre uma questo
a ser discutida. A cobertura dos testes em relao aplicao
depender diretamente das tcnicas que sero usadas para
encontrar os bugs; existem vrias tcnicas de encontrar bugs,
mas nenhuma tcnica consegue garantir que todos os bugs
sejam encontrados. Teste de software apenas mais uma das
possveis tcnicas que podem ser aplicadas. Nenhuma tcnica consegue encontrar mais de 85% dos bugs (Patton, 2005).
O ideal combinar diferentes tcnicas para garantir que a
maioria dos bugs sejam encontrados o mais cedo possvel
(Patton, 2005).
A escolha de qual tcnica utilizar depende de diversos
fatores, tais como: o modelo utilizado nas especificaes
do sistema, a experincia dos engenheiros de teste, tipos de
defeitos normalmente encontrados no sistema, objetivo do
teste, documentao disponvel, tipos de risco, exigncias
do cliente, tipo do sistema, requisitos obrigatrios, tempo
e custo do projeto.
No existe uma tcnica melhor ou pior que a outra. Existem
tcnicas mais adequadas a determinadas situaes. Ento,
perguntar qual a melhor tcnica no a pergunta certa.
Cada tcnica boa para um conjunto de objetivos, e no se
aplicam para tudo em um projeto de desenvolvimento de
um software. Num mesmo sistema, varias tcnicas podem
ser aplicadas.
Dentro do contexto de metodologias geis, onde as principais caratersticas so: pouca especificao e curto prazo de
tempo para o projeto, a tcnica que mais se adequa, para uma
maior cobertura da aplicao so os Testes Exploratrios.
Alguns testadores podem no concordar, a partir do teste
exploratrio o testador poder executar e criar testes ao
mesmo tempo em que explora a aplicao. Com isso, economizar tempo, e mesmo que a documentao seja mnima,
ele ter algo que possa ser usado. Dessa forma, por mais
que os testes no possam ser realizados da maneira devida,
a quantidade de bugs crticos ser praticamente a mesma,
pois como j dito, testes exploratrios acabam por criar outras baterias de testes e assim por diante. Assim, podemos
concluir que possvel conciliar testes a metodologias geis,
sem que a metodologia deixe de ser to gil assim.
Engenharia de Software Magazine - Testes exploratrios: Teoria e Prtica
Teste d e Software
Concluso
Referncias
BRAGA, Karen; PRETZ, Eduardo. Conhecimento e Teste Exploratrio: um modelo de captao

e Execuo
http://tconline.feevale.br/tc/files/6163_40.pdf
TEIXEIRA, V. S. and DELAMARO, M. E. 2008. Gerao de Metadados para o Apoio ao Teste
Estrutural de Componentes. VII Simpsio Brasileiro de Qualidade de Software,SBQS08,
Florianpolis, SC, Brasil, 2008, 406-419.
FERREIRA, C. and COHEN, J. 2008. Agile systems development and stakeholder satisfaction: a
South African empirical study. Annual Research Conference of the South African institute of
Computer Scientists and information Technologists on IT Research in Developing Countries:
Riding the Wave of Technology, SAICSIT 08, vol. 338. ACM, New York, NY, 48-55.
PATTON, Ron. 2005. Software Testing. ISBN: 0-672-32798-8
SOMMERVILLE, I. 2007.Engenharia de Software. 8. Ed. PEARSON. ISBN 8588639289.
sobre e
s

BECK, K. et al. 2001.Manifesto for Agile Software Development.

http://agilemanifesto.org
Feedback
eu
edio
ta
D
s
Teste exploratrio uma alternativa simples para auxiliar

no processo de garantia da qualidade de um projeto de software. Eles abrangem pensamentos do testador, fazendo com
que ele no pense de uma forma limitada sobre determinada
funcionalidade do sistema. Entretanto, necessrio um bom
planejamento e um acompanhamento para que o teste encontre
suas finalidades de uma forma aleatria, porm, organizada
para que no seja confundida com testes ad-hoc.
Para metodologias geis o tipo de teste que foi explicado nesse
artigo possui alta adequao, pois combina com o contexto
de como mtodos geis tratam os processos de software: com
pouca documentao formal e muito conhecimento sobre a
aplicao, que resumem bem os motivos para o uso de testes
exploratrios.
31
Planejamento e Gerncia
Nesta seo voc encontra artigos voltados para o planejamento
e gerncia de seus projetos de software.
Anlise de pontos de funo na prtica

Este artigo vem para desmistificar o processo de
medio de software atravs do uso de APF (Anlise por pontos de funo), tratando o assunto de
forma objetiva e prtica, trazendo tona os seus
benefcios e esclarecendo pontos chave para o sucesso no seu uso.

O processo de mtrica de software de extrema
importncia para que possa haver clareza quanto
ao tamanho do software a ser construdo, mitigando os riscos decorrentes de estimativas feitas
de acordo com o feeling, sendo tambm til na
averiguao da performance do time de desenvolvimento e por partir do conceito de medio
Andrey Abreu
andreyabreu@gmail.com
Ps graduado em engenharia de software

pela universidade GAMA FILHO, graduado
em gesto estratgica de organizaes
pela UNISUL, 14 anos de experincia na
rea de TI, Diretor de Tecnologia da TheSource Solues de Software, empresa do
Grupo Opens.
32
omo diria o pai do ciclo PDCA

Wi l l ia m Edwa rds Dem i ng,
O que no pode ser medido,
no pode ser gerenciado. O PDCA um
ciclo de desenvolvimento que tem foco
na melhoria contnua, significa Plan ->
Do -> Check -> Act, ou Planejar, Fazer,
Verificar e Agir.
Muitas so as formas de se medir um
software, algumas mais e outras menos
Engenharia de Software Magazine - Anlise de pontos de funo na prtica
independente da tecnologia, permite uma clareza maior para os stakeholders.
Resumo
Trataremos nesse artigo uma das formas de medio de software dentre as diversas existentes.
Entenderemos que mais do que um simples mtodo, APF uma forma precisa de se medir software
sob a tica do negcio, sem quaisquer ligaes
com tecnologias, ferramentas ou linguagens.
Alm disso, uma forma de se medir produtividade e performance do time de desenvolvimento, e
veremos ao longo do desenvolvimento do assunto
que mais do que tudo isso, APF d transparncia
ao processo de medio e na viso de tamanho do
software.
precisas e metdicas, todas tem seus

prs e contras, porm o resultado mais
importante quando se fala em mtrica e
que pode ser encontrado em qualquer
mtodo de medio o fato de deixar de
lado o achismo. Trabalhar com mtricas
se basear no histrico de produo
individual de cada membro do time,
levar em conta a cultura e os agentes externos que podem influenciar no projeto,
mtrica
e mais do que tudo, poder contar com um norte num mundo

onde 44% dos projetos atrasam, conforme o Chaos Report do
Standish Group.
Voc poderia dizer, ok concordo que necessrio um processo formal de mtrica, mas qual o melhor mtodo para se
utiliza? Constantemente me deparo respondendo perguntas
desse tipo, seja em relao a mtrica, processo de gerenciamento de projetos, processo de desenvolvimento, etc. Minha
resposta sempre a mesma: o melhor mtodo o que resolve
o problema do seu negcio e que se encaixa na cultura da sua
organizao, no h um melhor ou pior, h o mais adequado
sua necessidade.
Aqui falaremos um pouco de APF (Anlise de Pontos por
Funo), que dentre os diversos mtodos existentes o que
mais se aproxima do nvel mais alto de um software (sua
especificao de negcio), e num tempo onde falamos que o
cliente parte do processo de desenvolvimento, nada mais
justo do que utilizar um processo de mtrica que esteja mais
prximo da sua compreenso. E nesse nvel, independente
de tecnologias, linguagem de programao e do achismo, que
aplicamos a anlise por pontos de funo. No objetivo desse
artigo falar sobre qual a melhor forma de se medir software,
ou at promover o APF em relao aos demais mtodos, mas
sim demonstrar quais as vantagens de se utilizar um processo
como a APF.
Um pouco de histria
Em 1979 quando Alan J Albrecht pesquisava sobre produtividade na IBM, surgiu a Anlise de Pontos de Funo (Function
Point Analysis), divulgada no seu artigo oficial em Outubro de
1979 sob o ttulo Measuring Application Development Productivity. APF foi oficializada atravs do padro internacional
ISO/IEC e regulamentada pelo CPM Counting Practices
Manual do IFPUG (que o International Function Point Users
Group, grupo responsvel por manter e normalizar a APF).
Se fossemos fazer uma analogia, o termo mais prximo que
podemos utilizar para resumir o que a APF seria o metro
quadrado do software, e podemos compar-la com a construo de uma casa, onde o construtor mede e precifica o custo
de construo baseado no seu tamanho. O mesmo acontece
com APF, medimos software com base no seu tamanho, porm assim como na construo civil, fatores externos alm da
medida devem ser avaliados, como se a casa ser construda
de madeira ou tijolos, ou ainda se ter um mesanino ou um
terrao, e com esse conjunto de fatores temos ento alm de
uma medida quantitativa (tamanho em m2 no caso da nossa
casa), uma medida qualitativa (fatores adicionais que sero
levados em considerao na construo).
A estrutura da APF
Para entendermos a lgica do processo de contagem, ilustramos na Figura 1 um fluxo que mostra a estrutura da APF.
Conforme pode ser visto na Figura 1, a APF possui cinco
componentes divididos em dois grupos, que interagem dentro
e fora da fronteira da aplicao, so eles:
Figura 1. Fluxo dos cinco componentes da APF interagindo
Componentes de Dados
Os componentes de dados representam as funcionalidades
fornecidas pelo sistema ao usurio para atender as necessidades referentes aos dados que o sistema ir manipular. Os
componentes de dados esto divididos em ALI e AIE:
Arquivos Lgicos internos (ALI): Um ALI representa um
grupo de dados mantido pela aplicao, por exemplo, uma
classe ou uma tabela de banco de dados, porm sem ligao
alguma com o meio de armazenamento. O tamanho de um ALI
definido de acordo com o nmero de campos e o nmero de
tipos de elementos de registros lgicos nele contidos.
Arquivos de Interface Externa (AIE): Um AIE representa um
grupo de dados mantido por uma aplicao externa, logo um
AIE identificado como um ALI em outra aplicao. Assim
como no ALI, o tamanho de um AIE identificado de acordo
com o nmero de tipos de elementos de registros lgicos.
O fator determinante do tamanho de um ALI e AIE est
nos tipos de elementos que so contados em cada funo
identificada:
Tipos de Elementos de Dados (TED): Campo identificado
pelo usurio, nico e no recursivo. Por exemplo: campos de
uma tabela.
Tipos de Elementos de Registros (TER): Subgrupo de dados
identificado pelo usurio. Por exemplo: Generalizao/Especializao de uma classe.
Componentes de Transao
Os componentes de Transao representam as funcionalidades de processamento dos dados fornecidos pelo sistema ao
usurio, ou seja, a manipulao dos componentes lgicos feita
por componentes de transao. Os tipos considerados so:
Consultas Externas (CE): Representam uma combinao de
entradas e sadas. As CEs fazem parte dos requisitos lgicos do
usurio. Como exemplo temos: consultas implcitas, verificao
de senhas e recuperao de dados com base em parmetros.
Entradas Externas (EE): Processo lgico que mantm os dados
em um ou mais ALIs. Uma entrada externa contada com
base no nmero de campos de dados dos usurios envolvidos
e na soma dos ALIs e AIEs participantes do processo. Como
exemplo temos: Cadastros em geral, Validaes, Frmulas
e clculos.
33
Sadas Externas (SE): Processo lgico

que gera dados para um usurio ou
aplicativo externo. Como exemplo temos:
Relatrios, Backups, Grficos.
Assim como nos componentes de dados, o fator determinante do tamanho de
um componente de transao est nos
tipos de elementos que so contados em
cada funo identificada:
Tipos de Elementos de Dados (TED):
Campo identificado pelo usurio, nico
e no recursivo. Por exemplo: campos de
uma tabela;
Tipos de Arquivos Referenciados (TAR)

Arquivos lgicos utilizados pela transao. Representam o total de ALIs /
AIEs contados.
Contando os pontos de funo

Agora que j conhecemos um pouco
da estrutura, vamos entender o processo
de contagem de pontos de funo. Para
isso, observe a Figura 2. Ela representa
uma viso geral da Anlise de pontos
por funo. Como pode ser observado,
a contagem de pontos de funo se d
em 7 passos
1. Determinar o tipo de contagem
O primeiro passo para se fazer a
contagem de pontos de funo de uma
aplicao elencar que tipo de projeto
estamos querendo contar dentre os trs
possveis:
Projeto de Desenvolvimento: Contagem de pontos de funo de uma aplicao nova, ainda no existente;
Projeto de Manuteno: Contagem de
pontos de funo de alteraes em uma
aplicao existente;
Projeto de Aplicao: Contagem de
pontos de funo de uma aplicao
existente, instalada e em uso.
O tipo de projeto que est sendo contado influenciar no clculo de ajuste dos
pontos de funo.
2. Identificar a fronteira da aplicao
A identificao da fronteira da aplicao indica a separao entre o projeto
a ser contado e os aplicativos externos,
ou seja, a definio do escopo da
aplicao.
de extrema importncia a correta
identificao da fronteira da aplicao
34
antes do incio da contagem, a fim de no

incorrermos no erro de contar funes
que no fazem parte do escopo ou deixar
de fora funes que deveriam fazer parte
do escopo.
3. Contar as funes de dados
Nesse ponto ser necessria a contagem de cada ALI e AIE, identificando
seu grau de complexidade (com base na
quantidade de TEDs e TERs), conforme
Tabela 1. Conforme podemos observar,
as variveis Tipos de Elementos de Dados e Tipos de Elementos de Registros
impactam na complexidade definida
para os Arquivos Lgicos Internos
(ALI) ou Arquivos de Interface Externa
(AIE).
4. Contar as funes de transao
Da mesma forma que as funes de
dados, as funes de transao CE (Consultas Externas), EE (Entradas Externas)
e SE (Sadas Externas) devem ser contadas com identificao de seu tamanho
de acordo com as Tabelas 2 e 3.
Tipos de elementos
de registros
5. Calcular pontos de funo no

ajustados (PFNA)
Todo ponto de funo considerado
no ajustado ou bruto por haver variao
quanto ao tipo de sistema implementado,
ambiente de uso e outras variveis que
podem influenciar no seu tamanho.
Com base na contagem obtida nos
itens 3 e 4, devemos contar os PFNAs
(Pontos de funo no ajustados), que
a contagem bruta dos pontos de funo.
A Tabela 4 mostra a relao de complexidade x tipo de funo.
6. Calcular fator de ajuste
Para ajustar os pontos de funo de
acordo com o tipo de sistema que estamos desenvolvendo, so consideradas 14
caractersticas que devero ser contadas
de acordo com seu nvel de influncia,
sendo considerado 0 para o nvel mais
baixo de influncia at 5 para o nvel
mais alto.
Na Tabela 5 apresentamos a caracterstica comunicao de dados.
Tipos de elementos de dados

1 a 19
BAIXA
BAIXA
MDIA
1
2a5
>5
20 a 50
BAIXA
MDIA
ALTA
> 50
MDIA
ALTA
ALTA
Tabela 1. Complexidade de Arquivos Lgicos Internos (ALI) e Arquivos de Interface Externa (AIE)
Tipos de Arquivos referenciados
0a1
2
>2

1a4
5 a 15
BAIXA
BAIXA
BAIXA
MDIA
MDIA
ALTA
> 15
MDIA
ALTA
ALTA
Tabela 2. Complexidade de Entradas Externas (EE) e Entradas das Consultas Externas (CE)
Tipos de Arquivos referenciados
0a1
2a3
>3

1a5
6 a 19
BAIXA
BAIXA
BAIXA
MDIA
MDIA
ALTA
> 19
MDIA
ALTA
ALTA
Tabela 3. Complexidade de Sadas Externas(SE) e Sadas das Consultas Externas(CE)
Figura 2. Viso geral da anlise de pontos de funo
mtrica
Peso
Complexidade
BAIXA
7
5
3
4
3
ALI
AIE
EE
SE
CE
MEDIA
10
7
4
5
4
ALTA
15
10
6
7
6
Tabela 4. Peso x complexidade

Grau de Influncia
0
1
2
3
4
5
Comunicao de Dados
Justificativa
Batch/stand alone
Batch c/ entrada de dados ou impresso remota
Batch c/ entrada de dados e impresso remota
Entrada de dados online
Entrada de dados online c/ suporte a 1 protocolo
Entrada de dados online c/ suporte a n protocolos
Tabela 5. Comunicao de dados
Processamento distribudo
Grau de Influncia
0
1
2
3
4
5
Justificativa
Sem influncia sobre processamento distribudo
Gerao de dados para serem processadas fora da aplicao (ex. Planilhas)
Gerao de dados para processamento externo
Processamento distribudo online em 1 direo
Processamento distribudo online bi-direcional
Processamento distribudo dinamicamente
Tabela 6. Processamento distribudo
Desempenho
Grau de Influncia
0
1
2
3
4
5
Justificativa
Nenhum requisito especial de desempenho
Requisitos de desempenho estabelecidos, porm nenhuma ao especial requerida
Tempo de resposta e processamento so crticos em horrios especficos
Tempo de resposta e processamento so crticos em todo o horrio comercial
Requisitos de desempenho estabelecidos e prevista anlise de desempenho da
aplicao
Item 4 + uso de ferramentas de anlise de desempenho durante todo o ciclo de
desenv.
Tabela 7. Caracterstica desempenho

Grau de Influncia
Utilizao do equipamento 0
1
2
3
4
5
Justificativa
Nenhuma restrio operacional includa
Pequenas restries operacionais
Necessrias consideraes de ajuste de desempenho e segurana
Necessrias especificaes p/ mdulo especfico
Restries operacionais - tratamento especial
Item 4 + anlise de desempenho
Tabela 8. Utilizao do equipamento
Volume de transaes
Grau de Influncia
0
1
2
3
4
5
Tabela 9. Volume de transaes
Justificativa
No previsto perodos de pico
Perodos de pico em determinados meses / anos
Previstos picos semanais
Previstos picos dirios
Alto volume previsto, necessidade de anlise de desempenho na fase de projeto
Item 4 + uso de ferramentas de anlise de desempenho em todas as fases.
Na Tabela 6 temos a caracterstica

processamento distribudo.
Na Tabela 7 temos a caracterstica desempenho com seus respectivos graus
de influncia e justificativas.
utilizao do equipamento.
volume de transaes.
Na Tabela 10 temos a caracterstica entrada de dados online com seus respectivos graus de influncia e justificativas.
usabilidade.
atualizao online.
processamento complexo.
Na Tabela 14 temos a caracterstica reusabilidade com seus respectivos graus de
influncia e justificativas.
facilidade de implementao.
facilidade operacional.
mltiplos locais e organizaes com
seus respectivos graus de influncia e
justificativas.
facilidade de mudanas.
Feita a identificao de cada caracterstica, calcularemos o NIT (nvel de
influncia total). O NIT indica a variao
dada pelas caractersticas da aplicao
e ser utilizado para ajuste dos pontos
de funo no ajustados (calculados na
etapa anterior).
O c lc u lo do N I T dado p e l a
frmula:
NIT = Caractersticas Gerais
Em seguida, procedemos com o clculo
do fator de ajuste. Este feito com base
no valor do NIT e considera a frmula
apresentada abaixo:
FA = (NIT * 0,01) + 0,65
Onde:
FA = Fator de Ajuste;
NIT = Nvel total de influncia.
7. Calcular pontos de funo ajustados
Aps termos calculado os PFNAs
das funes de dados e transacionais,
35
definido nosso fator de ajuste e determinado o tipo de aplicao e seu escopo,

vamos ao ltimo passo da contagem,
que o ajuste dos PFs de acordo com a
variao encontrada.
O clculo de PFs Ajustados se d de
forma diferente para cada tipo de projeto
(definido no item 1).
Para projeto de desenvolvimento (FPD)
temos que ele se baseia em 3 elementos
para medio:
RF - Requisitos funcionais (definidos
pelo usurio);
RC - Requisitos de converso de dados
(definidos pelo usurio);
FA - Valor do fator de ajuste.
A partir destes elementos, considera-se
a frmula descrita abaixo para o clculo
dos pontos de funo ajustados para
projeto de desenvolvimento:
FPD = (RF + RC) * VAF
J para projeto de manuteno (FPM),
o clculo dos pontos de funo ajustados considera quatro elementos para
medio:
RF Requisitos funcionais (definidos
pelo usurio) medidos antes RFA e
depois RFD da modificao;
RC Requisitos de converso de dados
(definidos pelo usurio);
FA Valor do fator de ajuste considerado antes FAA e depois FAD da
modificao;
DEL Nmero de pontos de funo
no ajustados excludos pelo processo
de melhoria
Uma funo do tipo de dados considerada alterada quando h incluso,
excluso ou alterao de campos ou
elementos dos ALIs e AIEs.
Uma funo do tipo transao considerada alterada quando h alterao,
incluso ou excluso de ALIs /AIEs,
Arquivos referenciados e/ou lgica de
processamento.
projeto de manuteno:
FPM = [(RFA+RFD+RC)*FAA]+(DEL
* FAD)
36
Entrada de dados online
Grau de Influncia
0
1
2
3
4
5
Justificativa
100% das transaes processadas em batch
De 1% a 7% das transaes online
Mais de 30% das transaes online
Tabela 10. Entrada de dados online
Usabilidade
Auxlio navegao (teclas de funo, acesso direto e
menus dinmicos)
Help Online
Movimento automtico do cursor
Movimento hor/vert da tela
Impresso remota
Teclas de funo
Processos batch submetidos a partir de transaes on-line
Utilizao intensa de campos com vdeo reverso,
intensificados, sublinhados, coloridos e outros
indicadores
Impresso hard copy
Utilizao de mouse
Menus pop-up
O menor n. possvel de telas para executar funes de
negcio.
Suporte bilinge (contar como 4 itens)
Suporte multilnge. (contar como 6 itens)
Grau de Influncia
0
1
2
3
4
5
Justificativa
Nenhum dos itens descritos
De 1 a 3 itens
De 4 a 5 itens
Mais de 5 itens, sem requisitos de usabilidade
Mais de 5 itens, com definio de requisitos de
usabilidade
Mais de 5 itens, com definio de requisitos de
usabilidade e ferramentas de anlise de usabilidade
Tabela 11. Caracterstica usabilidade
Atualizao online
Grau de Influncia
0
1
2
3
4
5
Justificativa
Nenhuma
Atualizao de 1 a 3 ALIs, volume de dados baixo e recuperao simples
Atualizao de 1 mais de 3 ALIs, volume de dados baixo e recuperao simples
Atualizao online da maioria dos ALIs
Item 3 + proteo contra perda de dados
Item 4 + processo automatizado de recuperao
Tabela 12. Caracterstica atualizao online
Processamento complexo
Processamento especial de auditoria
Processamento lgico extensivo
Processamento matemtico extensivo
Processamento gerando muitas excees, resultando em
transaes incompletas que devem ser processadas novamente
Processamento complexo para manusear mltiplas possibilidades
de entrada/sada
Grau de Influncia
0
1
2
3
4
5
Justificativa
Nenhum dos itens descritos
Apenas 1 dos itens
Dois dos itens
Trs dos itens
Quatro dos itens
Todos os itens
Tabela 13. Caracterstica processamento complexo. Na Tabela 9 temos a caracterstica volume de

transaes.
mtrica
Reusabilidade
Grau de Influncia
0
1
2
3
4
5
Justificativa
Sem preocupao com reuso
Reuso somente dentro da aplicao
Menos de 10% preparado para reuso
10% ou mais preparado para reuso
Aplicao projetada para reuso nvel de cdigo
Aplicao projetada para reuso c/ parmetros
Dando continuidade, para projeto de

aplicao temos duas frmulas: uma
para contagem inicial de todos os requisitos de uma aplicao instalada e outra
para melhorias implementadas.
Para a contagem inicial (FPI) consideramos os elementos:
PFI Nmero de pontos de funo
identificados pelo usurio;
FA Valor do fator de ajuste.
Tabela 14. Caracterstica reusabilidade
Facilidade de
implementao
Grau de Influncia
Justificativa
0
1
2
Nenhuma considerao especial

Nenhuma considerao especial, necessidade de procedimentos especiais
Requisitos de converso / implantao estabelecidos, impacto da converso no
considerado
Requisitos de converso / implantao estabelecidos, impacto da converso
considerado
Item 2 + converso automtica e ferramentas de implantao providas
Item 3 + converso automtica e ferramentas de implantao providas
3
4
5
Tabela 15. Caracterstica facilidade de implementao.

Grau de Influncia
Facilidade operacional
0
1-4
Desenvolvidos processos de inicializao,
salvamento e recuperao, mas a interveno do 5
operador necessria
Estabelecidos processos de inicializao,
salvamento e recuperao, e nenhuma
interveno do operador necessria (conte
como dois itens)
A aplicao minimiza a necessidade de montar
fitas magnticas.
A aplicao minimiza a necessidade de
manuseio de papel
Justificativa
Nenhuma considerao especial de operao
Contar cada item como 1 ponto
Aplicao desenhada para trabalhar sem operador.
Tabela 16. Caracterstica facilidade operacional
Mltiplos locais e organizaes
Grau de Influncia
0
1
2
3
4
5
Justificativa
Sem instalao em diversos locais
Desenhada para operar em ambiente idnticos
Desenhada para operar em ambientes similares
Desenhada para operar em ambientes distintos
Itens 1 e 2 + Desenhada para operar em mltiplos locais
Item 3 + Desenhada para operar em mltiplos locais
Tabela 17. Caracterstica mltiplos locais e organizaes.
Facilidade de mudanas
Consultas e relatrios flexveis para atender necessidades simples (conte como 1 item)
Consultas e relatrios flexveis para atender necessidades de complexidade mdia (conte como 2 itens);
Consultas e relatrios flexveis para atender necessidades complexas (conte 3 itens);
Os dados de controle so armazenados em tabelas que so mantidas pelo usurio atravs de processos on-line, mas mudanas
tm efeitos somente no dia seguinte;
Os dados de controle so armazenados em tabelas que so mantidas pelo usurio atravs de processos on-line, as mudanas tm
efeito imediatamente (conte como 2 itens).

projeto de aplicao:
FPI = PFI * FA
J para a contagem aps melhorias (FPM)
considera-se os seguintes elementos:
PFA Nmero de pontos de funo
antes da melhoria;
PFAD Nmero de pontos de funo
includos;
PFAT Nmero de pontos de funo
das funes antes do trmino;
PFDT Nmero de pontos de funo
das funes depois do trmino;
PFD Nmero de pontos de funo
excludos pela melhoria;
FA Valor do fator de ajuste depois da
melhoria.
projeto de aplicao:
F P M = [ ( P FA+ P FA D + P FA T ) (PFDT+PFD)]*FA
Concluso
Nesse artigo foi possvel entender o
funcionamento da anlise de pontos
de funo, entendemos um pouco da
Grau de Influncia
0
1
2
3
4
5
Justificativa
Nenhum dos itens
1 dos itens
2 dos itens
3 dos itens
4 dos itens
Todos os itens
Tabela 18. Caracterstica facilidade de mudanas
37
HAZAN, Cludia -Anlise de Pontos por Funo agosto , 2001 . disponvel em http://www.inf.
ufes.br/~falbo/download/aulas/es-g/2005-1/APF.pdf. acessado em: out. 2005
[IFPUG99] THE INTERNATIONAL FUNCTION POINT USERS GROUP,Princeton Junction. Function
Point Counting Practices Manual release 4.1.1[s.l.], 1999.

D
s
VAZQUEZ, C. E.;SIMES, G. S; ALBERT, R. M.Anlise de Pontos de Funo Medio, Estimativas e

Gerenciamento de Projetos de Software. 2005. 3.ed. So Paulo- Editora Erica
Feedback
eu
edio
ta
38
Links
sobre e
s
histria e da importncia do processo de mtrica, vimos que

necessria a definio do tipo de sistema que queremos contar,
assim como a delimitao do seu escopo, identificamos que
preciso contar funes de dados e de transao, precisar o seu
tamanho de acordo com registros lgicos e por fim ajustar a
medida feita levando em conta caractersticas que tornam um
sistema diferente de outro.
A anlise de pontos de funo, assim como outras tcnicas
de mtrica de software, no tem o objetivo de resolver todos
os problemas de estimativa, mas sim ser uma ferramenta para
ajudar na preciso das previses de tamanho, tempo e custos,
seja para o desenvolvimento de um novo software, manuteno
de um software existente ou mesmo para avaliar o tamanho
de um software instalado.
Espero com esse artigo ter facilitado o entendimento geral
sobre APF, e despertado o seu interesse em saber mais sobre o
assunto, muitas so as referncias que podem ser encontradas,
e realmente vale a pena o estudo.
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 4
Cdigo Limpo
Jacimar Fernandes Tavares

jacimar.tavares@studentpartners.com.br
Bacharel em Cincia da Computao FAGOC

- Faculdade Governador Ozanam Coelho,
Microsoft Student Partners.
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.
A discusso deste tema interessante uma vez que
prov conhecimento ao desenvolvedor sobre como
transformar cdigos considerados ruins em bons cdigos atravs de exemplos prticos das teorias aqui
abordadas.
Esta srie de artigos discutir 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.

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.

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 ili zar o processo criat ivo

para a definio de estruturas
de cdigo que permitiro a
transformao das ideias abstradas em
regras de negcio implementadas em
uma linguagem especfica em forma
de cdigo fonte algo comum entre
desenvolvedores, contudo h esforos
para diminuir o impacto que diferentes
abstraes podem causar no desenvolvimento de uma soluo implementada

em equipe. Manter um cdigo abstrado
por outro desenvolvedor, dependendo
da complexidade em que foi concebido,
pode ser uma tarefa difcil, j que o raciocnio empregado na realizao de uma
implementao pode variar, e muito, de
um desenvolvedor para outro.
39
Nesse sentido, vrias tcnicas vm surgindo entre desenvolvedores, muitas delas expressas para terceiros em forma de
literatura tcnica, na tentativa de minimizar os riscos que as
diferentes abstraes podem agregar ao projeto.
Manter o projeto de cdigo limpo uma tarefa gradual que
envolve vrios passos. Sendo assim, o prximo passo rumo
obteno de estruturas de cdigo que minimizem os riscos das
diversas abstraes de diferentes desenvolvedores, e que sejam
ao mesmo tempo consideradas limpas, definir um formato
para arquivos fontes.
O conceito arquivo fonte ser utilizado porque as regras de
formatao presentes neste artigo extrapolam os limites de
uma classe, aplicando-se ao arquivo fonte, isto , o arquivo
que contm a classe e outros trechos de cdigo.
Definir a formatao que o projeto de cdigo como um todo
deve seguir envolve a obteno de conceitos importantes aqui
abordados, que proporcionaro ao desenvolvedor pensar na
disposio do cdigo fonte no arquivo fonte de uma maneira
diferente da utilizada por alguns desenvolvedores individuais.
O objetivo deste artigo, que gira em torno da definio de um
formato para o projeto de cdigo, est fundamentado nas boas
prticas para a criao de cdigo limpo. A seo Formatao
traz os tipos de formatao existentes e as regras a serem
aplicadas em cada tipo, de forma conceitual e prtica, atravs
das listagens de cdigo. Ao final, o desenvolvedor ter um
resumo das regras, que podero ser adotadas pela sua equipe
de desenvolvimento.
Formatao
Objetivo: Esta seo est relacionada com o formato que o
cdigo fonte deve possuir. Em outras palavras, deve se ter uma
ateno quanto a como o cdigo est distribudo na classe, se
a quantidade de linhas de cdigo muito para ser exibida na
tela ou se quem o visualiza ter o chato trabalho de rolar para
a direita para conseguir l-lo por completo.
Formatao do cdigo est intimamente relacionada
disposio, isto , como o cdigo est organizado, disposto
no arquivo fonte, e a quantidade de cdigo presente por arquivo. Esta seo aborda importantes teorias que sero teis
no processo de criar um formato para o cdigo fonte de suas
aplicaes que seja limpo.
Os tipos de formatao de cdigo: os arquivos de cdigo
so formatados basicamente de duas formas, quanto disposio do cdigo neles escritos: disposio vertical e disposio
horizontal.
A disposio vertical
A disposio vertical, isto , o formato que o cdigo assume
no arquivo fonte, verticalmente falando, deve ser o menor
quanto possvel. Isso, na prtica, quer dizer que a quantidade
de linhas de cdigo presentes em um arquivo fonte (quantidade de linhas no arquivo fonte igual ao tamanho vertical
do arquivo) deve ser mnima, pois arquivos com menos linhas
so mais fceis de encontrar trechos em especficos. Contudo,
um tamanho vertical considerado pequeno no implica em o
40
arquivo ser mais fcil de entender, visto que o entendimento

do cdigo escrito no arquivo depende mais da qualidade do
que est escrito do que o tamanho propriamente dito. Arquivos
fonte considerados pequenos no seu formato vertical podem
ser mais fceis de manter que arquivos considerados grandes,
mas isto no uma regra. No h um tamanho especfico que
deva ser seguido como uma regra, contudo, interessante que
os arquivos sejam o quanto menores possveis na sua forma
vertical, desde que haja uma razo para sua existncia.
Uma regra importante, relativa disposio vertical do
cdigo no arquivo fonte gira em torno do espaamento que
deve existir entre as estruturas que constituem a organizao
do cdigo fonte no arquivo fonte. As Listagens 1 e 2 serviro
para ilustrar.
Listagem 1. Cdigo sem espaamento entre estruturas.
01. using System;

02. using System.Collections.Generic;
03. using System.Linq;
04. using System.Text;
05. using System.Data.SqlClient;
06. namespace DiaPagamento
07. {
08. public class SingletonConexaoBancoSQL
09. {
10. private static SqlConnection objConexao = null;
11. private String stringconnection = Data Source= + Environment.
MachineName.ToString() + \\SQLEXPRESS; Initial Catalog=
DiaPagamento;Integrated Security=SSPI;MultipleActive
ResultSets=True ;
12. public SingletonConexaoBancoSQL()
13. {
14.
objConexao = new SqlConnection();
15.
objConexao.ConnectionString = stringconnection;
16.
objConexao.Open();
17. }
18. public static SqlConnection getConexao()
19. {
20.
if (objConexao == null)
21.
{
22.
new SingletonConexaoBancoSQL();
23.
}
24.
return objConexao;
25. }
26. public static void fecharConexao()
27. {
28.
objConexao.Close();
29. }
30. public static SqlDataReader ObterResultadoComando(String query)
31. {
32.
SqlConnection Conexao = SingletonConexaoBancoSQL.getConexao();
33.
SqlCommand Commando = new SqlCommand(query, Conexao);
34.
Commando.ExecuteNonQuery();
35.
SqlDataReader dadosObtidos = Commando.ExecuteReader();
36.
return dadosObtidos;
37. }
38. public static void ExecutarComando(String query)
39. {
40.
41.
42.
43. }
44. }
45. }
Engenharia de Software Magazine - Boas prticas para escrita de mtodos, funes e procedimentos Parte 4
desen volvimento
Listagem 2. Cdigo com espaamento entre estruturas
01. using System;

02. using System.Collections.Generic;
03. using System.Linq;
04. using System.Text;
05. using System.Data.SqlClient;
06.
07. namespace DiaPagamento
08. {
09.
10. public class SingletonConexaoBancoSQL
11. {
12. private static SqlConnection objConexao = null;
13. private String stringconnection = Data Source= + Environment.
MachineName.ToString() + \\SQLEXPRESS; Initial Catalog=
DiaPagamento;Integrated Security=SSPI;MultipleActive
ResultSets=True ;
14.
15. public SingletonConexaoBancoSQL()
16. {
17.
objConexao = new SqlConnection();
18.
objConexao.ConnectionString = stringconnection;
19.
objConexao.Open();
20. }
21.
22. public static SqlConnection getConexao()
23. {
24.
if (objConexao == null)
25.
{
26.
new SingletonConexaoBancoSQL();
As Listagens 1 e 2 possuem o mesmo trecho de cdigo. O

arquivo fonte da Listagem 1 composto de declaraes de bibliotecas em uso (linhas 1 a 5), da declarao do namespace (em
Java seria declarao do pacote) (linha 6), declarao da classe
(linha 8), os atributos da classe (linhas 10 e 11), os mtodos da
classe (linhas 12 a 43), o fim da declarao da classe (linha 44)
e o fim da declarao do namespace (linha 45). O arquivo da
Listagem 2 tambm possui as mesmas estruturas, mas a diferena que, em relao Listagem 1, est melhor organizada,
por um simples motivo: cada uma das partes citadas, que juntas
constituem o fonte, esto separadas por uma linha em branco. O
simples acrescentar de uma linha em branco entre os mtodos,
conjunto dos atributos, declaraes de namespaces e bibliotecas
faz com que a impresso de organizao e diviso do cdigo seja
mais visvel em primeira anlise. O cdigo da Listagem 1, em
primeira instncia, parece ser um nico bloco, o que d inteno
de uma grande quantidade de cdigo aglomerada.
Utilizar esse recurso de um espao em branco entre estruturas
de cdigo de um mesmo arquivo fonte contribui para que o
cdigo se torne mais limpo, pois facilita a ideia de pequenos
mdulos ao visualizar trechos separados. Este recurso ainda mais til quando a IDE de desenvolvimento no possui
recursos como o do Visual Studio e do Eclipse, entre outros,
que atribui cores para algumas palavras reservadas, como
os moderadores de acesso, o que facilita a viso de cdigo
dividido em pequenos mdulos. IDEs sem o recurso de atribuio de cores a algumas palavras em especfico dificultam
a visualizao do formato vertical do arquivo fonte, em suas
divises por estruturas.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54. }
}
return objConexao;
public static void fecharConexao()

{
objConexao.Close();
}
public static SqlDataReader ObterResultadoComando(String query)
{
SqlDataReader dadosObtidos = Commando.ExecuteReader();
return dadosObtidos;
}
public static void ExecutarComando(String query)
{
}
}
Ainda analisando as Listagens 1 e 2, pode-se perceber que a

regra de um espao em branco no utilizada entre as linhas 1
a 5 e 12 a 13 da Listagem 2, pois o cdigo presente nessas linhas
pertencem ao mesmo propsito, e no devem ser separados. Declarao de bibliotecas e declarao de atributos devem ser escritos em um mesmo bloco, s sendo separados por espaos em
branco antes e depois. J cada um dos mtodos da Listagem 2
constitui unidades independentes e de propsito diferentes
entre eles, portanto, aplicar a regra do espao em branco de
uma linha recomendado.
Outra regra importante, referente disposio vertical do
cdigo fonte no arquivo fonte, est relacionada ligao que
trechos de cdigo tm com outros trechos de cdigo do mesmo
arquivo. fundamental que, caso haja um mtodo que invoca
outro mtodo da mesma classe, o mtodo invocado fique debaixo do mtodo que o invoca. Isto facilita a busca pelo mtodo
chamado. Caso o mtodo chamado esteja longe do mtodo
que o invoca, o leitor do cdigo fonte ter que subir e descer a
barra de rolagem do arquivo fonte, o que torna o processo de
entendimento do cdigo que se est rastreando mais difcil,
alm de, em alguns casos, levar a perda do raciocnio que
estava sendo construdo ao se verificar os mtodos.
O mesmo serve para os atributos da classe. importante que
os atributos estejam declarados na classe na mesma ordem
que forem ser utilizados, por exemplo, por campos de um
formulrio ou por um mtodo construtor. Um exemplo pode
ser visto na Figura 1 e na Listagem 3.
Analisando o formulrio da Figura 1 possvel perceber
que a ordem dos campos nele definidos a mesma ordem
41
Figura 1. Formulrio Cadastro de Funcionrios

Listagem 3. Classe Funcionario
01. public class Funcionario

02. {
03. private String nomeFuncionario;
04. private String cPFFuncionario;
05. private String cepFuncionario;
06. private String telefoneFuncionario;
07. private Decimal salarioFuncionario;
08. private String cargoFuncionario;
09. public String NomeFuncionario
10. {
11. get { return nomeFuncionario; }
12. set { nomeFuncionario = value; }
13. }
14. public String CPFFuncionario
15. {
16. get { return cPFFuncionario; }
17. set { cPFFuncionario = value; }
18. }
19. public String CepFuncionario
20. {
21. get { return cepFuncionario; }
22. set { cepFuncionario = value; }
23. }
24. public String TelefoneFuncionario
25. {
26. get { return telefoneFuncionario; }
27. set { telefoneFuncionario = value; }
28. }
29. public Decimal SalarioFuncionario
30. {
31. get { return salarioFuncionario; }
32. set { salarioFuncionario = value; }
33. }
34. public String CargoFuncionario
35. {
36. get { return cargoFuncionario; }
37. set { cargoFuncionario = value; }
38. }
39. public Funcionario(String nome, String cpf, String cep,
String telefone, Decimal salario, String cargo)
40. {
41.
this.NomeFuncionario = nome;
42.
this.CPFFuncionario = cpf;
43.
this.CepFuncionario = cep;
44.
this.TelefoneFuncionario = telefone;
45.
this.SalarioFuncionario = salario;
46.
this.CargoFuncionario = cargo;
47. }
48. }
42
dos atributos descritos na classe Funcionario da Listagem 3.

Na Listagem 3 tambm possvel perceber que, alm dos
atributos estarem declarados na mesma ordem dos campos do
formulrio, seus mtodos get e set , linhas 9 a 38 da Listagem 3,
esto declarados na mesma ordem que os atributos foram
declarados.
Alm de todos esses detalhes, os parmetros do mtodo
construtor tambm esto na mesma ordem dos atributos e na
mesma ordem dos campos do formulrio da Figura 1. O corpo
do construtor da classe Funcionario tambm est definido na
mesma ordem. Essa a visualizao da aplicao na prtica da
regra sobre a ligao dos trechos de cdigo relacionados. Como
benefcio, fica mais fcil analisar todas estas informaes, visto
que esto seguindo uma ordem de ligao. O cdigo cliente
que por ventura o desenvolvedor vier a escrever, que utilize a
classe Funcionario, ter o esforo reduzido ao saber que uma
passagem de parmetros para o construtor de Funcionario poder seguir a mesma sequncia dos campos do formulrio.
Outro ponto importante da regra sobre a ligao de trechos
de cdigo de uma classe com trechos de cdigo da mesma
classe est relacionada ao fato de que variveis locais em um
mtodo devem ser declaradas no incio do corpo do mtodo, e
no no ponto onde sero usadas. Para ilustrar, vamos analisar
as Listagens 4 e 5.
Listagem 4. Mtodo sem a aplicao da regra
01. public Decimal calcularNovoValorParcela(DateTime dataVencimento,

Decimal valorParcela)
02. {
03. if (descobrirSePrestacaoVenceu(dataVencimento))
04. {
05. Int16 qtdDiasEmAtrazo = obterQtdDiasAtrazo(dataVencimento);
06. Decimal jurosTotais = qtdDiasEmAtrazo * 2.38m;
07. Decimal valorParcelaCorrigida = valorParcela + jurosTotais;
08. return valorParcelaCorrigida;
09. }
10. else
11. {
12. valorParcela = valorParcela - 7.25m;
13. return valorParcela;
14. }
15. }
Listagem 5. Mtodo com a aplicao da regra
01. public Decimal calcularNovoValorParcela(DateTime dataVencimento,

Decimal valorParcela)
02. {
03. Int16 qtdDiasEmAtrazo;
04. Decimal jurosTotais;
05. Decimal valorParcelaCorrigida;
06. if (descobrirSePrestacaoVenceu(dataVencimento))
07. {
08. qtdDiasEmAtrazo = obterQtdDiasAtrazo(dataVencimento);
09. jurosTotais = qtdDiasEmAtrazo * 2.38m;
10. valorParcelaCorrigida = valorParcela + jurosTotais;
11. return valorParcelaCorrigida;
12. }
13. else
14. {
15. valorParcela = valorParcela - 7.25m;
16. return valorParcela;
17. }
18. }
desen volvimento
Na Listagem 4, as variveis locais utilizadas no mtodo

calcularNovoValorParcela esto declaradas no ponto onde
esto sendo utilizadas, como pode ser visto nas linhas 5, 6
e 7. A aplicao da regra leva o mtodo a ser modificado,
tendo suas variveis locais declaradas no incio do corpo do
mtodo, como pode ser visto na Listagem 5, linhas 3, 4 e 5.
O mesmo serve para variveis declaradas prximo ao local
onde sero utilizadas. Elas devem ser sempre declaradas no
incio do corpo do mtodo.
Considerando agora o cdigo da Listagem 6, tem-se outro
importante exemplo relativo disposio vertical de trechos
de cdigo em um arquivo fonte. Em um exemplo passado foi
mostrado que mtodos que invocam outros mtodos da mesma classe devem vir sobre os mtodos invocados. O exemplo
da Listagem 6 mostra que mtodos que possuem qualquer
relao devem aparecer o mais prximo possvel.
Entre os mtodos da Listagem 6 no h a relao de mtodo
chamador e mtodo chamado. Contudo eles se encontram
agrupados: primeiro vm os mtodos de insero de dados
no banco (linhas 4 a 17), depois os mtodos de busca de
dados no banco (linhas 19 a 47), seguidos do grupo dos
mtodos de atualizao de dados no banco (linhas 49 a 57)
e, por ltimo, do grupo dos mtodos de excluso (grupo
com apenas um mtodo) (linhas 59 a 62). O programador
que escreveu esta classe utiliza esse padro para todas as
suas classes, dispondo verticalmente os mtodos por grupos,
o que facilita a busca na classe por um mtodo desejado.
Caso o mtodo a ser encontrado seja de excluso de dados,
o programador no perder tempo procurando no incio da
classe. Ele ir imediatamente para o fim da classe.
A disposio horizontal
A disposio horizontal est relacionado a como o cdigo
fonte se dispe horizontalmente no arquivo fonte, ou seja,
como ele definido em suas linhas. O primeiro ponto a
se considerar o tamanho horizontal do cdigo, isto , o
tamanho que as linhas podem alcanar no arquivo fonte.
O ideal que as linhas sejam o quanto menores possveis,
cuidando para que caibam dentro da visualizao da tela
do monitor e no precisem ser roladas para o lado com a
barra de rolagens para poderem ser totalmente lidas. Outros
detalhes importantes sobre o tamanho horizontal das linhas
de cdigo foram descritos no artigo sobre Funes, desta
srie de artigos sobre Cdigo Limpo (ver Nota 1).
Nota 1. Funes
O artigo sobre funes foi publicado na edio 40 da Engenharia de Software Magazine
Um ponto importante sobre a disposio horizontal do

cdigo o espaamento que deve haver entre palavras e
operadores de uma linha. Para ilustrar essa regra, considere
a Listagem 7.
A Listagem 7 servir para ilustrar todas as particularidades da regra de espaos entre palavras e operadores em
Listagem 6. Classe Professor
01. public class Professor: Pessoa

02. {
03. ...
04. public override Boolean criarPessoa(ArrayList dadosProfessor)
05. {
06. ...
07. }
08.
09. private Boolean gravaProfessor(Professor professor)
10. {
11. ...
12. }
13.
14. public ArrayList enviarProfessores()
15. {
16. ...
17. }
18.
19. public ArrayList buscaProfessores(String nome)
20. {
21.
22. }
23.
24. public ArrayList visualizaProfessor(String id, String nome)
25. {
26.
27. }
28.
29. public ArrayList visualizaNomesProfessores()
30. {
31.
32. }
33.
34. public Int64 recuperaIDProfessor(String nome)
35. {
36.
37. }
38.
39. public String recuperaProfessorPorID(Int64 id)
40. {
41.
42. }
43.
44. public ArrayList buscaProfessoresPorAluno(Int64 matricula,
String nomeAluno)
45. {
46. ...
47. }
48.
49. public Boolean atualizaProfessor(ArrayList dadosProfessor)
50. {
51. ...
52. }
53.
54. private Boolean atualizaProfessorBanco(Professor professor)
55. {
56. ...
57. }
58.
59. public override Boolean excluir(String ID)
60. {
61. ...
62. }
63.
64. }
43
uma linha. Comeando pela primeira particularidade,

possivel observar que na linha 19 tem-se a declarao do
mtodo criarFormulaBaskara. Nota-se que, aps a definio
do nome do mtodo no h espao entre ele e o parntese
aberto. Esta regra deve ser seguida, pois o parntese parte
do raciocnio empregado ao mtodo, ou seja, os parnteses
fazem parte do mesmo conceito que o nome do mtodo.
Na linha 21 h um objeto sendo instanciado. Nota-se que
h espao antes e depois do operador de igual (=, que no
contexto de instanciao de objetos significa recebe). O
operador est entre espaos em branco porque, por si s,
uma informao independente do nome do objeto. Escrevlo junto ao nome do objeto, resultado no caso, acaba misturando a visualizao do operador com o nome do objeto.
Operadores, portanto, devem vir precedidos e poscedidos
de espaos em branco.
Listagem 7. Classe FormulaBaskara
01. public class FormulaBaskara

02. {
03.
04. private Double x1;
06.
07. public Double X1
08. {
09. get { return x1; }
10. set { x1 = value; }
11. }
12.
14. {
16. set { x2 = value; }
17. }
18.
19. public FormulaBaskara criarFormulaBaskara(Double a, Double b,
Double c)
20. {
21. FormulaBaskara resultado = new FormulaBaskara();
22. Double delta;
23. delta = (b * b) - (4 * a * c);
24. resultado.X1 = (- b + Math.Sqrt(delta)) / (2 * a);
25. resultado.X2 = (- b - Math.Sqrt(delta)) / (2 * a);
26. return resultado;
27. }
28.
29. }
Outros pontos da aplicao dessa particularidade da regra podem ser vistos nas linhas 23, 24 e 25. Ainda nessas
linhas, possivel observar que os espaos em branco esto
sendo utilizados antes e depois dos parnteses, para deixar
claro que o que se encontra entre parnteses pertence a um
mesmo conceito nico. Essa ao refora a ideia de forma
visual de que tudo que est entre parnteses resolvido
primeiro para depois se comunicar com o resto do cdigo
fora dos parnteses. Sem os espaos esta regra continua
valendo, mas os espaos facilitam a visualizao de diviso
de conceitos.
Quando o assunto disposio horizontal do cdigo no
44
arquivo fonte, uma importante prtica a endentao, pois

permite que os blocos de cdigo sejam alinhados, sempre
com o cdigo contido por outra estrutura um pouco mais
direita do que o cdigo que a contm. Esta regra implementada por ambientes de desenvolvimento como o
Visual Studio, Eclipse e Netbeans, entre vrios outros.
Manter o cdigo com a endentao correta facilita a
visualizao das estruturas de forma separada, alm de
facilitar a visualizao da hierarquia que existe entre os
trechos de cdigo de uma classe, por exemplo. Alm disso,
essa organizao contribui para que o cdigo seja considerado limpo, pois alm de facilitar a viso hierrquica
do cdigo fonte, facilita o processo de entendimento e
tambm o de modificao do cdigo fonte.
A Listagem 7 possui o cdigo fonte de uma classe onde
nitidamente possvel verificar a aplicao da regra de
endentao citada neste artigo. Antes da declarao da
classe, pode-se perceber que no h espao, pois a primeira estrutura da hierarquia, linhas 1 e 2. Em seguida, j
nas linhas 4 e 5, h um recuo para a direita. Isto na regra
quer dizer que o cdigo das linhas 4 e 5 est contido na
primeira hierarquia, que a da declarao da classe. Nas
linhas 7 a 17 esto os mtodos get e set, no mesmo nvel
de endentao dos atributos da classe, pois eles, assim
como os atributos, possuem o mesmo nvel dentro da
hierarquia.
O mtodo declarado, aberto e fechado nas linhas 19, 20 e
27, tambm pertence ao mesmo nvel da hierarquia que os
atributos das linhas 4 e 5, porm o corpo do mtodo declarado na linha 19 possui um recuo a mais para a direita e dois
a mais para a direita em relao declarao da classe, pois
o cdigo do mtodo em questo est contido na hierarquia
do mtodo que, por sua vez, est contida na hierarquia da
classe. Essa regra no demonstra toda sua importncia
quando se est analisando um trecho de cdigo organizado,
com o da Listagem 7, mas se compar-la a mesma classe,
porm sem a endentao, os benefcios sero visualizados
rapidamente. A Listagem 8 contm a classe FormulaBaskara
sem endentao.
Analisar e entender o cdigo da Listagem 8 mais
difcil do que analisar o cdigo da Listagem 7, pois os
desenvolvedores j esto acostumados a trabalhar com
trechos de cdigo endentados.
No que se refere hierarquia imposta pela endentao
do cdigo, fundamental que o desenvolvedor esteja
consciente de que, caso a hierarquia seja mal definida, isto
, o cdigo seja endentado de forma errada, isto poder
levar o desenvolvedor que realiza anlises superficiais de
um trecho de cdigo ao erro, dado que poder concluir,
por exemplo, que uma estrutura como um Else pertence a
um bloco IF quando na realidade pertence a outro bloco
IF. Outro malefcio da falta de endentao do cdigo da
Listagem 8 pode ser visto quando o cdigo depurado.
Entender as estruturas e os blocos de cdigo visitados se
torna um pouco confuso.
desen volvimento
Listagem 8. Classe FormulaBaskara sem endentao
Definindo padres de formatao
01. public class FormulaBaskara

02. {
03.
04. p
rivate Double x1;
06.
08. {
10. set { x1 = value; }
11. }
12.
14. {
16. set { x2 = value; }
17. }
18.
19. public FormulaBaskara criarFormulaBaskara(Double a, Double b,
Double c)
20. {
21. FormulaBaskara resultado = new FormulaBaskara();
22. Double delta;
23. delta = (b * b) - (4 * a * c);
24. resultado.X1 = (- b + Math.Sqrt(delta)) / (2 * a);
25. resultado.X2 = (- b - Math.Sqrt(delta)) / (2 * a);
26. return resultado;
27. }
28.
29. }
Um recurso utilizado por diversas empresas de desenvolvimento e que se torna fundamental na construo de aplicativos
considerados dentro das normas de formatao a definio
de padres de formatao.
Padres de formatao so as regras que a equipe de desenvolvimento utiliza para que todo o cdigo implementado
possua formatao igual. Isso implica em todos os membros
da equipe de desenvolvimento seguirem os padres estabelecidos para que no haja implementaes, no que se refere
formatao do cdigo, individualistas.
Neste artigo esto sendo abordadas diversas regras de formao acerca da disposio, tanto vertical como horizontal
do cdigo fonte. Nesse sentido, importante que a equipe
de desenvolvimento tenha um momento para definir quais
os padres de formatao que devero seguir.
Uma das primeiras regras sobre formatao descritas
neste artigo gira em torno da disposio vertical do cdigo
fonte no arquivo fonte. Para determinar, por exemplo, qual
o tamanho em nmero de linhas de cdigo fonte que um
projeto deve possuir, a equipe pode estabelecer um nmero
de linhas ideal, um nmero mnimo e um nmero mximo,
levando em considerao, por exemplo, um histrico de
projetos anteriores desenvolvidos por ela.
45
Os tpicos listados so um resumo das regras apresentadas

neste artigo e que devem fazer parte do conjunto de boas
prticas que a equipe de desenvolvimento define para seus
projetos.
Concluso
A srie de artigos sobre cdigo limpo vem abordando importantes aspectos e tcnicas que so utilizadas para tornar o
projeto de cdigo limpo, atravs de suas sees.
Este artigo abordou a seo formatao, que forneceu ao
desenvolvedor as regras necessrias para que os projetos
de software tenham um formato fundamentado em boas
prticas. As regras que mostram como implementar uma
formatao consistente em projetos de cdigo devem ser
utilizadas por toda a equipe de desenvolvimento. fundamental que o conhecimento adquirido neste artigo seja
utilizado pela equipe e que os padres de formatao sejam
definidos para que todos possam utiliz-los.
Referncias
MARTIN, Robert C, 2009. Cdigo Limpo: Habilidades Prticas do Agile Software, 1ed. Rio de
Janeiro: Alta Books, 2009.

D
s
FOWLER, Martin. Refatorao: aperfeioando o projeto de cdigo existente, 1ed. Porto Alegre:
Bookman, 2004.
Feedback
eu
edio
ta
46
mtodos de consulta e mtodos de excluso. A melhor forma

de agrupamento deve ser definida pela equipe;
no se esquecer de manter espaos em branco, na horizontal, entre operadores e palavras reservadas. O mesmo deve
ser seguido para a definio da regra de parnteses;
manter sempre o cdigo endentado de acordo com as
regras de hierarquia do cdigo implementado.
sobre e
s
J para definir o tamanho horizontal do arquivo fonte, ou

seja, o tamanho mnimo e mximo que as linhas devem possuir, a equipe pode considerar como tamanho mnimo que
as linhas contenham tamanho suficiente para sua existncia.
Em contra partida, o tamanho mximo pode ser definido
de acordo com o tamanho do monitor, sem a necessidade
de rolagem. Esta regra mais fcil de ser utilizada quando
todos os monitores da equipe de desenvolvimento, teste e
manuteno (entre outros computadores utilizados para
analisar cdigo fonte) forem iguais.
Alguns ambientes de desenvolvimento, a exemplo do Netbeans, ao ter uma classe criada, automaticamente abrem
a chave da classe na mesma linha da declarao da classe.
Ambientes como o Visual Studio, por sua vez, definem automaticamente a chave aberta na linha posterior a da definio
da classe. Cabe equipe de desenvolvimento determinar
se os padres definidos pelo ambiente de desenvolvimento
sero mantidos ou sero alterados. O caminho que leva um
cdigo at ao reconhecimento como cdigo bem formatado
deve considerar at as pequenas coisas.
A seguir listado um resumo contendo informaes acerca
da formatao de cdigo que podem ser utilizadas pelos
leitores deste artigo em suas respectivas equipes:
sempre definir espaamento de uma linha em branco,
para dividir as diferentes estruturas que compem o arquivo fonte;
definir mtodos que invocam outros mtodos sempre
acima do mtodo invocado;
manter sempre a mesma sequncia dos atributos na definio dos mtodos construtores e de criao de objetos,
assim como est definida a ordem nos formulrios, caso
existam, como o exemplo citado neste artigo;
as variveis locais e objetos instanciados localmente
devem vir, a exemplo dos mtodos, no incio do corpo do
mtodo;
manter sempre a declarao das variveis e objetos instanciados no incio dos mtodos na mesma ordem que forem
ser utilizados no corpo do mtodo;
mtodos que pertencem a um mesmo contexto devem estar
agrupados. Este agrupamento pode ser como citado neste
artigo, por mtodos de insero, mtodos de atualizao,
desen volvimento
47

Edição42 2011

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Edição42 2011

Diunggah oleh

Hak Cipta:

Format Tersedia

magazine

AGILIDADE NA MEDIDA CERTA

Unimos talento Criamos futuro

Rodrigo Oliveira Spnola

Marco Antnio Pereira Arajo

Ano 4 - 42 Edio - 2011

Eduardo Oliveira Spnola

Fale com o Editor!

necessidade de aproximar a rea de TI com o negcio torna-se cada vez

inverter a ordem ou colocar tudo na devida ordem na produo de um novo

mais relevante medida que os altos executivos das grandes corpora-

sistema. Os novos produtos de software passaram a possuir verses baseadas no

es mundo a fora compreendem o quanto as solues desenvolvidas

ciclo de mudana do negcio. A cada nova necessidade, um novo produto. Este

por este departamento, at ento, restritamente tcnico, poderiam alavancar

o novo ciclo da Engenharia de Software.

sas corporaes a procurarem racionalizar seu modelo de negcio com base no

artigo em que sero apresentadas a estrutura e as foras da metodologia gil

denominada FDD (Future Driven Development) ou Desenvolvimento Guiado

atual em relao s constantes mudanas nas regras do negcio, originrias de

por Funcionalidades que, apesar de valorizar os processos e a forma de se fazer,

tem sua nfase nos valores e princpios do manifesto gil.

a mudana nos requisitos do sistema durante o seu desenvolvimento deve ser

Alm deste artigo, teremos mais seis nesta edio:

encarada com naturalidade. Este um fator de alta relevncia para um projeto

Scrum e MPS.BR na implantao de um modelo de desenvolvimento colaborativo

Fatores de influncia na iniciativa de melhoria de processo de software no

Essas mudanas esto associadas reconstruo do modelo de negcio da

empresa, da constante necessidade de inovar e atender a diversos pblicos com

Qualidade de software na viso dos Papas da Qualidade

nveis distintos de exigncia e comportamento. E como no poderia ser diferen-

Testes exploratrios: Teoria e Prtica

Anlise de pontos de funo na prtica

as organizaes atuais a implantarem ciclos de melhoria contnua que impul-

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

sionam, de forma constante, a empresa a buscar o novo. Estes fatores servem

Desejamos uma tima leitura!

13 - Scrum e MPS.BR: Um caso prtico do uso em conjunto destas abordagens

28 - Testes exploratrios: Teoria e Prtica

Brinde na web desta edio

Modstia parte, sua

So programas voltados para a

EDUCAO SUPERIOR ORIENTADA AO MERCADO

Edio 05 - Engenharia de Software Magazine

FDD: agilidade na medida certa

De que se trata o artigo?

Trabalha com gerenciamentos de projetos

Engenharia de Software Magazine - FDD: agilidade na medida certa

Em que situao o tema til?

Colaborao com o cliente mais que negociao de

Edio 42 - Engenharia de Software Magazine

Engenharia de Software Magazine - FDD: agilidade na medida certa

est em um caso de uso com a funo de calcular a mdia de

Na Figura 1, elaborada por Peter Schuh (2005), podem ser

Figura 1. Processo simplificado do FDD

Para Anderson (2004), basicamente os cinco processos do

Tambm fica evidente a preocupao dos seus autores para

O fluxo do FDD pode ser flexibilizado. Necessariamente,

Edio 42 - Engenharia de Software Magazine

Rastreabilidade e relatrios com incrvel preciso, j que se

O Gerenciamento do Projeto no FDD

Como se pode perceber, a base do FDD est na criao de uma

Engenharia de Software Magazine - FDD: agilidade na medida certa