Edição34 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
Engenharia de Software Magazine destaca como tema de capa desta

edio o artigo Seus testes so geis? Testes incrementais para uma
metodologia incremental. O artigo apresenta um estudo sobre as princi-
pais diferenas entre a atividade de testes antes e depois das metodologias geis
(principalmente o SCRUM). Estes pontos (diferenas) so citados com o intuito
Ano 3 - 34 Edio - 2011
Impresso no Brasil
de explicar como os testes esto sendo executados em projetos na atualidade. O

intuito de descrever estas diferenas deixar claro que devemos ter em mente
que os testes tambm so parte do desenvolvimento como um todo. Tambm
Corpo Editorial
necessrio pensar nesta integrao quando planejamos a sprint e os testes em si.
Colaboradores
Rodrigo Oliveira Spnola
Marco Antnio Pereira Arajo
Eduardo Oliveira Spnola
as estrias at o ponto em que comeamos a execut-los , sem dvida, essencial
Pensar nos testes como uma atividade incremental desde o momento de estimar
para o bom andamento da sprint e para a mudana de viso dos profissionais
da rea.
Por fim, veremos neste artigo os benefcios encontrados na alocao de analistas
Capa e Diagramao
Romulo Araujo - romulo@devmedia.com.br
de testes dentro dos times geis que podem ser resumidos em: (1) Integrao
do time, (2) Participao mais direta e ativa do profissional que est testando o
Coordenao Geral
Daniella Costa - daniella@devmedia.com.br
software, (3) Profissionais que esto desenvolvendo cdigo tambm esto inte-
Revisor
Gregory Monteiro - gregory@clubedelphi.net
Caroline Velozo - carolinelopes@devmedia.com.br
tambm esto interessados em aprender sobre programao, (5) Interao de
Jornalista Responsvel
Kaline Dolabella - JP24185
Alm desta matria, esta edio traz mais cinco artigos:
Na Web
www.devmedia.com.br/esmag
Desenvolvimento de Software Apoiado por Groupware
ressados em aprender sobre testes, (4) Profissionais que esto testando cdigo
todo o time de desenvolvimento com testes, (6) Analistas de Teste deixaram de
ser reativos para serem pr-ativos.
Voc tem Semancol?
Alternativas para reduo de problemas na manuteno de software
Apoio
Refatorao para Padres Parte 7

Tratamento de excees
Desejamos uma tima leitura!
Equipe Editorial Engenharia de Software Magazine
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:
Isabelle Macedo 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
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.
(21) 2220-5338

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!
maraujo@devmedia.com.br
Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ - Linha de Pesquisa em Engenharia de Software, Especialista em Mtodos Estatsticos
Computacionais e Bacharel em Matemtica com Habilitao em Informtica pela
UFJF, Professor e Coordenador do curso de Bacharelado em Sistemas de Informao
do Centro de Ensino Superior de Juiz de Fora, Professor do curso de Bacharelado em
Sistemas de Informao da Faculdade Metodista Granbery, Professor e Diretor do Curso Superior de Tecnologia em Anlise e Desenvolvimento de Sistemas da Fundao
Educacional D. Andr Arcoverde, Analista de Sistemas da Prefeitura de Juiz de Fora,
Colaborador da Engenharia de Software Magazine.
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
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,
NDICE
Por trs do bvio
06 Voc tem Semancol?
Glnio Cabral
Agilidade
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:
08 - Seus testes so geis?

Gabriela de Oliveira Patuci
Engenharia
14 - Desenvolvimento de Software Apoiado por Groupware
Gabriella Castro Barbosa Costa e Marco Antnio Pereira Arajo
21 - Alternativas para reduo de problemas na manuteno de software

Mateus Maida Paduelli
Tipo: Processo
Ttulo: Especificao de casos de uso na prtica Partes 16 a 20
Autor: Rodrigo Oliveira Spnola
Mini-Resumo: Definir requisitos no uma atividade trivial. Uma das
formas de realizar esta atividade atravs da especificao de casos de
uso. Neste sentido, nesta srie de vdeo aulas apresentaremos um conjunto
de especificaes de casos de uso. Os cenrios sero especificados passo
a passo considerando tpicos como fluxo principal, fluxo alternativo e
regras de negcios.
Desenvolvimento
38 - Refatorao para Padres Parte 7
Jacimar Fernandes Tavares e Marco Antnio Pereira Arajo
46 - Tratamento de Excees
Jacimar Fernandes Tavares e Marco Antnio Pereira Arajo
Edio 05 - Engenharia de Software Magazine
Pos 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.
Voc tem Semancol?

V
amos falar sobre vitaminas. Sabemos que as vitaminas fornecem ao corpo humano uma grande
variedade de nutrientes fundamentais para o seu
bom funcionamento. A vitamina A, por exemplo, contm
substncias antioxidantes que auxiliam no combate ao processo de envelhecimento. J a vitamina D fundamental na
regulao da presso arterial, de modo que quando ingerida
corretamente mantm o sistema nervoso bem calmo.
E assim, cada vitamina tem sua importncia no sentido de
promover o bem estar e o equilbrio do nosso metabolismo. H,
no entanto, uma vitamina diferente, peculiar at. Descoberta
por este colunista que lhe escreve, esta vitamina no promove
necessariamente aes benficas ao nosso organismo. Em vez
disso, ela especialista em viabilizar relacionamentos saudveis e respeitadores entre as pessoas. Caro leitor, com muito
prazer que lhe apresento a Vitamina S. S de Semancol.
A vitamina Semancol responsvel pela produo de uma
enzima chamada senso do ridculo, tambm conhecida
como desconfimetro. A funo desta enzima fazer com
que cada um de ns, vez por outra, tenha a sensao de estar
se comportando ou de estar prestes a se comportar de forma
inconveniente e inadequada. como se essa peculiar vitamina provocasse um alarme, uma espcie de aviso dentro de
ns que nos alerta para o fato de que algo pode no acabar
muito bem se continuarmos agindo da forma que estamos.
Por isso, pessoas carentes desta vitamina costumam ser protagonistas de situaes embaraosas e inconvenientes. Elas
no percebem o vital aviso.
Engenharia de Software - E se voc fosse um DVD numa locadora?
No a toa que vez por outra nos deparamos com indivduos assim, totalmente desprovidos deste complexo vitamnico.
Nos ambientes de trabalho, por exemplo, os efeitos colaterais
de tal abstinncia so facilmente percebidos. Vejamos alguns
exemplos:
1. Pessoas desprovidas de Semancol costumam falar em voz
alta ao celular dentro de um elevador abarrotado de gente. S
que as pessoas no tm nada a ver com seus assuntos particulares e muito menos so obrigadas a ouvi-los na ntegra.
No entanto, o que acontece.
2. Quando pessoas sem Semancol chegam atrasadas a reunies de trabalho, fazem questo de pedir desculpas em
alto e bom som, atrapalhando o andamento da reunio. Se
tivessem Semancol, se sentariam discretamente no lugar mais
prximo da porta e no primeiro intervalo se desculpariam
pessoalmente com o dirigente pelo atraso. Mas no, preferem
o estardalhao.
3. Por se acharem muito engraados, muitos abusam de piadas machistas e racistas durante o expediente, criando um
mal-estar generalizado. E o fazem aos risos escandalosos.
4. Coisas aparentemente pequenas tambm costumam causar grandes constrangimentos. Tive um colega que insistia
em usar uma caneta Bic na orelha esquerda o dia todo. No
tirava ela para nada. O cara parecia um padeiro. Nada contra
os padeiros, mas s vezes, enquanto ele atendia um cliente,
a tal caneta caia no cho e era aquela confuso para ach-la
em meio ao atendimento. Lembro-me de outro colega que
no cortava as unhas. As unhas dele pareciam as do Z do
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
Diferente da maioria das vitaminas, o semancol no pode

ser encontrado nos alimentos. Ele adquirido e desenvolvido na convivncia entre as pessoas. essa prtica, a prtica
da convivncia e da troca de experincias, que nos capacita
a interagir com maturidade e bom senso, respeitando as
individualidades e direitos de todos aqueles que nos rodeiam.

Isso ter Semancol.
No h como ser parte integrante de uma organizao
sem interagir com pessoas dos mais diferentes perfis. Por
isso, toda corporao dotada de regras de comportamento,
pois tais regras ao menos tentam garantir um certo clima
de respeito mtuo e gentileza no ambiente de trabalho, proporcionando assim o surgimento de relaes profissionais
cada vez mais saudveis. E tambm cada vez mais dotadas
de Semancol.
E agora, caro leitor, a pergunta final que no quer calar:
como anda sua taxa vitamnica de Semancol?
edio
ta
Caixo, de to cumpridas e sujas que eram. Era pavoroso ver

aquilo, e pior ainda era apertar sua mo.
5. H aqueles que tm como obsesso entupir os e-mails de
colegas e clientes com mensagens de motivao e as ultrajantes correntes do bem. E pior, o fazem de modo nada personalizado. Fica claro que a mesma mensagem foi enviada a
milhes de outras pessoas ao mesmo tempo.
6. Alguns perdem a noo das coisas quando o assunto
vestimenta no trabalho. Decotes exagerados e mini-saias
no so vestimentas adequadas para um ambiente de trabalho. Nem mesmo num escritrio de uma escola de samba as
pessoas devem se vestir assim, e olhe que o clima l bem
carnavalesco.
Agilidade
Nesta seo voc encontra artigos voltados para as prticas e mtodos geis.
Seus testes so geis?

Testes incrementais para uma metodologia incremental
De que se trata o artigo?

Neste artigo foram apresentadas as principais alteraes sofridas pela atividade de testes ao longo dos
ltimos anos, principalmente influenciadas pelas metodologias geis. A experincia em projetos Scrum foi
considerada e alguns pontos foram levantados como
sugestes de melhoria para o que acontece hoje,
seguindo as premissas do manifesto gil e a ideia de
desenvolvimento incremental de software.
Para que serve?

O artigo tem a inteno de ser uma referncia para as
pessoas que esto deixando de realizar os testes em
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.
m treinamentos, normalmente
comeamos a falar sobre quais
os conceitos que no so mais
utilizados pela disciplina de testes
antes mesmo de falar sobre como ela
funciona em ambientes geis. Isto porque muita coisa mudou e o ideal que
todos possam ter um tempo para notar
as principais caractersticas e diferenas
do que era feito em Waterfall e de como
fazemos hoje, no Scrum. Esse tambm
foi considerado o jeito mais intuitivo de
comear este artigo.
Engenharia de Software Magazine - Seus testes so geis?
Waterfall e esto ingressando no mundo gil. Alm

disso, o texto tambm contm lies aprendidas
durante os ltimos projetos e como os times andam
desenvolvendo os testes de maneira incremental.
Em que situao o tema til?

O tema til para os profissionais de Engenharia
de Software em geral (principalmente Testers
e Scrum Masters) que planejam iniciar projetos
utilizando metodologias geis ou at mesmo para
aqueles que j as utilizam, mas esto enfrentando
problemas com os resultados dos seus testes ou
com as tarefas de testes dentro das equipes.
Antes, trabalhvamos com times de

Testes. Analistas, Testadores, Engenheiros, juntos em times onde todos eram
da rea de Testes. Hoje, temos times
multifuncionais, todos os analistas de
testes ficam alocados dentro destes
times, trabalhando diretamente com
desenvolvedores, webdesigners, analistas de banco, arquitetos, scrum masters
e product owners. Estes profissionais
so considerados os pontos focais da
qualidade dentro dos times, mas no os
nicos responsveis por ela na entrega
M etodologias geis
do produto. A Figura 1 demonstra as duas estruturas, o modelo antigo de Equipes de Testes e o novo modelo, onde estes
profissionais j aparecem alocados dentro de seus novos times
multifuncionais.
Estrutura fsica dos times

Localizao fsica outro ponto extremamente importante, j que propicia uma melhor comunicao entre o time
quando planejada corretamente. No basta os profissionais
da qualidade estarem inseridos nos times, estes tambm
devem estar sentados ao lado dos outros membros da equipe
e terem acesso aos desenvolvedores. Este posicionamento
nada mais do que uma maneira de facilitar o entendimento
dos requisitos, a execuo dos testes em si (e dos retestes
inclusive) e toda a comunicao de fato. Caso contrrio, mudaramos muito pouco do cenrio antigo para o proposto em
metodologias geis. A Figura 2 demonstra o posicionamento
dos membros de uma equipe Scrum: sem divises e o mais
prximo possvel.
Sprint 0
Os testes podem e devem ser iniciados desde o primeiro dia
da sprint, s vezes at antes da reunio de planejamento das
atividades (planning meeting). Como podemos fazer isto? O analista de testes deve ser o responsvel por revisar os requisitos
vindos do cliente para que a maior parte das dvidas seja retirada e as estrias do sprint que vir possam ser revisadas antes
de serem passadas para todo o time. Desta forma, no momento
da planning, o requisito j foi revisado e est claro o suficiente
para ser discutido, estimado e quebrado em estrias.
Ter este Sprint 0, isto , este momento antes da sprint de desenvolvimento, em que podemos conhecer melhor o negcio
, sem dvida, um dos pontos pelos quais pode-se observar
maior nmero de melhorias na qualidade dos projetos. Ter
um requisito mais trabalhado e um time que conhece mais do
negcio no qual est trabalhando algo que s contribui para
o resultado final da construo do software.
Esta ajuda tcnica tambm de grande valia no momento
da criao das estrias porque nem sempre podemos ter um
product owner com um perfil mais tcnico. Em casos em que o
cliente tem um perfil mais leigo, a ajuda de algum que tenha
uma viso crtica de negcios, mas ao mesmo tempo seja do
time, pode ser crucial. A Tabela 1 mostra quais as principais
caractersticas necessrias para uma boa estria.
Planejamento: Testes tambm so discutidos?

Experincias recentes em times Scrum nos fazem crer que
muito se fala de desenvolvimento nas reunies de planejamento, mas muito pouco dito ou at mesmo discutido sobre
a atividade de testes. Precisamos ter em mente que, alm de
como vamos desenvolver, temos que pensar em como vamos
testar e esta parte tambm deve ser estimada, pois demanda
tempo e esforo como qualquer outra atividade. Desvios de
estimativa podem ser corrigidos se passarmos a ver os projetos
com este novo enfoque.
Existem vrios casos que, o jeito com que os testes sero

realizados, com certeza a parte mais importante do negcio.
Elaborao de sistemas que auxiliem a atividade de testes,
por exemplo, algo que deve ser pensado com muita cautela
e levado em considerao nas estimativas do projeto (e isso
demanda tempo no s dos profissionais de testes, mas do
time todo).
Vamos pensar em um exemplo: um sistema que faz o acompanhamento de usurios em um programa que ajuda fumantes a
pararem com o vcio em 100 dias. Todo dia, este usurio deve
entrar no sistema em uma espcie de dirio e registrar o que
lhe aconteceu ao longo deste tempo. Tambm vamos imaginar
que cada um destes 100 dias possua contedos especficos
(como artigos) que este usurio tenha que ler ou at mesmo
e-mails que ele vai receber.
O normal em uma reunio de planejamento seria o time todo
pensar em como desenvolver este programa: como enviar os emails de forma programada, como armazenar as informaes,
etc. Sim, isto faz sentido, mas tambm precisamos pensar em
como faremos para testar 100 dias de programa sem levar os
exatos 100 dias nesta atividade. Se precisamos verificar e validar o comportamento especfico do sistema para todos estes
Figura 1. Times de testes x Times geis
Figura 2. Posicionamento dos membros de uma equipe Scrum

User Stories (Estrias) devem ser INVEST:
Independente: devem ser independentes sempre que possvel.
Negocivel: deve ser negocivel.
Valiosa: devem ser valiosas para o cliente, agregando valor ao negcio.
Estimvel: devem ser passivas de estimativa.
Small (pequena): no devem ser grandes demais nem pequenas demais.
Testvel: devem ser claras o suficiente para serem testadas.
Tabela 1. Caractersticas de uma boa estria
ANTES
DEPOIS
Sprint 1
Sprint 2
Ambiente de Testes Ambiente de Produo

45
Sprint 3
Sprint 4
Ambiente de Testes
Ambiente de Produo
Ambiente de Testes
Ambiente de Produo
Ambiente de Testes
Ambiente de Produo
39
10
Tabela 2. Comparao entre o nmero de defeitos antes e depois das alteraes em Testes
Nmero de defeitos X Qualidade do Software
Figura 3. Exemplo de Scrum Board
dias ou, no mnimo, para uma porcentagem alta deles, como

faremos? Surge aqui a necessidade de estimar a construo de
um pequeno sistema de testes que consiga alterar a data que
o usurio se encontra dentro do programa.
Por fim, quando falamos em planejamento, tambm devemos
levar em conta os artefatos do sprint, como o board (quadro), por
exemplo. Na Figura 3 podemos perceber que o modelo de Scrum
Board foi alterado para melhor se adequar realidade dos testes.
Isto fica a critrio do time, como quase tudo no Scrum. Utilizar
ou no este modelo deve ser decidido no incio da sprint.
Incio dos testes: Qual o momento certo?

Saber o momento de iniciar os testes pode ser citado como o
prximo ponto diferencial entre as metodologias. O costume
das equipes de Testes sempre foi esperar por um pedido vindo
de desenvolvimento para o incio dos testes. O mximo que se
podia fazer antes deste momento era planejar os testes funcionais com base nos requisitos e/ou gerar scripts automatizados.
Bem, a partir do momento em que estamos desenvolvendo
software baseado em uma metodologia dita incremental, nada
mais justo que as atividades de testes tambm sejam realizadas
de maneira incremental.
Logo aps a reunio de planejamento, quando o time iniciar
o desenvolvimento do software, iniciamos o que chamamos
de teste incremental. importante que o profissional de testes
se aproxime dos desenvolvedores, trabalhe em pares, verificando o andamento das atividades ainda que no ambiente de
desenvolvimento. Quando antecipamos esta etapa de testes,
encontramos os provveis defeitos muito antes de chegar ao
ambiente de testes e desta forma, os defeitos tm um custo
muito inferior. Outro fator muito interessante que o time fica
cada vez mais maduro, tanto no conhecimento do requisito
desenvolvido nas conversas entre o prprio time, quanto na
qualidade de seu trabalho.
10
Uma das principais preocupaes de alguns profissionais

com a questo do teste incremental o fato de levantar os
defeitos e futuros problemas de maneira informal (atravs de
comunicao entre os membros do time). fato que este hbito
diminui o nmero de defeitos (formais) durante a sprint. O que
devemos ter em mente que o nmero de defeitos registrados
em ferramentas no diretamente proporcional qualidade
do software construdo.
O que podemos observar em projetos atualmente que
mesmo com um nmero de defeitos registrados bem menor,
a qualidade dos sistemas s vem aumentando, j que todos os
pontos so levantados ou durante os testes ainda no ambiente
de desenvolvimento ou, em ltimo caso, durante os testes
funcionais no ambiente de testes.
Outro fator relevante nesta discusso que um defeito tem
um custo muito mais baixo se for encontrado o mais cedo possvel durante o desenvolvimento (sprint). Encontrar um defeito
logo aps a sua criao diminui o seu custo drasticamente e
faz com que os desenvolvedores possam corrigir o problema
logo que ele encontrado.
A Tabela 2 demonstra o comportamento dos defeitos reportados antes e depois da implantao dos Testes Incrementais
em um projeto real.
Documentao
A ideia de que metodologias geis no tm nenhuma documentao ainda persiste no conceito de vrias pessoas. Na
verdade, o que se prega que devemos dar mais importncia
comunicao entre as pessoas do time do que documentao, mas, nada se fala a respeito de no ter documentao.
necessrio ter o conceito de que a documentao sim muito
importante mesmo em projetos geis. A seguir, so descritos
exemplos claros que justificam a importncia desta documentao bsica de testes.
O fato de o time ser multifuncional o primeiro motivo da
necessidade de planejamento e documentao mnima de
testes. Todos os profissionais alocados dentro do time podem
precisar ajudar na execuo dos testes e, desta forma, vo
precisar do step by step de cada caso de teste. Claro que o
fato de estarmos executando os Testes Incrementais colabora
para que os profissionais de testes no fiquem sem trabalho no
comeo da sprint e muito atarefados no final dela, mas mesmo
assim, sempre existiro os casos em que a ajuda dos outros
membros do time se far necessria. Sempre que a demanda
de testes estiver muito alta, os documentos com a especificao
dos casos de testes e todo o planejamento sero cruciais.
M etodologias geis
O segundo fator que devemos levar em conta so os testes de

aceitao. No podemos exigir que o cliente saiba exatamente
quais os tipos de teste ele deve executar e como estes testes
devem ser feitos. Ter documentos com os passos da execuo
dos testes de aceitao a maneira mais segura de se garantir
a boa execuo de tais testes.
Por fim, podemos considerar a criao de um planejamento
de testes o momento perfeito para identificar todas as possveis
dvidas que restaram sobre as estrias e os requisitos. Neste
momento, o Analista de Testes pode trabalhar juntamente com
o time e, principalmente, com o PO (product owner), para que
tudo fique claro e os requisitos sejam revisados novamente se
necessrio.
se faz ainda mais importante, para diminuir a disputa (mesmo

que informal) que se cria pelo trabalho do profissional.
Outra boa prtica que vem sendo desenvolvida em times
compartilhados a existncia de um ponto focal para auxiliar
em testes em ambos os times. Sempre existe a possibilidade de
o nmero de tarefas de testes serem inviveis para um nico
profissional, o que nos faz pensar em ter um auxlio que venha
de dentro do prprio time. Importante neste caso manter o
pensamento de que este auxlio deve partir de um integrante
do time que tenha bons skills de testes e a viso crtica do
produto. Nem sempre todos os membros de um time tm o
perfil de um testador.
Alocao dos Analistas de Testes
Uma mudana de cenrios aconteceu tambm no ramo da

automao de testes. Antes, muito se pesquisava sobre a
automao da criao de casos de testes. Hoje, com o advento
das metodologias geis, a ateno das equipes est muito mais
voltada para a automao da execuo de testes em si. Tudo isso
porque a metodologia d muito valor execuo e no tanto
para a documentao (como j foi dito anteriormente).
Ferramentas que ajudam nos testes de regresso, testes funcionais e criao de massa de dados so as mais procuradas.
Principalmente nos casos de construo de websites, onde
ferramentas (ou plugins) como Selenium IDE podem facilitar a execuo do mesmo caso de teste N vezes com valores
diferentes selecionados a partir de uma planilha Excel, por
exemplo. Testes de estresse do sistema tambm so muito
procurados e uma das ferramentas mais utilizadas o JMeter.
Simular situaes onde um nmero muito grande de usurios
tenta acessar o sistema pode ser muito til antes de mover um
site para produo (nestes casos, ter um nmero esperado de
usurios pode ajudar bastante no planejamento de tais testes).
A Tabela 3 mostra quais as principais ferramentas que esto
sendo utilizadas no mercado para automao (da execuo)
de testes.
Um dos fatores que pode interferir na qualidade do trabalho

dos analistas de testes, se no for bem considerado, a alocao
compartilhada entre times. Muitos times tm o costume de
compartilhar recursos como analistas de testes, arquitetos de
software e at mesmo scrum masters. claro que isso pode
funcionar muito bem, mas deve-se planejar com cautela e
alguns pontos devem ser considerados.
Times pequenos com uma mdia de trs pessoas normalmente possuem lderes que trabalham com mais de um projeto.
Este costume est cada vez mais comum. Alm disso, nos
ltimos tempos, compartilhar testadores e arquitetos virou
uma soluo para a falta de profissionais da rea. O que se
precisa considerar como se deve atuar para no perder o
foco do trabalho nestes times e saber dividir o tempo dirio
entre eles.
Solues prticas como ter o mesmo horrio para cada time
todos os dias podem trazer benefcios para os resultados deste
trabalho. Esta uma forma do profissional saber dividir seu
trabalho de maneira bem intuitiva e sem confundir o tempo
til que tem para cada time. Quando o mesmo profissional de
testes vai trabalhar com times de diferentes scrum masters, isto
Automao de Testes
Selenium: O Selenium IDE um ambiente integrado de desenvolvimento para scripts. Ele implementado como uma extenso do Firefox e permite gravar, editar e
depurar os testes. Esta ferramenta tambm permite que os usurios gravem e reproduzam os testes no ambiente real no qual sero executados. Pode ser usado para
testes de fumaa, regresso e funcionais em geral.
JMeter: Utilizado para testes de desempenho em aplicaes de diferentes tipos de servidores (HTTP/HTTPS, SOAP, JMS etc.). uma aplicao open source Java e foi
desenvolvida para executar load tests e testes de performance. Originalmente foi desenvolvido para aplicaes Web, mas agora est sendo utilizado tambm para outras
aplicaes.
Watir: Utilizado para testes automatizados para Web escritos na linguagem Ruby. Existem derivaes em .Net (WatN) e Java (WatJ). Basicamente para quem quer criar
testes fceis de entender e de manter. Os criadores da ferramenta prometem funcionamento perfeito com qualquer tecnologia.
FitNesse: Servidor web, Wiki e Ferramenta de Testes Automatizados para suportar testes de aceitao. O usurio pode criar critrios de aceitao de maneira colaborativa,
criar e executar testes automatizados e manter dados de teste.
Tabela 3. Ferramentas de Automao (execuo) de Testes
11
Ferramenta
Jira
Bugzilla
Gratuita?
Descrio
Ferramenta para gesto de projetos e acompanhamento de tarefas e erros. relativamente fcil de usar, oferece grande flexibilidade,
NO (Apenas para projetos de forma que voc pode fazer o acompanhamento de todas as tarefas, desde sua criao at finalizao, assinalando o assunto e seu
open source)
responsvel. Existe a possibilidade de se fazer comentrios e capturas. O responsvel e o criador do ticket podem ser informados por
e-mail sobre todas as mudanas efetuadas.
Aplicao para gesto de erros. Esta aplicao permite que indivduos ou grupos de programadores acompanhem os relatrios de erros
SIM
ou pedidos de melhorias. uma ferramenta baseada em Web e e-mail, que d suporte ao desenvolvimento do projeto Mozilla, rastreando
defeitos e servindo tambm como plataforma para pedidos de recursos.
Testlink
SIM
Ferramenta para registro de requisitos, armazenamento de casos de testes e resultados de teste.
QA Track
SIM
Ferramenta para automao do planejamento de testes e que apresenta interface grfica mais amigvel (user friendly).
Mercury TestDirector
NO
um aplicativo para Gesto de Testes Gerenciamento de Requisitos, Plano de Teste e Controle de Defeitos.
Rational TestManager
NO
um console central para as atividades de gerenciamento e relatrios de testes. Criado para ser extensvel, ele suporta tudo, desde
abordagens de teste manual at automatizados, incluindo testes unitrios, testes de regresso funcional e testes de desempenho.
Tabela 4. Ferramentas mais utilizadas pelas equipes em testes geis.
times utilizam esta viso para se trabalhar com pair programming entre desenvolvedor e testador na criao dos scripts
automatizados.
Em muitos casos, a tcnica pode ser inicialmente considerada
mais demorada ou at mesmo mais cara, mas com o passar
do tempo, pode-se constatar a criao de softwares com os
seguintes benefcios:
Menos uso de um debugger;
Menor quantidade de defeitos;
Software feito de maneira mais rpida e com melhor
qualidade.
Figura 4. Ciclo de TDD e execuo das tarefas de desenvolvimento.
TDD (Test Driven Development)

