Automação de Testes - Engenharia de Software - Edição 29

Prévia do material em texto

www.infnet.edu.br - cursos@infnet.edu.br - Central de Atendimento: (21) 2122-8800
E D U C A Ç Ã O S U P E R I O R O R I E N T A D A A O M E R C A D O
PÓS-GRADUAÇÃO
Engenharia de Software: 
Desenvolvimento Java
Engenharia de Software: 
Desenvolvimento .NET
GRADUAÇÃO
Engenharia de Computação
Análise e Desenv. de Sistemas
FORMAÇÕES
Desenvolvedor Java
Desenv. Java: Sist. Distribuídos
Gestor de TI
Desenvolvedor Web .NET 2008
MCITP Server Administrator 
SQL Server 2008
Acesse nosso site e conheça todos os nossos programas: www.infnet.edu.br/esti
A Escola Superior da Tecnologia da 
Informação oferece as melhores 
opções em cursos, formações, 
graduações e pós-graduações para 
profissionais de desenvolvimento 
e programação. 
São programas voltados para a 
formação de profissionais de elite, 
com aulas 100% práticas, corpo 
docente atuante no mercado, 
acesso à mais atualizada biblioteca 
de TI do Rio, laboratórios equipados 
com tecnologia de ponta, salas de 
estudo e exames.
r/esti
TURMAS
NO RIO DE
JANEIRO
Modéstia à parte, sua
melhor opção para
se destacar no mercado!
Corpo Editorial 
Colaboradores
Rodrigo Oliveira Spínola
Marco Antônio Pereira Araújo 
Eduardo Oliveira Spínola
Capa
Romulo Araujo - romulo@devmedia.com.br
Diagramação
Janete Feitosa
Coordenação Geral
Daniella Costa - daniella@devmedia.com.br
Revisor e Supervisor
Thiago Vincenzo - thiago.v.ciancio@devmedia.com.br
Na Web
www.devmedia.com.br/esmag
Ano 3 - 29ª Edição - 2010 Impresso no Brasil
A
utomatizar os testes nada mais é do que repassar para o computador as ativida-
des de testes que normalmente são realizadas de forma manual. A automação de 
testes deve ser iniciada a partir de um processo manual de teste já estabelecido e 
maduro. Várias são as ferramentas disponíveis no mercado para as empresas, entre pagas 
e gratuitas.
A automação de testes possui alta capacidade para reduzir esforços. Com isso, pensar em 
mecanismos para automação dos testes 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 software. 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 exe-
cuçã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 conhecimento sobre estraté-
gias de teste, a automação pode trazer grandes benefícios a um projeto de software.
Neste contexto, a Engenharia de Software Magazine destaca nesta edição duas 
matérias:
• Automação dos Testes: um lobo na pele de cordeiro?: cujo objetivo é apresentar uma 
reflexão sobre os cuidados que devem ser levados em consideração na aplicação da au-
tomação de testes. 
• Processo e automação de testes de Software: cujo objetivo é apresentar uma expe-
riência prática de executar um processo de teste em um projeto de software desenvolvido 
com base na Programação Exploratória, utilizando ferramentas para automação de testes.
Além destas matérias, esta edição traz mais seis artigos:
• O dia em que virei um Ninja
• Acompanhamento de projetos ágeis distribuído através do Daily Meeting
• Requisitos em SOA – Parte 2
• Diagramas de Sequência: Uma Abordagem Prática
• Refatoração para Padrões - Parte 2
• Qualidade de Software.
Desejamos uma ótima leitura!
Equipe Editorial Engenharia de Software Magazine
Rodrigo Oliveira Spínola 
rodrigo.devmedia@gmail.com
Doutorando em Engenharia de Sistemas e Computação (COPPE/UFRJ). Mestre em 
Engenharia de Software (COPPE/UFRJ, 2004). Bacharel em Ciências da Computação 
(UNIFACS, 2001). Colaborador da Kali Software (www.kalisoftware.com), tendo minis-
trado cursos na área de Qualidade de Produtos e Processos de Software, Requisitos e 
Desenvolvimento Orientado a Objetos. Consultor para implementação do MPS.BR. Atua 
como Gerente de Projeto e Analista de Requisitos em projetos de consultoria na COPPE/
UFRJ. É Colaborador da Engenharia de Software Magazine.
Marco Antônio Pereira Araújo
maraujo@devmedia.com.br
Doutor e Mestre em Engenharia de Sistemas e Computação pela COPPE/UFRJ - Li-
nha de Pesquisa em Engenharia de Software, Especialista em Métodos Estatísticos 
Computacionais e Bacharel em Matemática com Habilitação em Informática pela 
UFJF, Professor e Coordenador do curso de Bacharelado em Sistemas de Informação 
do Centro de Ensino Superior de Juiz de Fora, Professor do curso de Bacharelado em 
Sistemas de Informação da Faculdade Metodista Granbery, Professor e Diretor do Cur-
so Superior de Tecnologia em Análise e Desenvolvimento de Sistemas da Fundação 
Educacional D. André Arcoverde, Analista de Sistemas da Prefeitura de Juiz de Fora, 
Colaborador da Engenharia de Software Magazine.
Eduardo Oliveira Spínola
eduspinola@gmail.com
É Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Ma-
gazine. É bacharel em Ciências da Computação pela Universidade Salvador (UNIFACS) 
onde atualmente cursa o mestrado em Sistemas e Computação na linha de Engenharia 
de Software, sendo membro do GESA (Grupo de Engenharia de Software e Aplicações).
Apoio
Atendimento ao Leitor
A DevMedia conta com um departamento exclusivo para o atendimento ao leitor. 
Se você tiver algum problema no recebimento do seu exemplar ou precisar de 
algum esclarecimento sobre assinaturas, exemplares anteriores, endereço de 
bancas de jornal, entre outros, entre em contato com:
Daniela Maciel e Flávia Aparecido – Atendimento ao Leitor
www.devmedia.com.br/mancad
(21) 2220-5338
Kaline Dolabella
Gerente de Marketing e Atendimento
kalined@terra.com.br
(21) 2220-5338
Publicidade
Para informações sobre veiculação de anúncio na revista ou no site entre em 
contato com:
Cristiany Queiroz
publicidade@devmedia.com.br
Fale com o Editor! 
É muito importante para a equipe saber o que você está achando da revista: que tipo de artigo 
você gostaria de ler, que artigo você mais gostou e qual artigo você menos gostou. Fique a 
vontade para entrar em contato com os editores e dar a sua sugestão!
Se você estiver interessado em publicar um artigo na revista ou no site SQL Magazine, 
entre em contato com os editores, informando o título e mini-resumo do tema que você 
gostaria de publicar:
Rodrigo Oliveira Spínola - Colaborador
rodrigo.devmedia@gmail.com
EDITORIAL
 
 ÍNDICE
Por trás do obvio
06 – O dia em que virei um Ninja
Glênio Cabral
Agilidade
 07 - Acompanhamento de projetos ágeis distribuído através do Daily Meeting 
