Engenharia de Software - Edição 34

Prévia do material em texto

www.infnet.edu.br - cursos@infnet.edu.br - Central de Atendimento: (21) 2122-8800
E D U C A Ç Ã O S U P E R I O R O R I E N T A D A A O M E R C A D O
PÓS-GRADUAÇÃO
Engenharia de Software: 
Desenvolvimento Java
Engenharia de Software: 
Desenvolvimento .NET
GRADUAÇÃO
Engenharia de Computação
Análise e Desenv. de Sistemas
FORMAÇÕES
Desenvolvedor Java
Desenv. Java: Sist. Distribuídos
Gestor de TI
Desenvolvedor Web .NET 2008
MCITP Server Administrator 
SQL Server 2008
Acesse nosso site e conheça todos os nossos programas: www.infnet.edu.br/esti
A Escola Superior da Tecnologia da 
Informação oferece as melhores 
opções em cursos, formações, 
graduações e pós-graduações para 
profissionais de desenvolvimento 
e programação. 
São programas voltados para a 
formação de profissionais de elite, 
com aulas 100% práticas, corpo 
docente atuante no mercado, 
acesso à mais atualizada biblioteca 
de TI do Rio, laboratórios equipados 
com tecnologia de ponta, salas de 
estudo e exames.
r/esti
TURMAS
NO RIO DE
JANEIRO
Modéstia à parte, sua
melhor opção para
se destacar no mercado!
 
Corpo Editorial 
Colaboradores
Rodrigo Oliveira Spínola
Marco Antônio Pereira Araújo 
Eduardo Oliveira Spínola
Capa e Diagramação
Romulo Araujo - romulo@devmedia.com.br
Coordenação Geral
Daniella Costa - daniella@devmedia.com.br
Revisor
Gregory Monteiro - gregory@clubedelphi.net
Caroline Velozo - carolinelopes@devmedia.com.br
Jornalista Responsável
Kaline Dolabella - JP24185
Na Web
www.devmedia.com.br/esmag
Ano 3 - 34ª Edição - 2011 Impresso no Brasil
A 
Engenharia de Software Magazine destaca como tema de capa desta 
edição o artigo “Seus testes são “ágeis”? Testes incrementais para uma 
metodologia incremental”. O artigo apresenta um estudo sobre as princi-
pais diferenças entre a atividade de testes antes e depois das metodologias ágeis 
(principalmente o SCRUM). Estes pontos (diferenças) são citados com o intuito 
de explicar como os testes estão sendo executados em projetos na atualidade. O 
intuito de descrever estas diferenças é deixar claro que devemos ter em mente 
que os testes também são parte do desenvolvimento como um todo. Também é 
necessário pensar nesta integração quando planejamos a sprint e os testes em si. 
Pensar nos testes como uma atividade incremental desde o momento de estimar 
as estórias até o ponto em que começamos a executá-los é, sem dúvida, essencial 
para o bom andamento da sprint e para a mudança de visão dos profissionais 
da área.
Por fim, veremos neste artigo os benefícios encontrados na alocação de analistas 
de testes dentro dos times ágeis que podem ser resumidos em: (1) Integração 
do time, (2) Participação mais direta e ativa do profissional que está testando o 
software, (3) Profissionais que estão desenvolvendo código também estão inte-
ressados em aprender sobre testes, (4) Profissionais que estão testando código 
também estão interessados em aprender sobre programação, (5) Interação de 
todo o time de desenvolvimento com testes, (6) Analistas de Teste deixaram de 
ser reativos para serem pró-ativos.
Além desta matéria, esta edição traz mais cinco artigos:
• Você tem “Semancol”?
• Desenvolvimento de Software Apoiado por Groupware
• Alternativas para redução de problemas na manutenção de software
• Refatoração para Padrões – Parte 7
• Tratamento de exceções
Desejamos uma ótima leitura!
Equipe Editorial Engenharia de Software Magazine
Rodrigo Oliveira Spínola 
rodrigo.devmedia@gmail.com
Doutorando em Engenharia de Sistemas e Computação (COPPE/UFRJ). Mestre em 
Engenharia de Software (COPPE/UFRJ, 2004). Bacharel em Ciências da Computação 
(UNIFACS, 2001). Colaborador da Kali Software (www.kalisoftware.com), tendo minis-
trado cursos na área de Qualidade de Produtos e Processos de Software, Requisitos e 
Desenvolvimento Orientado a Objetos. Consultor para implementação do MPS.BR. Atua 
como Gerente de Projeto e Analista de Requisitos em projetos de consultoria na COPPE/
UFRJ. É Colaborador da Engenharia de Software Magazine.
Marco Antônio Pereira Araújo
maraujo@devmedia.com.br
Doutor e Mestre em Engenharia de Sistemas e Computação pela COPPE/UFRJ - Li-
nha de Pesquisa em Engenharia de Software, Especialista em Métodos Estatísticos 
Computacionais e Bacharel em Matemática com Habilitação em Informática pela 
UFJF, Professor e Coordenador do curso de Bacharelado em Sistemas de Informação 
do Centro de Ensino Superior de Juiz de Fora, Professor do curso de Bacharelado em 
Sistemas de Informação da Faculdade Metodista Granbery, Professor e Diretor do Cur-
so Superior de Tecnologia em Análise e Desenvolvimento de Sistemas da Fundação 
Educacional D. André Arcoverde, Analista de Sistemas da Prefeitura de Juiz de Fora, 
Colaborador da Engenharia de Software Magazine.
Eduardo Oliveira Spínola
eduspinola@gmail.com
É Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Ma-
gazine. É bacharel em Ciências da Computação pela Universidade Salvador (UNIFACS) 
onde atualmente cursa o mestrado em Sistemas e Computação na linha de Engenharia 
de Software, sendo membro do GESA (Grupo de Engenharia de Software e Aplicações).
Apoio
Atendimento ao Leitor
A DevMedia conta com um departamento exclusivo para o atendimento ao leitor. 
Se você tiver algum problema no recebimento do seu exemplar ou precisar de 
algum esclarecimento sobre assinaturas, exemplares anteriores, endereço 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
(21) 2220-5338
Publicidade
Para informações sobre veiculação de anúncio 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 sugestão!
Se você estiver interessado em publicar um artigo na revista ou no site SQL Magazine, 
entre em contato com os editores, informando o título e mini-resumo do tema que você 
gostaria de publicar:
Rodrigo Oliveira Spínola - Colaborador
rodrigo.devmedia@gmail.com
EDITORIAL
 
 ÍNDICE
Por trás do óbvio
06 – Você tem “Semancol”?
Glênio Cabral
Agilidade
08 - Seus testes são “ágeis”?
Gabriela de Oliveira Patuci 
Engenharia
14 - Desenvolvimento de Software Apoiado por Groupware 
Gabriella Castro Barbosa Costa e Marco Antônio Pereira Araújo
 21 - Alternativas para redução de problemas na manutenção de software 
Mateus Maida Paduelli
Desenvolvimento
38 - Refatoração para Padrões – Parte 7
Jacimar Fernandes Tavares e Marco Antônio Pereira Araújo 
46 - Tratamento de Exceções
Jacimar Fernandes Tavares e Marco Antônio Pereira Araújo 
Tipo: Processo 
Título: Especificação de casos de uso na prática – Partes 16 a 20
Autor: Rodrigo Oliveira Spínola
Mini-Resumo: Definir requisitos não é uma atividade trivial. Uma das 
formas de realizar esta atividade é através da especificação de casos de 
uso. Neste sentido, nesta série de vídeo aulas apresentaremos um conjunto 
de especificações de casos de uso. Os cenários serão especificados passo 
a passo considerando tópicos como fluxo principal, fluxo alternativo e 
regras de negócios.
Caro Leitor, 
Para esta edição, temos um conjunto de 5 vídeo aulas. 
Estas vídeo aulas estão disponíveis para download no Portal 
da Engenharia de Software Magazine e certamente trarão 
uma significativa contribuição para seu aprendizado. A lista 
de aulaspublicadas pode ser vista abaixo:
Edição 05 - Engenharia de Software Magazine 5 
 