Tcnica amplamente utilizada nos ltimos tempos, o TDD,
em portugus Desenvolvimento Dirigido por Testes, vem
crescendo na rea de desenvolvimento de software. Os resultados atingidos nos projetos que utilizam TDD fazem com que
este crescimento seja fortalecido, principalmente levando em
considerao que os passos necessrios para a utilizao da
tcnica so relativamente simples.
Durante a implantao do TDD, foram observados melhores
resultados quando desenvolvedores e testadores construam
juntos os casos de testes automatizados, definidos para validar
melhorias no produto ou at mesmo para novas funcionalidades. A partir deste ponto, o cdigo era produzido com base
nestes testes, o que garantia que este tinha os requisitos mnimos de qualidade e atendia necessidade do cliente. Aps a
criao do cdigo em si, os testes feitos anteriormente podiam
ser executados e possveis defeitos eram corrigidos. J com os
defeitos corrigidos (com base nos casos de testes construdos
anteriormente), os scripts automatizados eram executados
novamente para garantir que o cdigo estivesse correto. Este
ciclo se repetia at a finalizao da tarefa.
O papel do analista de testes nesta tcnica muito importante, visto que ele pode ajudar muito na criao dos casos de
teste, aproveitando seu conhecimento e viso crtica. Muitos
12
Por fim, devemos manter o foco tambm nas limitaes que

esta tcnica pode trazer sprint. Um exemplo de tais limitaes
o fato da qualidade do cdigo ser muito baseada na qualidade
dos testes em si. Logo, se os testes no forem criados de forma
criteriosa, o cdigo tambm no ser bom o suficiente. Outro
fator relevante a ser considerado o tipo de sistema que est
sendo desenvolvido. Sistemas com muita interface grfica ou
at mesmo com banco de dados relacional, podem ter seu desenvolvimento dificultado, se criados com esta tcnica.
A Figura 4 mostra como deve ser feita a execuo das tarefas
dentro do ciclo do TDD e qual o papel de um testador neste
ciclo, elaborando o plano de testes com todos os testes que sero
automatizados e integrando a ferramenta de teste de cdigo.
Ferramentas mais utilizadas

Algumas ferramentas vm sendo amplamente utilizadas
pelas equipes e profissionais de testes nos projetos geis.
Ferramentas de apoio a testes vo alm de automao (e de
execuo), elas podem ajudar na abertura de defeitos e no
acompanhamento dos requisitos e mudanas no projeto.
Feita uma pesquisa inicial, foram listadas as principais
ferramentas utilizadas pelas equipes e profissionais de testes
na atualidade. A Tabela 4 mostra quais as suas principais
caractersticas e o seu uso mais frequente.
Em resumo, pode-se dizer que as ferramentas pagas so
muito completas e interessantes, mas nem sempre as empresas
M etodologias geis
Ao final, vale ressaltar que no se pode pensar que sabemos o

melhor jeito de executar testes em times geis, isto seria iluso.
O importante conhecer o que j foi tentado e preservar o que
foi aprendido durante estas tentativas, pois com certeza, no
existe algo que possa ser considerado a bala de prata.
[2] CRISPIN, L; GREGORY, J. (2009). Agile Testing: A Practical Guide for Testers and Agile Teams.
Addison-Wesley Professional. ISBN 0321534468.
[3] COHN, M. (2004). User Stories Applied for Agile Software Development. Addison-Wesley
Professional. ASIN B000SEFH1A.
[4] BECK, KENT (2002). Test Driven Development: By Example. Addison-Wesley Professional.
ISBN 0321146530.
[5] Test Driven.com - Wrangling quality out of chaos.
http://www.testdriven.com/
Links
Endereo da pgina do Selenium
http://seleniumhq.org
Site do JMeter
http://jakarta.apache.org/jmeter/
Endereo da ferramenta Watir
http://watir.com
Site da ferramenta FitNesse
http://fitnesse.org/
Site do projeto Jira
http://www.ecore.com.br/atlassianbrasil/?gclid=CKrFuLL0-KYCFY4J2god-XSuCA
Site do Bugzilla
http://www.bugzilla.org/
Endereo da ferramenta Testlink
http://testlink.sourceforge.net/docs/testLink.php
Endereo da ferramenta QA Track
http://www.testmanagement.com/
Site do Mercury TestDirector
http://www.starbase.co.uk/products/hp-products/hp-testdirector.html
Site da Rational TestManager
http://www-01.ibm.com/software/awdtools/test/manager/

Feedback
eu
13
sobre e
s
Este artigo apresentou um estudo sobre as principais diferenas entre a atividade de testes antes e depois das metodologias
geis (principalmente o SCRUM).
Estes pontos (diferenas) foram citados com o intuito de explicar como os testes esto sendo executados em projetos na
atualidade. O intuito de descrever estas diferenas deixar
claro que devemos ter em mente que os testes tambm so
parte do desenvolvimento como um todo. Tambm necessrio pensar nesta integrao quando planejamos a sprint e os
testes em si. Pensar nos testes como uma atividade incremental
desde o momento de estimar as estrias at o ponto em que
comeamos a execut-los , sem dvida, essencial para o bom
andamento da sprint e para a mudana de viso dos profissionais da rea.
Os benefcios encontrados na alocao de analistas de testes
dentro dos times geis podem ser resumidos em:
Integrao do time;
Participao mais direta e ativa do profissional que est
testando o software;
Profissionais que esto desenvolvendo cdigo tambm esto
interessados em aprender sobre testes;
Profissionais que esto testando cdigo tambm esto interessados em aprender sobre programao;
Agilidade: interao de todo o time de desenvolvimento
com testes;
Analistas de Teste deixaram de ser reativos para serem
pr-ativos.
[1] BECK, K.; FOWLER, M. et al (2001).Manifesto for Agile Software Development.

http://www.agilemanifesto.org/.
D
s
Concluso
Referncias
edio
ta
tm a possibilidade de obter as licenas para todos os recursos.

As opes open source vm sendo cada vez mais utilizadas e
logo, melhoradas e difundidas.
Como so ferramentas de conhecimento pblico, tornou-se
muito fcil conseguir ajuda e referncias de ferramentas open
source, j que todos os profissionais da rea tm acesso a elas
(tanto quanto estudantes e pesquisadores).
Por fim, outro fator que deve ser considerado quando da
escolha das ferramentas sua integrao. Um exemplo claro
a utilizao das ferramentas TestLink e Bugzilla. O TestLink
tem uma boa integrao com interfaces de bug tracking em geral
e seus resultados podem ser utilizados de maneira a facilitar
o controle/manuteno das informaes do projeto. Estudar
como fazer este tipo de integrao pode ser um bom comeo
para a automao de dados de testes.
Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros
Desenvolvimento de Software Apoiado por

Groupware
Uma Introduo
Este artigo aborda o uso de groupware nos processos
de desenvolvimento de software que so realizados
de forma colaborativa, apresentando suas principais
caractersticas, vantagens, ferramentas e plataformas para apoiar o desenvolvimento de software
neste contexto.
Gabriella Castro Barbosa Costa

gabriellacbc@gmail.com
Bacharel em Sistemas de Informao pelo

CES-JF (2010) e Tcnica em Informtica Industrial pelo CEFET-MG (2007). Atua como
desenvolvedora Web desde 2008.

Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ, Especialista em Mtodos Estatsticos Computacionais e Bacharel em Informtica pela
UFJF, professor dos Cursos de Bacharelado
em Sistemas de Informao do Centro de
Ensino Superior de Juiz de Fora, da Faculdade Metodista Granbery e da Universidade
Severino Sombra, professor do curso de
Bacharelado em Cincia da Computao
da FAGOC, professor 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, Editor da Engenharia de Software Magazine.
14
Para que serve?

Como o trabalho colaborativo no desenvolvimento
de software de grande importncia, pois diferentes habilidades so necessrias, o uso de groupware
e modo geral, atravs da juno

de conhecimentos, experincias,
habilidades e esforos de um
grupo, conseguem-se alcanar melhores
resultados para um mesmo trabalho do
que se este fosse executado individualmente. O trabalho colaborativo, alm de
estimular os participantes envolvidos no
processo, propicia a resoluo de problemas e desafios de forma mais rpida e
eficiente, partindo do princpio de que
as falhas/inconsistncias de uma ideia
ou proposta podem ser encontradas por
outros integrantes do grupo durante a
realizao do trabalho.
Engenharia de Software Magazine - Desenvolvimento de Software Apoiado por Groupware
visa facilitar a execuo e controle das tarefas que,

em sua maioria, so realizadas de forma distribuda
e colaborativa.

Groupware pode ser utilizado para apoiar grupos
de pessoas a realizarem qualquer tarefa ou meta
em comum, mesmo trabalhando em localidades
e horrios distintos. O uso deste tipo de sistema
para apoio ao desenvolvimento de software traz
grandes vantagens j que este , em sua maior
parte, de carter colaborativo.
Embora traga muitas vantagens, o

trabalho coletivo exige um grande esforo na coordenao dos integrantes de
um grupo, de forma a evitar eventuais
conflitos e fazer com que os objetivos e
metas traadas sejam alcanadas de forma satisfatria pelo grupo. Outras desvantagens do trabalho em grupo que
este considerado mais lento e oneroso
e, s vezes, o grupo pode desperdiar
o tempo de trabalho em bate-papos ou
discusses desnecessrias.
A partir da interao e colaborao
entre indivduos, surge um novo tipo
de conhecimento tambm conhecido
Engen haria de Soft ware
por inteligncia coletiva, como o caso do que ocorre no

desenvolvimento de software livre, das enciclopdias online
colaborativas e das redes sociais. Os avanos da Web 2.0 e das
ferramentas de comunicao online alavancaram consideravelmente o uso de sistemas colaborativos como chats, agenda,
catlogo de endereos, webmail amigvel, gerenciador de arquivos, gerenciador de tarefas e enquetes, por exemplo.
Software colaborativo ou groupware pode ser definido como
um sistema baseado em computador usado para apoiar grupos
de pessoas a realizarem uma tarefa ou meta em comum, alm
de fornecer uma interface para um ambiente compartilhado.
Esse tipo de software visa facilitar o trabalho de equipes que
tm necessidade de um trabalho conjunto, mesmo trabalhando em localidades e horrios distintos. O estudo sobre
sistemas colaborativos engloba vrias reas como Engenharia
de Software, Banco de Dados, ComputaoGrfica, Sistemas
Distribudos e Inteligncia Artificial, alm de relacionar-se
com reas como a Sociologia, Lingustica e Psicologia. A rea
que envolve o estudo de sistemas baseados em computador
que auxiliam o trabalho cooperativo conhecida por CSCW
(Computer Supported Cooperative Work - Trabalho Colaborativo
Apoiado por Computadores). Portanto, groupware pode ser considerado uma ferramenta desenvolvida a partir dos conceitos
abordados em CSCW.
Neste contexto, este artigo traz uma introduo sobre o
trabalho colaborativo, destacando suas vantagens e desvantagens. Na seo seguinte so apresentadas as principais
caractersticas dos sistemas colaborativos, em seguida so
apontadas as diferenas entre o desenvolvimento colaborativo
de software e o desenvolvimento de software colaborativo. Por
fim, o trabalho colaborativo no contexto de desenvolvimento de
software abordado e so apresentados os principais exemplos
de groupware, como ferramentas de comunicao, ferramentas
para controle de verses, ferramentas para controle de erros,
ferramentas para gerncia de projetos e trs plataformas que
podem ser usadas durante o processo de desenvolvimento
de sistemas.
O Trabalho Colaborativo
Atravs do trabalho em grupo podem-se produzir melhores
resultados do que se os membros do grupo trabalhassem individualmente, j que h a possibilidade da complementao de
conhecimentos e do surgimento de pontos de vistas diferentes.
Com isso, a identificao de falhas na maneira escolhida para
a resoluo de problemas torna-se muito mais rpida e eficaz.
Outra grande vantagem do trabalho colaborativo a motivao
que este pode trazer aos membros participantes do grupo, j
que cada pessoa estar sendo observada e criticada pelos que
se encontram envolvidos no trabalho em comum.
Embora proporcione muitas vantagens, o trabalho em grupo
traz como principal desvantagem o fato de necessitar de uma
boa coordenao de seus membros para que os resultados sejam satisfatrios. Para que o trabalho colaborativo possa ocorrer de forma que as metas traadas inicialmente sejam, de fato,
alcanadas, alguns fatores como comunicao, coordenao,
cooperao e percepo so de suma importncia e devem

atuar de forma interligada.
- Comunicao
No trabalho em grupo, durante o processo de comunicao, os
participantes deste tm como principal objetivo compartilhar e
discutir suas ideias de forma a chegarem a um consenso. Nesta
etapa, o conhecimento individual e a maneira de express-lo
de cada integrante so de grande valia para que haja um bom
entendimento entre a pessoa que quer transmitir sua ideia e
os demais membros do grupo.
O meio utilizado para a comunicao entre o grupo tambm
pode exercer influncia na informao a ser transmitida. Quanto mais pessoal for o contato entre as pessoas, melhor ser o
aproveitamento da ideia transmitida. Por exemplo, reunies
presenciais podem ser mais eficazes do que conversas por
telefone, que por sua vez podem ser mais esclarecedoras do
que chats ou mensagens instantneas via web. Porm, muitas
vezes, no trabalho colaborativo no possvel a realizao
de reunies presenciais, para isto torna-se necessrio um
bom conhecimento de todos os membros do grupo sobre a
correta forma de utilizao das ferramentas de comunicao
e da linguagem e expresses a serem usadas no decorrer das
conversas.
No processo de colaborao, o mais importante no apenas
saber se o receptor recebeu a informao de forma adequada,
mas sim se teve um bom entendimento da mesma. Isso pode
ser percebido atravs das reaes do receptor em suas atitudes ou em sua fala.
Existem vrias possibilidades de comunicao entre os participantes de um grupo colaborativo, portanto, fica a cargo do
coordenador deste grupo analisar e definir a melhor e mais
apropriada ferramenta de comunicao para cada etapa ou
meta a ser cumprida.
As ferramentas de comunicao podem ser classificadas em
sncronas ou assncronas. As ferramentas sncronas possuem
como caracterstica a necessidade de interao em tempo
real, ou seja, membros do grupo devem estar presentes ou
conectados no momento em que ocorre a comunicao. Este
tipo de ferramenta deve ser usado quando se espera a interao entre os participantes do grupo, visto que o tempo de
resposta entre a ao de um participante e a reao de seus
companheiros curto. J as ferramentas de comunicao assncronas possuem como vantagem a interao entre pessoas
sem que estas estejam conectadas ao mesmo tempo, ou seja, a
mensagem desejada enviada, e permanece disponvel para
conhecimento dos destinatrios no momento em que estes se
conectam. Devem ser utilizadas quando h a necessidade de
uma melhor reflexo dos participantes, j que estes tero um
maior tempo disponvel antes de agir.
Como exemplos de ferramentas de comunicao podem
ser includas e-mail, lista de discusso, frum, ferramentas
de votao, mensagem instantnea, chat, vdeo conferncia e
telefone, sendo que algumas sero detalhadas e exemplificadas
no decorrer deste artigo.
15
- Coordenao
De forma a garantir que os objetivos traados pelo grupo sejam
alcanados, necessrio que haja uma boa coordenao das atividades a serem realizadas. Evitar que esforos de comunicao
e cooperao sejam perdidos e que as tarefas sejam realizadas
na ordem correta, de forma correta e no tempo correto, deve ser
uma atribuio do coordenador do grupo. Alm disso, devem
ser identificados e mapeados em tarefas os objetivos do grupo,
selecionados os participantes, distribudas as tarefas entre eles
e toda a realizao destas deve ser coordenada. Outra responsabilidade da coordenao a ser citada o tratamento de conflitos
que geralmente ocorrem devido a problemas de comunicao,
percepo ou interpretao, para que estes no acarretem em
competio, desorientao e problemas de hierarquia, que podem vir a prejudicar o grupo. Deve-se ressaltar a importncia
dos membros do grupo e os coordenadores devem sempre ter
cincia do trabalho que est sendo realizado pelos participantes,
assim possvel identificar e evitar esforos duplicados em prol
de um mesmo objetivo a ser alcanado e tambm se evita que
algum membro fique sem trabalho ou com tempo ocioso.
Atividades colaborativas sem a presena de um coordenador
apresentam um grande risco de que os participantes do grupo
desviem-se do foco principal ou se envolvam em tarefas repetitivas e ou conflitantes.
Como exemplos de ferramentas para suporte a atividades
de coordenao podem ser citadas: gerenciamento de fluxo
de trabalho (workflow) e ferramentas de desenvolvimento de
software colaborativo.
- Cooperao
a ao conjunta dos membros do grupo, como produo,
manipulao e organizao de informaes.
interessante que a maior parte do que for produzido pelo
grupo seja armazenada, de forma a garantir uma memria
do trabalho cooperativo que foi realizado. Essa memria
poder, posteriormente, fornecer auxlio, caso seja necessrio
checar os motivos ou ideias iniciais que levaram tomada de
alguma deciso para produo de um artefato ou mesmo no
caso da necessidade de alter-lo por mudana nos objetivos
iniciais.
Podem ser utilizadas ferramentas para auxiliar o trabalho
de cooperao que fornecem, por exemplo, registro e recuperao de verses e controle e permisses de acesso. Entre as
ferramentas para controle de verso enquadram-se o CVS e o
SVN, que sero descritas no decorrer deste artigo.
- Percepo
A percepo o ato de adquirir informao. essencial para
a comunicao, coordenao e cooperao em um grupo de
trabalho colaborativo.
Na interao entre pessoas face-a-face, a obteno de informaes maior, j que os sentidos esto presentes em sua
plenitude. J em ambientes virtuais, o suporte percepo
bem menor porque os meios de transmitir as informaes aos
rgos sensoriais dos seres humanos so restritos.
16
Uma interao que possibilita uma percepo de qualidade

capaz de fazer com que os participantes tenham disponveis
informaes necessrias para prosseguir seu trabalho, sem a
necessidade de interromper outros membros do grupo para
solicit-las.
Groupware
O termo groupware, ou software colaborativo, refere-se a
uma famlia de aplicaes baseadas em computador que do
suporte a grupos de pessoas engajadas em uma tarefa comum
e que provm uma interface para compartilhar o ambiente,
especialmente ao nvel de comunicao, colaborao e suporte
deciso. O uso de groupware permite que pessoas, mesmo
estando em diferentes localidades possam compartilhar
ideias e interesses comuns para a resoluo dos problemas e
objetivos do grupo.
Groupware pode ser considerado uma ferramenta desenvolvida a partir dos conceitos abordados em CSCW, que a rea
que envolve o estudo de sistemas baseados em computador
para auxlio ao trabalho cooperativo.
A utilizao de ferramentas groupware nas organizaes tem
como principal objetivo a melhoria na eficcia administrativa,
dando assistncia na comunicao, colaborao e coordenao
das atividades dos grupos.
Como exemplos de aplicaes de groupware podem ser
citados:
Sistemas de e-mail: Permitem a troca de mensagens e arquivos pelo grupo;
Workflows: Permitem o acompanhamento do fluxo de trabalho
e de informaes da empresa;
Sistemas de gerenciamento de documentos: Permitem o
acesso de forma rpida aos documentos digitais da empresa;
Reunies eletrnicas: Permitem a realizao de encontros
dos membros do grupo colaborativo para a resoluo de
problemas;
Sistemas de co-autoria e projeto: Permitem o desenvolvimento simultneo de documentos e projetos mesmo que os
participantes do grupo estejam em locais distintos;
Vdeo conferncias: Permitem a realizao de encontros
atravs da transmisso simultnea de udio e vdeo;
Tele presena, avatares e realidade virtual: Permitem a criao de ambientes virtuais para que as pessoas possam interagir
a partir de locais remotos.
As aplicaes de groupware, levando em considerao as variveis espao e tempo podem ser classificadas em quatro
categorias, conforme exibido na Tabela 1.
As categorias podem ser descritas como:
Interao face a face: Diz respeito s aplicaes que so
executadas de maneira sncrona, sendo que os membros do
grupo de trabalho encontram-se em um mesmo local em um
mesmo tempo. Como exemplo de aplicao, pode ser citado um
sistema de autoria de projeto em grupo, que permite tanto a
engenheiros como desenvolvedores manipularem um mesmo
arquivo simultaneamente;
Desenvolvimento colaborativo de software e

desenvolvimento de software colaborativo
O conceito de desenvolvimento colaborativo de software difere do de desenvolvimento de software colaborativo levandose em considerao que, nem sempre, o primeiro tem como
objetivo final a produo de software para ser usado para
apoiar trabalhos colaborativos. Um projeto cujo processo de
desenvolvimento ocorreu de forma colaborativa poder ter
como finalidade a utilizao de uma nica pessoa sem que
haja colaborao no uso deste sistema. J o desenvolvimento
de software colaborativo tem como meta a criao de sistemas
para apoio ao trabalho realizado de forma colaborativa. Uma
empresa pode fazer uso do desenvolvimento colaborativo
de software sem nunca ter desenvolvido nenhum software
colaborativo, por exemplo.
Trabalho Colaborativo e Desenvolvimento de Software

O trabalho colaborativo no desenvolvimento de software
de grande importncia, pois diferentes habilidades so
necessrias no decorrer do processo de desenvolvimento de
software. Deve-se levar em considerao que a equipe de desenvolvimento e os clientes/usurios do sistema necessitaro
de uma grande interao durante o decorrer do processo de
desenvolvimento haja vista que os analistas precisam compreender os requisitos propostos pelos clientes. Alm disso, os
arquitetos tm como papel verificar a melhor forma com que o
sistema dever ser feito, programadores tm o papel de passar
para uma linguagem de programao o que foi especificado,
sendo tudo isso coordenado e gerenciado pelos gerentes de
projetos, alm dos testes e adequaes do sistema de acordo
com o usurio final.
Alm da interao entre pessoas para o desenvolvimento de
sistemas de forma colaborativa importante ressaltar que estes
sistemas provavelmente devero oferecer interao com outros
sistemas, elevando ainda mais o grau de colaborao que dever existir no decorrer do processo de desenvolvimento.
No desenvolvimento colaborativo de software, como as
tarefas sero realizadas de forma distribuda e colaborativa,
torna-se necessrio que o escopo das mesmas seja claro e as
MESMO
DIFERENTE
MESMO
Interao face a face
Interao Assncrona
DIFERENTE
TEMPO
Interao Distribuda Sncrona
Interao Distribuda Assncrona
ESPAO
Interao Distribuda Sncrona: As aplicaes que se enquadram nesta categoria necessitam da utilizao de recursos
de telecomunicaes de forma a possibilitar a comunicao
simultnea entre locais de trabalho diferentes. Enquadram-se
nesta categoria os chats e vdeo conferncias;
Interao Assncrona: Nas aplicaes desta categoria, embora os integrantes do grupo de trabalho estejam situados
em um mesmo local, a interao ocorre em tempos distintos.
Como exemplos podem-se citar o compartilhamento de computadores e arquivos;
Interao Distribuda Assncrona: Diz respeito s aplicaes
que so utilizadas em tempos e espaos distintos por parte dos
membros do grupo de colaborao. Estas aplicaes tm como
objetivo a distribuio e encaminhamento das informaes. O
e-mail o principal exemplo desta categoria.
Tabela 1. Classificao das aplicaes de groupware de acordo com

espao x tempo.
responsabilidades, atividades e papis de cada participante

do processo de desenvolvimento bem definidas, de forma a
garantir o alcance dos objetivos inicialmente traados. Uma boa
gerncia da equipe responsvel pelo desenvolvimento colaborativo de software essencial para aumentar a produtividade
e evitar o desperdcio de recursos humanos.
No trabalho colaborativo de desenvolvimento necessrio
um conjunto de reunies para a coordenao das atividades
a serem realizadas pelo grupo e, com isso, as ferramentas de
apoio ao trabalho colaborativo funcionam como aliadas no
sentido de facilitar a comunicao entre os integrantes da
equipe.
Princpios bsicos da programao extrema ou XP (eXtreme
Programming), como simplicidade e comunicao, e prticas
colaborativas como a programao em pares tambm facilitam
o processo de desenvolvimento de software.
Embora possua muitas vantagens, fatores como comunicao
ineficiente, disperso geogrfica, diferenas culturais, perda
do esprito de equipe e falta de coordenao podem resultar no
fracasso de um projeto se no forem tratados de forma correta
durante o desenvolvimento colaborativo de software.
Tecnologias Colaborativas
Tecnologias colaborativas oferecem um grande auxlio no
processo de desenvolvimento de sistemas. Como principais
funes destas, pode-se citar o fornecimento de um canal de
comunicao entre os participantes de um grupo, mecanismos de armazenamento e acompanhamento de verses dos
artefatos produzidos, ferramentas para controle de defeitos,
ferramentas para auxlio na gerncia de projetos e plataformas
para desenvolvimento colaborativo, exemplificadas a seguir.
- Ferramentas de Comunicao
Para as ferramentas de comunicao, o uso da Internet
torna-se indispensvel e tal fato deve ser considerado ao
adot-las. Entre estas, pode-se citar as listas de discusso,
17
portais e comunidades virtuais, fruns, mensagens instantneas, chats, blogs e wikis. A seguir so apresentados
alguns exemplos.
Para utilizao de Listas de Discusso, o Mailman - Sistema
para administrao de listas de discusso ou newsletters de
fcil configurao e administrao via Web (Figura 1). Entre
suas principais funcionalidades podem ser citados: filtros de
contedo, arquivamento das mensagens enviadas para a lista,
Figura 1. Pgina inicial do Mailman
moderao de membros e filtros anti-spam. utilizado para

