EDITORIAL

D
iversas metodologias de desenvolvimento de software voltadas para o con-
trole têm sido elaboradas uma vez que um projeto de software, ao longo do
seu ciclo de vida, tem uma grande quantidade de itens de informação tais
como documentos, código-fonte, dados, manuais e outros, produzidos e até modifi-
cados, pelos mais diversos motivos.
Para que a qualidade do software seja garantida, em função destas modificações, é
Ano 2 - 24ª Edição - 2010 Impresso no Brasil necessário que se faça uso da Gerência de Configuração de Software (GCS). A Gerên-
cia de Configuração de Software tem como objetivo gerenciar e controlar a evolução
de um software através do controle formal de versão e solicitação de mudanças. É
Corpo Editorial uma forma sistemática e organizada de controlar as modificações de um software
tornando possível manter sua integridade ao longo do tempo. A quantidade de itens
Colaboradores que podem estar sob controle da GCS e os níveis de controle exigidos sobre estes
Rodrigo Oliveira Spínola itens irá variar de empresa para empresa ou mesmo de projeto para projeto. Sendo
rodrigo@sqlmagazine.com.br assim, o uso desta prática em conformidade com modelos de maturidade mantidos
Marco Antônio Pereira Araújo por entidades que possuam credibilidade nacional e internacional, e também o uso
Eduardo Oliveira Spínola de ferramentas adequadas que garantam a qualidade deste processo, é fundamental
para que uma empresa obtenha êxito e reconhecimento.
Capa e Diagramação
Para empresas de grande porte, isto não chega a ser um grande problema pois
Romulo Araujo - romulo@devmedia.com.br
normalmente se dispõem de capital e pessoal qualificado para manter tais práticas.
Coordenação Geral Entretanto, quando voltamos a olhar para as pequenas empresas, o cenário é exata-
Daniella Costa - daniella@devmedia.com.br mente o oposto.
Neste contexto, a Engenharia de Software Magazine destaca nesta edição uma ma-
Revisor e Supervisor téria cujo objetivo é mostrar uma solução especifica, de boa qualidade e baixo custo,
Thiago Vincenzo - thiago.v.ciancio@devmedia.com.br
que atenda as exigências dos modelos de maturidade e que possa ser utilizada para
Na Web implementar a Gerência de Configuração de Software em pequenas empresas. Uma
www.devmedia.com.br/esmag leitura muito interessante.
Além desta matéria, esta edição traz mais seis artigos:
• Automatizando Testes Funcionais em Aplicações Web
Apoio
• Testes de segurança
• A Comunicação no Processo de Software
• Testes funcionais automatizados com Hudson e Selenium RC
• Medição de Software
• Análise Quantitativa de Riscos e suas Técnicas

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 Rodrigo Oliveira Spínola
algum esclarecimento sobre assinaturas, exemplares anteriores, endereço de rodrigo@sqlmagazine.com.br
bancas de jornal, entre outros, entre em contato 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
Cristiany Queiróz– Atendimento ao Leitor (UNIFACS, 2001). Colaborador da Kali Software (www.kalisoftware.com), tendo minis-
www.devmedia.com.br/mancad
(21) 2220-5338 trado cursos na área de Qualidade de Produtos e Processos de Software, Requisitos e
Kaline Dolabella Desenvolvimento Orientado a Objetos. Consultor para implementação do MPS.BR. Atua
Gerente de Marketing e Atendimento como Gerente de Projeto e Analista de Requisitos em projetos de consultoria na COPPE/
kalined@terra.com.br
(21) 2220-5338 UFRJ. É Colaborador da Engenharia de Software Magazine.

Marco Antônio Pereira Araújo - Editor

Publicidade
(maraujo@devmedia.com.br)
Para informações sobre veiculação de anúncio na revista ou no site entre em
Doutor e Mestre em Engenharia de Sistemas e Computação pela COPPE/UFRJ - Li-
contato com:
nha de Pesquisa em Engenharia de Software, Especialista em Métodos Estatísticos
Kaline Dolabella
publicidade@devmedia.com.br 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
Fale com o Editor!
do Centro de Ensino Superior de Juiz de Fora, Professor do curso de Bacharelado em
É muito importante para a equipe saber o que você está achando da revista: que tipo de artigo
Sistemas de Informação da Faculdade Metodista Granbery, Professor e Diretor do Cur-
você gostaria de ler, que artigo você mais gostou e qual artigo você menos gostou. Fique a
so Superior de Tecnologia em Análise e Desenvolvimento de Sistemas da Fundação
vontade para entrar em contato com os editores e dar a sua sugestão!
Educacional D. André Arcoverde, Analista de Sistemas da Prefeitura de Juiz de Fora,
Se você estiver interessado em publicar um artigo na revista ou no site SQL Magazine,
Colaborador da Engenharia de Software Magazine.
entre em contato com os editores, informando o título e mini-resumo do tema que você
gostaria de publicar:
Eduardo Oliveira Spínola
(eduspinola@gmail.com)
Rodrigo Oliveira Spínola - Colaborador
É Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Ma-
editor@sqlmagazine.com.br
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).
 Caro Leitor
Caro Leitor,
Para esta edição, temos um conjunto de 4 vídeo aulas. Estas vídeo aulas estão disponíveis para download no Portal da En-
genharia de Software Magazine e certamente trarão uma significativa contribuição para seu aprendizado. A lista de aulas
publicadas pode ser vista abaixo:

Tipo: Validação,Verificação & Teste

Título: Estratégia de Teste Funcional baseada em Casos de Uso Parte I -
Explorando Casos de Uso para apoiar Testes
Autor: Arilo Claudio Dias Neto
Mini-Resumo: Nesta vídeo-aula é apresentado como preparar um modelo de casos
de uso e suas especificações para apoiar nas atividades de teste. São apresentadas as
informações que devem compor a especificação de um caso de uso e em seguida um
template de especificação de casos de uso. Ao final, é apresentado um processo para
apoiar no projeto de testes de software a partir de casos de uso.
Tipo: Validação,Verificação & Teste
Título: Estratégia de Teste Funcional baseada em Casos de Uso Parte II -
Projeto dos Testes a partir de Casos de Uso
Autor: Arilo Claudio Dias Neto
Mini-Resumo: Nesta vídeo-aula é apresentado com detalhes o processo para
apoiar no projeto de testes de software a partir de casos de uso, citado na aula
anterior. Ele é formado por uma sequência de 4 passos que vão desde a identi-
ficação dos atores de um modelo de casos de uso até a construção de casos e
procedimentos de testes. Nesta vídeo-aula são apresentados apenas os 3 primeiros
passos deste processo.
Tipo: Validação,Verificação & Teste
Título: Estratégia de Teste Funcional baseada em Casos de Uso Parte III -
Projeto dos Testes a partir de Casos de Uso
Autor: Arilo Claudio Dias Neto
Mini-Resumo: Nesta vídeo-aula é apresentado com detalhes o último passo que
compõe o processo para apoiar no projeto de testes de software a partir de casos de
uso: a alocação de casos e procedimentos de teste. Para isso, é seguido um caso de uso
de exemplo (REALIZAR DEPÓSITO) e passamos por todas as etapas para construção dos
testes.Neste momento utilizamos os critérios para geração dos testes (particionamento
por equivalência, análise do valor limite e grafo de causa-efeito) apresentados em
aulas anteriores.
Tipo: Validação,Verificação & Teste
Título: Estratégia de Teste Funcional baseada em Casos de Uso Parte IV – Exercício
Autor: Arilo Claudio Dias Neto
Mini-Resumo: Nesta vídeo-aula é apresentado um outro exemplo de construção de
testes de software a partir de casos de uso (CADASTRAR FUNCIONÁRIO).Com isso,ficam
disponíveis 2 exemplos com características diferentes a fim de facilitar o aprendizado.
Ao final,são deixados pontos em aberto para que quem estiver acompanhando as aulas
possa dar continuidade ao projeto dos testes, como um exercício.

ÍNDICE
Engenharia

06 - Testes de segurança
Eduardo Habib

14 - Gerência de Configuração
Alberto Boller Filho, Rodrigo Oliveira Spinola, Marcelo Nascimento Costa e Marcos Kalinowski

31 - Medição de Software
Monalessa Perini Barcellos

Agilidade
38 - A Comunicação no Processo de Software
Márcia Regina Simm Cantú

Planejamento e Gerência
43 - Análise Quantitativa de Riscos e suas Técnicas
Marcio Souza, Cristine Gusmão e Hermano Perrelli

Desenvolvimento
49 - Automatizando Testes Funcionais em Aplicações Web
Arilo Cláudio Dias Neto

57 - Testes funcionais automatizados com Hudson e Selenium RC

Fabrício Nogueira de Almeida, Victor Vidigal Ribeiro e Marco Antônio Pereira Araújo

4 Engenharia de Software Magazine

Edição 05 - Engenharia de Software Magazine 5
Engenharia
Nesta seção você encontra artigos voltados para testes, processo,
modelos, documentação, entre outros

Testes de segurança
Testes de segurança em aplicações web

De que se trata o artigo? Para que serve?

Eduardo Habib
eduardohabib@gmail.com
Possui Graduação e mestrado em Ciência da
Computação na UFMG. Atua na área de testes
de software há nove anos. Nesses anos teve
experiência no planejamento, especificação
e execução de testes manuais, automação
de testes, testes de desempenho e testes de
Neste artigo veremos a importância de se reali-
zar testes de segurança em aplicações Web. Ao
desenvolver uma aplicação web, deve-se pensar
na segurança dos dados durante toda a fase de
desenvolvimento. Isso minimiza as falhas de se-
gurança que chegam ao usuário final. Esse artigo
tratará dos testes de segurança realizados pelo
testador após o software já estar desenvolvido.
Será demonstrada a importância de se realizar
testes em aplicações web, as falhas de segu-
rança mais comuns na Internet e, por fim, serão
demonstradas extensões do Firefox e algumas
ferramentas que auxiliam nos testes de aplica-
ções web.
A realização de testes de segurança em aplicações
Web diminui a probabilidade de um software ser dis-
ponibilizado para o usuário final com falhas críticas de
segurança e que podem causar prejuízos ao usuário,
seja ele financeiro ou a liberação de dados sigilosos.
Em que situação o tema é útil?
Testar a segurança de aplicações Web é importante
em qualquer aplicação que contenha dados sigilosos
e/ou onde ocorra, de alguma forma, transações finan-
ceiras entre o cliente e o servidor, pois diminuem a
probabilidade do software ser colocado em produção
com uma falha crítica de segurança e que pode vir a
ser explorada por alguma pessoa mal intencionada.

segurança. Possui três anos de experiência le-
cionando no ensino superior. Freqüentemente
ministra treinamentos e/ou palestras relacio-
nados a testes de software já tendo, inclusive,
ministrado a disciplina de Testes de Software
na PUC Minas. Possui as certificações CQA -
Certified Quality Assurance da IBM e CTFL do
BSTQB. Atualmente é Gerente de testes no
SYNERGIA - DCC/UFMG.
A
segurança dos softwares de­
senvolvidos atualmente está
se tornando um ponto cada vez
mais importante a ser testado. Entretan­
to, testar a segurança de um software
é algo muito complexo e custoso. Por­
tanto, os testes de segurança devem ser
focados nos pontos onde a segurança
tem uma probabilidade maior de ser
comprometida.
Nesse artigo será demonstrada a im­
portância de se realizar testes de segu­
rança em aplicações web. Serão apresen­
tadas quais as falhas de segurança são

6 Engenharia de Software Magazine - Testes de segurança

 Validação, Verificação & Teste
mais comuns em aplicações web e algumas ferramentas livres
que auxiliam nesses testes.
Testes de segurança
No início da internet existiam apenas sites estáticos. Os
sites existentes desempenhavam papel apenas de repositó­
rios de informações que continham documentos estáticos,
e os navegadores web foram criados como uma forma de
visualização desses documentos. A maioria dos sites não
autenticava usuários porque não havia necessidade já que
a mesma informação era exibida para todos os usuários. Se
um invasor comprometesse um servidor, ele normalmente
não ganhava acesso a nenhuma informação confidencial,
visto que toda a informação já estava liberada para o
público. No máximo, o invasor poderia escrever algum
conteúdo no site ou utilizar o servidor como repositório
de arquivos.
Hoje em dia a internet é completamente diferente. A
maioria dos web sites são aplicações complexas e possuem
um fluxo de informações nos dois sentidos (servidor e
navegador). Elas suportam login, transações financeiras e
acesso a dados pessoais. O conteúdo exibido para os usu­
ários geralmente é gerado dinamicamente e muitas vezes
é específico para cada usuário. Muitos dos dados proces­
sados, e exibidos, são pessoais. A segurança é, portanto,
uma grande questão: ninguém utilizará uma aplicação web
caso acredite que suas informações confidenciais serão
exibidas para terceiros.
Atualmente, para as aplicações web proverem as funcio­
nalidades mais básicas, muitas vezes é necessário acessar
sistemas internos da empresa e esses sistemas, muitas
vezes, contêm dados sigilosos. Uma falha em uma dessas
aplicações web pode comprometer todo o servidor. Um
invasor que conseguir comprometer a aplicação web pode
roubar informações pessoais e com isso realizar ações
maliciosas contra os outros usuários.
Tanto as empresas desenvolvedoras de software quanto
os usuários finais têm grande interesse na segurança das
aplicações: as empresas, devido à necessidade de aumentar
o faturamento com comércio na internet, os usuários por­
que eles terão mais segurança para utilizar aplicativos.
Por que fazer testes de segurança?
Apesar de recentemente ter havido uma aumento da pre­
ocupação com segurança, notícias de invasões continuam
no noticiário e o número de incidentes de segurança tem
aumentado ano a ano.
Segundo dados divulgados pelo Centro de Estudos, Res­
posta e Tratamento de Incidentes de Segurança no Brasil
(CERT.br), e que podem ser visualizados na Figura 1, em
2009 foram registradas 358.343 notificações de incidentes
de segurança. Isso representa um aumento de 61% em
relação a 2008 e de 11530% em relação ao número de inci­
dentes registrados em 1999, primeiro ano da medição. Esses
números são coerentes com outro estudo publicado pela
Gartner, em que se estima que os ataques contra os sistemas
do departamento de defesa dos EUA foram 60% maiores em
2009, se comparados com o ano anterior.
Além do aumento do número de invasões que podem ser
visualizados na Figura 1, um estudo publicado pela Univer­
sidade de Michigan, revelou que mais de 75% dos sites de
bancos, que são os que mais investem em segurança, não são
inteiramente seguros como dizem ser e estão sujeitos a falhas
de segurança. Outro estudo, do instituto de pesquisa WhiteHat
Security, publicou dados demonstrando que cerca de 64% dos
1364 sites de companhias avaliados possuíam pelo menos uma
falha de segurança crítica.
Figura 1. Total de incidentes reportados ao CERT.br
Isso é muito crítico para as empresas já que o aumento do
faturamento das empresas que comercializam produtos na
web está diretamente ligado à sua reputação. Poucas pessoas
gostariam de fazer negócio com um site inseguro e, devido a
isso, as organizações não costumam publicar detalhes sobre
a segurança de seus dados, ataques sofridos e vulnerabili­
dades, com o objetivo de não adquirir uma má reputação.
Por isso, os números podem ser ainda mais alarmantes do
que os publicados pelo CERT.br.
Dentre os diversos fatores que influenciam o aumento
do número de incidentes de segurança, como a maior
popularização da internet pelo mundo e o surgimento de
ferramentas que auxiliam nesses ataques, deve-se destacar
outro fator que contribui para o aumento dos ataques: a
evolução constante da tecnologia utilizada nas aplicações
web. Como a tecnologia utilizada no desenvolvimento de
aplicações web evolui muito rapidamente, as aplicações web
trazem consigo, a todo o momento, uma nova variedade de
falhas de segurança. Novos ataques, que antes do desen­
volvimento da aplicação não eram conhecidos, são criados
após o desenvolvimento e podem ser exploradas até serem
corrigidos.
Alguns problemas, como a injeção SQL têm diminuído a
frequência de ocorrência conforme os desenvolvedores se
conscientizam deles. Entretanto, a introdução cada vez mais
Edição 24 - Engenharia de Software Magazine 7
frequente de novas tecnologias possibilita novas possibilidades
de exploração.
Existem diversas e excelentes ferramentas proprietárias
que auxiliam no teste de segurança de aplicações web. Con­
tudo, a maioria dessas ferramentas comerciais possui um
custo bastante elevado. Esse artigo se concentrará, então, na
apresentação de extensões para navegadores e ferramentas
Open Source que ajudam os testadores e especialistas em
segurança nos testes de segurança de aplicações web.
Principais falhas e a utilização de SSL
Conforme pôde ser visto na seção anterior, o número de
incidentes de segurança vem aumentando a cada ano e a
maioria dos sites possui problemas de segurança. Em con­
traste com esses dados, ao consultar a página de FAQ de
uma aplicação típica da web, o usuário será “tranquilizado”
que ela é segura pelo fato do site utilizar a tecnologia SSL.
Os usuários são frequentemente convidados a verificar
o certificado do site, comprovar os avançados protocolos
criptográficos em uso, e, com isso, é levado a confiar que
suas informações pessoais estão em boas mãos. Indepen­
dentemente de estar ou não utilizando SSL, a maioria das
aplicações web ainda contém falhas de segurança, falhas
essas que não têm nada a ver com a utilização ou não de
SSL. A utilização da tecnologia SSL é importante porque
ela protege a integridade do dado durante a transição entre
o navegador do usuário e o servidor web. Entretanto, SSL
não irá impedir os ataques que comprometem diretamente
os servidores ou os clientes de uma aplicação como ocorre
na maioria dos ataques.
Segue abaixo algumas falhas que não são resolvidas com a
utilização de SSL e na Figura 2, sua frequência de ocorrência
segundo STUTTARD:
• Falha de autenticação: Essa falha ocorre quando as creden­
ciais de acesso ao site não são protegidas adequadamente;
• Falha no controle de acesso: Essa falha envolve casos onde
a aplicação não consegue proteger o acesso aos seus dados
e funcionalidades, permitindo que o invasor veja dados
privados de outro usuário e acione comandos aos quais ele
não tem acesso;
• Injeção SQL: Essa falha ocorre quando a aplicação permite
que o invasor injete comandos no banco de dados utilizando,
para isso, a aplicação;
• Cross-Site Scripting: Cross-Site Scripting (XSS) é uma
falha em que se permite ao atacante inserir código (ex: Java
Script ou tags HTML) em páginas Web, visando conseguir
informações de outros usuários ou acessos restritos;
• Vazamento de informações: Essa falha ocorre quando
as aplicações divulgam, sem intenção, informações sobre
suas configurações, processos internos ou privacidade
devido a problemas na aplicação. Isso é muito crítico, pois
a divulgação de informações sobre a versão do servidor
de aplicação ou do banco de dados utilizado, por exemplo,
pode indicar ao invasor quais as falhas às quais a aplicação
está vulnerável.
8 Engenharia de Software Magazine - Testes de segurança
O principal problema das aplicações web é que, como a aplicação
não tem como garantir quais entradas os clientes irão submeter,
pode-se submeter entradas arbitrárias, mesmo que a aplicação
faça tratamento no cliente para evitar isso. Portanto, qualquer
aplicação web deve considerar que todos os usuários são poten­
ciais invasores e devem tomar medidas para evitar que pessoas
mal intencionadas utilizem essas entradas para comprometer a
aplicação. Esse problema se manifesta de várias formas:
• Usuários podem interferir em qualquer conjunto de dados
transmitidos entre o cliente e o servidor, incluindo requisições,
cookies e cabeçalhos HTTP. Qualquer controle implementado
do lado do cliente, como validações de entradas podem ser fa­
cilmente burladas;
• As requisições podem ser enviadas pelos usuários em qualquer
sequência. Qualquer suposição relativa à ordem como as requisi­
ções serão feitas pelos usuários pode ser burlada;
• Não se deve supor que os usuários utilizarão o navegador para
interagir com a aplicação. Existem várias ferramentas que permi­
tem a interação com um servidor, sem a utilização do navegador.
Essas ferramentas permitem que se façam requisições que não
seriam possíveis caso fosse utilizado um navegador comum.
Figura 2. Frequência de incidencia das principais falhas na Web
Existem ferramentas que testam automaticamente um conjunto
grande de entradas visando encontrar falhas. Alguns exemplos
de entradas enviadas são:
• Modificação de um valor transmitido em um campo escondido
do HTML (hidden);
• Modificação de um token da sessão, para roubar a sessão de
outro usuário autenticado;
• Remoção de certos parâmetros que são normalmente submeti­
dos, para explorar falhas de lógica na aplicação;
• Alterar alguma entrada para tentar fazer um acesso ao banco
de dados.
Nas próximas seções serão apresentadas ferramentas livres e
que podem ser utilizadas para realizar os testes de segurança
em aplicações web.
Montando seu ambiente de testes com ferramentas livres
Alguns ataques a aplicações web podem ser executadas usan­
do apenas um navegador web padrão. Entretanto, para que o
 Validação, Verificação & Teste

teste de segurança seja mais efetivo, exige-se a é convidado a encontrá-la e, caso o testador não a encontre, o WebGoat
utilização de ferramentas adicionais para que seja permite a solicitação de dicas para a identificação da falha. Caso não se
possível encontrar mais falhas de segurança. Mui­ consiga identificar a falha, após dicas de como encontrá-la, é possível
tas dessas ferramentas funcionam em conjunto ainda consultar uma descrição da solução. Se mesmo assim o testador não
com o navegador, quer como extensões que modi­ entender como encontrar a falha, pode-se consultar vídeos demonstrando
ficam a sua funcionalidade, ou como ferramentas passo a passo como identificá-la. O WebGoat é uma aplicação de extrema
externas que funcionam ao lado do navegador e necessidade, principalmente para iniciantes nos testes de segurança e que
modificam sua interação com o aplicativo alvo. querem aprender a realizar alguns testes. Os exemplos de utilização das
Para testar uma aplicação procurando por falhas ferramentas e extensões para navegadores apresentadas nesse artigo foram
de segurança é necessário ter domínio sobre essas feitos utilizando-se o WebGoat como aplicação alvo.
ferramentas. Nas próximas sessões, serão citadas
algumas extensões para o Firefox e ferramentas Navegadores
livres utilizadas para auxiliar o testador durante Um navegador web não é exatamente uma ferramenta hacker. Porém, a
os testes de segurança. escolha pelo navegador utilizado pode auxiliá-lo no teste a uma aplicação
web. O Firefox é, hoje, o segundo navegador mais utilizado do mundo
Ferramentas necessárias para a realização compreendendo, segundo alguns estudos, cerca de 25% do mercado e
dos testes possui diversas extensões que auxiliam o testador no teste de segurança
A primeira ferramenta que o testador deve de uma aplicação web. Abaixo iremos descrever algumas das extensões
possuir para realizar os testes, além do próprio que podem auxiliar nessa tarefa.
navegador, é um Proxy interceptador. Um Proxy • FoxyProxy: Permite o gerenciamento das configurações de proxy do
interceptador permite visualizar e modificar navegador, possibilitando a troca rápida entre os proxies utilizados,
todas as mensagens HTTP que passam entre o realização de configurações de Proxies diferentes para URLs diferentes.
navegador e a aplicação. Como os Proxies são ferramentas essenciais em testes de aplicações web,
Atualmente, além dos Proxies básicos existem
suítes que se tornaram muito poderosas por
possuírem, além dos Proxies, um conjunto de
outras funções projetadas para ajudá-lo no ataque
a aplicações web.
A segunda categoria principal de ferramenta é
conhecida como Web Spider. Essas ferramentas
agem solicitando páginas web, analisando os links
para outras páginas, e em seguida, solicitando
essas páginas. Eles continuam recursivamente até
que todo o conteúdo de um site seja descoberto.
A terceira categoria principal de ferramenta é o
Scanner de aplicação web. Essas ferramentas são
concebidas para automatizar muitas das tarefas
envolvidas no ataque a uma aplicação web reali­
zando desde o mapeamento inicial até a sondagem
por vulnerabilidades. Essas ferramentas fazem
uma busca automática por toda a aplicação subme­
tendo dados e analisando as respostas para, com
isso, tentar encontrar automaticamente falhas de
segurança conhecidas.
A quarta categoria principal de ferramenta ne­
cessária, principalmente quando o testador quer
realizar alguns testes em seu ambiente, é uma
aplicação cheia de falhas onde ele possa fazer
alguns experimentos. Essa aplicação existe. O
WebGoat é uma aplicação Web Open Source do
projeto OWASP. Nessa aplicação as falhas foram
inseridas propositalmente e seu principal objetivo
é ser um laboratório onde o testador aprende, na
prática, as principais vulnerabilidades encontra­
das em aplicações Web. Para cada falha, o usuário

Edição 24 - Engenharia de Software Magazine 9

visto que eles permitem interceptar todas as requisições e
respostas e modificá-las, e, além disso, muitas vezes utiliza-
se mais de um Proxy durante o teste, essa extensão é impor­
tante para agilizar esse processo de seleção e modificação
do Proxy utilizado;
• Tamper Data: extensão do Firefox que permite interceptar
e modificar as requisições HTTP enviadas e recebidas pelo
navegador;
• LiveHTTPHeaders: É uma extensão do Firefox que permite
visualizar os cabeçalhos HTTP enviados ao servidor web
ou os que são recebidos do servidor;
• Edit Cookies: permite adicionar e modificar valores e
atributos dos cookies;
• CookieWatcher: permite que o valor do cookie seja moni­
torado na barra de status.
Muitas vezes é possível modificar o seu navegador para
ajudá-lo no ataque de uma aplicação:
• Se a aplicação não utilizar cookies para armazenar tokens
de sessão, pode-se utilizar vários processos do mesmo na­
vegador, cada um com uma sessão diferente sobre o pedido.
Por exemplo, quando estiver testando o controle de acesso,
pode-se utilizar uma instância do navegador logada com um
usuário com mais privilégio e outra logada com uma sessão
com um usuário com poucos previlégios e assim, testar rapi­
damentte a aplicação com poucos pedidos de visitas;
• É possível limpar os dados que um navegador guarda
sobre alguma aplicação (principalmente dentro de cookies
e cache) de forma a iniciar novamente com o pedido como
um novo usuário;
• Pode-se acionar o botão direito do mouse em um link e
abri-lo em uma nova janela ou guia para explorar uma fun­
cionalidade que chama a atenção do invasor por aparentar
apresentar falhas de segurança, mantendo a sua posição
anterior para continuar trabalhando de forma sistemática
através da aplicação.
Com essas extensões, os testes de segurança poderão ser
realizados com muito mais facilidade. Apesar disso, para
realizar testes mais completos, é necessária a utilização
de mais ferramentas, que serão descritas nas próximas
sessões.
Outras ferramentas úteis
Após o navegador web, o item mais útil no seu conjunto
de ferramentas ao atacar uma aplicação web é um Proxy
Interceptador. No começo da Web os Proxies Interceptador
eram aplicações que proviam funcionalidades básicas. Nos
últimos anos, os Proxies Interceptador expandiram-se para
um grande número de suítes, cada uma contendo muitas
ferramentas interconectadas desenvolvidas para auxiliar
em todas as tarefas envolvidas no ataque a uma aplicação
web. Todas as funcionalidades referentes a Proxies Inter­
ceptador citadas no restante desse artigo estão presentes
no WebScarab, uma ferramenta livre do projeto Owasp.
10 Engenharia de Software Magazine - Testes de segurança
Como essas ferramentas funcionam
Cada suíte de testes integrados contém várias ferramentas
complementares que compartilham informações sobre a
aplicação alvo. Normalmente, o testador interage com a
aplicação de uma forma normal através do seu navegador,
e as ferramentas de acompanhamento monitoram os re­
sultados dos pedidos e das respostas, armazenando todas
as informações pertinentes sobre a aplicação de destino e
provendo inúmeras funções úteis. Cada suíte dispõe dos
seguintes componentes principais:
• Um Proxy Interceptador;
• Uma aplicação spider;
• Várias funções partilhadas e utilitárias.
Proxy Interceptador
O Proxy Interceptador fica no centro da suíte de ferramen­
tas e é o único componente realmente essencial na suíte.
Para utilizá-lo, deve-se configurar o navegador para usar o
Proxy escolhido como servidor Proxy em uma porta local
na própria máquina. O Proxy é, então, configurado para
escutar essa porta e receber todos os pedidos emitidos pelo
navegador e repassá-lo ao destino. Como ele tem acesso aos
dois sentidos da mensagem entre o navegador e o servidor
web e age como um interceptador, ele consegue barrar cada
mensagem para revisão e modificação pelo usuário, para
só então encaminhá-la ao destino.
Outras características comuns presentes nessas
suítes
Além de sua função principal de permitir a interceptação
e alteração de requisições e respostas, os Proxies possuem
uma riqueza de outros recursos para ajudar nos testes de
segurança de aplicações web. Entre os recursos, incluem-
se os seguintes:
• É permitida a criação de regras de interceptação,
possibilitando que as mensagens sejam intercepta­
das para revisão ou silenciosamente retransmitidas,
com base em critérios definidos pelo testador como
host de destino, url, método, tipo de recurso, código
de resposta, ou o aparecimento de determinadas ex­
pressões, conforme pode ser visualizado na Figura 3.
Em uma aplicação típica, muitas requisições e respostas são
de pouco interesse para o testador, e esta função permite
configurar o Proxy para interceptar apenas as mensagens
que lhe são interessantes;
• Um histórico detalhado de todas as requisições e respos­
tas, o que permite que mensagens antigas sejam revistas e
analisadas posteriormente;
• Regras para a modificação dinâmica do conteúdo das
requisições e respostas. Esta função pode ser útil em
inúmeras situações, por exemplo, para reescrever o valor
de um cookie ou outro parâmetro em todos os pedidos
visando remover diretivas de cache, para simular um
navegador específico modificando o cabeçalho e assim
sucessivamente;
 Validação, Verificação & Teste
