Edição37 2011

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.
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.
PS- GRADUAO
Engenharia de Software:
Desenvolvimento Java
Engenharia de Software:
Desenvolvimento .NET
GRADUAO
Engenharia de Computao
Anlise e Desenv. de Sistemas
F ORMAES
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
EDITORIAL
M
Ano 3 - 37 Edio - 2011
Impresso no Brasil
Corpo Editorial
Colaboradores
Rodrigo Oliveira Spnola
Marco Antnio Pereira Arajo
Eduardo Oliveira Spnola
Capa
Romulo Araujo - romulo@devmedia.com.br
Diagramao
Janete Feitosa
Reviso e Coordenao Geral
Daniella Costa - daniella@devmedia.com.br
Jornalista Responsvel
Kaline Dolabella - JP24185
Na Web
www.devmedia.com.br/esmag
Apoio
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:
Deise Aleis e Uellen Goulart Atendimento ao Leitor
www.devmedia.com.br/mancad
(21) 2220-5338
Kaline Dolabella
Gerente de Marketing e Atendimento
kalined@terra.com.br
(21) 2220-5338
uitos autores tm dito que para sobreviver voracidade do mercado necessrio agilidade nos negcios, porm qual o significado de tal termo? Segundo o
Gartner Group,agilidade de negcio estar apto a responder rapidamente e eficientemente s mudanas no mundo dos negcios e, transformar essas mudanas em vantagem
competitiva o principal motivo para sua adoo.
Neste contexto, observa-se que cada vez mais organizaes esto adotando a abordagem gil
como uma ttica de sobrevivncia nestes tempos economicamente turbulentos. Isto por sua vez
levou a uma srie de opinies interessantes examinando quais atitudes e atributos seus times
precisam para serem bem sucedidos. Sob esta tica a agilidade de negcio, reconhecida como
a habilidade para mudar o sentido do ambiente e responder eficientemente e efetivamente a
essa mudana, importante.
Acrescentar agilidade aos processos de gesto, em sua essncia j infere um maior nvel de
convergncia entre as iniciativas em TIC (Tecnologias da Informao e Comunicao) e os objetivos do negcio. Contudo, outros benefcios de uma abordagem gil no contexto de negcios
podem ser identificados, como, por exemplo: melhor time-to-market e aumento da velocidade
de tomada de deciso, o que acaba refletindo numa maior competitividade organizacional.
Neste contexto, a chave para realizar a verdadeira agilidade de negcio encorajar os executivos a pensarem nas mudanas de negcio sem se preocupar com as implicaes que as mesmas
traro ao legado de TIC existente na organizao. Em outras palavras, a empresa precisa se tornar
centrada no negcio e no centrada na TIC.
Quando o negcio se torna centrado em si, a organizao se torna hbil a definir, criar e construir novos processos ou funes de negcio. Entretanto, para viabilizar esta viso, essencial que
a TIC cumpra o seu papel de se elevar de uma abordagem puramente operacional ou ttica,
para uma participao mais estratgica, colaborando de modo concreto, inclusive, nas definies
dos objetivos de negcio.
Desta forma acredita-se que os mtodos geis tm muito a contribuir nesta direo atravs da
simplificao das iniciativas da TIC, sensibilizao e valorizao das pessoas, adoo de uma abordagem iterativa e adaptativa, aplicao prtica de seus princpios, valores, prticas e orientaes
sobre sistematizao das iniciativas da gesto em TIC.
Neste contexto, a Engenharia de Software Magazine destaca nesta edio o artigo A necessidade de ser gil. Este artigo tem por objetivo apresentar uma anlise comparativa entre nove
mtodos geis, no sentido de instrumentalizar as equipes e organizaes a obterem melhores
resultados na aplicao de mtodos geis em seus projetos.
Alm desta matria, esta edio traz mais seis artigos:
A difcil arte de administrar estrelas
Maturidade em Desenvolvimento de Software
Ferramentas de Testes de Software
A Gerncia de Projetos de Software em Duas Perspectivas Parte 1
Refatorao para Padres Parte 10
Reengenharia de Software Orientado a Objetos
Desejamos uma tima leitura!
Equipe Editorial Engenharia de Software Magazine
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.

maraujo@devmedia.com.br
Publicidade
Para informaes sobre veiculao de anncio na revista ou no site entre em
contato com:
Cristiany Queiroz
publicidade@devmedia.com.br
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:
Rodrigo Oliveira Spnola - Colaborador
rodrigo.devmedia@gmail.com
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.
Eduardo Oliveira Spnola

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).
Caro Leitor,
Para esta edio, temos um conjunto de 5 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:
NDICE
Por trs do bvio
06 A difcil arte de administrar estrelas
Glnio Cabral
Agilidade
Tipo: Processo
Ttulo: Reuso de software: definies, benefcios e dificuldades Partes
1a3
Autor: Rodrigo Oliveira Spnola
Mini-Resumo: Reuso de software o processo de incorporar em um novo
produto cdigo, especificaes de requisitos e projeto, planos de teste, ou
qualquer produto gerado durante desenvolvimentos anteriores. Neste
contexto, nesta srie de aulas conheceremos alguns conceitos associados
ao reuso de software, assim como alguns benefcios trazidos e dificuldades
em sua implantao.
08 - A necessidade de ser gil
Tipo: Processo
Ttulo: Desenvolvimento dirigido por modelos - Partes 1 e 2
Autor: Rodrigo Oliveira Spnola
Mini-Resumo: O Desenvolvimento de Software Dirigido a Modelos (Model
Driven Development - MDD) promove a utilizao de modelos como artefatos essenciais de desenvolvimento, isto , estes passam a ser tratados como
entidades de primeira classe no desenvolvimento de software, semelhana
do cdigo, alm de fornecer recursos para transformaes automticas entre
estes artefatos. Neste contexto, nesta srie de aulas conheceremos alguns
conceitos associados ao desenvolvimento dirigido a modelos.
Planejamento e Gerncia
Alexandre J. H. O. Luna, Cleyverson Pereira Costa e Hermano Perrelli de Moura
Engenharia
19 - Ferramentas de Teste de Software
Gabriela de Oliveira Patuci
27 - Maturidade em Desenvolvimento de Software

Aline Rodrigues, Roberto B. Figueredo e Rodrigo Oliveira Spnola
33 - A gerncia de projetos de software em duas perspectivas Parte 1

Geraldo Magela Dutra Gonalves
Desenvolvimento
41 - Refatorao para Padres Parte 10
Jacimar Fernandes Tavares e Marco Antnio Pereira Arajo
Edio 05 - Engenharia de Software Magazine
Por trs do bvio

Glnio Cabral
gleniocabral@yahoo.com.br
Administrador de Empresas, ps-graduado em Gesto de Pessoas e msico. Idealizador do site de educao infantil www.novainfancia.com.br.
A difcil arte de administrar estrelas
abe aquele colaborador que toda empresa sonha em ter

no seu quadro de pessoal? Um profissional de primeira
linha, competente ao extremo, fomentador de idias e
grande realizador?
Pois bem, as chamadas estrelas do mundo corporativo
fazem toda a diferena no dia-dia do ambiente de trabalho.
O problema que de vez em quando alguns desses brilhantes
profissionais so acometidos por acessos de estrelismo, que
podem se manifestar na forma de atitudes infantis, megalomanacas e individualistas. Situaes como essas so muito
comuns em times de futebol, empresas e organizaes de
um modo geral, e exigem dos gestores a adoo de posturas
sensatas e equilibradas, tais como:
Reconhecer o valor do profissional talentoso. No d para
negar a importncia que um profissional diferenciado tem
para uma organizao. Por isso preciso valoriz-lo para
mant-lo na equipe. Mas como se valoriza um profissional
que j valorizado naturalmente? Simples, motivando-o. Profissionais diferenciados se sentem motivados, por exemplo,
quando exercem suas atividades em condies de trabalho
compatveis com suas potencialidades. Como tm plena
conscincia de suas capacidades excepcionais, eles fazem
questo de exerc-las com o mximo de eficincia, o que
pressupe uma boa infra-estrutura no ambiente de trabalho.
Outra forma de valoriz-los garantir-lhes a possibilidade
de crescimento junto corporao. Vale lembrar que esses
profissionais so vidos por uma rpida ascenso na carreira,
e a sensao de estagnao profissional a pior sensao que
Engenharia de Software - A difcil arte de administrar estrelas
um deles pode vir a sentir. Em suma, prticas motivacionais

so essenciais para mant-los no quadro efetivo exercendo
suas potencialidades.
Reconhec-lo, no exalt-lo. H uma grande diferena
entre reconhecimento e exaltao. Reconhecer admitir
publicamente determinado desempenho de acordo com
critrios claros de avaliao. uma prtica justa de dar a
Csar o que de Csar. Exaltar, no entanto, colocar quem
quer que seja nas nuvens do cu, como um deus de palet
e gravata, levando-se mais em conta a fama e o histrico da
pessoa do que propriamente a sua produtividade. Ao eleger
determinado colaborador como o melhor da equipe, o gestor poder indiretamente estar promovendo uma atitude de
auto-suficincia e prepotncia no empregado, alm de causar
uma grande desmotivao no restante da equipe. Gestores
que adotam posturas de exaltao podem um dia dizer Cus,
criei um monstro! preciso reconhec-los, no transformlos em monstros.
Administrar com responsabilidade a concesso de privilgios. natural que funcionrios extremamente competentes
tenham privilgios e concesses diferenciadas. No entanto,
em casos de profissionais brilhantes que adotam comportamentos excntricos e irresponsveis, chegando at a prejudicar o clima e a imagem da empresa, tais medidas devem
ser ao menos revistas. Recentes pesquisas comprovaram
que a no punio do mau comportamento de profissionais
talentosos pode fazer com que empregados medianos e no
to imprescindveis assim acabem sendo estimulados a fazer
por trs do bvio
A Engenharia de Software Magazine tem que ser feita ao seu gosto.

Para isso, precisamos saber o que voc, leitor, acha da revista!
D seu voto sobre este artigo, atravs do link:
D
s
D seu feedback sobre esta edio!
Feedback
eu
www.devmedia.com.br/esmag/feedback
sobre e
s
Por fim, deve-se analisar o custo benefcio. claro que no

nada fcil abrir mo de uma estrela. Estrelas so raras, lucrativas
e agregam uma srie de ativos. Estrelas so fundamentais para
a prtica da diferenciao competitiva, prtica essencial para
a sobrevivncia da organizao. Mas at mesmo empregados
de grande talento podem ir longe demais um dia. Em tempos de mercado globalizado, habilidades como facilidade de
relacionamento e capacidade de trabalhar em equipe muitas
vezes so mais bem vistas do que certas competncias tcnicas
acompanhadas de tendncias desagregadoras. Por isso, em casos

extremos, o custo benefcio da permanncia do colaborador na
organizao deve ser cuidadosamente analisado. A depender do
caso em questo, nem sempre valer a pena pagar um alto preo
para se ter uma estrela no time. Estrelas um dia podem perder
o brilho, e assim as perdas podem ser muito maiores.
edio
ta
o mesmo. O que um risco e tanto para a organizao. Uma

coisa a estrela do time se comportar mal, outra coisa o
time inteiro se comportando da mesma forma. A vale o velho
ditado: uma andorinha s no faz vero.
Agilidade
Nesta seo voc encontra artigos voltados para as prticas e mtodos geis.
A necessidade de ser gil

Uma anlise crtica sobre nove mtodos geis
Alexandre Jos Henrique de
Oliveira Luna
ajhol@cin.ufpe.br
alexluna@mangve.org
Doutorando em Cincia da Computao pelo

CIn-UFPE em Governana em TIC (em andamento). Mestre em Cincia da Computao
pelo CIn-UFPE em Gerenciamento de Projetos (2009). MBA em Gesto Estratgica de
TIC, FACIPE (2003). Engenheiro Qumico pela
UFPE (2001). Analista Consultor da ATI-PE,
Gestor de Infraestrutura de TIC da Secretaria Estadual de Educao e Pesquisador do
NUTES-HC-UFPE e GP2-CIn-UFPE.
Cleyverson Pereira Costa

cpc@cin.ufpe.br
Mestre em Cincia da Computao pelo CInUFPE (2009). Especialista em Engenharia de

Software com nfase em Teste de Software
pelo CIn-UFPE (2007). Graduado em Cincia da Computao (2005). Pesquisador do
GP2-CIn-UFPE. Possui experincia na rea
de testes, tendo atuado como Engenheiro de
Testes pelo Motorola Brazil Test Center.
Hermano Perrelli de Moura

hermano@cin.ufpe.br
Possui graduao em Engenharia Eletrnica pela Universidade Federal de Pernambuco (1982), Mestrado em Informtica
pela Universidade Federal de Pernambuco
(1989) e PhD in Computing Science pela
University of Glasgow (1993). certificado PMP (2003) pelo Project Management
Institute. Atualmente Professor Adjunto
e Vice-Diretor do Centro de Informtica da
Universidade Federal de Pernambuco.
De que se trata o artigo?
Em que situao o tema til?
Este artigo tem por objetivo apresentar uma anlise

comparativa entre nove mtodos geis, no sentido
de instrumentalizar as equipes e organizaes a obterem melhores resultados na aplicao de mtodos
geis em seus projetos.
A velocidade de resposta s necessidades do negcio est intimamente ligada competitividade

dos times e organizaes. A aplicao de mtodos
geis, dentre outros benefcios, geram transparncia com usurios, clientes e acionistas. Fatores
como integrao das pessoas tcnicas e de negcio na obteno de resultados de melhor qualidade de forma rpida, facilita o alcance da estratgia
organizacional, o retorno dos investimentos,
dentre outros aspectos essenciais garantia da
sobrevivncia institucional. Este tema essencial para desenvolvedores, lderes de equipes e
profissionais de TIC que desejam colaborar para a
sustentabilidade de suas organizaes.
Para que serve?

Os mtodos geis esto se tornando uma alternativa
concreta para ajudar as equipes de desenvolvimento
de software a tornarem-se aptas a responder de forma rpida, flexvel e eficaz s constantes mudanas
que fazem parte da dinmica natureza dos negcios
das organizaes. Possuir uma viso crtica sobre o
assunto facilita a aplicao destes princpios e prticas no cotidiano das equipes nas empresas.
uitos autores como Roosmalen e Hoppenbrouwers,

Cummins e Sloane et al. tm
dito que para sobreviver voracidade
do mercado necessrio agilidade nos
negcios, porm qual o significado de
tal termo? Segundo o Gartner Group,
agilidade de negcio estar apto a
responder rapidamente e eficientemente
s mudanas no mundo dos negcios e,
transformar essas mudanas em vantagem competitiva o principal motivo
para sua adoo.
Engenharia de Software Magazine - A necessidade de ser gil
Neste contexto, observa-se que cada

vez mais organizaes esto adotando
a abordagem gil como uma ttica de
sobrevivncia nestes tempos economicamente turbulentos. Isto por sua vez levou
a uma srie de opinies interessantes
examinando quais atitudes e atributos
seus times precisam para serem bem
sucedidos. Sob esta tica a agilidade de
negcio, reconhecida como a habilidade
para mudar o sentido do ambiente e
responder eficientemente e efetivamente
a essa mudana, importante.
M etodologias geis
Acrescentar agilidade aos processos de gesto, em sua

essncia j infere um maior nvel de convergncia entre as
iniciativas em TIC (Tecnologias da Informao e Comunicao)
e os objetivos do negcio. Contudo, outros benefcios de uma
abordagem gil no contexto de negcios podem ser identificados, como, por exemplo: melhor time-to-market e aumento
da velocidade de tomada de deciso, o que acaba refletindo
numa maior competitividade organizacional.
Neste contexto, a chave para realizar a verdadeira agilidade
de negcio encorajar os executivos a pensarem nas mudanas de negcio sem se preocupar com as implicaes que as
mesmas traro ao legado de TIC existente na organizao.
Em outras palavras, a empresa precisa se tornar centrada no
negcio e no centrada na TIC.
Quando o negcio se torna centrado em si, a organizao
se torna hbil a definir, criar e construir novos processos ou
funes de negcio. Entretanto, para viabilizar esta viso,
essencial que a TIC cumpra o seu papel de se elevar de
uma abordagem puramente operacional ou ttica, para uma
participao mais estratgica, colaborando de modo concreto,
inclusive, nas definies dos objetivos de negcio.
Desta forma acredita-se que os mtodos geis tm muito a
contribuir nesta direo atravs da simplificao das iniciativas
da TIC, sensibilizao e valorizao das pessoas, adoo de
uma abordagem iterativa e adaptativa, aplicao prtica de seus
princpios, valores, prticas e orientaes sobre sistematizao
das iniciativas da gesto em TIC.
Engenharia de Software
Engenharia de Software uma rea do conhecimento voltada
para a especificao, desenvolvimento e manuteno de sistemas de software, aplicando tecnologias e prticas da cincia
da computao, gerncia de projetos e outras disciplinas,
objetivando organizao, produtividade e qualidade.
Pressman destaca que a Engenharia de software abrange trs
componentes bsicos:
Mtodos: proporcionam os detalhes de como construir o
software. Englobam tarefas como planejamento e estimativa de
projeto, anlise de requisitos de software e de sistemas, projeto
da estrutura de dados, arquitetura de programa e algoritmo
de processamento, codificao, teste e manuteno;
Ferramentas: existem para sustentar cada um dos mtodos.
Algumas ferramentas existentes para apoio so as ComputerAided Software Engineering, conhecidas como ferramentas
CASE;
Procedimentos: constituem o elo entre mtodos e ferramentas. Definem a sequncia em que os mtodos so aplicados.
Desde ento vem prosperando o aparecimento de diversos
mtodos, tcnicas e ferramentas para aperfeioar os processos
de desenvolvimento de software em todo o mundo. Mesmo
com toda esta evoluo, a Engenharia de Software h muito
vinha enfrentando problemas relativos a atraso na entrega
de projetos, oramento extrapolado, insatisfao de clientes
e usurios, alm de conflitos e desgastes entre analistas e
ID
P1
Princpio
P7
A prioridade a satisfao do cliente, mediante o rpido e contnuo fornecimento de

software que agregue um valor ao negcio.
As mudanas so bem-vindas, mesmo no final do desenvolvimento, principalmente se as
alteraes daro vantagem competitiva para os nossos clientes.
Fazer entregas frequentes de software que funcionem a partir de um par de semanas a um
par de meses, sempre procurando o menor intervalo de tempo entre as entregas.
As pessoas de negcio (executivos) e os desenvolvedores devem trabalhar juntos
diariamente e ao longo de todo o projeto.
Construir o projeto em torno de indivduos motivados. Fornecer todo apoio necessrio ao
ambiente do projeto e confiar plenamente na equipe.
O dilogo face a face a mais eficiente e eficaz forma de comunicar as informaes dentro
da equipe de desenvolvimento.
Software que funciona a principal medida de progresso.
P8
Os processos geis promovem um desenvolvimento sustentvel. Os promotores, usurios e
P9
desenvolvedores devem ser capazes de manter um ritmo de trabalho constante por tempo
indeterminado.
A ateno contnua qualidade tcnica e ao bom design melhora a agilidade.
P10
A simplicidade essencial. preciso saber maximizar o trabalho que NO deve ser feito.
P11
As melhores arquiteturas, requisitos e desenhos surgem a partir da prpria Equipe atravs

de sua pr-atividade e auto-organizao (inteligncia coletiva e colaborativa1).
Em intervalos regulares, a Equipe deve refletir sobre como se tornar mais eficaz, e ajustar o
seu comportamento para alcanar este objetivo.
P2
P3
P4
P5
P6
P12
Tabela 1. Princpios geis. FONTE: (BECK et al., 2001)
clientes. Isso se dava, dentre outros fatores, principalmente

em funo dos mtodos disponveis para o desenvolvimento
de software mostrarem-se pesados e burocrticos, ineficientes
e improdutivos.
O Manifesto gil
Sob este contexto e percepo, em 11 de fevereiro de 2001, um
grupo de profissionais e pesquisadores de TI se reuniram com
a finalidade de criar uma mobilizao em torno de uma srie
de valores e prticas de desenvolvimento de software que eles
intitularam de Manifesto for Agile Software Development.
Assim, os dezessete presentes assinaram o seguinte
manifesto:
Estamos descobrindo maneiras melhores de desenvolver software
fazendo-o ns mesmos e ajudando outros a faz-lo. Atravs desse
trabalho, passamos a valorizar:
Indivduos e interao entre eles mais que processos 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
Ou seja, mesmo havendo valor nos itens direita, valorizamos mais
os itens esquerda.
Este Manifesto tambm enuncia os doze princpios de um
processo gil, como podem ser vistos na Tabela 1.
Mtodos geis
Neste contexto e visando a melhores resultados, as empresas
de TIC esto adotando metodologias de desenvolvimento de
software mais flexveis e propcias s frequentes mudanas,

alm de mais interao durante todo o projeto entre os usurios e o prprio sistema. Estas metodologias so chamadas de
geis em contraposio s metodologias pesadas que, tradicionalmente, predominaram na rea, mas que se mostraram
ineficientes e improdutivas (FERREIRA e LIMA, 2006).
Uma premissa fundamental das metodologias geis o reconhecimento da dificuldade do usurio saber de antemo as
funcionalidades que gostaria que o sistema tivesse. Por isso,
essas metodologias adotam a estratgia de criar condies favorveis para as interaes e as retroalimentaes entre usurios
e Equipe durante todo o projeto. Com isso, as metodologias
geis so estruturadas de modo a atender a natureza mutvel
e dinmica do processo de construo de software.
As metodologias geis propem que os projetos devam ser
conduzidos de forma adaptativa, isto , feito atravs de desenvolvimento iterativo e interativo. A ideia central trabalhar com
iteraes curtas. Cada iterao entrega ao seu final um produto
completo e pronto para ser usado, que contm a implementao
de um novo subconjunto de caractersticas. O uso de iteraes
curtas permite aos usurios e clientes fazerem uma avaliao do
software logo que uma verso inicial colocada em produo.
importante salientar que uma das vantagens das metodologias geis em contraposio s metodologias tradicionais a
flexibilidade que estas possuem quando inseridas em ambientes que tm caractersticas como: definio dos requisitos com
grande volatilidade (mudanas constantes), onde as equipes
so pequenas e os prazos so mais curtos, o que por fim caracteriza a necessidade de um desenvolvimento rpido.
Dentre as metodologias geis mais difundidas pode-se
citar o XP e o SCRUM. Contudo, podemos citar tambm:
XPM Extremme Project Management, APM Agile Project
Management, FDD - Feature Driven Development, famlia
Crystal, DSDM - Dynamic System Development Method, ASD
- Adaptative Software Development, dentre outras.
Nas sees seguintes, como resultado de um processo
de reviso sistemtica, sero exploradas cada uma destas
metodologias e visitados seus princpios, valores e prticas.