gerenciar listas de projetos como SAMBA e KDE.
Para apoio a criao de comunidades virtuais um exemplo
o JoomlaClube, Comunidade dedicada a tpicos relacionados
ao CMS (Content Management System - Sistema Gerenciador de
Contedo) Joomla, cuja pgina est exibida na Figura 2.
A criao de Fruns pode ser apoiada pelo phpBB - Sistema
gerenciador de fruns em PHP - disponibilizado sob a licena
GPL. compatvel com vrios gerenciadores de bancos de
dados como o MySQL, PostgreSQL, SQL Server, Microsoft
Access e Oracle.
Jabber um conjunto de protocolos XML que possibilita a
troca de mensagens instantneas entre dois pontos distintos
na Internet. Para us-lo basta efetuar um registro no endereo
http://register.jabber.org , baixar o software cliente e efetuar
o login.
Para utilizao de um blog, pode-se utilizar o WordPress, uma
plataforma para publicao de contedo com foco na esttica,
nos Padres Web e na usabilidade, livre e gratuito. A Figura 3
exibe a pgina inicial de administrao de um site que faz uso
desta plataforma.
J o MediaWiki um software livre para criao de wikis,
desenvolvido utilizando a linguagem PHP. Foi originalmente
criado para ser usado na Wikipdia. A Figura 4 exibe a pgina
inicial da MediaWiki, onde pode ser realizado o download
do programa.
- Ferramentas para controle de verses
Figura 2. Pgina da Comunidade JoomlaClube
Figura 3. Pgina de administrao de site que usa WordPress
Figura 4. Pgina inicial da MediaWiki
18
As ferramentas de controle de verso so de grande importncia no desenvolvimento colaborativo de software, pois

permitem modificaes paralelas de forma padronizada e
controlada, garantindo a integridade e tambm a rastreabilidade das modificaes.
Como exemplo de ferramentas a serem usadas para este fim
pode-se citar o CVS e o Subversion, dentre outros, descritos
a seguir.
CVS (Concurrent Versions System): Software livre e de
cdigo aberto, desenvolvido para suportar grupos de trabalho
voltados para o desenvolvimento cooperativo de projetos,
permitindo que mltiplos participantes possam efetuar, de
forma independente e concorrente, alteraes em suas cpias
locais do objeto.
Possui arquitetura cliente-servidor, onde o servidor responsvel por armazenar as verses atuais de um projeto,
bem como seu histrico de alteraes. Quanto ao cliente, este
precisa conectar-se ao servidor para conseguir uma cpia do
projeto original para, aps isto, efetuar suas alteraes. Com
isso, torna-se necessrio que ambos (cliente e servidor) estejam
conectados por uma rede local ou mesmo pela Internet.
Aps a confirmao das alteraes de um projeto por parte
dos clientes, caso mais de um cliente tenha alterado um mesmo
arquivo, por exemplo, o servidor ir tentar efetuar uma fuso
de todas as alteraes. Caso isto no seja possvel, o servidor
executar a primeira alterao e informar ao responsvel pela
ltima alterao que houve um conflito, sendo necessria a
interveno humana. J quando a validao das alteraes

bem sucedida, a verso de cada arquivo envolvido no projeto
incrementada e o servidor armazena as alteraes (data, autor
e observao se houver) em seu log.
Como h um controle rigoroso de verses e alteraes por
parte do CVS, caso seja necessrio, possvel que os desenvolvedores tenham acesso s verses anteriores do projeto
desenvolvido sem quaisquer problemas.
Subversion: Tambm conhecido por SVN, um sistema de
controle de verso livre e de cdigo aberto, criado para ser
um substituto do CVS. Gerencia arquivos e diretrios e as
alteraes feitas neles ao longo do tempo, permitindo que
sejam recuperadas verses antigas dos dados, ou examinar o
histrico de como os dados foram alterados.
O SVN pode funcionar em rede, o que lhe permite ser usado
por pessoas em diferentes computadores e localidades. Com
isso, o desenvolvimento de software pode acontecer de forma
mais rpida, j que um mesmo arquivo pode ser alterado por
mltiplas pessoas e, como o trabalho est versionado, caso
haja alguma alterao incorreta realizada junto aos dados,
possvel, simplesmente, desfaz-la.
Alguns sistemas de controle de verso servem apenas para a
gesto de configurao de software (SCM - Software Configuration Management). Estes sistemas so utilizados para gerncia
do cdigo fonte e tm muitas caractersticas que so especficas
para desenvolvimento de software, tais como compreenso de
linguagens de programao ou fornecimento de ferramentas
para a construo de software. O Subversion no um desses
sistemas, haja vista que o mesmo pode ser utilizado para gerenciar qualquer coleo de arquivos.
- Ferramentas para controle de defeitos

Algumas ferramentas tm como funo documentar e controlar defeitos encontrados e suas respectivas correes. Elas
so de grande importncia para a qualidade e a produtividade
no desenvolvimento colaborativo de sistemas, pois permitem
o gerenciamento dos defeitos com capacidade de localizao,
confirmao e deteco de defeitos duplicados ou que no se
aplicam verso atual do arquivo que est sendo analisado.
Dentre as ferramentas para controle de defeitos no desenvolvimento de sistemas colaborativos podem ser citadas, como
exemplo, o Bugzilla e o Scarab.
Bugzilla: Trata-se de um sistema livre para rastreamento de
defeitos que permite programadores, individualmente ou em
grupo, acompanharem os bugs de um projeto de forma eficaz.
Alm disso, o Bugzilla uma ferramenta que pode ajudar a
equipe de desenvolvedores a se organizar e se comunicar de
maneira mais simples. considerada uma das ferramentas
de controle de erros mais usada em projetos de software livre.
Possui, alm do registro de informaes de erros, funcionalidades de priorizao de atendimento, assinalando os erros
aos participantes apropriados, configurao de dependncias
entre os erros e ainda possibilita a reviso de cdigo.
Scarab: Ferramenta para rastreamento de erros em Java,

a qual de fcil instalao, porm sua interface Web no
muito elaborada.
- Ferramentas para gerncia de projetos

O uso de ferramentas para gerncia de projetos possibilita
que as informaes sobre os projetos desenvolvidos estejam
disponveis para toda a equipe envolvida, o que aumenta a
qualidade do gerenciamento e facilita o alcance dos objetivos
traados. Ferramentas que se enquadram nesta categoria
possuem tambm como caracterstica a disponibilizao das
informaes sobre controle e acompanhamento do projeto de
forma rpida e eficiente. Como exemplos podem ser citados o
Microsoft Project e o dotProject.
Microsoft Project: Software comercial desenvolvido pela
Microsoft para auxiliar na gesto de projetos. Esta ferramenta
disponibiliza, alm de diversos relatrios, grfico de Gantt,
diagramas de custos, datas e durao do projeto, dentre outros.
Outra grande vantagem o fato desta ferramenta possuir uma
interface bastante amigvel e similar aos outros produtos que
so ofertados pela mesma empresa. uma das ferramentas
mais utilizadas pelo mercado nesta categoria.
O Microsoft Project pode ser usado para diferentes tipos de
projetos e no somente para os projetos de desenvolvimento de
software, como projetos de engenharia civil, por exemplo.
dotProject: um software livre para gerncia de projetos.
Diferentemente do Microsoft Project, uma aplicao web
cujo acesso realizado atravs de um browser, desenvolvido
utilizando a linguagem PHP, e faz uso do banco de dados
MySQL. Essa ferramenta possibilita o cadastro e visualizao
de todas as tarefas necessrias para a execuo de um projeto
e qual parte desta j foi realizada. Tambm possui diagrama
de Gantt, definio de responsveis por cada tarefa, lembretes
sobre os prazos e repositrio de arquivos. Pode ser utilizado
para gerenciar projetos dos mais diversos tipos, e no apenas
os de desenvolvimento de software.
No Brasil h uma comunidade onde so discutidos assuntos
de interesse sobre o dotProject que possui um site (http://
www.dotproject.com.br/) e uma lista de discusso de suporte
tcnico (http://listas.softwarelivre.org/cgi-bin/mailman/
listinfo/dotproject-br).
- Plataformas para desenvolvimento colaborativo

Para o desenvolvimento colaborativo de software, alm das
ferramentas anteriormente apresentadas, existem tambm as
plataformas para desenvolvimento de software colaborativo
que, em sua maioria, englobam todas as funcionalidades das
ferramentas de comunicao, gerncia, controle de verses
e de erros. Dentre as existentes, sero citadas: SourceForge,
Launchpad e GoogleCode, de uso gratuito.
SourceForge: Plataforma para desenvolvimento e distribuio de software de cdigo aberto que pertence e operado pela
19
Geeknet Inc., com sede nos EUA. Alm de ser um software de

controle de desenvolvimento colaborativo, oferece uma interface para acompanhamento do ciclo de vida no desenvolvimento
de software e pode ser integrado a outras aplicaes de cdigo
aberto como PostgreSQL e CVS.
Links
Mailman
http://www.gnu.org/software/mailman/index.html
JoomlaClube
http://www.joomlaclube.com.br/site/comunidade.html
Launchpad: Plataforma para desenvolvimento colaborativo

de software que prov as seguintes funcionalidades: bug tracking, hospedagem e reviso de cdigo, tradues, listas de
email e FAQs.
phpBB
http://www.phpbb.com/
Google Code: Projeto desenvolvido pelo Google que oferece

servio de hospedagem para desenvolvimento de software com
sistema para controle de verso, sistema de issuetracking, wiki
para documentao e 100MB para download. Alm disso, o site
contm cdigo-fonte aberto e uma lista com vrias APIs pblicas
do Google como Google Maps, Google Toolbar, Google AdSensee
e Google AdWords, sendo as duas ltimas basedas no protocolo
SOAP, permitindo que desenvolvedores integrem seus softwares
aos servios do Google.
WordPress
http://wordpress.com/
Jabber
http://www.jabber.org/
MediaWiki
http://www.mediawiki.org/wiki/MediaWiki
Bugzilla
http://www.bugzilla.org/
Scarab
http://scarab.tigris.org/
Microsoft Project
http://www.microsoft.com/project
Concluso
20
SourceForge
http://sourceforge.net
Launchpad
https://launchpad.net/
Google Code
http://code.google.com/intl/pt-BR/
Referncias
Ellis, C.A., Gibbs, S.J., and Rein, G.L. Groupware - Some Issues and Experiences. Communications
of the ACM, v 34, n 1, 1991.
Grudin, J. Computer-Supported Cooperative Work: History and Focus. IEEE Computer, v 27 n 5,
1994.
Microsoft Project
http://www.microsoft.com/project
dotProject
http://dotproject.net/
SourceForge
http://sourceforge.net
sobre e
s

dotProject
http://dotproject.net/
Feedback
eu
edio
ta
D
s
cada vez maior o nmero de empresas que esto distribuindo seus processos de desenvolvimento de software em cidades,
estados ou pases diferentes, de forma a obter profissionais
cada vez mais experientes e qualificados. Portanto, o uso das
ferramentas de apoio ao desenvolvimento colaborativo de
grande utilidade.
Problemas de comunicao e coordenao so considerados
como os principais no desenvolvimento de software, onde
as ferramentas para apoio ao trabalho em grupo (groupware)
podem ser utilizadas como forma de minimizar os impactos causados por estes problemas. Alm disso, o trabalho
em grupo, quando bem planejado e gerenciado pode ser de
grande valia quando equiparado ao trabalho de uma nica
pessoa. O processo de desenvolvimento de software , em
sua maior parte, de carter cooperativo. Atravs da utilizao
de softwares colaborativos, a produtividade de uma equipe,
desde que bem gerenciada, tende a ser melhor, ficando a cargo
dos coordenadores do grupo a escolha das ferramentas mais
adequadas de acordo com o objetivo traado.
Launchpad
https://launchpad.net/
Google Code
http://code.google.com/intl/pt-BR/
Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros
Alternativas para reduo de problemas na

manuteno de software
Apresentaremos neste artigo algumas alternativas de respostas para os problemas de manuteno apresentados no artigo sobre manuteno de
software apresentado na edio anterior. Estas
alternativas esto embasadas em trs fontes
distintas: na norma ISO/IEC 12207, nas solues
encontradas na organizao analisada no estudo
de caso, e nas propostas de outros autores que se
dedicaram ao assunto.
Para que serve?
N
Mateus Maida Paduelli
bacharel e mestre em computao pela
Universidade de So Paulo. J atuou em diversas organizaes com o tema manuteno de software e atualmente servidor
pblico federal.
a edio 33 da Engenharia de
Software Magazine, conhecemos as caractersticas, tipos e
desafios para a manuteno de software.
Alm disso, destacamos tambm as dificuldades encontradas na realizao das
atividades de manuteno de software.
Para isso, um estudo de observao
que foi conduzido com o objetivo de
verificar os problemas de manuteno
de software existentes em uma organizao empenhada no desenvolvimento
de software comercial.
Este texto indicado para aqueles profissionais

que atuam com manuteno de software no seu
dia-a-dia e que desejam entender melhor os atuais desafios em torno desse tema.

A manuteno de software hoje um assunto presente em organizaes que desenvolvem e mantm software. Isso se deve necessidade de sempre ajustar e melhorar o produto de software de
acordo com as mais diversas necessidades. Diante
desse fato, entender o significado e abrangncia
do termo manuteno de software pode auxiliar
organizaes e profissionais interessados no tema
a melhor conduzir seus esforos quando precisam
manter seus produtos.
21
Dando continuidade discusso sobre o assunto, apresentaremos neste artigo algumas alternativas de respostas para
os problemas de manuteno apresentados na edio anterior.
Estas alternativas esto embasadas em trs fontes distintas: na
norma ISO/IEC 12207, nas solues encontradas na organizao
analisada no estudo de caso, e nas propostas de outros autores
que se dedicaram ao assunto.
Acredita-se que a norma seja um excelente veculo para conduzir uma organizao de software pelas melhores prticas, j
que seu contedo resultado de um esforo fundamentado no
que poderia se chamar estado-da-arte da engenharia de software. Outra considerao importante diz respeito maneira
como a norma se apresenta. Ela no um modelo fechado que
diz como fazer e manter software da melhor forma, mas sim,
mostra o que deve ser considerado para que isso seja alcanado.
Dessa forma, a norma funciona como um guia para ser seguido
por organizaes interessadas em tratar sistematicamente seu
processo de software.
O estudo de caso apresentado no artigo da edio passada
ser estendido neste artigo, expondo agora prticas adotadas
pela organizao que trouxeram resultados satisfatrios para
a preveno ou conteno de problemas de manuteno de
software em seu ambiente de trabalho.
Extenso do Estudo de Caso

Neste tpico apresentada a extenso do estudo de caso
apresentado no artigo publicado na Engenharia de Software
Magazine edio 33.
Essa extenso foi possvel graas constatao de que a
organizao estava em busca freqente por melhorias em
seu ambiente de trabalho, e em sua capacidade de resposta
satisfatria aos clientes, que vinham crescendo em nmero,
sem, no entanto, valer-se da adoo de um processo extenso e
sistemtico como o sugerido pela norma ISO/IEC 12207.
O objetivo foi verificar quais mudanas a organizao vinha
adotando no seu dia-a-dia que estivessem contribuindo positivamente para a diminuio de seus problemas de manuteno
de software, ou ainda, o que os profissionais empenhados
nessa atividade achavam que deveria ser feito para que essa
reduo ocorresse.
Metodologia
A metodologia aplicada na extenso do estudo de caso tambm
foi baseada em questionrios e entrevistas. O intuito principal
desses questionrios foi o de servirem para a abertura de uma
discusso na qual exemplos de solues eficientes fossem citados pelos entrevistados. Como o objetivo era que a organizao
mostrasse quais atitudes vinha adotando para tratar de maneira
satisfatria sua atividade de manuteno, no havia como
estipular questes prvias, por isso o questionrio reduzido
funcionou somente como recurso para incio de entrevista.
De fato, as solues citadas, bem como observaes e todas
as informaes relevantes para o contexto da entrevista, foram
registradas pelo entrevistador em documento a parte e posteriormente compiladas.
22
Solues Identificadas
Os resultados obtidos foram organizados e utilizados
para elaborar os itens a seguir, que apresentam solues
apontadas pelos entrevistados como favorveis para a
atividade de manuteno de software, contribuindo para
reduzir um ou mais dos problemas conhecidos.
Melhoria em treinamento: uma prtica relevante
adotada pela organizao diz respeito a treinamento. A
soluo considerada foi a de verificar entre os profissionais
interessados, quais eram as ferramentas de software que
gostariam de um aprofundamento em conhecimentos, por
meio de certificaes. A partir desse levantamento, a organizao se comprometeu em comprar os livros necessrios
preparao para alguns exames de certificao oficial.
Como exemplo, tem-se uma das modalidades de certificao de DBA SQL Server da Microsoft. O gerenciador de
banco de dados SQL Server corresponde ao utilizado pela
organizao, e sua configurao correta, seja em termos
de desempenho ou de funcionalidades, de fundamental
importncia. Assim, a organizao comprou os livros necessrios preparao, e que normalmente tm um custo
relativamente alto, se comprometendo ainda a reembolsar
o valor pago para realizao do exame, caso o profissional
fosse aprovado. No momento das entrevistas, algumas
pessoas j haviam conseguido aprovao no mdulo
inicial da certificao. Esse conhecimento adicional em
banco de dados de relevncia para manuteno, j que
o software da empresa tem muitas partes implementadas
na forma de stored procedures, e muitas das manutenes
so efetuadas nesses componentes;
Gerenciamento do conhecimento: ligado diretamente
ao problema da rotatividade elevada, a organizao vinha
se empenhando em sistematizar os problemas de manuteno, principalmente os problemas de atendimento ao
cliente via suporte e help-desk, montando uma base de
conhecimentos onde fosse possvel consultar as solues
possveis para um problema freqente. Para isso, uma
ferramenta web de colaborao on-line foi instituda, e nela
registrado, na forma de perguntas e respostas, as maneiras de abordar inmeros problemas. A atitude gerencial
inicial para a composio das primeiras questes dessa
base foi a obteno, junto equipe de suporte, de uma lista
de problemas mais comuns. O passo seguinte foi reunir
consultores da empresa que trabalham na cidade de So
Paulo, para em reunies conjuntas entre equipe de suporte
e consultores, elaborar as primeiras respostas lista de
problemas de suporte. Tais questes foram posteriormente
inseridas na ferramenta web, de forma que qualquer pessoa dentro da organizao pudesse ter acesso e editar seu
contedo, como forma de complementao;
Melhoria na documentao oferecida ao cliente: da
mesma forma que foi criado um repositrio de problemas
e solues para a prpria organizao, tambm se criou
algo semelhante em relao aos clientes. Com o uso da
mesma ferramenta web, uma interface de consulta foi
Engenharia de Software Magazine - Alternativas para reduo de problemas na manuteno de software
M anuten o
disponibilizada aos clientes, permitindo a obteno de

respostas a problemas comuns que o suporte vinha reiteradas vezes atendendo, com uma linguagem padronizada
e uniforme. Questes de carter tcnico, que envolvesse
informaes de cdigo-fonte ou configurao de banco de
dados, no ficavam disponveis aos clientes (essa classificao de o que o cliente podia consultar e o que no podia,
era feita principalmente pela equipe de suporte, mas de
uma forma geral todos podiam interferir);
Padronizao no fluxo de informaes: buscando
corrigir problemas de comunicao com os usurios,
muitas vezes por motivos de o usurio informar partes
de seu problema para pessoas diferentes do suporte, o
que tornava a compreenso do todo dificultada e muitas
vezes gerava insatisfao desse cliente, foi uniformizada
a maneira como esse tipo de informao fluiria na organizao. O fluxo estabelecido foi o seguinte: todo problema
de software deveria ser primeiramente cadastrado no
sistema de help-desk, para ento algum contato via telefone
ou e-mail poder ser estabelecido. O sistema de help-desk
possua recurso de interao entre usurio e suporte,
registrando-se ali (e no por e-mail, como antes) todas as
interaes e detalhes do problema em questo. Com isso
evitou-se a perda de informaes passadas pelo cliente,
o que impactava na manuteno, pois chamados de alterao eram estabelecidos sem o devido detalhamento, o
que causava m especificao de requisitos de alterao,
gerando conflitos do prprio suporte com a equipe de
manuteno;
Melhoria em cronogramas: um dos grandes problemas
em manuteno a questo de prazos e o cumprimento de
cronogramas estabelecidos junto aos clientes. A organizao, visando minimizar esse tipo de problema, adotou a
postura de assumir de fato o cronograma junto ao cliente,
garantindo isso da seguinte forma: aps serem agendadas
as datas de entrega de manutenes, cada profissional
responsvel pela implementao deveria informar, diariamente, ao coordenador o andamento de suas atividades. Ao menor sinal de contratempos que fossem levar a
um no-cumprimento da data de entrega estipulada, o
coordenador indicava algum ou ele prprio assumia a
responsabilidade de auxiliar na manuteno para que o
prazo fosse cumprido. Essa postura forou a contratao
de novos programadores;
Diviso de tarefas: o sistema de registro de chamados de
manutenes passou a abrigar mais um campo de informao: o nvel de complexidade da manuteno, estipulado
pelo coordenador. Isso permitiu um melhor controle do
problema da sobrecarga de tarefas, o que seguramente foi
auxiliado pela contratao de novos programadores;
Melhoria em testes: essa foi uma das mudanas significativas para a reduo do nmero de problemas de
software que acabavam no ambiente de produo dos
clientes. A medida adotada foi a de insistir no uso de teste
beta (testes pelo cliente, em seu ambiente), porm a maneira
de negociao foi alterada. A organizao se comprometeu a

preparar todo ambiente paralelo ao de produo, necessrio
para efetuar os testes, sempre que uma verso de testes fosse
disponibilizada, ficando a cargo do cliente apenas proceder
com os testes, sem necessidade de qualquer configurao
de software. O cliente deveria oferecer apenas os recursos
de hardware (computador, espao em disco rgido para
replicao do banco de dados de produo etc.). Alm disso, a liberao da verso inicial de testes passou a ocorrer
somente aps revises mais rgidas realizadas internamente
na organizao por uma pessoa dedicada exclusivamente
a essa tarefa.
Por fim, verificou-se que a questo da documentao interna das manutenes era uma das preocupaes da organizao, porm ainda sem soluo satisfatria implementada,
portanto no citada aqui.
Embora no se tenha adotado um processo de manuteno
complexo e rgido, a lista de modificaes internas citada
contribuiu para a diminuio daqueles problemas mais
simples e que causavam grande impacto negativo junto
aos clientes.
No entanto, uma nova dificuldade parece ter surgido, e
tambm j estava sendo combatido pela gerncia atravs
de maiores exigncias, que era justamente o fato de os
procedimentos novos adotados nem sempre estarem sendo
seguidos, como por exemplo, a necessidade de sempre registrar na base de conhecimento as solues adotadas para
problemas que ainda no constavam dessa base.
Consideraes Gerais
As solues encontradas pela organizao pesquisada no
representam o resultado do emprego de alguma norma ou
processo bem definido, como dito anteriormente.
Foi justamente esse fato que permitiu utilizar essas solues
como alternativas para abordar os problemas de manuteno
de software. Isso porque importante que seja mostrado
tanto o aspecto rigorosamente formal proposto pela norma
ISO/IEC 12207, como tambm alternativas de solues.
valioso destacar que alternativas como as aqui apresentadas
podem at mesmo serem mais viveis do que a adoo da
prpria norma, dependendo do porte da organizao e de
sua estruturao.
O fundamental que as organizaes de software se empenhem em compreender as caractersticas e dificuldades de si
prprias, buscando continuamente por falhas e possveis formas de trat-las, o que muitas vezes pode ocorrer pela simples
mudana de atitudes e controle mais rgido de tarefas. O uso
de ferramentas de software tambm um ponto importante,
e nesse exemplo houve o uso de ferramentas para auxlio no
tratamento de informaes.
Solues com base na Norma ISO/IEC 12207

O relacionamento entre os problemas de manuteno de
software mostrados na edio passada pode ser estendido para
23
Problema
Categoria Processos Fundamentais
Grupo de Processos de Aquisio
Preparao da Aquisio
Seleo do Fornecedor
Acordo Contratual
Monitoramento do Fornecedor
Aceitao pelo Cliente
Grupo de Processos de Fornecimento
Proposta do Fornecedor
Liberao de Produto
Apoio para Aceitao de Produto
Grupo de Processos de Engenharia
Elicitao de Requisitos
29. Falta de compreenso dos usurios a respeito de suas reais necessidades de software
Anlise de Requisitos de Sistema

Projeto de Arquitetura de Sistema
Anlise de Requisitos de Software
33. Necessidades de integrao com softwares incompatveis

34. Plataformas heterogneas dificultam a definio de ferramentas adequadas
Projeto de Software
Construo de Software
Integrao de Software
Teste de Software
26. Mtodos inadequados de testes
Integrao de Sistema
Teste de Sistema
Instalao de Software
Manuteno de Software e Sistema
11. Ausncia de adoo de padres, metodologias e procedimentos de manuteno
Grupo de Processos de Operao