Figura 3. Tela do WebScarab que permite a configuração das URLs que
serão interceptadas
• Acesso a funcionalidades de Proxy que permitem que se nave­
gue no histórico de requisições e respostas, possibilitando, com
isso, que o testador identifique requisições suspeitas de possuírem
problemas de segurança e reemita o pedido, quantas vezes for
preciso e, caso necessário, faça modificações que permitam iden­
tificar possíveis falhas, conforme pode ser visto na Figura 4;
Figura 4. O WebScarab permite a visualização do Histórico das
requisições realizadas
• Funcionalidades para o mapeamento completo de toda a apli­
cação, funcionalidades essas conhecidas como Web Spiders. Os
Web Spiders agem solicitando páginas web, analisando os links
para outras páginas, e em seguida, solicitando essas páginas.
Eles continuam recursivamente até que todo o conteúdo de
um site seja descoberto;
• Funções que permitem revelar campos e comandos
escondidos.
Scanners de aplicação
Embora seja possível realizar um teste bem-sucedido
usando apenas técnicas manuais, para se tornar um bom
testador, é necessário fazer uso de automação, para aumentar
a rapidez e eficácia dos testes.
Existem algumas ferramentas que varrem toda a aplicação
procurando por falhas conhecidas e, após a varredura, emitem
um relatório com os pontos suspeitos de possuírem falhas de
segurança. Os recursos a seguir estão presentes na ferramenta
Paros, que permite a execução de uma varredura na aplicação
à procura de falhas de segurança:
• Permite varreduras automatizadas para detectar vulnerabili­
dades conhecidas. O Paros envia um conjunto de sequências de
ataque e analisa as respostas para identificar vulnerabilidades
conhecidas. A Figura 5 mostra o resultado de uma Varredura
feita utilizando esta ferramenta. Verifique na figura que é
possível identificar a URL onde se suspeita que exista a falha
de segurança e os parâmetros utilizados pelo Paros.
Figura 5. Resultado de um scan na aplicação WebGoat realizado pelo Paros
• Permite o controle das sequências de ataque e formas de
incorporá-las às requisições. Possui ainda um histórico de
todas as requisições permitindo a revisão dos resultados para
a identificação de todas as respostas incomuns ou anômalas
que merecem maior investigação;
• Funções para extração de dados úteis a partir das respostas
do aplicativo - por exemplo, analisando os campos de usuário
e senha em uma página de detalhes. Isso pode ser útil quando
você está explorando vulnerabilidades diversas, incluindo
falhas na sessão e controles de acesso;
• Funções para analisar cookies e outros tokens para qualquer
sequência.
Uma ressalva é que, todas as possíveis falhas apontadas
pelo Paros devem ser investigadas, pois após uma análise,
descobre-se que muitas delas não são falhas. Esse excesso
de falsos positivos acaba fazendo com que o testador perca
muito tempo analisando os possíveis defeitos. O autor deste
artigo desconhece, até a presente data, uma ferramenta livre
que faça a varredura de uma aplicação, procurando por
falhas de segurança conhecidas, e que seja tão boa quanto
alguns scanners proprietários disponíveis no mercado. Ape­
sar de falsos positivos ocorrerem também nas ferramentas
comerciais, ocorrem em uma escala bem menor do que no
Edição 24 - Engenharia de Software Magazine 11
Paros, ocasionando uma economia de tempo do testador na
análise de falhas.
Além disso, segundo SUTO, autor do artigo Analyzing the Accu-
racy and Time Costs of Web Application Security Scanners, mesmo as
ferramentas proprietárias chegam a não detectar, dependendo
da ferramenta utilizada, 66% das falhas presentes em um site,
o que faz com que não se possa confiar cegamente nessas ferra­
mentas e torna importante o papel do testador na identificação
desses defeitos não identificados pelos Web Scanners.
Requisições manuais
As suítes livres, como o WebScarab, permitem ainda facilida­
des para que o usuário emita uma única requisição e visualize
a sua resposta. Embora simples, esta função muitas vezes é
extremamente útil quando se está investigando uma possível
vulnerabilidade e, para isso, pode existir a necessidade de ree­
ditar a mesma requisição manualmente várias vezes, aprimo­
rando elementos da requisição para determinar o efeito sobre
o comportamento da aplicação.
Logicamente, com uma ferramenta com as funções integradas
você pode recuperar rapidamente uma requisição interessante
de outro componente utilizado no teste (Proxy, spider, etc.) para
investigação manual. Veja a Figura 6 para um exemplo de uma
tela do WebScarab onde é possível realizar a modificação de
uma requisição.
Figura 6. Reedição manual de uma requisição
O WebScarab possui as seguintes funcionalidades relacionadas
ao envio de requisições manuais:
• Integração com outros componentes do conjunto, e a pos­
sibilidade de submeter qualquer requisição de e para outros
componentes para investigação posterior;
• Histórico de todos os pedidos e respostas, mantendo um re­
gistro completo de todas as requisições manuais para revisão
posterior, e possibilitando que uma requisição modificada seja
recuperada para análise posterior.
12 Engenharia de Software Magazine - Testes de segurança
Funcionalidades adicionais
Além de suas ferramentas principais, as suítes de teste de
segurança normalmente fornecem uma vasta gama de outras
funcionalidades que visam atender a necessidades específicas
que surgem quando se está testando a segurança de uma apli­
cação web, e que permitam a outras ferramentas trabalharem
em situações inusitadas. Os recursos abaixo estão disponíveis
no WebScarab:
• Análise da estrutura de mensagens HTTP, incluindo análise e
modificação de cabeçalhos e parâmetros do pedido, conforme
pode ser visto na Figura 7;
Figura 7. O WebScarab permite a interceptação e modificação de
pedidos e respostas
• Renderização de conteúdo das respostas HTML, sendo pos­
sível visualizar a página da mesma forma que ela será exibida
no navegador web (Aba HTML da Figura 7);
• Capacidade de exibir e editar mensagens de texto e de forma
hexadecimal (Aba Hex da Figura 7);
• Funções de pesquisa por todas as requisições e respostas;
• Atualização automática do cabeçalho HTTP, para mantê-
lo consistente com qualquer edição manual do conteúdo da
mensagem;
• Codificadores e decodificadores para vários sistemas, per­
mitindo a rápida análise dos dados da aplicação em cookies
e outros parâmetros;
• O suporte para utilização de outros Proxies, que não são os
integrados na aplicação, permitindo-lhe encadear ferramentas
diferentes ou acessar um aplicativo através do Proxy usado por
sua organização ou ISP;
• Ferramenta de apoio a métodos de autenticação de HTTP,
permitindo-lhe utilizar todos os recursos da suíte em ambien­
tes onde estes são utilizados, tais como LANs corporativas;
• Suporte para os certificados de cliente SSL, permitindo-lhe
testar aplicações que utilizam essa tecnologia;
• Manipulação das características do HTTP, como a codificação
gzip, codificação de transferência em partes, e status 100 de
respostas provisórias;
 Validação, Verificação & Teste

• Extensibilidade, permitindo que a funcionalidade incorpo­
rada seja alterada e estendida de forma arbitrária por código
de terceiros;
• Salvamento das configurações utilizadas na ferramenta,
permitindo que uma configuração específica seja reutilizada
na próxima execução da suíte;
• O WebScarab é independente de plataforma, permitindo que
seja executado em todos os sistemas operacionais populares.
Conclusão
Cada uma das ferramentas apresentadas neste artigo possui
funcionalidades importantes e que, juntas, permitem ao testa­
dor a realização de testes de segurança de forma satisfatória.
Todas são eficazes e muito populares entre a comunidade que
utiliza softwares livres para testar a segurança de aplicativos
na web. Com isso, a escolha de qual suíte será utilizada é uma
as ferramentas livres ainda estão muito distantes de serem
tão boas quanto as ferramentas comerciais disponíveis no
mercado, já que, como eles encontram muitos falsos positi­
vos, acabam desperdiçando o tempo do testador na análise
de falhas que não existem.
Por fim, pôde-se perceber que o bom entendimento de
como utilizar as ferramentas utilizadas é de extrema im­
portância para a melhoria da segurança dos Web Sites, visto
que mesmo os melhores Web Scanners proprietários podem
não encontrar a maioria dos defeitos de segurança presente
em uma aplicação Web.
Feedback
Dê seu feedback sobre esta edição! eu

s
Dê
questão de preferência pessoal. Recomenda-se que seja feito A Engenharia de Software Magazine tem que ser feita ao seu gosto.

sobre e
o download das ferramentas descritas para que o próprio Para isso, precisamos saber o que você, leitor, acha da revista!

s
ta
edição
testador escolha qual ferramenta utilizar em seus testes. Dê seu voto sobre este artigo, através do link:
Entretanto, apesar das ferramentas livres terem evoluído www.devmedia.com.br/esmag/feedback
bastante, pode-se perceber que em relação aos Web Scanners,

Referências e links

STUTTARD, Dafydd, PINTO, Marcus. The Web Application Hacker’s Handbook: Discovering and Projeto Owasp
Exploiting Security Flaws. Wiley Publishing, 2007. http://www.owasp.org

MCGRAW, Gary, Software Security: Building Security In. Addison Wesley Professional, 2006. WebScarab
http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
Testing Experience: The Magazine for Professional Testers, Security Testing, Junho de 2009.
WebGoat
SUTO, Larry. Analyzing the Accuracy and Time Costs of Web Application Security Scanners. São http://www.owasp.org/index.php/Category:OWASP_WebGoat_Project
Francisco, Fevereiro de 2010.
Paros - for web application security assessment
Widespread security flaws revealed in online banks http://www.parosproxy.org/index.shtml
http://www.ur.umich.edu/0708/Jul28_08/02.php

WhiteHat: Web Security Vulnerabilities Found on Most Sites

http://www.eweek.com/c/a/Security/WhiteHat-Web-Security-Vulnerabilites-Found-on-Most-
Sites707138

Edição 24 - Engenharia de Software Magazine 13

Engenharia
Nesta seção você encontra artigos voltados para testes, processo,
modelos, documentação, entre outros
Gerência de Configuração
Definições Iniciais, Ferramentas e Processo
Alberto Boller Filho
alberto.boller@gmail.com
Formado em Tecnólogo Análise de Sistemas pelo
Centro Universitário Instituto Metodista Bennet.
Possui mais de 30 anos de experiência em infor-
mática. Possui especialização em administração
de redes Linux Conectiva, segurança de redes
Linux Conectiva, administração de redes Windo-
ws NT e Windows Server 2003, programação de
aplicações cliente servidor avançada em Delphi,
programação RPGII, programação COBOL, System
Administrator NOTES, Application Development
NOTES. Atualmente é Gerente de informática na
clínica de diagnóstico por imagens “CEPEM “ Cen-
tro de Estudos e Pesquisa da Mulher”.
Rodrigo Oliveira Spínola
rodrigo@sqlmagazine.com.br
Doutorando e Mestre em Engenharia de Software
pela COPPE/UFRJ (avaliada como a melhor pós-
graduação em computação do país). Criador do
projeto e editor chefe da revista Engenharia de
Software Magazine. Autor de diversos artigos
científicos sobre Engenharia de Software publica-
dos em revistas e conferências renomadas, dentro
e fora do país. Experiência de participação em
diversos projetos de consultoria para diferentes
empresas tendo atuado com gerência de projetos,
requisitos e testes de software. Implementador
certificado do MPS.BR, tendo também experiência
atuando junto a empresas certificadas CMMI.
14 Engenharia de Software Magazine - Gerência de Configuração
Marcelo Nascimento Costa
mnc@kalisoftware.com
Mestre em Engenharia de Sistemas e Computação
pela COPPE/UFRJ (avaliada como a melhor pós-
graduação em computação do país). Bacharel em
Ciência da Computação pela UFPA. Professor dos
cursos de graduação em computação e adminis-
tração do Instituto Metodista Bennett. Autor de
diversos artigos científicos sobre Engenharia de
Software publicados em revistas e conferências
renomadas, dentro e fora do país.
Marcos Kalinowski
mk@kalisoftware.com
Doutorando e Mestre em Engenharia de Software
pela COPPE/UFRJ (avaliada como a melhor pós-
graduação em computação do país), com ênfase
em Validação, Verificação e Testes de Software e
Melhoria de Processos. Bacharel em Ciência da
Computação pela UFRJ. Professor do curso de pós-
graduação e-IS Expert da UFRJ e Coordenador do
curso de Engenharia da Computação da UVA RJ.
C
om um mercado cada vez mais
exigente, as empresas que fabri­
cam software tem revisto seus
processos de construção com o intuito de
aumentar a qualidade de seus produtos
e também sua produtividade. Diversas
metodologias de desenvolvimento de
De que se trata o artigo?
Neste artigo serão mostrados inicialmente aspectos
relevantes da gerência de configuração. Na segun-
da parte do artigo, será apresentada a aplicação da
gerência de configuração dentro dos principais mo-
delos de maturidade e as vantagens de se utilizar
tais ferramentas, através de um estudo de caso de
implementação em uma empresa hipotética.
Para que serve?
Este trabalho tem como intuito servir como um mate-
rial de apoio para aqueles que desejam implementar
gerência de configuração em uma organização de-
senvolvedora de software, usando como ferramen-
tas de controle de mudanças e controle de versões, o
Mantis e o Subversion respectivamente.
Em que situação o tema é útil?
Para qualquer empresa de desenvolvimento de
software que tenham interesse em aumentar o
controle e confiabilidade nos artefatos gerados
pela equipe de desenvolvimento ao longo de
um processo de desenvolvimento de software.
software voltadas para o controle tem
sido elaboradas uma vez que um pro­
jeto de software, ao longo do seu ciclo
de vida, tem uma grande quantidade

de itens de informação tais como documentos, código-fonte,
dados, manuais e outros, produzidos e até modificados, pelos
mais diversos motivos.
Para que a qualidade do software seja garantida, em fun­
ção destas modificações, é necessário que se faça uso da
Gerência de Configuração de Software (GCS). A Gerência
de Configuração de Software tem como objetivo gerenciar
e controlar a evolução de um software através do controle
formal de versão e solicitação de mudanças. É uma forma
sistemática e organizada de controlar as modificações de
um software tornando possível manter sua integridade ao
longo do tempo. A quantidade de itens que podem estar
sob controle da GCS e os níveis de controle exigidos sobre
estes itens irá variar de empresa para empresa ou mesmo
de projeto para projeto. Sendo assim, o uso desta prática em
conformidade com modelos de maturidade mantidos por en­
tidades que possuam credibilidade nacional e internacional,
e também o uso de ferramentas adequadas que garantam
a qualidade deste processo, é fundamental para que uma
empresa obtenha êxito e reconhecimento.
Para empresas de grande porte, isto não chega a ser um
grande problema pois normalmente se dispõem de capital
e pessoal qualificado para manter tais práticas. Entretanto,
quando voltamos a olhar para as pequenas empresas, o
cenário é exatamente o oposto. As dificuldades e o custo
envolvidos para se adotar um modelo de gestão, treinar pes­
soal, adquirir ferramentas que apóiem a pratica de GCS, e
ainda obter certificação em um determinado nível de modelo
de maturidade, de uma entidade reconhecida, pode levar
uma pequena empresa a desistir rapidamente da adoção de
um processo de GCS com qualidade, e como conseqüência,
perder em competitividade para outras empresas. Este artigo
foi feito com o foco voltado para estas empresas.
Neste contexto, o objetivo deste artigo é mostrar uma solu­
ção especifica, de boa qualidade e baixo custo, que atenda
as exigências dos modelos de maturidade e que possa ser
utilizada para implementar a Gerência de Configuração de
Software em pequenas empresas.
Sob esta perspectiva, será apresentada uma revisão bi­
bliográfica sobre GCS, sua aplicação dentro dos modelos
de maturidade CMMI e MPS e uma solução especifica uti­
lizando as ferramentas Mantis e Subversion, através de um
estudo de caso de uma empresa fictícia de pequeno porte
que atenda as exigências do modelo de maturidade MPS, e
que possa servir como alternativa para empresas reais que
estejam buscando a implementação do processo de GCS.
Serão apresentados também os aspectos de instalação e
configuração das ferramentas, a fim de facilitar àqueles
que forem utilizá-las.
Gerência de Configuração
Ao longo do ciclo de vida de um software, diversas modifi­
cações podem ocorrer em seu projeto original. Os motivos
e origens destas modificações podem ser os mais variados
possíveis e podem ocorrer em qualquer época.
Projeto
A primeira lei da engenharia de sistemas diz:
“Independente de onde você está no ciclo de vida de um sistema, o
sistema vai se modificar e o desejo de modificá-lo vai persistir ao longo de
todo o ciclo de vida”. Bersoff (1980 apud Pressman, 2006, p. 600)
Produtos de software normalmente envolvem quantidades
significativas de artefatos que são manuseados por diversas
pessoas envolvidas em seu projeto.
Assim sendo, a possibilidade de introdução de defeitos au­
menta à medida que alterações são efetuadas sem uma analise
antes da sua execução, sem o registro formal antes da sua imple­
mentação, sem a comunicação às pessoas que necessitam saber
delas ou ainda sem um controle que vise melhorar a qualidade
e reduzir os erros.
Existem quatro fontes fundamentais de modificações de
software:
• Novas condições de negócio e/ou mercado, modificam regras
de negócio;
• Novas necessidades do cliente exigem modificações de
funcionalidades;
• Reorganização e/ou crescimento/diminuição do negócio;
• Restrições de orçamento ou cronograma, causando redefinição
do sistema;
Conceitos e Terminologias
A Gerência de Configuração de Software (GCS) ou Software
Configuration Management (SCM) é uma atividade abrangente
que ocorre ao longo de todo o ciclo de vida de um software e
que gerencia e controla sua evolução, através do controle de
versões e solicitações de mudanças, permitindo que os diver­
sos envolvidos na sua criação e manutenção tenham acesso ao
histórico destas modificações, fornecendo-lhes subsídios para
o entendimento do sistema na sua forma atual, e também nas
suas formas anteriores.
As atividades de GCS incluem:
• Identificar modificações;
• Controlar modificações;
• Garantir a implementação adequada das modificações;
• Relatar as modificações a outros que possam ter interesse.
Segundo Pressman (2006, p. 599), diferentemente da ativida­
de de suporte de software, que ocorre depois que o software
foi entregue ao cliente, a GCS é um conjunto de atividades de
acompanhamento e controle que começam quando o projeto
de engenharia de software tem início e só terminam quando o
software é retirado de operação.
A Gerência de Configuração de Software tem especial impor­
tância na garantia da qualidade do software e no apoio a gestão
de projetos, sendo imprescindível sua aplicação nas empresas que
desejam obter a certificação do Capability Maturity Model Integra­
tion (CMMI) nível 2 ou na obtenção da certificação do modelo para
Melhoria de Processo do Software Brasileiro (MPS-BR) nível F.
Segundo Pressman (2006 p. 606), o processo de gestão de
configuração de software define uma série de tarefas que têm
quatro objetivos principais:
Edição 24 - Engenharia de Software Magazine 15
• Identificar todos os itens de configuração;
• Gerir modificações em um ou mais destes itens;
• Facilitar a construção de diferentes versões de um mesmo
produto;
• Garantir que a qualidade do software seja mantida a medida
que a configuração evolui ao longo do tempo.
Para podermos entender como estas tarefas são executadas,
devemos conhecer alguns conceitos que são fundamentais
para a aplicação de GCS.
Configuração de Software
Diversos elementos são gerados como produto de um pro­
cesso de software. Estes elementos podem ser:
• Programas de computador (tanto na forma de código fonte
como executável);
• Documentos que podem descrever programas, procedi­
mentos regras de negócio etc. (Documentação técnica e de
usuário final);
• Estrutura de dados que podem estar contidos em programas
ou externos a ele;
A este conjunto de elementos, que compreende toda a in­
formação produzida no processo de software, chamamos de
“Configuração de Software”.
Itens de Configuração de Software – ICS
Segundo Molinari (2007 p. 44), um item de configuração é o
menor item de controle num processo de GCS.
Um item de configuração de Software (ICS) ou Software Con­
figuration Item (SCI) é cada elemento criado durante o processo
de engenharia de software, ou que para este processo seja
necessário. Pode ser um arquivo, uma aplicação corporativa,
uma parte de um documento, uma seqüência de casos de teste,
um hardware ou um componente de programa. Além dos
ICS´s gerados no processo de engenharia de software, também
poderão ser considerados como ICS’s ferramentas de software
como editores, compiladores, navegadores e outras ferramentas
que forem necessárias à correta geração do software.
Os ICS’s são identificados de maneira única e podem estar
relacionados a outros ICS’s e sua evolução é passível de ras­
treamento. O controle da Gerência de Configuração será feito
sobre estes itens e serão mantidas todas as informações a seu
respeito. Diversas versões de um mesmo ICS podem existir
como produto das modificações efetuadas no dia-a-dia.
Molinari (2007 p. 44) faz uma analogia interessante ao con­
ceito de classes em orientação a objetos (OO) quando diz que
o item está para uma “classe” em OO assim como as versões
deste item estão para as “instâncias” da classe em questão
conforme mostrado na Figura 1.
Repositório
Segundo Forte (1989 apud Pressman, 2006, p. 604), o repo­
sitório é o conjunto de mecanismos e estruturas que per­
mite a uma equipe de software gerir modificação de modo
16 Engenharia de Software Magazine - Gerência de Configuração
efetivo. Fornece as funções óbvias de um sistema de gestão
de banco de dados, mas, além disso executa ou propicia as
seguintes funções:
• Integridade de dados – Valida entradas no repositório,
garante consistência entre os ICS’s relacionados, executa mo­
dificações em cascata quando uma modificação em um objeto
exige modificações em objetos a ele relacionados;
• Compartilhamento de informações – Fornece mecanismo
para compartilhar a informação entre vários desenvolvedores e
ferramentas, controla o acesso aos ICS’s por diferentes usuários
através de política de bloqueio e desbloqueio de modo que as
modificações não sejam sobrepostas umas as outras;
• Integração de ferramenta – Provê uma estrutura de dados
que permite acesso à várias ferramentas de engenharia de
software;
• Integração de dados – Fornece funções de banco de dados
que permitem que várias tarefas de GCS sejam executadas em
um ou mais ICS’s;
• Imposição de metodologia – Define um modelo entidade
relacionamento que implica um modelo de processo especifico
de engenharia de software. O relacionamento entre objetos
definem um conjunto de passos a ser seguido para construir
o conteúdo do repositório;
• Padronização de documentação – Normalização para a
criação de documentos de engenharia de software.
Figura 1. Classes e instâncias de um item de configuração
Um repositório tem que ser capaz de manter ICS’s relaciona­
dos a diversas versões do software e ainda fornecer mecanis­
mos para montar esses ICS’s em uma configuração especifica
da versão, garantindo assim a gestão efetiva das entregas do
produto e permitindo aos desenvolvedores voltar a versões
anteriores. Precisa ser capaz de controlar variados tipos de
ICS’s incluindo textos, gráficos, mapas de bits e outros mais
complexos.
Além disso, o repositório deve ser capaz de guardar informa­
ções sobre baselines e pistas de auditoria com informações sobre
quando, por que, e por quem as modificações foram feitas.
Estas informações são chamadas de metadados, e são definidas
em um metamodelo que determina como as informações são
armazenadas no repositório, como ter acesso a elas, como podem
ser vistas pelos engenheiros de software, e como manter a sua
integridade e segurança.
Além de manter as informações sobre os ICS’s, o repositório
deve ser capaz de armazená-los fisicamente em um esquema
de bibliotecas.

Os ICS’s são retirados e inseridos nos repositórios, através
das seguintes operações:
• LOCK: Garante que apenas um usuário detém o acesso para
alterar um determinado ICS. Apesar de resolver o problema
de atualização simultânea, o lock serializa o trabalho dos
desenvolvedores.
• CHECK-OUT: Recupera a última versão de um item de
configuração guardado no repositório, copiando-o para a área
de trabalho do desenvolvedor.
• CHECK-IN: Insere ou atualiza um item de configuração
no repositório, incrementando a versão do ICS, e fazendo o
registro das informações de mudança.
Identificação de ICS’s
A identificação dos ICs é uma área de extrema importância
dentro da Gerência de Configuração de Software. Sem uma
identificação correta de um item, é impossível gerenciar este
processo.
Cada ICS deve ser identificado através de características
distintas que o caracterizam unicamente. Estas características
podem ser um nome, uma descrição, uma lista de recursos etc.
É necessário que cada organização defina suas convenções de
identificação.
Baseline
Um baseline pode ser descrito como a situação de uma cole­
ção de ICS’s similares em um momento especifico do ciclo de
vida de um software que foram aprovados e armazenados em
uma biblioteca controlada. Pode ser descrito também como a
conexão de um item de configuração com um determinado
marco no projeto (milestone). Um baseline pode ser visto como
um conjunto de itens de configuração identificados e liberados
para uso, independente de suas versões.
É importante identificar e agrupar estes ICS’s dentro dos
baselines apropriados pois desta forma, cria-se uma estrutura
que facilita o rastreamento de mudanças à estes ICS’s.
Em cada fase do processo de desenvolvimento, um conjunto
bem definido de itens de configuração deve ser estabelecido.
Tal conjunto representa um estágio do desenvolvimento, o qual
é passível de modificações apenas mediante um mecanismo
formal de alterações. A este conjunto é dado o nome de base­
lines, ou configurações base do sistema.
Em princípio, baselines poderiam ser estabelecidas em qual­
quer ponto do desenvolvimento. Entretanto, a grande vanta­
gem do conceito está em se fazer coincidir o estabelecimento de
baselines com os finais de fase do ciclo de vida do produto.
O desenvolvimento com configurações base pode, então, ser
resumido nos seguintes pontos:
• Caracterização do ciclo de vida, identificando-se as fases
pelas quais o desenvolvimento do software irá passar;
• Definição do conjunto de baselines, estabelecendo-se quais
serão os ICS’s que a irão compor;
• Estabelecer o marco o qual a baseline irá representar. Uma
nova baseline é estabelecida no final de cada fase do ciclo de
vida do software;
Projeto
• Durante cada fase, a modificação de uma configuração-base
somente pode ser feita de forma controlada, mediante um
processo bem definido;
• Ao ser estabelecida, cada baseline incorpora integralmente
a anterior.
• O estabelecimento de cada baseline somente é realizado
após ser aprovada por procedimentos de consistência interna,
verificação e validação;
Na Figura 2 vemos uma representação de baselines adaptada
de Molinari (2007, p 56).
Figura 2. Entendendo um baseline
Controle de Versão
Segundo Pressman (2006, p. 608), controle de versões
combina procedimentos e ferramentas para gerir diferentes
versões de objetos de configuração que são criados durante
o processo de software. Um sistema de controle de versão
implementa ou está diretamente integrado com quatro ca­
pacidades principais:
• Um banco de dados de projeto (repositório) que guarda
todos os objetos de configuração relevantes;
• Uma capacidade de gestão de versão que guarda todas as
versões de um objeto de configuração;
• Uma facilidade de construir que permite ao engenheiro de
software coletar todos os objetos de configuração relevantes
e construir uma versão especifica do software;
• Capacidade de acompanhamento de tópicos (também cha­
mado de acompanhamento de bugs).
Segundo Molinari (2007, p. 168), alguns colocam que a prin­
cipal missão de um sistema de controle de versões é permitir
a edição colaborativa e o compartilhamento de dados, outros
dizem que o sistema de controle de versões rastreia e controla
todos os artefatos do projeto e desse modo consegue coorde­
nar o trabalho paralelo de desenvolvedores.
Ainda segundo Molinari (2007, p.168), independente do que
cada um pensa sobre controle de versões, algumas das suas
características perceptíveis são:
• Mantém e disponibiliza cada versão já produzida de cada
item do projeto;
• Possui mecanismos para gerenciar diferentes ramos de
desenvolvimento possibilitando a existência de diferentes
versões de maneira simultânea;
• Estabelece uma política de sincronização de mudanças que
evita a sobreposição de mudanças;
• Fornece um histórico completo de alterações sobre cada
item do projeto.
Edição 24 - Engenharia de Software Magazine 17
 O sistema de controle de versões é o responsável por manter