No entanto, em funo dos modelos SCRUM e XP j serem
bastante conhecidos, os demais modelos sero abordados com
maior nfase.
eXtreme Programming XP
O eXtreme Programming ou XP um modelo gil de desenvolvimento de software criado em 1996 por Kent Bech
no Departamento de Computao da montadora de carros
Daimler Chrysler. Ele possui muitas diferenas em relao a
outros modelos, podendo ser aplicado a projetos de alto risco
e com requisitos dinmicos (vagos ou em constante mudana),
conduzidos por equipes de tamanho mdio e pequeno.
Como todo mtodo gil, o XP procura responder com velocidade s mudanas nas especificaes do projeto, com base
em princpios, valores e prticas bem definidos. Este mtodo
enfatiza o desenvolvimento rpido garantindo a satisfao do
cliente e cumprindo as estimativas do projeto. O XP baseia-se
em cinco valores para guiar o desenvolvimento: Comunicao,
Coragem, Feedback, Respeito e Simplicidade. Segundo Beck, o
mtodo oferece ainda 12 prticas, a saber: i) Jogo do planejamento; ii) Verses pequenas; iii) Metfora; iv) Projeto simples; v) Teste;
vi) Refatorao; vii) Programao em pares; viii) Propriedade
coletiva do cdigo; ix) Integrao contnua; x) 40 horas de trabalho semanal; xi) Cliente presente; e xii) Padres de codificao.
A Figura 1 demonstra uma representao do processo do XP,
incorporando as prticas, princpios e valores.
A comunicao um dos principais valores do XP que visa
incentivar uma melhor integrao entre clientes e desenvolvedores, encorajando a interao e o relacionamento interpessoal.
Segundo Nawrocki et al. (2002), com o incentivo na participao
do cliente no projeto e a liberao de verses frequentes, existe
uma probabilidade menor de ocorrncia de erros, assim como
permite ao time a antecipao soluo de muitos problemas.
A questo da manuteno de sistemas produzidos a partir
de um projeto XP bastante questionada quanto sua eficcia
devido a pouca documentao pregada pela metodologia.
Neste contexto, Nawrocki relata que as
fontes de conhecimento em projetos XP
so: o cdigo fonte, os casos de teste e a
memria dos programadores. O risco
em relao a pouca documentao est
na perda de memria que ocorre naturalmente quando h sada de desenvolvedores do time, o que se torna um fator
mais crtico no caso da manuteno de
projetos mais antigos. Nawrocki afirma,
ainda, que neste caso, a nica base para
a manuteno so o cdigo fonte e os
casos de teste.
SCRUM
Figura 1. Fluxo de trabalho em um projeto XP. FONTE: (SIQUEIRA, 2002)
10
O termo Scrum vem de um estudo feito

por Takeuchi e Nonaka (1986). Como
resultado deste estudo, foi percebido
M etodologias geis
que projetos de curta durao, usando equipes pequenas e

multidisciplinares (cross-functional), produzem melhores
resultados.
O framework Scrum tem como objetivo, segundo Schwaber,
definir um processo para projeto e desenvolvimento de software orientado a objeto, que seja focado nas pessoas e que
seja indicado para ambientes em que os requisitos surgem
e mudam rapidamente. O Scrum tambm considerado um
mtodo especfico para o gerenciamento do processo de desenvolvimento de software.
Seu ciclo de vida baseado em trs fases principais. A
fase de pr-planejamento, desenvolvimento e a fase de psplanejamento. O pr-planejamento dividido em duas fases
secundrias: a fase de planejamento e a de arquitetura do
projeto.
No Scrum, todo o desenvolvimento feito em iteraes:
todo o esforo orientado para que seja apresentado um novo
conjunto de funcionalidades ao final de cada iterao, denominada de sprint, para a qual sugerida uma durao de duas a
quatro semanas. A Figura 2 apresenta, de forma simplificada,
o desenvolvimento de um projeto utilizando o Scrum.
O Scrum define trs papis distintos: 1) Equipe responsvel
por entregar solues, geralmente formada por um grupo
pequeno (entre cinco e nove pessoas) e que trabalha de forma
auto-gerenciada; 2) Product Owner responsvel pela viso
de negcios do projeto, ele quem define e prioriza o Product
Backlog. Geralmente o papel desempenhado pelo cliente; 3)
Scrum Master uma mistura de gerente, facilitador e mediador. Seu papel remover obstculos da equipe e assegurar que
as prticas de Scrum esto sendo executadas com eficincia.
O desenvolvimento do produto, baseado no Scrum inicia com
a definio do Backlog pelo Product Owner. Posteriormente o
projeto organizado em Sprints e o Product backlog dividido
em Sprint Backlogs para que os itens selecionados possam
ser desenvolvidos. Ao final da Sprint, a Equipe demonstra os
resultados para o Product Owner e demais interessados, de
forma que os itens do Backlog sejam considerados prontos e
ento possa se iniciar um novo Sprint.
eXtreme Project Management - XPM

O XPM, ou eXtreme Project Management, prope melhorar o
gerenciamento de projetos desenvolvidos segundo o paradigma
gil, com nfase no XP. Este mtodo visa em especial os e-projects,
ou seja, projetos de software para os quais o tempo e o custo para
tornar o produto disponvel no mercado so crticos.
A principal diferena do XPM est na atitude em relao s
mudanas. Diferentemente da abordagem tradicional, na qual o
planejamento direciona os resultados, no XPM so os resultados
que direcionam o planejamento, sendo necessrio facilitar a mudana e no desencoraj-la. Segundo BECK, o mtodo definido
por 11 regras, descritas a seguir:
1. A gerncia de pessoas e de processos criativos demanda
processos de gerenciamento criativos. Tanto gerente quanto a
equipe precisam ser criativos no desenvolvimento de um produto
inovador, com alto valor para o negcio e maior qualidade;
Figura 2. Ciclo de Vida do Scrum. FONTE: (MOUNTAIN GOAT, 2009)
2. O contexto mais importante do que o contedo. O gerente

de projetos no XPM deve estar focado no aspecto empresarial
do projeto, ou seja, nos objetivos e nos benefcios do projeto, ao
invs dos aspectos tcnicos do produto ou servio que est sendo
realizado no projeto;
3. Ciclo de vida do projeto inclui perodo ps-implantao. O
que acontece depois que o projeto termina mais importante do
que os problemas que acontecem durante o projeto;
4. O gerente de projetos deve ter o perfil mais facilitador e
integrador do que o perfil de gerente. Para aumentar as chances de sucesso de um projeto empresarial, o gerente de projetos
deve mudar o foco do planejamento tcnico para a facilitao e
a integrao do processo de planejamento, com a participao
efetiva dos stakeholders;
5. Quanto mais tempo o gerente de projeto permanecer com os
stakeholders, melhor. O XPM est mais relacionado ao contexto do
projeto no que diz respeito disseminao da informao gerencial do negcio, do que com o seu contedo no que diz respeito
s especificaes tcnicas e entregas;
6. Stakeholders funcionam como Gerente Executivo de Projetos.
No XPM, os stakeholders devem ter as seguintes responsabilidades adicionais: i) participar das sesses de planejamento do
projeto que definem escopo, objetivos, stakeholders e benefcios;
ii) assistir o Gerente de Projetos nas disputas polticas e de poder
na organizao que influenciam o projeto; e iii) monitorar indicadores crticos do projeto, de custos e de prazo;
7. Se o sucesso do projeto no foi definido no comeo, ele no
ser alcanado no final. O sucesso em um projeto est geralmente
associado a: i) satisfazer os stakeholders; ii) atingir as exigncias
de escopo; iii) permanecer dentro do oramento e dos prazos
estabelecidos; iv) agregar valor ao negcio; v) assegurar uma boa
qualidade ao produto; e vi) deixar os membros da equipe satisfeitos. Os critrios de sucesso devem ser definidos logo de incio
e acompanhados durante todo o desenvolvimento;
8. Planejamento por cenrio ao invs de macroplanejamento.
Grande parte dos projetos empresariais possui o nvel de
incerteza muito alto, assim como o ritmo de mudanas. Por
isso, fazer o planejamento detalhado das fases do projeto
fornece uma alta probabilidade de retrabalho e constante
replanejamento;
9. Lucro ao invs de papelada burocrtica. No XPM, a documentao a mnima necessria para o desenvolvimento
e o acompanhamento do projeto. O importante modelar e
11
apresentar o valor agregado de acordo com a qualidade requerida e buscar o equilbrio entre a necessidade de negcio
que est sendo atendida e o retorno de investimento que isso
traz ao negcio. Mostre os lucros aos stakeholders e nada
mais importa;
10. Se o seu projeto no mudou, fique apreensivo. Gerente e
equipe devem reunir-se diariamente para avaliar se houve
alterao em expectativas de sucesso, escopo, objetivos, riscos,
qualidade, stakeholders ou projetos relacionados, bem como
verificar se suposies referentes a custo e benefcio continuam
pertinentes;
11. Em e-projects, um dia um tempo muito longo. O gerenciamento efetivo de e-projects demanda uma abordagem nova
e radical para o gerenciamento de projetos.
Agile Project Management - APM

A abordagem APM - Agile Project Management foi desenvolvida por um grupo de gerentes de vrios projetos XP bem sucedidos
da CC Pace Systems. Em sua concepo eles consideraram que a
adoo ainda lenta das metodologias geis origina-se principalmente da falta de alinhamento entre as suposies fundamentais
da gerncia tradicional e das metodologias de desenvolvimento
geis. Tambm alertaram para a necessidade de mudana em relao a estas suposies, propondo o desenvolvimento de um novo
framework para o apoio gerencial ao desenvolvimento gil.
Na busca deste novo framework, eles passaram a acreditar fortemente na adoo de princpios que explorassem a compreenso
do comportamento humano autnomo, adquirida a partir do
estudo de sistemas vivos existentes na natureza como revoadas,
cardumes e enxames , incluindo nas suposies e prticas de
gerncia a noo de sistemas adaptativos complexos (Complex
Adaptive Systems CAS). Apesar destes sistemas possurem
somente regras e capacidade estratgicas no contexto do prprio
sistema (ou grupo em anlise), seu comportamento coletivo
caracterizado por uma superposio de ordem, auto-organizao
e uma inteligncia coletiva que maior que a soma das partes,
alm de regularmente exibirem uma habilidade notvel para se
adaptarem a ambientes complexos e dinmicos.
Por exemplo, em uma equipe XP, os gerentes de projeto tambm
precisam de um conjunto de prticas simples que os guiem, que
forneam um framework dentro do qual possam administrar, e
no de um conjunto de instrues rgidas. Seguindo estas prticas,
o gerente torna-se um lder com capacidade de adaptao, capaz
de fixar uma direo, estabelecer regras simples e geradoras do
sistema, bem como encorajar uma constante avaliao (feedback),
adaptao e colaborao.
O framework para gerncia de projeto gil baseado em CAS
composto por seis prticas-chave que, juntas, ajudam a administrar equipes de desenvolvimento como sistemas adaptveis
complexos, ao mesmo tempo em que proporcionam liberdade
para sobrepor estilos prprios de liderana pessoal. Uma descrio resumida destas prticas apresentada a seguir:
1. Viso Direcionada Estabelea uma viso direcionadora para
o projeto e reforce-a continuamente, por meio de palavras e aes.
importante transmitir e manter no time sempre a viso do todo,
12
para que seja mais fcil para cada um compreender, transmitir e

mesmo supervisionar a produo das partes e a sua integrao
na formao do todo. A viso precisa ser sempre difundida, atualizada e preservada de agentes internos ou externos ao time;
2. Trabalho e Colaborao em Equipe Facilite a colaborao
e o trabalho em equipe reforando relacionamentos. Quando o
trabalho conjunto aprimora e refora os potenciais individuais
complementares, os resultados obtidos podem ser excepcionais.
Contudo, conseguir que as pessoas trabalhem de forma colaborativa um desafio e no pode acontecer por imposio;
3. Regras Simples Estabelea e apoie um conjunto de prticaschave (guias). Estabelea e fomente um conjunto de prticas
simples que possam fornecer suporte para um comportamento
complexo, permitindo equipe trabalhar dentro de uma estrutura flexvel;
4. Informao Aberta Fornea acesso aberto informao. O
compartilhamento da informao e o sentimento de propriedade
coletiva potencializam os resultados alcanados pela equipe;
5. Toque leve Aplique somente o controle suficiente para manter
a ordem emergente. O controle inteligente de equipes requer uma
sutil combinao de ordem imposta e emergente;
6. Vigilncia gil Aplique um contnuo monitoramento,
aprendizado e adaptao ao ambiente. O trabalho mais criativo
e gil ocorre no limiar entre a ordem e o caos imprevisvel o
bastante para ser desafiador, mas ordenado o suficiente para no
sair de controle.
easY Process - YP
O Departamento de Sistemas e Computao da Universidade
Federal de Campina Grande (UFCG) criou em maio de 2003 o
easY Process - YP, um processo de software mais simplificado
que se apoia em prticas do XP, RUP e Agile Modeling.
A necessidade de se criar um novo processo surgiu devido s
dificuldades encontradas em se adaptar os processos j existentes para o uso na academia. O Fluxo bsico est ilustrado
na Figura 3. Os tempos apresentados nos retngulos desta
figura denotam os tempos estimados pelo YP para o avano
de cada etapa do processo.
A primeira etapa do processo consiste na definio de
papis. O YP sugere os seguintes papis: cliente, usurio, testador, desenvolvedor e gerente; podendo uma mesma pessoa
desempenhar mais de um papel dentro do processo, principalmente quando se tratam de equipes de desenvolvimento
pequenas. Em seguida deve ser realizada uma conversa com
o cliente, onde informaes sobre o escopo do problema so
capturadas. A partir de ento, a equipe encontra-se apta a gerar o documento de viso, que aps ser validado pelo cliente,
funciona como um acordo de trabalho entre cliente e equipe
de desenvolvimento.
Na fase de inicializao o cliente define as User Stories e so
elaborados o projeto arquitetural e o modelo lgico de dados
este ltimo apenas se necessrio. O cliente deve priorizar
as User Stories e a equipe deve fazer uma estimativa inicial
do tempo para implementao de cada uma delas. Baseado
nessa estimativa pode-se ento verificar a viabilidade de
M etodologias geis
desenvolvimento do projeto no escopo e

tempo definidos.
Parte-se ento para o Planejamento, fase composta por dois planos, o de release e o de iterao. Ambos possuem tempo fixo com variao
de escopo permitida. Tratando-se do ambiente
acadmico so sugeridos trs releases, cada um
com duas iteraes de duas semanas, por semestre letivo. O planejamento de um release s
ocorre aps o trmino do anterior, e da mesma
forma para as iteraes. No planejamento de release alocaram-se as User Stories de acordo com
a priorizao do cliente. No planejamento de
iterao as User Stories alocadas so quebradas
em tarefas, e o cliente deve definir os testes de
aceitao para cada User Story. Para auxlio na Figura 3. Fluxo do YP. FONTE: (YP, 2006)
gerncia o processo faz uso da Tabela de Alocao de Tarefas (TAT), na qual se especificaram as User Stories
parte iterativa dos processos de FDD (projetar por caracterstienvolvidas, tarefas, responsveis, estimativas de tempo, tempo
ca e construir por caracterstica) suporta o desenvolvimento
real consumido e status da tarefa. Estes dois ltimos atributos
gil com adaptaes rpidas s mudanas, de acordo com as
so preenchidos apenas no fechamento da iterao.
exigncias e as necessidades do negcio. As iteraes do projeto
Segundo Garcia, algumas caractersticas importantes do YP
e a construo de uma caracterstica (feature) seguem por um
so:
perodo de uma a trs semanas de trabalho.
Participao efetiva do cliente: fator imprescindvel para o
A seguir esto descritos sucintamente os cinco processos ilussucesso do projeto;
trados na Figura 4.
Papis diferentes desempenhados pela mesma pessoa: neces Processo 1: Desenvolver um modelo abrangente Os
srio quando se trabalha com equipes pequenas;
membros de um projeto devem estar cientes do contexto e das
Releases e iteraes curtas: tratando-se do ambiente acadmico
exigncias do sistema a ser construdo logo no incio do desenso sugeridos trs releases, cada um com duas iteraes de duas
volvimento do projeto. Isso alcanado por meio de casos de uso
semanas;
ou especificaes funcionais exigidos neste processo;
Variao no escopo e no no tempo, tanto no release quanto
Processo 2: Construir uma lista de Caractersticas A
na iterao. Este um princpio baseado no paradigma gil que
equipe identifica as caractersticas, agrupa-as hierarquicamente
considera fixos o tempo e os recursos e permite variar dentro de
e atribuem prioridades e tamanho. Entre as tarefas deste prouma iterao o escopo;
cesso incluem a formao da equipe que ir projetar a lista de
Forte enfoque nos testes, em boas prticas de programao,
caractersticas;
propriedade coletiva de cdigo e refatoramento;
Processo 3: Planejar por Caractersticas Um plano de projeto
Acompanhamento do progresso do projeto atravs de mtricas
construdo e usado nos processos seguintes, determinando a
pr-definidas (user stories alcanadas, classes produzidas, testes
sequncia de desenvolvimento com as prioridades e as datas que
realizados) reunidas no Big Chart;
cada caracterstica deve ser completada;
Manuteno do repositrio de cdigo com ferramentas de
Processo 4: Projetar por Caractersticas Um pequeno
controle de verso.
grupo de caractersticas selecionado do conjunto de caractersticas. Deste grupo so identificadas as classes que esto
Feature Driven Development FDD
envolvidas e os seus respectivos proprietrios. Cada caracteCriado por Jeff de Luca e Peter Code, o FDD um mtodo gil
rstica selecionada ir passar por esta etapa, em que a equipe
e adaptvel ao sistema. Este mtodo no cobre o processo inteiro
de caractersticas define um diagrama de sequncia detalhado
de desenvolvimento do software, mas focaliza-o particularmente
para ela. Os proprietrios das classes estruturam suas classes
no projeto e nas fases de construo.
e mtodos. No final a equipe faz uma inspeo no projeto. EnO FDD incorpora o desenvolvimento iterativo e as melhotre as tarefas deste processo incluem a formao da equipe de
res prticas da modelagem gil. Os aspectos de qualidade
projeto e a definio de um guia de domnio, a construo do
so enfatizados durante todo o processo de desenvolvidiagrama de sequncia, a estruturao das classes e mtodos e
mento, incluindo entregas frequentes e tangveis, bem
a inspeo do projeto;
como monitorao do progresso do projeto no perodo de
Processo 5: Construir por Caractersticas Neste processo
desenvolvimento.
so realizados a implementao das classes e mtodos, a insFDD possui cinco processos sequenciais durante o projeto e
peo do cdigo, os testes de unidade e o desenvolvimento de
o desenvolvimento do sistema, como ilustrado na Figura 4. A
cada caracterstica ou conjunto delas.
13
Em relao s prticas definidas no FDD, elas no so extremamente rgidas, pregando a adaptao ao ambiente de
desenvolvimento. No entanto, existe um conjunto de prticas
que so fundamentais e que definem o FDD:
Modelagem em objetos de domnio: construir um diagrama de classes bsico com os objetos de domnio e suas
relaes, definindo assim uma arquitetura bsica para o
modelo do sistema;
Desenvolvimento por caractersticas: a implementao
deve ser orientada pelas caractersticas;
Autoria individual: o cdigo de autoria de um dono da
classe, o que permite uma maior rapidez na implementao
das tarefas associadas;
Times da caracterstica: para a implementao de uma
determinada caracterstica, o chefe programador recruta os
donos das classes que sero usadas. Esse grupo de pessoas
o time da caracterstica;
Inspees: o meio atravs do qual ocorrem as verificaes
de qualidade do cdigo e do projeto;
Integrao (build) regular: em um determinado perodo de
tempo fixo devem ser integradas as caractersticas j terminadas, permitindo a verificao de erros e tambm criando
uma verso atual que pode ser demonstrada ao cliente;
Gerncia de configurao: visa gerenciar todo o ciclo de
vida dos itens de configurao do projeto, realizando o controle de verses de todos os artefatos criados;
Reportar/Visibilidade dos resultados: permitir que se
conhea o progresso do projeto.
Famlia Crystal
Criado por Alistair Cockburn, a famlia de mtodos Crystal
prioriza a comunicao entre os participantes do projeto e
inclui um nmero diferente de mtodos que atendem projetos
com caractersticas distintas. A famlia Crystal formada por: i)

Crystal Clear; ii) Crystal Yellow; iii) Crystal Orange; iv) Crystal
Red; e v) Crystal Orange/Web. A escolha de um mtodo deve
ser baseada no tipo de projeto. A dimenso e o tamanho de um
projeto so representados por smbolos, onde cada um denota
uma categoria que especifica o tipo de projeto com relao ao
tamanho e a complexidade.
A Figura 5 apresenta a distribuio dos mtodos da famlia
Crystal a partir da anlise de duas dimenses: a criticidade
do produto a ser construdo pelo projeto versus a quantidade
de colaboradores envolvidos.
Conforme as cores dos membros da famlia Crystal se tornam mais escuras, tem-se um maior peso dos mtodos, o que
necessrio devido complexidade dos projetos. Esse peso
representado pela quantidade de artefatos e a rigidez da
gerncia, itens que so absorvidos entre os 13 elementos definidos para cada mtodo: papis, habilidades, times, tcnicas,
atividades, processos, artefatos, produtos de trabalho, padres,
ferramentas, personalidades, qualidade e valores da equipe.
As regras, caractersticas e valores so comuns em todos os
mtodos da famlia Crystal. Segundo Cockburn, dois valores
prprios da famlia Crystal so a alta tolerncia e o fato de ser
centrada em comunicao e pessoas. A tolerncia relacionase ao comportamento humano com relao s ferramentas e
produtos de trabalho utilizados em um projeto Crystal.
Segundo Cockburn, os princpios do Mtodo da Famlia
Crystal so os seguintes:
O time pode reduzir o trabalho em produtos intermedirios,
para produzir cdigo rodando mais frequentemente, atravs
do uso de canais de comunicao mais ricos entre as pessoas,
como o contato face-a-face;
Como cada projeto diferente e evolui ao longo do tempo,
o conjunto de prticas que a equipe adota tambm deve ser
adaptado e evoludo;
Os gargalos de mudana no software determinam a utilizao
do trabalho sobreposto (aquele que realizado por pessoas
distintas do time) e apontam os detentores de informao sobre
o projeto. Ou seja, fica fcil identificar quais pessoas do time
detm informaes essenciais sobre o projeto e gerenci-los.
Figura 4. Processos FDD. FONTE: adaptado de (ABRAHAMSSON et al., 2002)
As duas regras comuns Famlia Crystal, so:

O projeto precisa usar desenvolvimento incremental, com
incrementos de quatro meses ou menos (com forte preferncia
a incrementos de um a trs meses);
O time precisa realizar oficinas de reflexo pr e ps-incremento (com forte preferncia para a realizao de oficinas
no meio do incremento, tambm). Em outras palavras, antes,
durante e aps a finalizao de cada iterao.
Figura 5. A distribuio dos mtodos da famlia Crystal a partir de duas

dimenses. FONTE: Adaptado de (COCKBURN, 2000)
14
As duas tcnicas base em Crystal so:

A metodologia refinada pela tcnica: usando entrevistas de
projeto e oficinas com a equipe para converter e aperfeioar a
metodologia de referncia em um conjunto de regras prticas
para a conduo do projeto. Estas regras devero ser aperfeioadas pelo time na medida em que o projeto avana;
M etodologias geis
A tcnica usada para aplicar as oficinas de reflexo, que

devem ser refinadas pelo prprio time.
Ainda de acordo com Cockburn, o time pode substituir as
tcnicas acima por outras que julgar melhor no apoio para o
cumprimento das suas metas.
O cerne da filosofia Crystal considerar o desenvolvimento de
software como um jogo cooperativo de inveno e comunicao,
com o objetivo principal de fornecimento til de software. Duas
consequncias dessa filosofia so que diferentes projetos precisam
ser executados de forma diferente, e a quantidade de modelagem
e de comunicao que as pessoas precisam fazer apenas a
quantidade de que necessitam para fazer o jogo progredir. Os
membros da famlia Crystal compartilham: i) valores e princpios;
e ii) adaptao on-the-fly, ou seja, ajuste da forma de trabalho
durante a execuo do projeto.
Uma crtica comum a esta metodologia o excesso de simplicidade, de forma que para grandes projetos recomenda-se o uso
de mtodos geis com mais recursos, como por exemplo, o ASD
(Adaptative Software Development).
Dynamic Systems Development Method DSDM