Operao
Suporte ao Cliente
25. Falhas de comunicao com o usurio
Categoria Processos Organizacionais

Grupo de Processos de Gerncia
Alinhamento Organizacional
Gerncia Organizacional
Gerncia de Projeto
07. Mantenedores desconhecem planos da organizao com relao equipe de manuteno

04. Viso organizacional diferenciada para a equipe de desenvolvimento e para a equipe de manuteno
05. Dificuldades de comunicao entre a equipe de manuteno e a prpria organizao
20. Falta de uma equipe de manuteno
24. Manuteno de software vista como uma tarefa no prestigiosa
01. Falta de comprometimento com cronogramas
06. Software desenvolvido visto pela gerncia como no construdo para a manuteno
08. Contratao de temporrios para auxlio na manuteno leva ao menor controle sobre a atividade
12. Falta de suporte da gerncia
13. Sobrecarga de tarefas
15. Estimativa de prazo no condizente com a complexidade do software
Gerncia de Qualidade
14. Ausncia de manuteno preventiva
Gerncia de Riscos
21. Elevada rotatividade dos profissionais

30. Mudanas freqentes de prioridades (clientes)
31. Baixa qualidade da documentao dos sistemas (software original)
32. M qualidade do cdigo-fonte original
Medio
Tabela 1. Processos da norma ISO/IEC 12207 e problemas de manuteno de software
24
M anuten o
Grupo de Processos de Melhoria de Processo

Estabelecimento de Processo
Avaliao de Processo
Melhoria de Processo
Grupo de Processos de Recursos e Infra-estrutura
Gerncia de Recursos Humanos
Treinamento
10. Dificuldade na medio do desempenho da equipe de manuteno

23. Preferncia dos profissionais por trabalhos de desenvolvimento
02. Treinamento inadequado da equipe de manuteno
22. Mantenedores lamentam por no possurem contato com estado-da-arte da tecnologia
Gerncia de Conhecimento
09. Experincias com manutenes anteriores no so disseminadas dentro da prpria organizao e entre novos membros da equipe
Infra-estrutura 1
17. Ferramentas para manuteno precisam ser diferentes daquelas de desenvolvimento

18. Falta de recursos tecnolgicos adequados
19. Estagnao tecnolgica no ambiente de trabalho
Grupo de Processos de Reuso

Gerncia de Ativos
Gerncia de Programa de Reuso
Engenharia de Domnio
Categoria Processos de Apoio
Grupo de Processos de Gerncia de Configurao
Documentao
27. Documentao insuficiente ou superficial (software alterado)
Gerncia de Configurao
03. Ausncia de um profissional responsvel exclusivamente ao controle de configurao de software

16. Necessidade de suporte automatizado gerncia de configurao de software
Gerncia de Resoluo de Problemas

Gerncia de Solicitaes de Mudana
28. Necessidade constante dos usurios por melhorias e novas funcionalidades
Grupo de Processos de Garantia de Qualidade

Garantia de Qualidade
Verificao
Validao
Reviso Conjunta
Auditoria
Avaliao de Produto
Continuao: Tabela 1. Processos da norma ISO/IEC 12207 e problemas de manuteno de software
especificar tambm a qual processo do grupo o problema

de manuteno de software se relaciona (lembre-se que essa
relao devida ao no cumprimento de tarefas do processo
correspondente).
Para criar esse relacionamento, a Tabela 1 foi construda.
Nela so apresentados todos os grupos e processos da
norma, mostrando em quais desses processos os problemas de manuteno de software se encaixam, de forma
individual.
Percebe-se que no so todos os processos da norma que
quando no observados contribuem para os problemas de
manuteno de software. Porm, aqueles que esto diretamente ligados ao surgimento dos problemas, precisam de
um entendimento mais detalhado, explorando-se tambm
as tarefas previstas para cada um.
No tpico seguinte, cada processo que apresentou associao com problemas de manuteno descrito em um
quadro, que apresenta os resultados esperados de uma
implementao com sucesso do processo e suas respectivas

tarefas, de acordo com o que expe a norma. As tarefas
podem ser consideradas como as solues possveis para os
problemas atrelados a cada processo. Imediatamente aps
cada quadro, so apresentadas observaes ou comentrios a respeito do processo no contexto de manuteno de
software.

Um total de 14,7% dos problemas de manuteno de software foi classificado em processos pertencentes ao grupo
de processos de engenharia. Na Tabela 2 apresentado o
primeiro processo considerado desse grupo, o processo de
elicitao de requisitos.
1 De acordo com a norma, infraestrutura pode incluir hardware, software,
mtodos, ferramentas, tcnicas, padres e outras facilidades para desenvolvimento, operao e manuteno.
25

Processo: Elicitao de Requisitos
Objetivos: Reunio, processamento e monitoramento da evoluo das necessidades do cliente e
de seus requisitos atravs da vida do produto e/ou servio.
Resultados esperados de uma implementao com sucesso:
(1) Contnua comunicao com o cliente;
(2) Ajuste dos requisitos definidos com o cliente;
(3) Estabelecimento de um mecanismo para avaliar e recepcionar mudanas de requisitos do
cliente, resultado de mudanas de necessidades do mesmo;
(4) Elaborao de um mecanismo para continuamente monitorar as necessidades do cliente;
(5) Criao de um meio que permita ao cliente consultar o status de suas requisies;
(6) Gerenciamento de melhorias derivadas de troca de tecnologias ou mudanas de necessidades
do cliente.
Tarefas necessrias
Obteno dos requisitos do cliente: consiste em obter e definir quais so os requisitos do cliente,
por meio de solicitaes diretas e pela especificao de entradas para o seu sistema. Isso pode ser
obtido por reviso dos propsitos de negcio do cliente, verificao do ambiente operacional e de
hardware e ainda outros documentos.
Entendimento das expectativas do cliente: tem por objetivo assegurar que tanto fornecedor
quanto o cliente entenderam cada requisito da mesma maneira. Revises com os clientes para um
entendimento melhor das suas necessidades e expectativas devem ser conduzidas.
Concordncia com os requisitos: busca obter formalmente junto ao cliente e seus interessados a
concordncia total com relao aos requisitos estipulados.
Estabelecimento final dos requisitos: essa tarefa produz um documento formal considerado o
estabelecimento final dos requisitos para uso na fase de projeto e para confronto com futuras
mudanas de necessidades do cliente.
Gerenciamento de mudanas de requisitos do cliente: consiste em gerenciar todas as mudanas
do cliente em relao ao documento original de requisitos, garantindo que melhorias resultantes
de mudana de tecnologias ou de necessidades do cliente possam ser identificadas e aquelas que
sejam afetadas por mudanas possam ser analisadas em relao a impacto e riscos, permitindo a
tomada de aes.
Estabelecimento de mecanismo de comunicao com cliente: consiste em prover meios para que o
cliente possa ser alertado do status e disposio das suas mudanas de requisitos.
Tabela 2. Engenharia: processo de Elicitao de Requisitos
Comentrio sobre o processo:

A clara definio e entendimento comum dos requisitos
uma das caractersticas mais relevantes para manuteno
de software, porm, as sugestes da norma podem ser
demasiadas formais para a grande massa de pequenas
manutenes normalmente existentes. Exigir que o cliente
documentasse todos os pedidos da maneira como a norma
expe pode no ser adequado para a grande maioria dos
pequenos ajustes, o que poderia levar a um descontentamento do cliente, o qual consideraria a organizao que
contratou extremamente burocrtica.
A soluo mais evidente, a exemplo do que fazem muitas organizaes, o uso de sistemas on-line de help-desk,
reservando apenas s manutenes mais complexas um
procedimento formal de documento de requisitos.
Por meio de um help-desk, possvel documentar tanto
as solicitaes do cliente, como as interaes da equipe
de suporte/manuteno, atendendo tambm ao requisito
da norma de criao de um mecanismo para consulta ao
26

Processo: Anlise de Requisitos de Software
Objetivos: Estabelecimento dos requisitos de elementos de software para o sistema.
(1) Definio dos requisitos necessrios aos elementos de software do sistema, bem como suas
interfaces;
(2) Requisitos de software so analisados quanto corretude e testabilidade;
(3) O impacto dos requisitos de software no ambiente operacional compreendido;
(4) Consistncia e rastreabilidade so estabelecidas entre os requisitos de software e os requisitos
de sistema;
(5) Definio da priorizao de implementao para os requisitos de software;
(6) Aprovao e atualizao dos requisitos de software sempre que necessrio;
(7) Avaliao das mudanas de requisitos de software com relao a custos, cronograma e
impacto tcnico;
(8) Composio final dos requisitos de software e comunicao a todas as partes afetadas.
Tarefas necessrias
Especificao de requisitos de software: definir, analisar e priorizar requisitos de software
operacionais e no-operacionais do sistema, registrando no documento de requisitos de software.
Determinao do impacto no ambiente operacional: determinar as interfaces entre os requisitos
de software e outros elementos do ambiente operacional e o impacto que esses requisitos tero.
Desenvolvimento de um critrio de teste de software: usar os requisitos de software para definir
critrios de aceitao para os testes do produto de software, que devem mostrar conformidade
com esses requisitos de software.
Garantia de consistncia: garantir a consistncia entre a anlise dos requisitos de sistema
e a anlise dos requisitos de software. Essa consistncia deve ser mantida por meio do
estabelecimento e manuteno da rastreabilidade entre os requisitos de sistema e os requisitos
de software.
Avaliar e atualizar os requisitos de software: avaliar os requisitos junto ao cliente, aprovando as
mudanas e atualizando os requisitos de especificao de software.
Comunicar os requisitos de software: estabelecer mecanismos de comunicao para disseminao
dos requisitos de software, atualizando os mesmos para todas as partes que forem precisar.
Tabela 3. Engenharia: processo de Anlise de Requisitos de Software
status da uma determinada solicitao pelo cliente. Essa

uma forma de evitar outro problema importante que surge
com a obteno dos requisitos: a perda de informaes. Se
os requisitos forem passados via telefone, e-mail, fax, etc., a
experincia mostra que a perda dessas informaes comum
e leva a um descontentamento geral, com conseqente perda
de credibilidade da organizao frente ao cliente.
Na sequncia, o prximo processo a ser considerado o
de anlise de requisitos de software. Na Tabela 3 exposto
esse processo.
No contexto de manuteno de software, os requisitos
so freqentemente de incluso de novas funcionalidades
ou de adaptaes nas j existentes. Assim, supondo que o
atual software esteja com relativa estabilidade, modificaes
precisam ser cuidadosamente consideradas, j que no
verdade que uma alterao no software sempre garantir
que ele estar melhor adequado realidade da organizao.
Problemas como efeito cascata de alteraes, que geram
problemas em outros mdulos do sistema, precisam ser
M anuten o
considerados. A anlise de requisitos em muitas situaes

pode encontrar outros meios de atender necessidade do
cliente sem exigir mudana no software (o software normalmente tem recursos que so desconhecidos ao cliente).
Nesse ponto necessrio um servio de suporte eficiente
da organizao que desenvolve e mantm o produto, para
que possam ser percebidas as situaes nas quais recursos pouco conhecidos do software podem ser utilizados,
evitando-se assim manutenes desnecessrias.
O prximo processo considerado o de teste de software,
conforme mostrado na Tabela 4.
Testes de manutenes efetuadas, principalmente em
sistemas legados (normalmente softwares de grande porte
e com estrutura e documentao comprometidas), representam uma dificuldade grande para a disponibilizao
de um produto estvel. Esse fato torna o planejamento de
testes fundamental para evitar que ocorram muitas idas
e voltas do software ao ambiente de produo do cliente,
em razo de erros.
Quando a manuteno ocorre em um software que ainda
no constitui um sistema legado, como aqueles em pleno
processo de crescimento e agregao de novas funcionalidades, a importncia dos testes acentuada principalmente
no quesito de integrao. Testar um pequeno mdulo, ou
uma pequena funcionalidade alterada, pode ser simples e
realizado pelo prprio programador, porm no momento
da integrao que o efeito cascata de uma alterao com problemas pode gerar situaes futuras indesejadas. Garantir
que o produto de software integrado funcione por completo
Processo: Teste de Software
Objetivos: Confirmao de que o produto de software integrado est de acordo com os requisitos
previamente definidos.
(1) Critrio de integrao de software definido para demonstrar a conformidade com os
requisitos de software;
(2) O software integrado verificado usando-se o critrio criado;
(3) Os resultados dos testes so registrados;
(4) Uma estratgia de regresso definida para ser usada para re-testar o software quando uma
alterao em seus itens for realizada.
Tarefas necessrias
Desenvolvimento de testes para o produto de software integrado: descrever os testes a serem
efetuados no produto de software integrado, indicando os requisitos sendo checados, entrada de
dados e critrio de verificao. O conjunto de testes deve mostrar conformidade com os requisitos
de software.
Teste do produto de software integrado: teste do produto de software utilizando-se o critrio
estabelecido, registrando os resultados. Atualizao da documentao quando necessrio.
Teste de regresso do produto de software integrado: desenvolver uma estratgia de testes de
regresso para re-testar o software integrado. Se mudanas forem feitas nos itens de software,
proceder com os testes de regresso conforme critrio estabelecido.
Tabela 4. Engenharia: processo de Teste de Software
o mnimo esperado pelos clientes. Se a organizao falha

continuamente nesse ponto, a desconfiana do cliente no
software logo verificada.
Finalmente, o ltimo processo considerado no grupo de processos de engenharia o de manuteno de software e sistema.
Na Tabela 5 esse processo descrito.
A previso, pela norma, de um processo especfico para
manuteno de software, vem diretamente ao encontro dos
propsitos deste artigo. Uma poltica de manuteno focada
no entendimento da dinmica da atividade significa economia
de tempo e reduo de custos.
As tarefas da norma buscam conscientizar a organizao
de que a manuteno no pode ser uma tarefa subsidiria
dentro da empresa, sendo acionada ocasionalmente quando
Processo: Manuteno de Software e Sistema
Objetivos: Modificao de um sistema/produto de software aps entrega ao cliente, para corrigir
falhas, melhorar o desempenho ou outros atributos, ou ainda adapt-lo para um ambiente
modificado.
(1) Uma estratgia de manuteno desenvolvida para gerenciar modificaes, migraes e
retirada de produtos de acordo com a estratgia adotada;
(2) Identificao do impacto das mudanas no sistema/software existente para a organizao,
operaes ou interfaces;
(3) Documentao de sistema/software afetada atualizada conforme necessrio;
(4) Produtos modificados so desenvolvidos com testes associados que demonstram que outros
requisitos no esto comprometidos;
(5) Produtos atualizados so migrados para o ambiente do cliente;
(6) Via requisio, produtos so retirados de uso de uma maneira controlada que minimize os
distrbios para o cliente;
(7) O sistema/software modificado comunicado a todas as partes afetadas.
Tarefas necessrias
Desenvolvimento de uma estratgia de manuteno: desenvolver a estratgia para manuteno,
migrao e retirada de produtos de maneira consistente com os requisitos de manuteno,
comunicando a estratgia e possveis polticas de garantias.
Anlise de problemas do usurio e mudanas: analisar os problemas do usurio, suas requisies
e mudanas necessrias, avaliando o impacto de diferentes opes para modificar o sistema ou
software existente, interfaces e requisitos. Documentar a opo escolhida.
Implementar e testar modificaes:determinar quais produtos precisam ser mudados.Implementar,
testar e documentar as modificaes selecionadas, demonstrando que o sistema e requisitos de
software, bem como a integridade, no sero comprometidos com a alterao.
Atualizar o sistema do cliente: migrar o sistema e software atualizados para o ambiente do cliente.
Prover conforme apropriado: notificao dos planos de migrao e atividades, operao paralela
do antigo e do novo sistema e necessidades de treinamento. Proceder com uma atividade de psoperao para revisar e assegurar o impacto da modificao.
Retirada do produto de software: seguindo aprovao, retirar o sistema obsoleto do ambiente do
usurio, provendo conforme apropriado: notificao dos planos de retirada e atividades, operao
paralela com a troca de sistemas, converso de dados para o sistema novo, arquivamento do
sistema e dados, treinamento de usurios e suporte.
Comunicar modificaes: estabelecer mecanismos de comunicao para prover a disseminao das
modificaes de sistema/software a todas as partes afetadas.
Tabela 5. Engenharia: processo de Manuteno de Software e Sistema
27
Processo: Suporte ao Cliente
Processo: Alinhamento Organizacional
Objetivos: Estabelecimento e manuteno de um aceitvel nvel de servios atravs de

assistncia e consultoria ao cliente para dar apoio ao uso efetivo do produto.
(1) Identificao e monitorao dos servios necessrios para o suporte ao cliente;
(2) Avaliao da satisfao do cliente tanto com relao ao suporte oferecido como com relao
ao produto;
(3) Suporte operacional oferecido atravs do tratamento das questes do cliente, incluindo suas
novas requisies;
(4) As necessidades de suporte do cliente so conhecidas por meio do oferecimento de servios
apropriados.
Objetivos: Capacitao dos processos de software necessrios organizao para prover produtos
de software e servios, de forma que fiquem consistentes com seus objetivos de negcios.
(1) Definio dos objetivos de negcios da organizao;
(2) Definio de seu framework de processos, que inclui uma srie de processos de software
necessrios para alcanar os objetivos de negcios da organizao;
(3) Elaborao de uma estratgia para definio, implementao e melhoria de processos;
(4) A misso da organizao, seus valores principais, vises e objetivos so apresentados a todos
os funcionrios;
(5) Comum viso da organizao pelos seus funcionrios, compartilhando o entendimento dos
objetivos de negcios para que possam realizar suas funes eficientemente;
(6) Cada indivduo na organizao deve entender seu papel para alcanar os objetivos de negcios
e avaliar se est apto a cumprir esse papel.
Tarefas necessrias
Estabelecer suporte do produto: estabelecer um servio por meio do qual o cliente possa apresentar
problemas e questes encontradas no uso do produto e receber ajuda para solucion-los.
Prover treinamento dos usurios: oferecer treinamento e documentao ao usurio, de forma que
o produto possa ser eficientemente utilizado.
Monitorar o desempenho: monitorar o desempenho operacional do produto, de forma a estar
ciente dos problemas que podem impactar no nvel de servio.
Determinar o nvel se satisfao do cliente: determinar o nvel de satisfao do cliente com os
produtos e servios oferecidos.
Comparar a satisfao do cliente: comparar e monitorar o nvel obtido de satisfao do cliente com
as indstrias do setor e, quando possvel, com os concorrentes diretos.
Tabela 6. Operao: processo de Suporte ao Cliente
necessria, sem um planejamento e acompanhamento maior.

A razo disso a sua caracterstica de atividade inevitvel.
praticamente impossvel imaginar um software que funcionar
em uma empresa dinmica sem necessidade de modificaes
e de incluso de novas funcionalidades.
Uma observao importante sobre esse processo refere-se novamente necessidade de avaliar a real necessidade do cliente,
mantendo para isso um meio eficiente de comunicao e um
conhecimento sobre o negcio dele (ainda que pontual).
Tarefas necessrias
Desenvolver uma viso estratgica: desenvolver uma viso estratgica para a organizao, que seja
capaz de identificar os objetivos de negcios e sua relao com funes de engenharia de software
e de sistemas.
Definir o framework de processos: identificar os processos que precisam ser executados para que
seja possvel alcanar os objetivos de negcios.
Prover comprometimento gerencial: prover suporte gerencial para a aplicao e melhoria
estratgica de processos.
Comunicar a viso e objetivos: explicar a viso e objetivos estratgicos da organizao para todos
os indivduos que trabalhem para ela, utilizando mecanismos adequados de comunicao e
gerenciamento.
Garantir o compartilhamento de uma viso comum: garantir que cada indivduo da organizao
compreenda a viso comum e se comprometa a cumprir sua funo individual com eficincia.
Permitir participao ativa: permitir que cada indivduo contribua para se alcanar os objetivos de
negcios e apresentar iniciativas de melhoria de processos.
Tabela 7. Gerncia: processo de Alinhamento Organizacional
ser extremamente til para oferecer alternativas ao usurio,

evitando manutenes freqentemente desnecessrias.
Um total de 2,9% dos problemas de manuteno de software

foi classificado em processos pertencentes ao grupo de processos de operao, sendo somente um processo desse grupo
referenciado. O processo referenciado foi o de suporte ao cliente,
conforme apresentado na Tabela 6.

foi relacionado aos processos do grupo de gerncia. Esse foi o
grupo que mais apresentou problemas associados, e isso vem
ao encontro dos resultados encontrados no estudo de caso
apresentado, que aproxima os problemas de questes mais de
ordem gerencial do que de ordem tcnica.
O primeiro processo desse grupo o de alinhamento organizacional, conforme descrito na Tabela 7.

Prover suporte efetivo ao produto de software tornou-se
um fator bsico de competitividade. Diante dessa realidade,
e considerando que muitos dos problemas com operao de
software esto relacionados ao desconhecimento do usurio
em relao maneira correta de utilizar o software, planejar e
administrar a forma como o servio ser oferecido representa
caracterstica bsica de uma organizao que comercializa e
mantm produto de software.
No contexto de manuteno de software, o papel do suporte
ao produto tem grande importncia no sentido de evitar necessidades de mudanas. Pessoal de suporte bem treinado pode
28

A postura gerencial, como em todos os demais processos
envolvidos no ciclo de vida de software, tem papel fundamental na atividade de manuteno. Um nico funcionrio de
desenvolvimento preocupado em produzir software com alta
manutenibilidade dificilmente conseguir apoio dos demais
programadores e analistas, sem o devido suporte gerencial.
Desenvolver software com alta manutenibilidade algo de natureza estratgica e, portanto, deve partir da conscincia dos altos
M anuten o
administradores, como uma postura global da organizao.

Para complementar o papel da gerncia no contexto de manuteno de software, as decises associadas ao planejamento
e aos objetivos de longo prazo sobre o software no devem ser
mantidas de forma fechada entre os membros da cpula da
organizao, mas, pelo contrrio, devem ser compartilhadas
com as suas equipes, deixando claro ao desenvolvedor/mantenedor a sua importncia e contribuio para o propsito
maior do software em que trabalha. Viso diferenciada para
equipes de desenvolvimento e de manuteno o principal
ponto a se evitar.
O prximo processo do grupo de gerncia o de gerncia
organizacional, apresentado na Tabela 8.
Citar a adoo de prticas modernas de gerncia organizacional, bem como o uso de ferramentas e meios de monitorao
do desempenho global tanto das pessoas como dos demais
recursos de infra-estrutura, parece ser desnecessrio, uma vez
que isso j a realidade de organizaes competitivas. Porm,
no desnecessrio afirmar que mesmo em um ambiente
controlado e adaptado, problemas surgem, e no contexto de
manuteno de software eles podem representar um entrave
para a efetivao de outros processos, como o alinhamento
organizacional citado no processo anterior.
Os problemas de manuteno de software relacionados com
o processo de gerncia organizacional so totalmente de natureza humana e relacionados com a tradicional postura de
valorizao, muitas vezes absoluta, do desenvolvimento frente
a manuteno de software. Todavia, no seria justo acusar a
Processo: Gerncia Organizacional
Objetivos: Estabelecimento e controle de prticas de gerenciamento de software durante a
execuo dos processos necessrios ao provimento de produtos/servios de software.
(1) Investimento em infra-estrutura de gerenciamento adequada;
(2) Identificao das melhores prticas para apoiar a implementao do gerenciamento efetivo
da organizao e de seus projetos;
(3) Constituio de uma base para avaliao da conquista ou no dos objetivos de negcios da
organizao.
Tarefas necessrias
Identificar a estrutura de gerenciamento: identificar a infra-estrutura de gerenciamento
apropriada para a execuo de prticas de gerenciamento de software que forem consistentes
com os objetivos de negcios da organizao.
Investir em infra-estrutura de gerenciamento de software: investir na infra-estrutura apropriada
de gerenciamento de software, segundo o escopo amplo da organizao.
Identificar as prticas de gerenciamento de software: identificar efetivas prticas de
gerenciamento de software para apoiar a organizao e a implementao de software.
Avaliar a efetividade: avaliar a efetividade das prticas de gerenciamento de software
implementadas para alcanar os objetivos de negcios da organizao.
Prover suporte para a adoo das melhores prticas: utilizar abordagens de incentivo e infraestrutura de gerenciamento de software para apoiar a implementao de prticas de gerenciamento,
registrando-se as melhores para disseminao na organizao, como parte de seus bens.
Tabela 8. Gerncia: processo de Gerncia Organizacional
organizao que adota tal postura como incapaz de visualizar