as diversas versões dos ICS’s e faz isso através de um esquema
de arquivos e diretórios presentes no repositório, registrando
não só as alterações realizadas em cada arquivo mas também
na estrutura do diretório em si.
O repositório evolui, junto com o projeto guardando as múlti­
plas versões que o compõe organizadas em forma de revisões.
As revisões são as situações estáticas de todos os arquivos do
projeto em um determinado instante de tempo.
Em empresas de grande porte, onde existem vários profissio­
nais trabalhando concorrentemente nos mesmos arquivos, faz-se
necessário uma política para ordenar e integrar estas alterações,
a fim de evitar a perda de um trabalho ocasionada quando uma
pessoa sobrescreve o trabalho de outra.
Os sistemas de controle de versão implementam esta política,
assegurando que os desenvolvedores não trabalhem diretamen­
te nos arquivos do repositório, mas sim em cópias de trabalho
destes arquivos em suas próprias máquinas. Isto permite que
um desenvolvedor faça seu trabalho de forma independente e
sem interferir no trabalho de outro. Após terminado o trabalho,
o arquivo deve ser colocado novamente no repositório e para que
alterações não sejam inadvertidamente sobrepostas, o sistema
de controle de versões pode fazer uso das seguintes políticas
de versionamento:
• Trava-Modifica-Destrava: Apenas uma pessoa por vez detém
o direito de alterar um determinado arquivo. O sistema trava o
arquivo quando uma pessoa retira uma cópia para manutenção
e só libera a cópia para edição à outra pessoa, quando a primeira
publica sua nova versão. Esta política é limitada e pode causar
problemas administrativos e forçar a serialização do trabalho,
entretanto, é a solução indicada para organizações que neces­
sitam de um alto grau de formalização.
• Copia-Modifica-Resolve: Não utiliza travamento de arquivos.
Nesta política, cada desenvolvedor trabalha de forma indepen­
dente em sua cópia de trabalho, e ao final, as alterações são
mescladas no repositório, formando a versão final. Esta política
pode parecer caótica, mas na prática funciona bem, devido ao
baixo índice de conflitos. Os conflitos são causados na maioria
das vezes, por falta de comunicação entre os desenvolvedores.
Branch
Branching (ou ramificação em português) é uma parte funda­
mental do controle de versões. O conceito de branching reside
em se iniciar uma nova linha de desenvolvimento em paralelo
à uma principal já existente.
Esta técnica é extremamente útil em situações onde temos
que fazer grandes alterações em objetos de configuração e que
provavelmente levarão muito tempo, sem contudo afetar a linha
principal de manutenção do sistema. Nesta situação, cria-se uma
segunda cópia do objeto em questão e trabalha-se em paralelo
à linha principal. Ao longo do tempo, as manutenções feitas na
linha principal poderão ser incorporadas na ramificação para
que defeitos encontrados na cópia original possam ser conser­
tados também na ramificação. A Figura 3 demonstra como é a
técnica de branching ao longo do tempo.
18 Engenharia de Software Magazine - Gerência de Configuração
Figura 3. Branch de desenvolvimento
Merge
Em projetos onde existe um grande número de pessoas en­
volvidas, é comum que elas possuam uma cópia de trabalho da
linha principal de desenvolvimento. Neste contexto, o conceito
de merge é também uma parte fundamental do controle de
versões. O Merge faz a fusão de dois arquivos que estão sendo
alterados simultaneamente por desenvolvedores diferentes
garantindo que a versão final contenha todas as alterações.
Quando isso não é possível, mantém apenas a última versão
guardada e emite uma mensagem de “arquivo fora de data”
para que as diferenças sejam resolvidas com intervenção
humana. Em alterações demoradas, onde normalmente é
utilizada a técnica de branch, é recomendável que se façam
merges, periodicamente entre a linha principal e a ramificação,
para que no final não fique inviável fazer o merge devido ao
grande número de conflitos gerados entre as diferenças das
diversas versões.
Tags
Um outro tipo de controle de versão são as tags. Tags são
como fotografias de um projeto, em um determinado instante
do tempo. São rótulos associados a um conjunto de arquivos
usados para denominar um projeto ou uma nova versão, e que
rotulam estes arquivos. As tags nas versões de um conjunto
de itens de configuração, existente em diversos sistemas de
controle de versões, pode ser utilizado para implementar o
conceito de baseline.
Controle de Modificação
Mudanças são inevitáveis. Todo produto de software sofre
mudanças durante o seu ciclo de vida, seja por erro de cons­
trução, ou por necessidade de mudanças solicitadas pelos
clientes. Em projetos de grande porte, fazer modificações sem
um esquema formal de controle pode levar ao caos. Alguns
dos problemas que podem ser causados em projetos devido a
mudanças não controladas são:
• Aumento do custo do projeto;
• Atrasos em entregas planejadas;
• Impacto em outros objetos de configuração;
• Degradação da qualidade do software;
• Retrabalho.
Controle de modificações podem incluir procedimentos
humanos e também o uso de ferramentas automatizadas, e

seu objetivo é controlar estas mudanças e manter informações
sobre os pedidos de mudança, nos produtos e as implementa­
ções realizadas em função destas mudanças.
Informações do tipo quem, quando, por que e o que foi mu­
dado, em um item de configuração, são guardadas para que
seja possível haver uma rastreabilidade entre suas versões
anteriores e posteriores.
O processo de controle de mudanças começa quando o clien­
te emite um pedido de comunicação. Este pedido passa pela
análise de uma Comissão de Controle de Modificações (do
inglês Change Control Board – CCB), que é responsável pela
sua aprovação ou não. É gerada então uma ordem de modifi­
cação de engenharia (Engineering Change Order – ECO) pra as
modificações aprovadas. O ICS é retirado do repositório para
uma área de trabalho exclusiva do profissional, que irá executar
as mudanças. As mudanças são executadas, as atividades de
SQA são aplicadas, e os ICS’s modificados são introduzidos
no repositório com os mecanismos adequados de controle
de versão. Controles para acesso aos ICS’s pelos engenheiros
e controles de sincronização de modificações paralelas por
pessoas diferentes são usados nesta etapa.
A Figura 4 esboça o processo formal de controle de modifi­
cações segundo Pressman (2006, p 610).
Figura 4. Processo de controle de modificações (Pressman, 2006)
Auditoria de Configuração
Além dos controles de identificação, versão e modificação
vistos anteriormente, precisamos implementar algum mecanis­
mo que nos garanta que as modificações foram feitas de forma
adequada. Este mecanismo envolve dois aspectos:
Projeto
• Revisões técnicas formais;
• Auditoria de configuração de software.
A revisão técnica tem como foco a correção técnica do ICS
que foi modificado a partir de uma requisição. Revisores
avaliam o ICS para determinar se o mesmo é consistente.
Revisões técnicas formais normalmente são feitas para todas
as modificações, exceto as mais triviais.
A auditoria de configuração de software tem como objetivo
complementar a revisão técnica formal e trata dos seguintes
aspectos:
• Verifica se a modificação técnica especificada foi realizada e
se foi incorporada alguma modificação adicional;
• Verifica se uma revisão técnica formal foi feita para avaliar
a correção técnica;
• Verifica se o processo de software foi seguido;
• Verifica se constam anotados no ICS modificado, dados de
rastreabilidade tais como data da modificação, autor, nº de
requisição etc.;
• Verifica se os procedimentos de GCS para registrar e relatar
a modificação, foram seguidos;
• Verifica se todos os ICS’s relacionados foram atualizados de
forma adequada.
Quando a GCS é uma atividade formal, a auditoria de confi­
guração é conduzida pelo grupo responsável pela garantia de
qualidade. A auditoria também tem como objetivo garantir que
os ICS’s corretos foram incorporados em um build específico e
que sua documentação está consistente com a nova versão.
Relatórios de Estado
Os relatórios de estado é uma tarefa de GCS que tem por
objetivo responder às seguintes questões:
• O que aconteceu ?
• Quem fez ?
• Quando aconteceu ?
• O que mais será afetado ?
O relatório de estado reúne informações de todos os estágios
da GCS. Atividades como identificação de ICS’s, aprovação de
modificações, resultado das auditorias de configuração são
registradas no relatório de estado. O relatório de estado deve
ser colocado em um banco de dados de maneira que todas
as pessoas envolvidas na manutenção de software tenham
acesso as informações ali contidas. O principal objetivo de
um relatório de estado é manter a gerência e os profissionais
informados das modificações sofridas por um software, de­
vendo ser gerado regularmente.
Ferramentas de Apoio à GCS
Existem diversas ferramentas disponíveis no mercado para
apoiar a Gerência de Configuração de Sistemas. As funciona­
lidades, documentação, o suporte disponível e popularidade
variam bastante. As ferramentas comerciais apresentam
maior número de funcionalidades mas tem um alto custo. As
Edição 24 - Engenharia de Software Magazine 19
ferramentas open source além de baixo custo, também apre­
sentam vantagens como qualidade e segurança. A Tabela 1
apresenta algumas ferramentas e suas aplicações.
Tipo de ferramenta Nome
Controle de Versão CVS
SubVersion
Controle de mudança Mantis
Bugzilla
Integração (Build) Scons
Tabela 1. Ferramentas para GCS
CVS
O CVS, ou Concurrent Version System (Sistema de Versões
Concorrentes), é um sistema de controle de versão open source,
que permite que se trabalhe com diversas versões de arquivos
organizados em um diretório e localizados local ou remota­
mente, mantendo-se suas versões antigas e os logs de quem e
quando manipulou os arquivos.
É especialmente útil para se controlar versões de um software
durante seu desenvolvimento, ou para composição colaborativa
de um documento.
O CVS utiliza uma arquitetura cliente-servidor: um servidor
armazena as versões atuais do projeto e seu histórico, e os clien­
tes se conectam a esse servidor para obter uma cópia completa
do projeto, trabalhar nessa cópia e então devolver suas modifica­
ções. Tipicamente, cliente e servidor devem estar conectados por
uma rede local de computadores, ou pela internet, mas o cliente
e o servidor podem estar na mesma máquina se a configuração
do CVS for feita de maneira a dar acesso a versões e histórico
do projeto apenas a usuários locais.
O CVS possui limitações tais como:
• Os arquivos em um repositório CVS não podem ser re­
nomeados, eles devem ser explicitamente removidos e re-
adicionados;
• O protocolo do CVS não permite que os diretórios sejam mo­
vidos ou renomeados. Cada arquivo do subdiretório em questão
deve ser individualmente removido e re-adicionado;
• Não permite “lock” (permite que dois usuários alterem o
mesmo arquivo ao mesmo tempo) e em alguns casos pode ser
mais custoso resolver o conflito do que evitar que ele ocorra.
Subversion
Subversion (também conhecido por SVN, o nome da sua ferra­
menta de linha de comando) é um sistema de controle de versão
open source projetado especificamente para ser um substituto
moderno do CVS, que se considera ter algumas limitações.
O Subversion é bem conhecido na comunidade que utiliza
código aberto e é utilizado em diversos projetos incluindo
Apache Software Foundation, KDE, Free Pascal, FreeBSD, GCC
Python, Django, Ruby, Mono, SourceForge.net, ExtJS e Tigris.org.
O Google Code também faz a hospedagem de seus projetos de
código aberto utilizando o Subversion.
O Subversion também é adotado no mundo corporativo.
Em 2007, a Forrest Research reportou que o Subversion foi
20 Engenharia de Software Magazine - Gerência de Configuração
reconhecido como sendo líder isolado na categoria Standalone
Software Configuration Manager (SSCM) tendo uma forte
atuação na categoria Software Configuration and Change
Management (SCCM).
O Subversion começou a ser escrito no ano 2000 como um
esforço para criar um sistema de controle de versão o qual
operasse de forma parecida com o CVS porém sem os seus
problemas, e suprindo as facilidades não existentes no CVS. No
ano de 2001, o Subversion já estava suficientemente desenvol­
vido para ser capaz de hospedar seu próprio código fonte.
Algumas de suas facilidades são:
• Operações de “Commit” são atômicas. Interrupções nestas
operações não causam inconsistências no repositório;
• Mudanças de nomes, cópias, e movimentações de arquivos
são guardadas como histórico de revisões;
• Mudanças de nomes em diretórios são guardados também
como versões. Árvores de diretórios inteiras podem ser movi­
das ou copiadas com rapidez e tem estas operações guardadas
no histórico de revisões;
• Servidor Apache HTTP como servidor de rede;
• Operações de Branch e Tag são menos custosas, independente
do tamanho do arquivo. O Subversion não faz distinção entre
Tag, Branch e um diretório;
• Permite operações de “lock” para arquivos que não podem
ser fundidos (sofrer operação de “merge”).
Mantis
Mantis é um sistema de controle de mudança open source,
baseado em Web, bastante popular. Foi escrito em linguagem
PHP e trabalha com banco de dados MySQL, MS SQL e Pos­
tgreSQL e um webserver. Pode ser instalado em Windows,
Linux, Mac OS, OS/2 e outros e funciona na maioria dos web
browsers como um cliente.
Algumas de suas características são:
• É um software livre (licença GPL);
• Fácil de instalar;
• Fácil de avaliar;
• É baseado em Web;
• Suporta qualquer plataforma que roda PHP;
• Suporta múltiplos projetos por instancia;
• Suporte para Projetos, Sub-projetos e categorias;
• Suporte a diferentes níveis de acesso de usuário por projetos;
• Suporta log de mudanças;
• Possui diversos relatórios e gráficos;
• Usuários podem monitorar as solicitações;
• Envio de notificações por e-mail;
• Permite histórico de mudanças;
• Integração com SVN e CVS.
Bugzzila
Bugzilla é uma ferramenta baseada em Web e e-mail, que dá
suporte ao desenvolvimento do projeto Mozilla, rastreando
defeitos de software, e servindo também como plataforma
para solicitações e controle de mudanças. Como projeto de
software livre, é mantido por voluntários, sendo utilizado

por diversos outros projetos e empresas. Algumas de suas
características são:
• Capacidade de pesquisa avançada;
• Notificações por e-mail controladas pelas preferências de
usuários;
• Lista de defeitos em diversos formatos;
• Relatórios periódicos (diários, semanais etc.) enviados por
e-mail;
• Controle de tempo de execução de uma solicitação;
• Sistema de atribuição de tarefas;
• Diversas versões de localização (incluindo Português
– Brasil).
SCons
SCons é uma ferramenta de construção de software open
source escrita em Python. O SCons provê uma ponte entre
plataformas e é o substituto para o utilitário clássico Make com
funcionalidades similares ao autoconf/automake, e possui com­
piladores integrados. Algumas de suas características são:
• Seus arquivos de configuração são scripts Python;
• Analise automática de dependências, nativa para C, C++ e
Fortran, extensível para outras linguagens;
• Suporte nativo para adquirir arquivos fonte do CVS;
• Suporte nativo ao MS Visual Studio .NET
• Detecção de mudanças de construção usando assinaturas
baseadas em MD5.
Gerência de configuração nos modelos de maturidade
A partir dos anos 90, iniciou-se um movimento no sentido de
solucionar problemas que afetavam a industria de software.
Problemas como descumprimento de prazos, estouro de or­
çamentos, falta de funcionalidades requeridas pelos clientes e
outros, afetavam de maneira drástica a qualidade dos produtos
de software produzidos nesta época.
A maioria destes problemas originavam-se do fato da cons­
trução de software ser conduzida utilizando-se processos
improvisados e pouco ou nada controlados. Sendo assim,
vários órgãos e associações começaram a criar modelos que
orientassem o desenvolvimento destes produtos.
Embora hoje existam diversos modelos de maturidade
voltados para o desenvolvimento de software objetivando
aumentar a produtividade da construção e a sua qualidade,
todos incluem a utilização de práticas de GCS que variam de
acordo com cada modelo.
Neste artigo será apresentado os pontos em comum da apli­
cação da GCS nos modelos CMMI, e MPS.BR.
GCS aplicada no CMMI
O CMMI (Capability Maturity Model Integration) tem como
objetivo prover um modelo de maturidade para desenvolvi­
mento de produtos e serviços de uma maneira geral. Ele aponta
práticas que cobrem o ciclo de vida dos produtos desde a sua
concepção até a entrega e manutenção. A versão 1.0 foi publi­
cado em 2000 em substituição ao CMM (Capability Maturity
Model) Versão 1.1, criado pela SEI (Software Engineering
Projeto
Institute) na Carnegie Mellon University a pedido do Depar­
tamento de defesa dos EUA que necessitava de um modelo
para avaliar os seus fornecedores de software. A versão 1.1
foi publicada em 2002 e a atual, versão 1.2 , foi publicada em
agosto de 2006.
A missão inicial da equipe que produziu o CMMI era com­
binar três modelos:
• Capability Maturity Model for Software (SW-CMM) v. 2.0
draft C
• Systems Engineering Capability Model (SECM)
• Integrated Product Development Capability Maturity Model
(IPD-CMM) v. 0.98
O CMMI permite abordar a avaliação e o melhoramento de
processos utilizando dois tipos de representação: contínua e
por estágio.
A representação contínua permite a uma organização sele­
cionar áreas de processo e melhorar os processos relacionados
a ela. Nesta representação, são utilizados níveis de capacidade
para caracterizar os melhoramentos relativos a uma área de
processo individual.
A representação por estágios usa um conjunto pré-definido
de áreas de processo para definir uma via de melhoramento
para uma organização. Esta via de melhoramento é carac­
terizada por níveis de maturidade. Cada nível fornece um
conjunto de áreas de processo que caracterizam diferentes
comportamentos organizacionais.
A Figura 5 mostra uma visão geral por estágio dos níveis de
maturidade e as áreas de processo envolvidas. Podemos notar
na figura que a Gestão de Configuração de Software é uma
área de processo do nível 2 do modelo de maturidade.
Segundo o CMMI-DEV (2006, p.114), o propósito da Gestão
de Configuração de software (GCS) é estabelecer e manter a
integridade dos produtos de trabalho, usando identificação da
configuração, controle de configuração, status da configuração
contábil e auditoria de configuração.
As metas e práticas especificas da gestão de configuração
definidas na CMMI são:
SG 1. Estabelecer baselines.
SP 1.1 Identificar itens de configuração
SP 1.2 Estabelecer um Sistema de Gestão de Configuração
SP 1.3 Criar ou liberar baselines
SG 2. Rastrear e controlar mudanças
SP 2.1 Rastrear requisição de mudanças
SP 2.2 Controlar itens de configuração
SG 3. Estabelecer integridade
SP 3.1 Estabelecer registros de Gerencia da Configuração
SP 3.2 Realizar auditorias de configuração
GCS aplicada no MPS
O programa MPS.BR (Melhoria de Processo do Software
Brasileiro) foi criado em 2003 pela SOFTEX (Associação para
Promoção da Excelência do Software Brasileiro). O MPS.BR
tem o apoio do Ministério de Ciência e Tecnologia (MCT)
da Financiadora de Estudos e Projetos (FINEP) e do Banco
Edição 24 - Engenharia de Software Magazine 21
 Figura 5. Visão por nível de maturidade X Áreas de processo
Interamericano de Desenvolvimento (BID). Sua estrutura está
dividida em duas áreas de apoio:
• Fórum de Credenciamento Controle (FCC) cujas atribui­
ções são:
I. Emitir parecer que subsidie decisão da SOFTEX sobre o
credenciamento de Instituições Implementadoras (II) e Ins­
tituições Avaliadoras (IA);
II. Monitorar os resultados das Instituições Implementa­
doras (II) e Instituições Avaliadoras (IA), emitindo parecer
propondo à SOFTEX o seu descredenciamento no caso de
comprometimento da credibilidade do modelo MPS.
• Equipe Técnica do Modelo (ETM) cuja atribuição é apoiar a
SOFTEX sobre os aspectos técnicos relacionados ao Modelo
de Referência (MR-MPS) e Métodos de Avaliação (MA-MPS)
para:
I. Criação e aprimoramento contínuo do MR-MPS, MA-MPS
e seus guias específicos;
II. Capacitação de pessoas por meio de cursos, provas e
workshops.
22 Engenharia de Software Magazine - Gerência de Configuração
Este modelo surgiu pelo fato de muitas empresas ao busca­
rem certificação CMM/CMMI se depararem com os custos
elevados de implementação/avaliação, inviabilizando as
certificações para pequenas empresas.
Uma das metas do programa MPS.BR é definir e aprimorar
um modelo de melhoria e avaliação de processo de software
visando preferencialmente às micro, pequenas e médias em­
presas, de forma a atender as suas necessidades de negócio
e ser reconhecido nacional e internacionalmente como um
modelo aplicável à indústria de software.
A base técnica para a construção e aprimoramento deste
modelo de melhoria e avaliação de processo de software é
composta pelas normas ISO/IEC 12207:2008 [ISO/IEC, 2008a]
e ISO/IEC 15504-2 [ISO/IEC, 2003]. O MPR.BR se propõe ser
compatível com o modelo CMM/CMMI para software.
Na Figura 6 temos uma visão geral dos principais compo­
nentes MPS.BR.
O Modelo de Referência, MR-MPS, define níveis de ma­
turidade que são uma combinação entre processos e sua

capacidade. Para cada nível de maturidade são estabelecidos
processos que caracterizam estágios de melhoria da imple­
mentação de processos na organização. O MR-MPS define sete
níveis de maturidade:
• A (Em Otimização);
• B (Gerenciado Quantitativamente);
• C (Definido);
• D (Largamente Definido);
• E (Parcialmente Definido);
• F (Gerenciado);
• G (Parcialmente Gerenciado).
Figura 6. Visão geral dos componentes do MPS.BR
O primeiro nível da escala é o “G” e o último o “A”. A
Tabela 2 mostra os processos exigidos para cada nível de
maturidade.
Segundo definição do MPS.BR Guia de Implementação (2009,
p. 16), o propósito do processo de Gerência de Configuração
é estabelecer e manter a integridade de todos os produtos de
trabalho de um processo ou projeto e disponibilizá-los a todos
os envolvidos. A GCS é encarada pelo MPS.BR como sendo
um processo do nível de maturidade “F” e portanto deve ter
resultados esperados. Os resultados esperados da GCS são:
• GCO1 - Um Sistema de Gerência de Configuração é esta­
belecido e Mantido;
• GCO2 - Os itens de configuração são identificados com base
em critérios estabelecidos;
• GCO3 - Os itens de configuração sujeitos a um controle
formal são colocados sob baseline;
• GCO4 - A situação dos itens de configuração e das baselines
é registrada ao longo do tempo e disponibilizada;
• GCO5 - Modificações em itens de configuração são
controladas;
• GCO 6 - O armazenamento, o manuseio e a liberação de itens
de configuração e baselines são controlados consistentes;
• GCO7 - Auditorias de configuração são realizadas objeti­
vamente para assegurar que as baselines e os itens de confi­
guração estejam íntegros, completos e consistentes.
Nesta parte do artigo foi mostrado onde a Gerência de confi­
guração de Software se encaixa nos dois dos principais modelos
de maturidade de software usados por em presas brasileiras. Na
próxima seção do artigo será apresentado um estudo de caso
de aplicação de GCS em uma empresa de desenvolvimento de
Projeto
software utilizando-se das ferramentas Mantis para controle de
modificações e Subversion para controle de versões.
Nivel Processos
A
B Gerência de Projetos – GPR (evolução)
C Gerência de Riscos – GRI
Desenvolvimento para Reutilização – DRU
Gerência de Decisões – GDE
D Verificação – VER
Validação – VAL
Projeto e Construção do Produto – PCP
Integração do Produto – ITP
Desenvolvimento de Requisitos – DRE
E Gerência de Projetos – GPR (evolução)
Gerência de Reutilização – GRU
Gerência de Recursos Humanos – GRH
Definição do Processo Organizacional – DFP
Avaliação e Melhoria do Processo Organizacional – AMP
F Medição – MED
Garantia da Qualidade – GQA
Gerência de Portfólio de Projetos – GPP
Gerência de Configuração – GCO
Aquisição – AQU
G Gerência de Requisitos – GRE
Gerência de Projetos – GPR
Tabela 2. Níveis de Maturidade do MR-MPS
Estudo de caso de uma implementação de GCS com
Mantis e Subversion
A partir de agora será apresentado um estudo de caso de
implementação de práticas de GCS com as ferramentas Mantis
e Subversion em uma empresa de construção de software de
pequeno porte. A esta empresa, daremos o nome fictício de
“Casa do Software”.
Cenário
A empresa “Casa do Software” é uma empresa de pequeno porte
e conta com trinta e cinco colaboradores. A empresa desenvolve
softwares voltados para áreas comerciais de outras empresas
utilizados por vendedores em seus notebooks nas visitas a seus
clientes. A empresa não possui uma política de GCS implementa­
da. Existe apenas uma rotina periódica de back-ups que fica sob
responsabilidade do pessoal de suporte de infra-estrutura.
As solicitações de modificações são feitas pelos clientes
através de reuniões realizadas com o gerente de projetos e
desenvolvedores. A única documentação existente sobre as
solicitações são as atas das reuniões, não havendo documen­
tação de acompanhamento da manutenção e aprovação formal
das mesmas por parte da gerência de projetos. Existe mais
de uma versão do mesmo sistema, como conseqüência de
alterações feitas especificamente para determinados clientes,
o que complica ainda mais a manutenção dos produtos de
software. Como a empresa está em franca expansão, fica clara
a necessidade de se implementar práticas de GCS que possam
Edição 24 - Engenharia de Software Magazine 23
contribuir para melhorar a qualidade de software da mesma, Nas seções seguintes mostraremos um PGC para esta em­
além disso, as práticas de GCS adotadas deverão estar em presa com base em pesquisa nos trabalhos de Borges (2006),
conformidade com o MPS-BR. Barbosa (2007), Neto(2005).
Como nesta empresa não existe a prática de GCS, será ne­
cessário a realização de treinamentos para que os diversos
colaboradores envolvidos no processo de implementação de
tais práticas e também aqueles que irão fazer uso dela possam
compreender o novo processo e utilizá-lo conforme definido
no Plano de Gerência de Configuração.
Como projeto piloto, foi selecionado o SISVEN (Sistema de
Vendas). O SISVEN é um sistema feito em Java destinado a
tirar pedidos de vendas, fazer prospecção de clientes e roda
em notebooks utilizados por vendedores que visitam clientes
em todo o país.

Plano para implementação da GCS na empresa

Devido ao tamanho da empresa e da pouca experiência do
pessoal envolvido, será implantada a GCS sob a perspectiva
de desenvolvimento, a qual abrange os sistemas de Controle
Figura 7. Fluxo do Plano de Implementação da GCS na empresa
de Modificações, Controle de Versões e Gerenciamento da
Construção. Histórico das Revisões
Embora a implementação seja feita sob esta perspectiva, as As tabelas apresentadas nas Tabelas 3 e 4 deverão ser altera­
funções da perspectiva gerencial podem ser implementadas das sempre que alguma modificação for feita no PGC.
por estes três sistemas acrescendo-se procedimentos manuais.
Neste artigo apresentaremos uma solução baseada em Mantis Data Versão Descrição Autor
para o “Controle de modificações”, e Subversion para o “Con­ 05/07/2009 1.0 Criação da primeira versão Alberto Boller
trole de Versões”. O “Gerenciamento de construção” feito por
um sistema automatizado não será tratado neste trabalho. Na
Figura 7 podemos ver o fluxo do Plano para implementação da
GCS na empresa.

Criação da Equipe de Gerência de Configuração (EGC) Tabela 3. Histórico das Revisões

A Equipe de Gerência de Configuração (EGC) será composta
por um gerente de configuração, um gerente de projetos e por Data Versão Nome Cargo
uma pessoa de infra-estrutura. 05/07/2009 1.0 Alberto Boller Filho Gerente de Projetos
A responsabilidade deste grupo é procurar melhorar de for­
ma constante as atividades de GCS definidas para a empresa,
seja mudando processos ou incluindo novas ferramentas.

Criação do Comitê de Controle de Configuração (CCC) Tabela 4 . Aprovações

O Comitê de Controle de Configuração (CCC) será com­
posto pelo gerente de projetos e o Gerente de Qualidade. A
responsabilidade do CCC será avaliar se uma determinada
modificação deve ser implementada, rejeitada ou posterga­
da, baseando-se em análises de impacto que tal modificação
irá causar.
Criação do Plano de Gerência de Configuração (PGC)
O Plano de Gerência de Configuração (PGC) define formal­
mente os padrões e práticas adotadas pela empresa no que
tange à GCS. Neste documento estão descritos os procedi­
mentos a serem seguidos, as ferramentas a serem utilizadas,
os ICS’s que deverão estar sob controle da GCS, sua forma de
identificação e todas as diretrizes que qualquer sistema deverá
seguir dentro da empresa.
Histórico das Revisões
Aprovações
Identificação dos ICS’s
Os itens de configuração, os níveis de controle exigidos e
os identificadores para cada um encontram-se descritos na
Tabela 5. Outros itens também poderiam ser controlados
mas para exemplificar este estudo de caso, os itens constan­
tes nesta tabela são suficientes.
Regras para nomeação dos itens de configuração
Com exceção do Plano de Gerencia de Configuração,
Fontes e Executáveis, o nome dos artefatos deverá seguir
a seguinte regra:

24 Engenharia de Software Magazine - Gerência de Configuração

 Projeto

<SISVEN>-<identificador_do_artefato>-<xxx> Armazenamento dos ICS’s

Todos os ICS’s especificados na Tabela 5 serão armaze­
Onde <xxx> é um número sequencial começando em 001. nados em um repositório do Subvesion em um servidor de
arquivos que poderá ser acessado via Internet ou através
Descrição Identificador Nível de Controle da rede local. A estrutura do diretório do repositório para
Casos de uso UC Versão e mudança armazenamento do sistema SISVEN pode ser visto na
Diagrama de Classes DC Versão e Mudança Figura 8.
Documento de Requisitos DR Versão e Mudança
Plano de Testes PTES Versão e Mudança
Plano de Gerencia de Configuração - Versão e Mudança
Código Fonte - Versão e Mudança
Release - Versão e Mudança