6 Engenharia de Software - E se você fosse um DVD numa locadora?
Glênio Cabral
gleniocabral@yahoo.com.br
É Administrador de Empresas, pós-graduado em Gestão de Pessoas e músi-
co. Idealizador do site de educação infantil www.novainfancia.com.br.
Você tem “Semancol”?
Pos trás do Óbvio
Vamos falar sobre vitaminas. Sabemos que as vi-taminas fornecem ao corpo humano uma grande variedade de nutrientes fundamentais para o seu 
bom funcionamento. A vitamina A, por exemplo, contém 
substâncias antioxidantes que auxiliam no combate ao pro-
cesso de envelhecimento. Já a vitamina D é fundamental na 
regulação da pressão arterial, de modo que quando ingerida 
corretamente mantém o sistema nervoso bem calmo. 
E assim, cada vitamina tem sua importância no sentido de 
promover o bem estar e o equilíbrio do nosso metabolismo. Há, 
no entanto, uma vitamina diferente, peculiar até. Descoberta 
por este colunista que lhe escreve, esta vitamina não promove 
necessariamente ações benéficas ao nosso organismo. Em vez 
disso, ela é especialista em viabilizar relacionamentos saudá-
veis e respeitadores entre as pessoas. Caro leitor, é com muito 
prazer que lhe apresento a Vitamina S. S de “Semancol”. 
A vitamina Semancol é responsável pela produção de uma 
enzima chamada “senso do ridículo”, também conhecida 
como “desconfiômetro”. A função desta enzima é fazer com 
que cada um de nós, vez por outra, tenha a sensação de estar 
se comportando ou de estar prestes a se comportar de forma 
inconveniente e inadequada. É como se essa peculiar vita-
mina provocasse um alarme, uma espécie de aviso dentro de 
nós que nos alerta para o fato de que algo pode não acabar 
muito bem se continuarmos agindo da forma que estamos. 
Por isso, pessoas carentes desta vitamina costumam ser pro-
tagonistas de situações embaraçosas e inconvenientes. Elas 
não percebem o vital aviso.
Não é a toa que vez por outra nos deparamos com indivídu-
os assim, totalmente desprovidos deste complexo vitamínico. 
Nos ambientes de trabalho, por exemplo, os efeitos colaterais 
de tal abstinência são 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 não têm nada a ver com seus assuntos parti-
culares e muito menos são obrigadas a ouvi-los na íntegra. 
No entanto, é o que acontece.
2. Quando pessoas sem Semancol chegam atrasadas a reu-
niões de trabalho, fazem questão de pedir desculpas em 
alto e bom som, atrapalhando o andamento da reunião. Se 
tivessem Semancol, se sentariam discretamente no lugar mais 
próximo da porta e no primeiro intervalo se desculpariam 
pessoalmente com o dirigente pelo atraso. Mas não, preferem 
o estardalhaço. 
3. Por se acharem muito engraçados, muitos abusam de pia-
das machistas e racistas durante o expediente, criando um 
mal-estar generalizado. E o fazem aos risos escandalosos. 
4. Coisas aparentemente pequenas também costumam cau-
sar grandes constrangimentos. Tive um colega que insistia 
em usar uma caneta Bic na orelha esquerda o dia todo. Não 
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 chão e era aquela confusão para achá-la 
em meio ao atendimento. Lembro-me de outro colega que 
não cortava as unhas. As unhas dele pareciam as do Zé do 
Edição 32 - Engenharia de Software Magazine 7 
PoR tRáS Do óBvIo
Dê seu feedback sobre esta edição!
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, através do link:
www.devmedia.com.br/esmag/feedback
D
ê 
se
u Fe
edback
so
b
re esta edição
Caixão, de tão cumpridas e sujas que eram. Era pavoroso ver 
aquilo, e pior ainda era apertar sua mão.
5. Há aqueles que têm como obsessão entupir os e-mails de 
colegas e clientes com mensagens de motivação e as ultra-
jantes correntes do bem. E pior, o fazem de modo nada per-
sonalizado. Fica claro que a mesma mensagem foi enviada a 
milhões de outras pessoas ao mesmo tempo.
6. Alguns perdem a noção das coisas quando o assunto é 
vestimenta no trabalho. Decotes exagerados e mini-saias 
não são vestimentas adequadas para um ambiente de traba-
lho. Nem mesmo num escritório de uma escola de samba as 
pessoas devem se vestir assim, e olhe que o clima lá é bem 
carnavalesco. 
Diferente da maioria das vitaminas, o semancol não pode 
ser encontrado nos alimentos. Ele é adquirido e desenvolvi-
do na convivência entre as pessoas. É essa prática, a prática 
da convivência e da troca de experiências, que nos capacita 
a interagir com maturidade e bom senso, respeitando as 
individualidades e direitos de todos aqueles que nos rodeiam. 
Isso é ter “Semancol”. 
Não há como ser parte integrante de uma organização 
sem interagir com pessoas dos mais diferentes perfis. Por 
isso, toda corporação é dotada de regras de comportamento, 
pois tais regras ao menos tentam garantir um certo clima 
de respeito mútuo e gentileza no ambiente de trabalho, pro-
porcionando assim o surgimento de relações profissionais 
cada vez mais saudáveis. E também cada vez mais dotadas 
de “Semancol”. 
E agora, caro leitor, a pergunta final que não quer calar: 
como anda sua taxa vitamínica de “Semancol”?
8 Engenharia de Software Magazine - Seus testes são “ágeis”?
Gabriela de Oliveira Patuci
opgabi@gmail.com
É formada pela UNICAMP em Tecnologia 
em Informática e está cursando mestrado 
na área de Engenharia de Software. Possui 
certificação pela Scrum Alliance, tem expe-
riência de três anos no trabalho com me-
todologias á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. 
De que se trata o artigo?
Neste artigo foram apresentadas as principais alte-
rações sofridas pela atividade de testes ao longo dos 
últimos anos, principalmente influenciadas pelas me-
todologias ágeis. A experiência em projetos Scrum foi 
considerada e alguns pontos foram levantados como 
sugestões 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 intenção de ser uma referência para as 
pessoas que estão deixando de realizar os testes em 
Waterfall e estão ingressando no mundo ágil. Além 
disso, o texto também contém lições aprendidas 
durante os últimos projetos e como os times andam 
desenvolvendo os testes de maneira incremental.
Em que situação 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 estão enfrentando 
problemas com os resultados dos seus testes ou 
com as tarefas de testes dentro das equipes.
Seus testes são “ágeis”?
Testes incrementais para uma metodologia incremental
Agilidade
Nesta seção você encontra artigos voltados para as práticas e métodos ágeis.
Em treinamentos, normalmente começamos a falar sobre quais os conceitos que não são mais 
utilizados pela disciplina de testes 
antes mesmo de falar sobre como ela 
funciona em ambientes ágeis. Isto por-
que muita coisa mudou e o ideal é que 
todos possam ter um tempo para notar 
as principais características e diferenças 
do que era feito em Waterfall e de como 
fazemos hoje, no Scrum. Esse também 
foi considerado o jeito mais intuitivo de 
começar este artigo.
Antes, trabalhávamos com “times de 
Testes”. Analistas, Testadores, Engenhei-ros, 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, analis-
tas de banco, arquitetos, scrum masters 
e product owners. Estes profissionais 
são considerados os pontos focais da 
qualidade dentro dos times, mas não os 
únicos responsáveis por ela na entrega 
Edição 34 - Engenharia de Software Magazine 9 
MEtoDoLoGIAS áGEIS
do produto. A Figura 1 demonstra as duas estruturas, o mo-
delo antigo de Equipes de Testes e o novo modelo, onde estes 
profissionais já aparecem alocados dentro de seus novos times 
multifuncionais.
Estrutura física dos times
Localização física é outro ponto extremamente importan-
te, já que propicia uma melhor comunicação entre o time 
quando planejada corretamente. Não basta os profissionais 
da qualidade estarem inseridos nos times, estes também 
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 execução dos testes em si (e dos retestes 
inclusive) e toda a comunicação de fato. Caso contrário, mu-
daríamos muito pouco do cenário antigo para o proposto em 
metodologias ágeis. A Figura 2 demonstra o posicionamento 
dos membros de uma equipe Scrum: sem divisões e o mais 
próximo possível. 
Sprint 0
Os testes podem e devem ser iniciados desde o primeiro dia 
da sprint, às vezes até antes da reunião de planejamento das 
atividades (planning meeting). Como podemos fazer isto? O ana-
lista de testes deve ser o responsável por revisar os requisitos 
vindos do cliente para que a maior parte das dúvidas seja reti-
rada e as estórias 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 estórias.
Ter este Sprint 0, isto é, este momento antes da sprint de de-
senvolvimento, em que podemos conhecer melhor o negócio 
é, sem dúvida, um dos pontos pelos quais pode-se observar 
maior número de melhorias na qualidade dos projetos. Ter 
um requisito mais trabalhado e um time que conhece mais do 
negócio no qual está trabalhando é algo que só contribui para 
o resultado final da construção do software. 
Esta ajuda técnica também é de grande valia no momento 
da criação das estórias porque nem sempre podemos ter um 
product owner com um perfil mais técnico. Em casos em que o 
cliente tem um perfil mais leigo, a ajuda de alguém que tenha 
uma visão crítica de negócios, mas ao mesmo tempo seja do 
time, pode ser crucial. A Tabela 1 mostra quais as principais 
características necessárias para uma boa estória. 
Planejamento: Testes também são discutidos?
Experiências recentes em times Scrum nos fazem crer que 
muito se fala de desenvolvimento nas reuniões de planeja-
mento, mas muito pouco é dito ou até mesmo discutido sobre 
a atividade de testes. Precisamos ter em mente que, além de 
como vamos desenvolver, temos que pensar em como vamos 
testar e esta parte também deve ser estimada, pois demanda 
tempo e esforço como qualquer outra atividade. Desvios de 
estimativa podem ser corrigidos se passarmos a ver os projetos 
com este novo enfoque.
Figura 2. Posicionamento dos membros de uma equipe Scrum
Figura 1. Times de testes x Times Ágeis
User Stories (Estórias) devem ser INVEST: 
Independente: devem ser independentes sempre que possível.
Negociável: deve ser negociável.
Valiosa: devem ser valiosas para o cliente, agregando valor ao negócio.
Estimável: devem ser passivas de estimativa.
Small (pequena): não devem ser grandes demais nem pequenas demais.
Testável: devem ser claras o suficiente para serem testadas.
tabela 1. Características de uma boa estória
Existem vários casos que, o jeito com que os testes serão 
realizados, é com certeza a parte mais importante do negócio. 
Elaboração de sistemas que auxiliem a atividade de testes, 
por exemplo, é algo que deve ser pensado com muita cautela 
e levado em consideração nas estimativas do projeto (e isso 
demanda tempo não só dos profissionais de testes, mas do 
time todo).
Vamos pensar em um exemplo: um sistema que faz o acompa-
nhamento de usuários em um programa que ajuda fumantes a 
pararem com o vício em 100 dias. Todo dia, este usuário deve 
entrar no sistema em uma espécie de diário e registrar o que 
lhe aconteceu ao longo deste tempo. Também vamos imaginar 
que cada um destes 100 dias possua conteúdos específicos 
(como artigos) que este usuário tenha que ler ou até mesmo 
e-mails que ele vai receber.
O normal em uma reunião de planejamento seria o time todo 
pensar em como desenvolver este programa: como enviar os e-
mails de forma programada, como armazenar as informações, 
etc. Sim, isto faz sentido, mas também precisamos pensar em 
como faremos para testar 100 dias de programa sem levar os 
exatos 100 dias nesta atividade. Se precisamos verificar e va-
lidar o comportamento específico do sistema para todos estes 
10 Engenharia de Software Magazine - Seus testes são “ágeis”?
dias ou, no mínimo, para uma porcentagem alta deles, como 
faremos? Surge aqui a necessidade de estimar a construção de 
um pequeno sistema de testes que consiga alterar a data que 
o usuário se encontra dentro do programa. 
Por fim, quando falamos em planejamento, também 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 critério do time, como quase tudo no Scrum. Utilizar 
ou não este modelo deve ser decidido no início da sprint.
Início dos testes: Qual o momento certo?
Saber o momento de iniciar os testes pode ser citado como o 
próximo ponto diferencial entre as metodologias. O costume 
das equipes de Testes sempre foi esperar por um pedido vindo 
de desenvolvimento para o início dos testes. O máximo que se 
podia fazer antes deste momento era planejar os testes funcio-
nais 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 também sejam realizadas 
de maneira incremental.
Logo após a reunião 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, verifi-
cando o andamento das atividades ainda que no ambiente de 
desenvolvimento. Quando antecipamos esta etapa de testes, 
encontramos os prováveis defeitos muito antes de chegar ao 
ambiente de testes e desta forma, os defeitos têm 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 próprio time, quanto na 
qualidade de seu trabalho. 
Figura 3. Exemplo de Scrum Board
Número de defeitos X Qualidade do Software
Uma das principais preocupações de alguns profissionais 
com a questão do teste incremental é o fato de levantar os 
defeitos e futuros problemas de maneira informal (através de 
comunicação entre os membros do time). É fato que este hábito 
diminui o número de defeitos (formais) durante a sprint. O que 
devemos ter em mente é que o número de defeitos registrados 
em ferramentas não é diretamente proporcional à qualidade 
do software construído. 
O que podemos observar em projetos atualmente é que 
mesmo com um número de defeitos registrados bem menor, 
a qualidade dos sistemas só vem aumentando, já que todos os 
pontos são levantadosou durante os testes ainda no ambiente 
de desenvolvimento ou, em último caso, durante os testes 
funcionais no ambiente de testes.
Outro fator relevante nesta discussão é que um defeito tem 
um custo muito mais baixo se for encontrado o mais cedo pos-
sível durante o desenvolvimento (sprint). Encontrar um defeito 
logo após a sua criação 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 repor-
tados antes e depois da implantação dos Testes Incrementais 
em um projeto real. 
Documentação
A ideia de que metodologias ágeis não têm nenhuma do-
cumentação ainda persiste no conceito de várias pessoas. Na 
verdade, o que se prega é que devemos dar mais importância 
à comunicação entre as pessoas do time do que à documenta-
ção, mas, nada se fala a respeito de não ter documentação. É 
necessário ter o conceito de que a documentação é sim muito 
importante mesmo em projetos ágeis. A seguir, são descritos 
exemplos claros que justificam a importância desta documen-
tação básica de testes.
O fato de o time ser multifuncional é o primeiro motivo da 
necessidade de planejamento e documentação mínima de 
testes. Todos os profissionais alocados dentro do time podem 
precisar ajudar na execução dos testes e, desta forma, vão 
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 não fiquem sem trabalho no 
começo da sprint e muito atarefados no final dela, mas mesmo 
assim, sempre existirão os casos em que a ajuda dos outros 
membros do time se fará necessária. Sempre que a demanda 
de testes estiver muito alta, os documentos com a especificação 
dos casos de testes e todo o planejamento serão cruciais.
ANTES DEPOIS
Sprint 1 Sprint 2 Sprint 3 Sprint 4
Ambiente de Testes Ambiente de Produção Ambiente de Testes Ambiente de Produção Ambiente de Testes Ambiente de Produção Ambiente de Testes Ambiente de Produção
45 3 39 1 10 0 6 0
tabela 2. Comparação entre o número de defeitos antes e depois das alterações em Testes
Edição 34 - Engenharia de Software Magazine 11 
MEtoDoLoGIAS áGEIS
O segundo fator que devemos levar em conta são os testes de 
aceitação. Não 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 execução 
dos testes de aceitação é a maneira mais segura de se garantir 
a boa execução de tais testes.
Por fim, podemos considerar a criação de um planejamento 
de testes o momento perfeito para identificar todas as possíveis 
dúvidas que restaram sobre as estórias 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 
necessário. 
Alocação dos Analistas de Testes
Um dos fatores que pode interferir na qualidade do trabalho 
dos analistas de testes, se não for bem considerado, é a alocação 
compartilhada entre times. Muitos times têm 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 média de três pessoas normalmen-
te possuem líderes que trabalham com mais de um projeto. 
Este costume está cada vez mais comum. Além disso, nos 
últimos tempos, compartilhar testadores e arquitetos virou 
uma solução para a falta de profissionais da área. O que se 
precisa considerar é como se deve atuar para não perder o 
foco do trabalho nestes times e saber dividir o tempo diário 
entre eles.
Soluções práticas como ter o mesmo horário para cada time 
todos os dias podem trazer benefícios 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 
se faz ainda mais importante, para diminuir a disputa (mesmo 
que informal) que se cria pelo trabalho do profissional.
Outra boa prática que vem sendo desenvolvida em times 
compartilhados é a existência de um ponto focal para auxiliar 
em testes em ambos os times. Sempre existe a possibilidade de 
o número de tarefas de testes serem inviáveis para um único 
profissional, o que nos faz pensar em ter um auxílio que venha 
de dentro do próprio time. Importante neste caso é manter o 
pensamento de que este auxílio deve partir de um integrante 
do time que tenha bons skills de testes e a visão crítica do 
produto. Nem sempre todos os membros de um time têm o 
perfil de um testador.
Automação de Testes
Uma mudança de cenários aconteceu também no ramo da 
automação de testes. Antes, muito se pesquisava sobre a 
automação da criação de casos de testes. Hoje, com o advento 
das metodologias ágeis, a atenção das equipes está muito mais 
voltada para a automação da execução de testes em si. Tudo isso 
porque a metodologia dá muito valor à execução e não tanto 
para a documentação (como já foi dito anteriormente).
Ferramentas que ajudam nos testes de regressão, testes fun-
cionais e criação de massa de dados são as mais procuradas. 
Principalmente nos casos de construção de websites, onde 
ferramentas (ou plugins) como Selenium IDE podem facili-
tar a execução do mesmo caso de teste N vezes com valores 
diferentes selecionados a partir de uma planilha Excel, por 
exemplo. Testes de estresse do sistema também são muito 
procurados e uma das ferramentas mais utilizadas é o JMeter. 
Simular situações onde um número muito grande de usuários 
tenta acessar o sistema pode ser muito útil antes de mover um 
site para produção (nestes casos, ter um número esperado de 
usuários pode ajudar bastante no planejamento de tais testes). 
A Tabela 3 mostra quais as principais ferramentas que estão 
sendo utilizadas no mercado para automação (da execução) 
de testes. 
Selenium: O Selenium IDE é um ambiente integrado de desenvolvimento para scripts. Ele é implementado como uma extensão do Firefox e permite gravar, editar e 
depurar os testes. Esta ferramenta também permite que os usuários gravem e reproduzam os testes no ambiente real no qual serão executados. Pode ser usado para 
testes de fumaça, regressão e funcionais em geral.
JMeter: Utilizado para testes de desempenho em aplicações de diferentes tipos de servidores (HTTP/HTTPS, SOAP, JMS etc.). É uma aplicação open source Java e foi 
desenvolvida para executar load tests e testes de performance. Originalmente foi desenvolvido para aplicações Web, mas agora está sendo utilizado também para outras 
aplicações. 
Watir: Utilizado para testes automatizados para Web escritos na linguagem Ruby. Existem derivações em .Net (WatN) e Java (WatJ). Basicamente para quem quer criar 
testes fáceis 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 aceitação. O usuário pode criar critérios de aceitação de maneira colaborativa, 
criar e executar testes automatizados e manter dados de teste.
tabela 3. Ferramentas de Automação (execução) de Testes
12 Engenharia de Software Magazine - Seus testes são “ágeis”?
TDD (Test Driven Development)
Técnica amplamente utilizada nos últimos tempos, o TDD, 
em português Desenvolvimento Dirigido por Testes, vem 
crescendo na área de desenvolvimento de software. Os resul-
tados atingidos nos projetos que utilizam TDD fazem com que 
este crescimento seja fortalecido, principalmente levando emconsideração que os passos necessários para a utilização da 
técnica são relativamente simples.
Durante a implantação do TDD, foram observados melhores 
resultados quando desenvolvedores e testadores construíam 
juntos os casos de testes automatizados, definidos para validar 
melhorias no produto ou até mesmo para novas funcionalida-
des. A partir deste ponto, o código era produzido com base 
nestes testes, o que garantia que este tinha os requisitos míni-
mos de qualidade e atendia à necessidade do cliente. Após a 
criação do código em si, os testes feitos anteriormente podiam 
ser executados e possíveis defeitos eram corrigidos. Já com os 
defeitos corrigidos (com base nos casos de testes construídos 
anteriormente), os scripts automatizados eram executados 
novamente para garantir que o código estivesse correto. Este 
ciclo se repetia até a finalização da tarefa. 
O papel do analista de testes nesta técnica é muito impor-
tante, visto que ele pode ajudar muito na criação dos casos de 
teste, aproveitando seu conhecimento e visão crítica. Muitos 
times utilizam esta visão para se trabalhar com pair program-
ming entre desenvolvedor e testador na criação dos scripts 
automatizados.
Em muitos casos, a técnica pode ser inicialmente considerada 
mais demorada ou até mesmo mais cara, mas com o passar 
do tempo, pode-se constatar a criação de softwares com os 
seguintes benefícios:
• Menos uso de um debugger;
• Menor quantidade de defeitos;
• Software feito de maneira mais rápida e com melhor 
qualidade.
Por fim, devemos manter o foco também nas limitações que 
esta técnica pode trazer à sprint. Um exemplo de tais limitações 
é o fato da qualidade do código ser muito baseada na qualidade 
dos testes em si. Logo, se os testes não forem criados de forma 
criteriosa, o código também não será bom o suficiente. Outro 
fator relevante a ser considerado é o tipo de sistema que está 
sendo desenvolvido. Sistemas com muita interface gráfica ou 
até mesmo com banco de dados relacional, podem ter seu de-
senvolvimento dificultado, se criados com esta técnica.
A Figura 4 mostra como deve ser feita a execução 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 serão 
automatizados e integrando a ferramenta de teste de código.
Ferramentas mais utilizadas
Algumas ferramentas vêm sendo amplamente utilizadas 
pelas equipes e profissionais de testes nos projetos ágeis. 
Ferramentas de apoio a testes vão além de automação (e de 
execução), elas podem ajudar na abertura de defeitos e no 
acompanhamento dos requisitos e mudanças 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 
características e o seu uso mais frequente.
Em resumo, pode-se dizer que as ferramentas pagas são 
muito completas e interessantes, mas nem sempre as empresas 
Figura 4. Ciclo de TDD e execução das tarefas de desenvolvimento.
Ferramenta Gratuita? Descrição
Jira
NÃO (Apenas para projetos 
open source)
Ferramenta para gestão de projetos e acompanhamento de tarefas e erros. É relativamente fácil de usar, oferece grande flexibilidade, 
de forma que você pode fazer o acompanhamento de todas as tarefas, desde sua criação até finalização, assinalando o assunto e seu 
responsável. Existe a possibilidade de se fazer comentários e capturas. O responsável e o criador do ticket podem ser informados por 
e-mail sobre todas as mudanças efetuadas.
Bugzilla SIM
Aplicação para gestão de erros. Esta aplicação permite que indivíduos ou grupos de programadores acompanhem os relatórios de erros 
ou pedidos de melhorias. É uma ferramenta baseada em Web e e-mail, que dá suporte ao desenvolvimento do projeto Mozilla, rastreando 
defeitos e servindo também 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 automação do planejamento de testes e que apresenta interface gráfica mais amigável (user friendly).
Mercury TestDirector NÃO É um aplicativo para Gestão de Testes – Gerenciamento de Requisitos, Plano de Teste e Controle de Defeitos.
Rational TestManager NÃO
É um console central para as atividades de gerenciamento e relatórios de testes. Criado para ser extensível, ele suporta tudo, desde 
abordagens de teste manual até automatizados, incluindo testes unitários, testes de regressão funcional e testes de desempenho. 
tabela 4. Ferramentas mais utilizadas pelas equipes em testes ágeis. 
Edição 34 - Engenharia de Software Magazine 13 
MEtoDoLoGIAS áGEIS
têm a possibilidade de obter as licenças para todos os recursos. 
As opções open source vêm sendo cada vez mais utilizadas e 
logo, melhoradas e difundidas.
Como são ferramentas de conhecimento público, tornou-se 
muito fácil conseguir ajuda e referências de ferramentas open 
source, já que todos os profissionais da área têm acesso a elas 
(tanto quanto estudantes e pesquisadores).
Por fim, outro fator que deve ser considerado quando da 
escolha das ferramentas é sua integração. Um exemplo claro 
é a utilização das ferramentas TestLink e Bugzilla. O TestLink 
tem uma boa integração com interfaces de bug tracking em geral 
e seus resultados podem ser utilizados de maneira a facilitar 
o controle/manutenção das informações do projeto. Estudar 
como fazer este tipo de integração pode ser um bom começo 
para a automação de dados de testes.
Conclusão
Este artigo apresentou um estudo sobre as principais diferen-
ças entre a atividade de testes antes e depois das metodologias 
ágeis (principalmente o SCRUM).
Estes pontos (diferenças) foram citados com o intuito de ex-
plicar como os testes estão sendo executados em projetos na 
atualidade. O intuito de descrever estas diferenças é deixar 
claro que devemos ter em mente que os testes também são 
parte do desenvolvimento como um todo. Também é neces-
sário pensar nesta integração quando planejamos a sprint e os 
testes em si. Pensar nos testes como uma atividade incremental 
desde o momento de estimar as estórias até o ponto em que 
começamos a executá-los é, sem dúvida, essencial para o bom 
andamento da sprint e para a mudança de visão dos profis-
sionais da área.
Os benefícios encontrados na alocação de analistas de testes 
dentro dos times ágeis podem ser resumidos em:
• Integração do time;
• Participação mais direta e ativa do profissional que está 
testando o software;
• Profissionais que estão desenvolvendo código também estão 
interessados em aprender sobre testes;
• Profissionais que estão testando código também estão inte-
ressados em aprender sobre programação;
• Agilidade: interação de todo o time de desenvolvimento 
com testes;
• Analistas de Teste deixaram de ser reativos para serem 
pró-ativos.
Ao final, vale ressaltar que não se pode pensar que sabemos o 
melhor jeito de executar testes em times ágeis, isto seria ilusão. 
O importante é conhecer o que já foi tentado e preservar o que 
foi aprendido durante estas tentativas, pois com certeza, não 
existe algo que possa ser considerado “a bala de prata”. 
Endereço da página do Selenium
http://seleniumhq.org 
Site do JMeter
http://jakarta.apache.org/jmeter/
Endereço 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/
Endereço da ferramenta Testlink
http://testlink.sourceforge.net/docs/testLink.php
Endereço da ferramenta QA Track
http://www.testmanagement.com/
Site do Mercury TestDirector
http://www.starbase.co.uk/products/hp-products/hp-testdirector.htmlSite da Rational TestManager
http://www-01.ibm.com/software/awdtools/test/manager/
Links
[1] BECK, K.; FOWLER, M. et al (2001). Manifesto for Agile Software Development. 
http://www.agilemanifesto.org/. 
[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/
Referências 
Dê seu feedback sobre esta edição!
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, através do link:
www.devmedia.com.br/esmag/feedback
D
ê 
se
u Fe
edback
so
b
re esta edição
14 Engenharia de Software Magazine - Desenvolvimento de Software Apoiado por Groupware
Marco Antônio Pereira Araújo 
maraujo@devmedia.com.br
Doutor e Mestre em Engenharia de Siste-
mas e Computação pela COPPE/UFRJ, Es-
pecialista em Métodos Estatísticos Compu-
tacionais e Bacharel em Informática pela 
UFJF, professor dos Cursos de Bacharelado 
em Sistemas de Informação do Centro de 
Ensino Superior de Juiz de Fora, da Faculda-
de Metodista Granbery e da Universidade 
Severino Sombra, professor do curso de 
Bacharelado em Ciência da Computação 
da FAGOC, professor do Curso Superior de 
Tecnologia em Análise e Desenvolvimento 
de Sistemas da Fundação Educacional D. 
André Arcoverde, Analista de Sistemas da 
Prefeitura de Juiz de Fora, Editor da Enge-
nharia de Software Magazine.
Gabriella Castro Barbosa Costa 
gabriellacbc@gmail.com
Bacharel em Sistemas de Informação pelo 
CES-JF (2010) e Técnica em Informática In-
dustrial pelo CEFET-MG (2007). Atua como 
desenvolvedora Web desde 2008.
De que se trata o artigo?
Este artigo aborda o uso de groupware nos processos 
de desenvolvimento de software que são realizados 
de forma colaborativa, apresentando suas principais 
características, vantagens, ferramentas e platafor-
mas para apoiar o desenvolvimento de software 
neste contexto.
Para que serve?
Como o trabalho colaborativo no desenvolvimento 
de software é de grande importância, pois diferen-
tes habilidades são necessárias, o uso de groupware 
visa facilitar a execução e controle das tarefas que, 
em sua maioria, são realizadas de forma distribuída 
e colaborativa.
Em que situação o tema é útil?
Groupware pode ser utilizado para apoiar grupos 
de pessoas a realizarem qualquer tarefa ou meta 
em comum, mesmo trabalhando em localidades 
e horários distintos. O uso deste tipo de sistema 
para apoio ao desenvolvimento de software traz 
grandes vantagens já que este é, em sua maior 
parte, de caráter colaborativo.
Desenvolvimento de Software Apoiado por 
Groupware
Uma Introdução
Engenharia
Nesta seção você encontra artigos voltados para testes, processo, 
modelos, documentação, entre outros
De modo geral, através da junção de conhecimentos, experiências, habilidades e esforços de um 
grupo, conseguem-se alcançar melhores 
resultados para um mesmo trabalho do 
que se este fosse executado individual-
mente. O trabalho colaborativo, além de 
estimular os participantes envolvidos no 
processo, propicia a resolução de proble-
mas e desafios de forma mais rápida e 
eficiente, partindo do princípio de que 
as falhas/inconsistências de uma ideia 
ou proposta podem ser encontradas por 
outros integrantes do grupo durante a 
realização do trabalho.
Embora traga muitas vantagens, o 
trabalho coletivo exige um grande es-
forço na coordenação dos integrantes de 
um grupo, de forma a evitar eventuais 
conflitos e fazer com que os objetivos e 
metas traçadas sejam alcançadas de for-
ma satisfatória pelo grupo. Outras des-
vantagens do trabalho em grupo é que 
este é considerado mais lento e oneroso 
e, às vezes, o grupo pode desperdiçar 
o tempo de trabalho em bate-papos ou 
discussões desnecessárias.
A partir da interação e colaboração 
entre indivíduos, surge um novo tipo 
de conhecimento também conhecido 
Edição 34 - Engenharia de Software Magazine 15 
ENGENhARIA DE SoFt WARE
por ‘inteligência coletiva’, como é o caso do que ocorre no 
desenvolvimento de software livre, das enciclopédias online 
colaborativas e das redes sociais. Os avanços da Web 2.0 e das 
ferramentas de comunicação online alavancaram considera-
velmente o uso de sistemas colaborativos como chats, agenda, 
catálogo de endereços, webmail amigável, gerenciador de ar-
quivos, 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, além 
de fornecer uma interface para um ambiente compartilhado. 
Esse tipo de software visa facilitar o trabalho de equipes que 
têm necessidade de um trabalho conjunto, mesmo traba-
lhando em localidades e horários distintos. O estudo sobre 
sistemas colaborativos engloba várias áreas como Engenharia 
de Software, Banco de Dados, Computação Gráfica, Sistemas 
Distribuídos e Inteligência Artificial, além de relacionar-se 
com áreas como a Sociologia, Linguística 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 con-
siderado uma ferramenta desenvolvida a partir dos conceitos 
abordados em CSCW.
Neste contexto, este artigo traz uma introdução sobre o 
trabalho colaborativo, destacando suas vantagens e desvan-
tagens. Na seção seguinte são apresentadas as principais 
características dos sistemas colaborativos, em seguida são 
apontadas as diferenças 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 são apresentados os principais exemplos 
de groupware, como ferramentas de comunicação, ferramentas 
para controle de versões, ferramentas para controle de erros, 
ferramentas para gerência de projetos e três plataformas que 
podem ser usadas durante o processo de desenvolvimento 
de sistemas.
O Trabalho Colaborativo
Através do trabalho em grupo podem-se produzir melhores 
resultados do que se os membros do grupo trabalhassem indi-
vidualmente, já que há a possibilidade da complementação de 
conhecimentos e do surgimento de pontos de vistas diferentes. 
Com isso, a identificação de falhas na maneira escolhida para 
a resolução de problemas torna-se muito mais rápida e eficaz. 
Outra grande vantagem do trabalho colaborativo é a motivação 
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 coordenação de seus membros para que os resultados se-
jam satisfatórios. Para que o trabalho colaborativo possa ocor-
rer de forma que as metas traçadas inicialmente sejam, de fato, 
alcançadas, alguns fatores como comunicação, coordenação, 
cooperação e percepção são de suma importância e devem 
atuar de forma interligada.
- Comunicação
No trabalho em grupo, durante o processo de comunicação, os 
participantes deste têm 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 integrantesão 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 comunicação entre o grupo também 
pode exercer influência na informação a ser transmitida. Quan-
to mais pessoal for o contato entre as pessoas, melhor será o 
aproveitamento da ideia transmitida. Por exemplo, reuniões 
presenciais podem ser mais eficazes do que conversas por 
telefone, que por sua vez podem ser mais esclarecedoras do 
que chats ou mensagens instantâneas via web. Porém, muitas 
vezes, no trabalho colaborativo não é possível a realização 
de reuniões presenciais, para isto torna-se necessário um 
bom conhecimento de todos os membros do grupo sobre a 
correta forma de utilização das ferramentas de comunicação 
e da linguagem e expressões a serem usadas no decorrer das 
conversas.
No processo de colaboração, o mais importante não é apenas 
saber se o receptor recebeu a informação de forma adequada, 
mas sim se teve um bom entendimento da mesma. Isso pode 
ser percebido através das reações do receptor – em suas atitu-
des ou em sua fala.
Existem várias possibilidades de comunicação entre os par-
ticipantes de um grupo colaborativo, portanto, fica a cargo do 
coordenador deste grupo analisar e definir a melhor e mais 
apropriada ferramenta de comunicação para cada etapa ou 
meta a ser cumprida.
As ferramentas de comunicação podem ser classificadas em 
síncronas ou assíncronas. As ferramentas síncronas possuem 
como característica a necessidade de interação em tempo 
real, ou seja, membros do grupo devem estar presentes ou 
conectados no momento em que ocorre a comunicação. Este 
tipo de ferramenta deve ser usado quando se espera a inte-
ração entre os participantes do grupo, visto que o tempo de 
resposta entre a ação de um participante e a reação de seus 
companheiros é curto. Já as ferramentas de comunicação as-
síncronas possuem como vantagem a interação entre pessoas 
sem que estas estejam conectadas ao mesmo tempo, ou seja, a 
mensagem desejada é enviada, e permanece disponível para 
conhecimento dos destinatários no momento em que estes se 
conectam. Devem ser utilizadas quando há a necessidade de 
uma melhor reflexão dos participantes, já que estes terão um 
maior tempo disponível antes de agir.
Como exemplos de ferramentas de comunicação podem 
ser incluídas e-mail, lista de discussão, fórum, ferramentas 
de votação, mensagem instantânea, chat, vídeo conferência e 
telefone, sendo que algumas serão detalhadas e exemplificadas 
no decorrer deste artigo.
16 Engenharia de Software Magazine - Desenvolvimento de Software Apoiado por Groupware
- Coordenação 
De forma a garantir que os objetivos traçados pelo grupo sejam 
alcançados, é necessário que haja uma boa coordenação das ati-
vidades a serem realizadas. Evitar que esforços de comunicação 
e cooperação sejam perdidos e que as tarefas sejam realizadas 
na ordem correta, de forma correta e no tempo correto, deve ser 
uma atribuição do coordenador do grupo. Além disso, devem 
ser identificados e mapeados em tarefas os objetivos do grupo, 
selecionados os participantes, distribuídas as tarefas entre eles 
e toda a realização destas deve ser coordenada. Outra responsa-
bilidade da coordenação a ser citada é o tratamento de conflitos 
que geralmente ocorrem devido a problemas de comunicação, 
percepção ou interpretação, para que estes não acarretem em 
competição, desorientação e problemas de hierarquia, que po-
dem vir a prejudicar o grupo. Deve-se ressaltar a importância 
dos membros do grupo e os coordenadores devem sempre ter 
ciência do trabalho que está sendo realizado pelos participantes, 
assim é possível identificar e evitar esforços duplicados em prol 
de um mesmo objetivo a ser alcançado e também se evita que 
algum membro fique sem trabalho ou com tempo ocioso.
Atividades colaborativas sem a presença de um coordenador 
apresentam um grande risco de que os participantes do grupo 
desviem-se do foco principal ou se envolvam em tarefas repe-
titivas e ou conflitantes.
Como exemplos de ferramentas para suporte a atividades 
de coordenação podem ser citadas: gerenciamento de fluxo 
de trabalho (workflow) e ferramentas de desenvolvimento de 
software colaborativo. 
- Cooperação 
É a ação conjunta dos membros do grupo, como produção, 
manipulação e organização de informações. 
É interessante que a maior parte do que for produzido pelo 
grupo seja armazenada, de forma a garantir uma “memória” 
do trabalho cooperativo que foi realizado. Essa “memória” 
poderá, posteriormente, fornecer auxílio, caso seja necessário 
checar os motivos ou ideias iniciais que levaram à tomada de 
alguma decisão para produção de um artefato ou mesmo no 
caso da necessidade de alterá-lo por mudança nos objetivos 
iniciais.
Podem ser utilizadas ferramentas para auxiliar o trabalho 
de cooperação que fornecem, por exemplo, registro e recupe-
ração de versões e controle e permissões de acesso. Entre as 
ferramentas para controle de versão enquadram-se o CVS e o 
SVN, que serão descritas no decorrer deste artigo.
- Percepção 
A percepção é o ato de adquirir informação. É essencial para 
a comunicação, coordenação e cooperação em um grupo de 
trabalho colaborativo.
Na interação entre pessoas face-a-face, a obtenção de infor-
mações é maior, já que os sentidos estão presentes em sua 
plenitude. Já em ambientes virtuais, o suporte à percepção é 
bem menor porque os meios de transmitir as informações aos 
órgãos sensoriais dos seres humanos são restritos. 
Uma interação que possibilita uma percepção de qualidade 
é capaz de fazer com que os participantes tenham disponíveis 
informações necessárias 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 família de aplicações baseadas em computador que dão 
suporte a grupos de pessoas engajadas em uma tarefa comum 
e que provêm uma interface para compartilhar o ambiente, 
especialmente ao nível de comunicação, colaboração e suporte 
à decisão. O uso de groupware permite que pessoas, mesmo 
estando em diferentes localidades possam compartilhar 
ideias e interesses comuns para a resolução dos problemas e 
objetivos do grupo.
Groupware pode ser considerado uma ferramenta desenvol-
vida a partir dos conceitos abordados em CSCW, que é a área 
que envolve o estudo de sistemas baseados em computador 
para auxílio ao trabalho cooperativo.
A utilização de ferramentas groupware nas organizações tem 
como principal objetivo a melhoria na eficácia administrativa, 
dando assistência na comunicação, colaboração e coordenação 
das atividades dos grupos.
Como exemplos de aplicações de groupware podem ser 
citados:
• Sistemas de e-mail: Permitem a troca de mensagens e arqui-
vos pelo grupo;
• Workflows: Permitem o acompanhamento do fluxo de trabalho 
e de informações da empresa;
• Sistemas de gerenciamento de documentos: Permitem o 
acesso de forma rápida aos documentos digitais da empresa;
• Reuniões eletrônicas: Permitem a realização de encontros 
dos membros do grupo colaborativo para a resolução de 
problemas;
• Sistemas de co-autoria e projeto: Permitem o desenvolvi-
mento simultâneo de documentos e projetos mesmo que os 
participantes do grupo estejam em locais distintos;
• Vídeo conferências: Permitem a realização de encontros 
através da transmissão simultânea de áudio e vídeo;
• Tele presença, avatares e realidade virtual: Permitem a cria-
ção de ambientes virtuais para que as pessoas possam interagir 
a partir de locais remotos.
As aplicações de groupware, levando em consideração as va-
riáveis ‘espaço’ e ‘tempo’ podem ser classificadas em quatro 
categorias, conforme exibido na Tabela 1.
As categorias podem ser descritas como:
• Interação facea face: Diz respeito às aplicações que são 
executadas de maneira síncrona, sendo que os membros do 
grupo de trabalho encontram-se em um mesmo local em um 
mesmo tempo. Como exemplo de aplicação, pode ser citado um 
sistema de autoria de projeto em grupo, que permite tanto a 
engenheiros como desenvolvedores manipularem um mesmo 
arquivo simultaneamente;
Edição 34 - Engenharia de Software Magazine 17 
ENGENhARIA DE SoFt WARE
• Interação Distribuída Síncrona: As aplicações que se en-
quadram nesta categoria necessitam da utilização de recursos 
de telecomunicações de forma a possibilitar a comunicação 
simultânea entre locais de trabalho diferentes. Enquadram-se 
nesta categoria os chats e vídeo conferências;
• Interação Assíncrona: Nas aplicações desta categoria, em-
bora os integrantes do grupo de trabalho estejam situados 
em um mesmo local, a interação ocorre em tempos distintos. 
Como exemplos podem-se citar o compartilhamento de com-
putadores e arquivos;
• Interação Distribuída Assíncrona: Diz respeito às aplicações 
que são utilizadas em tempos e espaços distintos por parte dos 
membros do grupo de colaboração. Estas aplicações têm como 
objetivo a distribuição e encaminhamento das informações. O 
e-mail é o principal exemplo desta categoria.
Desenvolvimento colaborativo de software e 
desenvolvimento de software colaborativo
O conceito de desenvolvimento colaborativo de software di-
fere do de desenvolvimento de software colaborativo levando-
se em consideração que, nem sempre, o primeiro tem como 
objetivo final a produção de software para ser usado para 
apoiar trabalhos colaborativos. Um projeto cujo processo de 
desenvolvimento ocorreu de forma colaborativa poderá ter 
como finalidade a utilização de uma única pessoa sem que 
haja colaboração no uso deste sistema. Já o desenvolvimento 
de software colaborativo tem como meta a criação 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 importância, pois diferentes habilidades são 
necessárias no decorrer do processo de desenvolvimento de 
software. Deve-se levar em consideração que a equipe de de-
senvolvimento e os clientes/usuários do sistema necessitarão 
de uma grande interação durante o decorrer do processo de 
desenvolvimento haja vista que os analistas precisam compre-
ender os requisitos propostos pelos clientes. Além disso, os 
arquitetos têm como papel verificar a melhor forma com que o 
sistema deverá ser feito, programadores têm o papel de passar 
para uma linguagem de programação o que foi especificado, 
sendo tudo isso coordenado e gerenciado pelos gerentes de 
projetos, além dos testes e adequações do sistema de acordo 
com o usuário final. 
Além da interação entre pessoas para o desenvolvimento de 
sistemas de forma colaborativa é importante ressaltar que estes 
sistemas provavelmente deverão oferecer interação com outros 
sistemas, elevando ainda mais o grau de colaboração que deve-
rá existir no decorrer do processo de desenvolvimento.
No desenvolvimento colaborativo de software, como as 
tarefas serão realizadas de forma distribuída e colaborativa, 
torna-se necessário que o escopo das mesmas seja claro e as 
TEMPO
ES
PA
ÇO
MESMO DIFERENTE
M
ES
M
O
Interação face a face Interação Assíncrona
DI
FE
RE
NT
E
Interação Distribuída Síncrona Interação Distribuída Assíncrona
tabela 1. Classificação das aplicações de groupware de acordo com 
espaço x tempo.
responsabilidades, atividades e papéis de cada participante 
do processo de desenvolvimento bem definidas, de forma a 
garantir o alcance dos objetivos inicialmente traçados. Uma boa 
gerência da equipe responsável pelo desenvolvimento colabo-
rativo de software é essencial para aumentar a produtividade 
e evitar o desperdício de recursos humanos.
No trabalho colaborativo de desenvolvimento é necessário 
um conjunto de reuniões para a coordenação 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 comunicação entre os integrantes da 
equipe.
Princípios básicos da programação extrema ou XP (eXtreme 
Programming), como simplicidade e comunicação, e práticas 
colaborativas como a programação em pares também facilitam 
o processo de desenvolvimento de software.
Embora possua muitas vantagens, fatores como comunicação 
ineficiente, dispersão geográfica, diferenças culturais, perda 
do espírito de equipe e falta de coordenação podem resultar no 
fracasso de um projeto se não forem tratados de forma correta 
durante o desenvolvimento colaborativo de software.
Tecnologias Colaborativas
Tecnologias colaborativas oferecem um grande auxílio no 
processo de desenvolvimento de sistemas. Como principais 
funções destas, pode-se citar o fornecimento de um canal de 
comunicação entre os participantes de um grupo, mecanis-
mos de armazenamento e acompanhamento de versões dos 
artefatos produzidos, ferramentas para controle de defeitos, 
ferramentas para auxílio na gerência de projetos e plataformas 
para desenvolvimento colaborativo, exemplificadas a seguir.
- Ferramentas de Comunicação
Para as ferramentas de comunicação, o uso da Internet 
torna-se indispensável e tal fato deve ser considerado ao 
adotá-las. Entre estas, pode-se citar as listas de discussão, 
18 Engenharia de Software Magazine - Desenvolvimento de Software Apoiado por Groupware
portais e comunidades virtuais, fóruns, mensagens ins-
tantâneas, chats, blogs e wikis. A seguir são apresentados 
alguns exemplos.
Para utilização de Listas de Discussão, o Mailman - Sistema 
para administração de listas de discussão ou newsletters – é de 
fácil configuração e administração via Web (Figura 1). Entre 
suas principais funcionalidades podem ser citados: filtros de 
conteúdo, arquivamento das mensagens enviadas para a lista, 
Figura 1. Página inicial do Mailman
Figura 2. Página da Comunidade JoomlaClube
Figura 3. Página de administração de site que usa WordPress
Figura 4. Página inicial da MediaWiki
moderação de membros e filtros anti-spam. É utilizado para 
gerenciar listas de projetos como SAMBA e KDE. 
Para apoio a criação de comunidades virtuais um exemplo é 
o JoomlaClube, Comunidade dedicada a tópicos relacionados 
ao CMS (Content Management System - Sistema Gerenciador de 
Conteúdo) Joomla, cuja página está exibida na Figura 2.
A criação de Fóruns pode ser apoiada pelo phpBB - Sistema 
gerenciador de fóruns em PHP - disponibilizado sob a licença 
GPL. É compatível com vários 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 instantâneas entre dois pontos distintos 
na Internet. Para usá-lo basta efetuar um registro no endereço 
http://register.jabber.org , baixar o software cliente e efetuar 
o login.
Para utilização de um blog, pode-se utilizar o WordPress, uma 
plataforma para publicação de conteúdo com foco na estética, 
nos Padrões Web e na usabilidade, livre e gratuito. A Figura 3 
exibe a página inicial de administração de um site que faz uso 
desta plataforma.
Já o MediaWiki é um software livre para criação de wikis, 
desenvolvido utilizando a linguagem PHP. Foi originalmente 
criado para ser usado na Wikipédia. A Figura 4 exibe a página 
inicial da MediaWiki, onde pode ser realizado o download 
do programa.
- Ferramentas para controle de versões
As ferramentas de controle de versão são de grande impor-
tância no desenvolvimento colaborativo de software, poispermitem modificações paralelas de forma padronizada e 
controlada, garantindo a integridade e também a rastreabili-
dade das modificações.
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 
código aberto, desenvolvido para suportar grupos de trabalho 
voltados para o desenvolvimento cooperativo de projetos, 
permitindo que múltiplos participantes possam efetuar, de 
forma independente e concorrente, alterações em suas cópias 
locais do objeto. 
Possui arquitetura cliente-servidor, onde o servidor é res-
ponsável por armazenar as versões atuais de um projeto, 
bem como seu histórico de alterações. Quanto ao cliente, este 
precisa conectar-se ao servidor para conseguir uma cópia do 
projeto original para, após isto, efetuar suas alterações. Com 
isso, torna-se necessário que ambos (cliente e servidor) estejam 
conectados por uma rede local ou mesmo pela Internet.
Após a confirmação das alterações 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 fusão 
de todas as alterações. Caso isto não seja possível, o servidor 
executará a primeira alteração e informará ao responsável pela 
última alteração que houve um conflito, sendo necessária a 
Edição 34 - Engenharia de Software Magazine 19 
ENGENhARIA DE SoFt WARE
intervenção humana. Já quando a validação das alterações é 
bem sucedida, a versão de cada arquivo envolvido no projeto é 
incrementada e o servidor armazena as alterações (data, autor 
e observação – se houver) em seu log.
Como há um controle rigoroso de versões e alterações por 
parte do CVS, caso seja necessário, é possível que os desen-
volvedores tenham acesso às versões anteriores do projeto 
desenvolvido sem quaisquer problemas.
Subversion: Também conhecido por SVN, é um sistema de 
controle de versão livre e de código aberto, criado para ser 
um ‘substituto’ do CVS. Gerencia arquivos e diretórios e as 
alterações feitas neles ao longo do tempo, permitindo que 
sejam recuperadas versões antigas dos dados, ou examinar o 
histórico 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 rápida, já que um mesmo arquivo pode ser alterado por 
múltiplas pessoas e, como o trabalho está versionado, caso 
haja alguma alteração incorreta realizada junto aos dados, é 
possível, simplesmente, desfazê-la.
Alguns sistemas de controle de versão servem apenas para a 
gestão de configuração de software (SCM - Software Configura-
tion Management). Estes sistemas são utilizados para gerência 
do código fonte e têm muitas características que são específicas 
para desenvolvimento de software, tais como compreensão de 
linguagens de programação ou fornecimento de ferramentas 
para a construção de software. O Subversion não é um desses 
sistemas, haja vista que o mesmo pode ser utilizado para ge-
renciar qualquer coleção de arquivos. 
- Ferramentas para controle de defeitos
Algumas ferramentas têm como função documentar e con-
trolar defeitos encontrados e suas respectivas correções. Elas 
são de grande importância para a qualidade e a produtividade 
no desenvolvimento colaborativo de sistemas, pois permitem 
o gerenciamento dos defeitos com capacidade de localização, 
confirmação e detecção de defeitos duplicados ou que não se 
aplicam à versão atual do arquivo que está sendo analisado.
Dentre as ferramentas para controle de defeitos no desenvol-
vimento 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. 
Além 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, além do registro de informações de erros, funciona-
lidades de priorização de atendimento, assinalando os erros 
aos participantes apropriados, configuração de dependências 
entre os erros e ainda possibilita a revisão de código.
Scarab: Ferramenta para rastreamento de erros em Java, 
a qual é de fácil instalação, porém sua interface Web não é 
muito elaborada. 
- Ferramentas para gerência de projetos
O uso de ferramentas para gerência de projetos possibilita 
que as informações sobre os projetos desenvolvidos estejam 
disponíveis para toda a equipe envolvida, o que aumenta a 
qualidade do gerenciamento e facilita o alcance dos objetivos 
traçados. Ferramentas que se enquadram nesta categoria 
possuem também como característica a disponibilização das 
informações sobre controle e acompanhamento do projeto de 
forma rápida e eficiente. Como exemplos podem ser citados o 
Microsoft Project e o dotProject.
Microsoft Project: Software comercial desenvolvido pela 
Microsoft para auxiliar na gestão de projetos. Esta ferramenta 
disponibiliza, além de diversos relatórios, gráfico de Gantt, 
diagramas de custos, datas e duração do projeto, dentre outros. 
Outra grande vantagem é o fato desta ferramenta possuir uma 
interface bastante amigável e similar aos outros produtos que 
são 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 não somente para os projetos de desenvolvimento de 
software, como projetos de engenharia civil, por exemplo.
dotProject: É um software livre para gerência de projetos. 
Diferentemente do Microsoft Project, é uma aplicação web 
cujo acesso é realizado através de um browser, desenvolvido 
utilizando a linguagem PHP, e faz uso do banco de dados 
MySQL. Essa ferramenta possibilita o cadastro e visualização 
de todas as tarefas necessárias para a execução de um projeto 
e qual parte desta já foi realizada. Também possui diagrama 
de Gantt, definição de responsáveis por cada tarefa, lembretes 
sobre os prazos e repositório de arquivos. Pode ser utilizado 
para gerenciar projetos dos mais diversos tipos, e não apenas 
os de desenvolvimento de software.
No Brasil há uma comunidade onde são discutidos assuntos 
de interesse sobre o dotProject que possui um site (http://
www.dotproject.com.br/) e uma lista de discussão de suporte 
técnico (http://listas.softwarelivre.org/cgi-bin/mailman/
listinfo/dotproject-br).
- Plataformas para desenvolvimento colaborativo
Para o desenvolvimento colaborativo de software, além das 
ferramentas anteriormente apresentadas, existem também as 
plataformas para desenvolvimento de software colaborativo 
que, em sua maioria, englobam todas as funcionalidades das 
ferramentas de comunicação, gerência, controle de versões 
e de erros. Dentre as existentes, serão citadas: SourceForge, 
Launchpad e GoogleCode, de uso gratuito.
SourceForge: Plataforma para desenvolvimento e distribui-
ção de software de código aberto que pertence e é operado pela 
20 Engenharia de Software Magazine - Desenvolvimento de Software Apoiado por Groupware
Geeknet Inc., com sede nos EUA. Além de ser um software de 
controle de desenvolvimento colaborativo, oferece uma interfa-
ce para acompanhamento do ciclo de vida no desenvolvimento 
de software e pode ser integrado a outras aplicações de código 
aberto como PostgreSQL e CVS. 
Launchpad: Plataforma para desenvolvimento colaborativo 
de software que provê as seguintes funcionalidades: bug tra-
cking, hospedagem e revisão de código, traduções, listas de 
email e FAQs. 
Google Code: Projetodesenvolvido pelo Google que oferece 
serviço de hospedagem para desenvolvimento de software com 
sistema para controle de versão, sistema de issuetracking, wiki 
para documentação e 100MB para download. Além disso, o site 
contém código-fonte aberto e uma lista com várias APIs públicas 
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 serviços do Google.
Conclusão
É cada vez maior o número de empresas que estão distribuin-
do seus processos de desenvolvimento de software em cidades, 
estados ou países 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 comunicação e coordenação são 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 impac-
tos causados por estes problemas. Além 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 caráter cooperativo. Através da utilização 
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 traçado.
Mailman
http://www.gnu.org/software/mailman/index.html
JoomlaClube
http://www.joomlaclube.com.br/site/comunidade.html
phpBB
http://www.phpbb.com/
Jabber
http://www.jabber.org/
WordPress
http://wordpress.com/
MediaWiki
http://www.mediawiki.org/wiki/MediaWiki
Bugzilla
http://www.bugzilla.org/
Scarab
http://scarab.tigris.org/
Microsoft Project
http://www.microsoft.com/project
dotProject
http://dotproject.net/
SourceForge
http://sourceforge.net
Launchpad
https://launchpad.net/
Google Code
http://code.google.com/intl/pt-BR/
Links
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
Launchpad
https://launchpad.net/
Google Code
http://code.google.com/intl/pt-BR/
Referências 
Dê seu feedback sobre esta edição!
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, através do link:
www.devmedia.com.br/esmag/feedback
D
ê 
se
u Fe
edback
so
b
re esta edição
Edição 34 - Engenharia de Software Magazine 21 
Mateus Maida Paduelli
É bacharel e mestre em computação pela 
Universidade de São Paulo. Já atuou em di-
versas organizações com o tema manuten-
ção de software e atualmente é servidor 
público federal.
De que se trata o artigo?
Apresentaremos neste artigo algumas alternati-
vas de respostas para os problemas de manuten-
ção apresentados no artigo sobre manutenção de 
software apresentado na edição anterior. Estas 
alternativas estão embasadas em três fontes 
distintas: na norma ISO/IEC 12207, nas soluções 
encontradas na organização analisada no estudo 
de caso, e nas propostas de outros autores que se 
dedicaram ao assunto.
Para que serve?
Este texto é indicado para aqueles profissionais 
que atuam com manutenção de software no seu 
dia-a-dia e que desejam entender melhor os atu-
ais desafios em torno desse tema.
Em que situação o tema é útil?
A manutenção de software é hoje um assunto pre-
sente em organizações que desenvolvem e man-
tém software. Isso se deve à necessidade de sem-
pre ajustar e melhorar o produto de software de 
acordo com as mais diversas necessidades. Diante 
desse fato, entender o significado e abrangência 
do termo manutenção de software pode auxiliar 
organizações e profissionais interessados no tema 
a melhor conduzir seus esforços quando precisam 
manter seus produtos.
Alternativas para redução de problemas na 
manutenção de software
Engenharia
Nesta seção você encontra artigos voltados para testes, processo, 
modelos, documentação, entre outros
Na edição 33 da Engenharia de Software Magazine, conhece-mos as características, tipos e 
desafios para a manutenção de software. 
Além disso, destacamos também as difi-
culdades encontradas na realização das 
atividades de manutenção de software. 
Para isso, um estudo de observação 
que foi conduzido com o objetivo de 
verificar os problemas de manutenção 
de software existentes em uma organi-
zação empenhada no desenvolvimento 
de software comercial.
22 Engenharia de Software Magazine - Alternativas para redução de problemas na manutenção de software
Dando continuidade à discussão sobre o assunto, apresen-
taremos neste artigo algumas alternativas de respostas para 
os problemas de manutenção apresentados na edição anterior. 
Estas alternativas estão embasadas em três fontes distintas: na 
norma ISO/IEC 12207, nas soluções encontradas na organização 
analisada no estudo de caso, e nas propostas de outros autores 
que se dedicaram ao assunto.
Acredita-se que a norma seja um excelente veículo para con-
duzir uma organização de software pelas melhores práticas, já 
que seu conteúdo é resultado de um esforço fundamentado no 
que poderia se chamar estado-da-arte da engenharia de sof-
tware. Outra consideração importante diz respeito à maneira 
como a norma se apresenta. Ela não é 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 alcançado. 
Dessa forma, a norma funciona como um guia para ser seguido 
por organizações interessadas em tratar sistematicamente seu 
processo de software.
O estudo de caso apresentado no artigo da edição passada 
será estendido neste artigo, expondo agora práticas adotadas 
pela organização que trouxeram resultados satisfatórios para 
a prevenção ou contenção de problemas de manutenção de 
software em seu ambiente de trabalho. 
Extensão do Estudo de Caso
Neste tópico é apresentada a extensão do estudo de caso 
apresentado no artigo publicado na Engenharia de Software 
Magazine edição 33.
Essa extensão foi possível graças à constatação de que a 
organização estava em busca freqüente por melhorias em 
seu ambiente de trabalho, e em sua capacidade de resposta 
satisfatória aos clientes, que vinham crescendo em número, 
sem, no entanto, valer-se da adoção de um processo extenso e 
sistemático como o sugerido pela norma ISO/IEC 12207. 
O objetivo foi verificar quais mudanças a organização vinha 
adotando no seu dia-a-dia que estivessem contribuindo positi-
vamente para a diminuição de seus problemas de manutenção 
de software, ou ainda, o que os profissionais empenhados 
nessa atividade achavam que deveria ser feito para que essa 
redução ocorresse.
Metodologia
A metodologia aplicada na extensão do estudo de caso também 
foi baseada em questionários e entrevistas. O intuito principal 
desses questionários foi o de servirem para a abertura de uma 
discussão na qual exemplos de soluções eficientes fossem cita-
dos pelos entrevistados. Como o objetivo era que a organização 
mostrasse quais atitudes vinha adotando para tratar de maneira 
satisfatória sua atividade de manutenção, não havia como 
estipular questões prévias, por isso o questionário reduzido 
funcionou somente como recurso para início de entrevista. 
De fato, as soluções citadas, bem como observações e todas 
as informações relevantes