O Dynamic Systems Development Method - DSDM uma formulao dos mtodos RAD (Rapid Application Development) organizada
por um consrcio de companhias membros que, alm de fornecer
servios e treinamentos, tambm cuida do licenciamento de uso
do mtodo.
As ideias principais do DSDM podem ser observadas no conjunto de princpios que foram definidos para nortear o mtodo:
O envolvimento ativo do usurio imperativo;
O time deve ter o poder para tomar decises;
O foco na entrega frequente de produtos;
O encaixe ao propsito do negcio o critrio essencial para a
aceitao das entregas;
O desenvolvimento iterativo e incremental necessrio para
convergir com preciso s solues do negcio;
Todas as mudanas durante o desenvolvimento so
reversveis;
Requisitos so alinhados em um alto nvel;
O teste integrado por todo o ciclo de vida;
Uma abordagem colaborativa e cooperativa entre as partes
envolvidas essencial.
Alm desses princpios, existem algumas tcnicas principais que
so usadas durante a execuo de um projeto usando DSDM:
Time-box: definio de um perodo fixo para a execuo do
projeto, colocando at datas de entrega. Com isso, caso haja alguma funcionalidade que no possa ser implementada durante
o perodo estipulado, ela deve ser feita aps o desenvolvimento
em si (antes da fase de ps-projeto);
MoSCoW: regra bsica para a priorizao de requisitos durante
o perodo de desenvolvimento. A ideia fundamental priorizar
e implementar os requisitos que sejam considerados principais,
deixando os menos importantes para depois;
Modelagem: no deve ser uma atividade burocrtica, sendo
usada para prover um melhor entendimento do problema e da

soluo;
Prototipao: forma de verificar a adequao dos requisitos
e facilitar as discusses com o cliente. O prottipo criado deve
evoluir juntamente com o projeto;
Teste: essa atividade deve ser executada sistematicamente e de
forma contnua durante o projeto;
Gerncia de configurao: essencial, visto que os produtos so
entregues com uma grande frequncia.
Em relao ao processo do DSDM, existem cinco fases bsicas,
que podem ser vistas na Figura 6, antecedidas por uma fase de
pr-projeto e precedidas pelo ps-projeto. No pr-projeto, tem-se
como objetivo definir se o projeto deve ou no ser implementado, observando aspectos gerenciais bsicos, como questes
financeiras e um plano para o estudo de viabilidade. O estudo
de viabilidade em si feito na etapa seguinte, em que se verifica
se o DSDM a soluo mais adequada, alm das atividades tradicionais em um estudo desse tipo. Na etapa seguinte, de estudo
do negcio, so observados os processos que sero afetados e
as suas necessidades de informao (DSDM, 2003), definindo o
escopo do projeto.
Posteriormente iniciado o desenvolvimento em si, que executado de forma interativa em cada uma das trs fases seguintes:
modelagem funcional, projeto e construo e implementao.
Como a transio entre essas fases algo bastante complicado, a
deciso de quando e como isso deve acontecer acaba sendo feita de
projeto a projeto, podendo haver sobreposio e mescla entre elas.
Alm disso, a qualquer momento pode haver um refinamento do
projeto, fazendo com que se volte a fases anteriores para corrigir
problemas, solucionar dvidas, etc.
Na primeira fase de desenvolvimento, que cuida do modelo
funcional, os requisitos (funcionais e no funcionais) so obtidos,
montando uma lista de prioridades e colocando-os no prottipo.
Em seguida documentada a maioria dos requisitos dessa forma
(visual), atravs de esboos de tela, ao invs da especificao
textual. Na fase de implementao feita a transio do sistema
do ambiente de desenvolvimento para o operacional, cuidando
do treinamento e outras tarefas que sejam necessrias.
Ao finalizar as etapas de desenvolvimento com um resultado
satisfatrio na realizao dos requisitos, chega-se a fase de psprojeto. Nela feita a manuteno do sistema, realizando as
tarefas de alterao praticamente da mesma forma que foi feito
o desenvolvimento.
A equipe em um projeto DSDM, segundo Abrahamsson et al.
(2002), pode variar entre duas a seis pessoas, podendo existir
vrias equipes pequenas em um projeto. Em uma equipe de duas
pessoas deve existir pelo menos um usurio e um colaborador.
Adaptative Software Development ASD

Criado por Jim Highsmith, o mtodo Adaptative Software
Development baseia-se tambm em prticas derivadas do RAD,
orientando o desenvolvimento para aceitar as mudanas. Este
mtodo tem seu foco voltado principalmente para resolver problemas no desenvolvimento de sistemas grandes e complexos.
15
O mtodo incentiva fortemente o desenvolvimento incremental, iterativo e com prototipao constante.

Sob esse panorama, o ASD prope atualizar o ciclo de desenvolvimento baseado em planejar, projetar e construir, trocando-o
por um com as fases de especular, colaborar e aprender. Essa
mudana seria necessria devido ao enfoque diferente dos dois
ciclos: o primeiro considera a estabilidade no ambiente de negcios, enquanto o segundo foca em ambientes de incerteza e de
grande mudana viso comum a todos os mtodos geis.
O processo de desenvolvimento guiado por meio de ciclos,
compostos por trs fases: especulao, colaborao e aprendizado. Segundo Highsmith, o ASD permite mudanas no projeto, no visualizando as mudanas como um problema, mas sim
como uma vantagem. A no resistncia a mudanas enfatiza
uma caracterstica dos mtodos geis, que ser adaptativo.
Na Figura 7 apresenta-se o ciclo de vida do mtodo ASD. Na
fase de especulao realizado o planejamento do projeto, a
fase de colaborao apoia a equipe de trabalho nas mudanas
do projeto e a fase de aprendizado representa o conhecimento
envolvido no projeto, enfatizando o reconhecimento de erros
e mudanas durante o desenvolvimento.
O enfoque no ciclo ASD mais voltado aos resultados com
qualidade, do que s tarefas a serem desempenhadas. As
tarefas representam as atividades existentes para o desenvolvimento das funcionalidades.
Na Figura 7 apresentam-se as fases do ciclo de vida do mtodo
ASD. A primeira fase define a atividade para a iniciao do projeto e a atividade responsvel pelo ciclo de desenvolvimento
adaptvel (fase de especulao). A fase de colaborao possui
uma atividade utilizada para o desenvolvimento do componente
(mdulo) e a fase de aprendizado engloba as atividades de reviso, qualidade e liberao de verses. Na fase de aprendizado
existe um retorno que vai da atividade de reviso de qualidade e

volta para a atividade de ciclo adaptvel da fase de especulao,
o que representa o ciclo de aprendizado do mtodo. Os ciclos
duram em mdia de quatro a oito semanas.
O ciclo ASD possui seis caractersticas bsicas que devem
ser seguidas em um projeto. Essas caractersticas so apresentadas a seguir:
Conduzido misso - as atividades em cada ciclo de desenvolvimento devem ser ajustadas de acordo com o projeto;
Baseado em mdulos as atividades no devem ser orientadas
a tarefas, mas de preferncia ao desenvolvimento do software,
construindo pequenas verses em pequenos perodos;
Iterativo o desenvolvimento deve ser bem compreendido
e bem definido;
Quadro do tempo a ambiguidade em projetos complexos
com relao a prazos pode ser evitada com o uso de histricos
de projetos anteriores. A gerncia do projeto fora os participantes a tomarem decises inevitveis no incio do projeto;
Dirigido aos riscos as mudanas so frequentes no desenvolvimento do software e devem ser avaliadas constantemente
para sua adaptao;
Tolerante a mudanas as mudanas que proporcionam
risco ao projeto devem comear o mais rpido possvel.
O ASD prope poucas prticas para o trabalho de desenvolvimento do software, sendo basicamente trs: desenvolvimento
iterativo, planejamento (baseado em mdulos) e revises de grupo voltadas para o cliente. Neste mtodo existem poucas prticas
para o dia-a-dia do trabalho do time. Basicamente sugerido: i)
desenvolvimento iterativo; ii) desenvolvimento e planejamento
baseado em funcionalidades (e componentes); iii) avaliaes de
grupo com foco no cliente. De fato, talvez o mais significativo
problema com ASD seja que suas prticas se tornam difceis de
identificar e deixam muitos detalhes em aberto.
Anlise Comparativa
Cada mtodo gil possui caractersticas que influenciam no
funcionamento e no desenvolvimento do projeto de software.
Algumas caractersticas podem ser encontradas em vrios
mtodos e outras so especficas de cada um.
Desenvolvimento dirigido por planejamento
Desenvolvedor com habilidades variadas
Nveis de capacidade do cliente podem variar
Figura 6. O Processo DSDM. FONTE: Adaptado de (DSDM, 2003)
Figura 7. Ciclo de vida do ASD. FONTE: Adaptado de (HIGHSMITH, 2002b).
16
Abordagem gil
Desenvolvedor gil, educado, disposto e
colaborador
Clientes mais representativos e autorizados
Confiana em conhecimento documentado, explcito Confiana em conhecimento interpessoal, tcito

Requisitos conhecidos e altamente estveis
Requisitos emergentes, mudana rpida
Projetado para requisitos atuais e previsveis
Projetado para requisitos atuais
Retrabalho e reestruturaes de cdigo so caros
Retrabalho e reestruturaes de cdigo so baratos
Equipes e produtos maiores
Equipes e produtos menores
Premia a garantia da qualidade obtida
Premia o valor rpido obtido
Tabela 2. Comparao entre os pressupostos do desenvolvimento

dirigido por planejamento e da abordagem gil. FONTE: Adaptado de
(MAGALHES et al., 2005)
M etodologias geis
Mtodos
XP
SCRUM
XPM
APM
YP
FDD
Crystal
DSDM
ASD
Pontos chave
Principais Caractersticas
Limitaes/ Falhas
Desenvolvimento dirigido pelo cliente, equipes pequenas e

verses frequentes.
Enxuto, auto-organizvel, ciclo de desenvolvimento de at
15 dias.
Complementa a carncia de abordagem gerencial do XP.
Recomendada aplicao conjunta.
Refatorao do software melhora o desempenho e Pouca ateno no uso de prtica de gerenciamento.

responsvel pelas mudanas.
Viso do produto bem definida e repetvel.
Carente de testes de integrao e omisso em relao a
aspectos de implementao.
Voltado para e-Projects. Os resultados direcionam o As prticas so muito subjetivas. necessrio alto grau
planejamento e as mudanas so encorajadas.
de maturidade do Gerente de Projeto para coloc-las em
prtica.
Acredita fortemente na adoo de princpios que explorem Considera que o comportamento coletivo caracterizado Requer muita experincia do Gerente na liderana de
a compreenso do comportamento humano autnomo.
por uma superposio de ordem, auto-organizao e uma pessoas para se extrair o melhor resultado do mtodo. No
inteligncia coletiva que maior que a soma das partes.
recomendado para Equipes pouco maduras.
Processo simplificado que se apoia em prticas do XP, RUP Visa aplicao em projetos acadmicos, ou comerciais de Recomendado para projetos de escopo pequeno, que possam
e Agile Modeling.
pequeno ou mdio porte.
ser concludos em at quatro meses.
Formado por cinco processos e iteraes curtas.
Mtodo simples, desenvolvimento por caractersticas e Foco restrito ao projeto e implementao.
modelagem de objeto.
Vrios mtodos com caractersticas diferentes.
Capacidade de selecionar o mtodo mais adaptvel ao Dificuldade no uso de estimativas.
projeto.
Uso do RAD, equipe com autonomia para tomar decises. Utiliza a prototipao e possui vrios papis (responsveis) Somente os membros da equipe tm acesso aos
para execuo de uma atividade no mtodo.
procedimentos do mtodo, no envolvendo o cliente.
Foca no ciclo adaptvel, colaborativo e no desenvolvimento Oriundo da filosofia de Sistemas Adaptativos.
Baseia-se mais nos conceitos e na cultura gil do que em
iterativo.
prticas geis.
Tabela 3. Comparao entre os mtodos geis revisados. FONTE: Adaptado de (ABRAHAMSSON et al., 2002)
Neste artigo foram apresentadas reflexes sobre porque

adotar uma abordagem gil para os processos de negcio
das organizaes. Foram apresentadas algumas definies
sobre processo de desenvolvimento de software, assim como
a origem da formao da Aliana gil, atravs do Manifesto

Feedback
eu
17
sobre e
s
Concluses
D
s
gil, seus princpios e valores comuns a todos os mtodos

geis.
No decorrer deste artigo foram apresentados nove mtodos
geis, abordando seu processo de desenvolvimento e as prticas
existentes em cada um. Alm disso, foi apresentado tambm
um estudo comparativo dos processos de desenvolvimento
gil abordados. A reviso sistemtica realizada neste artigo
a respeito de metodologias geis est diretamente associada
com a necessidade de identificao dos princpios, valores e
boas prticas geis que possam ser adequados e aplicados aos
negcios de cada organizao.
Espera-se que os resultados da anlise comparativa, bem
como o conjunto de conhecimentos explorados neste artigo
sirvam de base para a formao de uma viso crtica sobre
a aplicao de mtodos geis na indstria de software, assim como no comportamento das equipes envolvidas neste
contexto. Possibilitando, desta forma, a gerao de um senso
analtico sobre em que circunstncias cada um dos mtodos
aqui explorados melhor se adquam natureza dos projetos em
andamento em nossas organizaes. E permitindo, inclusive,
uma reflexo sobre a pertinncia de utilizao combinada
de alguns mtodos geis, em funo das caractersticas das
variveis envolvidas em cada projeto, como: cliente, equipe,
restries e premissas, dentre outras.
edio
ta
Na Tabela 2 apresenta-se um estudo comparativo entre os

pressupostos do desenvolvimento dirigido por planejamento
(tradicional) e da abordagem gil realizado por Magalhes et
al. (2005).
Na Tabela 3 apresenta-se um estudo comparativo dos mtodos geis, partindo do estudo realizado por Abrahamsson
et al. (2002) e complementado por este trabalho, apontando os
pontos chaves, as principais caractersticas e as falhas entre
os mtodos aqui apresentados.
A contribuio acrescentada ao trabalho comparativo de
Abrahamsson et al. (2002) diz respeito mais precisamente
complementao da anlise com o acrscimo dos mtodos:
XPM, APM e YP, bem como a uma reviso da anlise original
sob a tica dos objetivos deste artigo.
Com base na Tabela 2 ficam perceptveis as vantagens resultantes da abordagem gil no que diz respeito capacidade
do time em responder de forma rpida e precisa s mudanas
naturais que fazem parte do ambiente dos negcios, onde esto
inseridos os projetos. Contudo, para adoo de uma abordagem
gil, as organizaes precisam estar dispostas a mudar a sua
percepo em relao a seus clientes, a reavaliar a forma como
encaram seus projetos e a assumir alguns riscos. Alm disso, os
times tambm precisam estar dispostos a aprender e amadurecer durante o processo, refinando suas prticas e aumentando
o grau de integrao e comunicao com o cliente.
Referncias
ABRAHAMSSON, P.; SALO, O.; RONKAINEN, J.; WARSTA, J. (2002). Agile Software Development
Methods. Review and analysis. ESPOO (Technical Research Centre of Finland) 2002. VTT
Publications n. 478, 112p, 2002.
APM (2003). CC PACE Systems. Agile Project Management Explained White paper. Disponvel
em: < http://www.ccpace.com/Resources/documents/AgileProjectManagement.pdf >.
BECK, K ; FOWLER, M. (2000). Planning extreme programming. Addison-Wesley Longman Publishing
Co., Inc. Boston, MA, USA, 2000. Disponvel em: < http://www.mip.sdu.dk/~brianj/Extreme%20
Programming%20Explained%20-%20Kent%20Beck%3B%20Addison-Wesley,%201999.pdf >.
MAGALHES, ANA L. C. DE C.; ROUILLER, ANA C.; VASCONCELOS, ALEXANDRE M. L. (2005). O

Gerenciamento de Projetos de Software Desenvolvidos Luz das Metodologias geis: Uma Viso
Comparativa. Revista ProQuality Qualidade na Produo de Software vol. 1, n. 1 Lavras,
Universidade Federal de Lavras, maio de 2005. Disponvel em: < http://www.proqualiti.org.br/
revista/revista_ProQualiti_maio2005.pdf#page=29 >.
NAWROCKI, J.; JASINSKI, M.; WALTER, B.; WOJCIECHOWSKI. (2002). Extreme Programming
Modified: Embrace Requirements Engineering Practices. In: RE 2002, International Conference on
Requirements Engineering, IEEE, 8 p., 2002.
BECK K. (1999). Programao Extrema Explicada. Bookman, 1999.
OLIVEIRA, E. S. (2003).Uso de Metodologias geis no Desenvolvimento de Software. Monografia

apresentada no Programa de Ps-Graduao em Engenharia de Software da UFMG, 2003.
PALMER, S.R.; FELSING, J.M.A (2002).Practical Guide to Feature-Driven Development.Prentice Hall, 2002.
COCKBURN, A. (2000). Agile Software Development Draft version: 3b. Highsmith Series Editors,
2000. Disponvel em: <http://zsiie.icis.pcz.pl/ksiazki/Agile%20Software%20Development.pdf>.
PRESSMAN, Roger S. (2006). Engenharia de Software: Uma abordagem prtica. Mc Graw Hill 6edio, 2006.
CUMMINS, F.A (2008). Building the Agile Enterprise: With SOA, BPM and MBM, 2008. Paperback, 336
pages, publication date: SEP-2008. ISBN-13: 978-0-12-374445-6. Disponvel em: < http://books.google.
com/books?hl=pt-BR e lr= e id=S6bla9Oy7SYC e oi=fnd e pg=PR13 e dq=%22agile+governance%22
e ots=k05jBK84BQ e sig=Yy6IpvSQ9TNKELMr3Ohv3dR_7UA >.
ROOSMALEN, MW VAN e HOPPENBROUWERS, S (2008). Supporting Corporate Governance

with Enterprise Architecture and Business Rule Management: A Synthesis of Stability and
Agility. Proceedings of ReMoD, 2008. Disponvel em: < http://ftp.informatik.rwth-aachen.de/
Publications/CEUR-WS/Vol-342/paper2.pdf >.
DSDM (2003). DYNAMIC SYSTEMS DEVELOPMENT METHOD LTD. DSDM Consortium, 2003. Site do
consrcio responsvel pelo DSDM e onde esto disponveis diversas informaes sobre o mtodo.
Disponvel em: <http://www.dsdm.org/>.
SCHWABER, Ken e BEEDLE, Mike (2002). Agile Software Development with SCRUM. Prentice Hall,
PTR Upper Saddle River, NJ, USA, 2002.
BECK, KENT et al. (2001). Agile Manifesto, 2001. Disponvel em: <http://www.agilemanifesto.org>.
FERREIRA, RB; LIMA, FPA (2006). Metodologias geis: Um Novo Paradigma de Desenvolvimento
de Software. II Workshop Um Olhar Sociotcnico sobre a Engenharia de Software WOSES, 2006,
Vila Velha - ES. Disponvel em: <http://www.cos.ufrj.br/~handrade/woses/woses2006/pdfs/10Artigo10WOSES-2006.pdf>.
GARCIA, F. P. et al. (2004). easYProcess: Um Processo de Desenvolvimento para Uso no Ambiente
Acadmico. XII WEI-Workshop de Educao em Computao. Campina Grande: UFCG, 2004.
Disponvel em: < http://www.dsc.ufcg.edu.br/~yp/Download/ArtigoYPWEI.pdf>.
HIGHSMITH, J. (2000). Retiring Lifecycle Dinosaurs. Software Testing e Quality Engineering 2, n.4,
July/August 2000.
HIGHSMITH, J. (2002a). Agile Software Development Ecosystems. Addison Wesley, 2002.
HIGHSMITH, J. (2002b).What Is Agile Software Development? Agile Software Development.
CROSSTALK. The Journal of Defense Software Engineering. Outubro, 2002. p. 4-9.
JACOBSEN, CATRINE M. (2001).XPM from idea to realization - critical approach to the concept of
XPM. Disponvel em: <http://www.glyn.dk/download/synopsisXPM.pdf >.
LOJKINE, J. (1996).A revoluo informacional. So Paulo, Editora Cortez, 1996.
LUFTMAN, J.N.; LEWIS, P.R. e OLDACH, S.H. (1993).Transforming The Enterprise: The Alignment Of
Business And Information Technology Strategies. IBM Systems Journal, v.32, n.1, p.198-221, 1993.
LUNA,Alexandre J.H.DE O.;COSTA,Cleyverson P.and NOVAES,Magdala A.(2010).Desenvolvimento Distribudo
de uma Aplicao de Telessade com a Metodologia gil SCRUM. In Revista Cientfica Tecnologus 4, no. 1: 6.
Disponvel em: <http://www.unibratec.com.br/revistacientifica/n4_artigos.html>.
18
SCOTT, DONNA (2000). Operation Zero Downtime, a Gartner Group Report, Donna Scott, 2000.
Disponvel em: <http://www.gartner.com/>.
SLOANE, E; BECK, R e METZGER, S (2008). AGSOA - Agile Governance for Service Oriented
Architecture (SOA) Systems: A Methodology to Deliver 21st Century Military Net-Centric Systems
of Systems. Systems Conference, 2008 2nd Annual IEEE, 2008. Disponvel em: < http://ieeexplore.
ieee.org/xpls/abs_all.jsp?arnumber=4518995 >.
SOARES, M. S. (2004). Comparao entre Metodologias geis e Tradicionais para Desenvolvimento
de Software. INFOCOMP Journal of Computer Science, Vol. 3, n. 2, p. 8-13, 2004.
SOMMERVILLE, IAN (2007). Engenharia de Software. Pearson Education - 8 Edio, So Paulo,
2007.
STAPLETON, JENNIFER (1997). DSDM: The Method in Practice. Pages: 192. Medium: Hardcover, 1997.
ISBN:0201178893.
TAKEUCHI, H. AND I. NONAKA (1986). The New New Product Development Game. Harvard Business
Review, 1986 (January-February).
THOMSETT, ROB (2002). Radical Project Management. Prentice Hall, 2002. ISBN-13: 978-0-13009486-5. Disponvel em: <http://my.safaribooksonline.com/0130094862>.
YP (2006). easY Process. Disponvel em: <http://www.dsc.ufcg.edu.br/~yp/>.
Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros
Ferramentas de teste de software

Como elas podem auxiliar nas atividades do dia a dia?
Gabriela de Oliveira Patuci

opgabi@gmail.com
formada pela UNICAMP em Tecnologia

em Informtica e est cursando mestrado
na rea de Engenharia de Software. Possui
certificao pela Scrum Alliance, tem experincia de trs anos no trabalho com metodologias geis e de cinco anos em Testes
e Qualidade de Software. Hoje atua como
Scrum Master em projetos internacionais
pela Ci&T e j palestrou em eventos como
Agile Brazil 2010.
atividade de testes de software

quase to antiga quanto o
desenvolvimento de sistemas
em si. Desde seu surgimento, muito vem
sendo discutido com relao possibilidade de se utilizar ferramentas que
facilitem o trabalho dos profissionais
de testes. Estas ferramentas surgiram
com o intuito de auxiliar tarefas como o
planejamento de casos de testes, execuo de testes, abertura de defeitos entre
outros.
Neste artigo, pretende-se apresentar
uma lista de ferramentas que foram consideradas algumas das mais utilizadas
pelos analistas e engenheiros de testes.
Seguindo este raciocnio, vamos ensinar,
de forma objetiva, como utilizar tais ferramentas, a fim de conseguir mais tempo
para executar os testes manuais, que
demandam um trabalho mais complexo
e focado por parte destes profissionais
da rea.
As reas que possuem ferramentas
conhecidas so muitas, dentre elas podemos citar, por exemplo: Testes Funcionais, de Performance, de Link e HTML,
Neste artigo apresentaremos uma relao de

ferramentas que auxiliam no gerenciamento e
execuo das atividades de testes de software.
Nesta lista destacamos a utilidade de cada uma
destas ferramentas, bem como aprendemos a
utiliz-las de uma maneira geral.
Para que serve?

O artigo tem a inteno de colaborar para o aprendizado na utilizao e na escolha de boas ferramentas que possam auxiliar o trabalho de profissionais de testes de software, tanto na execuo e
planejamento de testes quanto no gerenciamento
de defeitos.

O tema til para os profissionais de Testes de
Software que necessitam automatizar a execuo de parte de seus testes ou at mesmo apenas gerenciar de maneira mais controlada os
defeitos abertos e os casos de testes escritos.
de Segurana, Gerenciamento de Testes,

Gerenciamento de Requisitos e Bug Tracking (controle e abertura de defeitos).
Este artigo vai apresentar basicamente
19
alguns exemplos envolvendo gerenciamento, execuo dos