Tabela 5. Itens de Configuração

Regras para versionamento

As regras de versionamento serão aplicadas apenas nas
identificações de tags e branches, uma vez que o Subver­
sion controla as versões de itens de configuração a cada
operação de commit.
O padrão de versionamento utilizará a regra descrita a
seguir:
<XX>.<YY>
onde:
• XX é um número decimal que representa a versão;
• YY é um número decimal que representa a modificação.
O primeiro numero de versão deverá ser 01.00. A cada mo­
dificação, o valor YY deve ser incrementado de uma unidade
e retorna para 00 assim que uma nova versão é gerada.
Identificação de Tags
Sempre que uma nova baseline for criada, esta deverá ser
identificada por uma tag seguindo as seguintes regras:
• Baseline de Documentos
DOC-V-<versão>
• Baseline de Código Fonte
FONTE-V-<versão>
• Baseline de Releases
RELEASE-V-<versão>
Onde <versão> segue as regras descritas no item anterior.
Identificação de Branches
Sempre que houver necessidade de criação de um branch, sua
identificação deverá obedecer aos seguintes padrões:
• Branch de Documentos
DOC-MANUT-<número_da_solicitação_de_modificação>
• Branch de Código Fonte
FONTE-MANUT-< número_da_solicitação_de_modificação>
• Branch de Releases
RELEASE-MANUT-< número_da_solicitação_de_modificação>
O <número_da_solicitação_de_modificação> será aquele atri­
buído pelo campo ticket do Mantis conforme veremos adiante.
Figura 8. Estrutura de diretório do repositório
Gerenciamento de Baselines
Sempre que uma modificação for concluída, seja em algum
documento ou código fonte e o gerente de projetos tiver
inspecionado os testes e aprovado, o desenvolvedor poderá
solicitar ao gerente de configuração a criação de uma base­
line. As baselines ficarão armazenadas na subpasta “tag”
da estrutura de diretório do repositório.
Os branches deverão ser criados pelo gerente de configu­
ração apenas quando a modificação exigida pela solicitação
de mudança levar um tempo para sua conclusão superior
a três semanas, caso contrário será feita na mainline cuja
subpasta da estrutura de diretório chama-se “trunk” (ver
Figura 8).
Apenas o gerente de configuração terá autoridade para
criar branches e tags e deverá fazê-lo mediante a solicitação
formal do gerente de projeto que deverá enviar um e-mail
especificando o que e para quem deve ser criado.
Estabelecimento de um sistema de GCS
Conforme descrito no MPS.BR Guia de Implementação
(SOFTEX, 2009, p. 20), para que a Gerência de Configu­
ração ocorra de forma sistemática, é necessário que seja
estabelecido um sistema de Gerência de Configuração. Esse
sistema pode ser decomposto em três subsistemas: sistema
de controle de versões, sistema de controle de modificações
e sistema de gerenciamento de construção.
Para o subsistema de controle de modificações, utiliza­
remos a ferramenta Mantis. A escolha desta ferramenta
está apoiada no fato de ser open source (o que diminui os
custos), por ter integração direta com o Subversion (o que
permite dar visibilidade ao processo), e ser uma aplicação.

Edição 24 - Engenharia de Software Magazine 25

A Figura 9 ilustra o fluxo básico de controle de modificações produto TortoiseSVN que faz a mesma coisa só que de forma
que será seguido quando uma solicitação de modificação interativa e visual facilitando o trabalho.
for feita pelo usuário.

Figura 10. Tela de login do Mantis

Figura 9. Fluxo do Controle de modificações da empresa “Casa do Software” Figura 11. Visão inicial dos status de solicitações de mudanças

Nas Figuras 10 a 14 podemos visualizar como o Mantis

trata o controle de uma solicitação de modificações. Na
Figura 10 observamos que existe um controle de acesso
às solicitações a nível de tipo de usuário que pode ser um
relator, desenvolvedor, gerente administrador etc, cada qual
com suas restrições de acesso.
Na Figura 11 temos uma visão (a nível de usuário) das diver­
sas solicitações e seus status. Nas Figuras 12 a 14 aparece em
detalhes todos os tramites pelos quais passou uma solicitação
de mudanças, permitindo manter informado o usuário solici­
tante e todos os outros envolvidos no processo de GCS.
Para o subsistema de controle de versões, será utilizado o
Subversion. A escolha desta ferramenta também está baseada
no fato de ser open source, ter integração com o Mantis e com Figura 12. Visão detalhada de uma solicitação de mudança (Informações
o Eclipse. O Subversion possui uma parte server que roda em gerais)
um servidor e que fica responsável por fazer as operações de
check-in, check-out, controle de lock, merge, controle de acesso Na Figura 15 é apresentado um fluxo básico de utilização
e outras. O Subversion possui também uma parte client, que do Subversion.
roda na máquina do desenvolvedor e que tem a função de Nas Figuras 16 a 23 são apresentados exemplos das funções
solicitar à parte server as funções necessárias. Como a parte descritas na Figura 15 usando-se o TortoiseSVN.
client do Subversion é executada em linha de comando, e por As Figuras 16 e 17 mostram que o desenvolvedor deve fazer
esta razão ser pouco amigável, iremos utilizar como client o uma cópia dos ICS’s do repositório para seu disco local a fim

26 Engenharia de Software Magazine - Gerência de Configuração

 Projeto

de poder fazer as modificações necessárias utilizando-se da

operação de check-out. A Figura 18 mostra que novos itens de
configuração são adicionados à cópia local do repositório atra­
vés de operação de add. A Figura 19 mostra uma operação de
update para atualizar a cópia local do repositório. As Figuras 20
à 22 mostram uma atualização da mainline através de uma
operação de commit. Vale observar neste ultimo caso que esta
operação é controlada com autenticação de usuário e senha.
Por fim, a Figura 23 mostra um log com todas as operações
executadas neste repositório ao longo do tempo.
Através das figuras vistas pode-se concluir que o Subversion
Figura 16. Fazendo check-out
controla de forma adequada o armazenamento e manuseio de
ICS’s, fornecendo dados para sua auditoria.

Figura 17. Resultado da operação de check-out

Figura 13. Visão detalhada de uma solicitação de mudanças (Anotações)

Figura 18. Adicionando novos programas ao repositório local

Figura 14. Visão detalhada de uma solicitação de mudança (Histórico

do caso)

Figura 15. Fluxo básico de utilização do subversion Figura 19. Fazendo uma operação de update para atualizar a cópia local

Edição 24 - Engenharia de Software Magazine 27

Figura 20. Iniciando uma operação de commit
Figura 21. Operação de commit (autenticação de usuário autorizado)
Figura 22. Resultado da operação de commit
Resultados esperados do MPS.BR alcançados na solução
adotada
Conforme descrito anteriormente, a solução adotada deve­
rá estar em conformidade com o modelo MPS-BR.
Segundo o MPS.BR Guia Geral (SOFTEX, 2009, p.23) o
processo de Gerencia de Configuração encontra-se no nível
“F” do MR-MPS e deve atingir sete resultados esperados.
A Tabela 6 mostra os resultados esperados e os itens deste
trabalho onde estão contemplados.
28 Engenharia de Software Magazine - Gerência de Configuração
Figura 23. Log das operações realizadas no repositório
Instalação do Mantis
A versão do Mantis para Windows pode ser baixada a
partir do site “http://www.mantisbt.org/download.php”.
A sua versão estável mais recente é a MantisBT 1.1.8. Os se­
guintes softwares são requeridos e devem ser instalados:
• PHP 4.3.0 and higher
• MySQL database 4.1.1 and higher (MS SQL and DB2 are
also supported).
• Web server (Apache, IIS, etc.)
Como forma de facilitar a instalação dos softwares acima,
pode ser instalado a última versão do XAMPP que traz
todos os requisitos para rodar o Mantis. O XAMPP pode
ser baixado a partir do site www.baixaki.com.br.
Caso seja instalado o XAMPP, o diretório de instalação do
Mantis deve estar localizado na pasta “htdocs” existente
no diretório de instalação do XAMPP.
O Mantis é simples de instalar. Basicamente é só seguir
as instruções de instalação que irão surgir na tela.
Configuração do Mantis
Após instalado o Mantis é necessário configurar o arquivo
“config.inc.php” com os parâmetros corretos para emissão
de e-mails. A configuração utilizada neste trabalho está
apresentada na Figura 24. Os campos “user”, “domínio” e
“password” que aparecem no texto devem ser substituídos
pelos correspondentes de cada caso.
A configuração listada na Figura 24 já inclui os parâ­
metros necessários para integração com o Subversion. O
significado de cada parâmetro pode ser obtido no manual
do Mantis no endereço “http://manual.mantisbt.org/
index.php”.
Vale observar que para que o envio de e-mails a cada novo
status de uma solicitação de modificação ocorra, é neces­
sário a instalação do PHPMailer, que pode ser encontrado
no site “http://phpmailer.sourceforge.net”. A instalação do
PHPMailer é simples, bastando para tanto copiar os arqui­
vos “class.smtp.php” e “class.phpmailer.php” para o diretó­
rio destinado aos arquivos de include. No caso do XAMPP o
diretório é “<diretório_de_instalação_do_XAMPP>\ php\
 Projeto

Resultado esperado Seção

GCO 1. Um Sistema de Gerência de Configuração é estabelecido e mantido Estabelecimento de um sistema de GCS
GCO 2. Os itens de configuração são identificados com base em critérios estabelecidos Identificação dos ICS’s
Regras para nomeação dos itens de configuração
Regras para versionamento
Identificação de Tags
Identificação de Branches
GCO 3. Os itens de configuração sujeitos a um controle formal são colocados sob baseline Armazenamento dos ICS’s
Gerenciamento de Baselines
Estabelecimento de um sistema de GCS
GCO 4. A situação dos itens de configuração e das baselines é registrada ao longo do tempo e Gerenciamento de Baselines
disponibilizada; Estabelecimento de um sistema de GCS

GCO 5. Modificações em itens de configuração são controladas; Estabelecimento de um sistema de GCS

GCO 6. O armazenamento, o manuseio e a liberação de itens de configuração e baselines são Estabelecimento de um sistema de GCS
controlados

GCO 7. Auditorias de configuração são realizadas objetivamente para assegurar que as baselines e os Estabelecimento de um sistema de GCS
itens de configuração estejam íntegros, completos e consistentes

Tabela 6. Resultados esperados no nível F do MPS.BR

PEAR”. A instalação está descrita no arquivo “readme” que

traz também um exemplo simples.

Instalação do Subversion
A instalação do Subversion é mais simples do que a do
Mantis. O arquivo de instalação pode ser obtido no ende­
reço http://www.collab.net/downloads/subversion/. O
único software requerido é o Apache version: 2.2.11 que
já estará instalado caso o XAMPP tenha sido instalado
primeiro. Vale ressaltar que neste endereço existem dois
arquivos de instalação que devem ser baixados:
• CollabNet Subversion Server and Client v1.6.3 (for
Windows)
• CollabNet Subversion Command-Line Client v1.6.3 (for
Windows)

O primeiro é obrigatório para o funcionamento das ope­

rações. Para o segundo arquivo, poderá ser usada a alter­
nativa do software “TortoiseSVN” que é mais amigável e
tem integração direta com o Windows Explorer. O arquivo
para instalação do TortoiseSVN pode ser encontrado no
site “www.baixaki.com.br”. Não é necessário configuração
adicional no software para o seu funcionamento, porém,
para cada repositório deverá ser configurado os perfis Figura 24. Arquivo config.inc.php
de acesso no arquivo “svnserve.conf”. Para detalhes de
integração do Subversion com o Mantis, consulte o site terminologias e algumas ferramentas voltadas para dar
http://alt-tag.com/blog/archives/2006/11/integrating- apoio à GCS.
mantis-and-subversion/. Na sequencia, mostramos uma solução de boa qualidade e
baixo custo que atende as exigências dos modelos de maturi­
Consideraçõs Finais dade e que pode ser facilmente implementada em empresas
Neste artigo, vimos inicialmente os conceitos gerais de de pequeno porte a fim de instalar as práticas de Gerência de
Gerencia de Configuração de software, suas principais Configuração de Software. A solução foi mostrada através de

Edição 24 - Engenharia de Software Magazine 29

um estudo de caso em uma empresa fictícia, e fez uso das fer­ Dê seu feedback sobre esta edição! eu
Feedback

s
ramentas Mantis e Subversion para o controle de solicitação

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

sobre e
de modificações e controle de versões respectivamente.
Para isso, precisamos saber o que você, leitor, acha da revista!
Foram apresentados ainda aspectos de instalação das ferra­

s
ta
edição
Dê seu voto sobre este artigo, através do link:
mentas e sua customização.
www.devmedia.com.br/esmag/feedback

Referências Links

Barbosa, Valeria Plano de Gerência de Configuração de Software: Sistema de
Controle de Custos 11/09/2007 disponível em http://conexao.googlecode.com/files/
SYSCOPlanoGerenciaConfiguracao.pdf
Ben Collins-Sussman, de et al Version Control with Subversion: for Subversion 1.6 (Compiled
from r3445) 2008 disponível em <http:subversion.tigris.org/>
Borges, Vanessa R. Implantação de Práticas de Gerência de Configuração em uma Fábrica de
Software: Um estudo de caso (Graduação em Ciência da Computação) Universidade Federal de
Lavras, Minas Gerais, 2006
Forte, G.,“Rally Round the Repository”, CASE Outlook, Dez 1989, p. 5-27
MOLINARI, Leonardo. Gerência de configuração: Técnicas e práticas no desenvolvimento do
software. Florianópolis : Visual Books, 2007. 208p.
Neto, Euclides Plano de Gerência de configuração de software: Projeto VENSSO – Venda
de Serviços de Software 27/05/2005 disponível em <http://vensso.sourceforge.net/doc/
VENSSO_SCM_20050527.pdf>
Collabnet “CollabNet Subversion Downloads”
http://www.collab.net/downloads/subversion/
Comunidade de Software & Inovação Empresarial “As Ferramentas de SCM e o Suporte
do CMM”
http://paginas.ispgaya.pt/~msantos/es_artigos_tecnicos_1/60_FerramentasSCM_e_
suporteCMM.pdf
DevMedia “Gerência de Configuração – Parte 1”
http://www.devmedia.com.br/articles/viewcomp.asp?comp=9378
EAI Community “Establishing a Configuration Management Baseline”
http://it.toolbox.com/blogs/enterprise-solutions/establishing-a-configuration-management-
baseline-13910
Enciclopédia Livre, (2007) “Gerência de Configuração de Software”
http://pt.wikipedia.org/wiki/Ger%C3%AAncia_de_Configura%C3%A7%C3%A3o_de_Software
Gerência de Configuração “Gerência de Configuração”
http://www.cin.ufpe.br/~gfn/qualidade/gc.html

PRESSMAN, Roger S. Engenharia de software. 6ª. ed. São Paulo : McGraw-Hill, 2006. xxxi, 720p.
SEI, Software Engineering Institute. CMMI for Development, Version 1.2: CMMI DEV V 1.2.
Carnegie Mellon University, EUA, 2006 573p.
SOFTEX MPS.BR - Melhoria de Processo do Software Brasileiro, Guia de Implementação – Parte 2:
Nível F, Rio de Janeiro, 2009 53p
Mantis “Mantis Bug Tracker”
http://www.mantisbt.org/
Pronus Engenharia de Software “O que é Gerência de Configuração”
http://www.pronus.eng.br/artigos_tutoriais/gerencia_configuracao/gerencia_configuracao.php
Regularize “Gerência de Configuração de Software”
http://cartilha.regularize.com.br/list/18/cartilha/post/80/gerencia-de-configuracao-de-software.html

SOFTEX, MPS.BR - Melhoria de Processo do Software Brasileiro, Guia Geral Rio de Janeiro, 2009 57p Tigris.org “Subversion”
http://subversion.tigris.org/

30 Engenharia de Software Magazine - Gerência de Configuração

Engenharia
Nesta seção você encontra artigos voltados para testes, processo,
modelos, documentação, entre outros
Medição de Software
Um importante pilar da melhoria de processos de software
Monalessa Perini Barcellos
monalessa@inf.ufes.br
É Doutora em Ciências em Engenharia de
Sistemas e Computação (COPPE/UFRJ), Mes-
tre em Ciências em Engenharia de Sistemas
e Computação (COPPE/UFRJ), Bacharel em
Ciência da Computação (UFES). Professora
do Departamento de Informática, área Enge-
nharia de Software, da Universidade Federal
do Espírito Santo (UFES). Atuante desde 1999
em projetos, consultorias, treinamentos e pes-
quisas da área de Engenharia de Software.
O
s avanços tecnológicos e a alta
competitividade do mercado
estão continuamente aumen­
tando a demanda por softwares cada
vez melhores e que sejam produzidos
em projetos aderentes aos custos e
prazos planejados. Mesmo diante de
todos os avanços tecnológicos, realizar
projetos aderentes aos seus planos ain­
da é um desafio para grande parte das
organizações de software. Buscando
aprimorar suas práticas de Engenharia
de Software e, consequentemente, desen­
volver produtos de melhor qualidade em
projetos conduzidos de acordo com seus
planos, as organizações têm mostrado
um crescente interesse por programas
de melhoria de processos, contexto no
qual a medição de software tem papel
fundamental.
Edição 24 - Engenharia de Software Magazine
processo
De que se trata o artigo?
Este artigo discute algumas questões relaciona-
das à Medição de Software, principalmente no
contexto da melhoria de processos de software.
Para que serve?
Fornecer conhecimento sobre Medição de Softwa-
re para organizações, pesquisadores, estudantes e
profissionais de software.
Em que situação o tema é útil?
Organizações de software que têm (ou planejam
ter) a Medição de Software como uma de suas
práticas. Estudantes e profissionais de software
que buscam entendimento sobre o tema.
A medição de software é considerada
uma das atividades mais importantes
para a gerência e melhoria de processos
e produtos de software, uma vez que
fornece subsídios para a elaboração de
planos realistas para os projetos e possi­
bilita o monitoramento da aderência da
execução dos projetos em relação a seus
planos (ISO/IEC, 2007). Isso é possível,
pois as medidas, ao serem coletadas e
armazenadas, podem ser analisadas
31
através de métodos e fornecem informações importantes para
a tomada de decisão, envolvendo a identificação e realização
de ações corretivas e preventivas que orientem os projetos e
processos a alcançarem os objetivos para eles estabelecidos.
Resumindo: organizações de software que buscam a melhoria
de seus processos precisam realizar medição de software.
Considerando essa afirmação, neste artigo são discutidas
algumas questões relacionadas à medição de software e são
apresentadas algumas propostas que apóiam a definição
do processo de medição de software e sua realização nas
organizações.
É importante destacar que o objetivo aqui não é “ensinar como
realizar a medição”, e sim discutir questões relacionadas a esse
contexto. Para isso, inicialmente são apresentados o conceito
e um breve histórico da medição de software. Em seguida, a
utilização da medição de software nas organizações é discu­
tida e, por fim, algumas propostas que apóiam a definição do
processo de medição e sua execução são descritas.
Conceito e Histórico
Medição de software é uma avaliação quantitativa de qual­
quer aspecto dos processos e produtos da Engenharia de
Software, que permite seu melhor entendimento e, com isso,
auxilia o planejamento, controle e melhoria do que se produz
e de como é produzido (BASS et al., 1999). O elemento básico
da medição, que propicia a análise quantitativa, são as medi­
das, as quais caracterizam, em termos quantitativos, alguma
propriedade de um objeto da Engenharia de Software.
O objetivo mais importante da aplicação da medição de sof­
tware é prover informação quantitativa para apoiar a tomada
de decisões. Em outras palavras, as organizações de software
definem medidas e coletam dados que, ao serem analisados,
possam fornecer informações que sejam úteis à tomada de
decisões, que envolve a análise do alcance aos objetivos esta­
belecidos e identificação de ações corretivas e de melhoria.
A medição de software começou a ser praticada na década de
70, inicialmente apenas para medir o número de linhas de código
dos programas produzidos. Na década de 80, outras medidas –
relacionadas às fases finais do desenvolvimento – começaram
a ser utilizadas, porém os objetivos da realização da medição
nas organizações não eram explícitos ou, se eram, não eram
compreensíveis aos seus membros, resultando em medições
inúteis não alinhadas às necessidades das organizações ou dos
projetos. Nos anos 90, impulsionados por algumas aplicações
bem sucedidas, foram desenvolvidos modelos para o processo
de medição baseados na melhoria de processos e nos princípios
da qualidade total, fornecendo as diretrizes e a infraestrutura
básicas para definir, coletar, validar e analisar medidas.
Atualmente, a medição de software é considerada um dos
temas mais importantes na Engenharia de Software quando se
fala em melhoria de processos. Enquanto, no passado, muitas
organizações de software não reconheciam a importância das
atividades de medição e as tratavam apenas como “mais uma
coisa a ser feita”, hoje ela é considerada uma prática básica da
Engenharia de Software, sendo evidenciada por sua inclusão
32 Engenharia de Software Magazine - Medição de Software
nos requisitos dos níveis iniciais dos modelos que tratam da
melhoria de processos em níveis. No CMMI (Capability Ma­
turity Model Integration), a medição encontra-se no nível 2
(área de processo Medição e Análise) e no MR MPS (Modelo de
Referência para Melhoria de Processo de Software Brasileiro)
encontra-se no nível F (processo Medição).
Medição de Software nas Organizações
Para que a medição de software seja eficientemente reali­
zada em uma organização, e dê o retorno necessário para
ser percebida como prática fundamental à sobrevivência e
ao crescimento organizacional, sua implementação deve ser
orientada para apoiar a tomada de decisão nos âmbitos técnico
e de negócios. Esse é o principal diferencial entre as organi­
zações que se beneficiam com os resultados de seu programa
de medição e as organizações que simplesmente despendem
tempo e esforço para acumular dados inúteis.
Organizações de software bem sucedidas geralmente imple­
mentam a medição como parte de suas atividades, englobando
os níveis técnico, gerencial e estratégico. Nessas organizações, a
medição provê a informação necessária às tomadas de decisão
que impactam no desempenho técnico e de negócio, sendo essa
informação disponibilizada para os tomadores de decisão em
todos os níveis da organização, de acordo com seus objetivos.
Um gerente de projetos pode, por exemplo, utilizar as informa­
ções providas pela medição para realizar uma comunicação mais
eficiente, traçar os objetivos específicos dos projetos, identificar
e corrigir problemas antecipadamente, tomar decisões chave e
justificar tais decisões. Mas é importante ressaltar que, assim
como qualquer outra ferramenta gerencial ou técnica, a medição
não é capaz de garantir o alcance dos objetivos. Entretanto, ela é
capaz de auxiliar os tomadores de decisão a terem uma aborda­
gem pró-ativa às questões críticas inerentes aos projetos, o que
contribui para que os objetivos sejam alcançados.
Além de apoiar fortemente a tomada de decisão, a medição
auxilia e acelera o aprendizado organizacional, uma vez que
a análise dos dados coletados nos projetos provê a funda­
ção necessária para o aprendizado através de cada projeto
e, consequentemente, para o aprendizado organizacional.
Também auxilia a organização a perceber e entender as
diferenças entre o seu desempenho e o desempenho exigido
pelo mercado, permitindo que ela otimize seus processos
técnicos e de negócio, quando necessário. Isso é possível, pois
as medidas coletadas nos projetos da organização podem ser
combinadas e, através da utilização de diferentes técnicas,
analisadas para satisfazer as diferentes necessidades de in­
formação organizacionais.
As organizações podem, ainda, utilizar as informações
providas pela medição para elaborar planos realistas para os
projetos, comparar o desempenho dos projetos correntes com
seus planos, orientar os investimentos e decisões de melhoria
de processos e auxiliar a prever se os projetos em andamento
irão alcançar os objetivos inicialmente estabelecidos. Essas são
ações comuns em organizações de software maduras, onde
há utilização da medição em todo o ciclo de vida do software

e as informações obtidas são consideradas e utilizadas como
recurso estratégico na condução desse ciclo.
Somente quando as informações obtidas na análise dos dados
coletados são utilizadas para direcionar as ações necessárias
às organizações e seus projetos, é que o objetivo fundamental
da medição é alcançado e percebido pelas organizações, fator
que contribui para a real institucionalização de um programa
de medição eficiente.
Uma vez que a medição de software é implantada e executada
corretamente em uma organização, torna-se possível passar à
melhoria de processos.
Melhoria de processos de software é uma abordagem para de­
finição, organização e implementação de processos de software
que sejam eficientes para uma organização (KILPI, 2001).
Implantar melhoria de processos em uma organização baseia-se
fundamentalmente na identificação e realização das mudanças
que levam à melhoria dos processos. Para isso, inicialmente a
medição é utilizada para identificar as necessidades de mudanças.
Posteriormente, quando as mudanças são realizadas, a medição
é utilizada para avaliar os resultados das alterações. Em outras
palavras, a melhoria de processos é um ciclo contínuo no qual a
medição é um dos principais pilares.
Abordagens para Medição de Software
Existem na literatura técnica algumas abordagens que
tratam a medição de software e apóiam a definição do
processo de medição, bem como sua execução. Algumas
dessas abordagens propõem processos para a realização
da medição, outras definem modelos de informação que
estabelecem a estrutura de informação considerada pela
medição e outras incluem propostas tanto para o processo
de medição quanto para o modelo de informação.
O processo de medição pode ser definido como um conjun­
to de passos que deve orientar a realização da medição em
uma organização. Um processo de medição eficiente é fator
crítico ao sucesso da medição na organização, pois é ele que
direciona as atividades a serem realizadas para que, com
os resultados da análise dos dados coletados, seja possível
a identificação de tendências e antecipação aos problemas,
a fim de prover melhor controle dos custos, redução dos
riscos, melhoria da qualidade e, consequentemente, alcance
dos objetivos técnicos e de negócio (WANG e LI, 2005).
Apesar das propostas existentes possuírem diferenças
entre si, percebe-se que, no âmbito do processo de medição,
as definições propostas consistem basicamente de quatro
etapas: (i) definição das medidas; (ii) coleta das medidas;
(iii) análise das medidas coletadas; e, (iv) utilização dos
resultados da análise em ações.
A seguir são apresentadas as principais abordagens de
medição de software.
• ISO/IEC 15939 - Software Engineering – Software Mea-
surement Process
A norma ISO/IEC 15939 define uma das abordagens mais
conhecidas para o processo de medição. Segundo essa nor­
ma, um processo de medição é descrito como um modelo
processo
que identifica as atividades do processo de medição que são
requeridas para especificar que informações de medição
são necessárias, como as medidas serão definidas, como os
dados serão coletados, como os resultados serão analisados
e como avaliar se os resultados são válidos. O processo
de medição definido na ISO/IEC 15939 consiste de quatro
atividades que são sequenciadas em um ciclo iterativo, per­
mitindo feedback e melhoria contínua do processo. Ele é uma
adaptação do ciclo PDCA (Plan-Do-Check-Act), comumente
utilizado como base para a melhoria da qualidade. Suas ati­
vidades são: (i) estabelecer e manter comprometimento com
a medição; (ii) planejar o processo de medição; (iii) executar
o processo de medição; e, (iv) avaliar a medição.
O processo de medição proposto pela ISO/IEC 15939 é
orientado às necessidades de informação da organização.
Para cada necessidade de informação, o processo gera um
produto de informação, a fim de satisfazer a necessidade de
informação identificada. Para isso, o processo considera um
Modelo de Informação de Medição, que estabelece a ligação
entre as medidas definidas e as necessidades de informação
identificadas. A Figura 1 apresenta o Modelo de Informação
de Medição definido na ISO/IEC 15939.
Figura 1. Modelo de Informação de Medição da ISO/IEC 15939
De acordo com o Modelo de Informação de Medição, as ne­
cessidades de informação são atendidas por conceitos men­
suráveis definidos em relação às entidades que podem ser
medidas. Essas entidades possuem atributos aos quais são
aplicados métodos de medição para obter medidas base que
são associadas através de funções de medição para compor
medidas derivadas1. Medidas são analisadas por modelos de
análise e fornecem indicadores cuja interpretação representa
1 Medidas base são funcionalmente independentes de outras medidas,
enquanto que medidas derivadas são definidas como função de duas ou mais
medidas (ISO/IEC, 2002)
Edição 24 - Engenharia de Software Magazine 33
produtos de informação que atendem as necessidades de
informação inicialmente identificadas.
• IEEE Std 1061-1998 – IEEE Standard for a Software Quality
Metrics Methodology
O IEEE Std 1061-1998 provê um framework para medidas de
qualidade de software e um processo de medição de qualidade
de software para estabelecer requisitos de qualidade e iden­
tificar, implementar, analisar e validar medidas de qualidade
de processo e de produto.
Na Figura 2 é apresentado o framework para medidas de qua­
lidade de software definido no IEEE Std 1061-1998.
No primeiro nível são estabelecidos os requisitos de qua­
lidade do sistema (representado na Figura 2 pelo item Qua­
lidade de Software do Sistema) através da identificação de
atributos de qualidade (por exemplo, Confiabilidade). Fatores
de qualidade são, então, definidos para representar a visão
dos atributos de qualidade segundo a gerência e o usuário.
Para cada fator de qualidade é identificada uma medida para
representá-lo quantitativamente. Por exemplo: o atributo de
qualidade Confiabilidade pode ser representado pelo fator
de qualidade Tolerância a falhas, quantificado pela medida
Tempo médio entre falhas. Se necessário, os fatores podem
Figura 2. Framework para medidas de qualidade do IEEE Std 1061-1998
Figura 3. Modelo de Informação de Medição
34 Engenharia de Software Magazine - Medição de Software
ser decompostos em subfatores que, por sua vez são, também,
quantificados por medidas.
Baseando-se no framework definido, o IEEE Std 1061-1998
propõe um processo de medição composto por cinco ativida­
des: (i) estabelecer os requisitos da qualidade de software; (ii)
identificar as medidas de qualidade de software; (iii) imple­
mentar as medidas; (iv) analisar os resultados das medidas; e
(v) validar as medidas.
• Practical Software Measurement – PSM
PSM é uma abordagem para medição de software orientada
às necessidades de informação organizacionais aderente
à ISO/IEC 15939 e, como ela, possui dois componentes:
um Modelo de Informação de Medição e um Processo de
Medição.
O Modelo de Informação de Medição, assim como na ISO/
IEC 15939, tem como objetivo estabelecer a ligação entre as
medidas definidas e as necessidades de informação iden­
tificadas. Para isso, como mostra a Figura 3, o modelo de
informação representa a evolução de uma necessidade de
informação até o Plano de Medição.
A partir das necessidades de informação, conceitos mensu­
ráveis, que indicam o que deve ser medido para atendê-las,
devem ser identificados e modelados em um construtor de