e entender de maneira ampla seu negcio de software. Essa
postura clssica, e resultante da prpria histria de evoluo
da engenharia de software, vem agora gradativamente sendo
alterada, sendo que a velocidade dessa alterao depende muito
de uma anlise cuidadosa dos objetivos de mdio e longo prazo
de cada organizao.
Processo: Gerncia de Projeto
Objetivos: Identificao, estabelecimento, coordenao e monitorao de atividades, tarefas e
recursos necessrios a um projeto para produzir um produto ou servio no contexto de requisitos
e limitaes.
(1) Definio do escopo de trabalho para o projeto;
(2) Verificao das possibilidades de execuo do projeto com os recursos disponveis e limitaes
impostas;
(3) Estimativa das tarefas e dimensionamento dos recursos necessrios;
(4) Identificao e monitoramento de interfaces necessrias entre elementos do projeto e entre
outros projetos e unidades organizacionais;
(5) Desenvolvimento e implementao de planos para a execuo do projeto;
(6) Monitorao do progresso do projeto e elaborao de relatrios;
(7) Tomada de aes de correo de desvios quando objetivos no forem alcanados.
Tarefas necessrias
Definio do escopo do trabalho: definir o trabalho necessrio ao cumprimento do projeto.
Definio do ciclo de vida do projeto: definir o ciclo de vida e estratgia de desenvolvimento para
o projeto, que deve ser apropriado ao seu contexto, escopo e complexidade.
Avaliao da possibilidade de execuo do projeto: avaliar as possibilidades de se alcanar os
objetivos do projeto, diante dos recursos e limitaes existentes.
Determinar e manter estimativas para os atributos do projeto: definir e manter conjuntos de
atributos validados por etapas de projeto (atributos podem incluir: negcios e objetivos de
qualidade do projeto, estimativas de tamanho e complexidade, esforo necessrio e oramento).
Definio de tarefas e atividades do projeto: identificar atividades e tarefas de projeto de acordo
com o ciclo de vida, definindo ainda as dependncias entre elas.
Definio de necessidades de experincia, conhecimento e habilidades: identificar a experincia e
habilidades necessrias ao projeto, e aplic-las para selecionar indivduos e equipes.
Definio de cronograma: alocar recursos para as atividades e determinar a seqncia e
cronograma de execuo das atividades ligadas ao projeto.
Identificar e monitorar as interfaces de projeto: identificar e concordar com interfaces do projeto
com outros projetos ou com outras partes afetadas, monitorando os compromissos acordados.
Alocar responsabilidades: identificar as contribuies especficas de cada indivduo e de cada
grupo necessrias ao projeto, alocando suas responsabilidades especficas, e garantindo que os
comprometimentos foram entendidos e aceitos por todos.
Estabelecer o plano de projeto: definir e manter um plano mestre de projeto, bem como outros
planos relevantes, para cobrir o escopo e objetivos do projeto, seus recursos, infra-estrutura,
interfaces e mecanismos de comunicao necessrios.
Implementar o plano de projeto: implementar as atividades planejadas para o projeto,
registrando o status do progresso e reportando-o s partes afetadas.
Monitorar os atributos do projeto: monitorar o escopo do projeto, seu oramento, custos, recursos
e outros atributos necessrios, documentando desvios significativos que possam ocorrer.
Revisar o progresso do projeto: relatar regularmente e revisar o status do projeto e seu
desempenho frente ao plano de projeto.
Agir para corrigir desvios: tomar aes quando os objetivos de projeto no forem alcanados, para
corrigir desvios com relao ao planejamento, prevenindo a recorrncia de problemas j identificados.
Tabela 9. Gerncia: processo de Gerncia de Projeto
29
Na sequncia, o prximo processo relevante dentro do grupo

de gerncia o de gerncia de projeto, conforme mostrado na
Tabela 9.
Esse foi o processo com maior quantidade de problemas de
manuteno de software associados, apesar de ser um tema
tradicional em administrao. Aparentemente, os problemas resultantes de uma gerncia falha de projetos so bem
conhecidos em todos os contextos, no sendo exclusivos de
manuteno de software. Como exemplos tm-se a falta de
comprometimento com cronogramas, falta de suporte da
gerncia, sobrecarga de tarefas e estimativa de prazos no
condizentes com a complexidade do trabalho. Isso mostra
que apesar da teoria estar evoluda, preciso um controle
muito prximo no dia-a-dia para se evitarem tais problemas
comuns.
No contexto de manuteno de software, no entanto, alguns outros problemas se sobressaem e esto intimamente
ligados ao trabalho com software. Entre eles est a conhecida
idia falsa de que contratar novos integrantes para uma

Processo: Gerncia de Qualidade
Objetivos: Alcanar a satisfao do cliente, por meio da monitorao da qualidade dos produtos ou
servios, a nvel organizacional e de projeto, para assegurar que esto de acordo com os requisitos.
(1) Estabelecimento dos objetivos de qualidade com base nos requisitos explcitos e implcitos
do cliente;
(2) Definio de uma estratgia completa de desenvolvimento para alcanar os objetivos
definidos;
(3) Implantao de um sistema de gerenciamento de qualidade;
(4) Execuo de atividades de controle e garantia de qualidade, avaliando-se seu desempenho;
(5) Monitorao do desempenho com relao aos objetivos de qualidade;
(6) Tomada de providncias quando objetivos de qualidade no forem alcanados.
Tarefas necessrias
Estabelecer objetivos de qualidade: estabelecer objetivos de qualidade para o produto e processo,
preferencialmente de forma quantitativa, baseando-se nos requisitos de qualidade do cliente, e
considerando-se tambm aqueles implcitos relevantes ao ambiente desse cliente.
Definir estratgia global: definir uma estratgia global, incluindo os recursos e responsabilidades,
bem como os objetivos a serem alcanados e a contnua melhoria da qualidade.
Definir critrios de qualidade: definir padres, referncias e mtricas que iro assegurar e verificar
o alcance dos objetivos de qualidade, bem como definir o critrio de aceitao que ir ajudar a
decidir quando objetivos de qualidade foram ou no alcanados.
Estabelecer um sistema de gerenciamento de qualidade: estabelecer e manter um sistema de
gerenciamento de qualidade para planejar, implementar, monitorar e controlar aes preventivas
e corretivas.
Avaliar o cumprimento de objetivos de qualidade: revisar regularmente o atendimento de
objetivos, no nvel mais alto de gerenciamento, usando os critrios definidos.
Tomar aes corretivas ou preventivas: tomar aes corretivas e preventivas, em nvel de
organizao e projeto, quando os objetivos de qualidade no forem alcanados.
Coletar resultados: coletar o retorno do cliente, do projeto, dos processos e das pessoas, para
verificar a contnua melhora da qualidade tanto na organizao como no projeto.
Tabela 10. Gerncia: processo de Gerncia de Qualidade
30
equipe que trabalha com desenvolvimento ou manuteno

de software trar mais agilidade ao processo. Isso pode
ser verificado no problema da contratao de temporrios
que leva diminuio do controle sobre a atividade de
manuteno. Esse problema se une ao do software no ser
visto pela gerncia como um produto que precisa, ainda
durante o desenvolvimento, ter a manuteno trabalhada.
A unio desses dois problemas revela um outro: a falta
de conhecimento sobre o processo de software como um
todo. E aqui vale uma observao prtica importante: no
se podem atribuir a gerentes de projetos que no so de
software, tarefas de gerncia de projetos de software, sem
assegurar que estes conheam as peculiaridades inerentes
ao trabalho com software e seu ciclo de vida.
O processo seguinte, gerncia de qualidade, apresentado
na Tabela 10.
De uma maneira geral, quase todos os problemas de manuteno de software poderiam ser reduzidos ou evitados
com o controle da qualidade. Especificamente na classificao adotada, o problema da ausncia de manuteno
preventiva se relacionou com a gerncia da qualidade, pelo
fato da norma prever para esse processo a tomada de aes
corretivas e preventivas, que vem ao encontro da idia

Processo: Gerncia de Riscos
Objetivos: Identificao, anlise, tratamento e monitorao de riscos de projeto continuamente.
(1) Determinao do escopo do gerenciamento de riscos;
(2) Definio e implementao da apropriada estratgia de gerenciamento de riscos;
(3) Identificao dos riscos conforme se desenvolvem ao longo da conduo do projeto;
(4) Determinao dos recursos de tratamento dos riscos com base na anlise e priorizao dos
mesmos;
(5) Implementao do correto tratamento para evitar o impacto do risco, baseando-se na
prioridade e probabilidade de sua ocorrncia.
Tarefas necessrias
Estabelecer o escopo do gerenciamento de riscos: determinar o escopo do gerenciamento de
riscos a ser implementado, observando-se as polticas de gerenciamento de riscos da organizao.
Definir as estratgias de gerenciamento de riscos: definio das apropriadas estratgias, anlises,
tratamentos e monitoramento de riscos, sempre em relao organizao e ao projeto.
Identificar os riscos: identificar os riscos do projeto, inicialmente com relao estratgia de
projeto, e posteriormente, com os que surgirem durante a conduo do projeto.
Analisar os riscos: analisar os riscos para determinar prioridades e quais recursos de
monitoramento aplicar.
Definir e executar aes de tratamento de riscos: para cada risco ou conjunto de riscos
semelhantes, definir e executar aes apropriadas para reduzi-los a um nvel aceitvel.
Monitorar os riscos: monitorar o estado corrente de cada risco e assegurar a efetividade das aes
de tratamento.
Tomar aes corretivas: tomar aes corretivas apropriadas para reduzir ou evitar o impacto de
cada risco, quando verificado que o tratamento de risco no est atingindo o progresso previsto.
Tabela 11. Gerncia: processo de Gerncia de Riscos
M anuten o
de buscar antever problemas em um produto de software,

procedendo-se com sua correo ou ajuste.
fato conhecido que na prtica muitas vezes a garantia da
qualidade prejudicada por questes como tempo curto e
restries financeiras. No entanto, isso mais uma questo
cultural do que de limitao real. Por exemplo, se existe
limitao financeira para o projeto, razovel pensar que
se deva produzir exatamente o que o cliente deseja (idia
de verificao) e de forma correta (conceito de validao),
evitando problemas futuros com correes e modificaes
perfeitamente evitveis.
Dentro de manuteno de software, a garantia da qualidade deve estar enquadrada como objetivo estratgico da
organizao e disseminada da gerncia para os funcionrios
de nvel operacional. a postura gerencial e a conscincia
de equipe que leva a produo de trabalhos com qualidade.
Parece razovel pensar que se o foco for a qualidade da
manuteno, problemas como a ausncia de adoo de padres
ou treinamento inadequado da equipe de manuteno poderiam
deixar de figurar na lista de problemas de manuteno de
software.
Por fim, o ltimo processo considerado no grupo de
gerncia o de gerncia de riscos, conforme mostrado na
Tabela 11.
fato conhecido que riscos so circunstncias inerentes
a qualquer projeto. A diferena entre um desastre ou a definio de uma alternativa quando um risco ocorre est no
planejamento e nas formas controle que se estabeleceu sobre
a possibilidade dos mesmos ocorrerem.
Dada a caracterstica de ser normalmente impossvel prever se um risco ocorrer e quando ocorrer, somente resta
valer-se da verificao de dados histricos, ou mesmo do
uso de heursticas, para determinar quais os riscos potenciais conhecidos e ento estabelecer formas de reao a eles
caso ocorram.
Dentro do contexto de manuteno de software, foi possvel
listar pelo menos quatro riscos muito comuns, perante os
quais possvel adotar medidas de conteno. Percebe-se
que o problema da elevada rotatividade dos profissionais ligados
manuteno pode ser reduzido com programas de motivao e de justo trato de recursos humanos. J o problema das
mudanas freqentes de prioridades por parte dos clientes pode
ser combatido com a definio e execuo de aes de tratamento
de riscos, conforme sugere uma das tarefas da norma.
Por fim, os ltimos dois riscos que se transformam em problemas de manuteno de software so ligados a questes
tcnicas, como a m qualidade do cdigo-fonte original e a baixa
qualidade da documentao. A exemplo dos demais riscos, o
estudo prvio de como reagir a eles a nica preparao
com a qual a organizao pode contar, sendo que nesses
dois ltimos casos, uma possvel preparao seria o acordo
antecipado com o cliente sobre a possibilidade de se rever
os prazos estabelecidos.

Processo: Gerncia de Recursos Humanos
Objetivos: Prover organizao, e aos seus projetos, os indivduos que possuam habilidades e
conhecimentos para cumprir eficientemente seus papis, trabalhando em grupos coesivos.
(1) Identificao e contratao dos indivduos com as habilidades e competncias requeridas;
(2) Suporte efetiva interao entre indivduos e grupos;
(3) Fora de trabalho capaz de utilizar suas habilidades para compartilhar informaes e
coordenar suas atividades eficientemente;
(4) Definio de critrios objetivos para monitorar o desempenho de cada grupo e indivduo, para
o provimento de retorno e melhoria de desempenho.
Tarefas necessrias
Identificar as habilidades e competncias necessrias: identificar e avaliar habilidades e
competncias necessrias para atingir os objetivos da organizao.
Determinar o critrio de avaliao: definir critrio objetivo que possa ser usado para avaliar
candidatos e assegurar desempenho da equipe.
Recrutar pessoal qualificado: estabelecer um programa sistemtico para recrutamento de pessoal
qualificado que se encaixe nas necessidades da organizao.
Desenvolver habilidades e competncias: definir e prover oportunidades de desenvolvimento de
habilidades e competncias.
Definir a organizao de equipes de projeto: definir a estrutura e regras de operao sobre as
quais as equipes trabalharo.
Motivar equipes de projeto: motivar equipes para a execuo de seus trabalhos, assegurando que todos
tm: (1) entendimento do seu trabalho, (2) uma viso de comum interesse, (3) mecanismos apropriados
de comunicao e trabalho, (4) suporte da gerncia no que o indivduo estiver executando.
Manter interaes entre equipes de projeto: obter e manter um acordo no gerenciamento de
interaes entre equipes.
Avaliar desempenho: avaliar o desempenho de pessoal, tanto individualmente como por equipes,
no que se refere s suas contribuies aos objetivos da organizao como um todo. Assegurar que
os fatos levantados sero discutidos com o pessoal.
Prover retorno sobre o desempenho: prover retorno s pessoas, referente aos resultados de
avaliaes efetuadas.
Manter registros de pessoal: manter registros adequados de pessoal, incluindo no apenas
detalhes pessoais, mas tambm informaes a respeito de habilidades, treinamentos
completados e avaliaes de desempenho.
Tabela 12. Recursos e Infra-estrutura: processo de Gerncia de Recursos
Humanos
Grupo d Processos de Recursos e Infra-estrutura

Um total de 23,5% dos problemas de manuteno de software foi relacionado a problemas com a ausncia de observncia dos processos desse grupo, colocando-o em uma
posio bastante relevante para o contexto de problemas de
manuteno de software.
O primeiro processo que mereceu destaque nesse grupo
foi o de gerncia de recursos humanos, conforme mostrado na
Tabela 12.
Os problemas de manuteno relacionados a esse processo
podem ser vistos como um reflexo da postura clssica das
organizaes: a ateno voltada quase exclusivamente para
o desenvolvimento de software.
31
Uma caracterstica importante da postura organizacional

que se relaciona tanto com esse processo, como com o de
treinamento, conforme apresentado no prximo quadro,
refere-se estratgia de manter os profissionais mais
experientes, e com maior conhecimento sobre o software,
em tarefas de desenvolvimento, reservando aos novatos as
tarefas de manuteno. Essa postura evidencia o desprestgio da tarefa de manuteno pela gerncia o que justifica
diretamente um dos problemas associados a esse processo,
o problema da preferncia dos profissionais por trabalhos de
desenvolvimento. Percebe-se aqui, novamente, um problema cultural funcionando como fonte para problemas de
manuteno.
Nesse sentido, a gerncia de recursos humanos deve ser
considerada no contexto de manuteno de software, e no
de forma genrica, isso devido s caractersticas diferenciadas que essa atividade apresenta em face de outros tipos de
projetos no de software. Um dos pontos a considerar com
cuidado o de avaliar a possibilidade de maiores benefcios
em se colocar profissionais mais experientes em tarefas de
manuteno e no novatos recm contratados.
O prximo processo a ser estudado refere-se ao processo
de treinamento, conforme mostrado na Tabela 13.
Os problemas de manuteno associados a esse processo
so o treinamento inadequado da equipe de manuteno e
o fato de os mantenedores lamentarem por no possurem
contato com o estado-da-arte da tecnologia. Percebe-se

aqui que a valorizao da atividade de manuteno poderia diminuir ambos os problemas: por um lado entendendo-se o papel importante da manuteno de software,
o problema da falta ou inadequao do treinamento seria
atacado diretamente, com o surgimento de programas de
treinamento especficos e focados nas peculiaridades da
atividade. Por outro lado, a questo do no contato com
o estado-da-arte tambm seria reduzido.
O problema do no contato com o estado-da-arte
algo relativo. Hoje um mantenedor afirma isso, por
exemplo, porque no est em contato com a linguagem
de programao da moda ou a ltima metodologia para
desenvolvimento gil. Tal fato se deve valorizao do
desenvolvimento. Porm, se a manuteno passar a ser
outro ponto forte de ateno, a pessoa encarregada de
tarefas de manuteno ter a possibilidade de estar em
contato com tcnicas e ferramentas que so estado-da-arte,
mas da manuteno. Por exemplo, tm-se as tcnicas modernas de decompilao, as ferramentas de recuperao
de documentao etc. Dessa forma o no contato com o
estado-da-arte representa uma alegao referente aos
artefatos utilizados em desenvolvimento, uma vez que
infelizmente ainda so pouco conhecidos aqueles possveis de serem utilizados em manuteno.
O prximo processo considerado no grupo de recursos
e infraestrutura o de gerenciamento do conhecimento,
conforme mostrado na Tabela 14.
Processo: Treinamento
Processo: Gerenciamento do Conhecimento
Objetivos: Prover a organizao, e seus projetos, de indivduos que possuam as habilidades e

conhecimentos necessrios execuo de seus papis eficientemente.
(1) Treinamentos so desenvolvidos ou adquiridos para atender s necessidades de treinamento
tanto da organizao como de projeto;
(2) Treinamentos so conduzidos para assegurar que todos os indivduos possuam as habilidades
necessrias para executar suas tarefas, usando mecanismos como estratgias de treinamento e
materiais.
Objetivos: Garantia de que o conhecimento individual, informaes e habilidades sejam coletados,

compartilhados, reusados e melhorados atravs da organizao.
(1) Infra-estrutura estabelecida e mantida para o compartilhamento de informao atravs da
organizao;
(2) Conhecimento disponibilizado e compartilhado atravs da organizao;
(3)A organizao selecionar a apropriada estratgia de gerenciamento do conhecimento.
Tarefas necessrias
Desenvolver a estratgia para treinamento: desenvolver a estratgia de treinamento, incluindo
como as necessidades de treinamento sero identificadas, como os treinamentos necessrios
sero desenvolvidos ou adquiridos, e como os treinamentos sero realizados.
Identificar necessidades de treinamento: identificar e avaliar habilidades e competncias para
prover e melhor-las atravs de treinamentos.
Desenvolver ou adquirir treinamentos: desenvolver ou adquirir treinamentos que representem
necessidades comuns de treinamento.
Preparar para a execuo do treinamento: identificar e preparar a execuo das sesses de
treinamento, incluindo disponibilidade de materiais e de pessoal a ser treinado.
Treinar o pessoal: treinar o pessoal para possurem conhecimento e habilidades necessrias
execuo de seus papis.
Manter registros de treinamentos: manter adequado registro de treinamentos completados.
Avaliar efetividade do treinamento: identificar e avaliar o valor adicionado oferecido por cada
sesso de treinamento, incluindo a avaliao do material de treinamento utilizado.
Tabela 13. Recursos e Infra-estrutura: processo de Treinamento
32
Tarefas necessrias
Estabelecer um sistema de gerenciamento do conhecimento: estabelecer e manter uma
infra-estrutura de gerenciamento do conhecimento, bem como mecanismos para suportar as
atividades de identificar, classificar, exportar e usar o conhecimento.
Criar uma rede de contribuidores de conhecimento: estabelecer uma rede de especialistas
provendo sua natural interao.
Desenvolver uma estratgia de gerenciamento do conhecimento: definir uma estratgia
apropriada de gerenciamento do conhecimento baseada em necessidades organizacionais,
individuais, de domnio e de projetos.
Capturar o conhecimento: identificar e registrar cada item de conhecimento de acordo com a
classificao estabelecida e critrio de disseminao.
Disseminar a propriedade do conhecimento: compartilhar o conhecimento com especialistas,
usurios e projetistas.
Melhorar o conhecimento disponvel: validar e enriquecer o conhecimento armazenado,
assegurando sua adequao aos valores da organizao.
Tabela 14. Recursos e Infra-estrutura: processo de Gerenciamento do
Conhecimento
M anuten o

Processo: Infra-estrutura
Objetivos: Manter a infra-estrutura confivel e estvel, uma vez que necessria para o apoio do
desempenho de qualquer outro processo.
(1) Definio dos requisitos de infra-estrutura necessrios;
(2) Identificao e especificao dos elementos de infra-estrutura;
(3) Aquisio dos elementos de intra-estrutura;
(4) Implementao dos elementos de infra-estrutura.
Tarefas necessrias
Identificar o escopo do processo de infra-estrutura: identificar os procedimentos, padres,
ferramentas e tcnicas que o processo de infra-estrutura deve apoiar.
Definir os requisitos do processo de infra-estrutura: definir os requisitos de infra-estrutura para
apoiar o desempenho dos processos relacionados. Pode incluir: (1) segurana, (2) facilidades de
acesso remoto, (3) backup e recuperao de dados, (4) requisitos de manuteno, etc.
Adquirir e prover processo de infra-estrutura: adquirir e prover um processo de infra-estrutura,
que satisfaa aos requisitos.
Estabelecer o processo de infra-estrutura: reunir e integrar os elementos do processo de infraestrutura, provendo um ambiente efetivo que apie a implementao dos processos da organizao.
Prover apoio para o processo de infra-estrutura: prover suporte para aqueles que utilizam o
processo de infra-estrutura.
Manter o processo de infra-estrutura: realizar manuteno no processo de infra-estrutura com o
propsito de corrigir defeitos e melhorar o desempenho.
Tabela 15. Recursos e Infra-estrutura: processo de Infraestrutura

Manuteno de software uma tarefa imprevisvel. Isso
resulta no fato de que nem sempre possvel aplicar a ela
tcnicas pr-moldadas tpicas de processos de desenvolvimento. Nesse sentido, cada manuteno pode se tornar
uma fonte de novos conhecimentos e novas descobertas
heursticas.
justamente esse conhecimento derivado de manutenes passadas que deve ser preservado e, principalmente,
disseminado entre pessoas e equipes diferentes. Essa ao
pode gerar economia de tempo e de recursos, acelerando
a liberao das alteraes para o cliente. Infelizmente,
notou-se que um dos problemas de manuteno apontados
refere-se justamente perda ou no disseminao de conhecimentos adquiridos com os demais membros interessados
da organizao. Isso pode ser evitado com a construo de
sistemas internos paralelos de apoio, dedicados a armazenar
e disponibilizar esse tipo de informao.
Por fim, o ltimo processo desse grupo que recebe destaque
o processo de infraestrutura, mostrado na Tabela 15.
O processo de infraestrutura no contexto de conteno
e preveno de problemas de manuteno de software se
destaca no sentido de fornecer ferramentas e ambiente
diferenciado para manuteno.
Normalmente, o que ocorre nas empresas a unio, em um
mesmo ambiente computacional, de ferramentas e atividades
de desenvolvimento e manuteno, o que causa freqentemente

Processo: Documentao
Objetivos: Desenvolvimento e manuteno do registro de informaes produzidas por um
processo.
(1) Desenvolvimento da estratgia para identificao da documentao que ser produzida
durante o ciclo de vida de um produto ou servio;
(2) Identificao dos padres a serem aplicados para o desenvolvimento da documentao;
(3) Identificao da documentao a ser produzida pelo processo ou projeto;
(4) O contedo e propsito de toda documentao especificado, revisado e aprovado;
(5) Documentao desenvolvida de acordo com os padres definidos;
(6) Documentao mantida de acordo com os critrios definidos.
Tarefas necessrias
Desenvolver a estratgia de gerenciamento da documentao: determinar a estratgia de
gerenciamento da documentao, que deve indicar o que deve ser documentado a cada estgio do
ciclo de vida do produto/servio.
Estabelecer padres para documentos: estabelecer padres para desenvolver, modificar e manter
documentos.
Especificar requisitos de documentos: especificar os requisitos para os documentos, como ttulo,
data, identificao, verso, autores, revisores, propsito, lista de distribuio etc.
Identificar os documentos a serem produzidos: para qualquer ciclo de vida, identificar os documentos
a serem produzidos.
Desenvolver os documentos: desenvolver os documentos requeridos ao ponto corrente do processo,
de acordo com os padres e poltica estabelecidos.
Checar os documentos: revisar os documentos antes da distribuio e autoriz-los antes de cada
distribuio/atualizao.
Distribuir os documentos: distribuir os documentos de acordo com as formas de distribuio
determinadas, confirmando o recebimento quando necessrio.
Manter os documentos: manter os documentos atualizados de acordo com a estratgia de
documentao empregada.
Tabela 16. Gerncia de Configurao: processo de Documentao
problemas com sobreposio de arquivos, perda de modificaes e propagao de falhas. A soluo para esses problemas
no se resume em adotar um software de controle de verso. A
soluo precisa incluir uma separao entre desenvolvimento
e manuteno e principalmente processos para se conduzir
ambas as atividades.
conhecida a relativa dificuldade de se unir um projeto
modificado com o projeto paralelo em desenvolvimento. Isso
porque no mesmo instante em que um software esteja sendo
modificado em um determinado ponto, ele pode estar em
desenvolvimento por outra equipe, agregando-se funcionalidades novas, no necessariamente solicitadas pelos clientes,
mas como forma de sofisticao e complementao do software
original. Nesse momento surge a dificuldade de unir eventualmente mesmos arquivos modificados em locais diferentes.
Situaes como essas devem ser analisadas e amparadas por
ferramentas atravs de um processo de infraestrutura.

foi relacionado m implementao de processos do grupo de
processos de gerncia de configurao. So trs os processos
33
Processo: Gerncia de Configurao
Processo: Gerncia de Solicitaes de Mudana
Objetivos: Estabelecimento e manuteno da integridade dos itens de um processo (como

exemplo, um mdulo do produto de software em desenvolvimento), tornando-os disponveis s
partes interessadas.
(1) Desenvolvimento de uma estratgia de gerenciamento de configurao;
(2) Itens/produtos gerados por um processo ou projeto so identificados, definidos e confirmados;
(3) Modificaes e atualizaes nos itens/produtos so controladas;
(4) Modificaes e atualizaes so disponibilizadas a todas as partes afetadas;
(5) O status e modificaes dos itens/produtos so registrados e reportados;
(6) A completude e consistncia dos itens/produtos so asseguradas;
(7) O armazenamento, manipulao e entrega dos itens/produtos controlado.
Objetivos: Assegurar que as solicitaes de mudana sejam gerenciadas, monitoradas e