testes e controle de defeitos.
Gerenciamento de Testes
Algumas ferramentas existentes no mercado podem auxiliar
em todo o processo de gerenciamento de testes. Este processo
vai desde o cadastramento dos requisitos do projeto, at a
criao e execuo de Planos de Teste e Casos de Teste. No
caso deste artigo, selecionamos apenas uma ferramenta free
para que todos os profissionais pudessem ter acesso ao seu
contedo e testar seu funcionamento.
A ferramenta analisada foi o TestLink. Entre suas possibilidades podemos citar: controle de contedo (requisitos e casos
de teste) online, controle de execuo e resultados de testes.
O TestLink foi desenvolvido em linguagem PHP e nada mais
do que uma aplicao Web, que pode ser utilizada com o
servidor que o projeto j utiliza, como por exemplo, o Apache,
ou qualquer outro servidor de sua preferncia.
Vamos aos primeiros passos para utilizao desta ferramenta.
Inicialmente, deve-se cadastrar usurios e perfis necessrios
para a utilizao do sistema. A Figura 1 exibe uma das principais telas do sistema, onde o usurio poder configurar senhas
Figura 1. Tela Detalhes do Usurio
Figura 2. Tela de criao de Novo Projeto
20
e perfis. O usurio deve se atentar ao fato de que quanto mais

informaes forem preenchidas, melhor ser o cadastramento
dos usurios e perfis. Outro fator importante a lngua. Se o
usurio no deseja utilizar o sistema em Ingls (padro da
ferramenta), deve-se troc-la j no cadastro, editando o valor
da localizao do usurio no campo Locale.
Criados os usurios e perfis necessrios, o administrador do
sistema dever cadastrar no mnimo um projeto para que todo
contedo de testes seja administrado dentro deste projeto de
testes. Podemos ver atravs da Figura 2 como se d a criao
de um novo projeto. claro que o melhor que seja criado
um projeto de testes para cada projeto real, para que todas as
informaes fiquem seguras, bem divididas e, principalmente,
para que apenas os usurios necessrios tenham acesso ao
contedo de cada projeto.
Como podemos constatar, deve-se preencher os campos
Name e Related Notes com o ttulo do Projeto de Testes e uma
descrio bsica de seu contedo, respectivamente. O terceiro
campo, Enable Requirements, vai servir como um link entre
o projeto e os requisitos que podem ser cadastrados ao longo
do tempo na prpria ferramenta.
Aps a criao do projeto, ainda como administrador, devese criar uma baseline (ou build), um controlador de verses
para todo o contedo do projeto. A Figura 3 mostra a tela de
criao de uma baseline. Dentro desta mesma tela, pode-se
acompanhar o significado dos atributos da baseline (Ativo/
Inativo e Fechado/Aberto).
Um atributo considerado:
Ativo/Inativo se a baseline est ou no disponvel para a utilizao do TestLink. Baseline inativa no listada nas pginas
de execuo e relatrios;
Fechado/Aberto se os resultados do teste podem ser modificados para a baseline.
Feita a criao tanto do projeto como da nova baseline, o
sistema levar o usurio automaticamente at a tela inicial,
onde pode ser realizado o projeto de testes. Antes de comear
o projeto, faz-se necessrio a criao de um Plano de Testes.
A tela de criao de um Plano de Testes pode ser visualizada
na Figura 4. importante que o usurio seja cuidadoso ao
Figura 3. Tela de Nova Baseline
Engenharia de Software Magazine - Ferramentas de teste de software
Tes te de soft ware
criar um Ttulo e uma descrio para seu

plano de testes, assim como para o projeto.
Estes campos sero aqueles pelos quais
os planos sero identificados no futuro
pelos integrantes das equipes de desenvolvimento e testes.
Depois de criado o Plano de Testes,
deve-se cadastrar os requisitos que sero
utilizados no planejamento de testes. A
criao dos requisitos (Figura 5) um dos
passos no obrigatrios, mas, ajuda muito
no gerenciamento de contedo do projeto
e at mesmo na criao dos casos de teste Figura 4. Tela de Novo Plano de Testes
(nosso prximo passo). Algumas equipes
chegam a utilizar estes requisitos como parte do planejamento
de testes, visto que a validao do produto nada mais do que
a comparao entre os requisitos e aquilo que foi feito (mas de
forma mais complexa).
O prximo passo da criao dos documentos de testes o
desenvolvimento e cadastro dos casos de testes. A tela de
criao destes testes pode ser vista na Figura 6. Nesta tela,
deve ser feito o cadastro do caso de teste e do passo a passo a
ser reproduzido.
Os principais campos devem ser preenchidos: o Ttulo do
Caso de Teste, a Descrio e os Pr-Requisitos (o que deve
existir antes do caso de teste ser executado). A partir desta
etapa, os testes tambm podem ser executados e os relatrios
Figura 5. Tela de Especificao de Requisitos
gerados.
Abertura de Defeitos (Jira)

O mercado atual possui muitas ferramentas capazes de armazenar um grande nmero de defeitos com vrias informaes
relevantes (formando at mesmo um ciclo de vida dos bugs
reportados), mas uma das melhores , sem dvida, o Jira. Alm
de reportar defeitos, o Jira pode servir como base para o incio
da implantao de sprints e atividades no dia a dia de um
projeto Scrum. Esta ferramenta tambm pode gerar grficos
que ajudam na elucidao do status dirio do trabalho do time
de desenvolvimento como um todo.
Jira
Esta ferramenta utilizada principalmente para reportar
defeitos encontrados em baterias de testes, mas pode tambm
controlar tarefas e requisitos de projetos geis, por exemplo.
Ensinaremos agora como reportar defeitos, selecionar defeitos
para correo e inserir resultados de reteste.
A criao de um novo defeito pode ser feita atravs da pgina
principal (Dashboard) da ferramenta. O menu principal possui
uma opo denominada Create a new issue (Figura 7) no canto
superior direito da tela. Esta opo de criar um issue dentro
do Jira pode envolver vrios tipos de tickets, como Estrias,
Defeitos, Tarefas entre outras. Neste caso, como estamos criando um defeito, devemos selecionar a opo Bug.
Selecionada a opo Bug na tela de criao, exemplificada
nas Figuras 8 e 9, os campos devero ser preenchidos com o
Figura 6. Tela de Cadastro de Casos de Teste
mximo de detalhes possvel, como descrito a seguir. Os detalhes so imprescindveis para a reproduo exata do problema
por parte daqueles que desenvolvem o sistema e corrigem os
defeitos. Iniciando o preenchimento dos campos, primeiramente, deve-se ter em mente que alguns campos (Project e Issue
Type) viro com o contedo preenchido automaticamente, e
isso ocorrer apenas nos casos em que o usurio j criou contedo anteriormente. Por exemplo, s existiro opes para
verses (Affect Versions, Fix Versions) se estas foram criadas
pelo usurio em uma primeira instncia. Isto pode ser feito
de acordo com sprints, releases etc.
21
Figura 7. Tela inicial do Jira
Figura 8. Tela de Novo Issue (Parte 1)
Segue a lista com todos os campos da tela e como cada um

deles deve ser preenchido:
Project: Este campo ser preenchido automaticamente;
Issue type: Bug (tambm j preenchido);
Summary: Descrio breve do defeito (Ttulo);
Security Level: Aqui o usurio pode escolher quais perfis
tero acesso a este defeito (apenas administradores, todos os
usurios, etc.);
Priority: Prioridade do defeito;
Bug Type: Tipos cadastrados de defeito;
Due Data: Data limite para a correo do defeito;
Components: Componentes do sistema afetados pelo
defeito;
Affects Versions: preenchido manualmente e referente s
verses que so afetadas por este defeito. J vem com dados
carregados das verses criadas pelo usurio anteriormente
para este projeto;
Fix Versions: Preenchido manualmente, se refere s verses
que sofreram correo. J vem com dados carregados das verses criadas anteriormente pelo usurio (durante a criao do
prprio projeto);
Assignee: Pessoa que resolver o defeito (o usurio pode
incluir durante a criao ou pode deixar em aberto para que
um membro do time selecione o defeito a ser corrigido);
Reporter: Quem criou o defeito, tambm preenchido automaticamente com o usurio logado no sistema;
22
Environment: Ambiente onde o defeito foi encontrado (testes, desenvolvimento, produo);

Description: Descrio completa do
defeito encontrado (quanto mais completa, mais facilmente o defeito ser replicado pela equipe de desenvolvimento);
Original Estimate: Quanto tempo
estimado para a correo (normalmente
este campo preenchido pelo membro
do time que far a correo);
Attachment: Todo contedo que pode ser includo para
facilitar a correo (imagens, logs, etc.);
Story Points: Para os que usam Scrum, qual o esforo para
se corrigir o defeito;
Business Value: Para os que usam Scrum, qual o valor de
negcios da correo;
Acceptance Criteria: Para os que usam Scrum, requisitos
relevantes com relao ao defeito encontrado;
Root Cause: Causa raiz do defeito encontrado;
Root Cause Notes: Mais detalhes relevantes causa raiz do
defeito encontrado.
Criada a lista de defeitos, deve-se delegar cada ticket (bug)
a quem dever corrigi-lo, ou a prpria equipe pode fazer isto
de maneira colaborativa. O importante neste ponto saber
identificar todos os defeitos atravs de uma busca, como pode
ser visto na Figura 10. Primeiramente, basta clicar em Issues
no menu principal e, em seguida, selecionar a opo Search
for Issues. A tela apresentada na Figura 10 ser exibida.
Preencha os campos que achar conveniente para encontrar
os tickets.
Por fim, tarefas importantes como aceitar o defeito (o que
chamamos de assign) e alterar seu status aps ser corrigido
tambm sero exemplificadas para concluirmos as dicas apresentadas para a ferramenta Jira. A Figura 11 mostra como devemos aceitar um defeito, j a Figura 12 demonstra como alterar
o status do defeito de Accepted para Resolved Fixed.
Deve-se preencher os campos com o tipo de resoluo do defeito (neste caso, o defeito foi corrigido: Fixed), qual a verso foi
corrigida, quem corrigiu (Assignee), qual era o tipo do defeito
e comentrios que o usurio achar pertinente. Desta forma, o
defeito encerrado de maneira correta e o ciclo da ferramenta
finalmente se encerra.
Execuo Automatizada (Selenium IDE, JMeter e

WebDeveloper)
Em se tratando de automao de testes, as principais ferramentas, normalmente as mais citadas, so aquelas que auxiliam
na execuo dos testes em si, como add-ons do Firefox (Selenium e WebDeveloper) para execuo de testes mais simples,
ou at mesmo mais complexas, como o JMeter e outras ferramentas de testes de estresse. Durante a criao deste artigo,
foram realizados alguns testes com estas ferramentas e os
resultados esto descritos nos subcaptulos seguintes.
Tes te de soft ware
Figura 10. Tela de Busca Personalizada
Figura 9. Tela de Novo Issue (Parte 2)
Selenium IDE
Ferramenta conhecida por auxiliar em testes de fumaa,
regresso e estresse, o Selenium , na verdade, uma sute de
testes. Composto por uma IDE (plugin do Firefox), um RC
(sistema cliente/servidor) que permite que o usurio controle
o browser local ou remotamente e por um GRID (ferramenta
que permite ao usurio rodar o RC em um ou mais servidores
ao mesmo tempo), esta sute tem sido cada vez mais utilizada
pelas equipes de testes de software.
Uma das principais motivaes para a utilizao desta
sute, alm das possibilidades de uso amplas, a facilidade
de encontrar informaes sobre ela. Existem hoje muitos
fruns de discusso e equipes que utilizam tal recurso,
logo, fica muito mais simples conseguir ajuda e/ou suporte
para o Selenium. A Tabela 1 cita as principais caractersticas da ferramenta e algumas das maiores vantagens do
Selenium.
Focados na execuo dos testes em si, vamos exemplificar aqui, como utilizar o Selenium IDE para a gravao de
testes automatizados. A Figura 13 mostra a interface da
ferramenta.
Um exemplo claro e bem simples de utilizao desta ferramenta pode ser visto a seguir. Criou-se, neste exemplo, um
script que consegue abrir uma nova aba no browser, entrar
em um conhecido site de buscas e procurar por um contedo
especfico (neste caso, testes de fumaa). Os passos executados para a gravao do script de testes foram:
1. Clicar no boto de gravao;
2. Executar as aes dentro do site desejado. Neste exemplo,
digitou-se o endereo do site de buscas, inseriu-se o valor a
ser buscado e clicou-se no boto Pesquisa;
Figura 11. Tela de Assign
Figura 12. Tela de Resoluo de Tickets

Caractersticas do Selenium IDE
Fcil gravao e reproduo.
Seleo inteligente de identificaes, nomes ou Xpaths.
Autocomplete para todos os comandos mais utilizados.
Debug e definio dos pontos de interrupo.
Opo de salvar como HTML, scripts Ruby ou qualquer outro formato.
Suporte para arquivos cuja extenso .js.
Fcil customizao (atravs de plugins).
Identifica automaticamente o ttulo de cada pgina.
Tabela 1. Caractersticas do Selenium IDE
23
3. Logo aps obter os resultados desejados, clicar novamente

no boto de gravao para que esta seja finalizada.
Pode-se acompanhar os resultados do passo a passo anterior
atravs da Figura 14. Esta figura possui o script gerado e tambm
a tela do browser executando os comandos inseridos no script.
Comando
Funcionalidade
Verify
Localiza um elemento na pgina sem interromper a execuo do script aps um erro.
Assert
Localiza um elemento na pgina e interrompe a execuo do script aps um erro.
Click
Executa a ao de um clique em botes ou links da pgina.
Wait
Comando de espera (por uma ao, elemento surgir na pgina, etc.) at que o
elemento possa ser executado.
Store
Armazena valores (variveis de linguagem).
Type
Insere o texto desejado em campos de texto da pgina.
Tabela 2. Comandos do Selenium (Xpath)
Os principais comandos utilizados no Selenium podem ser

verificados na Tabela 2. Conhecer os principais comandos
o melhor incio para gerar os scripts de testes e automatizar,
principalmente, os testes de regresso e fumaa. Boa parte dos
comandos salvo no script a partir da prpria ferramenta, mas
muitas funcionalidades podem ser inseridas, ou at mesmo
incrementadas, se o usurio tiver um bom conhecimento dos
comandos da ferramenta. Um bom exemplo o comando
WaitForPageToLoad, que permite que a pgina seja carregada
no tempo correto de resposta da conexo sem interromper
os prximos passos do script. Se o usurio estiver utilizando
uma conexo de rede lenta, por exemplo, o script no ser interrompido e o usurio no receber uma mensagem de erro
no meio da execuo planejada.
Uma vez que este script esteja gravado, poder ser reutilizado
quantas vezes for necessrio. Alm da execuo dos testes, o
fato da ferramenta poder executar o mesmo script N vezes, faz
com que esta seja muito til para criao de cargas de massa
de testes, por exemplo. Alguns exemplos de utilizao do
Selenium IDE mais comuns no mercado atual so:
Testes de Aceitao por parte do cliente, que no tem muito
tempo de refazer o mesmo teste vrias vezes;
Testes de Regresso quando a mesma pgina ou sistema teve
seu cdigo alterado vrias vezes, mas sua estrutura pouco
mudou;
Testes de Fumaa para garantir que todos os mdulos de uma
pgina existem e que seu funcionamento bsico est correto.
JMeter
Figura 13. Tela inicial do Selenium
Figura 14. Gravao de script no Selenium
24
O JMeter uma ferramenta utilizada basicamente para testes de

carga e performance, open source e foi desenvolvida utilizando
Java. A ferramenta disponibiliza ao usurio vrios tipos de requisies e validaes (destas requisies), alm de controladores
lgicos tudo para a construo dos planos de testes.
O primeiro passo para utilizar a ferramenta fazer o download do arquivo compactado e instalar o software executando o
arquivo jmeter.bat. Uma vez instalada a ferramenta, o usurio
deve criar um grupo de usurios para
que os testes sejam executados futuramente. A Figura 15 mostra como
criar um grupo de usurios.
O JMeter permite ao usurio organizar os scripts gerados em vrios Grupos de Usurios. Todas as informaes
relacionadas a estes grupos devem ser
inseridas na tela Grupo de Usurios.
As principais delas so: o nmero de
usurios virtuais (quantas threads
voc gostaria de simular atravs da
ferramenta), o tempo de inicializao
e um contador de interao.
Criados os Grupos de Usurios,
pode-se voltar tela inicial do JMeter
(Figura 16), onde a estrutura principal do software exibe uma rvore de
Tes te de soft ware
testes (Test Plan) e uma rea de trabalho temporria que apia

o desenvolvimento deste Test Plan (a WorkBench).
Aps a correta criao dos grupos e dos planos de testes,
o usurio pode utilizar o software para gerar testes personalizados, de acordo com a necessidade do profissional. Por
fim, temos duas tabelas que sero teis para o manuseio da
ferramenta: a primeira possui todos os elementos necessrios
ao plano de testes no JMeter (Tabela 3) e a segunda, os tipos
de servio (Tabela 4).
WebDeveloper
Criado tambm como um complemento do browser Firefox,
a ferramenta WebDeveloper pode ser utilizada tanto pelos
profissionais de design web quanto por analistas de testes.
Esta ferramenta permite ao usurio navegar por todo um site,
tendo acesso a contedos como CSS, elementos escondidos em
formulrios, senhas etc.
O primeiro passo para a utilizao do WebDeveloper, assim
como para o Selenium IDE, a sua instalao. Para isso, basta
baixar seu contedo na prpria pgina do browser.
O funcionamento da ferramenta bem simples. O usurio
deve apenas clicar nas opes que deseja manter ativadas. A
Figura 17 mostra a tela principal deste complemento e algumas
das opes ativas.
Como visto na Figura 17, cada uma das opes do menu
representa um conjunto de ferramentas relacionadas. Vejamos
o que cada uma faz:
Desativar: permite habilitar/desabilitar cache, Java, JavaScript, redirecionamentos com <meta>, tamanho mnimo de
fontes, cores personalizadas, pop-ups e proxy;
Cookies: permite habilitar/desabilitar cookies, limpar

cookies, visualizar informaes de cookies (podendo editar
ou excluir), e adicionar cookies manualmente;
CSS: permite escolher as folhas de estilos a serem usadas
(escolhendo por arquivo ou por mdia), visualizar as folhas
de estilos aplicadas, obter os estilos de um elemento clicando
sobre ele, editar o CSS e ver o resultado dinamicamente (timo
para ajustar posies, cores e tamanhos), e utilizar o modo
Quirks (border box);
Formulrios: permite visualizar informaes de formulrios, converter mtodos de submisso, habilitar campos
Figura 15. Tela Grupo de Usurios
Figura 16. Tela de WorkBench
Thread Group
o ponto inicial, onde todos os outros elementos do Test Plan devem estar includos. Como o prprio nome ressalta, controla as threads que sero executadas pelo teste.
Samplers
So controladores pr-definidos para requisies especficas, podendo ser customizados com a insero de configuraes (Configurations), Assertions e etc.
Logic Controllers
So controladores mais genricos, podendo ser customizados com a insero de outros controllers, configuration elements, assertions, etc.
Listeners
Estes so os elementos que fornecem acesso s informaes obtidas pelo JMeter durante os testes.
Timers
Por padro, o JMeter faz requisies sem pausas entre elas. Os timers so utilizados para incluir pausas entre as requisies.
Assertions
Usado para verificar se a resposta obtida na requisio a esperada. Pode ser usado expresses regulares (Perl-style regular expression) na comparao.
Configuration Elements
Permite que o usurio envie requisies e at mesmo simule o envio de vrias requisies ao mesmo tempo.
Pre-Processor Elements
Post-Processor Elements
Executa alguma ao antes de fazer a requisio. Mais usado para pr-configuraes das requisies. Por exemplo, pode ser utilizado antes de um contador, para deixar o
valor processado preparado para ser futuramente utilizado (antes de outro comando).
Executa alguma ao depois de fazer a requisio. Mais usado para processar as respostas da requisio. Por exemplo, dentro de um caso de teste, ele deve ser inserido aps
um timer, para processar o valor deste comando.
Tabela 3. Elementos do Plano de Testes

FTP
Permite criar requisies usando o protocolo FTP (com autenticao ou no) e executa o comando de retrieve em um arquivo especfico.
HTTP
Permite criar requisies usando o protocolo HTTP ou HTTPS (com autenticao ou no), podendo incluir parmetros ou arquivos a requisio, escolher o mtodo usado (GET ou POST) e
manipular Cookies. Este sampler possui dois tipos de implementao: Java HTTP ou Commons HTTPClient.
JDBC
Com esta requisio possvel executar queries em um banco de dados especfico.
Objeto Java
Ajuda no teste de carga de classes Java, exigindo que seja implementada uma classe do tipo JavaSamplerClient para executar o mtodo a ser testado. A estrutura deste objeto similar
usada pelo JUnit.
SOAP/XML
Permite enviar requisies SOAP para um WebService, ou enviar XML-RPC atravs do protocolo HTTP.
LDAP
Permite enviar requisies para um servidor LDAP. Possui uma implementao simplificada e outra estendida.
JUnit
Usado para fazer teste de carga em testes de unidade que utilizam o framework JUnit.
Tabela 4. Tipos de Servio
25
desabilitados, limpar botes de seleo, preencher campos

automaticamente, e desconsiderar tamanho mximo de
campos;
Imagens: habilitar/desabilitar imagens, visualizar imagens
da pgina, visualizar informaes sobre imagens, exibir imagens no tamanho original, e substituir imagens pelo texto
alternativo;
Informaes: permite visualizar vrios elementos do HTML,
listar ttulos, visualizar cores usadas na pgina, visualizar
estrutura do documento, visualizar tamanho dos arquivos
que compem a pgina, visualizar propriedades da pgina,
visualizar cabealho de resposta HTTP, entre outras;
Outros: permite limpar dados pessoais de cache, histrico
ou autenticao HTTP, exibir linhas guia para ajudar com
alinhamento de elementos, exibir lente de aumento, exibir
comentrios HTML, exibir elementos ocultos, editar o contedo HTML acompanhando o resultado dinamicamente,
entre outros;
Destacar: permite destacar algumas tags do HTML, destacar
elementos obsoletos (depreciados pelo HTML), entre outros;
Redimensionar: permite cadastrar taman hos (por
exemplo: 800x600, 1024x768, etc.) e redimensionar a janela
automaticamente;
Ferramentas: permite validar CSS, HTML, acessibilidade,
ver controle de erros, entre outros;
Cdigo-fonte: permite ver o cdigo-fonte original, o cdigofonte gerado dinamicamente, entre outros;
Opes: permite configurar o plugin.
Referncias
[1] AP Test Software Quality Assurance Testing and Test Tool Resources. http://www.aptest.
com/resources.html.
[2] Test Expert. http://www.testexpert.com.br/?q=node/347.
[3] Firefox Add-Ons Selenium IDE. https://addons.mozilla.org/pt-br/firefox/tag/Selenium%20
IDE%20Plugin.
[4] TestLink Gerenciamento de Casos de Teste. http://www.slideshare.net/prical/testlink-apresentacao#.
[5] Firefox Add-Ons WebDeveloper. https://addons.mozilla.org/pt-br/firefox/addon/web-developer/
[7] Usando TestLink para Garantia de Qualidade. http://www.bugbang.com.br/?p=658
26

D
s
[6] The Apache Jakarta Project. http://jakarta.apache.org/jmeter/
Este artigo apresentou um estudo sobre as principais

ferramentas que vm sendo utilizadas no gerenciamento,
planejamento e automao de testes de software.
O resultado deste estudo foi a criao de uma lista de ferramentas e das principais atividades que podem ser executadas
atravs delas, visando tornar a atividade de testes mais simples e, ao mesmo tempo, mais completa. Esta seleo foi feita
com base na utilizao mais frequente destas ferramentas nos
ltimos projetos nos quais executamos automao e gerenciamento de testes automatizados. A automao de atividades
Feedback
eu
sobre e
s
Concluso
edio
ta
Figura 17. Comandos do WebDeveloper
antes feitas manualmente pode gerar maior oportunidade