medição para estabelecer exatamente que medidas de que
atributos são necessárias. A partir daí, o mecanismo de
coleta e organização dos dados de uma ou várias instân­
cias do construtor de medição deve ser definido. O Plano
de Medição é o resultado formal que agrupa todos os itens
anteriores.
Sendo aderente à ISO/IEC 15939, a relação entre neces­
sidades de informação e conceito mensurável do Modelo
de Informação do PSM equivale à relação entre esses itens
presente no Modelo de Informação de Medição da ISO/
IEC 15939 (representado no lado esquerdo da Figura 1). O
construtor de medição, por sua vez, inclui os demais itens
presentes no Modelo de Informação da ISO/IEC 15939 (de­
mais itens representados na Figura 1).
Considerando o modelo de informação definido, o PSM
propõe um processo de medição composto por quatro
fases: (i) planejamento; (ii) execução; (iii) avaliação; e (iv)
comprometimento.
Observando-se as primeiras etapas dos processos de
medição propostos nas abordagens apresentadas, nota-se
que elas são responsáveis pela identificação e definição das
medidas, bem como pela associação destas aos objetivos
organizacionais. Essas etapas são de grande importância
para a medição, pois são elas que definem que informações
serão fornecidas para apoiar as tomadas de decisão.
Essa tarefa pode parecer simples, mas não é, principalmente
em organizações de software. Para que as atividades de me­
dição estejam alinhadas aos objetivos de negócio, é preciso
identificar os fatores críticos que são capazes de determinar
se os objetivos de negócio serão ou não alcançados. Consi­
derando essa questão, há algumas abordagens que apóiam a
identificação e seleção de medidas adequadas à avaliação do
Figura 4. Exemplo de aplicação do GQM
processo
alcance dos objetivos organizacionais. Uma das abordagens
mais conhecidas é o Goal Question Metric - GQM que consi­
dera que, para cada objetivo estabelecido, é possível determi­
nar questões cujas respostas estão associadas a medidas. A
Figura 4 apresenta um exemplo para a relação de um obje­
tivo de negócio, suas questões e medidas associadas.
Após serem definidas, as medidas devem ser coletadas e
analisadas. O objetivo de analisar os dados das medidas é
tornar qualquer padrão, tendência ou relacionamento mais
visível, a fim de que estes possam auxiliar nos julgamen­
tos necessários às tomadas de decisão. Durante a análise,
medidas que fornecem informações sobre o alcance dos
objetivos são transformadas em indicadores. Os indicadores
são medidas base ou medidas derivadas que, associadas a
critérios de avaliação ou decisão pré-definidos, são capazes
de fornecer informações que descrevem o alcance dos obje­
tivos estabelecidos. São inicialmente definidos no Plano de
Medição, mas à medida que novas necessidades são identi­
ficadas, novos indicadores devem ser definidos.
Em relação à análise dos dados coletados para as medidas,
é importante observar que, ao longo da execução de um
processo de medição, o foco da análise muda de acordo com
a fase do ciclo de vida dos projetos nos quais a medição é
aplicada. Tipicamente são considerados três tipos de análise:
(i) análise de estimativas, utilizada principalmente no início
do projeto, para apoiar o planejamento ou replanejamentos;
(ii) análise de viabilidade, utilizada quando o Plano do
Projeto está próximo de ser concluído, para determinar se
os planos e metas nele estabelecidos são realísticos e al­
cançáveis; e (iii) análise de desempenho, utilizada durante
a execução do projeto para determinar se ele está indo ao
encontro dos planos e metas definidos. A Figura 5 ilustra
os três tipos de análise.
Edição 24 - Engenharia de Software Magazine 35
 projetos. Também apóia a melhoria de processos no nível or­
ganizacional, fornecendo informações resultantes da análise
dos dados coletados ao longo dos projetos, que podem ser
utilizadas para orientar ações de melhoria nos processos.
Neste artigo foram discutidos alguns aspectos relevantes
à aplicação da medição de software em organizações que
buscam a melhoria de processos, tendo sido enfatizada a
necessidade do alinhamento entre a medição e os objetivos
organizacionais.

Dê seu feedback sobre esta edição! Feedback

eu

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

sobre e
Para isso, precisamos saber o que você, leitor, acha da revista!

s
ta
edição
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback

Figura 5. Tipos de análise
No início de um projeto, é necessário estabelecer as es­
timativas para sua realização, principalmente as relacio­
nadas a tempo, custo e esforço. Dados do projeto corrente
e de projetos anteriores são utilizados para calcular essas
estimativas. O Plano do Projeto é então elaborado. Quando
sua elaboração está em fase conclusiva, dados das medidas
coletadas orientam a análise de viabilidade dos planos
estabelecidos, indicando os riscos envolvidos e fornecendo
diretrizes para que sejam traçadas outras alternativas, caso
necessário. Quando o projeto é executado, é importante que
seu status seja conhecido, bem como seu desempenho em
relação aos planos estabelecidos e possíveis problemas re­
lacionados. A análise de desempenho é quem fornece essas
informações, através da análise dos valores das medidas
coletadas ao longo do projeto, e relacionamento destas com
os objetivos estabelecidos nos planos.
Considerações Finais
Atualmente as organizações de software têm reconhecido a
necessidade de possuírem processos de software que sejam
capazes de atender às demandas de qualidade e produti­
vidade do mercado. Processos com essa característica são
resultado da gerência eficiente dos processos e projetos, que
leva à sua melhoria, contexto no qual a medição de software
é atividade primária.
A medição apóia a melhoria no nível dos projetos, uma vez
que fornece a base necessária para a realização de planos
realísticos e controle destes ao longo de sua execução nos
Referências
BASILI, V. R., ROMBACH, H. D., CALDIERA, G., 1994, Goal Question Metric Paradigm, Encyclopedia
of Software Engineering, 2 Volume Set, John Wiley & Sons, Inc.
BASS, L., BELADY, L., BROWN, A., FREEMAN, P., ISENSEE, S., KAZMAN, R., KRASNER, H., MUSA,
J., PFLEEGER, S., VREDENBURG, K., WASSERMAN, T., 1999, Constructing Superior Software,
Software Quality Institute Series, Macmillan Technical Publishing.
BRIMSON, J. A., 2004, Stop Cane Dancing and Integrate Statistical Process Control (SPC) into your
Process Based Management System, Measurement Business Excellence, v. 8, n. 2, p. 15-22.
CHRISSIS, M. B., KONRAD, M., SHRUM, S., 2006, CMMI (Second Edition): Guidelines for Process
Integration and Product Improvement, Addison-Wesley.
DEMING, W. E., 1986, Out of Crises, Massachusetts Institute of Technology, Center of Advanced
Engineering, Cambridge.
ISO/IEC, 2007, ISO/IEC 15939 (E) Software Engineering - Software Measurement Process,
International Organization for Standardization and the International Electrotechnical
Commission, Geneva, Switzerland.
KILPI, T., 2001, Implementing a Software Metrics Program at Nokia, IEEE Software, v. 18, n. 6,
p. 72-77.
McGARRY, J., CARD, D., JONES, C., LAYMAN, B., CLARK, E., DEAN, J., HALL, F., 2002, Pratical Software
Measurement: Objetive Information for Decision Makers, Addison Wesley, Boston, USA.
NIESSINK, F., VLIET, H., 2001, Measurement Program Success Factors Revisited, Information and
Software technology, v. 43, n. 10, p. 617-628.
SOFTEX, 2009, MPS.BR: Melhoria de Processo do Software Brasileiro - Guia Geral : 2009,
Disponível em: http://www.softex.br/mpsbr.
WANG, Q., LI, M., 2005, Measuring and Improving Software Process in China, In Proceedings
of International Symposium on Empirical Software Engineering - ISESE 2005, Hoosa Head,
Australia, p. 183-192.

36 Engenharia de Software Magazine - Medição de Software

 processo

Edição 24 - Engenharia de Software Magazine 37

Agilidade
Nesta seção você encontra artigos voltados para as práticas e métodos ágeis.
A Comunicação no Processo de Software
O papel cada vez mais decisivo da comunicação no processo de software
Márcia Regina Simm Cantú
macantu@bewnet.com.br
Bacharel em Ciência da Computação; atua
como analista de sistemas desde 2001.
38 Engenharia de Software Magazine - A Comunicação no Processo de Software
O
s avanços na área da tecnologia
têm permitido ao longo dos
últimos anos grande informa­
tização nos processos das organizações.
No entanto, dispor de um sistema de
software que atenda as diversas neces­
sidades da gestão organizacional pode
se tornar um processo complexo. Isso
implica, muitas vezes, em desenvolver
ou customizar um sistema. Mas não é só
isso: os sistemas de software precisam
evoluir para acompanhar os modelos de
gestão e, neste contexto passam obriga­
toriamente por manutenções que podem
ser melhorias, otimizações e até mesmo
reparos. Segundo Pfleeger (2004), estas
manutenções abrangem qualquer alte­
ração ou correção efetuada num sistema
que já está sendo utilizado, uma vez que
sua vida útil não acaba com a entrega. A
grande maioria dos sistemas de softwa­
re deve ser construída para incorporar
De que se trata o artigo?
Neste artigo veremos o quanto o processo de
software é permeado pelo processo de co-
municação interpessoal. Não se trata de um
processo apenas técnico, mas também social.
Com o advento do paradigma de desenvolvi-
mento rápido de software, destacamos o
papel cada vez mais decisivo da comunicação
interpessoal com a utilização de métodos
ágeis no desenvolvimento de software.
Para que serve?
O artigo busca identificar meios de ameni-
zar as barreiras de comunicação na gestão
de processos de software. Não se tem a
pretensão de esgotar o assunto, mas propor
uma reflexão acerca do tema, levantado por
diversos autores no campo da engenharia de
software.
Em que situação o tema é útil?
Na gestão e execução de processos de sof-
tware que necessitam de constantes adapta-
ções e integrações. Neste contexto, a comu-
nicação entre usuário e analista costuma ser
muito intensa, o que exige uma grande habi-
lidade de comunicação interpessoal, princi-
palmente por parte do analista de sistemas.

mudanças: seja porque o usuário decidiu realizar seu processo
de maneira diferente, seja porque houve alguma alteração de
leis ou normativas municipais, estaduais ou mesmo federais
que regulamentam os requisitos do sistema.
Num processo de software, tanto no desenvolvimento de um
sistema novo quanto na manutenção de um sistema existente, as
atividades relacionadas à etapa de levantamento de requisitos
representam um papel fundamental exatamente por constituí­
rem o alicerce para as fases subsequentes de desenvolvimento. O
levantamento de requisitos, de acordo com Sommerville (2007),
reflete as necessidades de um usuário e descrevem os serviços
que o sistema deve fornecer. Sendo assim, este não é um pro­
cesso apenas técnico, mas também social, uma vez que depende
fortemente de um entendimento entre os atores envolvidos, no
caso, o analista de sistemas e o usuário. Para Pressman (2006), o
levantamento de requisitos é uma atividade com comunicação
intensiva. O autor reforça a tese de que o ruído na comunicação
entre usuário e analista pode acarretar muitas dificuldades para
o desenvolvimento e/ou manutenção do sistema. Nesse sentido,
é necessário estudar e compreender como ocorre o processo de
comunicação a fim de buscar maneiras de minimizar as barrei­
ras da comunicação na gestão do processo de software.
O Processo de Comunicação
De acordo com Reti (2008), vive-se em um mundo de lingua­
gens próprias. Pode-se falar o mesmo idioma, mas usam-se
diferentes linguagens. Por isso, às vezes, não há um entendimen­
to adequado. Em função de cada indivíduo ter características
intrínsecas, grande parte das dificuldades de entendimento vem
da forma como cada um interpreta os fatos e a comunicação.
Até as próprias palavras podem ter significado único para cada
uma das pessoas do processo de comunicação. A expressão no
stress para o surfista é um tipo de onda ruim porque não tem
altura; para outros, significa “estar numa boa”.
O processo de comunicação é composto por cinco etapas, de
acordo com Chiavenato (1994):
• Emissor ou fonte: é a pessoa, coisa ou processo que emite
a mensagem;
• Transmissor ou codificador: elo que liga a fonte ao canal,
equipamento que transporta a mensagem codificada;
• Canal: espaço entre transmissor e receptor por onde a men­
sagem trafega;
• Receptor ou decodificador: equipamento que recebe a
mensagem e a decodifica. Se a comunicação é oral, a recepção
é garantida por meio de uma boa audição;
• Destino: é a pessoa, coisa ou processo para o qual a men­
sagem é enviada.
Existe ainda um elemento que deve ser acrescentado ao
Processo de Comunicação: o ruído. O ruído é uma interferên­
cia, um aspecto que prejudica a transmissão da mensagem e
distorce o seu significado. Estima-se que em todo o processo
de comunicação exista ruído, em maior ou menor grau.
Embora Chiavenato (1994) afirme que a comunicação é um
processo bidirecional e que necessita de um sinal de retroação ou
processo
confirmação de recebimento, é Griffin (2006) quem destaca a etapa
de feedback no processo de comunicação. Trata-se de um retorno
com relação ao recebimento da mensagem: é a certeza de que o
receptor recebeu a mensagem e a compreendeu. Isso eliminaria
a ocorrência do ruído, tornando a comunicação eficaz.
Apesar de parecer um processo simples, nem sempre, no en­
tanto, a mensagem enviada é igual à mensagem recebida. Isso só
ocorre porque o processo de comunicação é permeado ainda pelas
características das pessoas envolvidas. De acordo com Chiavenato
(1994), a comunicação é uma troca composta por palavras, letras
ou símbolos e engloba pensamentos, opiniões ou informações.
Neste sentido, o processo de comunicação é influenciado forte­
mente pela subjetividade humana, independente do ambiente
em que ocorre ou da forma como se dá.
Do ponto de vista organizacional, segundo Griffin (2006), a
comunicação tem o propósito de coordenar e orientar as metas
propostas. Isso só é possível com a troca de informações. Essa
troca permite o entendimento do que deve ser feito e como. Griffin
(2006, p.188) afirma ainda que: “A comunicação organizacional
expressa sentimentos e emoções. Por isso está longe de ser uma
coleção de fatos e números. Os funcionários, como acontece em
qualquer lugar do mundo, precisam comunicar emoções como
felicidade, raiva, desprazer, confiança e medo”.
Para Chiavenato (1994), a comunicação nas organizações difi­
cilmente ocorre sem problemas. O autor chama a atenção para o
fenômeno da transformação que ocorre no decorrer desse proces­
so, que faz com que o receptor receba uma mensagem diferente
daquela enviada pelo emissor. Essa transformação é provocada
por três problemas principais, no entender do autor:
• Omissão: supressão de conteúdo da mensagem;
• Distorção: alteração do conteúdo da mensagem;
• Sobrecarga: incapacidade de processar o volume de informa­
ções da mensagem, seja para o envio, seja para o recebimento
– provoca omissão e contribui para a distorção.
Mas, além desses problemas que transformam o processo de
comunicação, Chiavenato (1994) destaca ainda as barreiras da
comunicação, fatores que podem interferir nas etapas da comu­
nicação comprometendo o resultado final da mensagem enviada.
São exemplos de barreiras da comunicação: ideias preconcebidas,
significados pessoais, emoções, estado de ânimo, entre outras.
A especialização das pessoas nas organizações é, todavia, o
fator que mais influencia a comunicação no tocante ao processo
de software. Apontada como uma barreira da comunicação
por Megginson (1998), a especialização pode formar grupos
com interesses, comportamentos e até mesmo vocabulário
próprios. Tome-se, por exemplo, uma das etapas mais críticas
do Processo de software: o levantamento de requisitos. Imagine
o analista de sistemas interagindo com o usuário, cada qual
sintonizado nos seus conhecimentos técnicos. Não vai haver
entendimento, não vai haver comunicação.
Na concepção de Griffin (2006, p.192), a “comunicação é um
processo social em que duas ou mais partes trocam informações
ou compartilham significados. Trata-se de um processo de mão-
dupla e que acontece durante um certo tempo”.
Edição 24 - Engenharia de Software Magazine 39
 Sendo assim, para que ocorra comunicação e se alcancem os
objetivos desta fase do processo de software, o usuário deve ser
capaz de expressar suas necessidades numa linguagem que o
analista de sistemas entenda e o analista de sistemas deve ser
capaz de externar para o usuário o que entendeu.
O Processo de Software
Para Sommerville (2007, p. 42), “um processo de software
é um conjunto de atividades que leva à produção de um
produto de software”, no entanto, cada vez mais se aplica
o desenvolvimento de software para customizar sistemas
existentes. A Figura 1 ilustra o paradigma do ciclo de vida
clássico da Engenharia de Software, conhecido também por
“modelo em cascata”.
Análise
Requisitos
Projeto
Codificação
Teste
Manutenção
Figura 1. Ciclo de vida clássico - Fonte: Pressman (2006, p. 33)
Nessa visão clássica, o desenvolvimento de software se dá
seguindo etapas predefinidas que não iniciam antes do tér­
mino da etapa anterior, muito embora, na prática, observe-se
que essas etapas se sobrepõem e trocam informações entre si.
Pressman (2006) conceitua as etapas do ciclo da vida como:
• Análise: definição dos serviços e objetivos do sistema;
• Requisitos: descrição detalhada em linguagem natural
do que o sistema deve fazer. Definem as funções, serviços e
restrições operacionais do sistema (deve definir exatamente
o que será implementado);
Como os desenvolvedores vêem os usuários
Os usuários não sabem o que querem.
Os usuários não conseguem articular o que querem.
Os usuários têm muitas necessidades puramente políticas.
Os usuários querem tudo imediatamente.
Os usuários não sabem priorizar as necessidades.
Os usuários se recusam a se responsabilizar pelo sistema.
Os usuários são incapazes de fornecer uma declaração aproveitável sobre suas necessidades.
Os usuários não estão comprometidos com os projetos de desenvolvimento de sistemas.
Os usuários não querem se comprometer.
Os usuários não conseguem seguir o cronograma.
Tabela 1. Como usuários e desenvolvedores vêem uns aos outros - Fonte: Pfleeger (2004, p. 142)
40 Engenharia de Software Magazine - A Comunicação no Processo de Software
• Projeto: definição da estrutura de dados do sistema, sua arqui­
tetura, detalhes procedimentais e caracterização da interface;
• Codificação: implementação do sistema em linguagem de
máquina;
• Teste: validação dos aspectos lógicos internos do software,
bem como dos aspectos funcionais externos, a fim de garantir
que o sistema atenda as especificidades;
• Manutenção: tratamento de erros encontrados e adaptação
para novas funcionalidades. É importante salientar que a ma­
nutenção de um sistema de informação reaplica cada uma das
etapas precedentes do ciclo de vida ao sistema existente.
De acordo com Pressman (2006), uma compreensão completa
dos requisitos do sistema de informação é fundamental para
um bem-sucedido desenvolvimento de sistema. Não importa
quão bem projetado ou quão bem codificado seja, o sistema
mal especificado não atenderá as necessidades do usuário
e trará aborrecimentos e retrabalho ao desenvolvedor. Essa
constatação torna a etapa de levantamento de requisitos ex­
tremamente crítica para o sucesso do processo de software.
Como o levantamento de requisitos está relacionado com
a definição do que o sistema deve fazer, para Sommerville
(2007), esta etapa pode ser descrita como o processo de
comunicação entre usuário e analista e, nesse sentido, os
requisitos podem ser influenciados pelas preferências, recu­
sas e preconceitos dos usuários, além de questões políticas
e organizacionais. Essas diferenças de entendimento estão
intimamente ligadas ao processo de comunicação, uma vez
que a etapa de levantamento de requisitos decorre, basica­
mente, da interação entre analista de sistemas e usuário. É
importante salientar que essas preferências, recusas e pre­
conceitos podem surgir também por intermédio do próprio
analista de sistemas. Se, de um lado, o usuário afirma: “Não
era bem isto que eu queria!”, em contrapartida, é muito co­
mum ouvir um analista de sistemas se queixar: “O usuário
não sabe o que quer!”.
A Tabela 1 lista alguns destes estereótipos mais comuns
observados no relacionamento entre desenvolvedores de
sistemas e usuários.
Como os usuários vêem os desenvolvedores
Os desenvolvedores não entendem as necessidades operacionais.
Os desenvolvedores dão muita ênfase ao aspecto técnico.
Os desenvolvedores tentam nos dizer como fazer nosso trabalho.
Os desenvolvedores não conseguem transformar as necessidades em um sistema bem-sucedido.
Os desenvolvedores dizem não o tempo todo.
Os desenvolvedores estão sempre ultrapassando o orçamento.
Os desenvolvedores estão sempre atrasados.
Os desenvolvedores pedem aos usuários que dediquem seu tempo e esforço, mesmo que em detrimento de
suas responsabilidades principais.
Os desenvolvedores definem padrões não-realistas para a definição de requisitos.
Os desenvolvedores são incapazes de responder rapidamente a legítimas necessidades de mudança.