Hernan Julho Muñoz e Teresa M Medeiros Maciel 
Engenharia
15 - Requisitos em SOA – Parte 2
João Caldas Júnior 
20 - Automação dos Testes: um lobo na pele de cordeiro? 
Daniel Scaldaferri Lages 
26 - Processo e automação de testes de Software
Eliane Collins e Luana Lobão 
34 - Qualidade de Software 
Lenildo Morais 
Desenvolvimento
39 - Diagramas de Sequência: Uma Abordagem Prática 
Geraldo Magela Dutra Gonçalves 
46 - Refatoração para Padrões – Parte 2 
Jacimar Fernandes Tavares e Marco Antônio Pereira Araújo 
Tipo: Processo 
Título: Atividades da Gerência de Projetos – Partes 10 a 14
Autor: Rodrigo Oliveira Spínola
Mini-Resumo: A gerência de projetos possui um conjunto de atividades 
associadas aos processosda gerência. Nesta série de 5 vídeo aulas conhe-
ceremos algumas dessas principais atividades destacando seus objetivos, 
tarefas desempenhadas e resultados esperados. Alguns dos assuntos tratados 
serão: planejamento de cronograma, planejamento de recursos humanos e 
planejamento de riscos.
Caro Leitor, 
Para esta edição, temos um conjunto de 5 vídeo aulas. 
Estas vídeo aulas estão disponíveis para download no Portal 
da Engenharia de Software Magazine e certamente trarão 
uma significativa contribuição para seu aprendizado. A lista 
de aulas publicadas pode ser vista abaixo:
AMIGO
Existem coisas
que não conseguimos
ficar sem!
...só pra lembrar,
sua assinatura pode 
estar acabando! 
Renove Já!
www.devmedia.com.br/renovacao
Para mais informações:
www.devmedia.com.br/central
Edição 05 - Engenharia de Software Magazine 5 
6 Engenharia de Software - O dia em que virei um Ninja
Glênio Cabral
gleniocabral@yahoo.com.br
É Administrador de Empresas, pós-graduado em Gestão de Pessoas e mú-
sico. Idealizador do site de educação infantil www.novainfancia.com.br.
O dia em que virei um 
Ninja
Pos trás do Óbvio
Dê seu feedback sobre esta edição!
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
Para isso, precisamos saber o que você, leitor, acha da revista!
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback
D
ê 
se
u Fe
edback
so
b
re esta edição
Foi uma noite inesquecível. Lá estava eu, louco pra sentar-me na primeira fila para assistir a palestra “Técnicas Ninja para sua empresa”. O palestrante era um japonês que se 
dizia mestre das artes marciais e que agora aplicava as técnicas 
de luta para gerenciar melhor os seus negócios. Todo mundo 
dizia que sua empresa dera um salto de produção depois disso, 
por isso o auditório estava lotado. Assim que entrei fui logo re-
cepcionado por um homem trajado como um ninja, com espada 
e tudo. Ele deu um grito estarrecedor, começou a gesticular 
freneticamente e me entregou uma espada de madeira, dizendo 
“IAKIÓÓÓÓÓÓÓ!”. Sentei me sentindo um Karatê Kid.
Olhei para a espada de madeira em minha mão e disse pra 
mim mesmo: “abra a mente, abra a mente.” De repente, as luzes 
do auditório se apagaram. Um som ao fundo dizia pra gritar-
mos como nunca havíamos gritado antes em nossas vidas. Era 
engraçado observar aqueles engravatados empunhando uma 
espada de madeira aos berros, como se fossem criaturas bizar-
ras saídas de um RPG. Depois de dez segundos da mais pura 
histeria, o palestrante apareceu no palco encoberto por uma 
nuvem de fumaça e empunhando uma espada gigantesca. Pau-
sadamente, ele falou: “Sou o mestre Okhaio, e a partir de agora 
convoco o espírito de Shaulim para batizá-los e transformá-los 
em Ninjas Guerreiros.” Assim que terminou de falar isso, um 
caldeirão de água misturada com flores foi derramado sobre 
todos nós, sabe-se lá de onde. Pronto, fomos batizados pelo 
espírito de Shaulim. Só então o palestrante começou a exibir 
uma série de golpes de artes marciais mostrando como pode-
ríamos aplicá-los ao nosso dia-dia nas organizações. 
Sinceramente, não vi sentido algum em nada daquilo. Pra 
falar a verdade, estava me sentindo um perfeito idiota, todo 
encharcado e com uma espada de brinquedo na mão.
Apesar disso, aprendi preciosas lições com essa experiência. 
Primeiro, que há muita picaretagem no universo das palestras 
motivacionais. Não duvido que tais eventos possam trazer 
real proveito para as pessoas, mas tudo tem seu limite. Tentar 
compensar falta de conteúdo com bizarrices dessa natureza 
é um desrespeito às pessoas que pagaram e que esperam o 
retorno do seu investimento. Segundo, soluções mágicas e 
imediatas para problemas complexos não passam de engana-
ção. Problemas difíceis não são resolvidos da noite para o dia, 
uma vez que exigem esforço, experiência e aperfeiçoamento. 
Isso leva tempo. Terceiro, aprendi algo útil para economizar 
meu dinheiro, pois após essa experiência fico sempre com um 
pé atrás quando vejo anúncios mirabolantes de cursos ou de 
palestras. E quarto, definitivamente não é legal ser batizado 
por um espírito chamado Shaulin.
Portanto, estarmos atentos a venda de soluções fáceis e suspei-
tas é fundamental para que evitemos surpresas desagradáveis. 
Temos visto muitas dessas soluções (verdadeiras balas de prata) 
sendo vendidas também quando tratamos do desenvolvimento 
de software. O problema é que são tão bem vendidas que cor-
remos o sério risco de acreditarmos em sua eficácia.
Edição 29 - Engenharia de Software Magazine 7 
Teresa M Medeiros Maciel
tmmaciel@gmail.com
Mestre em Engenharia de Software e dou-
toranda pela UFPE. Professora do DEINFO/
UFRPE e pesquisadora do Instituto Nacional 
Tecnológico para Engenharia de Software - 
INES. Atua no desenvolvimento de software 
há cerca de 20 anos, tendo dedicado os 
últimos 10 anos à área de qualidade. Es-
truturou e liderou a gerência de qualidade 
do C.E.S.A.R durante 8 anos, onde condu-
ziu projetos de melhoria de processos de 
software. Desde 2008 vem desenvolvendo 
projetos de P&D aplicando a pesquisa em 
problemas reais da indústria de software, 
especialmente sobre a adoção de metodolo-
gias ágeis em ambientes diversos.
Hernan Julho Muñoz 
hernan99@gmail.com
Mestrando em Engenharia de Software 
pela Universidade Federal de Pernambuco. 
Especialização em Sistema de Informação 
com Ênfase em Componentes Web Distri-
buídos pela Faculdade Ruy Barbosa. Além 
de certicados Java como SCJP, SCWCD, 
SCBCD. Atualmente atua como analista 
de sistemas na Universidade Estadual da 
Bahia (Uneb).
De que se trata o artigo?
Neste artigo veremos os principais problemas as-
sociados ao acompanhamento de projetos ágeis 
num ambiente distribuído, dando ênfase à prática 
Daily Meeting do Scrum. Em seguida discutiremos 
como as ferramentas fornecem apoio a essa práti-
ca. Por fim, uma abordagem é proposta para dar 
o suporte necessário ao Daily Meeting distribuído 
com o apoio de um ambiente para a realização das 
reuniões diárias. 
Para que serve?
Este artigo serve para as empresas que visam me-
lhorar o acompanhamento de seus projetos distri-
buídos utilizando o Scrum como principal metodo-
logia ágil no gerenciamento do mesmo.
Em que situação o tema é útil?
Esse tema é útil para as empresas que preten-
dem escalar o projeto através do desenvolvi-
mento distribuído e estão em busca de infor-
mações de como o acompanhamento do projeto 
pode ser realizado.
Acompanhamento de projetos ágeis 
distribuído através do Daily Meeting
No cenário atual, os sistemas pos-suem funcionalidades cada vez mais complexas, os requisitos 
mudam constantemente, e a entrega é 
feita em um tempo cada vez mais curto. 
Tais fatos motivaram a adoção de meto-
dologias mais flexíveis, que promovesse 
maior rapidez e qualidade ao software 
produzido. A adoção das metodologias 
ágeis de desenvolvimento cresceu nos 
últimos anos pelo fato de os projetos 
que usavam os chamados métodos 
tradicionais apresentarem os mesmos 
problemas, dentre eles: extrapolação dos 
prazos de entrega do software, custo aci-
ma do previsto e a insatisfação elevada 
do cliente.
Em paralelo ao crescimento dos mé-
todos ágeis, o desenvolvimento distri-
buído de software vem ganhando cada 
vez mais adeptos. Dentre as razões pela 
Agilidade
Nesta seção você encontra artigos voltados para as práticas e métodos ágeis.
8 Engenharia de Software Magazine - Acompanhamento de projetos ágeis distribuído através do Daily Meeting
opção por esta abordagem, pode ser ressaltado o baixo custo 
para manter um espaço físico para acomodar muitas pessoas 
em algumas regiões e a dificuldade de encontrar pessoas 
qualificadas na mesma localidade. Outra vantagem é a capa-
cidade das equipes distribuídas de trabalharem em paraleloe em diferentes fusos horários, acelerando a velocidade de 
desenvolvimento [6].
O uso de metodologias ágeis no desenvolvimento de siste-
mas com times distribuídos pode ser uma boa estratégia para 
reduzir custo e ainda mais o tempo de desenvolvimento de 
um sistema. O fato de os princípios e valores dos métodos 
ágeis pregarem maior foco na interação de clientes, feedback 
rápido e maior interação entre os membros através do contato 
face-a-face, é um empecilho num ambiente distribuído. Apesar 
destas possíveis restrições, algumas empresas adotaram esta 
combinação com sucesso, como a experiência relatada por 
Sutherland [13], que descreve o cenário no qual foi aplicado 
Scrum com XP em equipes distribuídas.
A adoção do desenvolvimento ágil distribuído é considerada 
um desafio para o gerenciamento ágil de projetos, pelo fato 
de tornarem a comunicação e a interação entre os membros 
mais difíceis, podendo causar maus entendimentos das fun-
cionalidades durante o projeto. Por outro lado, metodologias 
ágeis mais específicas para a gestão de projetos, como Scrum, 
podem ajudar no gerenciamento ao incentivar a equipe a se 
comunicar e acompanhar o progresso do projeto todos os 
dias. Através das reuniões diárias propostas pelo Scrum, os 
membros da equipe interagem, o progresso é monitorado e os 
ajustes que precisam ser realizados durante o projeto podem 
ser tomados prontamente, melhorando a comunicação e a 
colaboração entre os membros.
O gerenciamento ágil de projetos com Scrum deriva de boas 
práticas de negócios em empresas como Fuji-Xerox, Honda, 
Canon e Toyota. Uma forma de minimizar a distância física 
em uma equipe distribuída é o apoio ferramental adequado, 
que viabilize a execução de práticas ágeis de forma distribuída, 
sem comprometer a comunicação e colaboração do time.
Motivada por este cenário, uma ferramenta de código aberto 
foi desenvolvida por um aluno do mestrado profissional do 
Cesar e evoluída por alunos de mestrado da UFPE, denomina-
da FireScrum. Essa ferramenta visa apoiar muitas das práticas 
definidas pelo Scrum, permitindo que o processo seja seguido 
e monitorado remotamente. Além disso, em algumas práticas o 
FireScrum provê formas de comunicação oral e textual, intera-
ção e colaboração entre os membros de equipes distribuídas.
Inserido neste contexto, este artigo apresenta uma forma 
de suportar a execução de práticas de acompanhamento de 
projetos ágeis distribuídos, mais especificamente a reunião 
diária (ou Daily Meeting) adotada pelo Scrum. Neste sentido, 
o objetivo principal deste trabalho é definir uma abordagem 
para tratar o Daily Meeting distribuído e propor um ambiente 
integrado à ferramenta FireScrum. Esse ambiente tem como 
finalidade apoiar equipes distribuídas na realização da reunião 
diária, possibilitando também o armazenamento de informa-
ções relevantes dessas reuniões. A seção Uma abordagem para 
tratar o Daily Meeting distribuído descreve em detalhes como 
esse apoio pode ser realizado.
Desenvolvimento de software distribuído
Atualmente, com a globalização e a crescente demanda por 
novos sistemas, as empresas se depararam com a necessidade 
de estudar novas formas para alcançar alta produtividade. 
Uma opção investigada para alcançar esses objetivos foi o 
desenvolvimento distribuído de software (DDS). O DDS con- 
siste no desenvolvimento de software com pessoas distribuí-
das em diferentes localidades. Estes locais podem ser bairros, 
cidades ou mesmo países diferentes. Ele permite que diversas 
pessoas trabalhem em lugares diferentes, como uma única 
equipe no intuito de desenvolver software mais rápido do 
que o habitual.
Além disso, alguns motivos são responsáveis pela crescente 
adoção do DDS, conforme descrito por French [5]. Em seu 
estudo, French menciona que a distribuição é, muitas vezes, 
uma consequência inevitável de fatores organizacionais. Os 
principais fatores identificados durante o estudo foram os 
seguintes:
• Os membros não podem ou não querem se mudar para outra 
localidade;
• Os membros especializados necessários para o sucesso do 
projeto estão em localidades diferentes;
• O custo da viagem ou mudança é alto;
• Reduzir o custo do espaço físico em determinado local.
Além disso, a demanda por novos sistemas estão crescendo 
mais rapidamente do que os recursos profissionais em alguns 
locais, e alguns tipos de especialidades são difíceis de serem 
encontrados.
Além dos fatores organizacionais já mencionados, o desen-
volvimento distribuído traz algumas vantagens competitivas 
para a solução global, tais como reduzir o tempo de entrega 
através de equipes distribuídas que trabalham em paralelo, 
e da possibilidade delas desenvolverem em diversos fusos 
horários. A redução de custos também pode ser alcançada 
porque contratar profissionais de diferentes países é muitas 
vezes mais barato do que os do mesmo local.
No entanto, esta abordagem também tem algumas desvanta-
gens. French menciona que, devido à natureza distribuída dos 
projetos, muitas vezes pode ser difícil ter reuniões regulares 
face-a-face. Este é um grande problema porque essas reuniões 
ajudam os membros a se conhecerem e a construir um bom 
relacionamento entre eles. Além disso, a relação face-a-face 
permite que os membros interajam mais para ajudar um ao 
outro em favor do projeto. Outro problema é a viagem para 
reuniões em outras localidades, que é caro e cansativo. Assim, 
esses problemas são responsáveis muitas vezes por um pro-
gresso mais lento ou até ao fracasso do projeto [6].
Deste modo, existem alguns desafios enfrentados pelas 
equipes distribuídas em termos de comunicação e colaboração, 
tais como: (1) atraso na resposta e resolução de problemas; (2) 
ausência de confiança entre os membros da equipe; (3) falta 
Edição 29 - Engenharia de Software Magazine 9 
AGILIDADE
de transparência sobre o progresso da equipe 
e atividades atribuídas; (4) falta de informações 
adequadas para os desenvolvedores quando 
ocorre alguma mudança, por exemplo, quando 
um membro necessita saber quem poderia ajudá-
lo em determinada mudança. No intuito de lidar 
com estes desafios, o gerente do projeto precisa de 
um esforço maior para lidar com tais problemas, 
sendo responsável por transmitir os progressos e 
os problemas que ocorrerem entre as equipes de 
diferentes localidades.
Também são necessárias duas mudanças para 
enfrentar esses problemas. Em primeiro lugar, 
uma ferramenta para auxiliar os membros a inte-
ragir mais através de uma comunicação síncrona e 
assíncrona distribuída entre os locais. Em segundo 
lugar, uma infraestrutura de colaboração para per-
mitir a colaboração síncrona com mais frequência 
entre os membros distribuídos. Como resultado, 
estas mudanças proporcionariam: (1) uma resposta 
mais rápida, diminuindo o tempo de resolução 
sobre as questões que envolvem a comunicação 
entre as equipes distribuídas; (2) aumento da 
produtividade da equipe, o senso de equipe e a 
motivação dos membros como um todo [4].
Na seção seguinte será discutido como esses pro-
blemas são abordados pelo desenvolvimento ágil.
Desenvolvimento Ágil Distribuído
O DDS não restringe seu uso a nenhuma metodo-
logia de desenvolvimento, tendo sido adotado por 
várias empresas nos últimos anos. As metodologias 
tradicionais já foram adotadas por muitos projetos 
distribuídos e muitos deles falharam devido a 
algumas das razões mencionadas na última seção. 
Lee [9] relata a experiência da aplicação da metodo-
logia tradicional em um dos projetos distribuídos, 
chamado Zorro. Segundo o relato, o projeto falhou 
devido a problemas como a falta de planejamento e 
comunicação entre as equipes globais e as equipes 
locais, a baixa prioridade de projetos locais e a falta 
de experiência, além de gestores locais responsáveis 
por várias funções.
Pelos problemas enfrentados com osmétodos 
tradicionais, muitas empresas passaram a adotar 
metodologias ágeis para amenizar esses proble-
mas. Lee descreve que no projeto seguinte, Cha-
meleon, o Yahoo decidiu adotar o Scrum e XP, con-
seguindo assim eliminar muitos dos problemas. 
O primeiro, de planejamento e comunicação, foi 
resolvido pela prática do Sprint Planning Meeting 
do Scrum e as reuniões entre os Scrum Master de 
cada equipe, chamada de Scrum de Scrums. O 
segundo problema foi resolvido pela priorização 
das funcionalidades baseado no valor agregado ao 
negócio (Business Value ou BV), ou no retorno sobre o investimento (ROI) 
mais elevado. Já o último problema foi contornado com a criação do papel 
do Scrum Master nas equipas locais, que passaram a ser responsáveis 
pelos impedimentos de seu backlog e a interação com outras equipes 
distribuídas através do Scrum de Scrums.
Lee menciona que projeto Zorro, que utilizou metodologias ágeis, teve 
um aumento de desempenho e satisfação do projeto de mais de 30% 
quando comparado com o projeto Chameleon, que utilizou metodologia 
tradicional.
Esta vantagem competitiva alcançada pelo uso de métodos ágeis tem 
feito muitas empresas começarem a usar metodologias ágeis juntamente 
com o desenvolvimento distribuído, obtendo um ambiente menos buro-
crático, com foco principal na comunicação e entrega rápida ao cliente. 
Outro caso de sucesso foi descrito por Sutherland [13], que menciona a 
experiência adquirida e os problemas surgidos, dando ênfase na comu-
nicação como um ponto chave em uma equipe distribuída. De acordo 
com Sutherland, a comunicação foi abordada no projeto através do Daily 
Meeting, compartilhamento de informação entre as equipes e o Sprint 
Planning Meeting. Estas reuniões foram realizadas utilizando videocon-
ferência por Skype.
A comunicação é um grande problema no gerenciamento do Product 
Backlog, na interação entre os membros, e na distribuição e compartilha- 
mento de informações. Apesar dos problemas, a comunicação e a 
10 Engenharia de Software Magazine - Acompanhamento de projetos ágeis distribuído através do Daily Meeting
colaboração entre os membros são mais bem tratados pelas 
metodologias ágeis do que pelos métodos tradicionais. Su-
therland [13] menciona que o uso de métodos tradicionais 
neste cenário distribuído tem mais problemas relacionados 
com a comunicação, porque as empresas tendem a fazer 
especificações mais detalhadas, levando um longo tempo 
antes de iniciar o projeto. Ele relata também dos problemas 
com o planejamento do projeto, devido à dificuldade que a 
equipe teve em seguir o que foi planejado, uma vez que este 
era detalhado e mais estático. Essa falta de flexibilidade faz 
com que os projetos apresentem uma alta taxa de falhas ou 
atrasos na entrega.
Neste cenário, Sutherland [14] descreveu que a equipe 
distribuída pode ser organizada em três modelos diferentes, 
apresentados a seguir:
• Scrums Isolados – as equipes são isoladas entre as locali-
dades. Em alguns casos, alguns times não usam Scrum, o 
que torna difícil a gestão do projeto;
• Scrum de Scrums Distribuídos – equipes Scrum são iso-
ladas em diferentes localidades e são integradas através do 
Scrum de Scrums. Scrum de Scrums é um encontro entre 
os Scrum Masters de cada equipe que ocorre diariamente 
(muitas vezes semanalmente) para verificar o progresso e 
os problemas entre as equipes distribuídas;
• Scrums Totalmente Integrados – equipes Scrum são 
formadas por membros de especialidades distintas, e em 
localidades diferentes. 
Dentre os modelos, o mais recomendado pela Scrum 
Alliance é o Scrum de Scrums Distribuídos. Este modelo 
de trabalho é adequado para equipes com diferentes espe-
cialidades que adotam Scrum e são isoladas, eliminando a 
maioria das dependências entre as equipes.
No Scrum de Scrums Distribuídos cada equipe tem um 
Scrum Master, que monitora diariamente o progresso de 
seus membros. Além disso, eles muitas vezes se reúnem 
através do Scrum de Scrums, sendo possível discutir pro-
blemas do projeto como um todo e sincronizam as questões 
que podem afetar as outras equipes. Assim, esse modelo in-
centiva uma maior comunicação e colaboração entre equipes 
distribuídas, fazendo com que trabalhem como uma equipe 
única em prol do projeto, e ajuda a promover uma rápida 
resolução de problemas entre as equipes.
Daily Meeting Distribuído
A adoção do Scrum por equipes distribuídas visa facilitar a 
comunicação entre os membros devido a certas práticas, tais 
como as Scrum Meetings, e especialmente o Daily Meeting. 
Estas reuniões ajudam as equipes a interagir mais e envol-
ver-se como uma equipe única para completar as tarefas, 
aumentando assim o compromisso de alcançar o objetivo 
da Sprint. No entanto, há uma dificuldade de sincronizar as 
atividades entre os membros de equipes distribuídas, bem 
como nos mecanismos de comunicação. Estes problemas 
foram encontrados no projeto relatado por Sutherland [14].
De acordo com Sutherland, o primeiro grande desafio é o 
gerenciamento de projetos, particularmente a sincronização 
entre as equipes distribuídas. Essa sincronização aconteceu 
pela realização do Daily Meeting por cada equipe distribuída. 
O segundo desafio é a comunicação entre as equipes, que foi 
tratado pelo Daily Meeting distribuído entre as equipes.
O Daily Meeting distribuído era necessário para que as 
equipes distribuídas acompanhassem juntas o progresso do 
projeto. Sutherland descreveu como a reunião ocorria diaria-
mente. Devido às diferenças de fuso horário, escolheu-se um 
horário onde todos os membros estariam presentes. A fim de 
evitar problemas relacionados à falha na comunicação oral, as 
equipes determinaram que cada membro deveria responder às 
perguntas por escrito antes da reunião começar. Isso encurta 
o tempo necessário para a teleconferência e ajuda a superar as 
barreiras da língua, facilitando o entendimento entre as pes-
soas. Após responderem as questões, os membros se reuniam 
usando teleconferência (geralmente por Skype) para discutir 
as questões.
Além da reunião diária entre as equipes, as subequipes de 
cada localidade tinham um Daily Meeting adicional no início 
do dia. O Scrum de Scrums também era realizado uma vez por 
semana para coordenar as tarefas entre as subequipes.
Esta experiência relatada por Sutherland possibilitou identi-
ficar problemas como as diferenças de fuso horário, comunica-
ção entre os membros, Daily Meeting locais, Scrum de Scrums 
e, também, a importância de responder as perguntas diárias 
antes de começar a reunião. A análise de como esses desafios 
foram resolvidos ajudou a propor uma abordagem para melhor 
apoiar as equipes distribuídas e a verificar que elas precisam 
de uma ferramenta para realizar essas reuniões virtuais.
Ferramentas para apoio ao Daily Meeting
Nesta seção serão discutidas as ferramentas de apoio às 
equipes durante o Daily Meeting distribuído.
Assembla
Assembla é uma ferramenta de gerenciamento ágil de proje-
tos baseado no Scrum que permite criar Sprints, criar as estó-
rias e associá-las a uma Sprint, assim como criar as tarefas. Ela 
também permite que os membros acompanhem o progresso 
das tarefas através do suporte ao Daily Meeting.
Para apoiar o Daily Meeting, a ferramenta tem um espaço 
no qual o usuário pode preencher as respostas referentes às 
três perguntas da reunião diária e ver as respostas de outros 
membros. As respostas são registradas para criar um histórico 
com o trabalho realizado pela equipe todos os dias. A fim de 
lembrar a equipe para responder à pergunta, um e-mail de 
alerta é enviado em um horário agendado. A ferramenta tam-
bém fornece um chat para permitir que os desenvolvedores 
discutam entre eles sobre os impedimentos.
Desse modo, Assembla fornece comunicação assíncrona 
baseada na resposta das três questões e comunicação sín-
crona atravésdo chat; ambas ajudam os membros durante o 
Daily Meeting. No entanto, esta solução não oferece recursos 
Edição 29 - Engenharia de Software Magazine 11 
AGILIDADE
multimídia interessantes, tais como vídeo-conferência. Outro 
recurso importante que a solução não oferece é o Taskboard 
para ajudar a equipe a monitorar o status da tarefa, e também 
não exibe o gráfico de Sprint Burndown aos membros, o que 
permitiria acompanhar o andamento do projeto ao longo da 
Sprint.
ScrumWorks
ScrumWorks é um software de gestão ágil de projetos que 
tem duas licenças, diferenciadas pelo número de recursos 
oferecidos. A primeira licença é o Basic ScrumWorks, que 
prevê apenas o gerenciamento do projeto, das Sprints e alguns 
relatórios. A segunda licença, o ScrumWorks Pro, fornece um 
conjunto mais completo de funcionalidades que permite aos 
membros gerenciar os usuários, o acesso a diferentes tipos de 
relatório, o acesso ao quadro de horários (Timesheet), e usar 
um Taskboard drag-and-drop.
No entanto, esta ferramenta não fornece um ambiente para 
reunião diária. Ele só possui o Taskboard, que permite aos 
membros da equipe monitorar o progresso das tarefas, e não 
possui recursos de colaboração, tais como vídeo-conferência, 
o que permitiria aos membros interagir em torno do Task-
board, apoiando assim a discussão sobre as três questões da 
reunião diária.
VersionOne
VersionOne é uma ferramenta de gestão de projetos que apoia 
algumas metodologias de desenvolvimento ágil, tais como 
Scrum, XP, Kanban, AgileUP e DSDM.
Esta ferramenta permite que a equipe planeje e gerencie as 
estórias e os objetivos de vários projetos, produtos e Sprints. Ela 
também permite adicionar à Sprint, estórias, defeitos, tarefas, 
testes e impedimentos, além de possibilitar que a equipe acom-
panhe o andamento do projeto usando Storyboard, Taskboard, 
Testboard e Burndown charts.
Embora a ferramenta forneça e compartilhe informações 
importantes para a reunião diária, tais como o TaskBoard e o 
Burndown, estas informações não são atualizadas em tempo 
real, ou seja, quando um membro atualiza o status de uma ta-
refa, essa alteração não aparece no Taskboard de outro membro 
no mesmo espaço de tempo. Isto é um empecilho para equipes 
distribuídas fazerem uma reunião diária síncrona. Portanto, 
esta solução não fornece um ambiente para os membros se 
reunirem todos os dias e discutir o andamento do sprint.
TargetProcess
TargetProcess também é um software integrado de gestão 
de projetos que apoia todas as atividades de desenvolvimento 
Scrum. Ele permite criar estórias, priorizar o Product Backlog, 
e seguir o progresso das tarefas através do TaskBoard e do 
gráfico Sprint Burndown.
Esta solução é web e ajuda a integrar as equipes distribuídas 
de modo que trabalhem juntas em um único projeto. O Task-
board apoia a reunião diária através da atualização do status 
das tarefas em tempo real pelos seus membros. No entanto, 
ele não tem um ambiente para organizar a equipe em uma 
reunião e não permite que os membros se comuniquem, a 
fim de proporcionar uma melhor interação entre eles usando 
o Taskboard.
Desta forma, esta solução é limitada para ser usada durante 
a reunião diária, uma vez que não tem os recursos necessários 
para integrar os membros e permitir que eles interajam sobre 
as três perguntas de acompanhamento. 
FireScrum
O FireScrum é uma ferramenta código livre de gerenciamen-
to ágil de projetos focada no Scrum. Foi desenvolvida com o 
objetivo de apoiar equipes distribuídas, motivada por lacunas 
nas propostas semelhantes (ScrumWorks, TargetProcess, 
VersionOne, Assembla). A ferramenta foi desenvolvida por 
alunos de Engenharia de Software da Universidade Federal 
de Pernambuco. A fim de facilitar o uso, a ferramenta foi pro-
jetada para que os membros trabalhem de forma semelhante 
a um ambiente físico. O Taskboard foi concebido como um 
quadro branco eletrônico, permitindo o uso de post-its para 
criar tarefas, e movê-los através das colunas do Taskboard, 
alterando assim o seu status. Outra preocupação foi a interação 
face-a-face defendida pelas metodologias ágeis, o que exigiu 
a utilização de recursos multimídia, possibilitando maior 
interação entre os membros remotos, mas que no entanto só 
está disponível no módulo Planning Poker.
O FireScrum é uma aplicação web, o que significa que é 
acessível remotamente através de um browser via Internet ou 
Intranet, e possui interfaces simples para o uso baseado nos 
conceitos de Rich Internet Applications (RIA), provendo maior 
usabilidade ao usuário. A ferramenta foi desenvolvida com 
uma arquitetura modular de modo facilitar a manutenção e 
extensão, permitindo adicionar novas funcionalidades.
Na versão atual do FireScrum, o apoio dado ao Daily Meeting 
é através do Taskboard atualizável em tempo real. No entanto, 
exige que os membros definam um horário para a reunião e 
se encontrem todos os dias em frente ao Taskboard. Durante 
a reunião cada membro deve alterar o status das tarefas refle-
tindo as três perguntas diárias. Entretanto, essa solução não 
permite que os membros interajam, uma vez que o Taskboard 
não possui comunicação escrita (por chat) nem oral (por vide-
oconferência). A ferramenta também não permite controlar a 
duração da reunião, e não possibilita que os membros vejam 
ao mesmo tempo outras informações necessárias, tais como o 
Sprint burndown para acompanhar o andamento do projeto. 
Conclusões sobre as ferramentas
Com base nos problemas enfrentados por equipes distribu-
ídas, conforme discutido nas últimas seções, e na análise das 
ferramentas atuais que adotam Scrum, tem-se observado a 
falta de ferramentas que apóiem o Daily Meeting distribuído. 
As ferramentas apenas fornecem o Taskboard ou um espaço 
para os membros de forma assíncrona responderem às três 
perguntas. Esta ausência pode estar relacionada ao fato do 
Scrum enfatizar o trabalho da equipe no mesmo espaço físico 
12 Engenharia de Software Magazine - Acompanhamento de projetos ágeis distribuído através do Daily Meeting
e não mencionar como essa reunião deve ser tratada num 
cenário distribuído. 
A Tabela 1 mostra um conjunto de recursos importantes 
identificados a partir dos problemas discutidos nas últimas 
seções, de modo a auxiliar as equipes distribuídas nas reu-
niões diárias.
Estas lacunas identificadas na Tabela 1 ajudaram a definir a 
abordagem proposta e discutida na próxima seção e também 
a criar um questionário para coletar a opinião de pessoas que 
vivenciaram projetos distribuídos. O questionário aplicado 
possuía perguntas sobre quais os problemas enfrentados du-
rante o projeto, e avaliava a importância dos recursos propostos 
na Tabela 1 em uma solução para amenizar os problemas 
durante o Daily Meeting distribuído. O resultado do questio-
nário pode ser acessado pelo link: https://spreadsheets.google.com/
gform?key=0Asx_k1VExGmFdDJvZUh3UTRTc2lTUmx5UUhX
aEg3TUE&hl#chart. Até o momento 38 pessoas responderam, 
dentre eles, alunos da UFPE e profissionais do ramo. 
Uma abordagem para tratar o Daily Meeting 
distribuído
O desenvolvimento dos módulos do FireScrum foi realizado de 
forma distribuída organizada em seis equipes. A experiência da 
implementação de um dos módulos, Planning Poker, foi relatada 
durante o Workshop Brasileiro de Métodos Ágeis [16]. Através 
deste relato foram levantados vários problemas enfrentados 
durante as reuniões diárias. O primeiro deles foi a dificuldade 
no agendamento da reunião, que ocorria normalmente por e-
mail. Alinhado a isso, existia o problema de os membros não 
se lembrarem de comparecer à reunião no horário combinado, 
além também da incompatibilidade do horário entre todos os 
membros, de modo que alguns deles não podiam comparecer e 
enviavam as respostas das três perguntas por e-mail, causando 
a faltade controle das respostas enviadas.
Outro problema enfrentado durante o desenvolvimento do 
Planning Poker foi a falta de integração entre as ferramentas 
de comunicação (por exemplo, Skype) e ferramentas para ge-
renciamento ágil de projetos (por exemplo, FireScrum). Esta 
combinação permite um melhor acompanhamento da reunião, 
visualizando os detalhes do projeto em tempo real por todos 
os membros e possibilita que os membros se comuniquem 
através de chat ou vídeo-conferência.
Estes problemas discutidos possivelmente ocorreram de for-
ma semelhante em outros projetos distribuídos, tais como os 
relatados por [13][9][18], uma vez que eles descreveram que o 
Skype foi utilizado para a reunião diária e não foi mencionado 
nenhuma ferramenta específica de apoio. Assim, esta aborda-
gem foi proposta visando amenizar os problemas enfrentados 
na experiência anterior e levantados no tópico Conclusões 
sobre as ferramentas.
A abordagem consiste num conjunto de subpráticas que 
podem ser adotadas pelos membros de equipes distribuídas 
de modo a tratar os principais pontos discutidos. Desta forma, 
inicialmente, a abordagem define a necessidade de o Scrum 
Master agendar o horário da reunião e definir quantos minu-
tos antes de começar o encontro um e-mail será enviado para 
os membros, a fim de lembrá-los da reunião. Esse lembrete 
deve ser enviado de preferência 20 minutos antes, para permi-
tir que os membros respondam previamente às três questões 
de acompanhamento. A resposta prévia das perguntas é im-
portante por uma série de razões, dentre elas: o fato de que 
alguns membros não podem comparecer à reunião; e ajudar 
a superar a barreira da língua durante a comunicação oral 
entre os membros de diferentes localidades.
Essa abordagem também sugere que os membros com-
partilhem informações importantes em tempo real sobre o 
projeto, como o Taskboard e Sprint Burndown. O primeiro, o 
Taskboard, é importante pois permite que os membros atua-
lizem o status de suas atividades, definam as atividades que 
eles irão realizar e informem se tiveram algum impedimento. 
Já o Sprint Burndown auxilia os membros a acompanhar o 
andamento do projeto. Alinhado a isso, é necessário fornecer 
recursos que permitam que os membros se comuniquem, tais 
como áudio, vídeo e chat. O áudio e o vídeo são importantes 
para que os membros conheçam o rosto e a voz das pessoas 
com as quais estão trabalhando remotamente, ajudando a 
Assembla ScrumWorks VersionOne TargetProcess FireScrum
Agendamento da reunião
Envio de lembrete aos usuários X
Preenchimento das três perguntas antes de começar a reunião X
Controle da duração da reunião
Salvar e recuperar informações da reunião
Comunicação Síncrona (Ex: chat ou videoconferência) X X
Comunicação Assíncrona X X
Taskboard ou TaskView X X X X
Taskboard atualizável em tempo real X X X
Geração do Sprint Burndown X X X X
Ambiente integrado a uma ferramenta de gerenciamento ágil de projetos
Tabela 1. Recursos para ajudar as equipes distribuídas nas reuniões
Edição 29 - Engenharia de Software Magazine 13 
AGILIDADE
criar um senso de equipe. E o chat é im-
portante para eventuais problemas da 
comunicação oral, seja por problemas 
tecnológicos (ex: velocidade da rede), 
bem como pelo problema de entendi-
mento entre os membros de diferentes 
localidades, como já mencionado.
No intuito de prover maior interação 
na equipe, os membros necessitam de 
um mecanismo que permita destacar (ou 
apontar) para os outros algum detalhe 
das informações compartilhadas, como se 
tivessem usando a própria mão em uma 
reunião presencial. Outro fator importante 
é o controle do tempo, uma vez que o 
encontro deve ser breve para evitar que a 
reunião perca o foco e alguém da equipe 
deixe de comparecer nos próximos dias. 
Além disso, para evitar o desperdício de 
tempo, o Scrum Master deve definir antes de começar a reunião 
a ordem que os membros irão falar.
Um último ponto definido pela abordagem proposta é a im-
portância de salvar as informações do encontro, como o chat, 
o áudio, o vídeo e as respostas das três perguntas respondidas 
pelos membros. Isso permite manter o histórico, possibilitando 
que os membros que não puderam comparecer à reunião pos-
sam se manter informados sobre o andamento do projeto.
A abordagem proposta definiu, portanto, um conjunto de subprá-
ticas no intuito de auxiliar o Daily Meeting distribuído. Entretanto, 
para atender cada uma delas, é necessário um ambiente integrado 
para auxiliar na realização destas reuniões, como descrito a seguir.
Ferramenta
A fim de apoiar a abordagem proposta, um ambiente para 
as reuniões diárias foi desenvolvido com o objetivo de apoiar 
todas as subpráticas descritas. Ele foi integrado ao FireScrum 
por ser uma ferramenta de gerenciamento ágil de projetos e 
oferecer recursos como Taskboard atualizável em tempo real 
e geração do Sprint Burndown, evitando assim criar uma nova 
ferramenta apenas para a reunião diária e ter outra para ge-
renciamento de projetos. Os principais requisitos endereçados 
pelo ambiente foram:
• Agendamento da reunião;
• Envio de lembrete por e-mail minutos antes da reunião 
começar;
• Permitir que os membros respondam as três perguntas 
previamente;
• Integrar o ambiente à ferramenta FireScrum;
• Permitir a comunicação oral e textual entre os membros;
• Compartilhamento de informações em tempo real através 
do Taskboard e do Sprint Burndown;
• Controle da duração das reuniões;
• Controle da duração da vez de cada membro falar;
• Controle da ordem dos membros que irão falar durante a 
reunião;
• Salvar e recuperar as informações da reunião, criando assim 
um histórico e permitindo que membros que não comparece-
ram à reunião possam visualizar o que aconteceu nela; 
• Permitir maior interação entre os membros criando um 
mouse para cada um no ambiente. Deste modo é possível que 
o membro interaja com o ambiente e aponte algum detalhe 
nas informações compartilhadas que ele queira que os outros 
prestem atenção;
• Exibir a lista de tarefas mostrando o responsável pela tarefa 
e o status dela.
Para atender os requisitos, o ambiente foi separado em três 
telas. A primeira é a de Configurações, que permite ao Scrum 
Master definir a ordem em que os membros irão falar, o tempo 
de duração da reunião, e definir os recursos que poderão ser 
utilizados na reunião (ex: habilitar ou desabilitar o chat, áudio/
vídeo, controle de tempo). A segunda tela é a principal, onde 
ocorre a reunião (ver Figura 1). E a última tela apresenta o 
histórico das reuniões anteriores que foram gravadas.
A Figura 1 exibe alguns dos recursos disponibilizados como 
áudio, vídeo e chat, as respostas das três questões e a lista de 
tarefas atribuídas a cada membro. O ambiente possui também 
uma aba para visualizar o Sprint Burndown, um botão para 
abrir o Taskboard, e no canto superior direito fica o controle 
do tempo e a vez do membro que está falando. 
O ambiente desenvolvido melhora o apoio às equipes distri-
buídas, que poderão usar uma única ferramenta, o FireScrum, 
para gerenciar projetos e realizar o acompanhamento diário 
do mesmo. 
Apesar de não ter sido ainda validado, o questionário ajudou 
a verificar a aceitação dos requisitos endereçados no ambiente. 
A maioria destes requisitos obteve uma aceitação acima dos 
60%. Dentre os itens com votos mais altos estão os recursos 
de comunicação e o compartilhamento de informações atra-
vés do Burndown e Taskboard, os quais atingiram taxas de 
Figura 1. Ambiente do Daily Meeting
14 Engenharia de Software Magazine - Acompanhamento de projetos ágeis distribuído através do Daily Meeting
quase 80% de aceitação. Os que obtiveram votos com menor 
aceitação foram: o armazenamento das informações da reu-
nião e a criação do mouse para cada usuário, que obtiveram 
uma aceitaçãopróxima dos 60%. Dessa forma, espera-se que 
o ambiente auxilie as equipes distribuídas ao prover um local 
virtual para se reunirem todos os dias.
Conclusão
Com a crescente adoção do desenvolvimento ágil distribuído, 
as empresas começaram a enfrentar outros desafios na gestão 
de projetos devido a problemas de comunicação e colaboração 
entre os membros da equipe. A utilização de um método ágil 
como o Scrum ameniza esses problemas, uma vez que as práticas 
definidas sugerem maior interação entre os membros, maior en-
volvimento do cliente, e feedback rápido com entregas periódicas 
num curto espaço de tempo. Entretanto, como ele enfatiza que 
as equipes devem trabalhar no mesmo espaço físico, o Scrum 
não define como a metodologia deve ser tratada em um cenário 
distribuído.
Um ponto não abordado quando a equipe é distribuída é a reu-
nião diária. A realização desta reunião de forma eficaz permitiria 
evitar os principais problemas de gestão, possibilitando que os 
membros se comuniquem e interajam diariamente, fornecendo 
feedback rápido sobre o andamento das atividades e do surgimen-
to de impedimentos. Como discutido na seção sobre Ferramentas 
para apoio ao Daily Meeting, apesar da importância das reuniões 
diárias, ele não é tratado adequadamente pelas ferramentas atuais 
de gerenciamento ágil de projetos, pois só fornecem o Taskboard 
ou um espaço para os membros, de forma assíncrona, responde-
rem às perguntas.
Assim, a fim de tratar o Daily Meeting distribuído, a aborda-
gem proposta neste artigo define algumas práticas de modo a 
auxiliar as equipes a organizar, gerenciar e realizar tais reuniões. 
Ela começa enfatizando a importância das reuniões ocorrerem 
em um horário agendado pelo Scrum Master, e a necessidade 
do envio de um lembrete para todos os membros da equipe 
alertando sobre a reunião. Para o melhor acompanhamento do 
projeto é imprescindível o compartilhamento de informações do 
projeto em tempo real entre os membros, tais como o Taskboard 
e o Sprint Burndown, e ainda a visualização das respostas de 
cada membro referente às três perguntas diárias. Entretanto, a 
reunião se torna efetiva se disponibilizadas diversas formas de 
comunicação síncrona, tanto oralmente (ex: videoconferência) 
quanto por escrito (ex: chat).
De modo a dar suporte às práticas definidas, foi desenvolvido 
um ambiente integrado à ferramenta de gerenciamento ágil de 
projetos FireScrum. O FireScrum foi escolhido por ser código 
livre, ter uma arquitetura modular e fornecer os recursos necessá-
rios para o ambiente, como o TaskBoard e o Sprint Burndown.
Assim sendo, este artigo descreveu como adaptar para um am-
biente distribuído uma das práticas do Scrum, o Daily Meeting. 
Além disso, discutiu como as ferramentas atuais dão suporte a 
essa prática, e apresentou um ambiente que fornece uma sala 
virtual para que as equipes possam se reunir todos os dias. 
Dê seu feedback sobre esta edição!
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
Para isso, precisamos saber o que você, leitor, acha da revista!
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback
D
ê 
se
u Fe
edback
so
b
re esta edição
Beck, Kent et al. Manifesto for agile software development. Fev. 2001. Disponível em http://www.
agilemanifesto.org. 
Boehm, Barry.A view of 20th and 21st century software engineering. ICSE ‘06: Proceedings of the 28th 
international conference on Software engineering. 2006.
Cavalcanti, Eric; Maciel, Teresa; Albuquerque, Jones. Ferramenta OpenSource para Apoio ao Uso do 
Scrum por Equipes Distribuídas. Workshop de Desenvolvimento Distribuído de Software (WDDS). 
2009.
Damian, Daniela; Marczak, Sabrina; Dascalu, Madalina; Heiss, Michael; Liche, Adrian. Using a Real-Time 
Conferencing Tool in Distributed Collaboration: An Experience Report from Siemens IT Solutions and 
Services. ICGSE ‘09: Proceedings of the 2009 Fourth IEEE International Conference on Global Software 
Engineering. 2009.
French, A.; Layzell, P.A Study of Communication and Cooperation in Distributed Software Project 
Teams. ICSM ‘98: Proceedings of the International Conference on Software Maintenance. 1998.
Herbsleb, James D.; Moitra, Deependra. Guest Editors’ Introduction: Global Software Development. 
IEEE Software. 2001.
Highsmith, Jim Agile Project Management - Creating Innovative Products. Pearson Education. 2004.
Karolak, Dale Walter.Global Software Development: Managing Virtual Teams and Environments. IEEE 
Computer Society Press. 1999.
Lee, Seiyoung; Yong, Hwan-Seung. Distributed agile: project management in a global environment. 
Empirical Software Engineer. 2010.
Dubakov, Michael; Stevens, Peter. TargetProcess. Agile Tools. The Good, the Bad and the Ugly. http://
www.targetprocess.com/download/whitepaper/agiletools.pdf. 2008.
ScrumWorks. ScrumWorks Pro 4. http://www.danube.com/docs/ ScrumWorks_Pro_Datasheet.pdf. 
2009.
Singleton. Accelerate with a Daily Scrum. Assembla. http://blog.assembla.com/assemblablog/
tabid/12618/bid/2424/Accelerate-with-a-Daily-Scrum.aspx. 2007.
Sutherland, Jeff; Schoonheim, Guido; Rustenburg, Eelco; Rijk, Maurits. Fully Distributed Scrum: The 
Secret Sauce for Hyperproductive Offshored Development Teams. Agile 2008 Conference. 2008.
Sutherland, Jeff; Viktorov, A.; Blount, J.; Puntikov, N. Distributed Scrum: Agile Project Management 
with Outsourced Development Teams. Hawaii International Conference on Software Systems, Big 
Island, Hawaii. 2007.
Takeuchi, Hirotaka; Nonaka, Ikujiro. The New New Product Development Game. Harvard Business 
Review. 1986.
Chalegre, Virgínia C.. Santos, Wylliams B.; Souza, Leandro O.; Munoz, Hernan J.; Meira, Silvio R. L. Estudo 
de Caso da Utilização de Scrum no Desenvolvimento Distribuído de Software. Conferência Brasileira 
sobre Métodos Ágeis de Desenvolvimento de Software. 2010.
Versionone. The State of Agile Development Survey Results. http://www.versionone.com/
pdf/3rdAnnualStateOfAgile_FullDataReport.pdf. 2008.
Williams, Wes; Stout, Mike. Colossal, Scattered, and Chaotic (Planning with a Large Distributed Team. 
AGILE Conference. 2006.
Referências
Edição 29 - Engenharia de Software Magazine 15 
João Caldas Júnior 
caldasjr@gmail.com
Possui mestrado em Ciências da Compu-
tação e Matemática Computacional pela 
Universidade de São Paulo. Atualmente 
trabalha como consultor de TI e é profes-
sor da Fundação Salvador Arena em São 
Bernardo do Campo-SP. Possui experiência 
em projetos de Engenharia de Software, 
Engenharia de Requisitos e Arquitetura 
Orientada a Serviços na área bancária.
De que se trata o artigo?
Neste artigo veremos os principais aspectos dos re-
quisitos técnicos de projetos SOA, como classificar 
estes requisitos e as características tecnológicas 
mais relevantes de um serviço. 
Para que serve?
Auxiliar na condução da coleta de requisitos técni-
cos de Projetos SOA e na identificação dos recursos 
tecnológicos importantes, prevendo-se o lança-
mento de um programa SOA generalizado para a 
empresa.
Em que situação o tema é útil?
Orienta na obtenção de um processo base para 
a definição da capacidade de planejamento, 
gestão e acompanhamento das soluções tecno-
lógicas em um projeto SOA.
Requisitos em SOA – Parte 2
Levantamento de Requisitos técnicos em SOA
Engenharia
Nesta seção você encontra artigos voltados para testes, processo, 
modelos, documentação, entre outros
No primeiro artigo desta série foi abordado como identificar os primeiros serviços e determi-
nar seus requisitos de negócio em um 
projeto Service-Oriented Architecture 
(SOA). Foram comentadas as principais 
abordagens para identificar serviços, 
assim como foram expostas algumas 
categorias para requisitos de negócios. 
Por fim, discutiu-se um processo simples 
para modelaros requisitos de negócio 
para os serviços identificados. 
Neste artigo, serão explorados diferen- 
tes tipos de soluções tecnológicas que 
precisam ser conhecidas a f im de 
capturar os requisitos técnicos de um 
projeto SOA. Serão apresentadas tam-
bém algumas exigências que devem ser-
vir de base para a captura de requisitos 
técnicos, prevendo-se o lançamento de 
um programa SOA generalizado para 
a empresa. Um programa deste porte 
visa: garantir a escala e o controle dos 
investimentos dentro de um cenário de 
16 Engenharia de Software Magazine - Requisitos em SOA – Parte 2
orçamentos restritivos, permitir uma maior visibilidade dos 
serviços compartilhados e um melhor planejamento e revisão 
da arquitetura.
Por onde começar?
O foco principal em um projeto SOA deveria ser dado às exi-
gências do negócio, porém como a maioria das iniciativas SOA 
acabam sendo lideradas pelas equipes de TI (e não pelas equipes 
de negócio) os requisitos de tecnologia ganham tanta importân-
cia quanto os requisitos de negócio. Dada essa realidade, (e aqui 
não se vai discutir se ela é correta ou não, pois simplesmente é 
a realidade) os grupos de TI, desde o início do projeto, iniciam 
discussões de questões como: a adoção do SOAP e WSDL, o 
uso de Web Services, Universal Description Discovery and 
Integration (UDDI), Enterprise Service Bus (ESBs), e o uso de 
ferramentas de governança em SOA (ver definições detalhadas 
na Nota do DevMan 1). Na prática, a equipe de TI escolhe um 
serviço de negócio a ser usado em uma prova de conceito (POC) 
e concentram-se fortemente na tecnologia que será utilizada 
no desenvolvimento deste POC.Neste ponto vale a pena uma 
reflexão, é preciso cautela na utilização de algumas das soluções 
tecnológicas listadas anteriormente, principalmente no que diz 
respeito a três delas: UDDI, ESB e as Ferramentas de Governan-
ça. Partindo da premissa que os projetos estão no início e que 
algumas soluções necessitam de maturidade, é preciso aprender 
antes de tomar decisões baseadas em folhetos de fornecedores. 
Por exemplo, o UDDI é conceitualmente perfeito, no entanto, 
a sua implantação em um projeto SOA que provavelmente 
iniciará com um pequeno número de serviços e uma base de 
consumidores relativamente limitada, é um exagero. No início, 
é bem mais produtivo gastar tempo na definição de contratos 
WSDL bem estruturados, pois eles darão base às informações 
que serão manipuladas pelos repositórios UDDI. 
A mesma linha de argumento é válida para um ESB. Depen-
dendo da complexidade da solução SOA a ser adotada, um ESB 
pode não ser a melhor solução para o problema. Um ESB deve 
ser usado quando existem diversos sistemas que precisam con-
versar de diversas maneiras e que estão distribuídos em locais 
diferentes (é o caso típico de aplicações em portais web).
O ESB atualmente tornou-se uma poderosa ferramenta de 
propaganda das arquiteturas orientadas a serviços, atuando 
como uma camada de abstração das interfaces dos serviços. 
Por meio do ESB é possível integrar os sistemas, mantendo seu 
encapsulamento e ainda existem ESBs que fazem mais: podem 
até controlar o SLA de um serviço. Todas essas características 
tornam a idéia de ter um ESB muito atraente, porém ele não 
é parte obrigatória de uma arquitetura orientada a serviços. 
Em casos que existem só dois sistemas (ex: Java e .net), é bem 
razoável considerar a possibilidade de usar algo mais simples, 
como o JMS por exemplo.
Finalmente, tem-se uma situação inversa no que diz respeito 
às ferramentas de governança. Em projetos SOA, sejam de pe-
queno ou de grande porte, existe a necessidade de versionar, 
monitorar e gerenciar os serviços de negócio, e esse papel pode 
ser realizado por ferramentas de governança. As ferramentas 
N o t a d o D e v M a n 1
Padronizando os Padrões (Erl [1])
O padrão SOAP é utilizado pelos Web Services e é responsável por definir o 
modelo da troca de mensagens. Para isso utiliza um arquivo XML que define en-
velopes e os nós intermediários da comunicação.
O padrão WSDL é responsável por identificar o protocolo e o endereço no qual 
um serviço está publicado, assim como seus parâmetros de entrada e saída. 
O padrão UDDI permite que os serviços sejam categorizados, porém sem for-
necer uma riqueza de textos para que buscas por um serviço específico sejam 
feitas.
O padrão ESB permite customizações no serviço de mensagens, isto é, ele fun-
ciona como um Mediador. A partir dele é possível fazer validações e roteamento 
de mensagens baseado no conteúdo da mensagem. Um barramento ESB permi-
te um baixo acoplamento entre sistemas visto que um sistema de origem não 
precisa conhecer o sistema de destino. 
de governança atuais cumprem seu papel perfeitamente 
quando aplicadas em pequenos projetos independentes, porém 
quanto maior o tamanho do projeto, maior são os problemas 
com questões como a gerência de mudanças, versionamento e 
a análise de impacto com as ferramentas que estão disponíveis 
hoje. Atualmente estas ferramentas possuem sérias limitações 
em termos de interoperabilidade, performance e escalabilidade 
em ambientes de sistemas SOA de grande porte [2].
Felizmente, nem todas as decisões são difíceis, uma boa 
notícia é que existem tecnologias que já possuem um razoável 
nível de padronização de mercado, seja para projetos iniciais 
(POC) ou projetos já amadurecidos. Tais tecnologias são: os 
Web Services, WSDL e SOAP. Os Web Services (baseados em 
XML) são o tipo de implementação de serviços mais largamente 
aceito e bem sucedido. Este tipo de implementação possui como 
requisitos fundamentais:
• Comunicação via protocolos internet (normalmente HTTP);
• Envio e recebimento de dados formatados como documentos 
XML.
 
A ampla aceitação dos Web Services resultou no surgimento 
de um conjunto de tecnologias suplementares que se tornaram 
um padrão de fato. Assim, ao desenvolver um Web Service 
deve-se considerar o uso de tecnologias que:
• Forneçam uma descrição de serviço que, no mínimo, consista 
de um documento WSDL;
• Sejam capazes de transportar documentos XML utilizando 
SOAP sobre HTTP.
Os Web Services devem ser definidos numa forma consistente 
para que possam ser descobertos e “interfaceados” com outros 
serviços e aplicações. A WSDL é uma especificação W3C que 
fornece a linguagem mais avançada para a descrição de defi-
nições de Web Services. 
Apesar de ter sido inicialmente concebido como a tecnolo-
gia para transpor a brecha entre plataformas baseadas em 
Edição 29 - Engenharia de Software Magazine 17 
ARQUITETUR A ORIENTADA A SERVIÇOS (SOA)
comunicação RPC, o SOAP se tornou um dos mais conhecidos 
formatos de mensagens e protocolo utilizado por Web Servi-
ces baseados em XML. Por este motivo, o acrônimo SOAP é 
referido frequentemente como Service-Oriented Architecture 
(or Application) Protocol (protocolo de arquitetura orientada 
a serviços) ao invés de Simple Object Access Protocol que 
curiosamente é seu nome verdadeiro.
Requisitos Técnicos para um serviço
Esta seção descreve quais são as categorias dos requisitos técni-
cos de um serviço em um projeto SOA. Em um sentido amplo, as 
categorias mais importantes são listadas abaixo, porém o requisito 
primordial para uma empresa, quando se trata de tecnologia 
SOA, é permitir a agilidade nos negócios – também conhecida 
como tolerância a mudanças. Uma empresa que utilize SOA 
com sucesso está sempre evoluindo e permitindo mudanças de 
cenários tecnológicos.
Segurança. A questão de segurança é atualmente a principal 
preocupação das empresas na tomada de decisões em relação a 
implementação de projetos SOA. De acordo com uma pesquisa 
global [4], patrocinada pela CA, 43% dos executivos sênior de TI 
classificam as ameaças à segurança como o item mais crítico na 
implementação de aplicações de SOA e de serviços baseados naWeb. Quem pode acessar o serviço? Quem pode acessar os dados 
de dentro de cada serviço? E como os dados são garantidos em 
uma transmissão entre os serviços? São perguntas que devem ser 
tecnologicamente respondidas assim que um projeto inicia.
Simplicidade. Como alguém que queira utilizar um serviço, 
pode facilmente utilizá-lo? Esta é a pergunta que fica na frontei-
ra entre os requisitos técnicos e os de negócio. Um serviço deve 
ser de fácil invocação, apresentar as funcionalidades esperadas, 
ter um bom tratamento de erros e, geralmente, ser capaz de se 
integrar com outros serviços. O ideal é que uma empresa menos 
madura deva ser capaz de utilizar um serviço sem um grande 
investimento em tecnologia ou grandes mudanças em seus pro-
cessos de negócio. 
Qualidade. Considere a disponibilidade, escalabilidade, confia-
bilidade, entre outras características como fatores de qualidade 
de um serviço. Quais são as consequências de SOA em uma 
perspectiva de negócios? Um aspecto fundamental em arquite-
turas orientadas por serviço é a gerência contínua da qualidade 
em todo o ciclo de desenvolvimento de processos de negócio e 
serviços. A qualidade de software está cada vez mais ancorada 
no atendimento a processos de negócio de ponta a ponta, que é 
traduzido no conceito de governança de TI, que é a chave para 
qualquer projeto SOA de sucesso. 
Em alto nível, a captura destas categorias é um excelente ponto 
de partida. É evidente que cada uma possui um maior detalha-
mento, planejamento, coordenação e gestão de projetos. No entan-
to, a orientação para o tipo de informação que se precisa capturar 
já ajuda a definir os requisitos técnicos fundamentais.
Características tecnológicas de um serviço
Para chegar a um modelo de arquitetura tecnologicamente 
desacoplada entre cliente e serviço, é preciso criar um ambiente 
propício para o compartilhamento e reuso de funcionalidades, 
assim como a composição de funcionalidades nas aplicações. 
Abaixo são apresentadas algumas características tecnológicas 
essenciais a serviços integrados a uma arquitetura.
Serviços são orientados a mensagens. Os serviços são for-
malmente definidos em termos das mensagens trocadas entre 
agentes fornecedores e agentes consumidores. A estrutura 
interna e a implementação são propositalmente abstraídas. 
Logo, existe um limite entre consumidores e fornecedores e 
esse limite representa a fronteira entre a interface pública de 
um serviço e sua implementação interna, privada. O limite 
de um serviço é publicado por meio do WSDL e pode incluir 
declarações que ditam as expectativas sobre o serviço. O cru-
zamento desse limite pode ser considerado uma tarefa cara 
por motivos como:
• O local físico do serviço pretendido pode ser um fator 
desconhecido;
• Os modelos de segurança e de confiança provavelmente 
mudarão a cada cruzamento do limite;
• O empacotamento e a conversão de dados entre as repre-
sentações pública e privada de um serviço podem exigir 
recursos adicionais; alguns deles podem ser externos ao 
próprio serviço;
• Ainda que os serviços sejam criados para durar, as confi-
gurações de serviço são criadas para mudar. Esse fato implica 
que um serviço confiável pode sofrer repentinas quedas de 
desempenho em função de configurações de rede ou de mi-
gração de local físico.
Serviços são autônomos. Os serviços são entidades implan-
tadas independentemente, com versões e gerências próprias. 
Os desenvolvedores não podem fazer suposições em relação 
às distâncias limites de um serviço, visto que essas distâncias 
têm muito mais probabilidade de mudar do que os limites 
propriamente ditos. Por exemplo, os limites do serviço de-
vem ser estáticos para minimizar o impacto da versão para o 
consumidor. Ainda que os limites de um serviço sejam bem 
estáveis, as opções de implantação desse serviço em relação à 
diretiva, ao local físico ou à topologia da rede provavelmente 
mudarão.
Os serviços são tratados dinamicamente por meio de URIs, 
permitindo que seus locais e topologias de implantação mudem 
ou evoluam com o tempo, com pouco impacto em relação ao 
próprio serviço (isso também é válido em relação aos canais 
de comunicação de um serviço). Ainda que essas alterações 
possam ter pouco impacto sobre o serviço, elas podem ter um 
impacto devastador sobre aplicativos que o utilizem. E se um 
serviço que estava sendo usando hoje passar para uma rede 
na Irlanda amanhã? A alteração no tempo de resposta pode 
ter impactos esperados ou inesperados sobre os consumidores 
do serviço. Os designers de serviço devem adotar uma visão 
pessimista sobre o uso dos serviços: os serviços falharão e seus 
comportamentos associados (níveis de serviço) estarão sujeitos 
à mudança. Níveis apropriados de tratamento de exceções e 
de lógica de compensação deverão ser associados a qualquer 
18 Engenharia de Software Magazine - Requisitos em SOA – Parte 2
invocação de serviço. Além disso, consumidores de serviço 
podem precisar modificar suas diretrizes para declarar 
tempos de resposta mínimos de serviços a serem utilizados.
Os consumidores de serviço não são os únicos que devem 
adotar visões pessimistas do desempenho: os provedores de 
serviço devem ser da mesma forma, pessimistas ao antecipar 
como seus serviços serão utilizados. Deve-se esperar que os 
consumidores de serviço falhem, algumas vezes sem notifi-
car o próprio serviço. Os provedores de serviço também não 
podem confiar que os consumidores “farão a coisa certa”. 
Por exemplo, os consumidores podem tentar se comunicar 
usando mensagens mal-elaboradas/mal-intencionadas ou 
tentar violar outras diretrizes necessárias para uma interação 
de serviço bem-sucedida. 
Feitas essas considerações, alguns princípios de design sim-
ples que ajudam a garantir a compatibilidade com a segunda 
característica (Serviços são autônomos) são:
• Os serviços devem ser implantados e ter a versão atualiza-
da, independentemente do sistema em que sejam implantados 
e utilizados;
• Os contratos devem ser projetados pressupondo-se que, 
uma vez publicados, não possam ser modificados. Essa 
abordagem força os desenvolvedores a criarem flexibilidade 
em seus de-signs de esquema;
• Os serviços devem ser tolerantes a falhas, adotando uma 
visão pessimista. Da perspectiva do consumidor, deve-se 
esperar níveis pouco confiáveis de disponibilidade e de de-
sempenho do serviço. Da perspectiva do fornecedor, espere 
que o serviço seja usado de forma errada (deliberadamente 
ou não) e que os consumidores do serviço falhem, talvez sem 
notificar o serviço.
Serviços compartilham esquema e contrato. Como já foi 
dito, a interação com um serviço deve seguir diretrizes defini-
das no contrato deste serviço. A maioria dos desenvolvedores 
define classes para representar as várias entidades dentro de 
determinados domínios de problemas (por exemplo, Cliente, 
Pedido e Produto). As classes combinam comportamento e 
dados (mensagens) em uma única linguagem de programação 
ou construção específica à plataforma. Os serviços dividem 
esse modelo para maximizar a flexibilidade e a interopera-
bilidade. Os serviços que se comunicam usando mensagens 
baseadas no esquema XML não reconhecem as linguagens e 
as plataformas de programação, garantindo níveis mais am-
plos de interoperabilidade. O esquema define a estrutura e o 
conteúdo das mensagens, ao passo que o contrato de serviço 
define o comportamento do próprio serviço.
Resumindo, o contrato de um serviço consiste nos seguintes 
elementos:
• Formatos de troca de mensagens definidos com o Esquema 
XML;
• Padrões de troca de mensagens (MEPs) definidos com o 
WSDL;
• O BPEL pode ser usado como contrato no nível de processo 
comercial para orquestrar vários serviços.
Os consumidores de serviço utilizam um contrato de ser-
viço para invocar um serviço e interagir com ele. Havendo 
essa confiança, o contratode um serviço deve permanecer 
estável com o passar do tempo. Os contratos devem ser pro-
jetados da forma mais explícita possível, ao mesmo tempo 
tirando proveito da natureza extensível do esquema XML 
e do modelo de processamento SOAP.
O maior desafio da terceira característica é sua conti-
nuidade. Depois que um contrato de serviço é publicado, 
é extremamente difícil modificá-lo e ao mesmo tempo 
minimizar o impacto sobre antigos consumidores do ser-
viço. A linha entre as representações de dados interna e 
externa é fundamental para a implantação e a reutilização 
bem-sucedida de determinado serviço. Os dados públicos 
(dados passados entre serviços) devem se basear em padrões 
organizacionais ou verticais, garantindo ampla aceitação 
entre diferentes serviços. Os dados privados (dados dentro 
de um serviço) são encapsulados em um serviço. De alguma 
maneira, os serviços são como representações menores de 
uma organização que conduz transações de e-business. 
Assim como uma organização deve mapear uma Ordem 
de compra externo em seu formato interno de OC, um 
serviço também deve mapear uma representação de dados 
sob contrato em seu formato interno. As experiências com 
encapsulamento de dados OO podem ser reutilizadas para 
ilustrar um conceito semelhante: a representação interna 
dos dados de um serviço só pode ser manipulada por meio 
do contrato do serviço.
Feitas essas considerações, vão aqui alguns princípios de 
design simples que o ajudam a garantir a compatibilidade 
com a terceira característica:
• Garantir que o contrato de um serviço permaneça estável 
para minimizar o impacto sobre os consumidores do serviço. 
O contrato nesse sentido se refere à representação de dados 
pública (dados), ao padrão de troca de mensagens (WSDL) e 
a recursos e níveis de serviço configuráveis (diretriz);
• Os contratos devem ser o mais explícitos possível, visando 
minimizar a má interpretação. Além disso, os contratos 
devem acomodar a futura versão do serviço por meio da 
extensibilidade da sintaxe XML e do modelo de processa-
mento SOAP;
• Evitar transpor a fronteira entre as representações de 
dados pública e privada. O formato interno dos dados de 
um serviço deve ficar oculto para os consumidores e o 
esquema de dados público deve preferencialmente seguir 
um padrão organizacional;
• Serviços de versão quando há alterações no contrato de 
serviço são inevitáveis. Essa abordagem minimiza a ruptura 
de implementações do antigo consumidor.
Conclusão
As demandas de uma arquitetura orientada a serviços em 
termos de disponibilidade, escalabilidade, desempenho, 
confiabilidade e assim por diante são ainda mais impor-
tantes quando postas frente às mudanças tecnológicas na 
Edição 29 - Engenharia de Software Magazine 19 
ARQUITETUR A ORIENTADA A SERVIÇOS (SOA)
área de TI. Em SOA existe um aumento significativo do 
risco de não acompanhar as necessidades do negócio se a 
infraestrutura não atender a demanda e não existir uma 
previsão ou planejamento para essa demanda. Portanto, 
em linhas gerais é vital ser cauteloso: planejar com antece-
dência, manter o ciclo de comunicação aberto, conhecer as 
tendências em serviços do setor, quais os próximos serviços 
a serem construídos e assim por diante. Em resumo, o 
importante é seguir um processo, ser pró-ativo em termos 
de capacidade de planejamento, gestão e acompanhamento 
das soluções adotadas. 
Do ponto de vista de arquitetura de software, é sempre 
bom manter os olhos sobre as tecnologias SOA mais atu-
ais, padrões e frameworks. Provavelmente, os serviços 
que seus clientes estão usando agora possuem uma vasta 
gama de tecnologias, de modo que você precisa monitorar 
continuamente estas tendências. Por isso, é prudente ter 
um Plano de interoperabilidade, ou melhor, tentar prever 
os desafios de interoperabilidade em termos de escolhas 
de tecnologia. 
[1] Erl,, T. “Introduction to Web Services Technologies: SOA, SOAP, WSDL and UDDI”
Prentice Hall PTR, Upper Saddle River, NJ, 2007 - www.thomaserl.com
[2] Rodriguez, T. Demsak, T.Lightweight SOAs: Exploring Patterns and Principles of a New 
Generation of SOA Solutions - http://msdn.microsoft.com/en-us/architecture/bb426891.aspx
[3] Smartsec “SOA - Service Oriented Architecture” - http://www.smartsec.com.br/soa.html
[4 ] TI INSIDE, Converge Comunicações “Segurança é ponto crítico em SOA e serviços web”
http://www.tiinside.com.br/News.aspx?ID=102376&C=262
[5] The World Wide Web Consortium (W3C) - http://www.w3.org/
Links
Dê seu feedback sobre esta edição!
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
Para isso, precisamos saber o que você, leitor, acha da revista!
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback
D
ê 
se
u Fe
edback
so
b
re esta edição
20 Engenharia de Software Magazine - Automação dos Testes: um lobo na pele de cordeiro?
Daniel Scaldaferri Lages
dlages@gmail.com 
Possui MBA em Gerência de Projetos pela 
Fundação Getúlio Vargas, é pós-graduado 
em Gerência de T.I. pela Universidade FU-
MEC e Bacharel em Ciência da Computação 
pela UFMG. Atualmente é Coordenador da 
equipe de Quality Assurance da CPM Braxis, 
filial BH. Sua experiência profissional inclui 
o cargo de Analista de Testes no Synergia 
(núcleo de engenharia de software do 
Departamento de Ciência da Computação 
da UFMG), Gerente da fábrica de software 
na Unitech (hoje CPM Braxis) e docência 
no curso de graduação de Sistemas de In-
formação na PUC-MG. Possui a certificação 
ITIL para gerenciamento de serviços de T.I. 
É certificado em testes de software pela IS-
TQB e em qualidade de software pela IBM. 
De que se trata o artigo?
Este artigo apresenta uma reflexão sobre os cui-
dados que devem ser levados em consideração na 
aplicação da automação de testes. Muitas vezes 
essa atividade é vista como a “salvação” em ter-
mos de custo, prazo e produtividade para os pro-
jetos. O artigo apresenta situações que mostram 
que, caso a automação não seja bem implemen-
tada, só irá prejudicar.
Para que serve?
O artigo poderá auxiliar os gerente e profissionais 
de testes que desejam automatizar os testes de 
software, apresentando os cuidados, as dificulda-
des e os pontos fracos e fortes dessa atividade. Irá 
auxiliá-los para que pensem racionalmente, e não 
utopicamente, sobre essa atividade. 
Em que situação o tema é útil?
Para empresas e profissionais que possuem inte-
resse em automatizar os testes dos seus softwa-
res de maneira controlada, com conhecimento de 
alguns dos principais riscos desta atividade.
Automação dos Testes: um lobo na pele de cordeiro?
Conheça os cuidados a serem tomados na implantação da automação dos 
testes para evitar o fracasso
Engenharia
Nesta seção você encontra artigos voltados para testes, processo, 
modelos, documentação, entre outros
O termo “lobo em pele de cordei-ro” utilizado no título desse artigo origina-se de uma fábula 
que fala do lobo que se disfarçou com 
uma pele coberta de lã e assim con-
seguiu entrar no rebanho de ovelhas, 
fazendo-se passar por uma delas tanto 
na aparência como no comportamento 
fingido, mas aproveitando essa condição 
para devorar as inocentes e despreveni-
das vítimas. 
Devido ao apelo de se implantar a au-
tomação de testes como a “salvação” em 
termos de custo, prazo e produtividade 
para os projetos de desenvolvimento de 
software, esta iniciativa pode ser com-
parada com a inocente ovelhinha, pois 
aparentemente não apresenta riscos à 
empresa, apenas benefícios. Mas esta 
ovelha pode se revelar um lobo, caso 
o processo de implantação da automa-
ção de testes não seja bem planejado e 
conduzido, resultando no fracasso do 
projeto. Apesar dessa analogia entre a 
Edição 29 - Engenharia de Software Magazine 21 
VALIDAÇÃO, VERIFIC AÇÃO & TESTE