de se executar testes manuais cada vez mais complexos. A
possibilidade de ter todo o material de testes desde os casos de
testes at os requisitos do produto tambm veio para facilitar
o trabalho das equipes de testes e melhorar a qualidade do
trabalho de todas elas.
Deve-se ter em mente que esta lista limitada a ferramentas
j utilizadas, mas no descreve a totalidade das boas ferramentas free que podem ser encontradas hoje. Muitas outras
ferramentas foram criadas e so amplamente utilizadas, e
mesmo assim no foram citadas neste artigo por falta de
conhecimento ou experincia em seu uso.
Cada uma das opes demonstradas tem o seu ponto
forte e deve ser utilizada de modo a auxiliar em testes de
tipos especficos. A primeira delas, o TestLink, tem como
principal objetivo armazenar o mximo de informaes do
planejamento de testes em um s lugar. J o Jira, tem como
ponto forte o armazenamento de tarefas e defeitos. As ltimas
ferramentas citadas (Selenium IDE, JMeter e WebDeveloper)
so basicamente auxiliadoras na execuo dos testes em si,
e nada tm a ver com planejamento e gerenciamento como
as anteriores.
Enfim, utilizar ferramentas com certeza algo que pode
facilitar e melhorar muito os testes, mas nunca ir substituir
os testes que exigem a inteligncia humana e a experincia
dos profissionais da rea. Como na maioria dos casos, a
melhor escolha a unio da experincia e autonomia de um
profissional com a rapidez de uma boa ferramenta. Deste
modo, este artigo teve como pretenso auxiliar neste trabalho
e instigar novos profissionais a conhecer e pesquisar sobre
a capacidade destas ferramentas que tanto auxiliam no dia
a dia das equipes de testes de software.
Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros
Maturidade em Desenvolvimento de Software

O caso do MPS.BR Melhoria de Processo do Software Brasileiro

Aline Rodrigues
Este artigo apresenta o MPS.BR abordando suas

principais definies e destacando seus nveis iniciais de maturidade.
alinecrodrigues@gmail.com
Analista de Sistemas graduada em Bacharelado de Sistemas de Informao pela

Faculdade Ruy Barbosa e ps-graduanda
em Engenharia de Software na ps graduao Ruy Barbosa. Atua como analista de
requisitos no Instituto do Meio Ambiente
pela Avansys Tecnologia, na liderana de
projetos, de desenvolvimento, superviso
de equipe tcnica, especificao e detalhamento de requisitos.
Roberto B. Figueredo
beto.boscolo@gmail.com
Bacharel em Sistemas de Informao pela

Faculdade Ruy Barbosa. Ps-graduando
em Engenharia de Software pela Faculdade
Ruy Barbosa. H quatro anos atuando como
desenvolvedor e analista de sistemas.
Rodrigo Spnola
rodrigo@sqlmagazine.com.br
Doutor e Mestre em Engenharia de Software pela COPPE/UFRJ.

Diretor de Operaes Kali Software
(www.kalisoftware.com)
Editor Chefe SQL Magazine | WebMobile |
Engenharia de Software Magazine
Professor do Curso de Ps-Graduao em
Engenharia de Software da Faculdade
Ruy Barbosa.
Para que serve?
o Brasil, devido em parte

grande quantidade de empresas prestadoras de servios de
software que esto surgindo no mercado, os clientes passaram a exigir um
maior nvel de qualidade.
As grandes empresas desenvolvedoras
de software investem muito dinheiro em
busca da obteno de uma certificao
com o intuito de atingir um nvel de produtividade e qualidade internacionais e
principalmente uma diferenciao no
mercado nacional. Desenvolver e dar
suporte a sistemas de software uma
tarefa desafiadora. Esse desafio passa
a ser ainda maior para as pequenas e
mdias empresas brasileiras. O custo de
implantao de um modelo de maturidade de software internacional, como
o caso do CMMI, elevadssimo, muitas
vezes fora da realidade das empresas
brasileiras.
O MPS.BR define um modelo de melhoria e avaliao de processos de software com o foco nas
pequenas e mdias empresas brasileiras. Ele estabelece um modelo de processos de software e
um mtodo de avaliao de processos de modo a
garantir que o MPS.BR est sendo empregado de
forma coerente com as suas definies.

A discusso deste tema til para empresas que
tenham interesse no modelo de maturidade definido pelo MPS BR e para profissionais da rea
de software que queiram atualizar seu conhecimento sobre o assunto.
A partir da constatao de que as

empresas brasileiras precisariam de
um modelo que se adequasse sua
realidade, a Softex, em parceria com o
governo e universidades iniciou em 2003
o Programa de Melhoria de Processo
27
de Software Brasileiro MPS. BR. O MPS.BR uma soluo

brasileira totalmente compatvel com o modelo CMMI e em
harmonia com as normas ISO/IEC 12207 e 15504. Neste contexto, neste artigo apresentaremos o MPS.BR destacando seus
nveis iniciais de maturidade.
MPS.BR
O MPS.BR define um modelo de melhoria e avaliao de
processos de software com o foco nas pequenas e mdias empresas brasileiras, de modo a atender as suas necessidades de
negcio e ser reconhecido nacional e internacionalmente como
um modelo aplicvel indstria de software. Ele estabelece um
modelo de processos de software e um mtodo de avaliao
de processos de modo a garantir que o MPS.BR est sendo
empregado de forma coerente com as suas definies.
Principais Conceitos
Alguns conceitos so essenciais para o entendimento do
modelo. A maioria deles so tirados de normas como ISO
12204 e ISO 15504:
Processo de software: framework para todas as tarefas que
so necessrias para construir software de alta qualidade
(PRESSMAN, 2007);
Atributo de processo: caracterstica mensurvel da capacidade do processo aplicvel a qualquer processo (ISO/IEC
15504-1, 2004);
Resultado esperado: um resultado observvel do sucesso
do alcance do propsito do processo (ISO/IEC 12207:1995/
Amd 1:2002);
Capacidade do processo: uma caracterstica da habilidade
do processo atingir os objetivos de negcio atuais ou futuros
(ISO/IEC 15504-1, 2004). Essa capacidade representada por
um conjunto de atributos de processo que so descritos em
termos de resultados esperados. Expressa o grau de refinamento e institucionalizao com que o processo executado
na organizao. Para uma organizao passar para um nvel
mais alto de maturidade cada processo deve alcanar um nvel
maior de capacidade.
Ativo de processo: qualquer coisa que a organizao considere til para atingir os objetivos do processo como polticas,
processos definidos, lies aprendidas, templates de documentos, padres, material de treinamento (SEI, 2006);
Perfil do Processo: conjunto de pontuao de atributos de
processo para um processo avaliado (ISO/IEC 15504-1, 2004).
Guias MPS.BR
O modelo MPS.BR descrito por meio de quatro documentos
em formato de guias. So eles: guia geral, guia de implementao, guia de aquisio e guia de avaliao.
Guia Geral
Descreve de forma detalhada todo o MPS.BR assim como as definies sobre cada um dos documentos que compem o modelo.
Nesse documento encontram-se todos os conceitos relacionados
ao MPS.BR, a descrio detalhada de cada nvel de maturidade
28
e dos processos que fazem parte de cada nvel, seus propsitos,

alm da descrio dos atributos de processo, que so requeridos
para o alcance de determinado nvel de maturidade e o resultado
esperado dos processos e dos atributos de processo.
O Guia Geral destinado a todas as organizaes interessadas
em melhorar os seus processos de software e a instituies cujo
objetivo implementar ou avaliar o modelo. Essas instituies
devem ser autorizadas, mediante convnio com a Softex com
base em um parecer do Frum de Credenciamento e Controle.
Guia de Implementao
Fornece orientaes para implementar os nveis de maturidade descritos no modelo de referncia MR-MPS, detalhando os
processos contemplados nos respectivos nveis de maturidade
e os resultados esperados com a implementao dos processos.
O guia de implementao dividido em 10 partes iniciando
com a implementao do nvel mais baixo de maturidade, nvel
G. Os demais documentos seguem com a implementao dos
demais nveis e a partir da parte 8 passa a descrever orientaes
para a implementao do modelo de referncia para organizaes que adquirem software, que trabalham como uma Fbrica
de Software ou Fbrica de Testes de software.
Guia de Aquisio
Descreve um processo de aquisio de software e servios
correlatos visando servir como um guia para empresas que
adquirem esses servios. O guia detalha todas as atividades e
tarefas envolvidas, descreve os produtos de trabalho e fornece
exemplos de como os principais documentos so preenchidos.
So considerados nesse contexto tanto o produto de software propriamente dito como os servios relacionados ao seu
desenvolvimento como manuteno, suporte, implantao,
treinamento, configurao do software e do ambiente operacional, entre outros. Tambm ajustado para aquisies de
produtos de prateleira, produtos personalizados ou de domnio
especfico tanto por instituies privadas como por instituies pblicas. O guia possui diversos anexos apresentando
sugestes de modelos de documentos que podem utilizados
e personalizados pelos compradores.
Guia de Avaliao
Tem o objetivo de verificar a maturidade organizacional na
execuo dos seus processos de software. Este guia descreve
as atividades e tarefas a serem realizadas para verificar se a
organizao alcanou determinado nvel de maturidade. Esse
processo permite a avaliao objetiva de uma organizao ou
unidade organizacional, permite que se atribua um nvel de
maturidade com base no resultado da avaliao tanto para
uma unidade como para a organizao como um todo, sendo
aplicvel a qualquer domnio na indstria de software e a
organizaes de qualquer tamanho.
A avaliao tem incio com a seleo de uma Instituio Avaliadora que registrar a avaliao na base de dados confidencial
da Softex. De acordo com o Guia de Avaliao, para que uma
avaliao tenha sucesso, necessrio:
Engenharia de Software Magazine - Maturidade em Desenvolvimento de Software
Processo
Comprometimento do patrocinador, de modo que todos os