A comunicação, neste contexto, fica bastante comprometida,
uma vez que esta relação social só pode se concretizar se hou­
ver respeito mútuo, que surge da aceitação do outro. De acordo
com Maturana (2001), “sem a aceitação do outro na convivência,
não há fenômeno social”. O usuário não pode ser um problema
para o analista de sistemas: o usuário é a sua razão de ser.
Koscianski (2007) aponta ainda um dos problemas mais co­
nhecidos no processo de software: a negociação de requisitos
entre usuário e analistas. Como a entrevista é, provavelmente,
a técnica mais comum de levantamento de requisitos de siste­
mas, as dificuldades de comunicação durante a especificação
de requisitos devem merecer atenção especial.
A entrevista é composta por questões sobre o sistema for­
muladas pelo analista de sistemas, derivando os requisitos
das respostas dadas pelos usuários a essas questões. Essas
entrevistas podem ser fechadas, respondendo os usuários
a perguntas predefinidas; ou abertas, que não seguem um
roteiro. As entrevistas abertas permitem uma compreensão
maior acerca das necessidades do usuário, uma vez que o
usuário pode discorrer livremente sobre as suas atividades
de trabalho. Mas isso pode tornar o processo mais trabalhoso
para o analista, que necessita de um grande poder de síntese
para organizar essas informações de forma estruturada. Além
disso, conforme Pressman (2006), frequentemente as informa­
ções fornecidas por um usuário se confundem ou entram em
conflito com outras informações fornecidas por outros usuários
envolvidos. Isso exige, em muitos casos, a utilização de técnicas
adicionais nesta fase de levantamento de requisitos.
Sommerville (2007) sugere as técnicas de Cenários e Casos de
Uso. A técnica de Cenários caracteriza-se por uma descrição
de exemplos de interação do mundo real que o sistema deve
atender. A técnica de Casos de Uso baseia-se em cenários e
identifica o tipo de interação e quais agentes (sistema, usu­
ário, etc.) estão envolvidos. Usualmente essas técnicas são
utilizadas em conjunto e podem fazer toda a diferença para
tornar a etapa de levantamento de requisitos mais eficaz. Não
obstante, todas as técnicas resultam de alguma interação com
o usuário. Assim, a comunicação é algo inerente à etapa de
levantamento de requisitos e precisa ser bem resolvida, a fim
de que o produto final de software atenda às necessidades do
usuário no prazo estipulado.
Como o desenvolvimento do software decorre principalmen­
te da etapa de levantamento de requisitos, é importante que
este mapeamento seja bem construído. Dentre as vantagens da
utilização do modelo de desenvolvimento de software baseado
no ciclo de vida clássico cita-se a documentação das etapas,
o que gera maior consistência para as fases subsequentes.
No entanto, Sommerville (2007) aponta a divisão inflexível
de etapas como uma grande desvantagem, tendo em vista a
dificuldade de reagir às mudanças inerentes do projeto. De­
terminadas diferenças de entendimento sobre o que o sistema
deve contemplar podem ser descobertas apenas na etapa final
de teste, o que obriga o retorno às fases iniciais de análise e
levantamento de requisitos para readequações, alerta o autor.
Verdadeiramente, podem ocorrer mudanças antes mesmo de
processo
terminada a fase de levantamento de requisitos, o que pode
comprometer todo o cronograma de um projeto.
Num ambiente em que o desenvolvimento e a pronta entrega
são as principais premissas para um sistema, o ciclo de vida
clássico talvez não seja a metodologia mais adequada, sendo
considerada um tanto burocrática e pesada. Especialmente na
década de 90, com a expansão da tecnologia nas pequenas e
médias empresas, essa situação começou a se tornar inviável,
o que levou alguns desenvolvedores de sistema a estudarem
métodos mais leves e rápidos. Mas foi em 2001 que alguns
desenvolvedores, produtores e consultores de software assina­
ram o “Manifesto para o Desenvolvimento Ágil de Software”.
Este manifesto declarava a descoberta por melhores modos
de desenvolvimento de software, baseados em indivíduos e
suas interações, softwares funcionais, colaboração do cliente
e resposta a modificações.
Desenvolvimento rápido de software, uma possível
solução?
Os métodos ágeis de software enfocam principalmente
a especificação, o projeto e a implementação de software.
São metodologias que envolvem o usuário em praticamente
todas as fases do processo, garantindo assim que possíveis
mudanças nos requisitos possam ser corrigidas em tempo
real. O foco nessas metodologias é a comunicação interativa,
pois não existe uma única etapa em que usuário e analista
interagem, mas várias. Nesse contexto os usuários podem
vir a comunicar-se com toda a equipe de desenvolvimento,
e não apenas com o analista, o que valoriza a cooperação
entre usuários e desenvolvedores em detrimento do forte
planejamento proposto pelo ciclo de vida clássico do processo
de software.
Sommerville (2007) aponta a Extreme Programming como o
método ágil mais conhecido, citando ainda o Scrum, Crystal,
entre outros. Todos esses métodos possuem como característica
comum o desenvolvimento iterativo, propondo, no entanto,
maneiras diferentes para o conseguir. Num desenvolvimento
iterativo, cada iteração é uma etapa do projeto de software.
Assim, com o foco na comunicação entre usuários e analista/
desenvolvedores, o projeto vai sendo validado e incrementado
a cada etapa. É isso que garante que as mudanças no projeto
sejam bem-vindas e que o sistema seja entregue num prazo
mais curto, de acordo com as necessidades do usuário. Um
envolvimento maior entre usuário e analista de sistemas pode
gerar maior compreensão acerca dos requisitos do sistema e
desfazer possíveis erros de interpretação. Além disso, a con­
vivência, por promover o companheirismo e a cooperação,
pode diminuir a distância técnica entre esses profissionais,
quebrando barreiras e preconceitos, resultando num produto
que atende às necessidades do usuário e que proporcione
maiores resultados à empresa.
O que fica evidente, no tocante à comunicação, é que o grande
trunfo dos métodos ágeis se dá pelo envolvimento do usuário
em todo o processo de software, e não apenas numa fase ini­
cial, a exemplo da metodologia do ciclo de vida clássico. No
Edição 24 - Engenharia de Software Magazine 41
entanto, é importante ressaltar que essa interação maior com
o usuário não garante a superação das barreiras de comuni­
cação, podendo até mesmo agravá-las. Falhas e barreiras na
comunicação podem fazer-se presentes em qualquer momento
de interação. Além disso, caso o escopo não tenha sido bem
especificado, corre-se o risco de não ter um sistema pronto
nunca, uma vez que a cada iteração o usuário pode rever os
requisitos e propor mudanças.
Mas não é necessário escolher entre os métodos ágeis e o ciclo
de vida clássico. A agilidade não abstrai disciplina e processo
no desenvolvimento de software. Sendo assim, uma alternativa
é considerar um modelo híbrido de processo de software que
contemple certo planejamento, de acordo com o modelo de
ciclo de vida clássico, aliado à intensificação do envolvimento
do usuário, proposto pelos métodos ágeis.
É importante ainda salientar que a escolha do método a ser
utilizado no processo de software vai depender do tipo de
sistema a ser desenvolvido. Os métodos ágeis são perfeitos
para pequenos sistemas ou pequenas adaptações e integrações
entre diferentes sistemas, no entanto, não se aplicam a siste­
mas complexos e críticos, nos quais são necessárias análises
detalhadas de requisitos e maior planejamento.
Conclusões
Para Pressman (2006), cabe ao analista de sistemas o papel
de facilitador no processo de software, quando elenca algu­
mas capacidades básicas que este deve possuir e que podem
se resumir na habilidade de comunicar-se, de entender e se
fazer entender. Griffin (2006), no entanto, enxerga cada ele­
mento do processo de comunicação como parte fundamental:
se um deles falhar, a mensagem pode não ser transmitida
adequadamente.
Por isso, para viabilizar a comunicação organizacional, é
importante que todas as pessoas envolvidas no processo de
software, desde usuários até analistas e desenvolvedores,
conheçam o processo de comunicação, seu funcionamento e
suas técnicas. Habilidades de ouvir, falar e valorizar a pessoa
com quem se comunica são importantes e devem ser promo­
vidas. Além disso, deve-se procurar evitar os pré-julgamentos
decorrentes de mitos e preconceitos. Eles podem interferir
fortemente nos relacionamentos interpessoais, causando os
indesejáveis ruídos na comunicação.
Outro aspecto do processo de comunicação que deve ser
amplamente encorajado é o feedback, por constituir-se numa
maneira de checar a compreensão das mensagens. Esse talvez
42 Engenharia de Software Magazine - A Comunicação no Processo de Software
seja o maior aliado no processo de software, uma vez que
permite que tanto o usuário quanto o analista de sistemas
saiba se o que disseram um ao outro foi compreendido.
Todas essas premissas não se constituem numa lista de pré-
requisitos básicos para garantir a eficácia da comunicação
num processo de software, mas podem servir como base na
busca da superação das suas barreiras. E para isso não faz
diferença a utilização de métodos ágeis ou a metodologia
de ciclo de vida clássico: aumentar a interação com usuários
pode significar aumentar as barreiras de comunicação, caso
o processo de comunicação entre usuário e analistas de sis­
temas não seja eficaz.
Nesse sentido, é imprescindível que toda e qualquer inte­
ração entre usuário e analista de sistemas prime pela clareza
na comunicação, focada no respeito mútuo e aliada, princi­
palmente, à prática do feedback, independente do modelo de
desenvolvimento de software adotado.
Dê seu feedback sobre esta edição! Feedback
eu
s
Dê
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
sobre e
Para isso, precisamos saber o que você, leitor, acha da revista!
s
ta
edição
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback
Referências Bibliográficas
CHIAVENATO, Idalberto. Gerenciando pessoas: o passo decisivo para a administração
participativa. São Paulo: Makron Books, 1994.
GRIFFIN, Ricky W.; MOORHEAD, Gregory. Fundamentos do comportamento organizacional. São
Paulo: Ática, 2006.
KOSCIANSKI, André; SOARES, Michel dos Santos. Qualidade de software. São Paulo: Novatec, 2007.
MATURANA, Humberto. Emoções e linguagem na educação e na política. Belo Horizonte: UFMG,
2001.
MEGGINSON, Leon C.; MOSLEY, Donald C.; PIETRI Jr., Paul H. Administração: conceito e aplicação.
São Paulo: Harbra, 1998.
PFLEEGER, Shari Lawrence. Engenharia de Software. São Paulo: Prentice Hall, 2004.
PRESSMAN, Roger S. Engenharia de software. São Paulo: McGraw-Hill, 2006.
RETI, Andréa Huggard-Caine. O segredo de cuidar das pessoas: experiências do cotidiano para
gerenciar melhor e aumentar o desempenho das equipes. Rio de janeiro: Elsevier, 2008.
SOMMERVILLE, Ian. Engenharia de software. São Paulo: Pearson Addison-Wesley, 2007.
Planejamento e Gerência
Nesta seção você encontra artigos voltados para o planejamento
e gerência de seus projetos de software
Análise Quantitativa de Riscos e suas Técnicas
Marcio Souza
mms3@cin.ufpe.br
Líder de Equipes de desenvolvimento de software
no Centro de Estudos e Sistemas Avançados do Re-
cife (C.E.S.A.R). Mestre em Ciência da Computação
pela Universidade Federal de Pernambuco e Gra-
duado em Informática pela Universidade Católica
do Salvador. É membro dos grupos de pesquisa na
área de gerenciamento de projetos e engenharia
de software, GP2 Project Management Research
Group e PROMISE (Project Management Improve-
ments in Software Engineering).
Cristine Gusmão
cristine.gusmao@nutes.ufpe.br
Graduada em Engenharia Elétrica (1993), mestrado
(2001) e doutorado (2007) em Ciência da Compu-
tação pela Universidade Federal de Pernambuco.
Professora adjunta da Universidade Federal de Per-
nambuco, com atividades na graduação e pós-gra-
duação, lotada no Núcleo de Telessaúde, pesquisa-
dora colaboradora do Grupo GP2 do Centro de Infor-
mática (CIn - UFPE), coordenadora e pesquisadora
do PROMISE (Project Management Improvements
in Software Engineering) e colaboradora do Progra-
ma de Mestrado em Engenharia de Computação da
Escola Politécnica de Pernambuco - Universidade de
Pernambuco (POLI - UPE). É membro da SBC. Tem
experiência na área de Ciência da Computação,
com ênfase em Engenharia de Software, atuando
principalmente nos seguintes temas: Gerência de
Riscos de Projetos, Qualidade de Software, Gerência
de Projetos, Gestão de Sistemas de Saúde, e-Health
e Consultoria em Processos de Negócio.
Hermano Perrelli
hermano@cin.ufpe.br
Atualmente é professor Adjunto e Vice-Diretor
do Centro de Informática da Universidade Fe-
deral de Pernambuco. Consultor e instrutor da
Qualiti Software Processes. Certificado PMP
(Project Management Professional) pelo PMI.
PhD In Computing Science pela University of
Glasgow, Mestre em Informática pela Univer-
sidade Federal de Pernambuco e graduado
em Engenharia Eletrônica pela Universidade
Federal de Pernambuco.
A
Análise Quantitativa de Riscos
(AQR) é um campo relativa­
mente novo, o qual tem cres­
cido rapidamente em diversas áreas do
conhecimento [Vose 2002]. Uma dessas
áreas tem sido o gerenciamento de
projetos, cujas diversas abordagens dis­
poníveis consideram a análise de riscos
como um dos seus principais processos
no contexto da gerência de riscos de um
projeto [Matias Júnior 2006].
A discussão sobre a análise quanti­
tativa de riscos presume que etapas
anteriores, tais como planejamento e
identificação de riscos, tenham sido
cumpridas. Desta forma, é melhor
Edição 24 - Engenharia de Software Magazine
De que se trata o artigo?
Este artigo traz o aprofundamento na Gerência
de Riscos, detalhando a Análise Quantitativa de
Riscos e suas principais técnicas, de acordo com a
recomendação do Guia PMBOK, e mostra o resul-
tado de um estudo comparativo destas técnicas.
Para que serve?
Analisar as decisões chaves na presença de incer-
tezas; alertar, principalmente, os envolvidos de
um projeto sobre riscos importantes antes de suas
ocorrências; e, traduzir os riscos em números.
Em que situação o tema é útil?
Auxiliar os envolvidos em um projeto, mais
especificamente, o gestor de projetos, no
processo de tomada de decisão.
conduzi-la após a avaliação dos riscos,
incluindo a priorização dos mesmos, e
garantir que todos os principais riscos
poderão ser considerados.
Segundo David Hulett [Hulett 2004], a
análise quantitativa de riscos é sempre
recomendada para projetos grandes,
complexos ou visíveis, podendo ser
43
adaptada para projetos menores sempre que necessário. Desta
forma, ela é tipicamente executada para examinar a viabilidade
de custos e de prazo de um projeto, ou seja, analisar as decisões
chaves na presença de incertezas.
Neste cenário, a AQR provê respostas a três questões que não
podem ser respondidas através de metodologias de gerencia­
mento de projetos determinísticas, tais como estimativa de
custo tradicional ou planejamento de projeto:
• Qual a probabilidade de alcançar o objetivo do projeto, dados
todos os riscos conhecidos e quantificados?
• De quanto pode ser o atraso e quão necessária é a contingên­
cia para o nível de certeza desejado pela organização?
• Onde está o maior risco, considerando o modelo do projeto e
a totalidade de todos os riscos identificados e quantificados?
A análise qualitativa de riscos, uma das principais partes
da avaliação de riscos, responde à última pergunta, mas não
pode estimar o total de risco do projeto, haja vista que cada
risco é examinado por vez [Hullet 2004]. Então, a contribuição
da Análise Quantitativa de Riscos é avaliar, simultaneamente,
todos os riscos do projeto em relação ao seu custo total, ou a
sua data final, bem como aos seus principais marcos.
A AQR tem como objetivo global alertar ao gerente, cliente
ou patrocinador do projeto a respeito de dois pontos princi­
pais: (1) se os objetivos gerais do projeto estão suficientemente
em perigo para justificar o tratamento dos riscos, e (2) sobre
riscos importantes antes das suas ocorrências, o que lhes per­
mite desenvolver ações de mitigação de risco ou captura de
oportunidades para tornar o projeto melhor. Uma dificuldade
na concretização deste objetivo ocorre porque, no início do
projeto, quando se pode tirar vantagem do tratamento dos
riscos, os dados sobre o risco e, em particular, os modelos
necessários para a análise quantitativa dos riscos não estão
disponíveis. Quando as estimativas de custos e prazos estão
mais amadurecidas, e os dados mais conhecidos, a flexibili­
dade e o poder de afetar o projeto com alternativas tornam-se
restritos, pois mais decisões têm de ser tomadas. Em algum
ponto, durante a execução do projeto, o objetivo principal da
análise quantitativa dos riscos é fornecer estimativas precisas
de onde o projeto resultará.
Ainda de acordo com David Hulett [Hulett 2004], as principais
entradas para a AQR são as distribuições de probabilidade dos
custos ou das durações da atividade (prazo). As distribuições
da probabilidade são usualmente distribuições contínuas de
valores possíveis do elemento custo ou do prazo, desenvolvida
através de entrevistas intensivas e análise de desempenhos
passados. A entrada típica é resultado do uso da estimativa
de 3-pontos, no qual o custo ou a duração é representado pelo
valor mais otimista (mais baixo, melhor), o valor mais prová­
vel para este projeto, e o valor pessimista (mais alto, pior). As
distribuições mais comumente usadas são a: triangular, beta,
uniforme, normal ou outros tipos de distribuições.
O método mais frequentemente usado na Análise Quanti­
tativa de Riscos é a simulação de Monte Carlo do modelo de
custo ou prazo [Hulett 2004; Matias Júnior 2006]. A simulação
44 Engenharia de Software Magazine - Análise Quantitativa de Riscos e suas Técnicas
de Monte Carlo é um método antigo, com mais de cinquenta
(50) anos, que combina as distribuições baseadas nos relacio­
namentos dos modelos, armazenando os resultados para serem
mostrados posteriormente. As saídas são sempre mostradas
graficamente, porém outras formas incluem listas de elemen­
tos de custos, que contêm o maior risco (maior contribuição
para a contingência em relação ao custo total), ou atividades
de tempo (atividades nos caminhos críticos, considerando o
maior número de iterações durante a simulação).
Adicionalmente, a AQR inclui a Análise por Árvore de
Decisão, a qual melhora a capacidade da organização de to­
mar a decisão correta quando as implicações das diferentes
decisões não podem ser preditas com certeza. A análise por
árvore de decisão envolve: especificação de todos os fatores
e as implicações de uma decisão, os custos e benefícios de to­
mar determinada decisão e as probabilidades associadas com
cenários incertos ou resultados que tenham um impacto na
decisão e os seus resultados. A análise por árvore de decisão,
então, computa o valor monetário esperado (custo ou lucro)
ou a utilidade esperada para a organização das alternativas
disponíveis. A parte interessada utiliza os resultados para
tomar decisões quando a incerteza está presente.
A Análise Quantitativa de Riscos, através de suas técnicas,
avalia numericamente o efeito dos riscos identificados nos
objetivos gerais do projeto [PMI 2004]. Então, na próxima
seção serão discutidas as principais técnicas utilizadas no
tratamento dos riscos.
As Técnicas
As técnicas quantitativas de análise de riscos traduzem, ma­
tematicamente ou computacionalmente, o risco em números.
Essas técnicas sempre provêem probabilidades numéricas ou
as consequências e o comportamento dos riscos identificados.
Os valores utilizados nessas técnicas são obtidos de bases de
dados históricas ou são estimativas de esforço. No último
caso, contêm um nível de incerteza devido ao possível uso
de subjetividade relacionado aos valores [Baker et al. 1998;
Padayachee 2001].
Nesse cenário, as técnicas mais comumente empregadas para
a AQR e destacadas na literatura são: Entrevistas, Análise de
Sensibilidade, Análise do Valor Monetário Esperado, Análise
da Árvore de Decisão e Simulação de Monte Carlo [Hulett 2004;
PMI 2004; Almeida e Ferreira 2008].
Entrevistas
As entrevistas são realizadas, conforme Newton Nóbrega
[Nóbrega 2007], de maneira análoga àquelas que compõem
os métodos de identificação de riscos, tendo como principal
diferença a recomendação de se buscar, na fase de identifica­
ção, dados qualitativos e quantitativos para os riscos. Já na
quantificação dos riscos, as entrevistas são realizadas com o
objetivo de se quantificar a probabilidade e as conseqüências
dos riscos sobre os resultados do projeto.
O Project Management Institute [PMI 2004] destaca que a
informação necessária vai depender do tipo de distribuição

de probabilidades que é usado. Se for utilizada a distribuição
uniforme, devem ser colhidas informações sobre o valor má­
ximo e mínimo para uma consequência de um evento de risco,
tal como citado anteriormente. No caso de uma distribuição
triangular, seriam necessárias informações sobre o cenário
otimista, pessimista e aquele mais provável. As distribuições
representam as probabilidades e as consequências do compo­
nente do projeto.
Por fim, a documentação do raciocínio (da análise lógica) por
detrás das extensões dos riscos é um componente importante
da entrevista sobre riscos, uma vez que pode gerar estratégias
eficazes de respostas aos riscos.
Análise de Sensibilidade
A Análise de Sensibilidade é uma técnica utilizada para
tomada de decisão que avalia a mudança de uma variável
dentro do projeto, analisando o resultado dessa variação sobre
o seu planejamento inicial, e é de grande importância para a
análise de novos cenários [Silva e Belderrain 2004; Almeida e
Ferreira 2008].
Esta técnica ajuda a determinar quais riscos apresentam
maior impacto potencial no projeto, examinando a extensão
com que a incerteza de cada elemento do projeto afeta o
objetivo que está sendo examinado quando todos os outros
elementos incertos são mantidos em seus valores de linha
de base, impactando em prazos e custos [PMI 2004; Almeida
e Ferreira 2008]. Desta forma, a aplicabilidade da análise de
sensibilidade é caracterizada tanto na gestão de prazos quanto
no retorno sobre o investimento.
De uma maneira geral, utiliza-se a análise de sensibilidade
para tomar melhores decisões, decidir quais dados estimados
devem ser refinados antes de iniciar o processo de tomada
de decisão e concentrar-se nos elementos críticos durante a
sua implantação. Por outro lado, o principal obstáculo é a não
indicação da possível ocorrência de variação dos parâmetros
escolhidos na modificação da variável em análise, bem como
considerar cada variável como sendo independente.
Análise do Valor Monetário Esperado
O Valor Monetário Esperado (VME) é uma prática de gerên­
cia de riscos utilizada para ajudar a quantificar e comparar
os riscos em vários aspectos de um projeto. Tal como outras
técnicas de análise quantitativa de riscos, o VME se baseia
em números específicos e quantificáveis para a realização de
cálculos ao invés de aproximações e subjetivações, tais como:
alto, médio e baixo.
Nessa linha, o VME é fundamentado em três números
básicos. São eles: probabilidade do risco ocorrer (Pr), pro­
babilidade do risco impactar o projeto se o mesmo ocorrer
(PI) e impacto no projeto se o risco ocorrer (I). Em relação
à variável PI, normalmente a maioria dos projetos não
utilizam este componente de cálculo, pois se supõe que os
riscos identificados terão a probabilidade de 100%, ou um
valor bem perto de impactar o projeto. Quanto ao elemento
impacto (I), o mesmo pode ser reclassificado, em maiores
Planejamento
detalhes, da seguinte maneira: impacto em relação ao cus­
to (Ic), impacto em relação ao empenho (Ie) e impacto em
relação ao cronograma (Icr).
Usando esta técnica para todos os riscos, ter-se-á uma análise
para apresentar aos stakeholders do projeto e, consequentemen­
te, poderá ser requerida uma reserva de contingência para
cobrir o impacto dos riscos, caso algum destes aconteça. John
Grass [Grass 2007] exemplifica essa situação (vide Tabela 1),
conforme explanado posteriormente.
Probabilidade de Impacto em termos de Reserva de Contingência
Risco
Ocorrência (Pr) custo (Ic) para o Risco
A 80% R$ 10.000,00 R$ 8.000,00
B 30% R$ 30.000,00 R$ 9.000,00
C 50% R$ 8.000,00 R$ 4.000,00
D 10% R$ 40.000,00 R$ 4.000,00
E 30% R$ 20.000,00 R$ 6.000,00
F 25% R$ 10.000,00 R$ 2.500,00
Total R$ 118.000,00 R$ 33.500,00
Tabela 1. Representação da técnica VME [Grass 2007]
Supondo a identificação de seis riscos no projeto, o impacto
potencial é de cento e dezoito mil reais (R$ 118.000,00). Entre­
tanto, não se pode solicitar toda essa quantia como reserva
de contingência, pois este nível de reserva seria considerado
para o caso de todos os riscos ocorrerem. Por isso, a reserva de
contingência é respeitada avaliando o potencial do impacto dos
riscos no projeto e a probabilidade dos mesmos acontecerem,
sendo evidenciada na última coluna da Tabela 1.
Percebe-se que a solicitação total da reserva de contingência é
de trinta e três mil e quinhentos reais (R$ 33.500,00), podendo
ser adicionada ao orçamento do projeto como uma poupança
referente aos riscos. Se o risco “C” e o “F” ocorrerem, parte
dessa reserva poderá ser usada para cobrir o impacto. Porém, a
ocorrência do risco “D” impactará na reserva de contingência,
podendo não ser o suficiente para proteger o projeto e cobrir
o impacto. Mesmo o risco “D” tendo apenas 10% de chance de
incidência, a equipe do projeto tem a obrigação de focar nesse
risco para assegurar que o mesmo seja gerenciado com sucesso,
ou seja, a equipe deve procurar minimizar o impacto através
de um gerenciamento pró-ativo do risco.
No caso do gerenciamento de projetos médios e grandes, faz
sentido incluir algum tempo e orçamento para riscos desco­
nhecidos. De acordo com John Grass [Grass 2007], existe uma
comprovação na indústria de que uma reserva de contingência
de 5% pode ser adicionada ao projeto para tratar dos riscos que
são desconhecidos no início do projeto.
Análise da Árvore de Decisão
A Árvore de Decisão consiste na determinação e visualização
gráfica de caminhos que poderão ser seguidos em um pro­
cesso de tomada de decisão [Pedro e Guerreiro 2004; Almeida
e Ferreira 2008]. Essa técnica é estudada em vários campos
de pesquisa como ciências sociais, estatística, engenharia e
Edição 24 - Engenharia de Software Magazine 45
inteligência artificial, e aplicada desde o diagnóstico de casos
médicos até avaliação de riscos na área financeira.
Segundo Raphael D’Castro [D’Castro 2009], como técnica
de computação inteligente e apresentando resultados extra­
ordinários na tarefa de classificação, a análise da árvore de
decisão é um candidato natural para auxiliar nos obstáculos
encontrados na gerência de riscos.
Na sua forma estrutural, Cliff Ragsdale diz que a árvore de
decisão compõe-se de nós (concebidos por círculos e quadrados
representando, respectivamente, eventos aleatórios e decisões)
interconectados por ramos (representados por linhas), sendo
que os ramos originados do nó de decisão mostram as diferen­
tes alternativas para uma decisão particular [Ragsdale 2001],
conforme ilustrado na Figura 1.
Figura 1. Exemplificação de uma árvore de decisão [Ragsdale 2001]
De uma maneira geral, os ramos da árvore correspondem a
cada possibilidade lógica que leva à próxima possibilidade ou
ação a ser tomada. Nem sempre a combinação das condições
descritas leva a uma ação definitiva. Quando isto ocorre, o
decisor tem o papel de optar pela melhor ação a ser tomada.
As folhas, situadas no final dos ramos, exibem os caminhos
aos quais uma decisão pode levar. Essas folhas terminais são
representadas, normalmente, por traços verticais, indicando
ponto final, ou por triângulos.
Neste panorama, David Hillson afirma que a análise da árvore
de decisão baseia-se em quatro elementos fundamentais: esco­
lha, probabilidade, custos e consequências [Hillson 2005]:
• Escolha: primeiro passo na construção da árvore de deci­
são. Identifica as opções a serem escolhidas para alcançar os
objetivos, sendo que essas escolhas definem os nós de decisão
da árvore.
• Probabilidade: na existência de incerteza, deve-se identificar
e avaliar a probabilidade estimada de cada resultado, por ser
uma importante variável associada com os diversos caminhos
de decisões diferentes.
• Custos: fator mais simples associado às escolhas alternativas. Ao
se fazer uma escolha, sempre existe um custo relacionado e uma
estimativa deve ser incluída em cada nó da árvore de decisão.
• Consequências: resultado da implementação de uma decisão,
considerando seus custos e riscos. Desta forma, a estrutura da
árvore de decisão apresenta o resultado presumido de cada
46 Engenharia de Software Magazine - Análise Quantitativa de Riscos e suas Técnicas
combinação escolha/probabilidade, representando os níveis
ao extremo de cada nó.
Na construção de uma árvore de decisão, considerando os
principais elementos defendidos por David Hillson, é plausível
fazer uma avaliação para determinar a escolha mais adequada,
ponderando custos, probabilidades e consequências associa­
dos, baseando-se na seguinte lógica: caminha-se pela árvore de
decisão, analisando cada percurso lógico alternativo; calcula-
se seu valor acumulando custos e benefícios do início ao fim;
utiliza-se este conjunto de valores e verifica-se o retorno de
cada caminho lógico alternativo, obtendo o valor esperado de
cada escolha (sempre ponderando as consequências quando as
probabilidades ocorrerem); por fim, o nó possuidor do valor
esperado mais alto, será a opção de decisão recomendada.
A existência de alguns obstáculos na utilização das árvores
de decisão merece ser citada. São eles: limitação prática da
técnica (análise de um baixo número de opções de decisão e
riscos possíveis); amplo modelo sem grande utilidade (tentativa
de demonstrar em uma única árvore, um projeto que envolve
muitas decisões em distintos níveis, associados a uma infini­
dade de riscos); e, necessidade de imparcialidade da pessoa
responsável por tomar a decisão fundamentada no valor espe­
rado mais alto [Gama 2002; Hillson 2005; D’Castro 2009].
Apesar das limitações citadas anteriormente, as principais
vantagens da técnica de árvore de decisão são a simplicidade,
facilidade de interpretação, flexibilidade e ser um método
não-paramétrico (não assume nenhuma distribuição parti­
cular para os dados e pode construir modelos para qualquer
função, desde que o número de exemplos de treino seja sufi­
ciente) [Gama 2002; Clarke e Bittencourt 2003; Hillson 2005;
Almeida e Ferreira 2008].
Simulação de Monte Carlo
O método de Monte Carlo é uma das técnicas do processo
de Análise Quantitativa de Riscos, sendo recomendado para a
análise de riscos de cronograma e de custos [Galvão 2005]. Seu
algoritmo é um processo de simulação que é repetido várias
vezes, sendo gerados, em cada iteração, possíveis valores para
as durações das atividades [Lima et al. 2008]. Desta forma, a
rede do projeto é montada baseada nesses valores, obtendo
uma aceitável data final do projeto.
Adiciona-se a isto que, na análise de cronograma é utilizado
o Método de Diagrama de Precedência (PDM) e, na análise de
custos, emprega-se a Estrutura Analítica de Trabalho (EAP)
[Nóbrega 2007]. A EAP é uma maneira de decompor o projeto
em componentes facilmente gerenciáveis. Desta forma, o proje­
to acaba transformado em grupos principais de trabalho, onde
esses são reduzidos a tarefas, subtarefas, e assim sucessivamen­
te, até que se chegue num nível de granularidade necessária e
entendível para finalizar um projeto específico.
O nome Monte Carlo surgiu no decorrer do projeto Manhat­
tan, na Segunda Guerra Mundial, devido ao fato da cidade
de Monte Carlo, capital de Mônaco, local de famosos cassi­
nos, ser uma importante referência em jogos de azar e cujo
 Planejamento

funcionamento possuir certa similaridade com o processo Conclusão

de simulação estatística [Gujarati 2002; Galvão 2005; Matias
Júnior 2006].
O método de Monte Carlo é um procedimento indutivo que
permite tomada de decisões de forma mais consistente, ou seja,
as respostas obtidas da sua aplicação não são binárias, mas sim
estabelecidas em termos probabilísticos [Smith 1973]. Então, essa
técnica admite determinar uma gama de cenários possíveis para
a conclusão do projeto, expondo, desta forma, a probabilidade
de ocorrência de cada cenário.
Para a determinação destes cenários e considerando a inci­
dência de riscos, utilizam-se distribuições de probabilidades
ao invés do uso de estimativas únicas, sendo as distribuições a
base para o processo de simulação.
Uma distribuição de probabilidades é representada matemati­
camente por uma função f, chamada função densidade de pro­
babilidade, cujo gráfico mostra as possibilidades de ocorrência
dos resultados possíveis de um evento.
Existem diversos tipos de distribuições de probabilidades que
são oferecidas por software especializado para análise de riscos
e que podem ser utilizadas para representar as incertezas nos
valores das durações das atividades ou outros parâmetros do
projeto. São elas as distribuições Beta, Binomial, Exponencial,
Gamma, Lognormal, Normal, PERT, Poisson, Student, Trian­
gular e Uniforme.
Vale destacar que, por não existir, normalmente, uma base real
para a escolha das distribuições, elas são selecionadas arbitra­
riamente [Conrow 1998]. Porém, motivos históricos e entrevistas
com especialistas podem ser artifícios para determinar a distri­
buição de probabilidade específica para o projeto.
Análise Comparativa das Técnicas
Na Tabela 2 são tratadas as vantagens e desvantagens das
principais técnicas de análise quantitativa de riscos mostradas
na seção anterior de forma sintética.
Todas as técnicas estudadas pregam o auxílio em processos
de tomada de decisão, oferecendo resultados numéricos mais
reais sobre os resultados do projeto. Acrescente-se a isso o fato
de elas serem aplicadas, principalmente, na gestão de prazos
(cronograma) ou na de custos, ou em ambas.
A Entrevista, mesmo no contexto da análise quantita­
tiva, é uma técnica bastante subjetiva, pois se baseia, na
maioria das vezes, nas experiências vivenciadas pelos
entrevistados. Em alguns poucos casos, os entrevista­
dos fundamentam suas opiniões em dados históricos
de projetos, quando guardados. Como ponto relevante
desse processo, é a possibilidade de determinar, quan­
titativamente, a probabilidade e as consequências dos
riscos sobre os resultados do projeto através de diferentes
pontos de vistas.
A técnica de Análise de Sensibilidade, mesmo aplicada
em uma variedade de contextos [Aggarwal et al. 2005;
Do e Rothermel 2008; Harman et al. 2009], ainda precisa
de uma pesquisa mais minuciosa na gestão de prazos
[Almeida e Ferreira 2008]. De qualquer sorte, a análise
de sensibilidade avalia, independentemente, a mudança
de uma variável, comparando-a com o seu planejamento
inicial, haja vista que as variáveis são isoladas. Desta
forma, permite decidir quais dados precisam de refina­
mento antes de iniciar o processo de tomada de decisão,
concentrando-se nos elementos críticos durante a sua
implantação.
Já a análise do Valor Monetário Esperado consegue
estabelecer uma reserva de contingência para cobrir o
impacto dos riscos que possam ocorrer, pois considera
todos os possíveis resultados, evitando assim, a simples
combinação de todos os melhores e piores casos. A limi­
tação da técnica é que a mesma proporciona melhores
resultados quando utilizada ao longo de muitos projetos
de porte semelhante, com um número de riscos conside­
rável [Loosemore et al. 2006]. Ou seja, quanto mais riscos
forem identificados, maior será a distribuição da reserva
de contingência entre os riscos envolvidos.
Entre as técnicas de análise quantitativa de riscos, a
análise da Árvore de Decisão apresenta diversas vanta­
gens, conforme mostrado na Tabela 2. A simplicidade,
facilidade de interpretação e a visualização gráfica das
alternativas a serem seguidas, capacitam os envolvi­
dos no processo de tomada de decisão, a entender o

Técnica Vantagem Desvantagem