controladas.
(1) Desenvolvimento de uma estratgia de gerenciamento;
(2) Requisies de mudana so identificadas e registradas;
(3) Dependncias e relaes com outros pedidos de mudana so identificadas;
(4) Definio de critrios para confirmao da implementao de mudanas;
(5) Priorizao de requisies de mudana e estimativas de recursos necessrios;
(6) Aprovao de mudanas com base na prioridade e disponibilidade de recursos;
(7) Mudanas aprovadas so implementadas;
(8) Possibilidade de conhecimento do status de todos os pedidos de mudana.
Tarefas necessrias
Tarefas necessrias
Desenvolver a estratgia de gerenciamento de configurao: determinar a estratgia de
Desenvolver uma estratgia de gerenciamento de mudanas: estabelecimento de uma estratgia

de gerenciamento de mudanas para assegurar que as mudanas possam ser descritas, registradas,
analisadas e implementadas.
Registrar os pedidos de mudanas: cada requisio de mudana deve ser unicamente identificada
e registrada.
Registrar o status dos pedidos de mudana: requisies de mudana devem possuir um status
associado para permitir facilidade no monitoramento.
Estabelecer as dependncias e relaes com outros pedidos: identificar o relacionamento do pedido de
mudana com outros pedidos para estabelecer suas dependncias (por exemplo, mudanas no mesmo
componente de software ou mudanas requisitadas para uma futura verso j planejada do software).
Avaliar o impacto da mudana: avaliar o impacto da mudana, os recursos e os potenciais benefcios
resultantes.
Identificar as atividades de verificao e validao necessrias: antes de implementar a mudana, o
escopo das atividades de verificao e validao correspondentes deve ser identificado.
Aprovar as mudanas antes de implementao: todas as mudanas devem ser aprovadas antes da
implementao.
Incluir mudana em cronograma: as mudanas aprovadas devem ser agendadas para
implementao.
Revisar a mudana implementada: todas as mudanas devem ser revisadas aps implementao e antes
de serem concludas, de modo a garantir que tiveram os efeitos desejados e atingiram os objetivos.
gerenciamento de configurao, incluindo as atividades e cronograma.

Identificar os itens de configurao: identificar os itens de configurao que precisam ser
individualmente armazenados, testados, revisados, usados, alterados, entregues e mantidos.
Estabelecer a estrutura e hierarquia de arquivo e diretrios: prover meios eficientes de acesso e
armazenamento de entidades necessrias.
Estabelecer baselines: estabelecer as baselines internas e de entrega, que devem armazenar todos
os itens configurados necessrios ao estgio respectivo do projeto (obs.: uma baseline representa
um pacote de itens validados e considerados de acordo com os propsitos do projeto).
Manter a descrio dos itens de configurao: manter uma descrio atualizada de cada item de
configurao.
Controlar modificaes e atualizaes: estabelecer um mecanismo para registrar e atualizar os itens.
Manter histrico de item de configurao: manter um histrico de cada item de configurao em
detalhamento suficiente para permitir recuperar toda verso anterior, quando necessrio.
Relatar status da configurao: relatar o status de cada item de configurao e seu relacionamento
com a atual integrao do sistema.
Verificar informaes sobre os itens configurados: verificar se a informao sobre os itens
configurados e suas estruturas, fornecidos pelo relatrio de status, est completa e assegurar ainda
a consistncia desses itens.
Gerenciar o backup, armazenamento, manipulao e entrega de itens de configurao: assegurar a
integridade dos itens configurados, bem como dos recursos de backup e armazenamento. Controlar
tambm a manipulao e entrega dos itens configurados.
Tabela 17. Gerncia de Configurao: processo de Gerncia de Configurao
desse grupo que merecem destaque nesse contexto. O primeiro processo, documentao, apresentado na Tabela 16.
A documentao de software uma das tarefas mais trabalhosas em manuteno de software. Isso porque cada manuteno individual deve ser documentada, e o projeto do software
como um todo atualizado. O desenvolvimento de documentos
padronizados e processos formais de atualizao de documentao podem no ser viveis para manutenes corriqueiras e
de pequeno porte. Enfrentar um processo burocrtico a cada
pequena manuteno acaba desestimulando a execuo dessa
atividade e conseqentemente levando progressiva desatualizao da documentao do projeto.
Cada organizao deve avaliar o produto de software que desenvolve do ponto de vista da documentao, estabelecendo-se
34
Tabela 18. Gerncia de Configurao: processo de Gerncia de

Solicitaes de Mudana
uma maneira prtica de manter essa documentao atualizada.

O interessante facilitar no caso de pequenas manutenes,
reservando somente s de grande porte processos mais formais
de construo e atualizao de documentos. Novamente o uso
de sistemas internos de apoio uma alternativa favorvel.
O prximo processo a receber ateno nesse grupo o de
gerncia de configurao, conforme mostrado na Tabela 17.
A quantidade de arquivos modificados em uma manuteno,
ainda que de pequeno porte, pode ser grande. A esse fato
inclui-se o problema de os mesmos arquivos poderem estar
sofrendo outras modificaes por parte da equipe de desenvolvimento. Esse apenas um dos problemas que precisam
ser tratados nesse processo, e est relacionado com a questo
de conciliar manuteno com desenvolvimento.
Outro fato ligado ao processo de gerncia de configurao
o estabelecimento de componentes e verses baselined. Se
M anuten o
o produto de software est, de um lado, em evoluo pela

equipe de desenvolvimento e, por outro lado, em fase de
adaptao e modificao por equipe de manuteno, tornase difcil e necessrio garantir uma forma de estabelecer e
armazenar verses testadas e confiveis do software como
um todo. A ausncia de um processo adequado pode levar a
perda de cdigo e alteraes, bem como a entrega de verses
do software com novos problemas para o cliente.
Finalmente, o ltimo processo a ser destacado o de gerncia de solicitaes de mudana. Esse processo mostrado
na Tabela 18.
Mudanas talvez seja a palavra mais presente no contexto
de manuteno de software e mudanas podem surgir em
um volume muito grande, o que depender do estgio de
evoluo do software e do domnio ao qual atende. A prtica
mostra que quando o volume de solicitaes de mudana
grande, inmeros outros problemas surgem derivados
desse fato.
Um processo adequado de gerncia de solicitaes de
mudana deve ser capaz de filtrar o que de fato resultar
em uma alterao no produto de software e o que pode ser
resolvido por outros meios ou valendo-se de recursos j
existentes e pouco conhecidos do software. Alm de saber
separar o que mesmo necessrio do que mero preciosismo do usurio, esse processo deve atentar-se especialmente
para a questo da priorizao dos chamados. Isso porque
o usurio normalmente ir solicitar alteraes em cima
de alteraes e a probabilidade de se perder o controle do
que est sendo feito alta. Uma dica aqui estabelecer um
mecanismo de comunicao eficiente com o usurio, preferencialmente atravs de um sistema paralelo ao qual o
usurio possa consultar e que possa tambm ser usado pela
organizao para expor dificuldades e possveis sobreposies de chamados considerados urgentes, deixando claro
ao cliente os fatos que justificam a negao ou adiamento
de uma determinada manuteno.
Propostas na Literatura
Alguns autores que se dedicaram a pesquisar problemas
de manuteno de software tambm mostraram propostas
de solues ou de reduo desses problemas.
As solues apresentadas so semelhantes e pode-se dizer
que esto muito bem resumidas e apresentadas em Dart et
al. (2001), que organizou suas propostas de interveno nos
problemas de manuteno em trs grandes grupos: recomendaes quanto a processos, quanto a pessoas e quanto
a ferramentas.
Propostas quanto aos processos:
Reexaminar polticas corporativas luz de ferramentas
CASE;
Enfatizar a importncia de garantir que todo cdigo esteja
completamente e cuidadosamente documentado;
Discernir as diferenas de necessidades entre projetos de

manuteno e projetos de novos softwares;
Implantar filosofia de projeto-para-manuteno;
Planejar apropriadamente o tempo em cronogramas que
incluam documentao e testes;
Promover os sucessos anteriores com relatrios de lies
aprendidas;
Instituir e reforar prticas de garantia de qualidade;
Investigar porque a comunicao interna na organizao
ocasionalmente torna-se ineficiente;
Melhorar as interaes dos clientes com os desenvolvedores
e mantenedores;
Melhorar a seleo de fornecedores e monitorar processos,
planos de estratgia e tomadas de decises.
Propostas quanto s pessoas:
Disseminar o conhecimento relativo ao estado-da-arte de
ferramentas e conhecimentos;
Associar pessoas a papis particulares (exemplo: testes) para
projetos e oferecer suporte corporativo a esses papis;
Encorajar as pessoas mais experientes para se tornarem
mantenedores;
Melhorar o prestgio das tarefas de manuteno;
Melhorar a comunicao entre grupos por meio de recursos
diversos (quadros, ferramentas eletrnicas etc.), registrando-se
a experincia individual e inter-projetos, elegendo-se algum
para organizar e promover essa comunicao;
Tornar mais efetivo o treinamento, especialmente com relao
ao uso de ferramentas, padres e documentao;
Estabelecer um recurso de consulta a informaes tcnicas
para suporte da gerncia.
Propostas quanto s ferramentas:
Investir em ferramentas mais efetivas, principalmente aquelas que suportarem engenharia reversa, reengenharia, testes,
gerncia de configurao e documentao;
Encorajar fornecedores a construrem ou adaptarem suas
ferramentas, especialmente para suportarem as necessidades
da organizao;
Melhorar a qualidade das ferramentas desenvolvidas
internamente;
Avaliar novas ferramentas e determinar a sua aplicabilidade
em projetos especficos;
Melhorar as atividades e uso de ferramentas que centralizem
comunicao entre projetos;
Encontrar solues de ferramentas que suportem plataformas
heterogneas da organizao (quando houver);
Encorajar o pessoal tcnico para freqentemente comunicarem suas necessidades de ferramentas gerncia superior.
Concluso
Os exemplos de solues possveis para os problemas de manuteno de software apresentados neste artigo, principalmente os
derivados da interpretao das recomendaes da norma, mostram como pode ser extenso e detalhadamente tratado o assunto.
35
D
s

Feedback
eu
edio
ta
Referncias Bibliogrficas
Andrews, J. H.; Lutfiyya, H. L. (2000) Experiences with a software maintenance project course, IEEE
Transactions on Software Engineering (TSE), v. 43, n. 4, p. 383-388.
Basili, V. (1990) Viewing Maintenance as Reuse-Oriented Software Development, IEEE Software,
v. 7, n. 1, p. 19-25.
Beck, K. (1999) Extreme Programming Explained, First Edition. Addison-Wesley.
Bennett, K. H.; Rajlich, V. T. (2000) Software maintenance and evolution: a roadmap, In: Conference
on The Future of Software Engineering, Limerick, Ireland, June.
Bennett, K. H.; Ramage, M.; Munro, M. (1999) Decision Model for Legacy Systems,IEEE Proceedings
on Software (TSE), v.146, n. 3, p. 153-159.
Bhatt, P.; Shroff, G.; Misra, A. K. (2004) Dynamics of software maintenance, ACM SIGSOFT Software
Engineering Notes, v. 29, n. 5, p. 1-5.
Bhatt, P.; Williams, K.; Shroff, G.; Misra, A. K. (2006) Influencing Factors in Outsourced Software
Maintenance, ACM SIGSOFT Software Engineering Notes, v. 31, n. 3, p. 1-6.
Blasi, P. J. (1999) Overview of ACM. Disponvel em: <http://www.acm.org/about_acm/ov.html>.
Acesso em: 09 mai. 2006.
De Lucia, A., Pompella, E., Stefanucci, S. (2004) Effort estimation for corrective software
maintenance. In: 14th International Conference on Software Engineering and Knowledge
Engineering, Ischia, Italy, July.
Dias, M. G. B. (2004) Uma experincia no ensino de manuteno de software, In: Workshop de
Manuteno de Software Moderna (WMSWM04), Braslia, DF, Brasil, Outubro.
Ferreira, A. P. L.; Battaiola, A. L.; Souza, F. F.; Tori, R. (2001) Proposta de Plano Pedaggico:
Bacharelado em Cincia da Computao, Sociedade Brasileira de Computao (SBC). Disponvel
em: <http://www.sbc.org.br/index.php?subject=39>.
Ghezzi, C.; Mandrioli, D. (2005) The Challenges of Software Engineering Education, In: 27th
International Conference on Software Engineering, Saint-Louis, Missouri, USA, May.
Hazzan, O.; Dubinsky, Y. (2003) Teaching a Software Development Methodology: The case of
Extreme Programming, In: 16th Conference on Software Engineering Education and Training
(CSEE&T 2003), Madrid, Spain, March.
IEEE (1998) Std 1219 IEEE Standard for Software Maintenance, Institute of Electrical and
Eletronic Engineers, New York, NY, USA.
Boehm, B.; Basili, V. (2001) Software Defect Reduction Top 10 List, Computer, v. 34, n. 1.
ISO/IEC 12207 (1998) Standard for Information Technology - Software Lifecycle Processes,
International Standard Organization, New York, NY, USA.
Cardow, J.E. (1992) Can software maintenance be taught?, In: Conference on Software
Maintenance, Orlando, FL, USA, November.
ISO/IEC 12207 (2002) Standard for Information Technology - Software Lifecycle Processes/Amd.1,
Castro, J. F. B.; Gimenes, I. M. S.; Maldonado, J. C. (2000) Uma proposta de Plano Pedaggico para
a matria Engenharia de Software, In: II Curso de Qualidade de Cursos de Graduao da rea de
Computao e Informtica, Curitiba, PR, Brasil, Julho.
ISO/IEC 12207 (2004) Standard for Information Technology - Software Lifecycle Processes/Amd.2,
Chapin, N. (1986) Software maintenance: A different view, In: Conference on Software

Costa, C. M.; Audy, J. L. N.; Mazzucco, J.; Furtado, J. V. (2000) Plano Pedaggico para cursos de
Bacharelado em Sistemas de Informao, Sociedade Brasileira de Computao (SBC). Disponvel
em <http://www.sbc.org.br/index.php?subject=39>.
Dahmer, A.; Santos, B. S. dos; Ogiba, S.; Kist, T. (2002) Uma Proposta de Plano Pedaggico para o
Curso de Licenciatura em Computao, Sociedade Brasileira de Computao (SBC). Disponvel em:
<http://www.sbc.org.br/index.php?subject=39>.
Dart, S.; Christie, A. M.; Brown, A. W. (2001) A Case Study in Software Maintenance, Technical
Report, Carnegie Mellon University.
Dekleva, S. M. (1990)Annual Software Maintenance Survey: Survey Results,Software Maintenance
Association, Vallejo, California, USA.
________. (1992) Delphi study of software maintenance problems, In: Conference on Software
36
ISO/IEC 15504 (2003) Software Process Assessment, International Standard Organization, New
York, NY, USA.
Koskinen, J.; Salminen, A.; Paakki, J. (2004) Hypertext support for the information needs of
software maintainers, Journal of Software Maintenance and Evolution: Research and Practice, v.
16, n. 3 , p. 187-215.
Kung, H.; Hsu, C. (1998) Software Maintenance Life Cycle Model, In: International Conference on
Software Maintenance, Bethesda, Maryland, USA.
Lehman, M. M. (1974) Programs, Cities, Students, Limits to Growth?, In: Imperial College of Science
Technology, London, England, May.
________. (1980) On Understanding Laws, Evolution and Conservation in the Large Program
Life Cycle, Journal of Systems and Software (JSS), v. 1, n. 3, p. 213-221.
________. (1991) Software Engineering, the Software Process and their Support, IEEE
Software Engineering Journal: Special Issues on Software Environments and Factories, v. 1, n. 3,
p. 213-221.
sobre e
s
Nesse sentido, este artigo representa um documento de que

existem maneiras de se tratar os problemas de manuteno
de software, residindo na cultura organizacional o principal
entrave para se atacar de forma ampla as dificuldades. Certamente a formao acadmica de seus funcionrios, voltada para
a conscientizao da importncia da manuteno de software e
das alternativas de resposta aos seus problemas, levaria a uma
predisposio maior para a mudana organizacional.
M anuten o
Referncias Bibliogrficas
________. (1996) Laws of Software Evolution Revisited. In: 5th European Workshop on
Software Process Technology, Nancy, France, October.
Singh, R. (1996). International Standard ISO/IEC 12207 Software Life Cycle Processes, Software
Process Improvement and Practice, vol. 2, p. 3550.
Lientz, B. P.; Swanson, E. B. (1980) Software Maintenance Management, Reading, MA, AddisonWesley.
Sneed, H. M. (2003) Critical Success Factors in Software Maintenance, In: International Conference
on Software Maintenance, Amsterdam, The Netherlands, September.
Naur, P.; Randell, B. (1968) Software Engineering: Report, In: Conference of NATO Science
Committee, Garmisch, Germany, October.
Soares, M. dos S. (2005) Uma experincia no ensino de Engenharia de Software orientada a

trabalhos prticos, In: Workshop de Educao em Informtica (WEI2005), Rio de Janeiro, RJ, Brasil,
Novembro.
Niessink, F. (1999) Software Maintenance Research in the Mire?,In: Annual Workshop on Empirical
Studies of Software Maintenance (WESS99), Oxford, United Kingdom, September.
Nunes, J. D. (2005) Projetos de Planos Pedaggicos Orientados a Problemas, Biblioteca Digital da
SBC. Disponvel em << http://www.sbc.org.br/bibliotecadigital/download.php?paper=218>>.
Paduelli, M.; Sanches, R. (2006)Problemas em manuteno de software: caracterizao e evoluo,
In: III Workshop de Manuteno de Software Moderna, Vila Velha, ES, Brasil, Maio.
Pfleeger, S. L. (2001) Software Engineering: theory and practice. Second Edition, New Jersey,
Prentice Hall.
Pigoski, T. M. (1996) Practical Software Maintenance: Best Practices for Managing Your Software
Investment,Willey Computer Publishing.
Polo, M.; Piattini, M.; Ruiz, F.; Calero, C. (1999) Roles in the maintenance process, ACM SIGSOFT
Software Engineering Notes, v. 24, n. 4, p. 84-86.
Polo, M.; Piattini, M.; Ruiz, F. (2003) Using a qualitative research method for building a software
maintenance methodology, Software Practice and Experience, v.32, n. 13, p. 12391260.
Pressman, R. S. (2005) Software Engineering: a practitioners approach, 6.ed., McGrawHill Higher
Education.
Rodriguez, E. (2004). Overview of ACM / Education. Disponvel em: <http://www.acm.org/
about_acm/ov_edu.html>.
Shackelford, R.; Cross, J. H.; Davies, G.; Impagliazzo, J.; Kamali, R.; LeBlanc, R.; Lunt, B.; McGettrick, A.;
Sloan, R.; Topi, H. (2004) Computing Curricula 2004: A Guide to Undergraduate Degree Programs in
Computing, Joint Task Force for Computing Curricula 2004, The Association for Computing (ACM),
November.
Silva, L.; Sayo, M.; Leite, J. C. S. P.; Breitman, K. (2003) Enriquecendo o cdigo com cenrios, In:
Simpsio Brasileiro de Engenharia de Software (SBES), Manaus, AM, Brasil, Outubro.
Silva, L. de P.; Santander, V. F. A. (2004) Uma Anlise Crtica dos Desafios para Engenharia de
Requisitos em Manuteno de Software, In: Workshop em Engenharia de Requisitos, Tandil,
Argentina, Dezembro.
Sommerville, I. (2003) Engenharia de Software, 6.ed., So Paulo, Addison Wesley.

Souza, S. C. B. de; Neves, W. C. G. das; Anquetil, N.; Oliveira, K. M. de. (2004) Documentao Essencial
para Manuteno de Software II, In: I Workshop de Manuteno de Software Moderna, Braslia,
DF, Brasil, Outubro.
Stiller, E.; LeBlanc, C. (2002) Effective Software Engineering Pedagogy, Journal of Computing
Sciences in Colleges, v. 17, n. 6, p. 124-134.
SWEBOK (2004) The Institute of Electrical and Electronics Engineers, Inc IEEE, Guide to the
Software Engineering Body of Knowledge, Version 2004.
Teixeira, C. A. C.; Martins, J. S. B.; Prado, A. F.; Jnior, O. M.; Geyer, C. F. R.; Azeredo, P. A. (2002) Um
Plano Pedaggico de Referncia para Cursos de Engenharia de Computao, Sociedade Brasileira
de Computao (SBC). Disponvel em <http://www.sbc.org.br/index.php?subject=39>.
Tomayko, J. E. (1987) Teaching a Project-Intensive Introduction to Software Engineering,Technical
Report, Carnegie Mellon Institute.
Ulrich, W. M. (1990) The evolutionary growth of software reengineering and the decade ahead.
American Programmer, v. 3, n. 10, p. 14-20.
Visaggio, G. (2001)Assessing the Maintenance Process Through Replicated, Controlled Experiment.
Journal of Systems and Software, v. 44, n. 3, p. 187-197.
________. (2001) Ageing of a data-intensive legacy system: symptoms and remedies. Journal
of Software Maintenance and Evolution: Research and Practice, v. 13, n. 5, p. 281-308.
Zarifian, P. (2001) Objetivo competncia: por uma nova lgica. Traduo Maria Helena C. V.
Trylinski, So Paulo, Atlas.
Zvegintzov, N.; Parikh, G. (2005) 60 years of Software Maintenance: Lessons Learned, In: 21st IEEE
International Conference on Software Maintenance (ICSM 2005), Budapest, Hungary, September.
Yourdon, e. (1992) Anlise Estruturada Moderna, traduo da terceira edio, Rio de Janeiro,
Campus.
37
Desenvolvimento
Nesta seo voc encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software
Refatorao para Padres Parte 7

Implementando os padres State e Composite atravs das tcnicas de
refatoraes para padres
Aborda o tema refatorao para padres com o objetivo de mostrar como o desenvolvedor pode us-lo
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.

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, da Faculdade Metodista Granbery e da Universidade Severino
Sombra, professor do Curso Superior de
38
m algumas aplicaes comum

encontrar cdigo criado para
ser executado quando um objeto
muda de estado. Nestes casos, alguns
desenvolvedores acabam escrevendo
cdigo para executar de acordo com os
diferentes estados que um objeto pode
assumir. Um problema nestes casos
refere-se reutilizao dessas estruturas, que em alguns casos no possvel,
pois est espalhada pela aplicao. O
padro de projeto State apresentado
neste artigo como uma forma de concentrar cdigo de mudana de estados
em determinadas classes, o que ser
possvel graas utilizao da tcnica
de refatorao para padres Substituir
Condicionais que Alteram Estados por
State. Em outro cenrio, tem-se a criao
de cdigo utilizado para formar objetos
compostos, ou seja, objetos formados a
Engenharia de Software Magazine - Refatorao para Padres Parte 7
Para prover conhecimento ao desenvolvedor sobre

refatorao para padres e demonstrar atravs de
exemplos prticos a aplicao das tcnicas de refatorao para padres Substituir Condicionais que Alteram Estados por State e Substituir rvore Implcita
por Composite.

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.
partir de informaes provenientes de

outros objetos. Neste sentido, o problema
se encontra em cdigos muitas vezes
complexos, que so responsveis por
juntar tais informaes. Sendo assim, o
padro de projeto Composite, atravs da
utilizao da tcnica de refatorao para
Desen volvimento
padres Substituir rvore Implcita por Composite, permite a

definio de estruturas de cdigo para reduzir a complexidade
de tais estruturas ao implementar um Composite.
O processo de implementao dos padres de projeto State e
Composite, apoiado pela utilizao das tcnicas de refatorao
para padres Substituir Condicionais que Alteram Estados por
State e Substituir rvore Implcita por Composite requerem a
utilizao de algumas tcnicas de refatorao. Substituir Condicionais que Alteram Estados por State tem como pr requisito
o conhecimento da refatorao Extrair Subclasse, enquanto a
utilizao da tcnica de refatorao para padres Substituir
rvore Implcita por Composite tem como pr requisito o conhecimento das tcnicas de refatorao Extrair Classe, Extrair
SuperClasse e Extrair Interface (ver Nota do Devman 1).
A partir deste momento apresentada uma breve contextualizao sobre os padres de projeto State e Composite, padres
que este artigo trata (ver Nota do Devman 2). Posteriormente
sero apresentadas as tcnicas de refatorao que ainda no
foram apresentadas nos artigos anteriores, antes de iniciar
o processo de apresentao das tcnicas de refatorao para
padres.
O padro de projeto State

Nome do padro de projeto: State. Pertence ao conjunto dos padres de projeto classificados como Padres
Comportamentais.
O problema: No desenvolvimento de aplicaes, comum
encontrar cdigo escrito com objetivo de executar operaes,
baseando-se no estado que um objeto se encontra. Neste
contexto, alguns desenvolvedores muita vezes definem estruturas condicionais que ficaro responsveis por definir qual
operao realizar, dado o estado de um determinado objeto.
O padro de projeto State permite que o desenvolvedor defina
uma estrutura de classes que ficaro responsveis por manter
o cdigo que define as operaes que sero realizadas a cada
mudana de estado de um objeto.
As consequncias: Com a implementao deste padro
de projeto tem-se uma estrutura que define bem os tipos de
comportamentos que um objeto poder assumir mediante seu
estado atual. Esta estrutura torna mais simples a implementao de novas operaes para outros possveis estados que um
objeto possa vir a ter.
O padro de projeto Composite