recursos necessrios estejam disponveis para a execuo da
avaliao;
Motivao por parte dos participantes da avaliao, responsabilidade do gerente da unidade organizacional;
Fornecimento de feedback de modo que seja possvel que
a organizao discuta sobre os resultados da avaliao fazendo com que a avaliao seja significativa para a unidade
organizacional;
Confidencialidade das informaes durante a avaliao
para que nenhum entrevistado se sinta ameaado e para que
todos possam se expressar livremente. Tambm abrange as
informaes contidas nos documentos;
Todos os membros devem perceber que a avaliao resultar em benefcios que os ajudaro no desempenho do seu
trabalho.
Os patrocinadores e colaboradores da unidade organizacional
devem confiar nos avaliadores, afinal, a avaliao deve chegar
a um resultado representativo para eles.
Figura 1. Comparao entre os modelos MPS.BR e o CMMI
Nveis de Maturidade
Os nveis de maturidade do MPS.BR, como no CMMI, estabelecem patamares de evoluo de processos caracterizando
estgios de melhoria da implementao de processos organizacionais. Essa diviso, embora baseada no CMMI, tem uma
graduao diferente. O MPS.BR subdividiu dois nveis do
modelo CMMI para melhor se adequar realidade das micro e
pequenas empresas brasileiras. Na Figura 1 temos um quadro
comparativo entre os nveis de maturidade MPS.BR e os nveis
de maturidade do CMMI.
Essa maior graduao de nveis de maturidade possibilita
s empresas brasileiras uma evoluo mais gradual e com
um custo inferior a sua equivalente internacional. Um maior
nmero de nveis possibilita tambm uma comparao mais
precisa entre unidades intra e inter-organizacionais.
Assim, o MPS.BR define 7 nveis de maturidade: A (Em
Otimizao, B (Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F
(Gerenciado), G (Parcialmente Gerenciado) conforme mostra
a Figura 2.
Processos
De acordo com (PRESSMAN, 2006), processo de software
um framework contendo todas as atividades necessrias para
a construo de software de qualidade. No MPS.BR eles so
descritos em termos de propsitos e resultados esperados, ou
seja, os objetivos gerais a serem atingidos pelo processo e os
resultados que se espera que o processo gere pela sua efetiva
implementao. Esses resultados podem ser artefatos como
documentos e componentes de software ou podem ser apenas
uma mudana no estado do processo.
Capacidade dos processos

A capacidade do processo a propriedade que expressa
o grau de refinamento e institucionalizao com que cada
Figura 2. Nveis de maturidade MPS.BR (Fonte: Softex, 2009)
processo executado na organizao. Um determinado nvel

de capacidade de um processo atingido quando os resultados
esperados de cada atributo de processo requerido para aquele
nvel atingido. necessrio que todos os processos requeridos
para determinado nvel de maturidade atinjam os resultados
esperados dos atributos requeridos para aquele nvel.
Os nveis de capacidade dos processos so cumulativos.
Para uma organizao avanar do nvel de maturidade G
para o nvel F, necessrio que todos os processos, tanto os
de nvel G como os de nvel F, estejam no nvel de capacidade relativo ao nvel de maturidade F. Assim, os processos
do nvel G devem possuir todos os atributos de processo
do nvel F.
Atributos de processo
Na verso mais recente do MPS.BR so descritos nove atributos de processo:
AP 1.1: O processo executado: o processo atinge o seu
propsito no importando de que maneira ele executado.
29
AP 2.1: O processo gerenciado: a execuo do processo

gerenciada. Uma poltica organizacional mantida para o
processo, planejamento da execuo, monitoramento e ajustes
realizados para atender o que foi planejado, entre outras atividades de gerenciamento.
AP 2.2: Os produtos de trabalho do processo so gerenciados: gerenciamento apropriado de todos os artefatos gerados
na execuo do projeto.
AP 3.1: O processo definido: medida de quo padronizados esto os processos. Processos que possuem esse atributo
seguem um padro definido para a sua execuo. Significa
que em todos os projetos da organizao esse projeto dever
ser executado de acordo com diretrizes definidas.
AP 3.2: O processo est implementado: o processo est sendo
efetivamente implementado como um processo definido para
atingir os seus resultados. Coleta e anlise de dados so realizadas para que esse processo passe a ser mais bem entendido
pela organizao e para que sejam identificados em que pontos
do processo podem ser feitas melhorias contnuas.
AP 4.1: O processo medido: a partir do conjunto de processos padronizados da empresa, medies so realizadas
nos processos relevantes da organizao. Esse atributo uma
medida de quanto os resultados das medies so usados para
melhoria de processos.
AP 4.2: O processo controlado: medida de quanto o processo controlado utilizando-se dados estatsticos.
AP 5.1: O processo objeto de inovaes: medida de
quanto as mudanas no processo so identificadas a partir
de anlise de causas comuns de variao do desempenho e
da investigao de enfoques inovadores para a definio e
inovao do processo. So definidos objetivos de melhoria
no processo. Dados so coletados a partir de medies feitas
estatisticamente para identificar causas comuns de variao
do desempenho do processo.
AP 5.2: O processo otimizado continuamente: medida de
quanto as mudanas tm impacto efetivo para o alcance dos
objetivos relevantes de melhoria do processo.
Descrio dos nveis de maturidade

Como visto, o modelo MPS.BR composto por 7 nveis de
maturidade. Para uma organizao adquirir a certificao nvel A de maturidade, ela deve ter implementados todos os 22
processos descritos no modelo. Com a verso 1.2 do modelo,
foi introduzido um novo conceito, de evoluo de processos.
Isso significa que ao invs de um nvel de maturidade mais
elevado possuir um novo processo de Gerncia de Projetos,
por exemplo, existe a evoluo desse processo que aparece no
primeiro nvel de maturidade. Essa evoluo ocorre tambm
para o processo Gerncia de Configurao.
Aqui, sero descritos com um maior nvel de detalhes o nvel
G de maturidade, pois esse o ponto de partida para uma organizao que deseja adequar seus processos para o MPS.BR.
Nele aparecem dois processos requeridos: o processo Gerncia
de Projeto, que aparece em outros nveis mas com um nvel de
capacidade maior e o processo Gerncia de Requisitos.
30
Nvel G Parcialmente Gerenciado

Este nvel demonstra a importncia do gerenciamento de
projetos para a organizao que pretende obter um modelo de
maturidade de processo. A organizao sai de um ambiente
catico onde processos improvisados so utilizados e o
sucesso depende de verdadeiros heris fazendo com que
constantemente o projeto ultrapasse o oramento previsto.
Para uma organizao poder se considerar como sendo do
nvel G de maturidade, deve implementar os dois processos
requeridos, Gerncia de Projetos e de Gerncia de Requisitos e
esses processos devem possuir atributos de processo de nvel
1.1 e 2.1, explicados anteriormente.
Gerncia de Projetos
O propsito desse processo, de acordo com o guia geral,
o estabelecimento de planos que definem as atividades, recursos e habilidades do projeto, bem como o provimento de
informaes sobre o andamento do projeto que permitam a
realizao de correes quando houver desvios significativos
no desempenho do projeto. Esse processo tem a caracterstica
de evoluir conforme a organizao cresce em nvel de maturidade. Novos resultados so esperados para esse processo
a partir do momento que a organizao atinge o nvel E de
maturidade e novos resultados so incorporados.
Nesse nvel, a gerncia de projeto passa a ser desempenhada
baseada em um processo definido para a organizao como um
todo. Quando a organizao evolui para o nvel B de maturidade, esse processo de gerenciamento passa a ser gerenciado
quantitativamente refletindo a alta maturidade que se espera
da organizao. Alguns resultados esperados evoluem e novos
so incorporados.
Conforme descrito no Guia Geral, os resultados esperados
para o processo de Gerncia de Projetos so:
1. O escopo do trabalho para o projeto definido;
2. As tarefas e os produtos de trabalho do projeto so dimensionados utilizando mtodos apropriados;
3. O modelo e as fases do ciclo de vida do projeto so
definidas;
4. (At o nvel F). O esforo e o custo para a execuo das tarefas e dos produtos de trabalho so estimados com base em
dados histricos ou referncias tcnicas; (A partir do nvel E)
O planejamento e as estimativas das atividades do projeto so
feitos baseados no repositrio de estimativas e no conjunto de
ativos de processo organizacional;
5. O oramento e o cronograma do projeto, incluindo marcos
e/ou pontos de controle, so estabelecidos e mantidos;
6. Os riscos do projeto so identificados e o seu impacto,
probabilidade de ocorrncia e prioridade de tratamento so
determinados e documentados;
7. Os recursos humanos para o projeto so planejados considerando o perfil e o conhecimento necessrios para execut-lo;
8. As tarefas, os recursos e o ambiente de trabalho necessrio
para executar o projeto so planejados;
9. Os dados relevantes do projeto so identificados e planejados quanto forma de coleta, armazenamento e distribuio.
Processo
Um mecanismo estabelecido para acess-los, incluindo, se

pertinente, questes de privacidade e segurana;
10. (At o nvel F). Planos para a execuo do projeto so estabelecidos e reunidos no Plano do Projeto; (A partir do nvel E).
Um plano geral para a execuo do projeto estabelecido com
a integrao de planos especficos;
11. A viabilidade de atingir as metas do projeto, considerando
as restries e os recursos disponveis, avaliada. Se necessrio,
ajustes so realizados;
12. O Plano do Projeto revisado com todos os interessados e o
compromisso com ele obtido;
13. (At o nvel F). O progresso do projeto monitorado com
relao ao estabelecido no Plano do Projeto e os resultados so
documentados; (A partir do nvel E) O projeto gerenciado
utilizando-se o Plano do Projeto e outros planos que afetam o
projeto. Os resultados so documentados;
14. O envolvimento das partes interessadas no projeto
gerenciado;
15. Revises so realizadas em marcos do projeto e conforme
estabelecido no planejamento;
16. Registros de problemas identificados e o resultado da anlise
de questes pertinentes, incluindo dependncias crticas, so
estabelecidos e tratados com as partes interessadas;
17. Aes para corrigir desvios em relao ao planejado e para
prevenir a repetio dos problemas identificados so estabelecidas, implementadas e acompanhadas at a sua concluso;
18. (Nos nveis E, D e C) Um processo definido para o projeto
estabelecido de acordo com a estratgia para adaptao do
processo da organizao; (Nos nveis A e B). Os sub-processos
mais adequados para compor o processo definido para o projeto
so selecionados com base na estabilidade histrica, em dados de
capacidade e em outros critrios previamente estabelecidos;
19. (A partir do nvel E) Produtos de trabalho, medidas e experincias documentadas contribuem para os ativos de processo
organizacional;
20. (A partir do nvel B) Os objetivos para a qualidade e para o
desempenho do processo definido para o projeto so estabelecidos e mantidos.
Como pode ser observado, nem todos os resultados esperados descritos acima valem para o nvel de maturidade G, mas
como esse processo aparece em outros nveis de maturidade
como uma evoluo, os resultados esperados foram descritos
todos aqui.
Gerncia de Requisitos
O objetivo desse processo gerenciar os requisitos dos produtos e componentes e identificar as possveis inconsistncias
entre os requisitos.
Conforme descreve o Guia Geral, o processo Gerncia de
Requisitos possui cinco resultados esperados:
1. O entendimento dos requisitos obtido junto aos fornecedores de requisitos;
2. Os requisitos de software so aprovados utilizando critrios
objetivos;
3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho estabelecida e mantida;

4. Revises em planos e produtos de trabalho do projeto so
realizadas visando identificar e corrigir inconsistncias em
relao aos requisitos;
5. Mudanas nos requisitos so gerenciadas ao longo do
projeto.
Diferentemente do processo de Gerncia do Projeto, que
possui uma caracterstica evolutiva, todos os resultados esperados so requisitos obrigatrios para o alcance do nvel
de maturidade G. Esse processo requisito obrigatrio para a
progresso aos demais nveis de maturidade.
Nvel F Gerenciado
O nvel F, assim como todos os nveis subseqentes, possui
todos os processos descritos no nvel G acrescido de mais quatro processos. Todos os processos acumulados at aqui devem
satisfazer os atributos de processo AP 1.1, AP 2.1, AP 2.2.
Os processos requeridos para esse nvel so:
1. Aquisio: gerenciamento da aquisio de produtos e
servios;
2. Gerncia de Configurao: tem como objetivo estabelecer e
manter a integridade de todos os produtos de trabalho de um
processo ou projeto e disponibiliz-los a todos os membros
do projeto;
3. Garantia da Qualidade: assegurar que os produtos de trabalho e a execuo dos processos estejam em conformidade
com os planos e recursos pr-definidos;
4. Medio: coletar e analisar dados relativos aos produtos
desenvolvidos.
Nvel E Parcialmente Definido

Nesse nvel o processo Gerncia de Projetos sofre sua primeira evoluo, retratando o propsito do nvel E de estabelecer
um processo de gerenciamento definido. Todos os processos
passam a ter os atributos de processo AP 3.1 e AP 3.2.
Os processos desse nvel so:
1. Avaliao e Melhoria do Processo Organizacional: avaliar
a contribuio dos processos padro da organizao;
2. Definio do Processo Organizacional: estabelecer e manter um conjunto de ativos de processo organizacional e padres
usveis e aplicveis s necessidades de negcio;
3. Gerncia de Recursos Humanos: prover os recursos humanos necessrios e manter suas competncias consistentes com
as necessidades do negcio;
4. Gerncia de Reutilizao: gerenciar o ciclo de vida dos
ativos reutilizveis.
Nvel D Largamente Definido

O nvel de maturidade D denota um novo estgio de padronizao da organizao. Novos processos so integrados
ao modelo exigindo que todos os processos anteriores sejam
definidos como padro da organizao.
31
Nesse nvel o processo Desenvolvimento para Reutilizao

sofre evoluo para refletir os atributos de processo requeridos
para esse nvel.
1. Desenvolvimento para Reutilizao: identificar oportunidades para reutilizao e estabelecer um programa de
reutilizao para desenvolver ativos a partir de engenharia
de domnios da aplicao;
2. Gerncia de Riscos: identificar, analisar, tratar, monitorar
e reduzir continuamente os riscos.
Nvel B Gerenciado Quantitativamente

Para este nvel de maturidade no existe nenhum processo
novo. Mais uma vez o conceito de evoluo de processo atribui novos resultados esperados para o processo Gerncia de
Projetos. No nvel B a gerncia de projetos deve ser efetuada
utilizando-se dados estatsticos coletados a partir da anlise
dos processos padres da organizao. Essa anlise quantitativa deve ser feita para outros processos relevantes para a
empresa. Nesse nvel, dois atributos de processo so requeridos para os processos em que a anlise quantitativa mais
relevante, AP 4.1 e AP 4.2.
Concluso
A qualidade de software, especialmente em projetos grandes,
est diretamente ligada maneira como o trabalho de desenvolvimento realizado durante todas as fases do ciclo de vida.
Para grandes empresas de desenvolvimento, como fbricas de
software, a existncia de um processo bem definido dentro da
organizao essencial para a manuteno da qualidade do
produto desenvolvido e para o reaproveitamento de componentes utilizados em projetos anteriores. Alm disso, a grande
quantidade de concorrentes no mercado vem forando essas
empresas a se certificarem em modelos de maturidade. Para
pequenas e mdias empresas, adotar um modelo de maturidade como o CMMI pode ser muito caro. Por isso, a adoo de
um modelo mais adequado sua realidade, como o MPS.BR,
pode trazer benefcios de curto prazo com custos inferiores
aos modelos internacionais.
Referncias
International Organization for Standardization and International Electrotechnical Comission.
ISO/IEC 15504 - http://www.iso.org/iso/iso_catalogue/. Acesso em 05/04/2011
PRESSMAN, R. S. Engenharia de Software, 6 edio, Macgraw Hill, 2006.
SOFTEX, Guia Geral v1.2 http://www.softex.br/mpsbr - Acesso em: 30/03/2011
SOFTEX, Guia de Avaliao http://www.softex.br/mpsbr - Acesso em: 05/04/2011
SOFTEX, Guia de Implementao http://www.softex.br/mpsbr - Acesso em: 05/04/2011
Para uma organizao ser considerada como sendo do nvel

mais alto do modelo MPS.BR, nvel A, ela deve ter todos os
processos implementados e padronizados na organizao, bem
como prover anlise quantitativa para determinados processos
e que esses dados constantemente coletados possam servir para

32
Feedback
eu
sobre e
s
Nvel A Em Otimizao
D
s
Nvel C Definido
a contnua otimizao dos processos de software. Com isso,

um novo processo aparece nesse nvel, a Anlise de Causas
de Problemas e Resoluo, cujo principal objetivo identificar
causas de defeitos e de outros problemas e tomar aes para
prevenir suas ocorrncias no futuro.
edio
ta
1. Desenvolvimento de Requisitos: estabelecer os requisitos

do produto e do cliente;
2. Integrao do Produto: compor os componentes do
produto;
3. Projeto e Construo do Produto: projetar e desenvolver a
soluo para atender os requisitos do cliente;
4. Validao: assegurar que o produto atende o propsito para
o qual foi especificado;
5. Verificao: confirmar que cada servio ou produto atende
os requisitos especificados.
Planejamento e Gerncia
Nesta seo voc encontra artigos voltados para o planejamento
e gerncia de seus projetos de software.
A gerncia de projetos de software em duas

perspectivas Parte 1
O PMBOK
Srie de dois artigos que aborda duas perspectivas em
Gerenciamento de Projetos de TI. So apresentadas e
contrapostas duas vertentes diferentes de tcnicas de
gerenciamento de projetos com o intuito de extrair,
dessa comparao, lies teis e aplicveis maior
parcela possvel de problemas reais de desenvolvimento de sistemas. Nenhuma das duas metodologias
tcnica exclusiva de gerenciamento de projetos de
TI, mas cada uma, em seu tempo, apresenta um diferente nvel de adaptabilidade a essa finalidade. Este
primeiro artigo demonstra a aplicabilidade de uma
norma de gerenciamento mais clssica: o PMBOK.
Para que serve?

Equipes de desenvolvimento de pequeno porte
deparam-se constantemente com a necessidade de
Geraldo Magela Dutra Gonalves

geraldo.magela@ufjf.edu.br
graduado em Engenharia Civil e possui especializao em Anlise e Desenvolvimento de

Sistemas, ambas pela Universidade Federal de
Juiz de Fora. tcnico em TI da Universidade
Federal de Juiz de Fora onde trabalha com
desenvolvimento de sistemas de informao e
informtica desde 1988. professor do Curso
Superior de Tecnologia em Anlise e Desenvolvimento de Sistemas da Fundao Educacional
D. Andr Arcoverde em Valena/RJ.
atividade de desenvolver sistemas de informao relativamente recente. Ainda no se

passaram muito mais de 60 anos desde
que os primeiros programas para computadores foram desenvolvidos. Embora
os seres humanos j acumulassem uma
larga experincia de projeto para execuo de grandes empreendimentos, numa
primeira abordagem, a necessidade de
implantar um processo mais controlado de produo

de software de qualidade enquanto lidam com escassez de mo de obra e recursos. A adoo de uma das
tcnicas de forma customizada pode gerar benefcios
sem um grande aporte de verbas. Os artigos pretendem fornecer conhecimento necessrio para encontrar esse meio termo.

O contedo apresentado neste artigo pode ter
utilidade tanto para apresentar conceitos bsicos inerentes s tcnicas de gerenciamento de
projetos adotadas por cada uma das abordagens
apresentadas assim como fornecer alternativas
de customizao desses processos, compondo
um grupo de tarefas de gerenciamento que seja
realizvel.
projetar o produto de software no se

apresentou muito bvia. Talvez isso tenha se dado devido natureza bastante
especial do produto software, to inovador quanto peculiar. O prprio conceito
de software como produto ainda no
tinha amadurecido.
Ao longo das dcadas, entretanto, a
demanda por quantidade e qualidade
desses produtos forou as comunidades
33
de desenvolvedores a lapidar esses conceitos, e desde ento, at

os dias modernos, tornou-se cada vez mais clara a necessidade
de projetar as etapas de construo de software e, consequentemente, surgiu a necessidade de gerenciar tais processos de
uma maneira racionalizada e formal, com o intuito de alcanar
os objetivos traados, estabelecendo metas intermedirias
que levam concluso do trabalho garantindo um equilbrio
entre trs fatores a princpio conflitantes: escopo, ou alcance,
ou extenso do domnio de um sistema, custo e cronograma
de entrega.
A qualidade do produto resultante uma consequncia direta
do balanceamento desses trs fatores, e se constitui num quarto
elemento agregado aos trs que compem a tripla restrio,
citada por gerentes de projetos. A moderna viso de gerenciamento de projetos se desdobra e acrescenta preocupaes com
administrao de recursos e, principalmente, uma acurada
anlise e gerenciamento de riscos.
Nenhuma das duas vertentes apresentadas nesse artigo foram
nativamente concebidas para emprego exclusivo em gerncia
de projetos de desenvolvimento de sistemas de informao,
citados como projetos de software ou projetos de TI. O primeiro
deles, conhecido como PMBOK (Project Management Body Of
Knowledge) ou Conjunto de Conhecimentos em Gerenciamento de Projetos, pode ser entendido como um grande template,
ou gabarito, que fornece uma grande quantidade de informaes sobre o que se pode determinar como um subconjunto
de um conjunto de conhecimentos em gerenciamento de projetos que amplamente reconhecido como boa prtica. No
se trata, portanto, de uma lista de aes ou de um script a ser
seguido, e sim um grande background que fornece elementos
que comporo um subconjunto realizvel de processos.
J o segundo, SCRUM, referenciado por seus prprios autores ou idealizadores no como uma metodologia, mas como
um framework conceitual, ou seja, um conjunto de conceitos
usado para resolver um problema de um domnio especfico.
Isso significa, tambm, que o SCRUM no estabelece passos ou
normas, e sim apresentar um arcabouo de onde extrair um
modelo de gerncia que produza bons resultados. As equipes
de gerenciamento, tanto aquelas trabalhando com PMBOK
quanto aquelas trabalhando com SCRUM, permanecem responsveis pela determinao do subconjunto adequado para
projetos especficos.
PMBOK Project Management Body of Knowledge

PMI a sigla para Project Management Institute, uma organizao internacional dedicada ao desenvolvimento, registro e
divulgao de boas prticas de gerenciamento de projetos. Uma
iniciativa iniciada em 1969 por cinco pessoas, na Filadlfia, nos
Estados Unidos, transformou-se numa agremiao com mais
de 500.000 associados e com representao em mais de 185
pases. Tais profissionais so oriundos das mais diversas reas
de atuao, j que o PMI no se concentra em uma rea especfica, antes procura abranger qualquer rea onde o conceito
de projeto, e consequentemente gerncia de projeto, possa ser
aplicado com xito. o PMI que edita o guia PMBOK Project
34
Management Body of Knowledge ou Guia do Conjunto de

Conhecimentos em Gerenciamento de Projetos. A cada edio
do PMBOK so incorporadas sugestes de melhoria recebidas
de colaboradores voluntrios no mundo todo, formando uma
rede de cooperao que aprimora constantemente o contedo
do guia.
O objetivo primordial do PMBOK fornecer material suficiente para a composio de uma sequncia de processos de
gerncia que atenda a uma necessidade especfica de desenvolvimento. Nesse sentido, fornece material para composio
de sequncias aplicveis a projetos de desenvolvimento de
sistemas ou projetos de TI. Atravs do conhecimento das reas
abordadas, identifica-se um subconjunto customizado e til
de processos.
Por descrever boas prticas, no significa que tudo aquilo
descrito deva ser aplicado integralmente a todo e qualquer
projeto. A equipe diretamente responsvel pela seleo
de caractersticas aplicveis a um projeto em particular. O
conceito subjacente ao PMBOK, definido no prprio trabalho, o de Apresentar um Conjunto de Conhecimentos em
Gerenciamento de Projetos amplamente reconhecido como
boa prtica. Significa que uma coleo de conhecimentos
adotada e aplicada por uma grande comunidade de equipes de
gerncia, havendo consenso sobre sua utilidade, alm de serem,
em geral, responsveis por aumentar as chances de sucesso
em projetos onde so efetivamente empregadas.
O PMI, com base no vocabulrio comum apresentado no
PMBOK, oferece programas de desenvolvimento profissional,
dos quais o mais conceituado a certificao de profissional
de gerenciamento de projetos - PMP (Project Management
Professional).
Definindo um projeto
As prticas apresentadas e discutidas pelo PMBOK aplicamse, exclusivamente, a projetos, desde que compreendidos na
acepo da palavra. Um projeto um esforo empreendido
por uma equipe no sentido de produzir um resultado nico
e mensurvel, onde podem ser identificados um incio e um
fim. Atividades contnuas, muito comuns em todos os tipos
de organizao no so projetos, so rotinas, e como tais,
gerenciveis atravs de tcnicas e processos diferenciados. O
grupo que empreende o esforo de desenvolvimento do produto no permanecer reunido aps a concluso do projeto,
ele provavelmente ser desfeito e seus membros realocados
com vistas execuo de novos projetos.
Uma particularidade de um projeto a singularidade de suas
entregas. Embora existam similaridades entre os processos de
execuo de diversos projetos, as entregas, parciais ou final,
compostas por produtos, servios, documentos ou outro artefato, so exclusivas, ou seja, adequadas e nicas para a soluo
do problema tratado.
Definindo gerenciamento de projetos

Gerenciar um projeto envolve a aplicao de habilidades e
ferramentas, assim como a aplicao de conhecimento sobre
Engenharia de Software Magazine - A gerncia de projetos de software em duas perspectivas Parte 1
Ges to de Proje tos
processos bsicos envolvidos no desenvolvimento do projeto visando alcanar plenamente seus objetivos e metas. Os diversos processos citados so organizados em
cinco grupos que no tm suas execues
efetuadas em sequncia, pelo contrrio,
apresentam sobreposies significativas,
o que, obviamente, torna o processo de gerenciamento mais delicado e complexo. Os
grupos so ordinariamente denominados:
de iniciao, de planejamento, de execuo, de monitoramento e controle e de
encerramento. Uma caracterstica bastante
marcante do processo de gerenciamento
a capacidade da liderana do projeto em
lidar com incertezas. Em outras palavras,
a identificao e preparao para lidar
com riscos de projeto podem significar
a diferena entre sucesso e fracasso.
Figura 1. reas de Conhecimento e suas Intersees
cada vez mais patente a necessidade de
conhecer os riscos existentes, mensurar
a probabilidade de sua ocorrncia, avaliar o impacto causado
aplicao, onde residiro conhecimentos, habilidades, normas,
quando de sua ocorrncia e preparar um plano de contingncia
regulamentos e ferramentas especficas de desenvolvimento
para seu enfrentamento.
na rea de TI. claro que essa especializao ter repercusses
nas outras quatro reas, forando a eliminao de processos
Habilidades e conhecimentos necessrios ao
desnecessrios em funo dessa especificidade. Considerando
gerenciamento de projetos
essa aplicao exclusiva, a rea especfica da aplicao engloba
O Guia PMBOK apresenta uma coleo de processos aplitambm todas as metodologias e ferramentas empregadas em
cveis a toda classe de projetos. Esses processos so excluengenharia de software.
sivamente utilizados em gerenciamento de projetos, mas
O entendimento do ambiente do projeto passa pela compreno so, por si s, completamente suficientes para suprir um
enso, por parte da equipe de gerenciamento, das nuances
processo completo e eficiente de gerenciamento. Para que o
particulares do domnio onde o sistema atuar, ou seja, em
processo torne-se realmente eficiente necessrio agregar
que contexto o sistema existir. Esses diferentes contextos, que
conhecimentos e habilidades oriundos de cinco reas que so
abrigaro diferentes sistemas, precisam ser compreendidos
complementares em alguma medida, gerando um conjunto
em suas vises diferenciadas, quais sejam, as vises cultural
interdisciplinar eficiente:
e social, internacional e poltica, assim como o ambiente fsico
conhecimentos e habilidades em gerenciamento de
propriamente dito. Como um exemplo, a equipe precisa ter
projetos;
bem dimensionado qual o impacto que o projeto causa nas
conhecimentos, normas e regulamentos da rea especfica
vidas das pessoas afetas ao contexto, assim como que tais
da aplicao;
pessoas afetam o projeto.
entendimento do ambiente de projeto;
Habilidades e conhecimentos de gerenciamento geral
conhecimento e habilidades de gerenciamento geral;
tornam-se teis na medida em que qualquer gerenciamento
habilidades interpessoais.
especfico foi delas, pelo menos parcialmente, derivado. Preocupaes como logstica, treinamentos, prticas de sade,
Conhecimentos e habilidades da rea de gerenciamento
aquisies e dezenas de outros itens considerados em gerende projetos obviamente se sobrepem s demais. A Figura 1
ciamento geral aplicam-se integralmente a qualquer tipo de
mostra como esta rea envolve partes significativas das outras,
projeto em decurso.
e destaca as intersees apresentadas por elas.
Entre outros desafios inerentes ao processo de gerenciamento
A figura demonstra a interao entre os conhecimentos e
de projetos destaca-se a difcil tarefa de gerir pessoas. Essa hahabilidades das disciplinas envolvidas, demonstrando clarabilidade deriva muito mais de habilidades interpessoais inatas
mente que gerenciamento de projetos as congrega de maneira
do que de treinamento especfico, embora tal habilidade possa
geral. Outro ponto esclarecedor contido na figura citada
ser desenvolvida e aperfeioada. Habilidades interpessoais
a possvel aplicao exclusiva de PMBOK a projetos de deaplicadas a equipes de gerenciamento e/ou desenvolvimento
senvolvimento de sistemas de informao ou projetos de TI.
incluem liderana, motivao, mediao e, principalmente,
Isso se d pela especializao completa da rea especfica da
comunicao eficaz.
35
Na verdade, no poucas vezes se constata que a gesto de pessoas torna-se um ponto nevrlgico nos processos de gerncia
de qualquer projeto. Sem querer adiantar demais concluses
da comparao proposta no princpio do artigo, pode-se aqui
colher uma primeira lio sobre a dirigibilidade de uma equipe
de desenvolvimento de sistemas. Grandes equipes tornam-se
no gerenciveis e mtodos mais modernos de gerncia, a
exemplo do SCRUM, indicam equipes com tamanho entre 7
e 9 profissionais. Se a equipe total bem maior do que isso,
prefervel compor sub-equipes e constituir uma hierarquia
de gerncias. A gerncia de pessoas inclui capacidades como
gerenciamento de conflitos, motivao pessoal e clareza na
forma de comunicao. O trabalho de cada sub-equipe pode ser
considerado um subprojeto, desde que as entregas de cada um
deles sejam coordenadas, j que existiro interdependncias.
O trabalho de coordenao dessas sub-equipes, integrao desses sub-projetos e padronizao dos procedimentos
utilizados entre diversos projetos realizados por uma nica
organizao, pode tornar-se uma atividade rdua, requerendo,
ela prpria, um esforo adicional de gerncia.
Uma prtica valiosa para lidar com esta tarefa estabelecer
uma unidade dentro da organizao, denominada PMO Project Management Office, ou escritrio de gerncia de projetos.
Dentre diversas outras atribuies, um PMO deve padronizar
procedimentos, promover difuso de prticas bem sucedidas,
propor a eliminao de etapas pouco produtivas, oferecer compartilhamento de recursos entre equipes (materiais e humanos)
assim como oferecer treinamento para novos integrantes das
equipes, evitando a paralisao de membros da equipe de
desenvolvimento para nivelamento de conhecimento.
claro que um PMO ser tipicamente mais til em organizaes que trabalham efetivamente com a filosofia de projetos,
principalmente para catalogar e disponibilizar uma memria
de projetos dessa organizao. Os processos de gerncia de projetos de desenvolvimento de sistemas valem-se extensivamente
do uso de mtricas de estimativa de esforo, custo e prazo e tais
mtodos so extremamente dependentes de um memorial de
dados histricos de projetos anteriores, sejam sucessos, sejam
fracassos, e os PMO so decisivos neste campo.
Ciclo de vida dos projetos e partes interessadas

Ciclo de vida de um projeto o conjunto de fases que interligam seu incio ao seu final. A experincia acumulada por
milhares de desenvolvedores ao longo de dcadas de esforo,
indica que esse ciclo no deve ser tratado como uma coisa
esttica, ou seja, invivel tentar aplicar uma srie de etapas
fixas a todo e qualquer tipo de projeto, j que particularidades
presentes em cada um deles exigiro medidas e procedimentos
customizados. Normalmente as fases do ciclo de vida de um
projeto so encadeadas de maneira sequencial e interconectadas atravs de entregas parciais de artefatos, mas, invariavelmente existem sobreposies de fases que exigem um maior
esforo de gerncia.
Dentre as inmeras habilidades requeridas por gerentes ou
equipes de gerenciamento de projetos, figura a de gerenciar a
36
satisfao do grupo de partes interessadas no desenvolvimento

do projeto (stakeholders), no que tange a entregas parciais
e sua respectiva qualidade, prazos e manuteno de custos
previstos, considerando que os interesses de tais partes geralmente se apresentam conflitantes. Entre o heterogneo grupo
de pessoas que compem o grupo de stakholders para um
determinado projeto destacam-se gerentes de projeto, usurio/
cliente, ou seja, aqueles que efetivamente utilizaro o sistema,
desenvolvedores, patrocinadores dentre outros interessados
que podem ser influenciadores ou influenciados, tanto pelo
projeto em curso quanto pelo produto que dele advir. Os
profissionais que integram o PMO, se ele existir, completam
o time de stakeholders para um projeto.
A norma de gerenciamento de projetos como descrita

no PMBOK
A norma de gerenciamento descrita pelo PMBOK baseia-se
em trs elementos descritos a seguir. O gerenciamento de
projetos se d pela execuo de processos, que so atividades
ou grupo de atividades que se encadeiam de forma complexa
e sobreposta, gerando produtos intermedirios no processo
de desenvolvimento do projeto. Tais processos devem ser
executados numa sequncia lgica e, para tanto, integram
grupos de processos, que so por sua vez executados em uma
relativa cronologia. Os grupos de processos so os de iniciao,
de planejamento, de execuo, de monitoramento e controle
e de encerramento. Embora suas prprias denominaes j
sugiram certa ordem entre tais grupos, sua execuo no deve
ser entendida como estritamente sequencial.
Finalmente, os processos de gerncia implementam atividades e prticas que permeiam nove reas de conhecimento
distintas, consideradas como primordiais para a composio
de um processo conciso de gerncia e execuo de um projeto.
Sintetizando estes conceitos em uma frase, pode-se definir uma
norma de gerenciamento de projetos como a adoo, dentre um
vasto elenco de possibilidades, de um conjunto de processos
de gerenciamento que compem grupos de processos de gerenciamento, pertencentes, por sua vez, ao mbito de variadas
reas de conhecimento.
Um dos conceitos norteadores dessa estrutura de processos aquele denominado PDCA (PlanDoCheckAct) ou
(PlanejarFazerVerificarAgir). No entanto, a estrutura de
processos de gerncia do ciclo de vida de um projeto mais
complexa. A Figura 2 ilustra de maneira acurada os relacionamentos existentes entre os processos constituintes dos grupos
de processos de gerncia. Nela est representado de forma
muito clara como os processos de monitoramento e controle
mantm contato com todos os demais processos dos outros
grupos, envolvendo-os.
preciso enfatizar que para um determinado projeto nem
todos os processos pertencentes a um determinado grupo
de processos devero ser completamente adotados. A habilidade da equipe de gerncia passa pelo bom discernimento
entre aqueles que sero teis e produtivos e aqueles que podero ser desconsiderados. um processo de adequao ou
Ges to de Proje tos
customizao. Um ponto delicado, nessa atividade, a integrao entre processos. Geralmente no trivial e no representvel
graficamente de maneira simples, a integrao pode demandar
um esforo pontual acentuado, e impactar de forma significativa o andamento da fase de execuo do projeto.
Grupo de processos de iniciao

Um projeto, de qualquer natureza, deve ser formalmente
iniciado. Dentro de dezenas de providncias que se fazem
necessrias, este grupo de atividades providencia o desenvolvimento de um termo formal de abertura assim como uma
declarao preliminar de escopo para o projeto. A iniciao
formal do projeto pode ento ser encaminhada, incluindo sua
diviso em fases, to complexas quanto forem a complexidade
e a extenso do escopo preliminar. O termo de abertura praticamente autoriza o projeto, ou pelo menos seus levantamentos
preliminares. A declarao preliminar de escopo estima o tamanho e complexidade do projeto, requisitos, limites entregas
parciais e finais.
Grupo de processos de planejamento

Os processos integrantes deste grupo conduzem ao desenvolvimento de um plano de gerenciamento do projeto. Um documento formal ou conjunto de documentos, que identificam
requisitos, traduzem este conjunto de requisitos em modelagem (no caso especfico de projetos de TI) que amadurecem
tanto as estimativas iniciais de escopo assim como custos e
demandas por recursos materiais e humanos.
Este processo iterativo: o plano de gerenciamento de projeto sofre atualizaes atravs de detalhamentos sucessivos
ou detalhamento progressivo, que impede o congelamento
dos planos de enfrentamento de riscos, principal obstculo
concluso de projetos com xito, principalmente aqueles com
cronograma mais extenso. De um conjunto de processos abrangente, a equipe que executa os processos de planejamento elege
aqueles que precisam ser realizados. O conjunto de possveis
processos de planejamento inclui o desenvolvimento do plano de gerenciamento de projeto propriamente dito, contendo
todos os detalhes citados a seguir, alm de um amadurecido
planejamento e definio de escopo.
A subdiviso do trabalho em componentes menores uma
consagrada estratgia de dividir para conquistar: o processo de
criao de uma EAP Estrutura Analtica de Projeto, antecipa
o emprego dessa forma de resolver problemas complexos. Para
atingir os objetivos finais do projeto, ele divido em etapas
que produzem entregas parciais atravs da realizao de atividades. Em relao a estas, dentro do grupo de processos de
planejamento, necessrio defini-las, planejar seu sequenciamento, estimar os recursos necessrios sua execuo e avaliar
a durao de cada uma delas. Com este conjunto de processos
realizados, possvel criar um cronograma.
Em relao a custos, uma estimativa geral de custos precede
um processo de oramentao, que estima custos por atividade. O planejamento do gerenciamento dedica-se tambm
a planejar a qualidade do produto entregue, quantidade e
Figura 2. Grupos de Processos e o Ciclo PDCA
qualidade dos recursos humanos empregados e planejamento

das comunicaes, incluindo as estratgias de disponibilizao
de informaes de fora para dentro das equipes de projeto,
assim como uma efetiva comunicao interna.
Um sub-grupo de processos que se destaca aquele concernente aos riscos de projeto. De uma atividade historicamente
preterida, tornou-se com o tempo em fator determinante de
fracasso ou sucesso. Processos dedicados devem planejar o gerenciamento de riscos, identific-los, promover sobre eles anlises quantitativas e qualitativas, alm do planejamento mais
fundamental sobre riscos: elaborar planos de contingncia, ou
seja, planos de respostas a ocorrncias de riscos. Finalizando, o
plano de gerenciamento de projeto deve prever como conduzir
compras e aquisies, assim como contrataes.
Grupo de processos de execuo

Os processos que integram esse grupo realizam o trabalho
para o qual o projeto foi criado. Dependendo da natureza e da
rea especfica para a qual o projeto foi idealizado, processos
aqui sofrero significativas adaptaes, assim como acrscimos
e cortes. Mas de uma maneira genrica, os processos neste
grupo dedicam-se a orientar e gerenciar a execuo planejada,
realizar as medidas de planejamento de qualidade, contratar
e desenvolver a equipe de projeto, distribuir informaes
s partes interessadas, assim como selecionar fornecedores
filtrando respostas s solicitaes efetuadas.
Considerando projetos de TI, aqui devero ser adicionados
processos de gerncia exclusivos sob metodologias de desenvolvimento de sistemas, que garantam no s a realizao do
objetivo, mas que tambm garantam os nveis de qualidade
projetados para os produtos resultantes.
Grupo de processos de monitoramento e controle

Monitorar e controlar so atividades que visam, principalmente, facilitar aes corretivas em face de desvios de rumo.
Os processos desse grupo preocupam-se em no permitir que
o projeto afaste-se daquela rota inicialmente traada. Como
praticamente impossvel evitar que imprevistos ocorram, de
37
fundamental importncia manter vigilncia constante sobre

o desempenho geral do projeto como subsdio indispensvel
para a tomada de decises crticas de correo de rumos e ou
alteraes controladas.
Assim, torna-se necessrio controlar o trabalho bem como
os fatores que podem criar mudanas, garantindo que, se
elas ocorrerem, que sejam benficas ao projeto. Para tanto,
fundamental verificar e controlar o escopo (ele pode suportar
variaes ao longo do tempo, mas quase nunca as radicais),
controlar as variaes de custos e modificaes no cronograma
de trabalho (sempre considerando que estas so extremamente
impactantes no resultado final), monitorar os resultados em
relao qualidade (por exemplo, no permitir que ajustes
de custos reflitam negativamente na qualidade), gerenciar e
mediar problemas na equipe de projeto, produzir relatrios
de desempenho, inclusive para gerenciar as expectativas dos
diversos stakeholders, alm monitorar o processo de controle
dos riscos.
Na verdade, os processos deste grupo permitem o exerccio
pleno de gerncia, entendido como a capacidade de tomar
decises de forma rpida e segura, baseadas em um conjunto
de dados normalmente pequeno e diversas vezes conflitantes,
garantindo assim a volta ou manuteno do projeto num rumo
que o leve a bom termo.
Grupo de processos de encerramento

Para um determinado projeto, podem existir um ou vrios
contratos relacionados. Nesse grupo de processos, encontram-se aqueles destinados a formalizar o encerramento do
projeto com o fechamento de todos os contratos abertos com
os respectivos aceites de entregas de produtos por parte dos
contratantes.
Intersees entre os processos de grupos diferentes

Embora exista certa ordem de execuo implcita entre os grupos de processos de gerenciamento e as sadas de determinados
processos constituam entradas para processos subsequentes,
existem sobreposies importantes entre esses processos ao
Figura 3. Sobreposio de Grupos de Processo
38
longo do ciclo de vida do projeto ou, iterativamente, ao longo

de fases de um projeto longo. Tais intersees no so idnticas
entre projetos diferentes e no so representveis graficamente
de forma precisa e trivial. Ainda assim, a Figura 3 demonstra,
de modo aproximada, como os processos se desenvolvem e se
sobrepem ao longo do ciclo de vida do projeto.
As reas de conhecimento em gerenciamento de

projetos
Os grupos de processos de gerenciamento apresentados anteriormente agrupam tais processos de acordo com a fase do
ciclo de vida do processo em questo, embora no estritamente.
Todavia, os processos executam atividades que pertencem ao
mbito de grandes reas de conhecimento relacionadas ao
desenvolvimento de projetos. Assim, uma outra classificao,
bem mais detalhada, apresentada no PMBOK, agrupando os
processos em suas respectivas reas.
Como um conjunto nada trivial de processos que se sucedem,
interagem e se sobrepem, um projeto necessita de um rgido
controle de integrao dessas partes. A rea de conhecimento
Gerenciamento de Integrao do Projeto dedica-se a essa delicada tarefa. Ela congrega processos ao longo de todo o ciclo
de vida do projeto, orientados em controlar entradas e sadas,
encadeando os resultados ou entregas parciais.
Assim, um processo pertencente ao Grupo de Processos
de Iniciao, qual seja, Desenvolver o Termo de Abertura do
Projeto, tambm um processo da rea de Gerenciamento de
Integrao do Projeto. Pelo exposto, pode-se perceber que a
representao grfica dos processos, delimitados por fronteiras
que representassem tanto os grupos quanto as reas de conhecimento, resultaria em um documento de visualizao difcil
ou confusa. Para fornecer uma visualizao mais limpa, a
Figura 4 apresenta as reas de conhecimento sem delimitar
grupos, enquanto que o texto seguinte enumera os processos
de cada rea pelo nome e apresenta, entre parntesis, o grupo
a que o processo pertence.
rea de Gerenciamento de Integrao do Projeto: Os
processos dessa rea, executados ao longo do ciclo de vida
do projeto so: Desenvolver o Termo de
Abertura do Projeto (iniciao), Desenvolver a Declarao do Escopo Preliminar do
Projeto (iniciao), Desenvolver o Plano de
Gerenciamento do Projeto (planejamento),
Orientar e Gerenciar a Execuo do Projeto
(execuo), Monitorar e Controlar o Trabalho do Projeto (monitoramento e controle),
Controle Integrado de Mudanas (monitoramento e controle) e Encerrar o Projeto (este
ltimo processo pertencente ao grupo de
processos de encerramento).
rea de Gerenciamento do Escopo do
Projeto: Escopo de um projeto pode ser
entendido como o alcance de atuao de um
projeto dentro de seu domnio mais amplo.
Na verdade, a determinao da natureza e
Ges to de Proje tos
Figura 4. reas de Conhecimento
extenso do escopo torna-se um fator crtico de sucesso, assim

como o o gerenciamento de seu desenvolvimento durante
o projeto. Trata-se de fazer tudo o que necessrio e apenas
o que necessrio. Integram a rea os seguintes processos:
Planejamento do Escopo (planejamento), Definio do Escopo (planejamento), Criar EAP (planejamento), Verificao
do Escopo (monitoramento e controle) e Controle do Escopo
(monitoramento e controle).
rea de Gerenciamento de Tempo do Projeto: quase
desnecessrio citar a importncia de dedicar processos de gerncia especficos para essa finalidade. Um dos pontos centrais
de preocupao de uma equipe de gerncia, j que o tempo
uma grandeza que no pode ser manipulada diretamente.
Outras grandezas como o prprio escopo ou a qualidade do
produto final podem sofrer ajustes, o tempo s ajustvel em
uma dimenso: mais tempo. Os processos dedicados dessa
rea so: Definio das Atividades (planejamento), Sequenciamento das Atividades (planejamento), Estimativa de Recursos
das Atividades (planejamento), Estimativa da Durao das
Atividades (planejamento), Desenvolvimento do Cronograma
(planejamento) e Controle do Cronograma (monitoramento e
controle).
rea de Gerenciamento de Custos do Projeto: Envolve
planejamento, estimativa, oramento e controle de custos.
Outra atividade delicada j que determinante de sucesso

ou fracasso. Processos: Estimativa de Custos (planejamento),
Oramento e Controle de Custos (planejamento).
rea de Gerenciamento da Qualidade do Projeto: Processos
dedicados a perseguir os objetivos fixados para o projeto, mas
pelo caminho mais econmico e mais elegante. Os processos
componentes so: Planejamento da Qualidade (planejamento),
Realizar a Garantia da Qualidade (execuo), Realizar o Controle da Qualidade (monitoramento e controle).
rea de Gerenciamento de Recursos Humanos: Selecionar,
treinar, compor as equipes e nivelar conhecimento entre seus
membros uma forma de garantir produtividade e alcanar
resultados de qualidade projetada. Os processos so: Planejamento de Recursos Humanos (planejamento), Contratar ou
Mobilizar as Equipes de Projeto (execuo), Desenvolver as
Equipes de Projeto (execuo) e Gerenciar as Equipes de Projeto
(monitoramento e controle).
rea de Gerenciamento de Comunicaes do Projeto: Comunicao gil e eficaz. Fator de importncia destacada em
qualquer processo torna-se crtico em projetos extensos e/ou
complexos. Os efeitos negativos advindos de comunicao
ineficiente podem ser muitas vezes incontornveis. Processos
dedicados: Planejamento das Comunicaes (planejamento), Distribuio das Informaes (execuo), Relatrio de
39
40
Referncias
Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos - Guia PMBOK Quarta edio C 2009 Project Management Institute, Four Campus Boulevard, Newtown
Square, PA 19073-3299 EUA

Feedback
eu
sobre e
s
O PMBOK muito mais detalhado do que o resumo apresentado at aqui. Ele apresenta todos os processos de todas as
reas em termos de entradas e sadas esperadas ou desejadas,
alm de organizar os processos em atividades encadeadas
atravs de fluxogramas detalhados.
Neste guia, que uma norma nacional americana, o gerente
ou gerentes interessados em compor um subconjunto de processos adequados a um projeto especfico, encontra subsdio
suficiente para, alm de montar esse conjunto, colher dicas
de tcnicas utilizadas na execuo de dezenas de atividades
relacionadas. Entretanto preciso que se faa, neste ponto,
uma reflexo sobre a aplicabilidade dessa metodologia. Uma
simples avaliao do alcance desse conjunto de processos e
D
s
Concluso
uma estimativa do esforo necessrio para empreender projetos com qualquer subconjunto deles deixa claro que PMBOK
parece mais adequado a projetos de mdio para grande portes,
e se tornaria um processo emperrado se aplicado a pequenos
empreendimentos.
Outra concluso bastante natural a de que PMBOK produz
resultados palpveis em projetos de qualquer natureza cuja
complexidade no seja a trivial e cuja durao exija a aplicao
de gerncia continuada. Na verdade, a grande quantidade de
informao que entregue pelo guia, assusta, numa primeira
avaliao, o gerente interessado em implantar uma metodologia intermediria. Mas no se pode perder de vista que
PMBOK perfeitamente adaptvel, tendo sido criado com
essa finalidade.
Atravs das dcadas em que se desenvolveram as metodologias e as tcnicas de desenvolvimento de sistemas de informao, cresceu sempre a demanda por produtos de maior qualidade, confiabilidade, custo razovel e entregues com rapidez, ou
seja, entrava para o jargo da rea, definitivamente, a ideia de
agilidade, entrega rpidas, mas sem prejuzo da qualidade. O
contexto moderno de desenvolvimento de sistemas de informao valoriza essa nova vertente sem abrir mo de metodologias
mais robustas, como o PMBOK demonstrado aqui.
O prximo artigo desta srie abordar o SCRUM, mais que
uma metodologia, um framework conceitual idealizado para
gerenciar processos de produo geis.
edio
ta
Desempenho (monitoramento e controle) e Gerenciar Partes

Interessadas (monitoramento e controle).
rea de Gerenciamento dos Riscos de Projeto: Falando especificamente de projetos de desenvolvimento de sistemas de
informao, as metodologias de desenvolvimento evoluram de
um patamar quase romntico, quando no eram considerados
quaisquer fatores externos que pudessem afetar sua progresso
at as modernas metodologias onde os riscos de projeto so
objeto de estudo atento por parte de equipes de gerncia. Conhecer os riscos, avaliar as probabilidades de sua ocorrncia e
elaborar planos de contingncia, so lies aprendidas a duras
penas nas ltimas dcadas. Os processos: Planejamento do Gerenciamento de Riscos (planejamento), Identificao dos Riscos
(planejamento), Anlise Qualitativa dos Riscos (planejamento),
Anlise Quantitativa dos Riscos (planejamento), Planejamento
de Respostas a Riscos (planejamento) e Monitoramento e Controle de Riscos (monitoramento e controle).
rea de Gerenciamento de Aquisies do Projeto: Compra
de servios e produtos, alocao de recursos e gerenciamento
de contratos secundrios. Processos: Planejar Compras e
Aquisies (planejamento), Planejar Contrataes (planejamento), Selecionar Respostas de Fornecedores (execuo),
Selecionar Fornecedores (execuo), Administrao do Contrato (monitoramento e controle) e Encerramento do Contrato
(encerramento ).
Desenvolvimento
Nesta seo voc encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software
Refatorao para Padres Parte 10

Utilizando tcnicas de refatorao para padres para implementar os
padres Adapter e Interpreter
Aborda o tema refatorao para padres com o objetivo de mostrar como o desenvolvedor pode uslo para melhorar o cdigo-fonte de suas aplicaes.
Para que serve?
Jacimar Fernandes Tavares

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

- Faculdade Governador Ozanam Coelho,
Microsoft Student Partners.

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.
s tcnicas de refatorao para

padres apresentadas nos artigos anteriores so focadas
em alguns cenrios que evidenciam a
necessidade de refatorar para um determinado padro. Este artigo, por sua vez,
no sair desta linha de raciocnio, pois
tem como base cenrios propcios para
a implementao dos padres que aqui
sero abordados: Adapter e Interpreter.
O primeiro cenrio configura-se a
partir da necessidade de utilizar uma
funcionalidade por parte do programador. A princpio, a primeira ao a de
verificar se tal funcionalidade j existe
evitando assim que uma nova e desnecessria funcionalidade seja escrita. Em
alguns casos, a interface de uma classe
pode no fornecer a funcionalidade
Para prover conhecimento ao desenvolvedor sobre

refatorao para padres e demonstrar atravs
de exemplos prticos a aplicao das tcnicas de
refatorao para padres Unificar Interfaces com
Adapter, Extrair Adapter e Substituir Linguagem
Implcita por Interpreter.

O tema se torna fundamental para desenvolvedores que j esto familiarizados com padres
de projeto e j os implementam em seus softwares e que querem saber mais sobre refatorao
para padres, conhecendo os benefcios que sua
utilizao traz.
desejada. Ao invs de modificar a interface para ento prover a funcionalidade

desejada, pode-se criar um adaptador,
que ficar responsvel por fornecer novas funcionalidades ao desenvolvedor.
Em outro cenrio, pode-se ter um
41
problema relacionado duplicao de cdigo de validao de

dados. Quando se tem muito cdigo de validao de dados
interessante que este esteja centralizado em um local, como
uma classe, para ser invocado quando necessrio. Validar dados envolve interpret-los primeiramente, e a criao de um
interpretador pode ser muito til neste sentido.
As tcnicas de refatorao que o desenvolvedor deve conhecer para um melhor entendimento sobre as refatoraes
para padres deste artigo so Extrair Classe, Extrair Mtodo,
Mover Mtodo, Extrair Subclasse, Subir Mtodo na Hierarquia,
Extrair Superclasse e Internalizar Mtodo (ver Nota 1). Uma
breve descrio dos padres Adapter e Interpreter tambm ser
apresentada antes de iniciar o processo de aprendizagem das
refatoraes para padres.
As consequncias: A implementao de tal interpretador

permitir ao desenvolvedor centralizar nas suas classes o
cdigo responsvel por analisar os dados e efetuar verificaes mediante a linguagem pr-definida por ele. Sendo
assim, cada gramtica que o sistema deve utilizar ser mais
fcil de ser mantida, pois o padro de projeto Interpreter
facilita essa adio e atualizao de gramticas.
Depois de uma breve introduo sobre os padres de
projeto que este artigo aborda, chegado o momento de
conhecer as tcnicas de refatorao para padres Unificar
Interfaces com Adapter, Extrair Adapter e Substituir Linguagem Implcita por Interpreter.
O padro de projeto Adapter
Resumo: O cdigo cliente comunica com duas classes,

preferencialmente com a interface de uma delas. Cria-se
um adaptador para unir as interfaces.
Motivao: Obter cdigo cliente simples no uma tarefa
simples, mas as refatoraes para padres tm mostrado que
possvel diminuir a complexidade existente nesse cdigo.
Em alguns momentos o desenvolvedor se depara com classes que tem a mesma funo ou funes parecidas, cdigo
cliente complexo, e interfaces de classes que no podem ser
alteradas, dado que no se tem permisso. Nestes casos, a
implementao de um adaptador se faz necessrio, o que
proporcionar um cdigo mais generalizado, facilitando o
acesso por parte dos clientes.
Vantagens: Permite a reduo de cdigo duplicado, ao direcionar o cdigo cliente para acessar uma interface que unifica
diversas classes; Permite a simplificao do cdigo cliente, que
acessar apenas uma interface para se comunicar com diversas
classes; Cria uma forma padro de como os clientes vo acessar
as classes que tiveram suas interfaces unificadas.
Desvantagens: Torna o projeto de cdigo existente mais
complexo, quando se tem permisso para alterar uma interface, mas se opta por adapt-la.
Mecnica:
1. Dado que existem duas classes e que se deseja comunicar
com as duas utilizando uma interface comum, aplica-se a
refatorao Extrair Interface na classe mais usada entre as
duas. Se a classe mais usada tiver mtodos cujos parmetros
so objetos dessa mesma classe, modifica-se para objetos
da interface criada.
2. Considerando a classe menos utilizada, busca-se por uma
classe que seja cliente dela. Aplica-se a refatorao Extrair
Classe. A classe extrada ser o Adapter que ser usado no
trabalho de unificar as interfaces. A classe Adapter extrada
deve possuir um atributo do tipo da classe menos utilizada,
um construtor que recebe como parmetro um objeto da
classe menos usada e atribua-o ao atributo declarado, e um
mtodo que retorne o atributo declarado.
3. A classe cliente deve ser atualizada, trocando-se as referncias da classe menos utilizada por referncias classe
Adapter criada.
Nome do padro de projeto: Adapter. Pertencente ao conjunto dos padres de projeto classificados como Padres
Estruturais.
O problema: Em determinado momento no desenvolvimento
de uma aplicao, o desenvolvedor pode se deparar com a necessidade de utilizar uma classe e perceber que sua interface
no prov as funcionalidades que ele precisa. O padro Adapter
atua neste contexto, permitindo ao desenvolvedor, ao invs de
modificar a interface da classe, criar um adaptador, que ser
responsvel por adaptar a interface que no corresponde s
necessidades do desenvolvedor em uma que corresponda.
As consequncias: Como consequncia, tem-se uma aplicao cujas classes podem ser mais bem utilizadas, dado que ao
se criar um adaptador, a utilidade da classe aumenta, mediante
aos novos recursos que ela prover.
O padro de projeto Interpreter

Nome do padro de projeto: Interpreter. Pertencente ao
conjunto dos padres de projeto classificados como Padres
Comportamentais.
O problema: Algumas aplicaes fazem uso de muito cdigo
para analisar, por exemplo, entradas do usurio e verificar se
elas pertencem a uma gramtica definida pelo desenvolvedor, e ento validar tais dados. Uma prtica neste sentido a
definio de vrias estruturas para analisar essas entradas,
espalhando esse cdigo de verificao por vrios pontos do
sistema. O padro de projeto Interpreter permite a criao de um
interpretador que concentrar esse cdigo de verificao.
Nota do DevMan 1
Refatoraes apresentadas em outros artigos
As tcnicas de refatorao Extrair Classe, Extrair Mtodo, Mover Mtodo, Extrair
Subclasse, Subir Mtodo na Hierarquia, Extrair Superclasse e Internalizar Mtodo j
foram apresentadas em outras edies da Engenharia de Software Magazine, mais
precisamente nas edies de nmero 29, 30, 33 e 34.
42
A refatorao para padres Unificar Interfaces com

Adapter
Engenharia de Software Magazine - Refatorao para Padres Parte 10
Desen volvimento
4. No cdigo cliente, que agora se comunica com a classe

Adapter, ao invs da classe menos usada, aplica-se a refatorao Extrair Mtodo para criar uma forma mais convencional
de acessar os mtodos da classe menos usada.
5. O mtodo extrado no passo 4 deve ser movido para a classe
Adapter com a refatorao Mover Mtodo. O mesmo processo
deve ser feito em todos os mtodos extrados no passo 4.
6. Agora a classe Adapter deve implementar, juntamente com
a classe mais usada, a interface extrada no passo 1. Talvez
seja necessrio atualizar a classe Adapter para se comunicar
efetivamente com a interface extrada.
7. Modificam-se todos os pontos que passaram a invocar o
Adapter no passo 3 por referncias interface extrada no
passo 1. A partir de ento, as duas classes se comunicaram
e podero ser acessadas pela mesma interface. Para reduzir uma possvel duplicao de cdigo existente, aplica-se
a refatorao Criar um Mtodo Padro e/ou a refatorao
para padres Introduzir Criao Polimrfica com Factory
Method, caso necessrio.
Exemplo: O exemplo a seguir mostra duas classes, Financiamento e Emprestimo. A classe Financiamento a mais
utilizada por grande parte do cdigo cliente que se comunica com as duas classes. J a classe Emprestimo no se tem
permisso para se modificar, portanto ela ser a classe que
se deseja adaptar. As Listagens 1 e 2 mostram as classes e
alguns de seus mtodos (aqueles que se deseja acessar via
interface nica).
O primeiro passo envolve a criao de uma interface com
Extrair Interface sobre a classe Financiamento. Posteriormente, atualiza-se a classe Financiamento para que passe
a implementar o mtodo que foi declarado na interface, no
caso o mtodo CalcularRiscoEmprestimo. A Listagem 3
mostra a interface.
O passo 2 sugere que a refatorao Extrair Classe seja usada
em uma classe cliente da classe Emprestimo. A classe Adapter extrada deve ainda receber algum cdigo, como sugere
o passo 2. A Listagem 4 mostra a classe extrada.
No passo 3, atualizando o cdigo cliente da classe menos
utilizada para referenciar a classe Adapter, tem-se o resultado que pode ser visto na Listagem 5.
Ao utilizar a refatorao Extrair Mtodo, como sugere o
passo 4, tem-se um mtodo que dever ser movido para a
classe Adapter, como parte do passo 5. A Listagem 6 mostra
o mtodo extrado e movido para a classe Adapter.
Modifica-se a classe Adapter para que passe a implementar
a interface comum, juntamente com a classe Financiamento.
Agora, a classe Financiamento e Emprestimo (via classe
Adapter) compartilham a mesma interface comum.
A refatorao para padres Extrair Adapter

Resumo: Uma classe possui mecanismos para adaptar vrias
verses de um componente, biblioteca, API, etc. Usa-se Extrair
Adapter para criar uma verso para cada verso dos componentes, bibliotecas, API, etc.
Listagem 1. Classe Financiamento.
01. public class Financiamento

02. {
03. public Decimal CalcularMedia(ArrayList listaValores)
04. {
05.
Int32 qtdValores = listaValores.Count;
06.
Decimal somaValores = 0.0m;
07.
Decimal media = 0.0m;
08.
for (Int32 i = 0; i < listaValores.Count; ++i)
09.
{
10.
somaValores += Convert.ToDecimal(listaValores[i]);
11.
}
12.
media = somaValores / qtdValores;
13.
return media;
14. }
15. public Decimal CalcularPorcentagem(Decimal valor,
Decimal porcentagem)
16. {
17.
Decimal porcento = (valor * porcentagem) / 100;
18.
return porcento;
19. }
20. public void CalcularRiscoEmprestimo(ArrayList listaMeses
ContribuicaoINSS, Decimal valorSalario)
21. {
22.
Decimal valorMaximoEmprestimo = CalcularPorcentagem
(valorSalario, 10.0m);
23.
Decimal mediaAnual = CalcularMedia(listaMeses
ContribuicaoINSS);
24.
if (valorMaximoEmprestimo > 100.0m && mediaAnual > 10.0m)
25.
{
26.
Emprestar();
27.
}
28. }
29. }
Listagem 2. Classe Emprestimo.
01. public class Emprestimo

02. {
03. ...
04. public Decimal CalcularMedia(ArrayList listaValores)
05. {
06.
Int32 qtdValores = listaValores.Count;
07.
Decimal somaValores = 0.0m;
08.
Decimal media = 0.0m;
09.
for (Int32 i = 0; i < listaValores.Count; ++i)
10.
{
11.
somaValores += Convert.ToDecimal(listaValores[i]);
12.
}
13.
media = somaValores / qtdValores;
14.
return media;
15. }
16. public Decimal CalcularPorcentagem(Decimal valor,
Decimal porcentagem)
17. {
18.
Decimal porcento = (valor * porcentagem) / 100;
19.
return porcento;
20. }
21. public void CalcularRiscoEmprestimo(ArrayList listaMeses
ContribuicaoINSS, Decimal valorSalario)
22. {
23.
Decimal valorMaximoEmprestimo = CalcularPorcentagem
(valorSalario, 10.0m);
24.
Decimal mediaAnual = CalcularMedia(listaMeses
ContribuicaoINSS);
25.
if (valorMaximoEmprestimo > 100.0m && mediaAnual > 10.0m)
26.
{
27.
Emprestar();
28.
}
29. }
30. ...
31. }
43
Motivao: Em algumas aplicaes, o desenvolvedor

pode se deparar com vrios trechos de cdigo definidos em
diversas classes com a finalidade de prover comunicao
com diferentes verses de um componente, biblioteca, etc.
Alguns desenvolvedores acabam inchando suas classes com
cdigo misturado a outros trechos de cdigo que exercem
outras funes, e isso acaba tornando o projeto de cdigo
existente complicado de se entender e rastrear. Essa tcnica
de refatorao para o padro Adapter permite a criao de
Listagem 3. Interface InterfaceComum.
01. interface InterfaceComum

02. {
03. void CalcularRiscoEmprestimo(ArrayList listaMeses,
Decimal valorSalario);
04. }
Listagem 4. Classe Adapter.
01. public class Adapter

02. {
03. private Emprestimo emprestimo;
04. public Adapter(Emprestimo emp)
05. {
06. this.emprestimo = emp;
07. }
08. public Emprestimo ObterObjetoAdapter()
09. {
10. return this.emprestimo;
11. }
12. }
Listagem 5. Cdigo cliente atualizado.
01. // Cdigo cliente antes

02. Emprestimo emprestimo = new Emprestimo();
03. emprestimo.CalcularRiscoEmprestimo(listaMeses, valorSalario);
04. // Cdigo cliente depois
05. Adapter Aemprestimo = new Adapter(new Emprestimo());
06. Aemprestimo.ObterObjetoAdapter().CalcularRiscoEmprestimo
(listaMeses, valorSalario);
Listagem 6. Mtodo CalcularRiscoEmprestimo, movido para classe Adapter
01. public class Adapter

02. {
03. private Emprestimo emprestimo;
04. public Adapter(Emprestimo emp)
05. {
06. this.emprestimo = emp;
07. }
08. public Emprestimo ObterObjetoAdapter()
09. {
10. return this.emprestimo;
11. }
12. public void CalcularRiscoEmprestimo(ArrayList listaMeses,
Decimal valorSalario)
13. {
14. ObterObjetoAdapter().CalcularRiscoEmprestimo
(listaMeses, valorSalario);
15. }
16. }
44
vrios adaptadores, um para cada verso (como exemplo, um

componente), permitindo assim que cada adaptador criado
gerencie uma verso, melhorando a organizao do projeto
de cdigo existente.
Vantagens: Permite a separao das diferentes verses, cada
uma em uma classe, tornando o cdigo fonte mais legvel;
Faz com que o cdigo mutvel esteja separado do cdigo que
no muda com tanta frequncia.
Desvantagens: Se no for bem utilizada, pode restringir
o acesso de algum cdigo cliente que no tenha acesso a
determinado adaptador.
Mecnica: Esta mecnica sugere duas formas de aplicar a
refatorao para padres Extrair Adapter. Uma delas usando a refatorao Substituir Condicional por Polimorfismo,
quando o cenrio da classe que possui cdigo para vrios
tipos de biblioteca ou API, por exemplo. Nesse caso, a seleo
do cdigo a ser usado deve estar sendo feito por uma lgica
condicional.
Caso o cenrio seja de vrios mtodos e atributos que so
invocados e utilizados para executar um determinado cdigo de verso, utilizam-se os passos descritos na mecnica a
seguir:
1. Busca-se por uma classe que contenha vrios mtodos e
atributos para diferentes verses.
2. Com a refatorao Extrair Subclasse ou Extrair Classe ser
criada uma classe Adapter que ser responsvel por carregar
para si uma das verses existentes na classe selecionada no
passo 1. Depois se move todo cdigo, incluindo atributos para
a classe extrada referente verso que se est separando.
3. O passo 2 dever ser repetido enquanto houver verses que
devero ser separadas da classe selecionada no passo 1.
4. Com as refatoraes Subir Mtodo na Hierarquia e Criar
Mtodo Padro ser possvel remover duplicao de cdigo,
caso necessrio.
Exemplo: Esta refatorao para padres simples. Trata-se
de identificar as verses existentes em uma classe e extrair
classes que carregaro uma das verses identificadas. A Listagem 7 mostra a classe Banco. Ela possui cdigo para dois
diferentes tipos de SGBDs, SQL Server e Firebird. A tarefa
ser dividir esse cdigo em classes especficas.
A Listagem 7, nas linhas 2, 9, 11, 13 a 18 24 a 31 e 40 a 43,
possui cdigo referente conexo com o banco SQL Server. J
nas linhas 3, 4, 10, 12, 19 a 23, 32 a 39 e 43 a 47 possui cdigo
referente conexo com o Firebird.
Aplicando a refatorao Extrair Classe, cria-se uma classe
Adapter chamada BancoFirebird, que receber o cdigo relacionado conexo com o Firebird. A Listagem 8 mostra o
resultado dessa extrao, bem como o cdigo movido.
Agora a classe Banco possui apenas cdigo para uma verso de SGBD. As verses de cdigo que estavam em uma s
classe foram divididas. Dando fim a esta refatorao para
padres, basta atualizar o cdigo cliente que trabalha com
Firebird para referenciar a classe BancoFirebird a partir de
agora.
Desen volvimento
Listagem 7. Classe Banco.
01.

02. using System.Data.SqlClient; // Referencia ao SQL Server
03. using FirebirdSql.Data.Client; // Referencia ao Firebird
04. using FirebirdSql.Data.FirebirdClient; // Referencia ao Firebird
05. namespace ExtrairAdapter
06. {
07. public class Banco
08. {
09.
public String stringconnection = Data Source=02DESKTOP
\\SQLEXPRESS;
Initial Catalog=HotelMaster;Integrated Security=SSPI;
MultipleActiveResultSets=True;
10.
public String stringConexaoFirebird = User=SYSDBA;
Password=masterkey;Database=c:\\BANCO.FDB;
DataSource= 10.0.0.1;Port=3050;Dialect=3;Charset=NONE;
Role=;Connection lifetime=0;Connection timeout=15;
Pooling=True;Packet Size=8192;Server Type=0;
11.
private static SqlConnection objConexao = null;
12.
private static FirebirdSql.Data.FirebirdClient.FbConnection
objConexaoFirebird = null;
13.
private void CriarObjConexao()
14.
{
15.
objConexao = new SqlConnection();
16.
objConexao.ConnectionString = stringconnection;
17.
objConexao.Open();
18.
}
19.
private void CriarObjConexaoFirebird()
20.
{
A refatorao para padres Substituir Linguagem

Implcita por Interpreter
Resumo: Vrios mtodos de uma classe combinados formam elementos de uma linguagem implcita. Crie vrias
classes cujas instncias formem expresses que possam
ser interpretveis.
Motivao: Quando se tem vrios mtodos que formam
uma linguagem implcita, como por exemplo, mtodos que
realizam busca em uma base de dados e que combinados
formam a informao desejada, pode-se duplicar esse cdigo
que contm uma linguagem implcita por vrios pontos da
aplicao, o que pode vir a prejudicar o processo de manuteno. Uma soluo neste sentido fornecida pelo uso
do padro de projeto Interpreter que permite a definio de
classes interpretadoras que contero tal cdigo de busca,
fornecendo um ponto de acesso nico, reduzindo assim a
duplicao de cdigo e fornecendo um mecanismo melhor
do que os mtodos que combinam informaes formando
uma linguagem implcita.
Vantagens: Define um mecanismo melhor do que o que
utiliza linguagem implcita; No necessita de grandes
mudanas envolvendo escrita de novos algoritmos para
definir as tarefas antes realizadas pela linguagem implcita;
Cria uma forma de configurar diferentes comportamentos
dinamicamente.
Desvantagens: Sua implementao pode ocasionar mudanas no cdigo cliente e definio de gramticas; Quando se
tem uma linguagem complexa, o trabalho de implementao
do interpretador pode ser maior.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48. }
49. }
objConexaoFirebird = new FirebirdSql.Data.FirebirdClient.

FbConnection(stringConexaoFirebird);
objConexaoFirebird.Open();
}
public SqlConnection getConexao()
{
if (objConexao == null)
{
CriarObjConexao();
}
return objConexao;
}
public FbConnection getConexaoFirebird()
{
if (objConexaoFirebird == null)
{
CriarObjConexaoFirebird();
}
return objConexaoFirebird;
}
public static void fecharConexao()
{
objConexao.Close();
}
public static void fecharConexaoFirebird()
{
objConexaoFirebird.Close();
}
Listagem 8. Classe BancoFirebird.
01.
02. using FirebirdSql.Data.Client; // Referencia ao Firebird
03. using FirebirdSql.Data.FirebirdClient; // Referencia ao Firebird
04. namespace ExtrairAdapter
05. {
06. public class BancoFirebird
07. {
08. public String stringConexaoFirebird = User=SYSDBA;
Password=masterkey;Database=c:\\BANCO.FDB;
DataSource= 10.0.0.1;Port=3050;Dialect=3;Charset=NONE;
Role=;Connection lifetime=0;Connection timeout=15;
Pooling=True;Packet Size=8192;Server Type=0;
09. private static FirebirdSql.Data.FirebirdClient.FbConnection
objConexaoFirebird = null;
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27. }
28. }
private void CriarObjConexaoFirebird()

{
objConexaoFirebird = new FirebirdSql.Data.FirebirdClient.
FbConnection(stringConexaoFirebird);
objConexaoFirebird.Open();
}
public FbConnection getConexaoFirebird()
{
if (objConexaoFirebird == null)
{
CriarObjConexaoFirebird();
}
return objConexaoFirebird;
}
public static void fecharConexaoFirebird()
{
objConexaoFirebird.Close();
}
45
Mecnica:
1. Na classe que possui uma linguagem implcita, busca-se
por um mtodo que receba como parmetro um nico objeto.
Cria-se uma classe cujo nome revele a inteno do mtodo
escolhido. Nela dever ser declarado um objeto do mesmo
tipo do parmetro do mtodo, dever ter um mtodo de leitura
e um construtor que atribua o valor recebido para o objeto
declarado.
Listagem 9. Classe Curso.
01. public class Curso

02. {
03.
04. public ArrayList BuscaCursos(String nome)
05. {
06. ArrayList listaCursos = BuscaporNome(nome);
07. return listaCursos;
08. }
09. private ArrayList BuscaporNome(String nome)
10. {
11. SqlConnection Conexao = Acesso.getConexao();
12. String queryBuscaCursos = SELECT IDCURSO, NOME,
IDPROFESSOR FROM TBCursos WHERE NOME LIKE % + nome + %;
13.
ArrayList listaCursos = new ArrayList();
14.
SqlCommand Commando11 = new SqlCommand
(queryBuscaCursos, Conexao);
15.
try
16.
{
17.
Commando11.ExecuteNonQuery();
18.
SqlDataReader dados = Commando11.ExecuteReader();
19.
while (dados.Read())
20.
{
21.
Curso curso = new Curso();
22.
curso.IdCurso = Convert.ToInt64(dados[0]);
23.
curso.Nome = Convert.ToString(dados[1]);
24.
curso.Professor = Convert.ToInt64(dados[2]);
25.
listaCursos.Add(curso);
26.
}
27.
dados.Close();
28.
return listaCursos;
29.
}
30.
catch
31.
{
32.
return listaCursos;
33.
}
34. }
35. ...
36. }
Listagem 10. Classe BuscaCursoNome.
01. public class BuscaCursoNome: InterpreterBuscaCursoNome

02. {
03. private String nome;
04. public BuscaCursoNome(String nome)
05. {
06. this.nome = nome;
07. }
08. public BuscaCursoNome ObterNomeCurso()
09. {
10. return this;
11. }
12. }
46
2. Com a refatorao Extrair Mtodo, extrai-se um mtodo que

contenha a parte da lgica do mtodo selecionado no passo 1.
Depois de criada uma superclasse com a refatorao Extrair
Superclasse, declara-se o mtodo extrado na superclasse
abstrata criada.
3. O passo 1 e 2 dever ser repetido enquanto houver mtodos
com lgica para se extrair.
4. Caso se tenha um mtodo que realiza operaes compostas,
como por exemplo, busca baseando-se em SQLs onde so selecionados dados conforme especificao da SQL, cria-se um
mecanismo que dividir o mtodo em questo por diversas
classes, sendo de responsabilidade do composite juntar as informaes e fornecer um ponto de acesso a elas.
5. Nesse momento ser removido todo cdigo duplicado existente nos mtodos extrados. Talvez seja necessria a aplicao
da refatorao Extrair Mtodo.
6. Com a refatorao Internalizar Mtodo, consegue-se remover os mtodos selecionados no passo 1, e que no esto mais
sendo utilizados.
Exemplo: Considere o cdigo da Listagem 9.
O mtodo BuscaCursos, juntamente com o mtodo por ele
invocado chamado BuscaPorNome, contm uma linguagem
implcita, que descreve como deve ser feita a busca por cursos.
O problema com esta abordagem que para se entender a linguagem que representa a forma como os cursos so buscados,
deve-se analisar os mtodos detalhadamente. Neste contexto,
ser aplicada essa refatorao para padres, a fim de eliminar
a linguagem implcita tornando explcita a forma como a busca
por cursos feita. Para isso, ser utilizado um Interpreter.
Primeiramente ser aplicada a refatorao Extrair Classe,
criando uma classe como solicitado no passo 1. A Listagem 10
mostra o resultado.
Aplicando Extrair Mtodo, criam-se mtodos que sero
responsveis por tornar claro como a busca realizada, visto que a linguagem implcita dificulta esta visualizao. A
Listagem 11 mostra a classe Curso com os mtodos extrados
do mtodo BuscaporNome.
O prximo passo consiste em aplicar a refatorao Extrair Superclasse criando uma superclasse para a classe extrada BuscaCursoNome. Posteriormente, os mtodos extrados na classe
Curso devero ser movidos para a classe BuscaCursoNome. Na
superclasse deve ser declarado o mtodo pblico movido para
BuscaCursoNome, chamado BuscaCursoPorNome. Fazem-se os
ajustes para que a superclasse o implemente. As Listagens 12
e 13 mostram a classe BuscarCursoNome com os mtodos
extrados e a superclasse InterpreterBuscaCursoNome.
Na classe Curso, Listagem 9, o mtodo BuscaCursos invocava o mtodo BuscaPorNome. Essa referncia dever ser
atualizada para, a partir de ento, trabalhar com o interpretador. A Listagem 14 mostra como fica o mtodo depois
dessa mudana.
A linguagem implcita foi substituda por uma hierarquia de
classes que agora deixa claro como as buscas so realizadas
detalhadamente.
Desen volvimento

02. {
03. ...
05. {
06.
ArrayList listaCursos = BuscaporNome(nome);
07.
return listaCursos;
08. }
09. private ArrayList BuscaporNome(String nome)
10. {
11.
SqlConnection Conexao = Acesso.getConexao();
12.
String queryBuscaCursos = SELECT IDCURSO, NOME,
IDPROFESSOR FROM TBCursos WHERE NOME LIKE % + nome + %;
13.
14.
15.
try
16.
{
17.
18.
19.
20.
{
21.
22.
23.
24.
25.
26.
}
27.
dados.Close();
28.
return listaCursos;
29.
}
30.
catch
31.
{
32.
return listaCursos;
33.
}
34. }
35. private String ObterSQL()
36. {
37.
String queryBuscaCursos = SELECT IDCURSO, NOME, IDPROFESSOR
FROM TBCursos WHERE NOME LIKE % + nome + %;
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76. }
return queryBuscaCursos;
}
private SqlConnection ObterObjConexao()
{
return Conexao;
}
private SqlCommand ObterObjComando()
{
SqlConnection Conexao = ObterObjConexao();
String queryBuscaCursos = ObterSQL();
return Commando11;
}
public ArrayList BuscarCursoPorNome()
{
SqlCommand Commando11 = ObterObjComando();
try
{
{
}
dados.Close();
return listaCursos;
}
catch
{
return listaCursos;
}
}
Listagem 12. Classe BuscaCursoNome.
01. public class BuscaCursoNome: InterpreterBuscaCursoNome

02. {
03. private String nome;
04. public BuscaCursoNome(String nome)
05. {
06. this.nome = nome;
07. }
08. public BuscaCursoNome ObterNomeCurso()
09. {
10. return this;
11. }
12. private String ObterSQL(String nome)
13. {
14.
String queryBuscaCursos = SELECT IDCURSO, NOME, IDPROFESSOR
FROM TBCursos WHERE NOME LIKE % + nome + %;
15.
return queryBuscaCursos;
16. }
17. private SqlConnection ObterObjConexao()
18. {
19.
20.
return Conexao;
21. }
22. private SqlCommand ObterObjComando(String nome)
23. {
24.
SqlConnection Conexao = ObterObjConexao();
25.
String queryBuscaCursos = ObterSQL(nome);
26.
27.
return Commando11;
28. }
29. public override ArrayList BuscarCursoPorNome(String nome)

30. {
31.
32.
SqlCommand Commando11 = ObterObjComando(nome);
33.
try
34.
{
35.
36.
37.
38.
{
39.
40.
41.
42.
43.
44.
}
45.
dados.Close();
46.
return listaCursos;
47.
}
48.
catch
49.
{
50.
return listaCursos;
51.
}
52. }
53. }
47
Para finalizar, aplica-se a refatorao Internalizar Mtodo,

para remover o mtodo BuscaPorNome (Listagem 9) que
contm a linguagem implcita removida e que no est mais
sendo utilizado.
48

Feedback
eu
Referncias
GAMMA, Erich, 2000. Padres de Projeto: solues reutilizveis de software orientado a objetos,
1ed. Porto Alegre: Bookman, 2000.
KERIEVSKY, Joshua. Refatorao para Padres, 1ed. Porto Alegre: Bookman, 2008.
FOWLER, Martin. Refatorao: aperfeioando o projeto de cdigo existente, 1ed. Porto Alegre:
Bookman, 2004.
sobre e
s

02. {
03.
05. {
06. InterpreterBuscaCursoNome interpretar = new BuscaCursoNome
(nome);
07. ArrayList listaCursos = interpretar.BuscarCursoPorNome(nome);
08. return listaCursos;
09. }
10. ...
11. }
Neste artigo foram colocados em prtica conceitos como

adaptao e reduo de cdigo duplicado atravs dos padres
Adapter e Interpreter. Criar adaptadores tem suas vantagens
e desvantagens, assim como criar interpretadores. Cabe ao
desenvolvedor analisar cada uma das tcnicas de refatorao
para padres aqui abordadas e verificar o contexto de suas
aplicaes para julgar se sua aplicao vlida.
D
s
01. public abstract class InterpreterBuscaCursoNome

02. {
03. public abstract ArrayList BuscarCursoPorNome(String nome);
04. }
Concluso
edio
ta
Listagem 13. Classe InterpreterBuscaCursoNome.
Desen volvimento
49
50

Edição37 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ção37 2011

Diunggah oleh

Hak Cipta:

Format Tersedia

Modstia parte, sua

melhor opo para

EDUCAO SUPERIOR ORIENTADA AO MERCADO

Rodrigo Oliveira Spnola

Marco Antnio Pereira Arajo

Fale com o Editor!

Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ - Linha de Pesquisa

Eduardo Oliveira Spnola

08 - A necessidade de ser gil

Alexandre J. H. O. Luna, Cleyverson Pereira Costa e Hermano Perrelli de Moura

27 - Maturidade em Desenvolvimento de Software

33 - A gerncia de projetos de software em duas perspectivas Parte 1

Edio 05 - Engenharia de Software Magazine

Por trs do bvio

A difcil arte de administrar estrelas

abe aquele colaborador que toda empresa sonha em ter

Engenharia de Software - A difcil arte de administrar estrelas

um deles pode vir a sentir. Em suma, prticas motivacionais

por trs do bvio

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

D seu feedback sobre esta edio!

Edio 37 - Engenharia de Software Magazine

Por fim, deve-se analisar o custo benefcio. claro que no

acompanhadas de tendncias desagregadoras. Por isso, em casos

o mesmo. O que um risco e tanto para a organizao. Uma

A necessidade de ser gil

Doutorando em Cincia da Computao pelo

Cleyverson Pereira Costa

Mestre em Cincia da Computao pelo CInUFPE (2009). Especialista em Engenharia de

Hermano Perrelli de Moura

De que se trata o artigo?

Em que situao o tema til?

Este artigo tem por objetivo apresentar uma anlise

A velocidade de resposta s necessidades do negcio est intimamente ligada competitividade

Para que serve?

uitos autores como Roosmalen e Hoppenbrouwers,

Engenharia de Software Magazine - A necessidade de ser gil

Neste contexto, observa-se que cada

Acrescentar agilidade aos processos de gesto, em sua

A prioridade a satisfao do cliente, mediante o rpido e contnuo fornecimento de

Os processos geis promovem um desenvolvimento sustentvel. Os promotores, usurios e

As melhores arquiteturas, requisitos e desenhos surgem a partir da prpria Equipe atravs

Tabela 1. Princpios geis. FONTE: (BECK et al., 2001)

clientes. Isso se dava, dentre outros fatores, principalmente

Edio 37 - Engenharia de Software Magazine

software mais flexveis e propcias s frequentes mudanas,

metodologias e visitados seus princpios, valores e prticas.

Engenharia de Software Magazine - A necessidade de ser gil

O termo Scrum vem de um estudo feito

que projetos de curta durao, usando equipes pequenas e

eXtreme Project Management - XPM

Figura 2. Ciclo de Vida do Scrum. FONTE: (MOUNTAIN GOAT, 2009)

2. O contexto mais importante do que o contedo. O gerente

Edio 37 - Engenharia de Software Magazine

Agile Project Management - APM

Engenharia de Software Magazine - A necessidade de ser gil

para que seja mais fcil para cada um compreender, transmitir e

desenvolvimento do projeto no escopo e

Edio 37 - Engenharia de Software Magazine

com caractersticas distintas. A famlia Crystal formada por: i)

Figura 4. Processos FDD. FONTE: adaptado de (ABRAHAMSSON et al., 2002)

As duas regras comuns Famlia Crystal, so:

Figura 5. A distribuio dos mtodos da famlia Crystal a partir de duas