Entrevistas Têm diversas visões de profissionais com experiências distintas. Dependência da informação obtida com o entrevistado.
Análise de Sensibilidade Avalia, independentemente, a mudança de uma variável, comparando-a com o seu planejamento inicial. Não indicação da variação de parâmetros que se relacionam com
uma determinada variável analisada e ausência de estudo mais
detalhado da aplicação da técnica junto à gestão de prazos.
Análise do VME Consegue estabelecer uma reserva de contingência para cobrir o impacto dos riscos, caso ocorram. Apresenta melhores resultados quando utilizada com muitos
projetos de porte semelhante e com um número de riscos
suficientes [Loosermore et al. 2006].
Análise da Árvore de Decisão Visualização gráfica dos caminhos a serem seguidos, simplicidade, facilidade de interpretação, flexibilidade, Dificuldade na apresentação dos resultados quando se tem um
método não-paramétrico, utilização numa gama de áreas de pesquisa e combinação com outras técnicas cenário de possibilidades muito pequeno ou muito amplo.
de tomada de decisão.
Simulação de Monte Carlo Processo de simulação repetido inúmeras vezes durante uma iteração, obtenção de respostas não binárias e Aleatoriedade na escolha das distribuições de probabilidade e
possibilidade de estudar as consequências da tomada de decisão sem executar o projeto [Nóbrega 2007]. demanda de tempo para sua aplicação.
Tabela 2. Vantagens e Desvantagens das principais técnicas da AQR

Edição 24 - Engenharia de Software Magazine 47

procedimento após uma breve explanação. Também, não
assume nenhuma distribuição especial e é capaz de esta­
belecer modelos para qualquer finalidade, desde que tenha
informação necessária de treino. Como obstáculo, oferece
dificuldades na apresentação dos resultados quando as
possibilidades são extremas, em termos de quantidade.
Por último, a Simulação de Monte Carlo, prática comum
e difundida no Project Management Body of Knowledge [PMI
2004], quando se usa simulação. Esta técnica gera cenários
presumíveis, sem que exista a necessidade de executar o
projeto. Como barreira, demanda tempo, pois precisa ser
Referências
[Aggarwal et al. 2005] Aggarwal, K. K., Singh, Y., Chandra, P. e Puri, M. (2005) “Sensitivity analysis of
fuzzy and neural network models”, SIGSOFT Softw. Eng. Notes, ACM, 30, 1-4.
[Almeida e Ferreira 2008] Almeida, E. P. e Ferreira, M. L. R. (2008) “Técnicas de Análise de Risco
Aplicadas à Planejamento e Programação de Projetos da Construção Civil”, IV Congresso Nacional
de Excelência em Gestão: Responsabilidade Socioambiental das Organizações Brasileiras, Niterói,
RJ, Brasil, 31 de julho, 01 e 02 de Agosto.
[Baker et al. 1998] Baker, S., Ponniah, D. e Smith, S. (1998) “Techniques for analysis of risks in major
projects”, Journal of the Operations Research Society, 49, pp567-572.
[Clarke e Bittencourt 2003] Clarke, Robin T. e Bittencourt, Hélio R. (2003) “Uso de Árvores de Decisão na
Classificação de Imagens Digitais”,XI SBSR, Belo Horizonte, Brasil, 05-10 de Abril, INPE, p. 2043 - 2045.
[Conrow 1998] Conrow, Edmund H.(1998)“Some Limitations of Quantitative Risk Analysis Approaches
Used in Project Management”,Invited paper by the Office of the Secretary of Defense, April.
[D’Castro 2009] D’Castro, Raphael J. (2009) “Avaliação de Riscos em Projetos de Software a partir do
Uso de Técnicas de Inteligência Computacional”,Trabalho de Conclusão de Curso, Departamento de
Sistemas e Computação, Engenharia da Computação, Universidade de Pernambuco, Junho.
[Do e Rothermel 2008] Do, H. e Rothermel, G. (2008) “Using sensitivity analysis to create simplified
economic models for regression testing”, ISSTA ‘08: Proceedings of the 2008 international
symposium on Software testing and analysis, ACM, 2008, 51-62.
[Galvão 2005] Galvão, Márcio (2005) “Análise Quantitativa de Riscos com Simulação de Monte
Carlo”, Revista Mundo PM, Project Management, Número 05, Out./Nov., Ano 1.
[Gama 2002] Gama, João (2002) “Árvores de Decisão”, Laboratory of Artificial Intelligence and
Decision Support, University of Porto, Portugal, Disponível em: http://www.liaad.up.pt/~jgama/
Aulas_ECD/arv.pdf, Acesso em: 9 ago. 2009.
[Grass 2007] Grass, John (2007)“Valor Monetário Esperado (VME)”,The ICPM – Project Management
Community, Disponível em: http://www.theicpm.com/index.php?option=com_content&view=art
icle&id=2772:valor-monetario-esperado-vme&catid=82, Acesso em: 08 ago. 2009.
[Gujarati 2002] Gujarati, D. N. (2002) “Econometria básica”, 3ª edição, Makron Books, São Paulo.
[Harman et al. 2009] Harman, M., Krinke, J., Ren, J. e Yoo, S. (2009) “Search based data sensitivity
analysis applied to requirement engineering”, GECCO ‘09: Proceedings of the 11th Annual
conference on Genetic and evolutionary computation, ACM, 1681-1688.
[Hillson 2005] Hillson, David (2005)“Using Decision Trees”,Risk Doctor Briefing,The Risk Doctor, Disponível
em: http://www.risk-doctor.com/pdf-briefings/risk-doctor18e.pdf, Acesso em: 10 abr. 2009.
48 Engenharia de Software Magazine - Análise Quantitativa de Riscos e suas Técnicas
executada mais de uma vez. Ademais, não existe uma lógica
ou regra para a determinação das distribuições utilizadas,
consistindo estas em escolhas aleatórias do responsável pela
execução e análise do método.
Dê seu feedback sobre esta edição! Feedback
eu
s
Dê
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
sobre e
Para isso, precisamos saber o que você, leitor, acha da revista!
s
ta
Dê seu voto sobre este artigo, através do link: edição
www.devmedia.com.br/esmag/feedback
[Hullet 2004] Hulett, David (2004) “Quantitative Risk Analysis Fundamentals”, Defense Acquisition
University, Disponível em: https://acc.dau.mil/CommunityBrowser.aspx?id=19270, Acesso em: 25
abr. 2009.
[Lima et al. 2008] Lima, E. C. P., Viana, J. C., Levino, N. A. e Mota, C. M. M. (2008) “Simulação de
Monte Carlo Auxiliando a Análise de Viabilidade Econômica de Projetos”, IV Congresso Nacional de
Excelência em Gestão: Responsabilidade Socioambiental das Organizações Brasileiras, Niterói, RJ,
Brasil, 31 de julho, 01 e 02 de Agosto.
[Loosermore et al. 2006] Loosemore, Martin, Raftery, John, Reilly, Charlie e Higgon, Dave (2006)
“Risk Management in Projects”, 2nd Edition, Taylor & Francis, New York, USA.
[Matias Júnior 2006] Matias Júnior, R. (2006) “Análise Quantitativa de Risco Baseada no Método
de Monte Carlo: Abordagem PMBOK”, Congresso Brasileiro de Gerenciamento de Projetos, 29 a 31
de Março, Florianópolis.
[Nóbrega 2007] Nóbrega, Newton C. M. (2007) “Um Estudo Teórico da Avaliação de Riscos em
Projetos de Investimento em Organizações”, Monografia para a graduação em Engenharia de
Produção, Universidade Federal de Juiz de Fora, Novembro.
[Padayachee 2001] Padayachee, Keshnee (2001) “Techniques Used in Risk Analysis of Software
Development”, University of South Africa.
[Pedro e Guerreiro 2004] Pedro, Lucilene M. e Guerreiro, Reinaldo (2004)“Aplicação de Árvores de Decisão
na Análise Financeira”,In: 4º Congresso USP de Controladoria e Contabilidade, São Paulo, v.1, p.0-0.
[PMI 2004] PMI, Project Management Institute. (2004) “A Guide to the Project Management Body
of Knowledge”, ANSI/PMI 99-01-2004, Four Campus Boulevard, Newtown Square, USA.
[Ragsdale 2001] Ragsdale, Cliff T. (2001) “Spreadsheet modeling and decision analysis: a practical
introduction to management science”, 3rd, Cincinnati, Ohio, South-Western College Pub.
[Silva e Belderrain 2004] Silva, Roterdan M. e Belderrain, Mischel C. N. (2004) “Considerações sobre
Análise de Sensibilidade em Análise de Decisão”, Instituto Tecnológico de Aeronáutica, Divisão de
Engenharia Mecânica-Aeronáutica, Relatório de Iniciação Científica, 44p, CNPq.
[Smith 1973] Smith, Kerry (1973) “Monte Carlo Methods,Their Role for Econometrics”,Lexinton Books.
[Vose 2002] Vose, David (2002) “Risk Analysis: a quantitative guide”, 2nd Edition, UK, John Wiley
& Sons, 418 p.
Desenvolvimento
Nesta seção você encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software
Automatizando Testes Funcionais em
Aplicações Web
Utilizando a Ferramenta Selenium para execução de Testes Funcionais
Arilo Cláudio Dias Neto
ariloclaudio@gmail.com
É Doutor em Engenharia de Sistemas e Com-
putação formado na COPPE/UFRJ e possui
o certificado de Implementador do modelo
MPS. Possui 7 anos de experiência em análise,
desenvolvimento e teste de software. É editor
técnico da Revista SQL Magazine, gerenciada
pelo Grupo DevMedia.
N
os artigos anteriores escri­
tos para a ES Magazine, nos
preocupamos em discutir os
conceitos básicos sobre Teste de Sof­
tware e apresentar uma estratégia que
possibilita a geração de casos de teste
de software a partir de casos de uso já
especificados. Tal estratégia seria apli­
cada no nível de teste de software, re­
presentando um tipo de técnica de teste
Edição 24 - Engenharia de Software Magazine
De que se trata o artigo?
Neste artigo iremos apresentar a implementação
de uma estratégia de teste funcional utilizando
uma ferramenta, Selenium IDE, para automação da
execução e re-execução dos testes.
Para que serve?
O artigo demonstra na prática a ferramenta Sele-
nium IDE para automação de teste funcional usan-
do uma estratégia de teste do tipo capture-replay,
contextualizada ao domínio de aplicações web.
Em que situação o tema é útil?
O tema é útil para os desenvolvedores e en-
genheiros de software que planejam aplicar
a automação de testes no desenvolvimento de
aplicações web.
funcional, onde o sistema é tratado em
uma visão macroscópica e sua avaliação
é feita sem considerar detalhes internos
de implementação.
No entanto, apesar de ser totalmente
viável, a aplicação desta estratégia de
teste quando realizada manualmente
representa um grande esforço para um
projeto de software. Com isso, pensar em
mecanismos para automação dos testes
49
consiste em pensar em mecanismo para reduzir o esforço desta
atividade no contexto geral de um projeto de software.
É importante termos em mente que automação por si só
não resulta em redução de esforço nos testes ou aumento da
qualidade desta atividade. A automação simplesmente torna
automática algumas tarefas do processo de testes, mas ela não
faz milagres. Como assim? Uma ferramenta de testes apenas
automatiza o nosso conhecimento técnico sobre teste de sof­
tware. Sendo assim, se não tivermos conhecimento técnico
adequado sobre teste de software, o conjunto de casos de
teste gerado para avaliar nosso sistema não terá cobertura ou
qualidade suficiente, de forma que a ferramenta irá apenas
automatizar a execução do conjunto de testes inadequados,
ou seja, não termos qualquer ganho com isso.
Se tivermos um processo de teste bem definido e um bom co­
nhecimento sobre estratégias de teste, a automação pode trazer
grandes benefícios a um projeto de software. Nesse contexto,
neste artigo iremos apresentar a implementação de uma estra­
tégia de teste funcional apresentada no artigo “Planejamento
de Testes a partir de Casos de Uso” publicado na edição 6 da
ES Magazine utilizando uma ferramenta, Selenium IDE, para
automação da execução e re-execução dos testes.
Estratégias de Teste de Software
Durante o desenvolvimento de um software, diversas
estratégias para teste podem ser aplicadas. De acordo com
PRESSMAN (2005), essas estratégias podem ser categorizadas
da seguinte forma:
• Baseadas em implementação: utiliza o código como elemento
para a geração dos testes. É uma atividade cara, sob o ponto de
vista de recursos necessários para a sua realização, e bastante
complexa quando o tamanho do código se torna bastante gran­
de. É totalmente dependente de apoio ferramental;
• Baseadas em especificação: utiliza um documento de espe­
cificação como base para geração dos testes. Assim, tenta-se
cobrir as imposições e restrições descritas nos requisitos esta­
belecidos para o sistema. A automação da geração dos testes
nesse caso é mais complicada, caso não se tenha um formalis­
mo para a elaboração da especificação do sistema;
• Baseadas em modelos: é uma subcategoria de estratégias
baseada em especificação. Utiliza modelos desenvolvidos ao
longo do processo de desenvolvimento que representam o com­
portamento ou estrutura do software como base para a geração
dos testes. Facilita a geração automática dos testes, porem é
completamente dependente da facilidade para a construção do
modelo adotado e de sua qualidade (corretude).
Cada estratégia apresentada possui sua aplicabilidade, van­
tagens e desvantagens. Não é propósito deste artigo discutir
qual seria a estratégia mais adequada. Ao longo deste artigo
iremos adotar uma estratégia de geração de testes baseada em
especificação, representada pelos casos de uso de um sistema.
Assim, partiremos desta informação para a geração de casos
e procedimentos (roteiros) de teste, seguindo uma estratégia
de teste funcional.
50 Engenharia de Software Magazine - Automatizando Testes Funcionais em Aplicações Web
Teste funcional representa uma categoria de técnicas de
teste em que o componente de software a ser testado é abor­
dado como se fosse uma caixa-preta, ou seja, não se consi­
dera o comportamento interno do mesmo (Figura 1). Dados
de entrada são fornecidos, o teste é executado e o resultado
obtido é comparado a um resultado esperado previamente
conhecido. Haverá sucesso no teste se o resultado obtido for
igual ao resultado esperado. O componente de software a
ser testado pode ser um método, uma função interna, um
programa, um componente, um conjunto de programas e/
ou componentes ou mesmo uma funcionalidade. A técnica
de teste funcional é aplicável a todos os níveis de teste, seja
teste de sistema, aceitação, integração ou unidade.
Figura 1. Técnica de Teste Funcional (caixa-preta)
Um dos mecanismos para facilitar a realização de testes
funcionais é pensar na automação de algumas tarefas que
compõem o processo de testes. Esse é o assunto da próxima
seção.
Automação dos Testes
Automação dos testes consiste no uso de algum apoio com­
putacional, ferramentas, para controlar a execução dos testes,
a comparação dos resultados e comportamentos obtidos com
a execução dos testes em relação aos resultados e compor­
tamentos esperados, a configuração das pré-condições dos
testes e outras atividades do controle dos testes e relato de seus
resultados (KALOWA e HUIZINGA, 2007). Comumente, a au­
tomação dos testes envolve automatizar um processo manual
já estabelecido em uma organização que utiliza um processo
de testes formalizado.
Apesar de os testes manuais poderem encontrar muitos de­
feitos em um software, essa tarefa é complexa, desgastante e
consome muito tempo. Além disso, ela pode não ser tão efetiva
em revelar alguns tipos de falhas em um software.
A automação dos testes é um processo de escrever um pro­
grama computacional para realizar testes que, caso contrário,
seriam feitos manualmente. Uma vez que os testes foram
automatizados, eles podem ser executados rapidamente,
logicamente que proporcionalmente à quantidade de casos
de teste a serem executados. Este representa, na maioria dos
casos, o método de teste com custo mais efetivo para produtos
que possuem uma longa vida, com muitas manutenções, pois
pequenas modificações em certas partes do software ao longo
de sua vida podem fazer com que outras partes do software que
estariam funcionando anteriormente deixem de funcionar.
Existem duas abordagens gerais para automação dos testes:
• Testes dirigidos a código: as interfaces para classes, módu­
los ou bibliotecas são testadas com uma larga variedade de
argumentos de entrada para validar se os resultados que estão
sendo retornados estão corretos;
 Validação, Verificação & Teste
• Teste de Interface (em inglês, Graphical User Interface, ou
simplesmente GUI): um framework de teste gera eventos de
interface do usuário tais como digitação de teclas ou cliques
do mouse, e observa as mudanças que ocorrem na interface do
usuário. Assim, podemos validar se o comportamento obser­
vado do software após tais eventos estão corretos.
Uma forma de gerar casos de teste automaticamente é utili­
zando a estratégia de Teste Baseado em Modelos (ver Nota
DevMan), que adota modelos representando o sistema para
geração de casos de teste, porém existem outras estratégias
interessantes.
O quê automatizar, quando automatizar ou até mesmo se é
necessário de fato automatizar são decisões cruciais que a equi­
pe de teste deve tomar. Selecionar as funcionalidades corretas
do software para automação é um fator essencial para deter­
minar o sucesso da automação. Automatizar funcionalidades
instáveis ou funcionalidades que estão sofrendo alterações
constantes deve ser evitado (MARICK, 2010).
Neste artigo, iremos focar apenas em teste de interface, como
veremos com mais detalhe na continuidade deste artigo.
Importância da Automação dos Testes
Uma das principais características das atividades de teste
de software, assim como a atividade de desenvolvimento de
software em geral, é o fato de ser realizada por pessoas, e
consequentemente passível de erros. A famosa frase “errar é
humano” é o fato que nos leva a desejar testes automatizados.
Diversos problemas relacionados aos testes a serem aplicados
em um software podem ser evitados a partir da automação
desta atividade, dentre os quais:
• Dados de entrada de teste incorretos, informando valores
ou tipos de dados inválidos;
• Não perceber um comportamento incorreto do software a
um certo evento;
• Reportar os resultados dos testes incorretamente;
• Esquecer de executar alguns casos de teste;
• Esquecer de executar alguma pré-condição para execução
dos testes;
• Alteração na execução da sequência de casos de teste, o que
poderia levar a execução dos testes a um fracasso.
Além de evitar os problemas causados por eventuais
falhas humanas, a automação dos testes pode ainda nos
proporcionar:
• Uma forma de armazenar conhecimento sobre o domínio do
projeto ou sobre as funcionalidades que compõem o sistema,
minimizando a dependência pelas pessoas que compõem o
projeto;
• Garantir a acurácia dos relatórios de teste, pois são ge­
rados de forma automática e sempre seguindo um mesmo
padrão;
• Velocidade na execução dos testes, pois uma vez projetado,
sua execução é automática e pode não depender de interven­
ção humana;
Nota do DevMan
Teste Baseado em Modelos
Teste Baseado em Modelos (TBM) consiste em uma estratégia de teste na qual
casos de teste são derivados totalmente ou parcialmente de um modelo que des-
creve algum aspecto (ex: funcionalidade, segurança, desempenho, etc.) de um sof-
tware (UTTING e LEGEARD, 2007). Para sua utilização, é necessário que o compor-
tamento ou estrutura do software (ou parte deles) tenha sido formalizado através
de modelos com regras bem definidas (ex: métodos formais, máquinas de estado
finito, diagramas UML, dentre outros).
A estratégia de TBM normalmente inclui diferentes níveis de abstração, um mo-
delo comportamental/estrutural do software, o relacionamento entre modelos e
código, uma tecnologia para geração dos casos de teste, a importância dos critérios
de seleção dos testes (algoritmos para geração dos casos de teste) e uma discussão
do que pode ou não ser automatizado durante os testes (PRETSCHNER, 2005).
• Realizar teste em momentos específicos e sempre que
necessário, por exemplo, podemos optar por sempre exe­
cutar os testes a cada modificação no sistema com um
esforço baixo, pois os testes já estariam prontos para serem
executados;
• Simplificação nos testes de regressão, pois os testes podem
ser repetidos sempre que a equipe de teste julgar necessário
com pouco esforço;
• Possibilidade de testar o sistema com diferentes conjuntos
de dados, pois o processo de geração e/ou execução é reali­
zado por um computador, de forma que é mais simples gerar
e utilizar nos testes diferentes combinações de dados.
Na seção seguinte iremos focar no tipo de automação de
teste que iremos seguir neste artigo: teste de interface.
Teste de Interface (Graphical User Interface [GUI] Testing)
Muitas ferramentas de automação provêm funcionalidades
de gravar a execução de um software e rodar esta gravação que
permitem aos usuários interativamente “filmar” as ações do usu­
ário e repeti-la quantas vezes quiser, comparando os resultados
e comportamentos obtidos com aqueles esperados. A vantagem
desta abordagem, chamada capture-replay, é que ela requer pouco
ou nenhum desenvolvimento de software. Nesta abordagem, uma
ferramenta de teste grava as entradas de teste como se estivesse
sendo submetido ao software que está sendo testado. Os casos de
entrada armazenados podem então ser usados para reproduzir
os testes posteriormente. Esta abordagem pode ser aplicada a
qualquer aplicação que possua uma interface de usuário gráfica.
No entanto, a dependência dessas funcionalidades representa
mais problemas de confiabilidade e manutenibilidade. Alterar
o nome de um botão ou movê-lo para outra parte da tela pode
requerer que os testes tenham que ser regravados. A abordagem
capture-replay também muitas vezes acrescenta atividades irrele­
vantes ou registra incorretamente algumas atividades. Isso são
limitações reais desta abordagem, mas ainda assim ela possui
bastante aplicabilidade em projetos de software.
Edição 24 - Engenharia de Software Magazine 51
 Nome Empresa
HP QuickTest Professional HP
IBM Rational Functional Tester IBM Rational
Rational robot IBM Rational
Selenium Ferramenta opensource
SilkTest Borland
TestComplete AutomatedQA
TestPartner Micro Focus
Watir Ferramenta opensource
Site com diversas outras ferramentas Ferramenta opensource
Tabela 1. Ferramentas de Automação de Testes de Software mais populares
Uma variação deste tipo de ferramenta seriam as ferra­
mentas para teste de aplicações web. Neste caso, a inter­
face são as páginas web. Este tipo de ferramenta também
requer pouco ou nenhum desenvolvimento de software.
No entanto, o framework para testes pode utilizar diferen­
tes técnicas pois ele está lendo HTML em vez de eventos
de janela de aplicações.
Por fim, outra variação de automação de testes sem
scripts que não usa a ideia de capture-replay, em vez
disso constrói um modelo da aplicação a ser testada e
então permite ao testador criar casos de teste simples­
mente editando os parâmetros e condições de teste. Esta
abordagem pode ser aplicada a qualquer software baseado
em interfaces.
As ferramentas de automação de teste mais conhecidas
podem ser caras, apesar de já existirem diversas ferramen­
tas gratuitas e com um bom conjunto de funcionalidades
de apoio à automação dos testes. Por isso, é importante
realizar uma análise de custo-benefício no momento de
escolher as ferramentas a serem aplicadas em um projeto.
A Tabela 1 apresenta uma lista com algumas das ferra­
mentas de automação mais utilizadas.
Neste artigo, utilizaremos a ferramenta Selenium IDE
para automação de teste funcional usando uma estratégia
de teste do tipo capture-replay, porém contextualizada ao
domínio de aplicações web.
Ferramenta Selenium IDE
Selenium IDE é um ambiente de desenvolvimento in­
tegrado para os testes com Selenium. Foi desenvolvido
como uma extensão do Firefox e permite gravar, editar e
depurar os testes. O Selenium IDE inclui o Selenium Core,
permitindo gravar e reproduzir os testes no ambiente que
eles serão executados, de maneira fácil e rápida.
Entre suas funcionalidades, podemos citar:
1. Gravação e reprodução dos testes de forma simples;
2. Seleção de campo inteligente, que captura as informa­
ções sobre os campos a partir da página;
3. Funcionalidade autocompletar para todos os comandos
de Selenium;
4. Possibilita navegar entre os testes;
52 Engenharia de Software Magazine - Automatizando Testes Funcionais em Aplicações Web
URL
https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?zn=bto&cp=1-11-127-24^1352_4000_100__
http://www-01.ibm.com/software/awdtools/tester/functional/index.html
http://www-142.ibm.com/software/products/br/pt/robot/
http://seleniumhq.org/
http://www.borland.com/br/products/silk/silktest/index.html
http://www.automatedqa.com/products/testcomplete/
http://www.microfocus.com/products/TestPartner/index.asp
http://watir.com/
http://www.opensourcetesting.org/
5. Possibilita configurar depuração e pontos de paradas para
verificação durante os testes;
6. Permite salvar os testes como HTML, scripts em Ruby ou
outro formato.
A partir da próxima seção passaremos a usar Selenium em
um estudo de caso real.
Estudo de Caso: Americanas.com
Neste artigo, realizaremos um teste para uma das opções
disponíveis no site amerianas.com, o cadastro de um novo cliente
realizado no endereço https://carrinho.americanas.com.br/portal/
meuCadastro.portal.
O cadastro de um novo cliente deve seguir alguns passos:
1. Indicação de que ainda não é um cliente (Figura 2). Neste
momento, podemos seguir pelas opções “Já sou cliente – login
e senha”, “Já sou cliente – esqueci minha senha”, “Já sou cliente
– meu e-mail mudou”, “Não sou cliente – informe CEP”, “Não
sou cliente – não sei meu CEP” e “Não sou cliente – estou fora
do Brasil”. No nosso estudo de caso, consideraremos apenas a
opção “Não sou cliente – informe CEP”;
Figura 2. Tela Inicial do Cadastro de Clientes
2. A partir da opção anterior, será exibido um formulá­
rio de cadastro de cliente contendo uma série de campos
(Figura 3);
3. Preenchido o formulário de cadastro, será realizada a vali­
dação dos dados e confirmação da operação, onde é indicado
que o cliente foi de fato cadastrado (Figura 4).
Projetando Testes para nosso Estudo de Caso
Primeiramente, precisamos projetar os testes deste estudo de
caso passo-a-passo, campo-a-campo utilizando algum critério
 Validação, Verificação & Teste
para geração de testes funcionais que foi apresentado no artigo
“Planejamento de Testes a partir de Casos de Uso” publicado
na edição 6 da ES Magazine. É isso que faremos.
Figura 3. Formulário de Cadastro de Clientes
• Projetando os testes do PASSO 1:
Como foi dito na seção anterior, neste passo iremos considerar
apenas a opção “Ainda não sou cliente – Informe seu CEP”.
Esta opção possui apenas um campo, CEP, e o botão Prosseguir.
Neste caso, usaremos o critério particionamento em classes
de equivalência para gerar testes válidos e testes inválidos,
conforme a Tabela 2.
Figura 4. Confirmação do Cadastro de Clientes
Campo Categoria Valor Resultado Esperado
Teste Válido 69046-610 Passar para o PASSO 2
CEP Mensagem de erro:“CEP Inválido.”
Teste Inválido 06543-232
Tabela 2. Casos de Teste para o PASSO 1
Dessa forma, podemos criar um único procedimento de
teste responsável pela execução dos dois casos de teste, onde
primeiramente seria executado o caso de teste inválido e em
seguida o caso de teste válido.
• Projetando os testes do PASSO 2:
Neste passo, existem ao total 22 campos, sendo que 14 são de
preenchimento obrigatório, 5 são opcionais (em cinza na Figura 3)
e 3 são somente leitura (gerados a partir de outros campos –
cidade, estado e país). A Tabela 3 apresenta os casos de teste
gerados para cada campo do formulário utilizando o critério
de geração particionamento em classes de equivalência.
Observe que cada campo possui no máximo dois casos de
teste, de forma que podemos combinar todos os casos de teste
inválidos em um mesmo procedimento de teste (obviamente
alguns casos de teste válidos também irão compor este pro­
cedimento de teste – procedimento de teste 01 na Tabela 3) e
criar um segundo procedimento de teste apenas com casos
de teste válidos, confirmando o cadastro do cliente (proce­
dimento de teste 02).
A partir de agora, iremos usar a ferramenta Selenium para gra­
var e executar os testes projetados para nosso estudo de caso.
Utilizando Selenium para Gravação dos Testes
Como foi dito na Seção Ferramenta Selenium IDE, esta ferra­
menta funciona como um plug-in do Firefox, de forma que é
necessário este browser para gravar e reproduzir os testes.
Então vamos começar?
Primeiramente, abra o Firefox e acesse o endereço de cadas­
tro de um novo cliente (https://carrinho.americanas.com.br/
portal/meuCadastro.portal). Em seguida, abra a ferramenta
Edição 24 - Engenharia de Software Magazine 53
 Campo Categoria Valor Resultado Esperado Procedimento de Teste