Nome do padro de projeto: Composite. Pertence ao conjunto dos padres de projeto classificados como Padres
Estruturais.
O problema: Em aplicaes orientadas a objetos, possvel
instanciar objetos de diversas formas. Uma delas criando
objetos que, para sua instanciao, so necessrias informaes
contidas, algumas das vezes, em outros objetos.
Alguns desenvolvedores costumam delegar esta tarefa de
instanciao de objetos compostos ao cliente da aplicao,
mas esta prtica faz com que a complexidade do cdigo cliente
aumente.
Nota do DevMan 1
Refatoraes apresentadas em outros artigos
As tcnicas de refatorao Extrair Subclasse e Extrair Interface j foram apresentadas em outras edies da Engenharia de Software Magazine, mais precisamente
nas edies de nmero 30 e 33.
Nota do DevMan 2
Relembrando conceitos
Uma breve descrio do padro de projeto Composite foi apresentada no artigo
da edio de nmero 30 da Engenharia de Software Magazine. Neste artigo tais
conceitos sero relembrados para facilitar o entendimento da tcnica de refatorao para padres Substituir rvore Implcita por Composite.
As consequncias: A definio do padro Composite facilita este trabalho, uma vez que fornece uma soluo para a
criao de uma estrutura hierrquica que permita a instanciao de objetos compostos, fazendo com que este processo
fique oculto ao cliente da aplicao. Com isso, tem-se um
cdigo cliente mais simples, e um projeto de cdigo mais
bem definido, pois o trabalho de instanciao de objetos
compostos fica com a hierarquia de classes, e no ao cdigo
cliente da aplicao.
A refatorao Extrair Classe

Esta refatorao pertence ao grupo de refatoraes classificadas como Movendo Recursos entre Objetos.
Nome da refatorao: Extrair Classe.
Resumo: Classes com dupla responsabilidade devem ser
divididas em duas ou mais, dependendo da natureza das
responsabilidades.
Motivao: Em gesto da manuteno so descritos vrios
tipos de manuteno, entre elas a que permite que novas funcionalidades sejam acrescentadas ao sistema. Neste contexto,
geralmente acrescentar novas funcionalidades requer que cdigo novo seja escrito em determinadas classes. Alguns desenvolvedores, porm, acabam implementando funcionalidades em
uma classe que no condizem com as suas responsabilidades,
o que aumenta a complexidade da classe, reduz a coeso e
diminui a manutenibilidade. Isso ocorre porque muitas vezes
a classe que naturalmente deveria receber a nova funcionalidade no existe e, ao invs de cri-la, o desenvolvedor acaba
implementando em outra classe existente.
Mecnica:
Analisando uma classe com excesso de responsabilidades,
v-se qual a melhor diviso possvel, pensando em quais
classes precisam ser criadas.
Cria-se a classe, ou as classes necessrias.
Movem-se as responsabilidades de uma classe para outra,
usando a refatorao Mover Mtodo.
39
Listagem 1. Classe Cliente.
01. public class Cliente

02. {
03. private String nome;
04. private String cPF;
05. private String cep;
06. private String telefone;
07. private String salario;
08. private UInt32 limiteCreditoCliente;
09. ...
10. public Cliente CriarCliente(ArrayList dadosRecebidos)
11. {
12.
Cliente objCliente = new Cliente();
13.
objCliente.Nome = Convert.ToString(dadosRecebidos[0]);
14.
objCliente.CPF = Convert.ToString(dadosRecebidos[1]);
15.
objCliente.Cep = Convert.ToString(dadosRecebidos[2]);
16.
objCliente.Telefone = Convert.ToString(dadosRecebidos[3]);
17.
objCliente.Salario = Convert.ToString(dadosRecebidos[4]);
18.
objCliente.LimiteCreditoCliente = Convert.ToUInt32
(dadosRecebidos[5]);
19.
return objCliente;
20. }
21. public UInt32 CalcularLimiteCredito(UInt32 salario)
22. {
23.
UInt32 limiteCredito = 0;
24.
if (salario < 500)
25.
{
26.
limiteCredito = ((salario / 100) * 10);
27.
}
28.
else if (salario >= 500 && salario < 1000)
29.
{
30.
31.
}
32.
else if (salario >= 1000)
33.
{
34.
35.
}
36.
return limiteCredito;
37. }
38. }
Listagem 2. Classe Funcionario.
01. public class Funcionario

02. {
08. private String cargoFuncionario;
09.
10. public Funcionario CriarFuncionario(ArrayList dadosRecebidos)
11. {
12.
Funcionario objFuncionario = new Funcionario();
13.
objFuncionario.Nome = Convert.ToString(dadosRecebidos[0]);
14.
objFuncionario.CPF = Convert.ToString(dadosRecebidos[1]);
15.
objFuncionario.Cep = Convert.ToString(dadosRecebidos[2]);
16.
objFuncionario.Telefone = Convert.ToString(dadosRecebidos[3]);
17.
objFuncionario.CargoFuncionario = Convert.ToString
18.
return objFuncionario;
19. }
20. }
40
Estabelea as associaes corretas com a classe criada.

Execute testes.
A refatorao Extrair Superclasse

Esta refatorao pertence ao grupo de refatoraes classificadas como Lidando com Generalizao.
Nome da refatorao: Extrair Superclasse.
Resumo: Algumas classes possuem caractersticas em comum, sejam atributos ou mtodos. Cria-se uma superclasse
que receber todas as caractersticas em comum s classes.
Motivao: Reduz o cdigo duplicado ao centralizar informaes que podero ser consultadas em um nico lugar ao invs de
vrios, o que diminui a manutenibilidade do cdigo fonte.
Mecnica:
Cria-se uma classe abstrata e modificam-se as classes que
contm caractersticas em comum para se tornarem subclasses
da classe criada.
Aplicam-se nas subclasses as refatoraes Subir Campo na
Hierarquia e Subir Mtodo na Hierarquia. Elas permitiro
que o cdigo em comum das subclasses seja levado para a
superclasse.
Analisando os mtodos que restaram nas subclasses, caso
haja cdigo em comum entre eles, aplica-se a refatorao
Extrair Mtodo e a refatorao Subir Mtodo na Hierarquia
novamente, no cdigo em comum depois da extrao. Ainda
h o recurso de usar a refatorao Criar Mtodo Padro para
mover o mtodo padro para a superclasse.
Fazem-se os ajustes necessrios nas chamadas s
subclasses.
Executam-se os testes necessrios.
Exemplo: As Listagens 1 e 2 mostram as classes Cliente e
Funcionario.
A classe Funcionario possui uma srie de atributos que so
usados pelo mtodo de criao de objetos CriarFuncionario.
Analisando-se a classe Cliente, pode-se perceber que h vrios
atributos que so idnticos aos da classe Funcionario. Isso
caracteriza que deve ser criada uma superclasse para receber
esses atributos em comum. Cria-se a superclasse abstrata, neste
caso, com o nome Pessoa e move-se os atributos em comum
da classe Cliente e Funcionario para ela, e define-se as classes
Cliente e Funcionario como subclasses da classe Pessoa. O
resultado pode ser visto na Listagem 3.
Deve-se cuidar para que os mtodos get e set tambm sejam
movidos para a superclasse. Aqui neste exemplo, o cdigo
oculto representado por reticncias se refere a eles.
As classes Funcionario e Cliente agora s possuem comportamento especficos de cada uma delas, mas caso houvessem
mtodos com comportamento semelhante nas duas, aplicaria
a refatorao Criar Mtodo Padro para resolver o problema.
As Listagens 4 e 5 mostram como ficaram as classes Cliente e
Funcionario depois da refatorao.
Aps a apresentao dos padres de projeto State e Composite,
bem como a apresentao das tcnicas de refatorao Extrair
Classe e Extrair Superclasse, sero apresentadas agora as
Desen volvimento
tcnicas de refatorao para padres Substituir Condicionais

que Alteram Estados por State e Substituir rvore Implcita
por Composite.
Substituir Condicionais que Alteram Estados por State

Resumo: Existe uma complexa expresso condicional responsvel pela mudana de estados de um objeto. Substitui-se
tal lgica por classes State.
Motivao: Algumas classes apresentam complexas estruturas que so utilizadas para determinar como um objeto muda
de estado. O padro de projeto State atua neste sentido, fornecendo um mecanismo para tratar a mudana de estado dos
objetos. Esta refatorao para padres, por sua vez, fornece os
mecanismos necessrios para implementao de tal padro.
Vantagens: Permite uma reduo da lgica condicional que
determina mudana de estados dos objetos; Simplifica estruturas responsveis por fornecer o mecanismo de mudana de
estados; Aumenta a legibilidade no sentido de permitir uma
melhor visualizao de como ocorre a mudana de estado de
um objeto.
Desvantagens: Se a lgica condicional usada para determinar
o estado dos objetos j for simples de ser entendida, o padro de
projetos State pode complicar o projeto de cdigo existente.
Mecnica: Os passos descritos para esta mecnica dependem
do conhecimento prvio de outra tcnica de refatorao para
padres, Substituir Cdigo de Tipo por Classe.
1. Analisando a classe que possui um atributo responsvel
por receber ou se comparar a outros valores, aplicando a refatorao para padres Substituir Cdigo de Tipo por Classe,
substitui-se o atributo por um objeto da classe criada, como
nome State. A classe State criada ser a superclasse da hierarquia de estados.
2. Aplicando Extrair Subclasse, obtm-se uma subclasse para
cada estado que deva ser criado. Defini-se a superclasse da
hierarquia de estados como abstrata.
3. O mtodo que possui o atributo citado no passo 1 deve ser
copiado para a superclasse da hierarquia de estados. Posteriormente, ele dever ser adaptado ao seu novo local. O mtodo
original deve ter seu contedo substitudo por um esquema
que faa com que ele delegue a sua cpia da hierarquia de
estados. O mesmo deve ser feito com outros mtodos que
modificam o atributo, caso existam.
4. Analisando os estados que o mtodo copiado para a superclasse da hierarquia de estados pode assumir, definem-se
mtodos nas subclasses correspondentes ao seu estado.
5. Ajuste o esquema de polimorfismo que permitir que os
mtodos das subclasses sejam acessados atravs da declarao
na superclasse.
Exemplo: O exemplo que ser utilizado o mesmo da refatorao para padres Substituir Cdigo de Tipo por Classe, mas
agora com outro foco, que o de mover os mtodos de estados
para cada subclasse na hierarquia de estados que ser criada. A
classe StatusAcesso que foi utilizada em Substituir Cdigo de
Tipo por Classe, depois de refatorada, passou a utilizar tambm
Listagem 3. Superclasse abstrata Pessoa.
01. public abstract class Pessoa

02. {
08.
09. public Pessoa()
10. {
11. }
12. }
Listagem 4. Classe Cliente.
01. public class Cliente: Pessoa

02. {
03. private UInt32 limiteCreditoCliente;
04.
05. public Cliente()
06. {
07. }
08. public Cliente CriarCliente(ArrayList dadosRecebidos)
09. {
10.
Cliente objCliente = new Cliente();
11.
objCliente.Nome = Convert.ToString(dadosRecebidos[0]);
12.
objCliente.CPF = Convert.ToString(dadosRecebidos[1]);
13.
objCliente.Cep = Convert.ToString(dadosRecebidos[2]);
14.
objCliente.Telefone = Convert.ToString(dadosRecebidos[3]);
15.
objCliente.Salario = Convert.ToString(dadosRecebidos[4]);
16.
objCliente.LimiteCreditoCliente = Convert.ToUInt32
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36. }
return objCliente;
}
public UInt32 CalcularLimiteCredito(UInt32 salario)
{
UInt32 limiteCredito = 0;
if (salario < 500)
{
}
else if (salario >= 500 && salario < 1000)
{
}
else if (salario >= 1000)
{
}
return limiteCredito;
}
Listagem 5. Classe Funcionario.
01. public class Funcionario: Pessoa

02. {
03. private String cargoFuncionario;
04.
05. public Funcionario()
06. {
07. }
08. public Funcionario CriarFuncionario(ArrayList dadosRecebidos)
09. {
10. Funcionario objFuncionario = new Funcionario();
11. objFuncionario.Nome = Convert.ToString(dadosRecebidos[0]);
12. objFuncionario.CPF = Convert.ToString(dadosRecebidos[1]);
13. objFuncionario.Cep = Convert.ToString(dadosRecebidos[2]);
14. objFuncionario.Telefone = Convert.ToString(dadosRecebidos[3]);
15. objFuncionario.CargoFuncionario = Convert.ToString
16. return objFuncionario;
17. }
18. }
41
Listagem 6. Classe StateAberto.
01. public class StateAberto : State

02. {
03. }
Listagem 7. Classe StateFechado.
01. public class StateFechado : State

02. {
03. }
Listagem 8. Classe StateOcioso.
01. public class StateOcioso : State

02. {
03. }
Listagem 9. Classe StateBloqueado.
01. public class StateBloqueado: State

02. {
03. }
Listagem 10. Classe State.
01. public abstract class State

02. {
03. }
Listagem 11. Classe State.

02. {
03. private Boolean estado;
04. private Acesso objAcessoSeguro;
05. private readonly String Aberto = Aberto;
06. private readonly String Fechado = Fechado;
07. private readonly String Ocioso = Ocioso;
08. private readonly String Bloqueado = Bloqueado;
09. ...
10. public String VerificarAcesso()
11. {
12. if (obterAcesso().Equals(Aberto))
13. {
14.
estado = false;
15.
AlterarAcesso(Acesso.Fechado);
16. }
17. else if (obterAcesso().Equals(Fechado))
18. {
19.
estado = true;
20.
AlterarAcesso(Acesso.Aberto);
21. }
22. else if (obterAcesso().Equals(Ocioso))
23. {
24.
estado = true;
25.
26. }
27. else if (obterAcesso().Equals(Bloqueado))
28. {
29.
estado = true;
30.
31. }
32. return objAcessoSeguro.nome;
33. }
34. }
Listagem 12. Classe StatusAcesso.
01. public class StatusAcesso

02. {
03. private State state;
04. public String VerificarAcesso()
05. {
06. return state.VerificarAcesso();
07. }
08. }
42
a classe Acesso. J que a classe Acesso no poder ser modificada

para abstrata, cria-se uma superclasse com o nome de State. O
passo 2 envolve a criao das subclasses, cada uma com um
objetivo que o de carregar a sua parte na lgica de mudana
de estados (descoberta ao analisar o mtodo VerificarAcesso,
classe StatusAcesso). As Listagens 6, 7, 8, 9 e 10 mostram as
subclasses criadas e a superclasse State.
O passo 3 indica que o mtodo VerificarAcesso, classe StatusAcesso (ver refatorao para padres Substituir Cdigo de tipo
por Classe) deve ser copiado para a classe State, bem como todo
cdigo necessrio para seu funcionamento, e depois modifica-se
o mtodo da classe StatusAcesso para delegar ao mtodo copiado
para State. As mudanas so ilustradas nas Listagens 11 e 12.
Agora se devem definir os mtodos nas subclasses conforme
sua funo, movendo para eles a parte lgica correspondente
sua funo no mtodo VerificarAcesso, Listagem 11. Aps
essas mudanas, o mtodo VerificarAcesso dever ser modificado para abstrato, sendo implementado nas subclasses. As
Listagens 13, 14, 15, 16 e 17 mostram essas mudanas, o que
conclui esta refatorao para o padro State.
Substituir rvore implcita por Composite

Resumo: Em algumas classes encontrada, por exemplo,
uma string que utilizada na representao de uma estrutura
de rvore implcita. Substitui-se esta representao por um
Composite.
Motivao: O uso desta tcnica traz alguns benefcios que
podem ser apontados como parte fundamental na motivao
desta tcnica. Um composite pode, neste sentido, permitir a
criao de uma soluo mais simples, onde cdigo duplicado
deixar de existir em alguns pontos, quando se remove rvores
implcitas levando o cdigo para um Composite.
Vantagens: Permite que cdigo que se repete em vrios pontos pela aplicao seja encapsulado pelo composite; Encapsula
cdigo similar e fornece uma forma de acesso global; Torna
mais simples o trabalho do desenvolvedor quando vai definir
o que o cdigo cliente far e como far sua tarefa.
Desvantagens: Aumenta a complexidade do projeto quando
a utilizao de arvores no to intensa.
Mecnica: Folhas implcitas so partes da rvore que podem ser consideradas como folhas ou filhas de um pai, ou
seja, partes da rvore implcita que so precedidas de outras
partes (dependentes). Para aplicar este padro, seguem-se os
seguintes passos:
1. Utilizando a refatorao Extrair Classe, criam-se classes
correspondentes s folhas implcitas encontradas na rvore.
2. As folhas encontradas devem ser substitudas por instncias
de sua classe correspondente, criada no passo 1.
3. O passo 3 sugere a repetio dos passos 1 e 2, at que no
haja mais folhas implcitas a serem substitudas. Para isso,
talvez seja necessria a utilizao das refatoraes Extrair
Superclasse ou Extrair Interface.
4. Cria-se uma classe pai que ser a classe responsvel por
receber as instncias das classes criadas para as folhas, armazenando-as atravs de mtodos, definindo assim a composio.
Desen volvimento
Listagem 13. Superclasse State.

02. {
03. protected Boolean estado;
04. protected Acesso objAcessoSeguro;
05. private readonly String Aberto = Aberto;
06. private readonly String Fechado = Fechado;
07. private readonly String Ocioso = Ocioso;
08. private readonly String Bloqueado = Bloqueado;
09. private String obterAcesso()
10. {
11.
return objAcessoSeguro.nome;
12. }
13. protected void AlterarAcesso(Acesso objAcesso)
14. {
15.
this.objAcessoSeguro = objAcesso;
16. }
17. public abstract String VerificarAcesso();
18. }
Listagem 14. Subclasse StateAberto.
01. public class StateAberto: State

02. {
03. public override String VerificarAcesso()
04. {
05. estado = false;
06. AlterarAcesso(Acesso.Fechado);
08. }
09. }
Listagem 15. Subclasse StateFechado.
01. public class StateFechado: State

02. {
04. {
05. estado = true;
06. AlterarAcesso(Acesso.Aberto);
08. }
09. }
Listagem 16. Subclasse StateOcioso.
01. public class StateOcioso: State

02. {
04. {
05. estado = true;
06. AlterarAcesso(Acesso.Aberto);
08. }
09. }
Trocam-se as referncias ao cdigo pai por instncias da classe

definida.
5. Repetem-se os passos 4 e 5 enquanto houver necessidade
de criar classes pai.
Exemplo: O exemplo que ser utilizado mostra uma classe
que possui um mtodo responsvel por criar um layout de
HTML para ser impresso na tela. A Listagem 18 mostra a
classe em questo.
Analisando o corpo do mtodo Gerar, percebe-se uma rvore
implcita, onde o pai, ou n principal, est nas linhas 8 e 18, enquanto as folhas, ou ns filhos, podem ser vistos nas linhas 10 a 12
e 14 a 16. Encontrado o n pai e os seus respectivos filhos, hora de
aplicar o passo 1, que implica na criao de classes para modelar
os filhos. As Listagens 19, 20 e 21 mostram o resultado.
Resta neste momento mover o cdigo pertencente s folhas
para suas respectivas classes, bem como ajustar a classe pai
para receber instncias dessa classe, o que far dela um composite, cuja sua instncia ser o resultado que o mtodo Gerar,
Listagem 18, provia inicialmente. Os resultados podem ser
vistos nas Listagens 22, 23, 24 e 25, finalizando esta refatorao
para o padro Composite.
Listagem 18. Classe GerarLayout.
01. public class GerarLayout

02. {
03. private String layoutPadrao;
04.
05. public String Gerar()
06. {
07. String quebra = \n;
08. LayoutPadrao = <html xmlns=http://www.w3.org/1999/xhtml >;
09. LayoutPadrao += quebra;
10. LayoutPadrao += <head id=Head1 runat=server>;
11. LayoutPadrao += quebra + quebra;
12. LayoutPadrao += </head>;
13. LayoutPadrao += quebra ;
14. LayoutPadrao += <body>;
16. LayoutPadrao += </body>;
18. LayoutPadrao += </html>;
19. return LayoutPadrao;
20. }
21. }
Listagem 19. Classe NoPrincipal.
01. public class NoPrincipal

02. {
03. }
Listagem 17. Subclasse StateBloqueado.
01. public class StateBloqueado: State

02. {
04. {
05.
estado = true;
06.
07.
return objAcessoSeguro.nome;
08. }
09. }
Listagem 20. Classe NoCabecalho.
01. public class NoCabecalho

02. {
03. }
Listagem 21. Classe NoCorpo.
01. public class NoCorpo

02. {
03. }
43
Listagem 22. Classe GerarLayout.
Listagem 24. Classe NoCabecalho.
01. public class GerarLayout

02. {
03. private String layoutPadrao;
04.
05. public String Gerar()
06. {
07. String quebra = \n;
08. NoPrincipal layout = new NoPrincipal();
09.
this.LayoutPadrao = layout.GerarLayoutCompleto(quebra, LayoutPadrao);
10. return this.LayoutPadrao;
11. }
12. }
01. public class NoCabecalho

02. {
03. public String Cabecalho(String quebra, String LayoutPadrao)
04. {
05. LayoutPadrao += <head id=Head1 runat=server>;
07. LayoutPadrao += </head>;
10. }
11. }
Listagem 23. Classe NoPrincipal.
Listagem 25. Classe NoCorpo.
01. public class NoPrincipal

02. {
03. public String GerarLayoutCompleto(String quebra, String LayoutPadrao)
04. {
05. NoCabecalho cabecalho = new NoCabecalho();
06. NoCorpo corpo = new NoCorpo();
07. LayoutPadrao = <html xmlns=http://www.w3.org/1999/xhtml >;
09. LayoutPadrao = cabecalho.Cabecalho(quebra, LayoutPadrao);
10. LayoutPadrao = corpo.Corpo(quebra, LayoutPadrao);
11. LayoutPadrao += </html>;
13. }
14. }
01. public class NoCorpo

02. {
03. public String Corpo(String quebra, String LayoutPadrao)
04. {
05. LayoutPadrao += <body>;
07. LayoutPadrao += </body>;
10. }
11. }
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.
44
Feedback
eu
sobre e
s

D
s
Um dos grandes objetivos da implementao dos padres de

projeto a criao de estruturas que facilitam a reutilizao
de cdigo. A definio dos padres de projeto State e Composite
neste artigo, alm de outros benefcios, permitem melhorias
no projeto de cdigo existente, o que pode contribuir para
manutenes futuras.
edio
ta
Concluso
Desen volvimento
45
Desenvolvimento
Nesta seo voc encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software
Tratamento de excees
Tratando excees no desenvolvimento de software com Java

Utilizao de mecanismos que permitem o tratamento de excees no desenvolvimento de software na linguagem Java. Uma abordagem prtica est
sendo apresentada para ilustrar tais mecanismos.
Jacimar Fernandes Tavares

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

- Faculdade Governador Ozanam Coelho,
Microsoft Student Partners.

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, da Faculdade Metodista Granbery e da Universidade Severino
Sombra, professor do Curso Superior de
ARTIGO EXTRA!
Este artigo estaria disponibilizado integralmente
apenas no leitor digital.
46
processo de desenvolvimento
de uma aplicao pode contar
com vrias etapas, alm da
etapa de implementao. Uma etapa
que se torna indispensvel no processo
de desenvolvimento de uma aplicao
aquela onde se realizam testes na tentativa de eliminar as chances de um erro
ocorrer quando esta aplicao j estiver
em produo.
Neste contexto, temos que um problema comum a vrios usurios est ligado
ao fato da indevida insero de dados
no software. Entradas no esperadas
pelo sistema podem ocasionar erros
na execuo da aplicao, fazendo com
que a mesma venha at mesmo a ser
encerrada.
Os mecanismos de tratamentos de
excees (ler Nota do DevMan 1) que
as linguagens de programao possuem permitem que o desenvolvedor
Engenharia de Software Magazine - Tratamento de excees
Para que serve?

Apresentar como levantar e tratar excees lanadas durante a execuo de um programa, evitando
problemas na execuo das aplicaes como comportamentos inesperados que pode levar ao encerramento da aplicao.

O tema se torna fundamental, no ponto de vista
de uma empresa com uma poltica de testes,
para identificar potenciais problemas no previstos pelos desenvolvedores. Em empresas sem
poltica de testes, este artigo pode ajudar desenvolvedores a identificar e prevenir possveis
falhas no produto final, evitando gastos com
manuteno.
implemente estruturas que sero invocadas quando algo de errado ocorrer

na execuo da aplicao, permitindo
assim que ela continue executando,
recuperando-se do erro.
Desen volvimento
Neste artigo so abordados os tipos de erros que podem

surgir durante o processo de desenvolvimento de uma aplicao ou depois de concluda a etapa de desenvolvimento, o
que permitir ao desenvolvedor uma melhor compreenso
sobre os tipos de erros que podem originar excees na execuo do software. Tambm so abordadas as vantagens de
lanar excees, ao invs de trat-las na prpria classe onde
aconteceu o problema, e as estruturas de cdigo que permitem
ao desenvolvedor criar mecanismos para levantar excees
em softwares desenvolvidos na linguagem Java. Com este
artigo o desenvolvedor ser capaz de criar mecanismos para
levantamento de excees em pontos propcios a ocorrncia
das mesmas.
Viso geral sobre os tipos de erros em uma aplicao

A partir deste momento so apresentados os tipos de erros a
que uma aplicao est sujeita. Conhecer os tipos pode ajudar
o desenvolvedor na tarefa de trat-los, reduzindo as chances
da aplicao desenvolvida ser entregue para o cliente que
posteriormente poder identific-los.
Os tipos de erros so classificados como erros de sintaxe, erros
de runtime (tempo de execuo) e erros de lgica. O primeiro
deles, erros de sintaxe, so os erros ocasionados por falhas
do desenvolvedor ao escrever as estruturas de cdigo em sua
aplicao. Erros de sintaxe so acusados pelo compilador durante a compilao do cdigo fonte, restando ao desenvolvedor
reescrever a estrutura que contm o erro de sintaxe de forma
correta e compilar a aplicao novamente.
Erros de runtime so os erros que acontecem durante a execuo da aplicao que resultam em comportamentos inesperados, mediante, por exemplo, as entradas invlidas por parte
do usurio ou recursos solicitados pelo software, mas que se
encontram indisponveis no momento da solicitao. As excees levantadas caracterizam erros em tempo de execuo.
J os erros de lgica so os erros provenientes de falhas
na lgica modelada para a aplicao, que pode resultar em
sadas diferentes das esperadas pelo usurio, devido lgica
do problema que foi construda de forma errada. Este tipo
de erro no acusado pelo compilador, o que dificulta sua
identificao. Neste caso, o que se deve fazer reescrever a
lgica implementada e verificar atravs de testes se os resultados obtidos condizem com a funo que o cdigo deve
desempenhar.
Viso geral sobre excees