Teste Válido Arilo Claudio Dados válidos, verifica os demais campos 02
Nome
Teste Inválido Em branco Mensagem de erro:“Nome Inválido.” 01
Teste Válido 14005039731 Dados válidos, verifica os demais campos 02
CPF
Teste Inválido 14005039710 Mensagem de erro:“CPF Inválido.” 01
Masculino Masculino Dados válidos, verifica os demais campos 02
Sexo
Feminino Feminino Dados válidos, verifica os demais campos 01
Teste Válido 13/09/1982 Dados válidos, verifica os demais campos 02
Data de Nascimento
Teste Inválido 31/02/1982 Mensagem de erro:“Data de nascimento Inválida.” 01
Teste Válido 92 2345-6789 Dados válidos, verifica os demais campos 02
Telefone Residencial
Teste Inválido Em branco Mensagem de erro:“Telefone residencial inválido.” 01
Telefone Celular Teste Válido 92 8181-8181 Dados válidos, verifica os demais campos 01 e 02
Telefone Comercial Teste Válido 92 3456-7890 Dados válidos, verifica os demais campos 01 e 02
Teste Válido ariloclaudio@gmail.com Dados válidos, verifica os demais campos 02
E-mail
Teste Inválido Em branco Mensagem de erro:“E-mail inválido.” 01
Teste Válido arilo Dados válidos, verifica os demais campos 02
Senha
Teste Inválido abc Mensagem de erro:“Senha inválida.” 01
Teste Válido Igual ao campo Senha Dados válidos, verifica os demais campos 02
Confirme a Senha
Teste Inválido Diferente do campo Senha Mensagem de erro:“A senha e confirmação de senha não conferem.” 01
Teste Válido Arilo Claudio Dados válidos, verifica os demais campos 02
Como gostaria de ser chamado?
Teste Inválido Em branco Mensagem de erro:“A senha e confirmação de senha não conferem.” 01
SIM SIM Dados válidos, verifica os demais campos 02
Deseja receber e-mail de ofertas?
NÃO NÃO Dados válidos, verifica os demais campos 01
Descrição do Endereço Teste Válido Residencial Dados válidos, verifica os demais campos 01 e 02
Teste Válido Rua B29 Dados válidos, verifica os demais campos 02
Endereço
Teste Inválido Em branco Mensagem de erro:“Endereço inválido.” 01
Teste Válido 120 Dados válidos, verifica os demais campos 02
Número
Teste Inválido Em branco Mensagem de erro:“Número do endereço inválido.” 01
Complemento Teste Válido Apt 123 Dados válidos, verifica os demais campos 01 e 02
Teste Válido 69046-610 Dados válidos, verifica os demais campos 02
CEP
Teste Inválido 06543-232 Mensagem de erro:“CEP inválido.” 01
Teste Válido Alvorada Dados válidos, verifica os demais campos 02
Bairro
Teste Inválido Em branco Mensagem de erro:“Bairro inválido.” 01
Tabela 3. Casos de Teste para o PASSO 2

Selenium, que já deve estar instalada em seu Firefox. Ao abrir

esta ferramenta, será visualizada sua tela responsável pela
gravação dos testes, na qual por padrão ela já está ativada para
gravação, como pode ser visualizado no ícone com uma bola
vermelha localizado no canto superior direito da tela.
Em seguida, sem fazer nada em Selenium, devemos re­
tornar à tela de cadastro de clientes e preencher seguindo
primeiramente o procedimento de teste referente ao passo
1. O resultado disto em Selenium deve ser uma tela similar
à tela apresentada na Figura 5. Neste momento, podemos
interromper a gravação dos testes. Para isso, basta clicar no
ícone citado anteriormente de forma que este não apareça
como pressionado na tela. Com isso, temos o primeiro roteiro
de teste gravado em Selenium. A partir disso podemos salvá- Figura 5. Roteiro de Teste do PASSO 1
lo ou até mesmo reproduzi-lo, repetindo os testes. Iremos
falar mais sobre sua reprodução na próxima seção. Para isso, primeiramente temos que nos certificar que a
Neste roteiro, foi adicionado um comando verifyTextPresent tela do Firefox está no passo 2 do processo de cadastro
(em destaque na Figura 5) que verifica se após digitar um de clientes e precisamos limpar a ferramenta Selenium
CEP inexistente, a tela retornada contém a mensagem “CEP para que ela inicie uma nova gravação. Depois de veri­
inválido.” que deveria ser retornada por este caso de teste. ficado, devemos iniciar uma nova gravação e preencher
Finalizado o passo 1, passaremos à gravação do passo 2. o formulário de cadastro de clientes primeiramente de

54 Engenharia de Software Magazine - Automatizando Testes Funcionais em Aplicações Web

 Validação, Verificação & Teste
acordo com o procedimento de teste 01 (dados inválidos),
conforme visualizado na Figura 6. Observe que ao final
do roteiro de testes foram adicionados comandos para
verificar se cada campo que recebeu um valor inválido
reportou este problema durante a execução dos testes.
Depois, devemos repetir o processo (limpar os dados em
Selenium e iniciar nova gravação) com os dados do proce­
dimento de teste 02 (dados válidos), conforme a Figura 7.
Observe que ao final do roteiro de testes foi adicionado um
comando para verificar se a tela resultante após esse proce­
dimento foi a tela de cadastro com sucesso (Figura 4). Isso
foi feito analisando se existia o texto “Olá, Arilo Claudio”,
que deveria ser exibido após o cadastro do usuário que optou
por ser chamado de “Arilo Claudio”.
Figura 6. Roteiro de Teste do PASSO 2 (Procedimento de Teste 01 – Dados
Inválidos)
Figura 8. Reprodução do Procedimento de Teste 02 do PASSO 2 com uma
falha
Figura 7. Roteiro de Teste do PASSO 2 (Procedimento de Teste 02 – Dados
Válidos)
Feito isso, temos nossos roteiros de teste gravados e sal­
vos (devemos salvá-los a cada gravação), e a partir de então
poderemos reproduzi-los sempre que necessário.
Observe que a gravação só pode ser reproduzida caso a
execução inicial dos testes (realizada durante a gravação)
tenha sido bem sucedida, ou seja, os testes não falha­
ram, pois o objetivo durante as reproduções dos testes
é obter exatamente os resultados obtidos na primeira
execução.
Utilizando Selenium para Reprodução dos
Testes
A reprodução dos testes é bastante simples. Para cada
passo, basta abrir o arquivo com o roteiro de teste que
foi salvo durante a gravação, e então clicar no ícone com
uma seta verde e três barras verdes à sua direita. Neste
momento, a ferramenta Selenium irá reproduzir todos os
passos feitos no momento da gravação dos testes. Caso
cada comando seja executado com sucesso, a linha é
pintada na cor verde. Caso uma falha tenha ocorrido, a
linha é pintada com a cor vermelha, indicando que houve
problemas que precisam ser analisados.
A Figura 8 exibe uma falha ocorrida no primeiro co­
mando ao tentar reproduzir o procedimento de teste 02
do PASSO 2 (sua linha está em vermelho).
OBS: até o dia 11/03/2010, se você não preenchesse o
CEP no formulário de cadastro, o sistema apresentava
uma falha (Figura 9). Neste caso, não teríamos como
gravar testes com esta condição, pois eles falhariam e não
teríamos como reproduzi-los em um segundo momento.
Em situações como essa, a equipe de desenvolvimento
deve primeiramente corrigir o problema, e então os testes
devem ser gravados.
Conclusões
Este artigo apresentou um possível mecanismo para
automação de teste funcional para aplicações web a partir
do uso da ferramenta Selenium. Tal mecanismo adotou a
estratégia de geração de casos de testes a partir de casos
de uso apresentada em outro artigo publicado na edição
6 da ES magazine.
O objetivo foi apresentar uma solução de automação
dos testes, deixando destacado que a automação só faz
Edição 24 - Engenharia de Software Magazine 55
Figura 9. Falha real ao tentar cadastrar um cliente sem informar seu CEP

sentido a partir do bom conhecimento técnico sobre testes Referências

de software pela equipe de testes, caso contrário há grande
chance de os testes serem malsucedidos. Ferramentas auto­
matizam o conhecimento técnico da equipe de teste, mas não
conseguem passar sobre este conhecimento para aumentar
a qualidade dos testes. Uma vez que este conhecimento
é provido pela equipe de teste, ferramentas contribuem
significativamente para a redução do esforço dos testes e
aumento de sua qualidade.
KOLAWA, A.; HUIZINGA, D. (2007).  Automated Defect Prevention: Best Practices in Software
Management.Wiley-IEEE Computer Society Press. p. 74. ISBN 0470042125.
MARICK, B. “When Should a Test Be Automated?”.StickyMinds.com. Acessado em 10/03/2010.
PRETSCHNER, A. (2005), “Model-based testing”, Proceedings of 27th International Conference on
Software Engineering, (ICSE‘05), pp. 722-723.
UTTING, M.; LEGEARD, B.; (2007),“Practical Model-Based Testing: A Tools Approach”, ISBN-13: 978-0-
12-372501-1, Morgan-Kaufmann.

Dê seu feedback sobre esta edição! Feedback CRAIG, R.D., JASKIEL, S. P.,“Systematic Software Testing”,Artech House Publishers, Boston, 2002. 
eu
s
Dê

A Engenharia de Software Magazine tem que ser feita ao seu gosto. PRESSMAN, R. S., “Software Engineering: A Practitioner’s Approach”, McGraw-Hill, 6th ed, Nova York,
sobre e

Para isso, precisamos saber o que você, leitor, acha da revista! NY, 2005.
s

ta
edição
Dê seu voto sobre este artigo, através do link:
ROCHA, A. R. C., MALDONADO, J. C., WEBER, K. C. et al., “Qualidade de software – Teoria e prática”,
www.devmedia.com.br/esmag/feedback Prentice Hall, São Paulo, 2001.

56 Engenharia de Software Magazine - Automatizando Testes Funcionais em Aplicações Web

Desenvolvimento
Nesta seção você encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software
Testes funcionais automatizados com
Hudson e Selenium RC
Fabrício Nogueira de Almeida
fnalmeida@gmail.com
É pós-graduando do Curso de Gerência de pro-
jetos em engenharia de software pelo centro de
Ensino Superior de Juiz de Fora - CES, Bacharel em
Sistemas de informação pela Faculdade Metodis-
ta Granbery de Juiz de Fora e Analista de Sistemas
da Uptodate Consulting.
Victor Vidigal Ribeiro
victorvidigal@gmail.com
É mestrando em Engenharia de Sistemas e Com-
putação pela COPPE/UFRJ e pós-graduando do
Curso de Gerência de projetos em engenharia de
software pelo Centro de Ensino Superior de Juiz
de Fora - CES.
Marco Antônio Pereira Araújo
maraujo@devmedia.com.br
É Doutor e Mestre em Engenharia de Sistemas e
Computação pela COPPE/UFRJ, 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 Ba-
charelado 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 Fa-
culdade Metodista Granbery, Professor e Diretor do
Curso Superior de Tecnologia em Análise e Desen-
volvimento de Sistemas da Fundação Educacional
D. André Arcoverde, Professor do Curso de Bacha-
relado em Ciência da Computação da Faculdade
Governador Ozanam Coelho, Analista de Sistemas
da Prefeitura de Juiz de Fora, Editor da Engenharia
de Software Magazine.
J
á é bastante aceita pela comunidade
de desenvolvedores o uso de tes­
tes para auxiliar na qualidade dos
softwares desenvolvidos. Dentre os tipos
de testes utilizados existe o teste funcional,
que verifica se o sistema está cumprindo
com seus requisitos utilizando a perspec­
tiva do usuário. Na prática, rodar testes
funcionais significa executar o sistema e
verificar seu comportamento através dos
retornos fornecidos por este sistema.
Para que não haja a necessidade de exe-
cutar esses testes manualmente existem
ferramentas que, depois de programa­
das, executam o sistema automaticamen­
te e verificam seus retornos. Uma dessas
ferramentas é a Selenium IDE, utilizada
neste artigo.
Uma técnica que pode ser utilizada em
conjunto com os testes funcionais é a
técnica de integração contínua. Com esta
técnica é possível uma maior confiabili­
dade no sistema que está no repositório,
pois possibilita que os testes definidos
sejam executados periodicamente.
Edição 24 - Engenharia de Software Magazine
De que se trata o artigo?
Definir uma abordagem para criação e execução de
testes funcionais automatizados.
Para que serve?
O modelo proposto automatiza a execução de testes
funcionais criados através da ferramenta Selenium
IDE, o que proporciona menor dependência de recur-
sos humanos nessa tarefa e auxilia a gerenciamento
da execução dos testes.
Em que situação o tema é útil?
Em ambientes onde é preciso testar constan-
temente os artefatos gerados, e em projetos
onde os testes são complexos e demandam
muitos recursos humanos.
Este artigo propõe a construção de um
ambiente de integração contínua onde
testes funcionais são executados periodi­
camente sobre um sistema, disponível em
um repositório Subversion (SVN) neste
caso. O artigo mostra o funcionamento de
uma pequena aplicação que calcula se um
aluno foi ou não aprovado, que é utilizada
como exemplo. Depois disso, explica como
gerar testes funcionais com a ferramenta
57
Selenium IDE e como importar esses testes para o framework
de testes JUnit. Depois disso, é demonstrado como os testes que
foram exportados podem ser executados através da ferramenta
Selenium RC e, posteriormente, como executar esses testes em
um servidor de integração contínua chamado Hudson. Para criar
o projeto que será testado foi utilizado o Maven, uma ferramenta
de gerenciamento e automação de projetos em Java que permite
uma maior integração entre o projeto a ser testado e o Hudson.
Aplicação a ser testada
Para a execução dos testes a serem demonstrados neste artigo
foi criada uma aplicação que calcula a aprovação de um aluno.
É importante conhecer o funcionamento da aplicação para que
se possa entender os testes elaborados.
Esta aplicação funciona através de um browser e recebe o
nome, frequência, nota 1, nota 2 e nota final do aluno como
parâmetros de entrada. Além desses parâmetros, o sistema
possui ainda um botão Calcular Aprovação, como pode ser
visto na Figura 1.
Figura 1. Tela do sistema
Após inserir os dados e clicar no botão Calcular Aprovação,
o sistema emite uma mensagem para o usuário informando
se o aluno foi ou não aprovado seguindo as seguintes regras:
caso a frequência do aluno for menor que 75, ele é reprovado.
Caso contrário, a média entre a nota 1 e a nota 2 é calculada.
Se esta média for menor que 30, o aluno é reprovado, caso
seja maior ou igual a 70, o aluno é aprovado. Se a média entre
as duas notas for maior ou igual a 30 e menor que 70, então é
calculado a média entre a média anterior e a nota final. Se esta
nova média for maior ou igual a 50, o aluno é aprovado. Caso
contrário, ele é reprovado.
A Figura 2 mostra a mensagem que o sistema exibe ao usuário
após clicar no botão Calcular Aprovação, em um caso que o
aluno é aprovado. É bastante importante observar que este tipo
de resposta do sistema é que possibilita a execução dos testes
funcionais, pois através dessas mensagens é que os testes vão
verificar se o sistema agiu como esperado ou não.
Figura 2. Mensagem de resposta
58 Engenharia de Software Magazine - Testes funcionais automatizados com Hudson e Selenium RC
Instalando o selenium IDE
Podemos então iniciar a construção dos testes funcionais
utilizando o Selenium IDE, um plug-in para o navegador
Firefox que permite gravar, editar, depurar e reproduzir
testes funcionais para páginas web.
Para instalar o Selenium IDE, acesse o endereço https://
addons.mozilla.org/pt-BR/firefox/ usando o navegador
Firefox, e informe no campo de busca o termo selenium
ide. Após isto, clique no link Selenium IDE que aparece na
lista e, em seguida, no botão Add to Firefox, como mostra
a Figura 3.
Figura 3. Instalação do Selenium IDE
Após a instalação, o plug-in estará disponível através do
menu Ferramentas do navegador.
Criando os casos de teste com Selenium IDE
Para criar os casos de testes funcionais, primeiro é pre­
ciso acessar a aplicação de exemplo, criada anteriormente,
com o navegador Firefox. Depois, no menu Ferramentas,
selecione a opção Selenium IDE.
Uma nova janela, como mostra a Figura 4, se abrirá
permitindo iniciar a gravação dos testes. Observe no
canto superior direito dessa janela se o botão que indica
o status da gravação está pressionado. Caso este botão
esteja pressionado, cada ação do usuário no browser será
gravada pelo Selenium IDE. Por ação pode-se entender,
por exemplo, o preenchimento de um campo ou um clique
em um botão.
Para iniciar gravação dos testes basta preencher os cam­
pos da aplicação com os valores descritos na Tabela 1,
referentes ao primeiro caso de teste a ser realizado, consi­
derando um aluno sendo reprovado por infrequência.
Campo Valor
Nome João
Frequência 74
Nota 1 0
Nota 2 0
Nota Final 0
Tabela 1. Reprovação por infrequência
 Validação, Verificação e Teste

Seguindo os procedimentos acima, podem ser gerados mais

4 casos de testes com os dados apresentados nas Tabelas 2,
3, 4 e 5.

Campo Valor
Nome João
Frequência 75
Nota 1 70
Nota 2 70
Nota Final 0
Tabela 2. Aprovação por nota

Campo Valor
Nome João
Frequência 75
Nota 1 29
Nota 2 30
Nota Final 0
Tabela 3. Reprovação por nota

Campo Valor
Nome João
Figura 4. Janela do Selenium IDE Frequência 75
Nota 1 30
Após o preenchimento dos campos, clique no botão Calcular
Nota 2 30
Aprovação. O sistema retornará a mensagem dizendo que o
aluno foi reprovado. Nota Final 69
Neste momento, é preciso informar ao Selenium IDE o que Tabela 4. Reprovação por nota final
era esperado caso o valor 74 fosse digitado para a frequência
e todas as notas fossem preenchidas com zero. Neste caso, ob­ Campo Valor
servando as regras descritas no início do artigo, o aluno seria Nome João
reprovado por infrequência. Logo, espera-se que o sistema emi­ Frequência 75
ta uma mensagem informando que o aluno foi reprovado.
Nota 1 30
Para passar esta informação ao Selenium IDE, selecione o
Nota 2 30
texto da mensagem, clique com o botão direito do mouse e
escolha a opção verifyTextPresent, como mostra a Figura 5. Nota Final 70
Em seguida, deve-se terminar a gravação do teste, clicando no Tabela 5. Aprovação por nota final
botão do canto superior direito da ferramenta. Por fim, deve-se
gravar o caso de teste, a partir do menu Arquivo. Depois de criar os casos de testes necessários eles devem
ser exportados como um arquivo de teste do framework JUnit
para que possam ser executados com o Hudson e o Selenium
RC. Essas duas ferramentas são necessárias para a execução
automática dos testes funcionais e serão vistas posteriormente
neste artigo.
Para exportar os testes gravados, acesse a opção Arquivo /
Exportar Teste Como / Java (JUnit) Selenium RC, informe um
nome para o arquivo precedido pela extensão .java e clique
sobre o botão Salvar. Com isto, será gerado um arquivo de teste
do JUnit baseado no teste que acabou de ser gravado. É preciso
exportar cada caso de teste gravado com o Selenium IDE.
Depois de exportar cada arquivo, é preciso editá-los e
alterar a URL que indica a página inicial do teste. Para
Figura 5. Gravando resultado do caso de teste isso, altere o primeiro parâmetro do método SetUp, de

Edição 24 - Engenharia de Software Magazine 59

http://change-this-to-the-site-you-are-testing/ para o endereço
do servidor da aplicação. Neste exemplo, a URL inicial é http://
localhost:8000/.
Criando o projeto de testes
Neste ponto do artigo, já temos os casos de testes exportados
como um arquivo executável pelo JUnit. Precisamos agora criar
um projeto onde esses testes estarão contidos.
Para criar este projeto será utilizado o IDE Eclipse com o plug-
in m2eclipse que permite a integração entre o IDE e o Maven.
Este plug-in pode ser instalado através da URL http://m2eclipse.
sonatype.org/sites/m2e. A criação de um projeto utilizando o
Maven não foi por acaso. Esse gerenciador de projetos trabalha
muito bem com o servidor de integração contínua Hudson, que
será utilizado posteriormente.
Para criar o projeto, abra o Eclipse e acesse o menu File / New
/ Other, e escolha a opção Maven / Maven Project. Depois disso,
é preciso dar um nome ao projeto criado. No artigo o projeto
recebeu o nome de CalcularAprovacaoSelenium.
Depois de criado, deve-se alterar o arquivo pom.xml, gerado
pelo Maven, para que fique semelhante à Listagem 1. Com essas
alterações no arquivo, as dependências do JUnit e Selenium-Java-
Client, necessárias para a execução dos testes, são adicionadas
no projeto.
Após criar o projeto e definir suas dependências, devem-se co­
piar os testes gerados através da ferramenta Selenium IDE para
o pacote test. A Figura 6 mostra a estrutura do projeto criado.
Figura 6. Estrutura do projeto de testes
Tanto o projeto de teste quanto o projeto a ser testado devem
ser enviados para um repositório de dados. Neste artigo, será
utilizado o SVN. Como o uso de repositórios já é bastante
comum, isso não será abordado nesse artigo.
Selenium Remote-Control
O Selenium Remote-Control, ou simplesmente Selenium
RC, permite a execução automatizada de testes criados no
Selenium IDE. No ambiente proposto, será utilizado o Sele­
nium RC juntamente com o servidor de integração Hudson
60 Engenharia de Software Magazine - Testes funcionais automatizados com Hudson e Selenium RC
para programar a execução dos testes e criar um ambiente de
testes automatizado.
Listagem 1. Arquivo pom.xml
<project xmlns=”http://maven.apache.org/POM/4.0.0” xmlns:xsi=
”http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation=”http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd”>
<modelVersion>4.0.0</modelVersion>
<groupId>CalcularAprovacaoSelenium</groupId>
<artifactId>CalcularAprovacaoSelenium</artifactId>
<packaging>jar</packaging>
<version>0.0.1-SNAPSHOT</version>
<name>CalcularAprovacaoSelenium</name>
<url>http://maven.apache.org</url>
<
dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.2</version>
<scope>test</scope>
</dependency>
<dependency>
<
groupId>org.seleniumhq.selenium.client-drivers</groupId>
<
artifactId>selenium-java-client-driver</artifactId>
<
version>1.0.1</version>
</dependency>
<
/dependencies>
</project>
O Selenium RC pode ser baixado no endereço http://seleniu­
mhq.org/download/. Depois de baixá-lo, extraia seu conteúdo
em algum diretório do computador. No exemplo demonstrado
no artigo, é utilizado o diretório C:.
Para executar o Selenium RC, deve-se abrir o prompt de co­
mando e digitar os comandos demonstrados na Listagem 2.
O primeiro comando acessa o diretório onde o JRE (Java Run­
time Environment) está instalado e a linha seguinte executa
o Selenium RC.
Listagem 2. Execução do Selenium RC
cd C:\Program Files (x86)\Java\jre6\bin
java -jar C:\selenium-remote-control-1.0.1\selenium-server-1.0.1\
selenium-server.jar
Uma dica para agilizar este processo é criar um arquivo com
extensão .bat com o conteúdo da Listagem 2.
Após executar o Selenium RC, uma janela como a ilustrada
na Figura 7 é exibida. Essa janela deve ser mantida sempre
aberta para que o Selenium RC fique ativo possibilitando a
execução dos testes.
Neste ponto será possível testar a execução dos testes dire­
tamente pelo Eclipse. Para isso, devemos clicar com o botão
direito sobre o projeto, acessar a opção Run As e depois Ma­
ven Test, como mostra a Figura 8. Com esse procedimento, o
projeto será executado chamando o Maven2 e atribuindo ao
 Validação, Verificação e Teste
parâmetro Goal o valor test, indicando que os testes do projeto
devem ser rodados.
Figura 7. Prompt Selenium RC
Instalação e configuração do servidor de integração
hudson
Para garantir mais produtividade e melhor controle sobre a
execução dos testes, vamos utilizar o Servidor de Integração
Hudson, que permite a execução dos testes funcionais de for­
ma automatizada e contínua. O Hudson será responsável por
baixar o projeto de testes direto do repositório SVN e executar
os testes no Selenium RC através das configurações feitas com
o Maven2, e conforme agendado no aplicativo.
O Hudson é um projeto web desenvolvido em Java e dispo­
nibilizado para download através do link https://hudson.dev.
java.net/ e pode ser executado através de um servidor web.
Neste exemplo, será utilizado o Apache Tomcat, disponível
para download em http://tomcat.apache.org/.
Figura 8. Executando os testes no eclipse
Depois de instalado o Tomcat, deve-se copiar o arquivo hud­
son.war para a pasta webapps e reiniciar o servidor para fazer
o deploy da aplicação. Feito isso, acesse o Hudson através do
endereço http://localhost:8080/hudson. A Figura 9 mostra a
tela inicial do servidor de integração Hudson.
Figura 9. Tela inicial do Hudson
O próximo passo será configurar o Hudson. Para isso, de­
vemos acessar no menu lateral a opção Gerenciar Hudson e
depois Configure System.
Entre as principais configurações do Hudson, deve ser
habilitada a instalação do Maven através da sua opção
Install automatically. Marcando essa opção, o Hudson
se encarregará de baixar as bibliotecas necessárias para
construção de projetos do tipo Maven2. É preciso também
incluir a instalação do JDK desmarcando sua opção Install
automatically e informando o caminho onde o JDK foi ins­
talado no campo JAVA_HOME. A Figura 10 ilustra como é
feita essa configuração.
Figura 10. Configuração Hudson
Para mais detalhes sobre as opções de configuração dis­
ponível pelo Hudson, veja o artigo Integração contínua com
Hudson, Maven2, TestNG e Subversion publicado na edição
21 da Engenharia de Software Magazine.
Criando tarefas do hudson
Concluída a etapa de configuração, é possível criar uma tare­
fa e agendar a execução dos testes. Para isso, deve-se acessar o
menu lateral Nova Tarefa e, na tela seguinte, deve-se informar
o nome da tarefa a ser criada. Nesse exemplo, é chamada de
TesteSeleniumCalcularAprovacao. Em seguida, selecione a
opção Construir um projeto maven2 e clique em OK.
Após isto, uma nova janela será exibida, sendo possível
configurar como será a construção dessa tarefa. Em Geren­
ciamento de código fonte, deve-se marcar a opção Subversion,
e depois informar o caminho do projeto no repositório SVN
no campo URL do Repositório. Essa configuração indicará ao
Hudson o caminho que ele utilizará para baixar os arquivos
do projeto.
Edição 24 - Engenharia de Software Magazine 61
 A seguir é possível configurar a periodicidade de execução
dos testes. Para isso, a opção Construir periodicamente em
Disparadores de construção deve ser marcada. Na caixa
de texto deve ser inserido o seguinte valor: * * * 5. Essa
configuração indica ao Hudson que esta tarefa deve ser
executada no minuto cinco de cada hora. Clicando sobre o
ícone localizado ao lado direito da caixa de texto, o Hu­
dson fornece um tópico de ajuda que explica com detalhes
as opções de agendamento.
A próxima configuração a ser feita é indicar no campo POM
Raiz o caminho para o arquivo pom.xml, que mantém as
configurações do Maven2 no projeto. Neste exemplo, o cami­
nho do arquivo de configuração é <NOME DO PROJETO>/
pom.xml. A opção Goals and options deve ser preenchida Figura 12. Console Output
com o valor test. Esse parâmetro indica ao Hudson que deve
executar o Maven para rodar os testes do projeto. Conclusão
Por fim, é possível configurar o Hudson para enviar noti­ Esse artigo procurou mostrar como montar um ambiente
ficações de email a cada construção executada com falhas. de testes funcionais automatizados utilizando ferramentas
Para isso, a opção Notificação de e-mail deve ser marcada e Open Source. Esse ambiente foi construído com o servidor
deve-se ainda informar os e-mails para os quais desejamos de integração Hudson, o gerenciador de projetos Maven2,
que sejam enviadas notificações. repositório de dados SVN, framework de testes JUnit e um
Depois de realizadas as devidas configurações, as altera­ aplicativo responsável por executar os testes gerados através
ções devem ser salvas através do botão Salvar. Após isto, do Selenium IDE, o Selenium RC.
uma tela como a mostrada na Figura 11 será exibida. Neste Executar testes muitas vezes pode se tornar uma tarefa que
ponto é possível construir uma tarefa manualmente clicando demanda tempo e consome muito recursos em um projeto. Mas
no link Construir Agora. devido a sua importância dentro da Engenharia de Software,
deixá-la de lado pode significar entregar um produto com alto
índice de falhas para o cliente. Com a alternativa proposta
neste artigo, ganhamos um alto índice de produtividade na
execução dos testes funcionais garantindo mais qualidade ao
produto final que será entregue ao cliente.

Dê seu feedback sobre esta edição! Feedback

eu

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

sobre e
Para isso, precisamos saber o que você, leitor, acha da revista!

s
ta
edição
Figura 11. Tela principal da tarefa Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback
O Hudson exibe em Histórico de construções o status das
Links
construções já realizadas e também aquelas que estão em
execução. Clicando sobre uma construção e acessando a op­ Hudson
http://hudson-ci.org/
ção Console Output é possível visualizar o log de execução
da construção, como mostra a Figura 12. Maven
Depois de fazer essas configurações, o Hudson irá baixar http://maven.apache.org/
o sistema periodicamente do repositório e irá executar os
Tomcat
testes funcionais criados no Selenium IDE. Com isso, pode- http://tomcat.apache.org/
se economizar bastante esforço da equipe de testes que não
precisará executar todos os testes do sistema a cada alteração SeleniumRC
http://seleniumhq.org/projects/remote-control/
realizada pelos programadores. Além disso, o sistema que
está no repositório pode ser considerado mais confiável, Subversion
pois ele está sempre sendo testado. http://subversion.tigris.org/

62 Engenharia de Software Magazine - Testes funcionais automatizados com Hudson e Selenium RC

Validação, Verificação e Teste

Edição 24 - Engenharia de Software Magazine 63

 AMIGO
...só pra lembrar,
Existem coisas sua assinatura pode
estar acabando!
que não
conseguimos
ficar sem!
Renove Já!

www.devmedia.com.br/renovacao
Para mais informações:
www.devmedia.com.br/central

64 Engenharia de Software Magazine - Testes funcionais automatizados com Hudson e Selenium RC