Quando se implementa uma aplicao e no se definem
mecanismos para controlar a validade dos dados inseridos,
alguns dados podem provocar erros de runtime, pois representam que algo no saiu como esperado, no caso um fluxo
de exceo. Toda ao que representa um fluxo de exceo na
aplicao, ou seja, aes que no so descritas no fluxo principal de execuo, podem levantar uma exceo no software,
se no tratada. Para que excees no interrompam a execuo
da aplicao, o desenvolvedor deve definir mecanismos de
captura e tratamento de excees na aplicao.
Nota do DevMan 1
Tratamento de Excees
O tratamento de excees uma tcnica que deve ser considerada em qualquer plataforma. A maioria dos conceitos vistos neste artigo podem ser utilizados independente da
linguagem que esteja trabalhando e altamente recomendado que todos os desenvolvedores estejam conscientes disso para que as empresas tenham processos eficientes e
criem projetos dos quais possam reutilizar cdigo de tratamento de excees.
A hierarquia de classes de excees em Java, que juntamente

com estruturas de cdigo como os manipuladores de excees
Try, Catch e Finally, constituem o mecanismo de captura e tratamento de excees. As excees lanadas so objetos de uma
das subclasses de java.lang.Throwable que, por sua vez, possui
duas subclasses muito importantes para o levantamento de
excees, que so java.lang.Error e java.lang.Exception.
A primeira, java.lang.Error, a superclasse de uma hierarquia
de classes que levantam excees das quais no se deve criar
mecanismos para captura, pois as excees levantadas no devem ser tratadas. Um exemplo a subclasse java.lang.InternalError, que levanta excees relativas a erros internos aplicao
que a impedem de continuar executando. A classe java.lang.
Exception possui uma hierarquia de classes que levantam excees das quais o desenvolvedor poder criar manipuladores
para capturar e tratar as excees capturadas, no impedindo
que o software continue executando normalmente aps tratada
a exceo capturada. A classe java.io.FileNotFoundException
uma das suas subclasses, que permite a captura de excees
referentes a arquivos no encontrados no disco. Excees desta
classe no finalizam a execuo da aplicao, caso tratadas.
As vantagens de lanar excees

Cada desenvolvedor possui uma abordagem diferente para
restringir os tipos de dados que um usurio insere em uma
aplicao. Todos os dados inseridos devem estar de acordo com
os tipos que a aplicao espera. muito comum ver usurios
inserindo informaes erradas, e esta ao pode provocar
erros de runtime.
Um campo criado para receber um valor referente a uma
idade de uma pessoa deve ser do tipo inteiro e no negativo.
Neste contexto, inserir uma idade negativa, com casas decimais
ou com letras provocar um erro de execuo da aplicao.
Em outro cenrio pode-se ter a entrada de valores para a
realizao de uma operao matemtica. Caso a operao seja
de diviso, e o usurio tente realizar uma diviso por zero,
poder ocorrer outro erro de execuo.
Alguns desenvolvedores optam por escrever trechos de cdigo acoplados a interface que realizam a tarefa de verificar se
o dado inserido est dentro dos limites do que se esperado.
O problema neste caso que o cdigo criado no pode ser
reaproveitado, uma vez que toda verificao referente ao mesmo dado ter que ser reescrito acoplado outra interface que
47
necessite realizar a mesma verificao. Outra tcnica utilizada

mostrar uma mensagem de erro, referente entrada invlida
do usurio. Para essa ao, talvez o retorno de alguns mtodos
devam ser modificados, e isso pode tornar o cdigo mais difcil
de entender quando se analisam os mtodos existentes.
Os mecanismos de levantamento de excees permitem
ao desenvolvedor criar estruturas de cdigo responsveis
por capturar as excees levantadas durante a execuo da
aplicao, e trat-las de modo que a execuo da aplicao
no seja interrompida. Sendo assim, o desenvolvedor pode
definir classes responsveis por tratar as diversas excees
que podem vir a ocorrer em determinado ponto da aplicao.
Ao definir classes que capturam os mais diversos tipos de
excees, o desenvolvedor evita a duplicao de cdigo, pois
evita que o mesmo trecho utilizado para verificar as entradas
invlidas do usurio, ou outras verificaes, seja reescrito por
diversos pontos que necessitem da mesma verificao, dado
que o cdigo de tratamento de excees ficar disponvel em
uma determinada classe, e a exceo poder ser propagada
para uma das classes exception criada.
Com esses recursos pode-se separar o cdigo de tratamento
de excees do cdigo responsvel por implementar a lgica
do negcio. Em linguagens que no possuem mecanismos para
tratamento de excees pode-se encontrar grande quantidade
de cdigo para tratamento misturado a cdigo responsvel por
implementar a lgica da aplicao.
Estruturas utilizadas para levantar excees

Existem algumas estruturas de cdigo que so utilizadas para
o levantamento e tratamento de excees. A partir deste momento, sero apresentadas as estruturas e as diversas formas de
utiliz-las para tratar as excees capturadas. Para isso, alguns
exemplos de cdigo so utilizados, que se referem a alguns cenrios onde pode ocorrer algum tipo de exceo. Sendo assim,
ao decorrer da definio desses cenrios, vrias estruturas de
cdigo so mostradas com objetivo de ilustrar o processo de
Listagem 1. Manipulador Try.
01. try
02. {
03. //A execuo do programa tentar executar o corpo do bloco try
(entre chaves).
04. }
Listagem 2. Manipuladores Try/Catch.
01. try
02. {
03. //A execuo do programa tentar executar o corpo do bloco try
(entre chaves).
04. }
05. catch(/*Tipo de Exceo a ser capturada*/ )
06. {
07. /* Se a tentativa de execuo do bloco try no pode ser realizada,
uma exceo levantada pelo compilador, mas neste caso
capturada pelo bloco catch.
08. */
09. }
48
implementao de um mecanismo de tratamento de excees

em aplicativos Java, tornando visvel como trat-las em outras
classes, ao invs da classe onde o problema ocorreu.
Para capturar excees, o Java (e outras linguagens) utiliza
os manipuladores Try (tentar), Catch (capturar) e Finally (finalizar). Os blocos Try/Catch permitem ao desenvolvedor criar
fluxos principais com a garantia de que, se o bloco Try no for
executado, uma possvel soluo exista, ou seja, caso a tentativa de executar uma ao no possa ser concluda, pois uma
exceo foi levantada, o manipulador Catch ficar responsvel
por capturar a exceo. No manipulador Try o desenvolvedor
insere o cdigo dentro das chaves, para que durante a execuo
do programa haja uma tentativa de executar aquela ao. A
Listagem 1 mostra a sintaxe do manipulador Try.
Na Listagem 1, linha 1, podemos ver o comando try, seguido de duas chaves nas linhas 2 e 4. Se esta tentativa for bem
sucedida, o programa terminar com sucesso a ao iniciada.
Caso no consiga executar o corpo do bloco try, o compilador
levantar uma exceo. Essa exceo deve ser capturada por
um bloco catch, que permitir o tratamento desse erro de runtime, permitindo assim que a execuo do programa continue,
sem que seja abortado, como mostra a Listagem 2.
Assim como na Listagem 1, a linha 1 da Listagem 2 mostra
o comando try, seguido das chaves nas linhas 2 e 4. Um bloco
try deve obrigatoriamente vir seguido por um manipulador
catch, como podemos ver na linha 5. Este mesmo bloco try pode
ser seguido por vrios blocos catch, cada um com o objetivo de
capturar um determinado tipo de exceo.
Alm dos manipuladores Try/Catch apresentados, tem-se ainda
o manipulador Finally, responsvel por, aps a execuo de um
bloco try, finalizar o uso de algum recurso que est sendo utilizado. Como exemplo pode-se ter a utilizao de um arquivo.
Ao terminar sua utilizao, talvez seja interessante que o bloco
Finally encerre o seu uso, liberando o arquivo. importante
ressaltar que seu uso no obrigatrio. A Listagem 3 mostra a
sintaxe do manipulador finally, depois do manipulador catch.
Aps conhecidas as estruturas de cdigo que permitem a captura das excees, o prximo passo consiste em conhecer alguns
tipos de excees que podem ocorrer em aplicativos Java.
Um primeiro exemplo mostra uma simples aplicao, responsvel por receber dois nmeros, realizar uma diviso e
mostrar o resultado. Estas aes constituem o fluxo principal
de execuo. A Listagem 4 mostra o cdigo dessa aplicao.
Nas linhas 1 e 2 da Listagem 4, tem-se o cdigo responsvel
solicitar e armazenar os dados solicitados para o usurio, no
caso dois nmeros para realizar a diviso. Na linha 3 ocorre a
diviso e, na linha 4, possvel ver o comando que mostrar o
resultado obtido. Se tudo der certo, ou seja, se o usurio digitar
somente nmeros inteiros e no entrar com outro tipo de dado,
a operao ser realizada com sucesso, mas garantir que isso
ir realmente acontecer impossvel, portanto os comandos
das linhas 1, 2 e 3 podem no funcionar corretamente, isto ,
levantar excees.
Comeando a utilizar os mecanismos de captura e tratamento
de excees no cdigo da Listagem 4, tem-se uma estrutura de
Desen volvimento
cdigo como mostra a Listagem 5, que possibilita a captura de

uma exceo caso a entrada no seja um nmero inteiro.
O cdigo da Listagem 4, passvel de excees, est agora no
corpo do bloco try (Listagem 5). O manipulador Catch, linha 8
a 11 da Listagem 5, permite que se uma exceo levantada pela
classe java.lang.NumberFormatException for levantada, o aplicativo no aborte. Entradas como nmeros com casas decimais
ou letras levantam excees de formato invlido.
Continuando a trabalhar no cdigo da Listagem 5, ainda h
pontos que podem levantar excees. Um exemplo de outra exceo levantada pode ser vista caso haja uma tentativa de dividir
um nmero inteiro por zero. Realizar operaes de diviso por
zero tambm levanta uma nova exceo que deve ser capturada.
Tentar uma diviso por zero um erro matemtico que levanta
uma exceo que pode ser tratada atravs da classe java.lang.
ArithmeticException. O cdigo da Listagem 6 mostra o cdigo da
Listagem 5 aps receber o novo manipulador catch.
Uma das formas utilizadas pelos desenvolvedores para construir mecanismos de captura e tratamento de exceo, como j
foi mencionado neste artigo, definir as estruturas acopladas
s interfaces dos formulrios. O prximo exemplo exige a
criao de um aplicativo Java, chamado DivideDoisNumeros.
Neste caso est sendo utilizado o NetBeans 6.5.1.
Cria-se uma interface para o aplicativo, como a interface da
Figura 1.
O funcionamento do aplicativo simples. Realiza operaes
de diviso e mostra o resultado, como o exemplo que foi apresentado. A diferena consiste em criar um aplicativo onde a
exceo capturada possa ser utilizada para interagir com o
usurio. Alm disso, ser possvel ver como criar cdigo de
tratamento de excees que ficar acoplado interface, abordagem essa utilizada por alguns desenvolvedores.
O cdigo do projeto DivideDoisNumeros ser dividido em
trs mtodos. Um deles, chamado testeCampoNumero1()
testa os dados inseridos no primeiro JTextField, afim de verificar se nenhuma exceo ser lanada. Caso isto ocorra, o
jLabel1 mostrar a mensagem de erro da exceo capturada.
O mesmo feito para o campo JTextField2, atravs do mtodo
chamado testeCampoNumerico2(). O terceiro mtodo, DivideDoisNumeros(), ser executado Caso nenhuma exceo
seja capturada nos dois mtodos executados, restando a ele
primeiramente testar se no h a tentativa de diviso por
zero. Caso isto no ocorra, a diviso efetuada. A Listagem 7
Figura1. Interface aplicativo DivideDoisNumeros
Listagem 3. Manipuladores Try/Catch/Finally.
01. try
02. {
03.
//A execuo do programa tentar executar o corpo do bloco
try(entre chaves).
04. }
05. catch(/*Tipo de Exceo a ser capturada*/ )
06. {
07. /* Se a tentativa de execuo do bloco try no pode
ser realizada, uma exceo levantada pelo
compilador, mas neste caso capturada pelo
bloco catch.
08. */
09. }
10. finally
11. {
12.
/* Aqui fica o cdigo que finaliza a ao iniciada pelo try,
que pode ser a liberao dos recursos nele alocados.
13.
*/
14. }
Listagem 4. Aplicativo de diviso de nmeros.
01. int numero1 = Integer.parseInt(JOptionPane.showInputDialog

(null, Digite um numero: ));
02. int numero2 = Integer.parseInt(JOptionPane.showInputDialog
(null, Digite outro numero: ));
03. int resultado = numero1 / numero2;
04. JOptionPane.showMessageDialog(null, Resultado: + resultado);
01. try
02. {
03. int numero1 = Integer.parseInt(JOptionPane.howInputDialog
07. }
08. catch(NumberFormatException e)
09. {
10. JOptionPane.showMessageDialog(null, Insira Numeros);
11. }
01. try
02. {
03. int numero1 = Integer.parseInt(JOptionPaneshowInputDialog
07. }
09. {
10.
JOptionPane.showMessageDialog(null, Insira Numeros);
11. }
12. catch(ArithmeticException e)
13. {
14.
JOptionPane.showMessageDialog(null, Impossivel fazer diviso
com 0);
15. }
49
apresenta o cdigo do projeto DivideDoisNumeros, que est

acoplado interface criada no projeto (Figura 1).
Nas linhas 48 a 54 est o mtodo de evento do boto Calcular. Ao
inserir os dados e clicar em Calcular, um if verifica se os mtodos
testeCampoNumero1 e testeCampoNumero2 esto retornando
true, o que significa que no houveram excees levantadas.
O cdigo criado para o tratamento de excees no projeto
DivideDoisNumeros resolve o problema referente captura
Listagem 7. Cdigo acoplado ao formulrio do projeto.
01. int numero1;

02. int numero2;
03. int resultado;
04. boolean testeCampoNumero1()
05. {
06. try
07. {
08. numero1 = Integer.parseInt(jTextField1.getText());
09. return true;
10. }
12. {
13. jLabel1.setText(Entrada Invlida. Digite numero );
14. return false;
15. }
16. }
17. boolean testeCampoNumero2()
18. {
19. try
20. {
21. numero2 = Integer.parseInt(jTextField2.getText());
22. return true;
23. }
25. {
26. jLabel2.setText(Entrada Invlida. Digite numero .);
27. return false;
28. }
29. }
30. void DivideDoisNumeros()
31. {
32. try
33. {
34. resultado = numero1 / numero2;
35. jLabel3.setText(String.valueOf(resultado));
36. }
37. catch(ArithmeticException e)
38. {
39. jLabel3.setText(Impossivel fazer diviso com 0);
40. }
41. }
42. void setTextLabels()
43. {
44. jLabel1.setText();
47. }
48. private void jButton1ActionPerformed(java.awt.event.
ActionEvent evt) {
49. setTextLabels();
50. if(testeCampoNumero1() && testeCampoNumero2())
51. {
52. DivideDoisNumeros();
53. }
54. }
50
e tratamento das excees levantadas, no impedindo que o

software aborte. O problema que ele apresenta que, toda vez
que um novo formulrio for criado no projeto com caractersticas semelhantes, o cdigo dever ser duplicado para o outro
formulrio. Com isso no h reaproveitamento de cdigo, pois
o cdigo de negcio est misturado ao cdigo de interface e ao
cdigo de tratamento de excees.
Propagando excees para outras classes

Os exemplos vistos at este momento mostraram como utilizar os manipuladores de exceo, bem como definir estruturas
para trat-las. Neste momento ser apresentada uma segunda
alternativa para levantamento e tratamento de excees. Este
modelo permite que a exceo seja propagada para outra classe,
e l seja tratada, o que traz alguns benefcios como j foram
mencionados no incio deste artigo. Os prximos exemplos
mostram como capturar excees criadas e levantadas pelo
prprio desenvolvedor para determinadas situaes. Alm
dos manipuladores j conhecidos como try/catch e finally, o
desenvolvedor pode ainda contar com outros recursos para
levantar excees. A palavra reservada new permite que uma
nova exceo seja criada, enquanto throw permite que a exceo seja lanada. Existe ainda a palavra reservada throws que
se difere de throw por ser utilizada em mtodos que podem
levantar excees.
O prximo projeto, chamado Vendas, foi criado para ilustrar
a abordagem de propagar excees para outras classes, ao
invs de trat-las no local onde ocorreram. A Figura 2 mostra
o formulrio criado para o projeto.
O projeto Vendas tem como objetivo permitir o lanamento
das vendas a serem efetuadas. Para esta tarefa, o usurio
dever escolher qual produto est sendo vendido e qual a
quantidade desejada. Neste caso, o processo de realizar a
venda est limitado a verificar se a quantidade desejada do
produto est disponvel em estoque e concretizar a venda.
Caso a quantidade desejada no esteja disponvel, a venda
no poder ser efetuada. Isto implica em criar e levantar
uma nova exceo, para notificar que o produto no possui a
quantidade desejada.
Analisando a Figura 2, tem-se o formulrio criado para
permitir a realizao das vendas no sistema.
O primeiro passo na criao deste projeto definir as
classes Venda e Produto. A Listagem 8 mostra o cdigo da
Figura 2. Formulrio projeto Vendas
Desen volvimento
Listagem 8. Classe Venda.
01. public class Venda

02. {
03. public Venda()
04. {
05. }
06. public Boolean realizarVenda(String nomeProduto, int qtdProduto)
07. {
08.
Produto produtodavenda = new Produto();
09.
produtodavenda.setNomeProduto(nomeProduto);
10.
int qtdProdutoEmEstoque = produtodavenda.VerificaQTD
ProdutoEstoque();
11.
if(qtdProdutoEmEstoque < qtdProduto)
12.
{
13.
return false;
14.
}
15.
else
16.
{
17.
return true;
18.
}
19. }
20. }
Listagem 9. Classe Produto.
01. public class Produto

02. {
03. private String nomeProduto;
04. private int qtdProduto;
05. public String getNomeProduto() {
06. return nomeProduto;
07. }
08. public void setNomeProduto(String nomeProduto) {
09. this.nomeProduto = nomeProduto;
10. }
11. public int getQtdProduto() {
12. return qtdProduto;
13. }
14. public void setQtdProduto(int qtdProduto) {
15. this.qtdProduto = qtdProduto;
16. }
17. public Produto()
18. {
19. }
20. public int VerificaQTDProdutoEstoque()
21. {
22. ...
23. return qtdProdutoEmEstoque;
24. }
25. }
Listagem 10. Classe qtdProdutoInsuficienteException.
01. import javax.swing.JOptionPane;

02.
03. public class qtdProdutoInsuficienteException extends RuntimeException
04. {
05. public qtdProdutoInsuficienteException(String mensagemExcecao)
06. {
07. JOptionPane.showMessageDialog(null, mensagemExcecao);
08. }
09. }
classe venda, enquanto a Listagem 9 mostra o cdigo da

classe Produto.
A Classe Venda, Listagem 8, possui um mtodo chamado
realizarVenda, que ser invocado toda vez que houver uma
nova tentativa de realizar uma venda. Nas linhas 10 a 18
h uma chamada ao mtodo VerificaQTDProdutoEstoque,
da classe Produto, Listagem 9. Se o produto estiver disponvel na quantidade solicitada, o mtodo realizarVenda
retorna true.
O prximo passo implica em criar uma classe exception que
trate uma exceo levantada caso o produto no possua a
quantidade desejada, ou seja, caso o mtodo realizarVenda
no retorne true. A Listagem 10 mostra a classe qtdProdutoInsuficienteException, que estende de RuntimeException.
O mtodo construtor qtdProdutoInsuficienteException
recebe uma mensagem de erro como parmetro e exibe a exceo capturada em tempo de execuo. Agora resta escrever
o cdigo cliente que tentar realizar uma venda ao invocar
o mtodo realizarVenda, Listagem 8. Caso no seja possvel
realizar a venda, uma exceo dever ser criada, com o uso
da palavra reservada new e levantada com throw, como pode
ser visto na Listagem 11.
O cdigo da Listagem 11 est escrito no evento onclick do
boto Efetuar Venda (Figura 2). Caso a venda seja efetuada
com sucesso, uma mensagem exibida para o usurio do
sistema como forma de interao.
Os benefcios da abordagem de captura e tratamento de
excees utilizada no projeto Vendas, em relao ao projeto anterior DivideDoisNumeros, est ligado ao fato de
poder reutilizar cdigo. No projeto DivideDoisNumeros
o cdigo de tratamento de excees se mistura ao cdigo
cliente e ao cdigo de negcio. J no projeto Vendas, ficou
claro que o cdigo ficou dividido de forma a permitir a
reutilizao ao se definir as classes Venda e Produto, que
so as classes que contm o cdigo de negcio e definir
a classe qtdProdutoInsuficienteException que contm o
cdigo de tratamento de excees. Assim, caso aparea
a necessidade de, em outro ponto do projeto Vendas,
haver uma verificao referente quantidade de produtos em estoque, no ser necessrio duplicar cdigo de
Listagem 11. Cdigo cliente que tenta realizar uma venda.
01. private void jButton1ActionPerformed(java.awt.event.

ActionEvent evt) {
02. Venda venda = new Venda();
03. if(venda.realizarVenda(list1.getItem(busyIconIndex),
Integer.parseInt(jTextField1.getText())))
04. {
05.
JOptionPane.showMessageDialog(null, Venda Efetuada
com Sucesso);
06. }
07. else
08. {
09.
throw new qtdProdutoInsuficienteException(Quantidade do
Produto indisponvel no estoque);
10. }
11. }
51
52

Feedback
eu
sobre e
s
Neste artigo foram abordados vrios conceitos e tcnicas que

devem fazer parte do dia-a-dia de todos os desenvolvedores.
Uma empresa consciente da necessidade de ter profissionais
munidos desses conceitos e interados desses processos pode
alcanar um bom rendimento. Todas as tcnicas e recursos
aqui abordados podem contribuir para o sucesso de vrios
projetos que a empresa est trabalhando, ao evitar diversas
falhas no sistema. Cada vez mais o mercado exige softwares
com qualidade e que sejam capazes de se recuperar de erros
e ao mesmo tempo interagir com o usurio, ao mostrar mensagens referentes s excees capturadas, possibilitando uma
melhor utilizao do produto desenvolvido.
DEITEL, H. M, 2005. Java: Como programar, 6ed. So Paulo: Pearson Prentice Hall, 2005.
D
s
Concluso
Referncias
edio
ta
tratamento de excees, pois ele j est concentrado na classe

qtdProdutoInsuficienteException.
Desen volvimento
53

Edição34 2011

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Edição34 2011

Transféré par

Droits d'auteur :

Formats disponibles

Modstia parte, sua

melhor opo para

EDUCAO SUPERIOR ORIENTADA AO MERCADO

Engenharia de Software Magazine destaca como tema de capa desta

de explicar como os testes esto sendo executados em projetos na atualidade. O

necessrio pensar nesta integrao quando planejamos a sprint e os testes em si.

as estrias at o ponto em que comeamos a execut-los , sem dvida, essencial

tambm esto interessados em aprender sobre programao, (5) Interao de

Alm desta matria, esta edio traz mais cinco artigos:

Desenvolvimento de Software Apoiado por Groupware

Refatorao para Padres Parte 7

Rodrigo Oliveira Spnola

Marco Antnio Pereira Arajo

Fale com o Editor!

Se voc estiver interessado em publicar um artigo na revista ou no site SQL Magazine,

Eduardo Oliveira Spnola

Para esta edio, temos um conjunto de 5 vdeo aulas.

08 - Seus testes so geis?

21 - Alternativas para reduo de problemas na manuteno de software

Edio 05 - Engenharia de Software Magazine

Pos trs do bvio

Voc tem Semancol?

Engenharia de Software - E se voc fosse um DVD numa locadora?

por trs do bvio

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

D seu feedback sobre esta edio!

Edio 32 - Engenharia de Software Magazine

Diferente da maioria das vitaminas, o semancol no pode

individualidades e direitos de todos aqueles que nos rodeiam.

Caixo, de to cumpridas e sujas que eram. Era pavoroso ver

Seus testes so geis?

De que se trata o artigo?

Para que serve?

Gabriela de Oliveira Patuci

formada pela UNICAMP em Tecnologia

Engenharia de Software Magazine - Seus testes so geis?

Waterfall e esto ingressando no mundo gil. Alm

Em que situao o tema til?

Antes, trabalhvamos com times de

Estrutura fsica dos times

Planejamento: Testes tambm so discutidos?

Existem vrios casos que, o jeito com que os testes sero

Figura 1. Times de testes x Times geis

Figura 2. Posicionamento dos membros de uma equipe Scrum

Edio 34 - Engenharia de Software Magazine

Ambiente de Testes Ambiente de Produo

Nmero de defeitos X Qualidade do Software

Figura 3. Exemplo de Scrum Board

dias ou, no mnimo, para uma porcentagem alta deles, como

Incio dos testes: Qual o momento certo?

Engenharia de Software Magazine - Seus testes so geis?

Uma das principais preocupaes de alguns profissionais

O segundo fator que devemos levar em conta so os testes de

se faz ainda mais importante, para diminuir a disputa (mesmo

Alocao dos Analistas de Testes

Uma mudana de cenrios aconteceu tambm no ramo da

Um dos fatores que pode interferir na qualidade do trabalho

Tabela 3. Ferramentas de Automao (execuo) de Testes

Edio 34 - Engenharia de Software Magazine

Ferramenta para registro de requisitos, armazenamento de casos de testes e resultados de teste.

Tabela 4. Ferramentas mais utilizadas pelas equipes em testes geis.

Figura 4. Ciclo de TDD e execuo das tarefas de desenvolvimento.

TDD (Test Driven Development)