Engenharia de Software - Edição 70

Rodrigo Oliveira Spnola
rodrigo.devmedia@gmail.com
Doutor e Mestre em Engenharia de Software pela COPPE/UFRJ. Realizou seu Ps-Doutorado na
University of Maryland Baltimore County e Centro Fraunhofer nos Estados Unidos. Atualmente
Professor Titular do Programa de Ps-Graduao em Sistemas e Computao da Universidade
Salvador - UNIFACS.
Marco Antnio Pereira Arajo

maraujo@devmedia.com.br
70 Edio - 2014
Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ, Especialista em

Mtodos Estatsticos Computacionais e Bacharel em Matemtica com Habilitao em Informtica pela UFJF.
Corpo Editorial
Editor
Rodrigo Oliveira Spnola
Eduardo Oliveira Spnola

eduspinola@gmail.com
Colaboradores
Eduardo Oliveira Spnola
Nicolli Souza Rios Alves
Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Magazine.
bacharel em Cincia da Computao pela Universidade Salvador (UNIFACS).
Consultora Tcnica
Daniella Costa
Nicolli Souza Rios Alves

nicolli.devmedia@gmail.com
Bacharel em Cincia da Computao na Universidade Salvador (UNIFACS), Mestranda em Sistemas
e Computao no Programa de Ps-Graduao em Sistemas e Computao da UNIFACS na linha de
Engenharia de Software. editora da Engenharia de Software Magazine.
Jornalista Responsvel
Kaline Dolabella - JP24185
Na Web
http://www.devmedia.com.br/revista-engenharia-de-software-magazine
Atendimento ao Leitor
A DevMedia conta com um departamento exclusivo para o atendimento ao leitor.
Se voc tiver algum problema no recebimento do seu exemplar ou precisar de algum
esclarecimento sobre assinaturas, exemplares anteriores, endereo de bancas de
jornal, entre outros, entre em contato com:
www.devmedia.com.br/central
(21) 3382-5038
Publicidade
Para informaes sobre veiculao de anncio na revista ou no site entre em
contato com:
publicidade@devmedia.com.br
Fale com o Editor!

muito importante para a equipe saber o que voc est achando da revista: que tipo de artigo voc
gostaria de ler, que artigo voc mais gostou e qual artigo voc menos gostou. Fique a vontade para
entrar em contato com os editores e dar a sua sugesto!
Se voc estiver interessado em publicar um artigo na revista ou no site ES Magazine,
entre em contato com os editores, informando o ttulo e mini-resumo do tema que voc gostaria
de publicar.
Contedo sobre Agilidade, Artigo no estilo Prtico
Sumrio
06 MPS.BR: Melhorando o nvel de maturidade do processo com metodologia gil

[ Elaine G. M. de Figueiredo ]
Contedo sobre Agilidade, Artigo no estilo Prtico
12 Estudo de caso de uma Modelagem gil

[ Andr Vidal ]
Contedo sobre Agilidade
23 Desenvolvimento gil: O papel do PMO no mundo gil

[ Srgio Salles Galvo Neto ]
Contedo sobre Agilidade
33 O que faz um Gerente de projetos e um Scrum Master?

[ Srgio Salles Galvo Neto ]
Contedo sobre Boas Prticas, Contedo sobre Arquitetura e Desenvolvimento
42 Entendendo o Teste de Software por Amostragem

D
s
[ Clia Negrini ]
Feedback
eu
48 Como aumentar a produtividade de sua equipe de programadores
Contedo sobre Boas Prticas
52 Como detectar problemas de usabilidade e corrigi-los

[ Karin R. Coelho Quandt ]
edio
ta
[ Ivania Ramos dos Santos e Marcos Vinicius De Bortolli ]
sobre e
s
Artigo no estilo Prtico
D seu feedback sobre esta edio!

A Engenharia de Software Magazine tem que ser
feita ao seu gosto.
Para isso, precisamos saber o que voc, leitor, acha
da revista!
Contedo sobre Planejamento e Desenvolvimento, Artigo no estilo Prtico
57 Teste unitrio com JUnit e ComplexGraph

[ Felippe Moreira Fada, Vincius Lucena Bonoto e Marco Antnio Pereira Arajo ]
www.devmedia.com.br/esmag/feedback
Edio 05 - Engenharia de Software Magazine
Agilidade
Nesta seo voc encontra artigos voltados para as prticas e mtodos geis.
MPS.BR: Melhorando o nvel de maturidade

do processo com metodologia gil
Um processo de software com prticas geis para atingir resultados
esperados conforme o MPS.BR
Fique por dentro:
Elaine G. M. de Figueiredo
mira.figueiredo@gmail.com
Mestrado em Ciencias da Computano com

enfase em engenharia de software, ps graduao em gerncia de projetos, oito anos de atuao na rea de desenvolvimento e qualidade de
software. Atualmente gerente de projetos na
multinacional espanhola Indra Company, membro colaborador do grupo de pesquisa ASSERT
Advanced System and Software Engineering
Research Technologies Lab pela universidade
federal de Pernambuco. Certificada P1 no programa MPS.BR.
MPS.BR ou Melhoria de Processos do Software Brasileiro simultaneamente um movimento

para a melhoria da qualidade (Programa
MPS.BR) e um modelo de qualidade de
processo (Modelo MPS), ele baseado
nas normas ISO/IEC 12207 e ISO/IEC
15504 e compatvel com o CMMI. O MPS
.BR sugere resultados a serem atingidos
como requisitos para atender objetivos
de qualidade (obteno de qualidade).
Esses resultados podem ser atingidos
por meio de tarefas ou conjunto de
tarefas que quando mal aplicados torna
o processo mais burocrtico.
Em um sentido contrrio tem-se as
organizaes que necessitam atingir
objetivos de qualidade mas no podem
adotar prticas burocrticas ou mesmo
no geis. Para estes casos, possvel por
meio de metodologia gil entregar o que
o MPS.BR aguarda como melhoria para
os nveis de maturidade de processo de
desenvolvimento.
Este artigo exibe um processo de software

pautado sobre a metodologia gil de desenvolvimento e que poder ser adotado por aqueles
que desejam ter seus processos coerentes a
alguns objetivos de qualidade segundo o MPS
.BR. Deste modo, ele til a estudantes, profissionais de desenvolvimento de software e
empresas que necessitam utilizar um processo
de software gil, mas que necessitam, ou desejam, atingir requisitos que os programas de
qualidade como o MPS.BR defendem.
Alguns conceitos de qualidade do MPS.

BR e importantes para o entendimento
desse artigo so:
1. Capacidade do processo: Uma caracterizao da habilidade do processo
atingir os objetivos de negcio atuais
ou futuros;
2. Atributo de processo: Uma caracterstica mensurvel da capacidade do processo aplicvel a qualquer processo];
3. Nvel de maturidade: Grau de melhoria de processo para um predeterminado
conjunto de processos no qual todos os
Engenharia de Software Magazine - MPS.BR: Melhorando o nvel de maturidade do processo com metodologia gil
agilidade
resultados esperados do processo e dos atributos dos processos so atendidos.

A qualidade pode ser agregada a qualquer processo de software uma vez que o mesmo tenha prticas e procedimentos
homologados e conceituados pela engenharia de software. Para
este artigo ser defendida a filosofia gil de desenvolvimento
de software como opo para o desenvolvimento de sistemas.
A essncia desta filosofia a definio de desenvolvimento
de software galgado na agilidade, na flexibilidade, nas habilidades de comunicao e na capacidade de oferecer novos
produtos e servios de valor ao mercado, em curtos perodos
de tempo e a baixo valor de custo.
Descrio do Processo
O processo escolhido baseado nas principais tcnicas da
metodologia XP e do Scrum, enquanto a primeira mais focada
em prticas operacionais de codificao, teste e integrao, a
segunda focada no gerenciamento do projeto.
As prticas XP a serem utilizadas so:
Codificao em par: dois programadores utilizando o mesmo computador escrevem o cdigo e vistoriam o mesmo;
Testes automatizados: escrita de script ou cdigos de
testes para verificarem os cdigos escritos para o programa
e detectarem erros de forma automatizada, precisando para
isso rodar rotinas de testes no prprio sistema;
Integrao contnua: os programadores devem integrar os
novos cdigos ao software to rapidamente e com a maior
frequncia possvel;
Design simplificado: os programadores so estimulados a
desenvolver o cdigo do software o mais simples possvel;
Reegenharia de Software: o cdigo deve ser constantemente
melhorado, sem que a funcionalidade seja alterada pela equipe
do projeto o tempo todo.
As prticas Scrum que sero adotadas so basicamente o
fluxo de processo, ou seja, as fases e etapas cumpridas para a
concepo do software devem ser as mesmas da metodologia
Scrum. Tal metodologia explicitada abaixo com o fluxo de
processo a ser utilizado, assim como perfis, papis e artefatos
entregues.
Perfis e Papis
Os perfis de desenvolvimento necessrios para execuo do
processo so:
Scrum Master: gerencia a metodologia do Scrum, ensinando
as prticas do Scrum a todos os envolvidos no projeto e implementando o Scrum de modo que esteja adequado cultura da
organizao. Para tal, deve garantir que todos sigam as regras
e prticas do Scrum. responsvel por remover os impedimentos do projeto, perceber e resolver problemas pessoais ou
conflitos entre os integrantes da equipe de desenvolvimento.
Product Owner: o proprietrio do produto e deve representar os interesses do cliente. Deve ser a interface entre o cliente
e o time de desenvolvedores, ou seja, estar sempre em contato
com o cliente e saber exatamente o que se espera do projeto,

no contexto do atendimento das necessidades de negcio do
cliente. Para tal, deve ter conhecimento a respeito do negcio
e das prticas do Scrum. Pode ser um financiador, o prprio
cliente, um experiente usurio final ou um importante interessado da equipe.
Equipe Scrum: um grupo de pessoas com diferentes habilidades necessrias (gerencial, tcnico e operacional) para
transformar requisitos em um incremento potencialmente
entregvel.
Artefatos e procedimentos a serem entregues

Os procedimentos e os artefatos que compem este processo
devem se preocupar em cumprir algumas metas de qualidade
do MPS.BR. Seguem abaixo os produtos que devem ser entregues para as demandas de desenvolvimento, seguindo os
resultados propostos no MPS.BR:
Documentos de Viso: para a definio de escopo das
necessidades, caractersticas e funes especificadas para
o produto que ser desenvolvido determinando o que far
parte ou no do projeto. Artefato ligado ao resultado esperado
GPR1 - O escopo do trabalho para o projeto definido do
modelo MPS BR;
Contagem de Pontos por Funo: fornecendo uma referncia
para a atribuio de tamanho e esforo. Esta prtica est relacionada ao resultado esperado GPR2 As tarefas e os produtos
de trabalho do projeto so dimensionados utilizando mtodos
apropriados do MPS BR;
Cronogramas/planilhas de atividades, ou quadro de tarefas.
Vinculado ao GPR5 - O oramento e o cronograma do projeto,
incluindo a definio de marcos e pontos de controle, so
estabelecidos e mantidos do modelo MPS BR;
Product Backlog: possui uma lista de todas as funcionalidades desejadas no produto, descritas em forma de user stories
(estrias do usurio). Cada estria do Product Backlog deve ter
um valor de negcio atribudo pelo Product Owner. Produto
obtido por meio de tarefa relacionada a requisitos de software;
a gerncia de requisitos exigncia do MPS.BR;
Documento de Arquitetura: este documento deve apresentar
a estrutura fundamental do software, descrever as estruturas
recorrentes da comunicao entre componentes e apresentar
uma soluo para um problema de projeto em um determinado contexto;
Ata da Reunio de Planejamento: deve registrar os assuntos
tratados durante a reunio, a relao dos participantes bem
como a assinatura destes e as decises a serem tomadas, caso
necessrio. Isto prov a gesto de comunicao. As atas devem
ainda registrar mudanas desejadas para posterior analise; ou
seja, realizao da gesto de mudana de requisitos realizada
por meio de anlise de impacto, principalmente dos cdigos j
escritos. Atividade e artefato baseado no GRE5 - Mudanas nos
requisitos so gerenciadas ao longo do projeto do MPS BR;
Ata da Reunio de Reviso da Sprint: contm a pauta da
reunio, a relao dos participantes, bem como a assinatura
destes, a avaliao da execuo das tarefas, registro de bug,
mudanas e possveis novas estrias encontradas durante a

apresentao do release; trata-se de mais um artefatos originado por uma atividade voltada anlise de impacto;
Verses de software, seguindo gerncia de configurao,
com possveis registros atravs da utilizao da ferramenta
SVN, relacionada a um dos resultados esperados do nvel F do
MPS BR GCO1 - Um Sistema de Gerncia de Configurao
estabelecido e mantido. Isto se faz relevante principalmente
em um ambiente gil de desenvolvimento de software com a
utilizao da prtica de integrao contnua.
Apresentam-se tambm seis procedimentos, que guiam a
execuo adequada das atividades do processo proposto:
1. Definio das Estrias: guiar o Product Owner na descrio
das estrias, definio de valor de negcio e conceito de pronto
para cada das estrias;
2. Desenvolvimento das Estrias: apoiar o Scrum Master no
clculo da velocidade da Equipe, a prpria Equipe na seleo
e manipulao das estrias a serem desenvolvidas durante a
Sprint e na diviso destas estrias em tarefas executveis;
3. Estimativa por Ponto de Estria: medida do tempo em dias
que um desenvolvedor pode levar para entregar uma estria.
Este valor considerado para mtricas e monitoramento da
velocidade e produtividade do projeto;
4. Criao/Atualizao do Quadro de Trabalho: descreve
como criar e atualizar o Quadro de Trabalho que permite
o acompanhamento do desenvolvimento de uma estria do
Product Backlog, onde cada etapa do desenvolvimento de uma
tarefa poder ser rapidamente identificada pela equipe. Para
tal, possui colunas especificando os estados das tarefas, as
prprias tarefas descritas em post-its, dentre outros atributos.
A adoo de uma ferramenta para a criao e manuteno do
quadro poder ser adotada;
5. Reunies: descrevem como conduzir as cerimnias do
Scrum, que so reunies, formais ou no, que acontecem em
momentos distintos do Processo;
6. Dados Histricos: descreve como as lies aprendidas
durante a execuo do projeto devero ser coletadas e armazenadas para que o resultado desta coleta sirva de base de
conhecimento para a equipe utilizar em projetos futuros.
no produto entregue para verificar se tudo realmente foi

implementado.
Ao final da Sprint, deve-se realizar uma Reunio de Reviso
(Sprint Review), onde a equipe demonstra o produto gerado ao
Product Owner e este valida se o objetivo foi atingido. Logo
em seguida, realiza-se a Reunio de Retrospectiva (Sprint Retrospective), uma reunio de lies aprendidas, com o objetivo
de melhorar o processo, ou a equipe (time) e/ou produto para
a prxima Sprint.
As prticas do Scrum so implementadas atravs de trs
papis principais: o Product Owner que define as funcionalidades do produto (Product Backlog) atravs de User Stories
(requisitos); o ScrumMaster que representa a gerncia para
o projeto, sendo o responsvel pela aplicao dos valores e
prticas do Scrum; e a equipe (team) que define as tarefas que
iro compor o Sprint Backlog e desenvolve as funcionalidades
do produto.
Fluxo Geral de Desenvolvimento de Sistemas

A partir de uma perspectiva de gerenciamento baseado no
ciclo de desenvolvimento iterativo incremental para o Scrum,
e conforme recomendaes e boas prticas de gerncia gil de
projetos de software provenientes de organizaes nacionais
que fazem uso nos seus processos de metodologias geis, chegou-se a um processo composto por trs fases: Planejamento
ou Pr-Game, Desenvolvimento ou Game, e Finalizao ou
Ps-Game que so apoiadas por atividades de Monitoramento
e Controle conforme a Figura 1.
Fluxos de Processo
O ciclo ou fluxo do processo tem o seu progresso baseado
em uma srie de iteraes bem definidas, cada uma com durao de duas a quatro semanas, chamadas Sprints. Antes de
cada Sprint, realiza-se uma Reunio de Planejamento (Sprint
Planning Meeting) onde o time (equipe) de desenvolvedores
tem contato com o cliente (Product Owner) para priorizar o
trabalho que precisa ser feito, selecionar e estimar as tarefas
que o time pode realizar dentro da Sprint.
A prxima fase a Execuo da Sprint onde o time controla o andamento do desenvolvimento realizando Reunies
Dirias (Daily Meeting), no mais que 15 minutos de durao,
e observando o seu progresso usando um grfico chamado
Sprint Burndown. Ao final de cada Sprint, feita uma reviso
Figura 1. Fluxo Geral para Desenvolvimento de Sistemas
agilidade
A seguir, este processo apresentado atravs da descrio

de suas fases, atividades e responsveis por execut-las.
Tambm sero descritos os procedimentos a serem seguidos,
que descrevem e exemplificam prticas geis incorporadas no
processo, alm dos artefatos a serem gerados na execuo das
atividades de cada fase.
Detalhamento das Fases

A Figura 2 apresenta o fluxo da Fase de Planejamento ou
tambm chamada de Pr-Game que tem como objetivo delimitar o escopo do projeto, planejar o tempo e custo e eliminar
os possveis riscos a partir da definio de uma arquitetura
estvel.
requisitos, estrias e demais coisas que o cliente desejar, que

deve ser descrito utilizando a terminologia do cliente.
A fase seguinte a diviso do Backlog em Sprints, onde as
estrias com maior valor para o cliente so selecionadas e
divididas nas interaes (Sprints). Neste momento deve ser
aplicado o valor da estria e o tempo de desenvolvimento em
dias para cada uma.
Por fim, a equipe deve ser selecionada. O ideal que a mesma
no seja maior do que 8 pessoas e menor do que 4. Um projeto
de arquitetura elaborado por meio de um template padro
de definio arquitetural, com a elaborao dos diagramas
necessrios. A equipe deve discutir e apresentar a estrutura
fundamental do software, descrever as estruturas recorrentes
da comunicao entre componentes e apresentar uma soluo
para um problema de projeto em um determinado contexto.
no projeto de arquitetura de software que os requisitos no
funcionais so primeiramente considerados.
A diviso das Sprints, da equipe, e a definio da arquitetura
podem ser feitas simultaneamente, onde cada papel desempenha uma funo, interagindo um com o outro, agregando assim
agilidade. Opcionalmente, a arquitetura pode ser feita para
os produtos resultantes de uma Sprint, e no para o produto
resultante do processo como um todo (Product Backlog).
A estimativa de ponto por funo obtida por meio do documento de viso e de arquitetura. A estimativa ser apresentada
juntamente ao Backlog e as Sprints para todos os envolvidos na
Figura 2. Fluxo geral para a fase de modelagem ou pr game
A fase iniciada quando o setor responsvel pelo desenvolvimento de software recebe uma demanda de desenvolvimento.
Para isso, uma ordem de servio criada. A partir da ordem
de servio, o solicitante do servio (cliente) deve identificar o
seu representante (Product Owner). Este Product Owner ser
responsvel por definir as funcionalidades do produto e aceitar
ou rejeitar os resultados das Sprints.
O Product Owner deve possuir o conhecimento a respeito
do negcio e a respeito do Scrum. O Product Owner deve
descrever um estado desejado do produto no futuro. A viso
do produto deve possuir as caractersticas do produto com
uma viso voltada ao negcio, algumas premissas do projeto,
se necessrio, a fim de garantir um entendimento comum das
partes envolvidas e as restries ou limitaes aplicveis que
afetar o desempenho do projeto.
O Product Owner deve definir as funcionalidades desejadas
para o produto e priorizar as mesmas de acordo com seu valor
de negcio. O Product Backlog basicamente uma lista de
reunio de planejamento (a reunio visa apresentar o projeto e

obter aceite sobre o mesmo), concluindo-se assim esta fase.
A fase de desenvolvimento ou Game ser exibida na Figura 3.
Nesta fase, uma parte do produto desenvolvida com base nos
objetivos do Product Owner, na arquitetura definida e com
nfase no gerenciamento dos recursos disponveis e no valor
de negcio das estrias.
O incio da fase de desenvolvimento sempre deve ser precedida pela fase de modelagem e planejamento, explicitada
anteriormente. O incio do desenvolvimento se d por meio
da anlise dos dados histricos de projetos semelhantes e as
lies aprendidas em Sprints anteriores. Estes dados serviro
como base de conhecimento para auxiliar nas estimativas
de esforo, estimativas de custo do projeto, e tambm para o
conhecimento da situao e prticas a serem evitadas ou no;
trata-se da primeira subfase do desenvolvimento.
Figura 3. Fluxo geral para a fase de desenvolvimento ou game
10
As tarefas devem ser devidamente divididas entre os integrantes da equipe e atribudas a cada um deles para que tais
profissionais entendam o seu papel e possam juntamente ao
ScrumMaster atualizar suas tarefas no quadro. Deve-se criar
e fixar um quadro de tarefas na parede, referente a Sprint,
para anexar as estrias e suas tarefas atravs de post-its, inserir informaes sobre itens no planejados e acompanhar
os objetivos da Sprint atravs do grfico Burndown. Uma
ferramenta pode ser adotada para a insero do quadro de
tarefas dentre as atividades, pois existem vrias ferramentas
no mercado que so quadro informatizados, que possuem
todas as funcionalidades de tal.
Aps os aceites dos interessados, a diviso e entendimento
das tarefas e estrias; a equipe poder iniciar o desenvolvimento que se baseia na codificao, testes automatizados e
integrao contnua de cdigo no SVN. Neste contexto, os testes
tambm podem incluir a confeco de
artefatos, como plano de teste, roteiro
e casos de testes.
No contexto dos testes, a opo por
adotar testes manuais e a elaborao
de documentaes, o que contrrio
s prticas geis, surge da necessidade
que a organizao ou equipe pode vir
a ter da referida documentao como
registro, ou mesmo no caso de ter
profissionais de teste especializados
e dedicados a somente uma demanda
de desenvolvimento; o que ofertaria
a possibilidade da escrita de cdigo
de teste, automatizando os mesmos, e
da escrita da documentao ou testes
manuais para alguns tipos de testes.
O Scrum Master deve realizar uma
reunio diariamente com todos os
membros da equipe com o objetivo de
sincronizar o progresso do trabalho
e levantar impedimentos que devem
ser removidos.
A equipe deve continuar a codificar,
testar e entregar cdigo enquanto
houverem estrias, deve juntamente
ao Scrum Master verificar o surgimento de tarefas no planejadas,
atualizar o Quadro de Trabalho,
grfico Sprint Burndown e atualizar a
lista de impedimentos, impedimentos
que devem ser retirados sempre pelo
ScrumMaster.
Trs etapas devem ter ateno neste
fluxo, as etapas de atualizao de
Sprint e Product Backlog que podem
ser feitas sobre o quadro de tarefas
ou no prprio artefato de Product
Backlog. Estas so importantes para
agilidade
atualizao do que foi feito, do registro dos problemas, ou

ainda das estrias no planejadas que surgiram. Tais aes so
relevantes para o prprio registro e gesto de conhecimento
dentro do projeto e equipe. Outra importante tarefa o Monitoramento e Controle que o Scrum Master deve fazer ao longo
do processo, sempre visualizando impedimento, ou sugerindo
melhorias, registrando ocorrncias e lies aprendidas.
Sempre que uma Sprint for finalizada, a fase exposta na
Figura 4 deve ser iniciada. Esta a fase de finalizao ou
ps-game.
Tudo o que afeta a forma como a equipe desenvolve o software deve ser aberto para debate, como processos e prticas,
ambiente e comunicao, e ferramentas artefatos.
Por fim, os dados so atualizados e uma nova Sprint
deve ser planejada, iniciando assim novamente o ciclo de
desenvolvimento.
possvel observar que este processo agrega as prticas geis
algumas prticas e procedimentos de metodologias tradicionais. Isto se deve necessidade de obedecer alguns objetivos
de qualidade que so sustentados pelos programas; os mesmos
s podem ser obtidos por meio de prticas no geis, ou ainda
por meio da adaptao destas. Por exemplo: para prover a
rastreabilidade dos requisitos (resultado esperado do processo
gerncia de requisitos do MPS.BR) e assim prever impactos no
desenvolvimento devido a uma solicitao de mudana, ser
inserida uma coluna a mais no documento de Product Backlog,
de modo que sero traados relacionamentos entre as estrias
em que ser possvel notar qual estria poder ser alterada ou
impactada de alguma forma por outra.
A ideia de fazer um processo gil considera prticas de metodologias diferentes, ou seja, prticas geis com tradicionais
no pode ser considerada errnea ou indesejada, pelo contrrio,
um processo escrito dessa forma possibilita a obteno dos
benefcios que ambas as metodologias podem trazer.
Links:
Figura 4. Fluxo geral para a fase de finalizao ou ps-game
A fase de finalizao concebida por meio de uma reunio

com todos os envolvidos no projeto, onde o Product Owner
oferta seu parecer sobre o produto desenvolvido, se o mesmo
atende as necessidades de negcio. Se no ocorrer aprovao, o desenvolvimento iniciado novamente sobre uma
Sprint de correo que deve ser paralela nova Sprint de
desenvolvimento.
Caso haja aprovao, o Product revisado e atualizado.
Ocorre ento a reunio de retrospectiva que vai apoiar o Scrum
Master a discutir os acontecimentos e compreender os fatos e
sentimentos durante a iterao (Sprint). Ela pode ser realizada
utilizando os seguintes questionamentos:
O que fizemos bem?
O que podia ter sido feito melhor?
O que pode ser melhorado?
Agile Alliance. What Is Agile Software Development?

http://www.agilealliance.org/intro
Softex Sociedade para Promoo da Excelncia do Software Brasileiro
(2012) MPS.BR Melhoria de Processo do Software Brasileiro, Guia Geral,
verso 1.2
http://www.softex.br/wp-content/uploads/2013/07/MPS.BR_Guia_Geral_
Software_2012.pdf
Voc gostou deste artigo?

D seu voto em www.devmedia.com.br/esmag/feedback
Ajude-nos a manter a qualidade da revista!
11
Agilidade
Nesta seo voc encontra artigos voltados para as prticas e mtodos geis.
Estudo de caso de uma Modelagem gil

Um estudo de caso para auxiliar times de desenvolvimento na implantao
Fique por dentro:
Andr Vidal
andre.vidal@oatsolutions.com.br
Graduado em Cincia da Computao pela

UNESP de Rio Claro, com MBA em Gesto de
Projetos pela FGV. Atua nas reas de gesto e
servios voltados engenharia de software,
com destaque gesto de projetos geis, modelagem de processo e anlise de negcios h
quinze anos. Nesses anos teve experincia na
formao de equipes de desenvolvimento e
sustentao, executando a pr-venda de projetos, atuando no planejamento, controle e implantao de metodologias de desenvolvimento e servios com base em processos baseados
no Cobit, ITIL, PMI e Scrum.
12
nicialmente proposta por Scott

Ambler em 2004, a Modelagem gil
(MA) surgiu como a tcnica mais
indicada para as prticas de anlise e
comunicao de equipes que utilizam
XP (Extreme Programming) e o Unified
Process (UP) como metodologias de
referncia para o desenvolvimento.
Considerada muito mais prtica voltada
modelagem sistemas de software, do
que uma metodologia formal, Ambler
estabelece que a MA deve ser vista
como uma coleo de prticas, guiadas por
princpios e valores que podem ser aplicados
por profissionais de software no dia a dia. A
MA no um processo prescritivo, pois ela
no define procedimentos detalhados de como
criar um dado tipo de modelo. Ao invs disso,
ela prov conselhos de como ser efetivo como
modelador. A MA deve ser vista como uma
arte, no como uma cincia.
A aplicao das prticas da MA devem auxiliar as equipes equalizarem
o conhecimento sobre o projeto do
software, definindo como ser feito o
desenvolvimento durante uma iterao.
Engenharia de Software Magazine - Estudo de caso de uma Modelagem gil
Nesse artigo veremos algumas boas prticas e

tcnicas empregadas na Modelagem gil (MA),
largamente utilizada por equipes de desenvolvimento de software baseadas em AGILE, por meio
de exemplos prticos. Os benefcios produzidos
pela MA vo muito alm do que apenas documentar os modelos de anlise, mas sim, torna
essas tarefas algo de interesse pblico do time,
criando um protocolo de comunicao entre os
membros da equipe. Os modelos produzidos durante a iterao da MA so vistos como um bem
coletivo da equipe e deve estar aliada ao uso
de uma linguagem comum entre os membros
dos times, sempre amparada por um processo
flexvel, bem definido. Para exemplificar o uso
da MA utilizaremos diagramas da UML (Unified
Modeling Language) e o processo de referncia
adotado tem por base o UP (Unified Process). Ao
longo desse artigo faremos a demonstrao de
um case, onde os modelos apresentados podero
auxili-lo quanto ao entendimento de como essa
poderosa ferramenta gil simplifica os trabalhos
de anlise e comunicao de sua equipe.
Portanto, uma exigncia que os membros de uma equipe que pratiquem a

MA conheam pelo menos uma tcnica
agilidade
de anlise, para que tenham um protocolo nico de comunicao entre seus membros. Nesse artigo trabalharemos com
os modelos utilizados pela Anlise Orientada a Objetos e os
artefatos utilizaro como base os diagramas da UML (Unified
Modeling Language).
Processo Unificado (UP)

O Processo Unificado (UP) foi concebido originalmente para
ser uma metodologia voltada gesto de projetos de desenvolvimento de software. Ele um guia composto por um conjunto
de disciplinas, as quais definem tarefas e atribuies teis para
nortear as atividades que resultaro na gerao do software.
O processo inicia mediante as necessidades do negcio de
clientes e seus usurios. A partir delas possvel que sejam
estabelecidos prazos, custos e critrios de qualidade aceitveis
para o software ser entregue.
O Processo Unificado define que o planejamento deve ser
iterativo e incremental. Dessa forma, a arquitetura do software
deve ser baseada em componentes, tornando possvel fazer um
mapeamento eficiente de requisitos e promovendo uma melhor
organizao da especificao resultante da anlise.
A fase de anlise deve definir como o sistema funcionar
internamente e de qual maneira os requisitos do cliente sero
atendidos. Alguns aspectos devem ser considerados nessa fase
de projeto do sistema, como: arquitetura do sistema, linguagem
de programao utilizada, Banco de Dados (SGBD), padro de
interface grfica, aplicao de frameworks, entre outros.
A Modelagem gil (MA) ocorre durante a fase de anlise,
quando feita a documentao computacional do projeto
do software. Nessa fase estabelecido como o software ser
construdo e precisa estar coerente com a descrio realizada
pelos artefatos produzidos pela definio dos requisitos.
Durante a etapa de anlise, duas atividades bsicas devem
ser cumpridas:
Projeto da arquitetura (ou projeto de alto nvel): O projeto
da arquitetura normalmente realizado por um arquiteto de
software, visando distribuir as classes de objetos relacionados
do sistema em outros subsistemas em formato de componentes,
distribuindo-os pelos recursos de hardware disponveis para
a aplicao;
Projeto detalhado (ou projeto de baixo nvel): Na fase de projeto detalhado so modeladas as relaes de cada mdulo com
os objetivos do negcio, realizando o projeto de interface com o
usurio, o banco de dados e as demais integraes sistmicas.
Extreme Programming (XP)

O desenvolvimento com Extreme Programming (XP) foi
criado no incio dos anos 80 por Kent Beck e Ward Cunningham, baseado em experincias no desenvolvimento de
sistemas em Smalltalk. O trabalho de ambos definiu uma
nova maneira de desenvolver software, passando a utilizar
conceitos que at ento nunca haviam sido explorados por
grande parte das equipes.
O modelo XP clssico abordava a aplicao de tcnicas relacionadas modelagem de domnios de sistemas, incluindo
a padronizao do cdigo fonte, o uso de design patterns e a

declarao das necessidades dos clientes em forma de cartes
CRC (Class Responsibility Card). Tais diretivas simplificavam
de forma significativa a documentao do processo de desenvolvimento de software.
J em meados dos anos 90 e, envolvido diretamente com
a doutrina do Movimento gil, Kent Beck estabelece as diretrizes daquilo que conhecemos hoje do modelo XP. Uma
metodologia preparada para evidenciar de maneira formal e
organizada os valores geis, postulando conceitos de transparncia, responsabilidade, foco na prestao de contas ao cliente
e efetuando entregas de software funcional ao final de cada
iterao, tal como prega o Processo Unificado.
Em 2002, Scott Ambler incorpora ao modelo XP os princpios
da Modelagem gil, definindo que durante o ciclo de vida da
iterao (semanal), as equipes de desenvolvimento devem se
preocupar em gerar modelos que auxiliem a implantao do
software e no com a documentao de projeto. Ou seja, no
dia a dia do desenvolvimento, mais importante informar a
todos o que deve ser feito, do que documentar algo que pode
mudar rapidamente.
Dessa maneira, sendo o XP uma adaptao do Processo
Unificado, foi criada uma orientao para tratar novas construes, voltada melhoria contnua da implementao de
controles e na definio arquitetura de sistemas. O mtodo
designa que problemas de projeto originados por necessidades
de arquitetura ou pela troca de tecnologia devem ser tratados
como Spikes. Dessa maneira, sesses de Modelagem gil so
utilizadas tanto na resoluo do Spike no projeto de alto nvel,
como tambm no projeto detalhado, promovendo agilidade ao
ciclo de desenvolvimento.
Comunicao
A comunicao interna da equipe numa iterao com Modelagem gil to ou mais importante que a externa, feita junto
ao cliente. A interao entre os membros da equipe deve ter
por objetivo gerar conhecimento e engajamento, auxiliando na
formao de um domnio de conhecimento comum ao time.
Dentre as tcnicas utilizadas por times MA que promovem
melhorias na comunicao, podemos citar a anlise colaborativa, a proximidade na distribuio geogrfica da equipe no
ambiente de trabalho, o uso de sesses de brainstorming e as
reunies dirias.
A forma como a equipe est distribuda no ambiente de trabalho recebe ateno e, realmente, pode fazer a diferena no
desempenho do time durante o projeto. Na Figura 1 podemos
ver um esboo do ambiente propcio prtica da comunicao
osmtica, desejvel para equipes de desenvolvimento XP.
A proposta da comunicao osmtica foi inicialmente estabelecida pela metodologia Crystal Clear, definida por Alistair
Cockburn, tornando o formato das salas de desenvolvimento
bastante conveniente s equipes que atuam com XP e demais
metodologias geis.
A disposio do layout de ambientes MA deve forar
a comunicao entre as pessoas durante os trabalhos de
13
desenvolvimento. Dessa forma, as caractersticas do local

devem ser formatadas para proporcionar melhorias comunicao do time, favorecendo as prticas geis. Ambientes formulados para promover esse tipo de interao devem prover:
rea comum: local onde o time se rene para o trabalho
dirio, de forma coletiva para trocar informaes relevantes
e experincias do projeto. Este local deve ser centralizado,
desprovido de barreiras de comunicao (por exemplo, baias
altas). A utilizao de perturbadores do foco de trabalho
restrita nessa rea, tal como celulares, tablets e aparelhos do
gnero que dispersam a ateno do time;
Cavernas (caves): local onde as pessoas podem desenvolver o
trabalho de maneira focada e concentrada, fora da rea comum.
Este local est montado numa das laterais da sala, e permite a
execuo de atividades que no faam parte do trabalho;
Paredes: as paredes devem ser utilizadas para o desenho e
desenvolvimento de modelos. Precisam estar preparadas para
esse tipo de interao, com lousas, dashboards e quadros que
facilitem e sejam difusores de informao para todos aqueles
que atuam junto ao time de desenvolvimento. de suma
importncia esse item para equipes que desejam praticar a
Modelagem gil.
Figura 1. Modelo de layout de estdio de software
Modelagem gil (MA)

Por definio, a Modelagem gil (MA) uma forma colaborativa de se analisar e desenvolver software, sendo vista muito
mais como uma prtica comum entre os integrantes do time,
do que um processo altamente definido.
Tecnicamente, o foco da MA est centrado na gerao de
um entendimento nico para a equipe. A orientao que
o desenvolvimento de novos modelos seja feito de forma
evolutiva, adotando a simplicidade como premissa bsica e
tendo sua progresso feita de forma incremental, semelhante
14
ao que propagado tanto pelo Processo Unificado, quanto

pelo XP.
O uso da MA deve estar voltada definio de um conjunto
de artefatos voltados formao do conhecimento comum
equipe com relao ao projeto de software, permitindo ao time
criar um padro simplificado de comunicao.
Como utilizar a modelagem gil?

A utilizao da MA por times de desenvolvimento prev
a aceitao de novos modelos de forma pragmtica, pois a
incluso de artefatos deve ocorrer desde que esses auxiliem o
entendimento da equipe e facilite o trabalho como um todo,
pois o produto final mais importante que a representao
do mesmo.
Portanto, a criao de novos modelos depende que os mesmos
sejam convencionados pela prpria equipe, pois sero adotados
por todos como um protocolo de comunicao, uma vez que
no h uma preocupao explcita com a documentao.
Princpios
Os princpios gerais da Modelagem gil (MA) defendem
que o modelo de trabalho das equipes deve evitar a perda de
tempo. Esse conceito vem dos processos baseados nas prticas
do Lean Software Development, onde eliminar o desperdcio,
amplificar a aprendizagem do time, entregar o mais rpido
possvel e capacitar a equipe para a construo de integridade
ao produto so vistos como as formas mais eficazes de exercitar
a modelagem gil com um time. A Modelagem gil aplicada
a esse contexto deve:
Atender a um propsito: Quando existe uma necessidade
que deve ser atendida, presume-se que algo de til est sendo
construdo. O objetivo final da modelagem fazer com que o
cdigo funcione ao final dos trabalhos, mesmo que para isso
modelos exigidos pela metodologia no sejam produzidos,
uma vez que o time chegue concluso que o propsito final,
entregar o cdigo funcionando, no seja atingido;
Ser preciso: A preciso est diretamente ligada eficincia
do modelo produzido. Um modelo preciso auxilia de forma
significativa o entendimento da equipe para com as necessidades do projeto, logo sua utilidade grande;
Ser consistente: A consistncia dos modelos deve sempre ser
averiguada por meio dos testes aplicados pela equipe durante
o desenvolvimento. Eventualmente correes devem ser aplicadas ao modelo, para que o mesmo se mantenha consistente
durante os trabalhos do projeto;
Agregar valor ao produto: A relao custo/benefcio da
utilizao do modelo deve atender s necessidades de comunicao da equipe, no sendo um trabalho descartvel. Logo,
agrega valor ao produto modelos cujo ciclo de vida perdura
por grande parte do projeto;
Ser simples: A simplicidade vista como a grande marca
da Modelagem gil, pois acaba induzindo as equipes trabalharem com modelos de fcil entendimento. Para esse propsito, muitas vezes, as equipes devem seguir o acrnimo KISS
(Keep It Simple, Stupid), para que os modelos produzidos no
agilidade
se percam quanto aos objetivos gerais da MA que estabelece

a simplicidade como uma necessidade do trabalho.
Ciclo de Vida
A criao de novos modelos em MA segue aquilo que metodologia preconiza: modelos intermedirios e temporrios
devem ter foco na comunicao entre os membros do time,
antes que sejam promovidos a permanente. Para Scott Ambler,
o uso de documentao no relacionada ao desenvolvimento
de software um dos principais causadores de atraso e desperdcio de tempo nas entregas dos projetos. Por tal motivo
criou-se uma falsa concepo que em processos geis no h
documentao. A documentao feita assim que os modelos
intermedirios utilizados sejam homologados e promovidos
produo. Dessa maneira, dizer que no h documentao
um grande equvoco!
Em XP, por exemplo, prope-se uma inverso nas fases do
desenvolvimento de software tradicional, executando as atividades de anlise e testes frente da codificao e do design.
Assim, o ciclo de vida dos artefatos criados para comunicao
da equipe tende a ser mais curtos, relegando aos artefatos
de arquitetura e modelos relacionais aquilo que realmente
necessita ser documentado num projeto. Para isso, os critrios
utilizados na criao de novos modelos durante a iterao MA
seguem o workflow apresentado na Figura 2.
importante salientar que todo projeto MA prega que
uma equipe deve produzir software potencialmente pronto
para funcionar em produo com periodicidade curta. Dessa
maneira, em MA a documentao deve ser produzida aps a
implantao das funcionalidades em produo. Isso justifica
que um artefato, desde sua concepo at sua transformao
em um modelo permanente, muitas vezes seja trabalhado de
forma temporria.
A garantia que cdigo esteja pronto para ser utilizado em
produo ao final de uma iterao no implica que sua documentao tambm seja gerada durante a mesma iterao. Dessa
maneira, comum estipular que a documentao seja produzida aps a implantao das funcionalidades em produo.
Modelagem gil na prtica

A Modelagem gil tem seus valores enraizados com a aplicao direta de seus princpios na prtica. Dessa forma, a MA
para ser melhor compreendida e assimilada por todos numa
equipe de desenvolvimento de software, alm da referncia
terica em modelagem orientada a objetos, a equipe precisa
por a MA em prtica.
Ao adotar a MA em projetos baseados no Processo Unificado
(UP) e Extreme Programming (XP), os princpios da tcnica
tendem a ser explorados em sua plenitude. Na prtica, fundamental que a liderana tcnica da equipe tenha em mente
que o processo ser melhorado gradativamente e, sendo esse
um processo iterativo e incremental desde seu incio, a tendncia que as prticas utilizadas nas primeiras iteraes sejam
refinadas e melhoradas a cada entrega.
O resultado esperado ao final do projeto que o processo
utilizado pela equipe j esteja bem maduro e mais ajustado
s necessidades do time; quando comparado com o que fora
proposto inicialmente. Ou seja, existe a necessidade explcita
que o processo seja rodado muitas vezes, e premissa bsica
que os timeboxes sejam definidos e respeitados pelo time.
Vale frisar que somente se o processo for executado at o fim,
que se pode identificar os problemas e melhorar algo em
tempo de projeto.
Outro ponto importante para o ajuste do processo durante
o curso do projeto diz respeito s reunies dirias. Muito
difundidas por outros mtodos como o Scrum e XP, as reunies dirias so o momento em que o time se rene para
discutir sobre aquilo que vem ocorrendo durante o projeto,
entendendo os problemas e definindo como eles podem ser
resolvidos durante a prpria iterao. Durante as discusses
dirias, possveis solues para os problemas apresentados so
definidos pela equipe e a modelar para comunicar tem papel
importante nesse contexto.
Estudo de Caso
Nesse artigo, para fins didticos, iremos apresentar os
principais conceitos da Modelagem gil por meio da sua
Figura 2. Ciclo de Vida Modelagem gil (MA)
15
aplicao a um caso tpico de desenvolvimento de sistema.

A Figura 3 apresenta as principais caractersticas da MA
que sero tratadas durante a aplicao do caso de estudo
WebBank.
Mostraremos a partir de exemplos, como a MA pode ser aplicada por times de desenvolvimento, sugerindo a produo de
diagramas que ajudaro a assimilar os conceitos aqui tratados,
sem que o leitor precise ter conhecimento de uma linguagem
de programao especfica.
Viso do produto
O WebBank um banco lder em seu segmento de mercado
e deseja disponibilizar uma nova tecnologia para acesso a
servios bancrios de conta corrente, atendendo assim uma
das principais solicitaes de seus clientes; obtidas na ltima
pesquisa de satisfao feita pelo banco.
O WebBank ir oferecer os principais servios utilizados por
seus clientes tambm por meio de aplicativo para dispositivos
mveis. O App ser disponibilizado para download em dois
formatos, um para o sistema operacional iOS e outro para
Android.
De acordo com o estudo feito pelo banco, os servios mais
acessados pelos seus clientes em seu site na web faro parte
da primeira verso do software. Dessa maneira, o aplicativo
dever oferecer apenas os servios bsicos de conta corrente.
Pelo aplicativo ser possvel que o cliente obtenha o saldo e
extrato de sua conta, alm dos servios de pagamento de contas e compra de recarga para celular. Cada movimentao na
conta corrente feita pelo cliente via aplicativo, ser tarifada de
acordo com a tabela de preos vigente do banco.
O App deve ser simples e interativo. Na tela inicial, o cliente
poder inserir o nmero da conta. Caso a conta seja vlida,
ter a permisso para efetuar seu login. Logo que for identificado, ser apresentada ao cliente a tela principal do aplicativo,
onde ser apresentado o saldo atual da conta e os servios que
podero ser utilizados.
Algumas informaes relacionadas ao projeto so:
Stakeholders: Cliente WebBank, Gerente de Produto
WebBank;
Premissas: O App ser disponibilizado no formato para iOS
e outro para Android;
Restries: Toda solicitao feita pelo cliente via aplicativo
dever ser autenticada pelo sistema de Segurana WebBank.
Caractersticas da Modelagem gil

A Modelagem gil (MA) tem por caracterstica incentivar as
equipes de projeto criar modelos de anlise simplificados, os
quais permitam um entendimento unvoco para todos do time
de como os requisitos definidos pelo cliente sero desenvolvidos durante a jornada de trabalho. Na prtica, a execuo
do processo de anlise feita de forma coletiva, trazendo um
entendimento comum e fazendo com que todos do time saibam
realmente o que dever ser feito durante a iterao.
Atualmente, grande parte das metodologias e processos de
desenvolvimento de software adotados pelo mercado utiliza
o Processo Unificado (UP) como modelo de referncia e, sabido que nem sempre todos os artefatos de anlise propostos
pelo UP so necessrios durante a execuo de um projeto.
Muitos dos problemas relacionados documentao de projeto
devem-se principalmente ao fato de se confundir que com a
UML (Unified Modeling Language) ou qualquer outra linguagem de modelagem, devemos documentar um projeto de
desenvolvimento de software. Na verdade, a UML pode sim
ser utilizada para a documentao, porm a mesma se mostra
mais eficiente quando aplicada comunicao.
Dessa forma, a excluso de modelos pouco relevantes ou com a
adoo de modelos hbridos de anlise, permite-se que durante
uma iterao a equipe se importe com apenas aquilo que realmente necessrio para o desenvolvimento, ou seja, no se gera algo
que no traga valor ao processo de desenvolvimento. Geralmente,
o trabalho em equipe deve manter seu foco para que:
Os modelos sejam vistos como artefatos da equipe, onde
todos tem possibilidade de alter-los a qualquer momento,
quando for preciso;
Os modelos propostos sejam de domnio pblico;
A participao dos stakeholders seja uma prtica efetiva na
modelagem coletiva;
O modelo seja algo de valor que venha da prpria equipe
para o entendimento da equipe.
Essa prtica faz com que as linguagens de modelagem, bem
como os artefatos empregados, sejam a maneira formal de
comunicao entre os envolvidos com o projeto de desenvolvimento. Vale ressaltar que equipes que atuam com MA, com
o desenrolar do projeto, tendem a produzir uma quantidade
reduzida de modelos durante o desenvolvimento, evitando
assim, o desperdcio de tempo.
Figura 3. Caractersticas da Modelagem gil
16
agilidade
Modelagem gil na definio da arquitetura

A construo de sistemas de informao
um processo crtico, principalmente quando
iniciado um novo projeto de desenvolvimento.
Inmeros fatores podem agir de maneira ativa
para o aumento ou diminuio do nvel de complexidade do projeto. A definio de interfaces,
padres e a infraestrutura tcnica do produto
podem ser determinantes para o sucesso do
empreendimento.
Baseado na gesto proativa de mitigao de
riscos presente no XP, o direcionamento da
soluo de arquitetura tratado pelo nome de
Spike. Um Spike pode ser visto como uma
maneira de tratar a arquitetura de um projeto
de forma a no impactar as entregas das hist- Figura 4. Diagrama de Implantao WebBank
rias de negcio do cliente.
O Processo Unificado, por sua vez, determina que a modeo direcionamento e orientao do time sobre um determinado
lagem da arquitetura deve ocorrer em duas fases distintas.
tema. Essas sesses ocorrem durante todo o projeto, porm
A primeira atendendo ao projeto de arquitetura de alto nvel,
so prioritariamente necessrias no incio. Essa tcnica prev
prevendo a construo de modelos que estabeleam a distribuique as perguntas levantadas pelo time potencialmente so
o dos componentes e os recursos de hardware disponveis.
resolvidas pelo prprio time!
Na segunda fase o projeto detalhado, de baixo nvel, as funDessa forma, o Brainstorming no exige que seja feita uma
cionalidades de cada mdulo sistmico so elaboradas desde
preparao prvia, com a definio de perguntas como feito
suas interfaces at o banco de dados. Ambas as fases descritas
em sesses JAD, por exemplo, pois faz a discusso emergir dos
pelo Processo Unificado so trabalhadas no XP, porm com
problemas enfrentados pela equipe e, com a possibilidade do
viso e direcionamentos diferentes.
grupo produzir seus prprios modelos, torna-se facilitada a
A aplicao da Modelagem gil ao contexto de um Spike
resoluo do mesmo pela prpria equipe durante as reunies
deve providenciar modelos simplificados, pois nessa etapa
dirias.
esses devem amparar o mnimo de informaes para que sejam
executadas as Provas de Conceito (POC), implementando os
Aplicao de artefatos corretos
conceitos de arquitetura e proporcionando testar a viabilidade
A aplicao de artefatos corretos determinante para o bom
do modelo.
desempenho da equipe, pois para cada situao e para aquilo
Para o exemplo do case WebBank, a primeira definio para
que se deseja representar existe uma demanda por conhecia estrutura necessria arquitetura do projeto seria represenmento especfico. A aplicao do artefato correto permite um
tada por um Diagrama de Implantao, conforme apresentado
melhor entendimento da demanda solicitada.
pela Figura 4. A simplicidade desse modelo representa aquilo
Em resumo, a forma como ser feita a comunicao deve ser
que necessrio para implantar a soluo no momento inicial.
convencionada e utilizada sem restries por todos os mem costumeiro dizer que devemos ter a informao necessria
bros da equipe de desenvolvimento e, havendo a necessidade
para que a equipe no passe fome! Ou seja, qualquer modelo
de comunicar e analisar sistemas, tais meios devem ser plemais elaborado, empregando maior quantidade de informanamente utilizados. Artefatos tcnicos de anlise de sistemas,
es, pelo o projeto estar em seu incio, pode representar um
tais como a Anlise Essencial, Estruturada ou Orientao a
desperdcio de tempo. Vale lembrar que a nica certeza que
Objetos devem ser o meio utilizado para esse fim.
haver uma evoluo dos modelos cada iterao.
Para isso, importante que os membros do time tenham
familiaridade com algum tipo de notao. UML, Diagramas
A importncia do brainstorming
de Fluxo de Dados e Modelos Relacionais so exemplos de
Durante o projeto necessrio que o facilitador e lder tcartefatos que precisam ser empregados e entendidos por todos
nico de MA faa sesses de Brainstorming com sua equipe,
durante as sesses de Modelagem gil.
apresentando ao time informaes suficientes para que se
J sabido que durante as sesses de Brainstorming a criao
fomente um amplo entendimento das necessidades do projeto,
de modelos ocorre de forma at intuitiva, pois o ambiente
instigando que todos se envolvam mais facilmente com a viso
propcio para tal. Logo, o cruzamento de informaes para a
e o contexto do produto que ser desenvolvido.
criao de novos modelos acaba ocorrendo de forma a aprimorar
Em MA, sesses de Brainstorming so de grande importno entendimento de todos com relao s demandas propostas.
cia, pois servem para explorar as potencialidades do grupo,
Imagine que estamos a postos com nossa equipe, logo no infuncionando tanto para a resoluo de problemas, como para
cio das atividades do projeto, prontos para iniciar a modelagem
17
do aplicativo WebBank. muito comum explorarmos aquilo

que nos parece bvio no incio do desenvolvimento do sistema,
principalmente em tecnologias voltadas para web ou mobile. A
cultura da interface um ponto forte desses modelos e deve ser
visto pela equipe como algo que direcione a especificao.
Pelas indicaes dadas no texto com a Viso do Produto
WebBank, o time consegue identificar aquilo que prioritrio
estar disponvel para o cliente durante sua interao com o
aplicativo. Para tal, a melhor sada para iniciar o entendimento
construir um prottipo de baixa fidelidade, conforme apresentado na Figura 5.
Inicialmente, com as informaes disponveis do texto, ficou
estabelecido que devemos apresentar ao usurio as seguintes
informaes: Login/Senha, Extrato, Pagamento de contas,
Recarga para celular, Nmero da conta e Saldo atualizado
da conta.
ser til para a confeco dos testes unitrios e de aceitao.

A construo do modelo visual deve facilitar o entendimento
do negcio por parte do time. Na primeira sesso de modelagem dos casos de uso do projeto, o resultado est representado
pela Figura 7.
Figura 6. Modelo de navegao
Figura 5. Prottipo de baixa fidelidade
Dado esse primeiro passo, para que tudo fique ainda muito
mais intuitivo, pode ser til definir como ser a dinmica
dos controles que estaro disponveis para o usurio durante
o uso da aplicao. Portanto, entender como as interfaces se
comunicam com o cliente e tentar estabelecer um modelo
passo a passo do aplicativo, simulando sua navegao pode
ser uma tarefa desejvel, facilitando a compreenso do comportamento do software. A equipe pode definir um Modelo de
Navegao do aplicativo para esse fim, conforme apresentado
pela Figura 6.
Orientao a testes
Figura 7. Modelo de caso de uso
A prtica de testar todo e qualquer modelo oriunda do

Extreme Programming (XP), onde por meio da aplicao
da tcnica TDD (Test Driven Development) os modelos so
certificados quanto sua veracidade e utilidade, por meio
de testes de aceitao do cliente e, unitrios, provenientes do
desenvolvimento.
Com base na descrio da Viso do Produto WebBank, j
podemos definir um modelo dos casos de uso envolvidos,
mesmo que em alto nvel. Portanto, o passo a passo da interao homem/sistema, com a dinmica especificada por escrito
Com a construo e especificao do modelo de casos de uso,

j possvel definir boa parte dos cenrios de teste. Em XP, a
orientao a testes alm de promover qualidade aos produtos
gerados, previne com relao propagao de erros. Com o uso
dessa tcnica, a validao dos modelos a cada iterao reflete
tanto na qualidade do produto, pois oferece maior confiabilidade ao cdigo gerado, como tambm permite que aquilo que
for enviado produo de fato, a verso mais estabilizada
dos modelos de anlise utilizados pela equipe.
18
agilidade
Criao de modelos paralelos

A criao de modelos paralelos serve para a elucidao
e entendimento de determinados conceitos do sistema, os
quais podem no ficar to claros com o uso dos demais
modelos institudos para o projeto. Os modelos que surgem em paralelo, por natureza so temporrios e devem
ser vistos como uma alternativa, podendo ser descartados
assim que os propsitos que determinaram sua construo
forem atendidos. Dessa forma, modelos paralelos na maior
parte das vezes, embora teis, so descartveis. Observe as
perguntas a seguir:
Como que o usurio inicia o uso do aplicativo?
Qual sua primeira ao ao entrar no sistema?
O aplicativo far a validao do usurio na aplicao?
Existir uma interface principal?
O usurio ter uma rea exclusiva para navegao com
controles personalizados?
Estas perguntas podem ser respondidas por meio de diagramas que indiquem o fluxo de aes. Dessa forma, at para
estruturar melhor o entendimento, os modelos j desenhados, contendo o Prottipo de baixa fidelidade e o Mapa de
Navegao, servem como base para o esboo dos fluxos (ou
atividades), que o usurio poder interagir pela aplicao.
comum que o time defina o entendimento do fluxo por
meio de uma representao do processo. Para isso, utiliza-se o
formato de um Diagrama de Atividades, conforme apresentado

pela Figura 8 para esse fim, definindo as etapas sequenciais
do processo desejado.
Figura 8. Diagrama de atividades
19
a utilizao de ferramentas CASE,

para que seja possvel municiar os
membros das equipes com toda
a informao necessria para dar
andamento aos seus trabalhos.
Modelagem incremental
Figura 9. Diagrama de sequncia
A modelagem incremental baseada no conceito de iterao, uma

vez que os times esto trabalhando
em regime de ciclos de desenvolvimento com tempo fixo. Dessa
forma, todo e qualquer modelo trabalhado pela equipe deve crescer,
ao passo que o projeto avana. O
incremento dos modelos inerente
necessidade da equipe que deve
sempre gerar apenas aquilo que
necessrio para dar prosseguimento aos trabalhos durante a iterao
do desenvolvimento.
Para exemplificar a modelagem
incremental, um dos melhores
modelos para essa representao
o Diagrama de Sequncia, apresentado na Figura 9. Esse modelo
tende a ser construdo agregando
novas informaes no decorrer do
desenvolvimento do sistema, sempre que necessrio.
Modelagem coletiva
Figura 10. Modelo relacional
Apresentao de modelos pblicos

Os modelos utilizados pelo time durante a modelagem e
anlise do projeto devem estar disponveis para todos os
membros da equipe. Preferencialmente esses modelos devem
ficar num local pblico e de amplo acesso ao time de projeto.
Para que haja essa exposio, necessrio que quadros sejam
disponibilizados, onde a equipe possa escrever e desenhar,
entre outras atividades pertinentes anlise.
A distribuio geogrfica dos quadros deve ser feita no local
de trabalho da equipe, uma vez que a comunicao visual
desses modelos providencia um maior interesse do time para
com o problema a ser resolvido. Em casos de equipes com
dispersas em locais geograficamente distintos, os modelos
devem ser publicados em local comum na rede, se possvel, com
20
A modelagem coletiva uma forma eficiente de equalizar

o conhecimento da equipe junto aos principais modelos
utilizados pela equipe durante o projeto. Vale lembrar que
a modelagem um trabalho de abstrao e, nem sempre, os
modelos desenhados pela equipe contemplam todas as necessidades do projeto ou mesmo esto validados. As sesses de
modelagem devem ter por objetivo promover a comunicao
entre os participantes do time, com o intuito de abordar apenas
o domnio da soluo a ser dada para um conjunto restrito de
requisitos.
Por tal motivo, a modelagem coletiva deve ser prevista como
prtica diria da equipe, antes mesmo do incio do desenvolvimento dos testes e do cdigo, pois a partir dela que os membros do time estaro aptos para implementar as orientaes
definidas pelos modelos analisados pelo time. A Modelagem
de Dados apresentada pela Figura 10 um modelo altamente
coletivo, pois em sua definio contm os conceitos que sero
trabalhados em conjunto pela equipe durante as iteraes.
No mesmo contexto do MER, se aplica tambm ao diagrama
de classes, representado pela Figura 11.
Modelar para comunicar

Sobre o aspecto da comunicao em Modelagem gil, Alistair
Cockburn por meio da sua metodologia Crystal, estabelece
agilidade
que a escolha por modelos menos formais e

mais interativos auxiliam o processo de entendimento das equipes e influenciam diretamente na performance dos times durante a
execuo de um projeto de desenvolvimento
de software.
Cockburn prope que a eficcia na comunicao est diretamente ligada proximidade entre os interlocutores, sendo que
a comunicao cara a cara mais efetiva,
alm de propiciar um melhor entendimento
aos envolvidos no projeto, que dialogam
entre si e resolvem os problemas de forma
direta e conjunta. Para isso ele prope um
grfico para definir a eficcia dos meios de
comunicao disponveis para as equipes
durante um projeto, o que pode ser visto
pela Figura 12.
Claramente, modelos voltados para comuFigura 11. Diagrama de classes
nicar tendem a ser temporrios. Por esse
modelo fica fcil perceber a importncia
nos ambientes de trabalho geis serem disponibilizados um
da comunicao interativa entre os membros de uma equipe,
uma vez que a utilizao de difusores de informao impriquadro do tipo Kanban e lousas para que a equipe possa
me uma maior disponibilidade naquilo que realmente se faz
rabiscar seu entendimento e ajustar de forma visual a coimportante durante o curso do projeto. Dessa forma comum
municao entre si.
21
a Demonstrao em Cdigo! Por mais que os modelos gerados

durante a anlise sejam teis para o entendimento do que
deve ser feito, um objetivo fim deve ser cumprido: a gerao
do cdigo. Dessa maneira, todo e qualquer modelo s poder
ser homologado uma vez que o cdigo gerado passe pelos
testes de aceitao e funcionais, garantindo que o modelo
atende s necessidades do negcio, funcionais, do produto
e principalmente, esteja aderente s expectativas do cliente.
Sem isso, nada feito!
Referncias:
Agile Software Requirements, Lean Requirements Practices for Teams
Programs and the Enterprise (2011): Addison-Wesley.
Ambler, S. (2002). Agile Modeling, Effective Practices for eXtreme Programming and the Unified Process: Wiley.
Beck, K. (2000). Extreme programming explained. Reading: AddisonWesley.
Figura 12. Diagrama de comunicao (Robustez)
Cockburn, A. (2002), Agile Software Development: Addison-Wesley.
Outros meios de comunicao, tal como e-mail, wiki, telefone,

conferncia podem ser utilizados, porm se mostram menos
efetivos quando se h a necessidade de centralizar as aes
que o time deve tomar durante a jornada de desenvolvimento.
Ou seja, a comunicao para que se torne fluda, deve estar
disponvel e acessvel no ambiente em que o time se rene para
o trabalho e isso parte fundamental para que seja criado um
ambiente com sinergia e orientado a resultados.
Os conceitos aqui apresentados mostraram uma nova forma
de aplicar as prticas definidas pelo Processo Unificado. Vimos
neste artigo que a abordagem gil vlida desde que ao final
exista um produto que possa ser utilizado.
Por tal motivo, de todos os itens relacionados s caractersticas da Modelagem gil, o ltimo sintetiza esse artigo:
Crispin, L., Gregory, J., Agile Testing, A Practical Guide for Testers and Agile
Teams (2009): Addison-Wesley.
22
Kroll, P., MacIsaac, B., Agility and Discipline made Easy, Pratices from OpenUp
and RUP (2006): Addison-Wesley.
Poppendieck, M., Poppendieck, T, Lean Software Development: An Agile
Toolkit (2003), Addison-Wesley Professional.

Planejamento e Gerncia
Nesta seo voc encontra artigos voltados para o planejamento
e gerncia de seus projetos de software.
Desenvolvimento gil: O papel do PMO no

mundo gil
Qual o papel do PMO no mundo gil
Fique por dentro:
Srgio Salles Galvo Neto

ssallesinf@hotmail.com
Gerente de Projetos certificado PMP, ITIL, Microsoft entre outras. Atuando na rea de informtica desde 1992 e, a mais de 10 anos liderando
equipes em projetos de desenvolvimento e implantao de softwares. Nos ltimos cinco anos,
atuando como Scrum Master em projetos em
diversas tecnologias e ramos de negcio.
e acordo com os princpios

do PMI (Project Management
Institute), entidade responsvel pela divulgao e padronizao de
boas prticas em Gerenciamento de
Projetos, atravs da publicao do guia
PMBOK (Project Management Body of
Knowledge), o corpo de conhecimentos
em Gesto de Projetos, recomenda-se
a existncia do chamado Escritrio de
Projetos (PMO). Nas empresas de maior
porte pertencentes ao seguimento de
desenvolvimento de software, mais
comum encontrarmos uma estrutura
mais voltada a projetos, so as chamadas
estruturas projetizadas. Geralmente,
estas empresas projetizadas possuem
um escritrio de projetos onde so
estabelecidos os padres relacionados
ao gerenciamento de projetos tais como
metodologias, ferramentas, modelos,
entre outros.
A crescente adoo dos mtodos geis por empresas do seguimento de desenvolvimento de

software, independentemente de seu porte, j
comea a afetar as estruturas tradicionais de
gerenciamento de projetos. Trata-se de uma
mudana na cultura nestas organizaes. O
escritrio de projetos e o executivo de projetos
passaram a ter outras e novas preocupaes
e responsabilidades para ajudar a garantir o
sucesso dos projetos. Neste artigo iremos descrever como os executivos de projeto devem se
adequar a esta realidade do mundo gil.
Iremos explorar, neste artigo, uma

viso geral sobre o papel dos escritrios
de projetos, dos responsveis pelos escritrios de projetos, conhecidos como
executivos de projeto ou PMOs, suas
funes, seus papis frente s organizaes. Faremos tambm a anlise de
alguns importantes relatrios emitidos
por instituies muito bem reconhecidas
no mercado como a ESI International e
a Version One.
A ESI Internationl elaborou um estudo
sobre a situao geral dos escritrios e
23
executivos de projetos (PMOs) ao redor do mundo, demonstrando o que mudou no ano de 2013 em relao ao ano de
2012. Em linhas gerais, o estudo da ESI representa o que os
PMOs vem enfrentado e seus principais desafios em termos
de futuro.
A Version One emite um relatrio anual sobre um estudo a
respeito da situao da adoo das metodologias geis por empresas de diversos tamanhos ao redor do mundo. Este estudo
busca responder questes tais como o aumento ou a reduo
de eficincia percebida nos projetos, atravs da compilao e
apresentao de quadros explicativos expondo os nmeros percentuais das opinies das pessoas pesquisadas neste estudo.
Outros e relevantes assuntos so tratados de forma objetiva
apontados neste estudo o qual o torna uma fonte de informao
muito rica para apoiar a tomada de deciso, principalmente
para aquelas empresa que ainda no optaram ou ainda no se
decidiram por adotarem uma metodologia gil.
Com o advento da popularizao das metodologias geis e
uma crescente demanda em sua adoo, as empresas do ramo
de desenvolvimento de software precisam adequar-se a esta
nova realidade. Em empresas de menor porte, a adoo por
um novo mtodo , sem dvida, mais rpido e fcil do que em
uma empresa de maior porte.
Uma empresa de maior porte precisa de maiores e mais
precisos controles sobre o andamento de seus projetos. Em
empresas deste tipo, geralmente optaram por criar uma
estrutura projetizada, a rea de projetos vista com grande
relevncia e deve estar alinhada com as estratgias da empresa.
de responsabilidade do executivo de projetos tornar esse alinhamento possvel e garantir que os projetos sejam concludos
conforme tais expectativas.
Os executivos de projetos, dentro dos escritrios de projetos, tambm so responsveis pela criao e manuteno da
metodologia de projetos da empresa, eles devem promover
uma melhoria contnua nos processos que compem a metodologia de projetos da empresa. Optar por adotar uma metodologia gil requer uma importante e decisiva participao
dele. Neste artigo veremos quais so as principais barreiras e
preocupaes encontradas as quais impedem ou dificultam a
adoo dos mtodos geis. Por outro lado, este artigo tambm
abordar os ganhos percebidos pelas empresas que optaram
em adot-los.
Escritrio de Projetos (PMO)

Em organizaes focadas em projeto, tambm conhecidas por
possurem uma estrutura organizacional projetizada, entendese que o corpo diretor adotou e compreende a necessidade de
criar, planejar, executar, monitorar e concluir projetos os quais,
geram resultados tangveis, estratgicos e que agregam valor
ao negcio ou atividade fim da empresa. Desta forma, existe
um compromisso entre todos da empresa em garantir que estes
projetos sejam concludos e de forma satisfatria. Satisfatrio
, to somente, classificado aquele projeto o qual cumpriu seu
escopo, dentro de um prazo e custo planejado, com a qualidade
esperada pelo solicitante.
24
A profissionalizao das equipes de projeto , certamente, o

meio mais seguro de garantir que as equipes obtenham sucesso
em seus projetos. O PMI oferece diversas certificaes conforme o nvel de escolaridade e de experincia do profissional de
projetos. Citaremos algumas das mais conhecidas e, lembrando
que no se limitam a apenas estas:
Certificao PMP Profissional de Gerenciamento de Projetos (PMP);
Certificao CAPM Profissional Tcnico Certificado em
Gerenciamento de Projetos;
Certificao PgMP Profissional de Gerenciamento de
Programas;
Certificao PMI-SP Profissional em Gerenciamento de
Cronograma do PMI;
Certificao PMI-RMP Profissional em Gerenciamento de
Riscos do PMI;
Certificao PMI-ACP Profissional Certificado em Mtodos
geis do PMI.
Ter bons profissionais, com conhecimento (habilidades e
tcnicas), experincia e certificaes, aliado ao apoio da direo
da empresa pode ainda no ser suficiente. Empresas voltadas a
projetos, por necessidade, precisam ser eficientes em diversos
aspectos e, a racionalizao de recursos (sejam materiais ou
humanos) uma das formas mais eficazes para controle dos
custos de um projeto, afinal de contas, um projeto conduzido
por pessoas (recursos) e, na maioria das vezes, representam o
maior custo e risco de um projeto.
Neste sentido de racionalizar os recursos humanos, comum
existirem equipes ou clulas de trabalho que trabalham de
forma a serem compartilhadas entre os projetos. Quando se
trata de desenvolvimento de software, temos bons exemplos
destas clulas ou equipes:
Anlise de Requisitos;
Testes;
Infraestrutura;
Arquitetura de Solues;
Controle de Qualidade.
Mas importante lembrarmos o fato de estarmos falando de
uma empresa a qual, mesmo com objetivo fim sendo a produo de software, tambm possui unidades de cunho administrativo e, consequentemente, estas unidades tambm recebem
demandas dos projetos. Podemos citar como exemplo:
Recursos Humanos (RH): contratar e manter os recursos
humanos dos projetos;
Compras: Aquisio de bens e servios para os projetos;
Tecnologia de Informao: especificar novos itens (hardware e/ou software) que sero usados como ferramentas
de trabalho para os projetos. No obstante, a manuteno e
evoluo dos ambientes de TI para suportarem as demandas
crescentes dos projetos.
Podemos perceber a grande e certa possibilidade de haverem conflitos de prioridades entre as demandas dos projetos.
Engenharia de Software Magazine - Desenvolvimento gil: O papel do PMO no mundo gil
planejamento
Iremos expor uma situao real para auxiliar no entendimento

destes conflitos ou concorrncias entre projetos.
A empresa produz software sob demanda a partir de projetos
contratados por seus clientes. Existem equipes agrupadas por
tecnologias Java, .Net e PHP. Estas equipes so compostas por
pessoas altamente capacitadas e comprometidas. Aps uma
negociao, a empresa vendeu um projeto o qual precisar ser
desenvolvido por duas das equipes, usando as tecnologias Java
e PHP, chamaremos este projeto de A. Ao mesmo tempo, um
segundo projeto fechado com outro cliente o qual precisar
das equipes de .Net e PHP, chamaremos este projeto de B.
neste momento que comeam os conflitos, tais como:
Projeto A: precisar contratar mais desenvolvedores Java;
Projeto B: precisar contratar mais desenvolvedores .Net;
Projeto A e Projeto B: precisaro dos mesmos recursos de
PHP;
Projeto A: precisar que a empresa adquira impressoras
fiscais de um novo modelo;
Projeto B: precisar de monitores maiores e que possuam
maior resoluo;
Projeto A e projeto B: precisaro de mais servidores para
hospedarem as verses de testes e homologao;
Projeto A e Projeto B: possuem prazos semelhantes onde os
testes ocorrero nos mesmos perodos de tempo.
Estas so apenas algumas situaes, digamos que at normais de acontecerem em empresas de desenvolvimento e,
no importa o tamanho que a empresa possua, o diferencial
competitivo de cada uma est em sua maturidade e estratgia
em lidar com situaes como esta.
Conforme dissemos anteriormente, esta empresa possui uma
estrutura projetizada e sabe como gerenciar projetos mas, de
acordo com o cenrio de concorrncia entre os projetos, quem
poder ajudar a definir as prioridades? O departamento de
Recursos Humanos ir priorizar as contrataes do Projeto A
ou do Projeto B? O departamento de compras dever priorizar
a compra dos Monitores para o projeto B ou a aquisio das impressoras fiscais do projeto A? A equipe de testes ter condies
de atender ambos projetos com a equipe atual e, ao mesmo tempo? Estas e outras perguntas inevitavelmente necessitaro da
interveno de algum mas, quem teria condies de decidir?
Podemos dizer o presidente ou o diretor mas, se analisarmos
friamente a situao, no seria papel de um presidente ou de
um diretor interceder em uma questo puramente operacional. Neste momento, no estamos avaliando a capacidade ou
disponibilidade, apenas observando a questo do ponto de
vista prtico, um presidente ou um diretor possuem funes e
responsabilidades muito maiores. Neste caso, seria necessrio
algum com um papel intermedirio, que entendesse a viso
dos projetos e como conciliar os conflitos.
O papel mais indicado seria do executivo de projetos ou
PMO (Project Management Officer). Este papel, para poder ser
devidamente executado, necessita de uma estrutura adequada, um lugar onde o gerenciamento de projetos seja pensado,
planejado, construdo para abrigar os itens necessrios para
a execuo dos projetos (ferramentas, softwares, etc.), onde

os projetos sejam executados e gerem resultados em sintonia
com a estratgia da empresa. Esta estrutura dedicada a projetos tem o nome de escritrio de projetos, ou PMO (Project
Management Office).
Possuir uma estrutura projetizada remete-nos a uma maneira
formal e/ou tradicional de conduo de projetos. Algumas
empresas, normalmente aquelas de maior porte, entenderam
a necessidade em criar um escritrio de projetos.
Para criar um escritrio de projetos, so necessrios investimentos significativos. Mas isso deve ser entendido no apenas
como investimento financeiro mas tambm, investimento de
tempo, em treinamentos, em confiana depositada em seus
colaboradores e, na quebra de paradigmas, promovendo uma
mudana profunda na cultura da empresa. Tais investimentos
so quase impossveis de serem mensurados em termos financeiros. Por outro lado, existe a confiana em se obter ganhos em
diversos aspectos, principalmente no que se refere a melhoria
de controles e gerao de indicadores.
A empresa passa a entender que, para atingir seus objetivos
comerciais, a melhor opo criar projetos que a levem a
atingir estes objetivos. Os projetos devem resultar em novos
produtos e/ou servios ou na evoluo destes produtos/
servios. Tais projetos iro manter a empresa competitiva e
atualizada frente ao mercado, um mercado cada vez mais
rpido e exigente.
Viso geral sobre o Escritrio de Projetos (PMO)

O escritrio de projetos possui a responsabilidade de estabelecer, de forma padronizada, os processos de governana dos
projetos, ou seja, dar transparncia e visibilidade de como os
processos de gerenciamento de projeto so criados, executados, monitorados e auditados. A partir do estabelecimento
dos processos, cria-se a metodologia de projetos da empresa a
qual pode adotar integralmente ou as partes das boas prticas
sugeridas no PMBOK (o que extremamente recomendvel)
desde que estejam em conformidade com a estratgia e cultura da empresa. A adoo de mais de um conjunto de boas
prticas tambm muito comum no ramo da engenharia de
software. Podemos citar o Prince2 como exemplo de framework
de gesto de projetos.
A metodologia, alm dos processos, tambm define as ferramentas (geralmente os softwares) e as tcnicas (modelos
matemticos ou conjunto de procedimentos) as quais sero
utilizadas nos projetos. O local e o tratamento das informaes
histricas dos projetos tambm devero ser estabelecidos no
escritrio de projetos, ou seja, todas as informaes geradas
pelos projetos devem estar em repositrios (sistemas de gesto
de arquivos) que alm de armazenar, devem cuidar do acesso
e versionamento destes arquivos. As informaes histricas
devem ser monitoradas e revisadas a fim de gerar indicadores
dos projetos. Estes indicadores devero ser criados para demonstrar a sade dos projetos e, serem utilizados na tomada de
decises no que se refere, essencialmente, melhoria contnua
dos processos e projetos.
25
Projetos podem ser organizados atravs de programas de projetos e, o conjunto de programas de projeto pode ser organizado
em portflio de projetos. Esta abordagem de organizao de projetos melhor executada e controlada no escritrio de projetos
pois, tambm funo dele prover a situao dos projetos. A
categorizao dos projetos em programas ou portflios uma
forma de demonstrar o alinhamento dos projetos estratgia da
empresa. Projetos de pesquisa, por exemplo, podem no estar
na estratgia da empresa at que surjam oportunidades (riscos
positivos) onde um ou mais projetos de pesquisa podem se
tornar estratgicos. Desta maneira, atravs do uso da avaliao
dos programas e/ou portflios de projetos, torna-se mais clara
a deciso em se executar ou no um determinado programa ou
projeto. O executivo de projetos dever garantir que estes projetos estejam alinhados com a estratgia comercial da empresa. o
mesmo que dizer: O sucesso da empresa depende do sucesso
dos projetos e do Executivo de Projetos respectivamente.
Executivo de Projetos (PMO)

Os escritrios de projetos podem ser estruturados de diversas
maneiras de forma a oferecer diferentes nveis de controle e
influncia dentro de cada organizao. No PMBOK, eles podem
servir para Suportar, Controlar ou Dirigir os projetos. Para
cada um, o nvel de controle e responsabilidade do executivo
de projetos tambm ser diferente.
Suportar significa que o escritrio de projetos ir disponibilizar uma estrutura mnima a fim de garantir o registro das
atividades, resultados obtidos e das lies aprendidas de cada
projeto. Em linhas gerais, o escritrio de projetos funcionar
como um repositrio de informaes garantindo que o passado
esteja registrado. O nvel de controle sobre os projetos ser
pequeno, bem como a influncia do executivo de projetos sobre
os projetos tambm ser modesto.
Quando o assunto controlar, quer dizer que o escritrio de
projetos possuir uma estrutura suficiente para estabelecer
padres e exigir o cumprimento destes padres. Para controlar
ser necessrio que os projetos sigam uma metodologia, um
conjunto de boas prticas, modelos, formulrios, ferramentas,
ou seja, tudo que esteja de acordo com a governana para que
o controle demonstre os resultados obtidos a partir da anlise
de indicadores definidos.
Dirigir assumir o controle dos projetos em si, ou seja, o executivo de projetos passa a administrar e gerenciar os gerentes
e os projetos durante todo seu ciclo de vida. Alm de suportar
e controlar, os resultados obtidos de cada projeto tambm
passam a ser de integral responsabilidade do escritrio de
projetos e do executivo de projetos.
Independentemente do nvel de controle esperado pela organizao, dentro de um escritrio de projetos, o PMO precisar,
alm de profundos conhecimentos sobre todos os aspectos
que envolvem a gesto de projetos, possuir certas habilidades
tais como: negociao, conciliao, e ser um mentor nato. E,
no menos importante, um executivo de projetos dever ter a
capacidade de traduzir a estratgia da empresa em forma de
projetos (ou programas e portflios). O objetivo desta traduo
26
poder estabelecer mtricas (indicadores) e, por conseguinte,

os parmetros para monitorar, controlar e ajustar os projetos de
forma que atinjam seus objetivos e que estes objetivos estejam
em conformidade com a estratgia da empresa.
Podemos perceber que as figuras do escritrio de projetos e
do executivo de projetos passam a ter um papel crucial para
que a empresa, a partir da estratgia comercial estabelecida,
atinja o sucesso atravs do resultado positivo dos projetos,
ainda mais quando o ramo da empresa o desenvolvimento
de software. Uma empresa atuante neste segmento precisar
acompanhar as mudanas tecnolgicas para manter-se competitiva no mercado.
Alm da evoluo da tecnologia, das linguagens de desenvolvimento, dos equipamentos, as metodologias tambm devem
evoluir. O bordo de que o departamento de tecnologia da
informao (TI) deve fazer mais (produzir mais) com menos
(custos menores) uma constante no cotidiano destas empresas
e, neste sentido, adotar uma metodologia gil uma maneira
de melhorar a eficincia e eficcia dos projetos.
Um retrato dos escritrios de projeto pelo Mundo

Em sua 3 Edio, a empresa ESI International emitiu um
relatrio chamado The Global State of the PMO. O estudo fez
uma anlise sobre a situao dos escritrios de projeto ao redor
do mundo em 2013. Neste estudo podemos encontrar diversas
informaes teis sobre o desafio dos escritrios de projeto bem
como a situao atual e um cenrio de tendncias para eles.
Enfatiza-se, neste estudo, como sendo vital a existncia dos
escritrios de projetos para contribuir na orientao ttica,
estratgica ou operacional no dia a dia dos negcios atravs
do envolvimento nas entregas de resultados dos projetos e
programas de projetos das empresas. Alguns resultados interessantes foram:
68% dos PMOs foram questionados sobre sua prpria eficcia
em 2013 (54% em 2012);
Significa o aumento da importncia do papel dos PMOs.
75% dos PMOs ativos esto empenhados em gerar sustentao de aprendizado e tambm criar um plano de carreira
para gerentes de projeto;
A grande preocupao na capacitao contnua e reteno dos
talentos nas empresas.
22% de todos os PMOs pesquisados operam no nvel estratgico das empresas;
Ou seja, a importncia do papel dos PMOs vem assumindo maior
relevncia ttica e estratgica para as empresas.
56% PMOs ativos informaram que mais de 75% dos projetos
foram entregues dentro do prazo/custo.
Com a adoo dos PMOs, a eficincia e eficcia dos projetos
notoriamente maior.
Em complemento, o estudo demonstra em alguns pontos
chave a viso geral e o valor atribudo aos PMOs, tanto no que
se refere ao escritrio de projetos, propriamente dito, bem como
aos executivos de projetos. A seguir a relao destes pontos
chaves demonstrados no estudo:
planejamento
Menor envolvimento em Treinamento: Com o aumento da

profissionalizao dos gerentes e das equipes de projetos, a
necessidade do PMO se envolver em treinamentos de capacitao tem sido cada vez menor;
Aumento da visibilidade sobre a eficincia dos PMOs: Houve
aumento de 15% no nmero de PMOs que passaram a observar
e medir sua prpria eficincia. Em outras palavras, os PMOs
tem tido a necessidade, cada vez maior, de demonstrar seu
valor atravs de mtricas tais como sucesso nos projetos e
retorno do investimento (ROI), completude de projetos dentro
dos prazos e custos;
Menos desafios: Em contrapartida sobre o aumento da
visibilidade de sua eficincia, os PMOs considerados ativos
e engajados em sua funo tem sido menos desafiados pelas
partes interessadas. O fato de serem menos desafiados pode
ser visto como uma melhora pois no se precisa desafiar aquele
que j possui um histrico de eficincia e eficcia;
Planos de Carreira: 75% dos PMOs considerados ativos e
engajados, esto empenhados em criar planos de carreira
para os gerentes e equipes de projeto. Um nmero bastante
expressivo quando comparado aos 41% obtidos no estudo no
ano de 2012;
Aumento na satisfao com os PMOs 42% dos entrevistados
consideraram como Excelentes ou Muito Bons os PMOs
de suas empresas;
Para medir a eficincia os PMOs adotaram mtricas tais
como:
- Aumento na satisfao de seus clientes 64%. Em 2012
este nmero era de 45%;
- Retorno do Investimento (ROI) 43%. Em 2012 este nmero
era de 24%.
Na Figura 1 podemos verificar o percentual de empresas que
responderam se tem, no tem ou se pretendem ter um PMO.
72% pode ser encarado como um excelente ndice demonstrando a preocupao das empresas em investir na criao e
manuteno dos escritrios de projetos. As empresas demonstram tambm o quanto valorizam e entendem a importncia
na adoo dos escritrios de projetos e a conscincia da necessidade do alinhamento das estratgias junto a rea de projetos.
Em termos globais, 46% das empresas possui um escritrio de
projetos. Neste estudo, mencionado que o grande desafio
dos PMOs lidar com o ambiente dos clientes em constante
mudana e a crise financeira global.
A adoo dos mtodos geis pelo Escritrio de

Projetos
Apesar de notria a eficincia obtida a partir da adoo dos
mtodos geis, o PMO dever estud-la de forma a verificar a
melhor maneira de adot-la. Adotar um conjunto de mtodos
geis significa alterar os processos atuais, gerar mecanismos
para medir sua eficincia e sua eficcia. Tambm representa
ceder de certos formalismos para dar espao agilidade.
Mas, na prtica, quais so os impactos reais em adotar os
mtodos geis? Para responder a esta questo, podemos citar
o 8 Relatrio Anual Sobre a Situao do Mtodo gil nas
empresas (State of Agile), patrocinado pela empresa Version
One, o qual apresenta uma viso gerao quanto a adoo dos
mtodos geis pelas empresas. Para garantir a integridade das
informaes, as pesquisas foram respondidas por 3501 pessoas
no ano de 2013 as quais trabalham em empresas do ramo de
desenvolvimento de software e TI ao redor do Mundo onde
66% so oriundas da Amrica do Norte e 22% da Europa.
Segundo este 8 Relatrio Anual, existem diversos fatores que
impedem a adoo dos mtodos geis, entre eles foram destacados trs como sendo os principais: a incapacidade de mudar a
cultura organizacional, resistncia a mudanas e tentar encaixar os elementos geis em mtodos tradicionais (No geis).
80%
72%
70%
60%
50%
40%
30%
20%
13%
10%
7%
4%
4%
0%
Yes
No
Don't Know
No
No
We have an existing PMO in

place
We have never had a PMO
Do not know if we have a PMO
Do not know if we have a PMO
We used to have a PMO but it

was disbanded
Figura 1. Percentual de empresas que possuem PMO
27
O estudo elencou outros itens classificados como barreiras os

quais podem ser observados na Figura 2.
Ainda observando o 8 relatrio anual, so citadas como as
maiores preocupaes em adotar os mtodos geis: Perda do
Controle de Gesto e a Falta de visibilidade de planejamento.
Na Figura 3, podemos observar as demais preocupaes expressas pelas pessoas entrevistadas pelo estudo.
As barreiras e as preocupaes citadas no 8 Relatrio Anual
representam a incerteza por parte das empresas em adotar os
mtodos geis. Porm, para estes que foram considerados como
principais, cabe uma ponderao do ponto de vista prtico
uma vez que no se pode avaliar um argumento apenas por
um nico ponto de vista.
Avaliao sobre as barreiras e preocupaes na adoo

dos mtodos geis
Em continuidade aos pontos mencionados no 8 Relatrio
Anual, sobre as barreiras A incapacidade de mudar a cultura
Figura 2. Barreiras para adoo dos mtodos geis
organizacional e Resistncia a Mudanas: para se manter em

um mercado cada vez mais competitivo e exigente, adaptar-se
uma questo crucial. A empresa que apostar em estratgias
e em processos imutveis, principalmente no ramo de desenvolvimento de software pode inviabilizar sua existncia.
A constante e rpida evoluo da tecnologia iro pressionar
estas empresas por mudanas. Empresas que se adaptam de
forma gil possuem mais chances de se manterem competitivas e at tornarem-se lderes graas inovao. Outro forte
argumento o simples fato dos processos de melhoria contnua
serem o alvo de modelos de maturidade tais como CMMi, MPS
.Br, ISO, entre outros.
Quanto a outra barreira mencionada Tentar encaixar os
elementos geis em mtodos tradicionais (No geis), para
analisar esta tentativa em tentar encaixar itens de um modelo
em outro, de naturezas diferentes preciso recorrer Relao
Custo versus Benefcio, esta a maneira mais coerente em se
verificar se vivel trocar uma coisa por outra coisa.
Em ateno s principais preocupaes em adotar os mtodos geis: Perda do Controle de Gesto e a Falta de visibilidade de planejamento so fundamentais para entender
o que exatamente est sendo perdido. Perda de Controle de
Gesto s ocorre quando se deixa de gerenciar algo e, no caso
dos mtodos geis parte da Gesto e Controle passam a ser
responsabilidade da equipe e do Scrum Master. Dizer que
haver falta de visibilidade de planejamento tambm precisa
ser reavaliado pois, nos mtodos geis, passamos a ter a viso
do Backlog do Produto.
Nos modelos de maturidade, tanto no CMMi quanto no MPS
.Br, ambos so unnimes na utilizao dos mtodos geis
desde que alguns controles sejam estabelecidos. Troca-se
a visibilidade do planejamento pelo backlog, estimula-se a
gerao de histrico de unidades de medida de performance
Greatest Concerns About Adopting Agile

Loss of management control
30%
Lack of up-front planning
30%
28%
Management opposition
24%
Lack of documentation
23%
Lack of predictability
20%
Lack of engineering discipline

19%
No concerns
18%
Inability to scale
17%
Dev team opposed to change

15%
Regulatory compliance
13%
Quality of engineering talent

Reduce software quality
9%
Figura 3. Maiores preocupaes em adotar Mtodos geis
28
planejamento
Reasons for Adopting Agile

Not important at all
Somewaht important
Accelerate time to market
3%
Manage changing priorities
3%
Better align IT/business

Increase productivity
Enhance software quality
Project visibility
Reduce Risk
Simplify development process
Very Important
21%
43%
17%
27%
28%
9%
30%
6%
12%
45%
40%
Improve tem morale
14%
41%
Enhance software maintainability/extensibility
13%
8%
35%
10%
38%
40%
7%
40%
45%
34%
15%
47%
36%
15%
18%
47%
35%
11%
19%
48%
15%
Manage distributed teams
23%
55%
Reduce Cost
Improve/increase engineering discipline
27%
42%
24%
6%
32%
54%
9%
3%
Highest importance
7%
36%
37%
5%
25%
4%
Figura 4. Razes para adotar Metodologias geis
para estrias. A complexa gesto de riscos substituda pela

tratativa de impedimentos da Sprint onde o Scrum Master
responsvel por remover estes impedimentos.
Existem algumas orientaes, nos modelos tradicionais de
gesto de projeto, quanto a no tentar gerenciar pacotes de
trabalhos cujo esforo seja inferior a X horas onde, o nmero
X estabelecido pela cultura da empresa. Esta regra conhecida como a regra das 80 horas onde, no h vantagens em
decompor atividades cujo esforo somando seja inferior a
80 horas. Neste caso, para pacotes de trabalho que possuam
menos de 80 horas de esforo, deve-se apenas informar a
sua completude ou no. Ao observarmos a execuo de um
projeto usando metodologia gil, durante o planejamento de
uma Sprint (Sprint Plan), promete-se uma entrega de algo de
valor em um determinado tempo, a meta da Sprint software
funcionando. Se analisarmos friamente, algo muito parecido
com a regra das 80 horas. Se existe a possibilidade de abrir
mo de certos nveis de detalhamentos sem que haja perda de
controle, igualmente, pode-se abrir mo de um detalhamento
em prol de ser mais gil.
Nos mtodos geis, como o Scrum, a equipe da sprint a responsvel pela sue completude conforme a meta estabelecida.
O cumprimento da meta planejada passa a ser a nova unidade
de medida. O objetivo dos mtodos geis que as equipes sejam auto gerenciadas, onde existe o fator motivador chamado
comprometimento. Ou seja, questo de honra cumprir a
meta dentro do prazo e isso transcende a qualquer indicador
ou processo, pois traz tona questes como responsabilidade,
auto realizao, satisfao profissional, entre outros.
A evoluo necessria, adotar mtodos geis trazem

comprovados ganhos mas, preciso que algum na
empresa observe, estude e pontue os impactos de forma
coerente e embasada. Recomenda-se experimentos de
adoo em uma equipe, cujo escopo de trabalho seja menos crtico frente s demais equipes da empresa. Medir
o desempenho e os resultados obtidos servir de base
na tomada de deciso. O executivo de projetos dever
estimular iniciativas como esta.
Vantagens comprovadas na adoo dos mtodos

geis
Continuaremos a analisar os resultados apresentados
no 8 relatrio anual onde so demonstrados nmeros
interessantes sobre as vantagens na adoo dos mtodos
geis. As trs razes mais votadas foram:
23% - Acelera o tempo de resposta em atender ao mercado
(Accelerate time to Market);
16% - Melhora a gesto de Mudanas de Prioridades
(Manage changing priorities);
15% - Propicia melhor Alinhamento entre TI/Negcios
(Better align IT/business).
A maioria das respostas da pesquisa constante no 8
Relatrio Anual foram centradas no maior e melhor foco
no cliente e em uma maior previsibilidade dos projetos.
Maiores detalhes podem ser observados na Figura 4.
Neste 8 Relatrio Anual, no que tange rapidez em concluir os projetos, houve um consenso onde 73% das pessoas
29
pesquisadas concluram que os mtodos geis reduziram o

tempo gasto nos projetos. Segundo o estudo deste indicador,
em menos de dois anos, a quantidade de pessoas que consideraram os mtodos geis como redutores de prazos dos projetos
mais que dobrou e, consonantemente, o nmero de pessoas
que achavam que os mtodos geis ou no reduziam ou eram
mais lentos, caiu significativamente. Observe a Figura 5 para
o quadro completo.
Na opinio da maioria das pessoas pesquisadas, houveram
melhorias significativas, que foram percebidas ano aps ano,
em todas as reas medidas. Com as pessoas mais experientes
na adoo e uso das metodologias geis, os maiores benefcios
para as empresas foram:
Melhor gerenciamento das mudanas de prioridade (92%);
Produtividade Maior (87%);
Melhor Visibilidade do Projeto (82%).
Does Agile is faster?

73%
12%
9%
6%
Slower time to
complete
Not yet completed

an agile project
Same time to
complete
Faster time to
complete
Figura 5. gil mais rpido?
Para visualizar melhor as reas metidas, observe a Figura 6

a qual demonstra os percentuais percebidos como: Melhorou
(got better), No houve Melhora (No Benefit) ou Piorou (Got
Worst) e, em complementao, a Figura 7, representa o chamado Quadrante Mgico onde demonstrado o alinhamento entre as reas que foram percebidas como mais importantes (Most
Important) e aquelas onde foram percebidas mais nitidamente
as melhoras a partir da adoo das metodologias geis.
O papel dos Escritrios e Executivos de Projetos na

adoo dos mtodos geis
Incorporar mtodos geis na metodologia atual de gerenciamento de projetos de uma empresa em seu escritrio de
projetos depender de uma correta viso sobre o tema pelo
executivo de projetos. No relatrio anual da empresa ESI
International (The Global State of the PMO 2013) existe uma
seo dedicada ao tema gil. A referida sesso, em seu incio,
apresenta a frase de um gestor a qual diz, em linhas gerais,
que o aumento das equipes geis e seu respectivo aumento de
poder ir diminuir o valor de um PMO centralizado.
Diminuir o valor pode ser interpretado, de forma mais coloquial, que o escritrio de projetos no precisar mais envolverse ou despender tantos esforos em conduzir projetos geis. As
atenes de um PMO devero estar mais voltadas a questes
como treinamento e suporte s equipes geis. Isso possvel
uma vez que as equipes de projetos geis partem do princpio
de serem auto gerenciveis, ou seja, atividades que antes eram
de responsabilidade do gerente de projeto agora so divididas
entre os membros da equipe. Como exemplo, podemos citar
como atividades agora de responsabilidade da equipe, do
Scrum Master e do Product Owner: a organizao e distribuio do trabalho a ser executada, a resoluo de problemas mais
Actual improvement from adopting agile methodologies

got Better
No Benefit
Got Worse
92%
Ability to manage changing priorities

Increased productivity
87%
11%
2%
Improved project visibility
86%
12%
2%
Improved team morale
86%
11%
82%
Reduce risk
82%
17%
1%
Faster time-to-market
83%
16%
1%
82%
16%
78%
Simplify development process

Improved/increased engineering discipline
74%
Enhance software maintainability/extensibility
75%
Manage distribute teams
15%
4%
Enhanced sotware quality
Better alignment between IT & buseness objectives
67%
Figura 6. Melhorias observadas ao adotar Agile
30
7% 1%
18%
22%
23%
29%
3%
2%
4%
4%
2%
4%
planejamento
Figura 7. Quadrante Mgico Melhorias na Adoo de Agile
corriqueiros, a comunicao direta com o cliente, entre outras.

Este comportamento nativo dos mtodos geis.
Em projetos tradicionais, o encerramento das fases e do
projeto como um todo, passam pela atividade de Lies
Aprendidas. Basicamente as Lies Aprendidas so registradas
em um documento, onde os participantes do projeto (equipe,
cliente, gerente do projeto, patrocinador e partes interessadas)
expressam o que foi bom, o que foi ruim ou o que poderia ter
sido melhor e as sugestes de melhoria (para corrigirem o que
foi apontado como ruim) durante a fase ou projeto concludo.
responsabilidade do gerente de projeto providenciar este encontro e o registro das lies aprendidas. O registro das lies
aprendidas deve ser encaminhado ao executivo de projetos e
este dever analis-lo e compor aes para que as sugestes de
melhoria sejam avaliadas e providenciadas a fim de que, numa
prxima fase ou projeto o problema no se repita.
Em projetos geis, no Scrum principalmente, o processo de
lies aprendidas executado a partir das Sprint Reviews ou
Sprint Retrospective. A principal diferena entre as Lies
Aprendidas e as Revises ou Retrospectivas das Sprints est
no curto espao de tempo em que estas ocorrem. O intervalo
entre uma Sprint Review e outra ocorrer de, em geral, de
trs a quatro semanas, dependendo do formato de Sprints
estabelecido pela equipe.
Eis que surge o primeiro ponto de ateno aos PMOs a
necessidade de se criar um canal de comunicao aberto entre
o Scrum Master e o Escritrio de Projetos pois, aquilo que
for apontado como item necessrio de melhoria, dever ser
analisado e viabilizado de uma forma muito mais rpida de
forma a no impactar significativamente as prximas Sprints.
Lembrando que as Sprints so como fases do projeto, porm
com um objetivo claro (meta da Sprint) o qual se refere a entrega de software funcionando. O PMO dever reservar um
tempo maior em ateno aos pedidos das equipes geis. Uma
necessidade apontada durante a Reviso da Sprint, caso no
seja resolvida at o final do planejamento da prxima Sprint
(Sprint Plan), pode ser encarado como um impedimento o qual
poder gerar entre atrasos ou at o cancelamento da Sprint.
Percebemos agora o quo importante ser a atitude do PMO
frente a este novo cenrio.
Outro ponto muito importante que o escritrio de projetos
dever auxiliar os gerentes de projetos e as equipe geis no que
se refere ao treinamento e capacitao das equipes. As necessidades por treinamentos e o ritmo acelerado de trabalhos iro
impor grandes restries de tempo para que as equipes possam
enviar as pessoas para serem treinadas.
Tomando como base o Scrum, como metodologia gil, um
papel indispensvel o chamado Product Owner, ou Dono do
Produto. Este papel impe um conhecimento muito profundo
sobre o que o produto (a ser criado e entregue pela equipe
Scrum) bem como o senso de prioridade. No Scrum, os requisitos
so tratados como estrias e, cada estria seria um conjunto de
requisitos funcionais e/ou no funcionais os quais so esperados como funcionalidades palpveis, parte do que se chama de
software funcionando. Uma Sprint precisa ser planejada e, este
planejamento passa pela anlise de um conjunto de estrias
priorizado pelo Product Owner. A equipe Scrum se rene e,
analisa o conjunto de estrias e emite um oramento. O resultado deste planejamento (Sprint Plan) a meta da Sprint, em
outras palavras, a quantidade de estrias cujo esforo orado
possvel de ser entregue dentro do prazo de execuo de uma
Sprint (geralmente de trs a quatro semanas).
31
O dono do produto e o Scrum Master, bem como a equipe e

o cliente, iro interagir intensamente para viabilizar a entrega
do produto que foi prometido. Para garantir o cumprimento
da meta da Sprint, como prtica do Scrum, a equipe se compromete a entregar a meta dentro do prazo. O responsvel por
considerar entregue e verificar os prximos itens (estrias) a
serem produzidos o Product Owner. As preocupaes de
capacitao, de um escritrio de projetos, no se limitam mais a
capacitaes em gesto de projetos, mas tambm, capacitaes
em reas de negcio e tecnolgicas.
No presente artigo acabamos por utilizar a metodologia gil
Scrum como referncia. Isto ocorre pelo fato de que a metodologia gil mais adotada pelas empresas. A metodologia Scrum,
somando-se com algumas varincias conjuntas de Scrum com
outras metodologias, somam 73% de adoo por parte das
empresas. Na Figura 8 podemos verificar a distribuio na
adoo das demais metodologias geis pelas empresas.
Agile Methodology Used

55%
60%
50%
40%
Podemos concluir, a partir do contedo apresentado neste

artigo que as empresas de maior porte, uma vez que possuam
uma estrutura voltada a projetos, necessitam de uma unidade
organizacional a qual suporte os projetos. A esta unidade organizacional se d o nome de escritrio de projetos e, o papel
responsvel pela criao, manuteno e evoluo desta unidade
organizacional o Executivo de Projetos.
A adoo dos escritrios de projetos bem como dos mtodos
geis foram amplamente discutidas e tiveram comprovada a
sua necessidade e importncia. Os mtodos geis contribuem
de forma significativa para que aumente o alinhamento dos
resultados dos projetos s expectativas comerciais das empresas (time to Market) e ainda, tornando mais fceis as mudanas
nas prioridades.
O PMO dever incluir em seu planejamento estratgico a
adoo destes mtodos geis demonstrando, principalmente, os
significativos ganhos por elas oferecido. Elaborar um plano de
adoo dos mtodos geis a partir da identificao dos pontos de
impacto na metodologia de projetos atual da empresa. O PMO
dever ainda, dentro de um contexto agora gil, organizar-se
para receber as solicitaes de melhoria originadas nas Revises
e Retrospectivas das Sprints e providenciar o devido suporte e
treinamento para as equipes geis, no somente sobre as questes geis, mas ainda sobre tecnologias relacionadas produtividade e capacitao em negcio para Product Owners.
30%
Links e Referncias:
20%
10%
1%
1%
1%
1%
2%
2%
3%
5%
7%
11%
10%
0%
ESI International - The Softer Side of Agile: Leading Collaborative Teams

to Success
http://www.esi-intl.co.uk/resource_centre/white_papers/agile/softerside.asp
Version One 8th Annual State of Agile Survey
http://stateofagile.versionone.com/?utm_campaign=2014%20State%20of%20
Agile%20Auto%20Responder&utm_medium=email&utm_source=Eloqua
Prince2 Gesto de Projetos de TI
http://www.prince-officialsite.com/
Figura 8. Uso dos Mtodos geis
De forma resumida, o papel do PMO ser o de patrocinar e

apoiar a adoo das metodologias geis e tornar o escritrio de
projetos um lugar para abrigar, alm dos gerentes de projetos,
os Scrum Masters. Para tanto, o PMO dever dedicar mais
ateno ao tema metodologias geis e verificar os ganhos e os
impactos na metodologia de gerenciamento de projetos atual
adotada na empresa.
Da mesma forma que houve um investimento na empresa em
tornar sua estrutura voltada a projetos (projetizada), chegado
o momento de uma evoluo para a adoo de mtodos geis
dentro da cultura da empresa. Diversos fatores foram colocados neste artigo de forma a auxiliar o PMO de empresas do
segmento de desenvolvimento de software em sua tomada de
deciso. So fatores tanto positivos como tambm negativos,
ou na verdade os desafios a serem enfrentados por estes profissionais de projetos.
32
PMO Maturity Cube, um modelo de avaliao de maturidade exclusivo

para Escritrios de Projetos. Autores: Amrico Pinto, Doutorando, Skema
Business School/ESC-Lille, Frana; Marcelo F. de Matheus Cota, Doutorando,
Universidade de So Paulo; Dr. Ginger Levin, University of WisconsinParkside, EUA.
http://pmotools.org/arquivos/PMOMaturityCube.pdf
Gerenciamento de Projetos Uma abordagem sistmica para planejamento,
programao e controle 10 edio. Autor: Harold Kerzner. ISBN 978-85212-0603-3.
The Implementation of Project Management: The Professionals Handbook. Autor: Linn C., Stuckenbruck. ISBN: 0201072602. ISBN-13: 9780201072600.

Planejamento e Gerncia
Nesta seo voc encontra artigos voltados para o planejamento
e gerncia de seus projetos de software.
O que faz um Gerente de projetos e um

Scrum Master?
Qual profissional sua organizao precisa?
Fique por dentro:
Srgio Salles Galvo Neto

ssallesinf@hotmail.com
Gerente de Projetos certificado PMP, ITIL, Microsoft entre outras. Atuando na rea de informtica desde 1992 e, a mais de 10 anos liderando
equipes em projetos de desenvolvimento e implantao de softwares. Nos ltimos cinco anos,
atuando como ScrumMaster em projetos em
diversas tecnologias e ramos de negcio.
efinir escopo, estabelecer planos para o projeto, criar a lista

de atividades e subatividades,
estabelecer cronograma, identificar riscos, avaliar e orar o impacto dos riscos
no projeto, calcular os custos humanos
e materiais, estabelecer os marcos do
projeto, estabelecer os indicadores de
acompanhamento do projeto, compor
o plano de faturamento ao cliente ou ao
patrocinador, administrar o oramento,
criar e manter um plano de comunicao, obter os aceites e interagir com o
departamento financeiro da empresa
para gerar as faturas e acompanhar a
liberao dos pagamentos junto ao cliente, entre outras responsabilidades. Estes
so alguns exemplos das atribuies de
um Gerente de Projetos segundo o PMI
(Project Management Institute). Se ao ler
estes pontos descritos anteriormente e
no pode reconhecer ou no entender
o significado deles porque talvez no
esteja familiarizado com os processos de
Tem sido uma prtica constante a publicao

de vagas e oportunidades de trabalho para Gerentes de Projeto requerendo conhecimentos
em metodologias geis e, da mesma forma, os
anncios solicitando profissionais ScrumMaster
os quais possuam conhecimentos sobre a metodologia PMI. Estamos abordando dois papis
fundamentais no processo de desenvolvimento
de software, porm, as organizaes que esto
procura de um profissional devem saber qual
papel e quais so os requisitos de conhecimento mais adequados s necessidades da organizao. Este artigo visa esclarecer as diferenas
entre estes papeis e auxiliar na escolha do papel
mais adequado para a organizao.
gerenciamento de projetos. Este desconhecimento por parte dos executivos

muito maior do que se imagina.
Segundo o relatrio anual do Standish
Group, o Chaos Manifesto do ano de
2012, o papel do Patrocinador foi questionado, pois caso o Executivo no possua
determinadas caractersticas, ele no
ter condies de atuar em plenitude e
poder colocar em risco ou at condenar
33
os projetos da empresa ao fracasso. No relatrio emitido pelo

Standish Group, foi dedicado um bom espao para abordar os
principais aspectos dos quais um Executivo deva possuir para
poder desempenhar plenamente suas funes e elevar o nvel
de sucesso dos projetos de sistemas como um todo. Em dois
tpicos, o relatrio do Standish Group abordou a personalidade
e a conduta dos patrocinadores e/ou executivos.
Dentre todos os tpicos, um dos que chamam ateno
foi o dedicado avaliao da conduta dos Executivos. Nesta
avaliao foram considerados itens como: a personalidade do
executivo (uma espcie de DNA de sua maneira de comandar),
as experincias do executivo (os diferentes tipos e condies de
projetos em que o executivo participou) e, o que necessrio
saber para ser tornar um bom executivo (conhecimentos e
habilidades). O resultado deste estudo demonstrou 50 pontos,
chamados de segredos, que um executivo deve possuir para
ser considerado como timo.
Dentre estes 50 segredos, um dos que mais chama a ateno
foi o segredo de nmero 3 intitulado como Entendimento
dos Processos de Gerenciamento de Projetos. Neste tpico,
a avaliao realizada demonstrou o nvel de dificuldade de
entendimento por parte dos executivos quanto aos processos
de gesto de projetos. Apenas 17% dos executivos avaliados
consideraram no ter dificuldades em entender os processos
de gerenciamento dos projetos (Figura 1), ou seja, 83% dos
executivos no entendem o que est sendo discutido em termos
dos processos e respectivas atividades envolvidas.
Diante deste cenrio, quase impossvel a interao em plenitude de algum a qual possua a responsabilidade de decidir e ordenar sobre um assunto do qual falta o devido conhecimento.
Chaos Manifesto 2012 - The Standish Group

% Dificuldade no Entendimento sobre Processos de
Gerenciamento de Projetos
17%
11%
Muito Difcil
Difcil
46%
26%
Pouco Difcil
Sem Dificuldade
Figura 1. Percentual de Dificuldade de Entendimento sobre os Processos

de Gesto de Projetos
Dentro de um projeto, existem papis e responsabilidades

e estes, so a base para a execuo do processo. Estamos
falando das pessoas, dos membros da equipe os quais sero
responsveis por diferentes partes e em diferentes momentos
no decorrer do projeto.
Depois de entendermos as metodologias, os papis de cada
um, iremos contextualizar a aplicao do papel do Gerente
de Projetos e do ScrumMaster em um projeto de desenvolvimento de software. Desta maneira, os executivos de sua
organizao tero uma ideia clara do perfil mais adequado
a ser contratado de acordo com as suas necessidades, sua
realidade operacional.
O papel do gerente de projeto, qual o objetivo das metodologias geis, o papel do ScrumMaster e, em uma abordagem
prtica, verificar onde os papis so corretamente aplicados
para a execuo de projetos de engenharia de software.
Definio de Projeto
Segundo oPMBOK (Project Management Body of Knowledge livro reconhecido como o Corpo de Conhecimentos sobre
Gesto de Projetos), publicado e mantido pela instituio americana PMI (Project Management Institute), em linhas gerais,
projeto um esforo temporrio empreendido para alcanar
um objetivo especfico. Projetos so executados por pessoas,
geralmente tm limitaes de recursos e so planejados, executados e controlados. Um projeto cria um produto, servio
ou resultado especfico.
Construir uma nova estrada, uma praa de pedgios, um
novo sistema de gesto de recursos, uma escola, um novo
servio de atendimento, so bons exemplos de projetos. Neste
momento, importante ressaltar a diferena entre Projeto e
Operao. Operao uma ao em si, o ato de fazer alguma
coisa de forma padronizada e repetitiva, so as aes que
sustentam as atividades comerciais.
Outro exemplo de projeto, aquele que objetiva alcanar um
resultado especfico pode ser considerado como um projeto de
melhoria. Um projeto sobre algo que j existe e que pode ser
modificado de forma a gerar melhores resultados ou atender
a mudanas de necessidades (requisitos).
Agora que o termo projeto est definido, precisamos entender como os projetos so executados / conduzidos. Para
tanto, preciso entender as metodologias voltadas para este
tema. Metodologias so conjuntos de processos (aes) e
ferramentas que auxiliam na execuo de uma determinada
atividade.
Viso geral sobre Gerenciamento de Projetos

Desta forma, se faz necessrio entender o propsito dos
processos de gesto de projetos, firmando o conhecimento
da definio de projeto e as abordagens das metodologias
que surgiram com objetivo principal de aumentar as chances
de sucesso dos projetos. Em se tratando de Engenharia de
Software, de desenvolvimento de sistemas, a adoo destas
metodologias vem se tornando cada vez mais indispensvel
para que se alcancem melhores resultados.
34
De acordo com oPMBOK, Gerenciar Projetos a aplicao

de um conjunto de conhecimentos, habilidades, ferramentas
e tcnicas de forma que as atividades do projeto alcancem
seus requisitos. Significam os itens imprescindveis os quais
aumentam as chances de sucesso dos projetos de atingirem os
objetivos estabelecidos.
O PMBOK estabelece que o Gerenciamento de Projetos deve
ser realizado atravs da correta aplicao e integrao de
Engenharia de Software Magazine - O que faz um Gerente de projetos e um Scrum Master?
planejamento
47 processos organizados e agrupados em cinco grupos de

processos. Os cinco grupos de processos so:
Iniciao;
Planejamento;
Execuo;
Monitoramento e Controle;
Encerramento.
Gerenciar projetos comumente inclui (mas no se limitam) a:
Identificar requisitos;
Enderear as diversas necessidades, preocupaes e expectativas das Partes Interessadas (Stakeholders) durante o
planejamento e execuo do projeto;
Estabelecer, manter e distribuir a comunicao entre as partes
interessadas, de forma colaborativa e eficaz;
Gerenciar as Partes Interessadas (Stakeholders) no sentido
de cumprir os requisitos do projeto e criar os entregveis (as
entregas) do projeto;
Balancear as limitaes concorrentes do projeto, que incluem
(mas no se limitam) a:
- Escopo;
- Qualidade;
- Prazo;
- Oramento;
- Recursos;
- Riscos.
Nota
As limitaes do projeto (constraints) esto completamente interligadas e devem estar
totalmente balanceadas. Caso uma destas limitaes seja afetada, automaticamente as demais
tambm sero. Por exemplo, se o Escopo for ampliado, consequentemente, ser necessrio mais
tempo (prazo), aumento nos processos de qualidade, aumento no custo (oramento), aumento
do uso dos recursos e, aumentam-se os riscos.
Contexto do Gerenciamento de Projetos

De acordo com oPMBOK, podemos ampliar a viso da Gesto de projetos agrupando os projetos atravs de Programas,
Portflios e o Escritrio de Projetos, mais conhecido como PMO
(Project Management Office).
Programas uma forma de agrupar projetos relacionados gerenciados de uma maneira coordenada, com objetivo de obter
benefcios e controles que no seriam possveis caso fossem
gerenciados individualmente. Para gerir os Programas, existe
o conceito de Gerenciamento de Programas. Um bom exemplo
de programa seria o desenvolvimento de um novo modelo de
carro, onde podem ser criados projetos independentes para
seus componentes como motor, cambio, freios, etc. Os programas ainda podem ser decompostos em subprogramas. Os
subprogramas geram projetos mais especializados de forma
que possam ser mais bem gerenciados.
Portflios so conjuntos de projetos ou de programas os
quais so agrupados para facilitar o gerenciamento eficaz do
trabalho para alcanar os objetivos estratgicos da organizao. Voltando ao exemplo do programa de um novo modelo
de carro, o portflio pode ser criado para novos modelos de

carro do tipo utilitrios, ou novos motores, etc. Os Portflios
tambm podem ser organizados e subdivididos em sub portflios, de maneira a facilitar a gesto e aumentar a eficincia
de seus resultados.
O escritrio de Projetos, o PMO, uma estrutura gerencial
cuja funo a de padronizar os processos de governana
relacionados a projetos. Esta estrutura facilita o compartilhamento de recursos, metodologias, ferramentas e tcnicas.
Dentre as responsabilidades do PMO esto, desde o suporte
aos gerentes de projeto, fornecer treinamento e capacitao,
gerir conflitos e at mesmo, responder pela gesto de projetos,
portflios ou programas.
Vantagens em se trabalhar com Projetos

A presso comercial para que as empresas tenham mais
lucratividade, reduzindo custos e aumentando a eficincia,
potencializado pelos fatores da globalizao remetem a necessidade das empresas serem mais geis. A estrutura tradicional
altamente burocrtica e a experincia tem mostrado que
essa estrutura no pode responder de modo suficientemente
rpido a um ambiente em constante mudana. Por isso, a estrutura tradicional deve ser substituda pelo gerenciamento
de projetos, ou outra estrutura temporria de gesto que seja
altamente orgnica e que possa responder muito rapidamente
conforme as situaes se apresentarem internamente e externamente empresa. O gerenciamento de projetos tem sido
amplamente discutido por executivos e acadmicos como uma
das possibilidades exequveis para modelos organizacionais
futuros que poderiam integrar esforos complexos e reduzir
a burocracia.
Uma empresa tem como opo trabalhar de forma projetizada
(orientada a projetos). Originalmente, as empresas trabalhavam de forma funcional. Uma vez que definimos o conceito
de projetos e a maneira com que eles devem ser tratados pelas
organizaes, cabe o entendimento de como as organizaes
esto estruturadas e qual deve ser a abordagem para a adoo
de uma estrutura orientada a projetos.
Saiba identificar o tipo da Organizao onde voc

trabalha
As organizaes estabelecem suas estruturas de forma a
obterem uma melhor maneira de administrar seus recursos
humanos, materiais e financeiros possibilitando atingir de
forma mais eficiente seus objetivos comerciais. Basicamente,
existem trs estruturas organizacionais: funcional, projetizada
e a matricial.
A estrutura organizacional funcional prega que cada funcionrio possui um superior e que as equipes esto organizadas por funo exercida (por exemplo: finanas, produo,
jurdico). Empresas de menor porte esto mais suscetveis a
adotarem esta estrutura funcional como um posto de gasolina,
borracharia ou um pequeno comrcio.
Na estrutura organizacional projetizada, existem os departamentos e cada um deles possui um gestor de projetos para
35
conduzir seus prprios projetos contando com o apoio de

outros departamentos. Esta abordagem traz tona a questo
da concorrncia dos recursos dos departamentos de apoio,
sendo requisitados simultaneamente pelos gerentes de projetos
dos demais departamentos da empresa. Por exemplo, a pessoa
responsvel pelas aquisies de uma empresa, inevitavelmente, receber solicitaes de compra de diversos gerentes de
projetos. Por vezes, receber solicitaes de compras de um
mesmo material porm com dias de diferena, fazendo com
que o comprador repita, desnecessariamente, todo o processo
de compra.
J a estrutura organizacional matricial prope a mistura entre
as estruturas funcional e projetizada. Desta forma, o projeto
ser conduzido conforme seu grau de relevncia, alocando os
recursos funcionais necessrios.
A estrutura matricial pode ainda ter trs aspectos: matricial
fraca, matricial forte e a matricial balanceada. Para entender
melhor cada uma delas, vamos explicar como esto organizadas cada uma delas a seguir.
A estrutura matricial fraca mantm o Gerente Funcional (responsvel por um setor, unidade organizacional ou grupo de
pessoas) com o maior nvel de autoridade. O gerente de projetos
est subordinado ao gerente funcional e depende dele e dos
demais gerentes funcionais para disponibilizarem os recursos
humanos e materiais para a execuo dos projetos.
J na estrutura matricial forte, o Gerente de Projetos que
tem maior nvel de autoridade, alocando os recursos humanos
e materiais necessrios ou at contrat-los externamente a fim
de garantir a execuo e entrega dos resultados dos projetos.
A estrutura matricial balanceada busca, como o prprio
nome diz, balancear as necessidades funcionais e dos projetos
dentro da empresa, ou seja, o Gerente Funcional e o Gerente de
Projetos possuem o mesmo grau de autoridade. Esta estrutura
pouco utilizada dada a complexidade em sua gesto.
O contexto dos projetos

O PMBOK no considerado como uma metodologia. Apesar
do mercado j ter se habituado a chamar de Metodologia de
Gesto de Projetos PMI, o foco do PMBOK concentrar um
conjunto de boas prticas e processos, de forma genrica. Fica
sob responsabilidade de cada empresa construir sua prpria
metodologia a qual pode ou no seguir as recomendaes que
constam no PMBOK. Para ser considerada uma metodologia, a
abordagem do PMBOK deveria estabelecer princpios e regras,
estabelecendo como exatamente os processos deveriam ser
executados quando na verdade, o PMBOK sugere processos,
ferramentas e tcnicas de forma que a empresa estabelea as
suas prprias regras para execut-los.
Considerando o exposto, passamos a estabelecer como premissa que as empresas, aquelas que optaram em trabalhar
por projetos, devam manter uma estrutura Matricial Forte.
Geralmente, a alta direo da empresa determina uma necessidade interna ou de um cliente, algo precisa ser criado
objetivando um resultado especfico. Pode ser construir uma
nova loja, ampliar instalaes, criar uma nova rea, implantar
36
um sistema de gesto (ERP), construir um novo sistema, elaborar um novo site ou uma grande mudana visando atender
a objetivos estratgicos da empresa. Ao solicitante ou cliente
do projeto d-se o nome de patrocinador. o patrocinador que
ir usufruir dos resultados alcanados no projeto e, aquele que
paga pelo projeto.
Mas, no basta saber o que se quer, ter em mente o objetivo
esperado apenas parte do projeto. A partir deste momento,
existe uma pessoa a qual dever transformar este objetivo
em um projeto e o profissional mais indicado o gerente de
projetos.
Como nosso enfoque a rea de desenvolvimento de software, iremos assumir que trataremos de um projeto de um novo
sistema (software). Desta forma, do ponto de vista prtico, a
alta direo da empresa precisar saber, basicamente, para entrega deste novo sistema a ser desenvolvido, quanto tempo ir
levar, quanto custar, como saber se o novo sistema atender
s expectativas, quantas etapas ou fases, como e quando sero
informados do avano do projeto, quais e quantas pessoas
sero envolvidas, como os problemas sero encaminhados e
resolvidos, enfim, sero necessrios documentos que definiro todos estes pontos, um informe executivo peridico entre
outros documentos.
Digamos que este o modo formal, ou melhor, profissional
de se gerenciar projetos conforme consta no PMBOK. O patrocinador e todas as partes interessadas (pessoas afetadas
direta ou indiretamente pelo projeto) sabero de todo o andamento, das suas atividades e responsabilidades, a partir das
informaes, documentos e relatrios emitidos pelo Gerente
de Projetos. Percebam que esta forma de conduo de projetos
generalista ao ponto de poder ser adotada em projetos de
qualquer natureza, desde a construo de uma ponte, de criar
uma nova linha de montagem em uma indstria automotiva
e, neste ponto que se destacam as boas prticas sugeridas no
PMBOK (PMI) e a necessidade de se criar uma metodologia
dentro da empresa a qual estabelea esta cultura de projetos
para que todos os envolvidos estejam integrados em todos os
momentos do projeto, entendendo o que est sendo, o que ser
feito e, principalmente, o que est sendo dito e informado sobre
o projeto. Este o contexto de um projeto.
Entendendo os conceitos de Engenharia de Software

Bom, j sabemos o que um projeto e como ele ser conduzido, mas em se tratando de desenvolvimento de software, existe
ainda a necessidade de se saber construir software e esta,
uma rea bastante abrangente, pois existem diversas maneiras
de se fazer software. Digamos que no incio da informtica,
a construo de software estava focada em resolver questes
muito cientficas e especficas tais como clculos balsticos,
para fins militares. Os computadores no estavam acessveis
ao pblico em geral, apenas em centros governamentais e
cientficos como universidades.
Com a popularizao da informtica, o mundo percebeu a
capacidade em utiliz-la de forma a reduzir as atividades repetitivas e, nesta ocasio, surgiram os chamados programadores,
planejamento
pessoas as quais detinham o conhecimento para instruir (programar) um computador, atravs de uma linguagem especfica
para executar as tarefas determinadas. Nesta ocasio, no
existiam mtodos ou normas as quais orientasse a construo
destes programas.
Dada a falta de mtodos e de profissionais frente a crescente demanda, no final da dcada de 1960, instaurou-se
a chamada Crise do Software. Para normalizar a prtica
de desenvolvimento de sistemas, surge a Engenharia de
Software trazendo consigo os princpios da engenharia
tais como: criao, construo, anlise, desenvolvimento
e manuteno, com um tratamento mais sistemtico e controlado. Com a engenharia de software torna-se possvel
especificar, projetar, planejar, construir, aferir e garantir a
qualidade dos resultados.
Com a evoluo da engenharia de software, foram criados os
chamados modelos de processo de software. Estes modelos visam a melhor representao do gerenciamento do processo de
software, trazendo maior visibilidade. Os modelos basicamente
determinam o ciclo de vida. Ciclo de vida, como o prprio
nome indica, significa a representao de todas as fases desde
a concepo at a finalizao do software entregue, quando
este passa a ser tratado como um produto e ser mantido em
um regime de operao de manuteno. So exemplos de
modelos de processo:
Sequencial ou cascata;
Desenvolvimento iterativo e incremental;
Evolucional ou prototipao;
Modelo em V;
Espiral;
Componentizado;
Formal;
gil;
RAD.
Podemos verificar que os modelos foram evoluindo na

medida em que o tempo e a maturidade foram passando.
Conforme foi dito anteriormente, estes modelos foram criados
para melhorar a visibilidade do gerenciamento do processo
de software bem como do gerenciamento do projeto. Esta
trajetria de evoluo dos modelos passa por diversos nveis
de exigncia, como gerao de documentos, processos de
aprovao e validaes entre fases. O melhor exemplo o
modelo sequencial (ou cascata) onde uma fase do processo
de desenvolvimento de software, s pode ser iniciada aps
a concluso e aceite da fase anterior. Este modelo sequencial
(cascata) est representado na Figura 2.
J nos modelo iterativo e incremental a proposta a de que
as fases que no possuam dependncias diretas podem ser
iniciadas em paralelo desde que as aprovaes (aceites) ocorram formalmente. A melhor representao deste modelo
demonstrada atravs do Processo Unificado (Unified Process).
O Processo Unificado prope a construo do software em
partes menores que, ao final, sero integrados para formar
um grande sistema. Este padro de desenvolvimento permite
possuir mais equipes trabalhando em diferentes partes do
software e de forma integrada. A Figura 3 representa o processo unificado (PU).
O PU foi evoludo e popularizado atravs da empresa Rational (agora pertencente empresa IBM) atravs da criao
do chamado Rational Unified Process (RUP). A Rational
desenvolveu um conjunto de ferramentas as quais representavam todas as fases de forma iterativa com a equipe de
desenvolvimento de software onde, alm de visualizar os
processos era possvel armazenar os artefatos gerados como
um repositrio e ainda navegar por todo seu contedo tal qual
um website. Este padro adota o processo de levantamento e
gesto de requisitos (as necessidades do solicitante), ou as funcionalidades que sero promovidas pelo software na forma
Figura 2. Modelo Sequencial (Cascata)
37
de casos de uso. Casos de uso so documentos criados para

descrever estes requisitos e todas as suas validaes como
regras de negcio, atores (pessoas envolvidas na utilizao
do software), cenrios (como a funcionalidade dever ser
tratada), fluxos, prototipao, relacionamento com casos de
uso, entre outros assuntos que auxiliem no entendimento do
que est sendo solicitado.
Sendo assim, o ponto central do modelo PU est justamente
na correta descrio das funcionalidades atravs dos requisitos e casos de uso gerados. So documentos que precisam de
levantamentos realizados por um analista o qual ir traduzir
as necessidades dos solicitantes em um formato adequado para
a equipe de desenvolvimento do software.
Outro fator interessante foi que o Rational Unified Process
(RUP) inseriu a abordagem de gerenciamento de projetos conforme estabelecida pelo Project Management Institute (PMI).
neste momento que a gesto de projetos e a rea de Engenharia
de Software se unem para oferecer, cada vez mais, visibilidade
para as partes interessadas e os patrocinadores do projeto. Em
resumo, tornou-se claro que o desenvolvimento do software
fazia parte de um projeto.
Os modelos de processos e os padres associados aos modelos
de desenvolvimento de software estavam concentrados em
guiar as atividades e normatizar o desenvolvimento em si. Por
outro lado, um projeto pode possuir mais de um software a
desenvolver e ainda cuidar de outras atividades relacionadas
ao projeto como a aquisio de um imvel, mobilirio e infraestrutura para receber a nova equipe que ir operar o novo
software que est sendo desenvolvido no projeto.
Ainda em se tratando de Modelos Iterativos, existem tambm
os modelos geis (Agile) nos quais so oferecidos um conjunto
de prticas que permitem a produo de software de maneira
mais rpida e eficaz. A base do desenvolvimento gil consiste
em um manifesto, chamado de Manifesto gil. A partir deste
Figura 3. Modelo Iterativo (Unified Process)
38
manifesto gil surgiram vrias metodologias tais como Scrum,

Extreme Programming (XP), entre outras.
O contedo deste Manifesto diz:
Manifesto para Desenvolvimento gil de Software
Estamos descobrindo maneiras melhores de desenvolver
software, fazendo-o ns mesmos e ajudando outros a
fazerem o mesmo. Atravs deste trabalho, passamos a
valorizar:
Indivduos e interaes mais que processos e ferramentas
Software em funcionamento mais que documentao
abrangente
Colaborao com o cliente mais que negociao de
contratos
Responder a mudanas mais que seguir um plano
Ou seja, mesmo havendo valor nos itens direita,
valorizamos mais os itens esquerda.
Tomando como base o que descrevemos anteriormente sobre
o PU, percebemos a ruptura na necessidade de tantos processos
e iteraes, documentos e aprovaes quando na realidade o
objetivo a entrega de um software funcionando. Construir
um software o qual atenda s expectativas deve ser feito atravs do contato direto entre a equipe de desenvolvimento e o
prprio solicitante (cliente).
importante lembrar que esta forma de construir software
s possvel graas evoluo e maturidade das tecnologias
e da cultura das pessoas envolvidas. Nas dcadas de 90 e
incio dos anos 2000, podemos dizer que a tecnologia at viabilizaria a adoo de uma metodologia gil mas a cultura das
pessoas, principalmente daquelas pessoas que contratavam
a construo de um software, estava muito longe. Tomemos
como exemplo a compra de um carro. Seria timo poder chegar
numa concessionria e dizer todos os requisitos desejados em
um novo carro e, numa linha de
montagem, estes requisitos iriam
sendo adicionados como rdio,
bancos de couro, ar condicionado, entre outros mas, e quando
chegasse ao ponto da escolha
do motor? Cmbio? Sistema de
Freios? Trao? Suspenso? Neste
ponto seriam exigidos conhecimentos muito mais profundos e
tcnicos os quais, nem todas as
pessoas possuem. Em se tratando
de software, seria a mesma situao onde o solicitante poderia
ser questionado sobre temas que
ele no conhece e nem pretende
conhecer devido a sua prpria
formao ou profisso.
Retornando ao ponto sobre os
processos e modelos, quando
abordamos o tema dos processos
planejamento
geis, mais uma vez, temos a clara viso de que a construo

do software possui necessidades especficas para garantir
mais flexibilidade e qualidade na entrega do software funcionando, que o software funcione conforme as expectativas
de quem o solicitou. E o projeto? Qual seria o papel do projeto
sendo que na verdade o item desejado o software entregue e
funcionando. O papel do projeto de disponibilizar controles
e envolvimento das partes interessadas a fim de garantir que
todo o processo de desenvolvimento de software, seja ele gil
ou no, funcione perfeitamente.
Um projeto formal pode ser gil?

A resposta sim, definitivamente. A base de um mtodo gil
o de abolir burocracias que dificultam atingir um determinado objetivo. Em nosso caso, estamos falando de construir
software e totalmente possvel entregar software, de qualidade, funcionando conforme as expectativas de forma gil e
documentada de maneira mnima e necessria.
A Engenharia de Software, com seus processos e modelos
permitiu o surgimento dos chamados modelos de maturidade. Maturidade se resume na adoo das reconhecidas boas
prticas da engenharia de software (metodologias, processos,
ferramentas e tcnicas) aplicadas pelas empresas que produzem software. O modelo de maturidade mais reconhecido
mundialmente o CMMI (Capability Maturity Model Integration)
criado pelo Software Engineering Institute SEI.
Como referncia em termos da maturidade no desenvolvimento de software, o modelo CMMI aceita plenamente a
adoo de metodologias geis desde que estas no interfiram
ou deixem de lado o cumprimento das boas prticas como
registros e controles.
O modelo CMMI fornece um conjunto de boas prticas geralmente aplicveis em grandes projetos que possuam altos nveis
de risco e ainda, oferece um conjunto de prticas de gesto e
suporte para implantao dos mtodos geis nas empresas,
independentemente do tamanho dos projetos. No cabe neste
artigo o detalhamento sobre o Modelo CMMI. Recomendamos
o artigo CMMI: Uma viso Geral publicado na edio nmero 44. O importante ter em mente o fato de que a maturidade
pode e deve andar em conjunto com a agilidade.
Da mesma forma que o modelo CMMI prev e apoia a adoo
das metodologias geis, o PMI (Project Management Institute)
tambm as reconhece. Em 2011 o PMI lanou uma nova certificao voltada aos praticantes dos mtodos geis chamada
de PMI-ACP (Agile Certified Practitioner ou Praticante de Agile
Certificado). Esta certificao visa demonstrar ao mercado
(empregadores) o nvel de profissionalismo em prticas geis
na gesto de projetos pelo praticante (profissional), aumentar
a versatilidade do profissional em ferramentas e tcnicas de
gesto de projetos, aliada com a capacidade de liderana de
equipes geis e a disponibilizao de uma estrutura voltada
treinamentos e iniciativas de desenvolvimento profissional.
39
Em resumo, as prticas geis podem e devem ser associadas

a processos formais de gesto de projetos. Isto no significa
abrir mo da rapidez que as prticas geis oferecem sem perder
o controle, qualidade e visibilidade oferecidas pela gesto de
projetos formal. Porm, tanto as prticas geis bem como o
gerenciamento de projetos formal, por si s, no garantem a
eficincia e eficcia do resultado. Precisamos separar as reas
e demonstrar o funcionamento destas prticas para elucidar o
contexto de desenvolvimento de software na vida real.
Gesto de Projetos e Mtodos geis na prtica

Falamos anteriormente da existncia das empresas e como
estas esto normalmente estruturadas. Agora necessrio que
o leitor identifique se a empresa em que est trabalhando do
tipo funcional, projetizada ou matricial para enxergar os paralelos e comparaes a seguir. Vamos estabelecer um cenrio
onde apresentaremos a aplicao dos conceitos de gesto de
projetos e prticas geis.
Voc trabalha numa empresa voltada ao desenvolvimento
de software, do tipo matricial forte onde o gerente de projetos possui a autoridade necessria para acionar os demais
gerentes funcionais e garantir que os projetos sejam executados seguindo a metodologia definida pela empresa. Esta
metodologia inclui a gesto de projetos formal (seguindo as
recomendaes do PMBOK do PMI) bem como as boas prticas
da rea de engenharia de software, entre elas o uso das prticas
geis do Scrum conforme sugeridas pelo modelo CMMI. No
entraremos no mrito da empresa estar ou no certificada em
um dos nveis de maturidade do CMMI.
Sua empresa venceu uma concorrncia para desenvolver um
software de gesto para um cliente do ramo de minerao.
Este projeto foi concebido a partir da apresentao de uma
solicitao de proposta (RFP Request For Proposal) onde foram
recebidas as informaes como escopo, prazo, qualidade. Esta
solicitao foi recebida pela rea comercial da sua empresa e,
foi encaminhada ao time de oramento. Este time de oramento
composto por membros da equipe comercial, do gerente de
projetos e at da alta direo da sua empresa.
O Gerente de Projetos em conjunto com as equipes funcionais
fizeram a anlise das solicitaes da empresa de minerao,
definiram um plano de projeto contendo: escopo, premissas,
restries, custos, riscos, controle e garantia da qualidade,
controle de solicitaes de mudanas, plano de comunicao,
gesto das partes interessadas, controle dos contratos de terceirizadas, gesto dos recursos, enfim, todos os tpicos descritos
na metodologia da empresa que tomaram como base o PMBOK.
E alm disso, iro adotar a metodologia gil Scrum. Neste
documento de plano de projeto, j se sabe, em linhas gerais,
o que precisa ser feito e como, quando ser feito e por quem.
De posse destas informaes, a equipe comercial pode gerar
uma proposta contendo valores e condies.
Chega a notcia de que a sua empresa foi escolhida pela
empresa de minerao para desenvolver o sistema de gesto
solicitado por ela. Neste momento, o Gerente de Projetos entra
em cena para alocao dos recursos e dar incio ao projeto.
40
Faz-se uma reviso do plano do projeto para garantir que tudo

o que estava na proposta comercial est contemplado no plano
e ento feita a reunio de incio (Kick-off). As providencias
administrativas so iniciadas, os recursos alocados e, o time
de desenvolvimento faz a reviso das estrias liderados pelo
ScrumMaster, organizam o backlog de estrias e planejam
as Sprints.
Para iniciar o desenvolvimento do sistema, a primeira coisa
que o time de desenvolvimento precisar do envolvimento do
cliente (as pessoas elencadas pela empresa de minerao) para
refinar e desenvolver as estrias. Neste meio tempo, o gerente
do projeto est providenciando contratos, contrataes de pessoas e materiais necessrios para a execuo do projeto.
Durante o planejamento da Sprint, o ScrumMaster e a equipe
de desenvolvimento no conseguem total disponibilidade do
cliente. Um impedimento registrado na reunio e o ScrumMaster aciona o Gerente do Projeto por telefone. O Gerente de
Projeto, verifica no plano do projeto e identifica no plano de
comunicao e na matriz de responsabilidades quem a pessoa responsvel do lado do cliente em resolver este problema.
O Gerente de Projeto entra em contato com esta pessoa, explica
a situao e solicita um encaminhamento. Passado um breve
perodo, o cliente assume que no havia entendido corretamente e que os recursos estaro disponveis no prximo dia.
Conforme o entendimento telefnico, o gerente de projetos
registra a ocorrncia no formato previsto da metodologia
da empresa e acompanha a soluo do impedimento junto
ao ScrumMaster. No dia seguinte as pessoas definidas pelo
cliente chegam empresa e desempenham o papel necessrio
para iniciar as atividades de desenvolvimento junto ao ScrumMaster e a equipe. O impedimento removido, registrado na
reunio diria e o processo de desenvolvimento segue, sem
maiores problemas.
De acordo com a evoluo das sprints, o ScrumMaster envolve e reporta o Gerente de Projetos quanto ao andamento
e, o Gerente de Projetos por sua vez emite os relatrios e
os documentos de aceite obrigatrios na liberao dos pagamentos e incio das prximas fases. O ScrumMaster e a
equipe de desenvolvimento tambm registram as mudanas
no backlog, as reunies de retrospectiva, planejamento das
sprints seguintes.
Ao final do prazo acordado, a equipe de desenvolvimento da
sua empresa entrega o sistema de gesto em funcionamento,
conforme as expectativas definidas pela empresa de minerao
e o projeto dado como finalizado com sucesso, entrando em
produo e em operao gerando os benefcios esperados. Enfim,
temos um caso de projeto bem sucedido utilizando o processo
formal e o gil de desenvolvimento de software em harmonia.
Entendendo os Papis do Gerente de Projetos e do

ScrumMaster
Com o sucesso comprovado de resultados ao se adotar as
metodologias geis, algumas empresas passaram a entender
que o papel do ScrumMaster seria suficiente para executar
os projetos. Da mesma forma que outras empresas tambm
planejamento
passaram a entender que um Gerente de Projetos tambm poderia assumir a funo de ScrumMaster. Diante da novidade e,
por vezes, da falta de informaes podemos considerar natural
que esta confuso entre papis ocorram.
Segundo o PMBOK (PMI), o papel do gerente de projetos a
pessoa definida por uma organizao responsvel por garantir que os resultados (objetivos) do projeto sejam alcanados.
Diferentemente dos gerentes funcionais (responsveis por
equipes funcionais ou unidades de negcio especficas) ou dos
gerentes operacionais (responsveis por garantir a eficincia
das operaes comerciais). Um Gerente de Projetos possui
responsabilidades e competncias prprias. Destacamos entre
as responsabilidades do Gerente de Projetos a responsabilidade de atender s necessidades das tarefas, das equipes e
dos indivduos, funcionando como um elo entre a equipe e a
estratgia pois, atravs dos projetos que as empresas podem
crescer e se manterem atendendo as crescentes e variadas
demandas do mercado.
Um Gerente de Projeto precisa deter muito mais do que conhecimentos sobre ferramentas e tcnicas, deve aliar a prtica
e ainda possuir habilidades gerenciais (soft skills) tais como:
liderana, motivao, possuir boa comunicao, influenciador,
tomada de deciso, confiabilidade, gesto de conflitos, orientao, entre outros.
O papel do ScrumMaster, diferentemente do Gerente de Projeto, o de facilitar o caminho da equipe para que esta possa
concluir os objetivos da Sprint, removendo impedimentos,
impedindo que influencias externas atrapalhem o andamento das atividades, mantendo o foco da equipe. Alm disso, o
ScrumMaster o responsvel pela aplicao correta das prticas do Scrum, capacitando e motivando a equipe, promovendo
as adaptaes necessrias ao processo de desenvolvimento de
software. No precisa necessariamente ser um Lder da equipe
de desenvolvimento, mas por outro lado, assume para si o
papel de ponto focal entre a equipe e os demais envolvidos no
projeto como o Gerente de Projetos e o Cliente.
Percebemos que algumas empresas, ao publicarem vagas
e oportunidades de emprego vem exigindo, cada vez mais,
que tanto o Gerente de Projetos possua conhecimento e experincia com Scrum e prticas geis bem como, exigindo do
ScrumMaster que possua conhecimentos e experincia sobre

gesto de projetos.
Entretanto, importante deixar claro que os papeis do Gerente de Projetos e do ScrumMaster so bem distintos e no
deveriam ser confundidos. Do ponto de vista prtico, conforme
expusemos neste artigo, um Gerente de Projetos possui muitas
responsabilidades as quais, vo muito alm de cuidar e garantir
que o software seja entregue conforme o combinado e, no
pode ficar junto da equipe aguardando que impedimentos
ocorram para poder resolv-los.
Da mesma forma, no seria justo que um ScrumMaster deixasse de resolver os impedimentos apresentados pela equipe
enquanto produz relatrios ou est em reunio junto ao cliente
para aprovao de pagamentos.
Links:
The Standish Group responsvel pela emisso do relatrio anual Chaos
Manifesto
http://blog.standishgroup.com/
Relatrio Chaos Manifesto 2011
http://versionone.com/assets/img/files/ChaosManifest_2011.pdf
http://versionone.com/assets/img/files/CHAOSManifesto2012.pdf
http://versionone.com/assets/img/files/ChaosManifesto2013.pdf
Project Management Institute (PMI)
www.pmi.org
Sobre a Certificao PMI-ACP (Agile Certified Practitioner)
http://www.pmi.org/Certification/~/media/Files/PDF/Agile/PMI_Agile_Certification_Content_Outline.ashx

41
Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros
Entendendo o Teste de Software por

Amostragem
Como utilizar amostragem em teste de software
Fique por dentro:
Clia Negrini
celianegrini@hotmail.com
Graduada em Anlise de Sistemas, cursando

MBA de Engenharia de Software na FIAP, certificada pela ISTQB (Certified Tester Foundation
Level) e pela Scrum Alliance (CSM- Certified
Scrum Master), com 13 anos de atuao na rea
de tecnologia, sendo os ltimos 8 anos dedicados a Qualidade de Software. Atualmente
coordenadora de testes e qualidade na empresa
VALID Certificadora Digital.
42
tcnica de teste por amostragem

tem como principal objetivo
permitir a inferncia estatstica em atividades de teste. Devido
impossibilidade de considerar todos
os dados de um sistema, retirado um
dado amostral que ser utilizado como
base e a partir dele sero realizadas concluses provveis em maior ou menor
grau, dependendo do nmero de dados
considerados e como essa seleo foi
feita, gerando assim concluses incertas.
Entretanto, quando essas informaes
so avaliadas seguindo certos princpios
que regem uma pesquisa, o grau de
incerteza da inferncia estatstica pode
ser mensurado.
Para realizar a mensurao do grau de
incerteza envolvido utilizada a teoria
da Probabilidade, que uma importante
rea da matemtica que tem por finalidade modelar a ocorrncia de eventos
potenciais de um experimento aleatrio
(resultados que no seguem um modelo
Engenharia de Software Magazine - Entendendo o Teste de Software por Amostragem
A amostragem geralmente utilizada quando

um conjunto de dados muito grande para ser
avaliado em sua totalidade, com isso espera-se
chegar a concluses vlidas sobre um conjunto de
dados grande quando utilizado apenas um dado
amostral. Para que isso acontea, a amostra deve
ser representativa, ou seja, ao utilizar um pequeno nmero de elementos, deve ser possvel a partir das informaes obtidas chegar a concluses
sobre o conjunto de dados maior. A amostragem
utilizada em diversos segmentos, mas quando
pensamos em teste de software, qual seria a melhor maneira de utiliz-la? Entender e distinguir
os mtodos de amostragem o desafio que iremos explorar com esse artigo. Sendo assim, este
artigo til para quem quer ter uma viso geral
de como a amostragem estatstica pode ser aplicada qualidade de software.
padro, mas esto todos presentes no

espao amostral).
Podemos utilizar a tcnica de teste
amostral de diversas formas, uma delas
se baseando nos casos de testes existentes, porm preciso tomar cuidado,
pois para atingir a expectativa necessrio que esses casos de testes sejam
en gen haria
criados de forma eficiente e objetiva, seno a amostra no

ser representativa o suficiente. As tcnicas de amostragem
so utilizadas geralmente por motivo de auditoria ou teste
de regresso, mas nada impede que seja implementada nas
atividades dirias de um testador.
Pode ser utilizada para testar um caso de teste especfico
como, por exemplo, um caso de teste que avalia um determinado campo e este possui muitas variaes. Nessa situao, as
tcnicas de amostragem auxiliam a determinar quais informaes sero inseridas para que no seja necessrio inserir todos
os dados possveis para realizar o teste.
Para utilizarmos de forma coerente a tcnica de testes por
amostragem preciso ter certa experincia no software que
ser testado, ou seja, ao menos uma navegao deve ter sido
feita na aplicao. Esse teste preliminar precisa acontecer para
que tenhamos conhecimento das reas mais crticas do sistema
e ento saibamos dividir nossa amostra de forma proporcional
a atingir os pontos desejados tentando ser o menos incerto
possvel. Desta forma seremos capazes de saber como e onde
tirar boas amostras do que preciso testar.
Se tomarmos como base o que feito em outras reas de
conhecimento, antes de investirem tempo e dinheiro em um
determinado solo, gua, etc., primeiramente retirada uma
pequena amostra do que precisa ser avaliado e a partir dessa
informao analisa-se se o solo frtil, se a gua impura e
assim por diante, concentrando ento seus esforos nos pontos
avaliados, conforme o resultado obtido. Com os analistas de
testes funciona da mesma forma; ao utilizar tcnicas de amostragem tomando como base o risco, concentram o tempo de
teste nesses pontos, otimizando assim seus testes. Isso muito
utilizado quando o tempo disponvel pequeno e a quantidade
a ser testada grande e com muitas variaes gerando assim
muitas combinaes. Com base nos resultados da amostragem
podem ser realizados testes adicionais para encontrar mais
defeitos nos pontos mais crticos.
Avaliar ou estimar atributos ou caractersticas de todo o
sistema atravs de uma amostra representativa pode ser mais
eficiente enquanto continua a fornecer as informaes necessrias. Mas para que isso seja possvel, preciso primeiramente
entender o que e como utilizar cada tcnica de amostragem.
Desta forma, exploraremos a seguir quatro mtodos de amostragem estatstica e dois no estatsticos.
Amostragem aleatria simples

A amostragem aleatria simples o tipo de amostragem mais
utilizada. Neste mtodo, cada item de um grupo de dados
tem a mesma probabilidade de ser selecionado como parte da
amostra, assim como qualquer outro item. Com isso possvel determinar que realizando verificaes aleatoriamente
possvel chegar a diferentes combinaes.
Trazendo essa tcnica para a rea de qualidade de software,
podemos dizer que essa amostragem auxilia e at agiliza na
deteco de defeitos. Geralmente utilizada quando os dados
que precisam ser testados so volumosos e o tempo disponvel
pequeno, isso no significa que o analista de teste no estava
igualmente interessado em todos os dados possveis de serem

inseridos ou casos de testes existentes, pelo contrrio, o desejo
sempre executar cada um deles, mas a escolha pela amostra
acontece por razes prticas, ou seja, utilizada quando um
dado a ser testado tem tantas variaes (em alguns casos pode
chegar a milhes) que seria impossvel checar at mesmo a
maior parte deles. Mas podem acontecer situaes em que a
quantidade no chegue na casa dos milhes, nem dos mil, mas
mesmo assim possui uma quantidade de variaes considervel, com isso a escolha pela amostragem pode ser uma deciso
prudente, considerando o cenrio existente na organizao e
o prazo estipulado para entrega do teste.
Uma das vantagens de se utilizar a abordagem de teste
aleatrio ocorre quando um programa j foi testado diversas
vezes com base em um mesmo conjunto de entradas de teste.
Em situaes como essa ele se torna mais preparado apenas
para o conjunto testado e no com outras possveis variaes,
com isso, quando utilizamos a abordagem da amostragem
aleatria, onde a cada momento podemos ter dados diferentes,
a probabilidade de encontrar erros e de se ter um sistema mais
estvel maior. Outra vantagem est na facilidade de se gerar
conjuntos de teste do tamanho desejado por meio de amostragem aleatria. Esta flexibilidade permite que a quantidade de
teste a ser executada possa ser adaptada para o tempo e para
o oramento disponvel.
No entanto, a amostragem aleatria quando utilizada para
um tipo de entrada especfica, pode no ser to eficiente quanto
a um teste estrutural. O teste estrutural utiliza o cdigo fonte
do software para orientar a seleo dos dados de teste, as entradas de teste so escolhidas de modo que cada membro de um
conjunto escolhido de elementos, por exemplo, a cobertura do
conjunto de declaraes, desvios condicionais, ou caminho
exercido por pelo menos um caso de teste no conjunto de teste.
projetado de forma a distribuir eficientemente o esforo de
teste em todo o cdigo do software com uma abordagem que
a tcnica de testes aleatrios no possui.
Por esse motivo, deve-se tomar cuidado e realizar uma anlise prvia para avaliar se a fase que o software se encontra
a adequada para se aplicar uma das tcnicas de amostragem.
Seguem alguns exemplos que podero auxiliar na hora de
realizar esse tipo de anlise.
Exemplo1: Um testador poderia sortear 10 entradas para um
caso de teste a partir de todas as possveis entradas vlidas
de um intervalo de 1-500 que tem por objetivo avaliar o comportamento de um campo numrico. Para fazer a escolha dos
10 nmeros que sero testados, o testador poder utilizar um
software que faz a gerao de nmeros aleatrios, ou ento
escrever os 500 nmeros em um pedao de papel e realizar o
sorteio de 10, ou quem sabe pedir para algum colega falar 10
nmeros no intervalo de 1-500, ou at utilizar-se do Excel. Tudo
vai depender da quantidade de nmeros que se tem para esse
teste amostral, para ento descobrir qual ser a melhor maneira de tirar essa amostra. O importante aqui ressaltar que
dos 500 nmeros possveis, todos tm a mesma chance de ser
escolhido. Mesmo que as pessoas tendem a evitar combinaes
43
como 1-2-3-4-5-6-7-8-9-10, ela tem a mesma chance de ser um

conjunto vencedor de nmeros como a combinao de 8-1522-29-69-97-103-301-303-402.
A amostragem aleatria simples um mtodo, como o prprio
nome diz, simples e a teoria por trs est bem estabelecida.
Existem frmulas padro para determinar o tamanho da
amostra, as estimativas e assim por diante, e estas frmulas
so fceis de utilizar.
Exemplo2: Agora vamos imaginar um software que precisa
sofrer regresso e que possui um milho de casos de testes
para serem executados, ou seja, se forem executados 1000 testes
seria possvel ter apenas 0,001% de cobertura da aplicao. Para
casos como esse preciso determinar qual o nvel de segurana
que desejado para essa execuo e a partir da determinar o
tamanho da amostra que ser utilizada para ento garantir a
qualidade da aplicao. Para isso, preciso primeiro definir
uma meta de qualidade que queremos garantir, vamos supor
que a meta de qualidade seja 99% livre de bugs, isso significa
que teremos 1% de chance das funcionalidades da aplicao
falharem. Para determinar nossa amostra, vamos utilizar do
mesmo trabalho matemtico que utilizado em pesquisas em
modo geral.
A primeira pergunta que precisa de resposta : Quantas
amostras precisamos para 1 milho de casos de testes se queremos ter uma margem de apenas 1% de falha? Existem muitas
calculadoras disponveis online e gratuitas que auxiliam a
determinar o tamanho da amostra. Utilizando dessa abordagem, foi possvel chegar no nmero 16.317 de casos de testes
que precisam ser executados para garantir 99% de confiana.
Se no final da execuo dos 16.317 casos de testes for obtido
100% de sucesso, possvel ento estabelecer uma confiana
de 99% para uma margem de 1% de erro. Mas se ao final no
for obtido uma margem de sucesso de 100% na execuo
preciso ento avaliar os pontos mais crticos e realizar uma
nova amostragem com base nesses pontos e avaliar se outra
tcnica se faz necessria.
Voltando a considerar que 100% dos 16.317 casos de testes
executados obtiveram sucesso, vamos utilizar dessa mesma
abordagem para realizar comparaes da quantidade de testes
X Nmero de amostras necessrias. Observe a Tabela 1, onde
o objetivo o mesmo, estabelecer 99% de confiana para 1%
de erro.
99% de Confiana para 1% de falha

Casos de Testes a serem executados
Nmero de amostras necessrias
100
99
1.000
944
10.000
6239
100.000
14.228
1.000.000
16.317
Tabela 1. Nmero de amostras conforme a quantidade de testes que

precisam ser executados
44
Com a comparao da tabela possvel identificar que aos

poucos testes adicionais so necessrios para alcanar o
mesmo nvel de qualidade para um software cada vez mais
complexo.
Existe tambm a possibilidade de se calcular a probabilidade
de um certo dado ser selecionado com base na amostra total
que possui. Supondo que existam 1000 casos de testes criados
para determinado projeto e com base na tcnica anterior foi
estabelecido que 944 precisam ser executados, qual a probabilidade de um caso de teste ser executado? O clculo nesse
caso bem simples, uma vez que o tamanho da amostra (n) e
a populao total (N), o clculo da probabilidade de um caso
de teste ser includo na amostra torna-se uma simples questo
de diviso.
Probabilidade de ser selecionado:
= (n N) x 100%
= (944 1000) x 100%
= 94,4%
Isto indica que cada caso de teste tem 94,4% de chances de
ser selecionado.
Uma desvantagem da amostragem aleatria ocorre quando
mesmo voc sabendo que seus casos de testes so divididos por
casos de uso, onde voc pode ter uma variao de quantidade
conforme o caso de uso, onde um caso de uso pode ter 20 casos de testes e outro 200 casos de testes, no utilizamos essas
informaes no momento de determinar a amostra. Com isso,
pode acontecer de no termos uma amostra to representativa
quanto a desejada. Nesses casos, vale a pena avaliar se outra
tcnica por amostragem no seria mais adequada.
Amostragem estratificada
A amostragem estratificada tem sido amplamente estudada e
utilizada desde a dcada de 1950. H muitos livros a respeito da
amostragem estratificada. No entanto, tanto quanto sabido,
a amostragem estratificada no tem sido aplicada no campo
da engenharia de confiabilidade de software.
A amostragem estratificada foi conhecida como um mtodo
de amostragem complexa, diferentemente do que vimos no
tpico anterior, o que poderia tornar os resultados de amostragem mais precisa. Ela funciona da seguinte forma, ao menos um representante de cada subgrupo dentro do contexto
do sistema precisa ser representado na amostra. Com isso
determinado que o primeiro passo para utilizar essa tcnica
de amostragem dividi-la em subgrupos, como podemos
observar na Figura1, em seguida so retiradas amostras aleatrias de cada subgrupo criado. O percentual de amostragem
para cada subgrupo pode ser definido da mesma forma que o
subgrupo tem de proporo dentro do sistema.
Exemplo 1: Vamos supor que o teste que precisa ser feito
referente a uma base de clientes, onde conforme o perfil do
cliente uma variao acontece na aplicao e ela precisa ser
testada. Aps realizar um levantamento identificado que:
70% dos clientes so caracterizados como pblico em geral,
en gen haria
30% possuem investimentos financeiros acima de 100mil e 10%

possuem investimentos financeiros acima de 1 milho.
A partir das informaes obtidas, iremos utilizar uma quantidade de cada grupo de clientes conforme sua proporo dentro
da aplicao. Com isso poderamos considerar nos testes 50
cadastros de clientes do pblico em geral, 20 cadastros de
clientes com investimentos financeiros acima de 100 mil e cinco
cadastros de clientes que possuem investimentos financeiros
acima de 1 milho. A amostragem estratificada tambm pode
provar igual nmero de itens de cada subgrupo. Com isso,
teremos uma amostra aleatria dentro de um mesmo sistema,
mas de um pblico diferente, o que aumenta a probabilidade
de se ter uma amostra mais eficiente.
Figura 1. Diviso da amostragem em subgrupos Crdito: Anderson

Vieira
Porm, existem desvantagens em se utilizar a amostragem

estratificada, uma delas o fato de ter que separar em grupos
cada item de interesse antes de se tirar a amostra requerida.
O outro ponto de ateno o cuidado que preciso ter no momento de separar os grupos da amostra, pois algumas variveis
podem estar relacionadas com alguns pontos, mas no para
os outros, o que complica e potencialmente reduz a utilidade
dos estratos. Outro cuidado que preciso ter que em alguns
casos (como projetos com um grande nmero de estratos, ou
aqueles com um tamanho de amostra mnima especificada por
grupo), amostragem estratificada pode requerer uma amostra
maior do que outros mtodos.
Exemplo2: Uma base de clientes de aproximadamente
100.000 registros possui aproximadamente 500 clientes com
um perfil de Cliente preferencial, desta forma dependendo
da estratificao que for feita, se essa informao sequer for
considerada provvel que esses clientes no estejam presentes
em nenhum dos estratos. Com isso, vlido ressaltar que a
amostragem estratificada procura assegurar que a amostra
ter a proporo equivalente do que desejado para a anlise
ou teste que precisa ser feito, ento preciso tomar o cuidado
de no momento de separar os estratos considerar para ao menos um deles os clientes com o perfil Cliente Preferencial.
Com isso poderamos determinar por exemplo que a amostra

dever conter cerca de trs clientes preferenciais em uma
amostra de 1000 registros (300: 100000 = 3:1000).
Amostragem sistemtica
Amostragem sistemtica outro mtodo de amostragem
estatstica. Um tipo de mtodo de amostragem probabilstica
em que os membros da amostra de uma populao maior so
selecionados de acordo com um ponto de partida aleatrio e
um intervalo fixo, porm peridico.Este intervalo de tempo
define o intervalo de amostragem que calculada dividindo-se o tamanho da populao pelo tamanho da amostra
desejada. Apesar da populao da amostra ser selecionada
com antecedncia, a amostragem sistemtica considerada
aleatria, pois apesar do intervalo ser peridico, o ponto de
partida aleatrio. Para iniciar uma amostra sistemtica
preciso seguir os passos:
1. preciso saber qual a quantidade de amostra que deseja
avaliar, por exemplo de 1 a N (onde N o tamanho total);
2. Determinar o intervalo de amostragem (K), para isso basta
dividir o nmero de unidades na populao pelo tamanho da
amostra desejada. Por exemplo, para selecionar uma amostra
de 100 a partir de uma populao de 500, voc precisaria de
um intervalo de amostragem de 500 100 = 5. Portanto, K = 5.
Com isso a seleo dever ser feita a cada cinco unidades para
acabar com um total de 100 unidades em sua amostra;
3. Escolha um nmero entre 1 e K aleatoriamente. Este nmero chamado de incio aleatrio e seria o primeiro nmero
includo na sua amostra. Usando o exemplo acima, voc deve
selecionar um nmero entre 1 e 5 a partir de uma tabela de
nmeros aleatrios. Se voc escolher 3, a terceira unidade em
seu quadro seria a primeira unidade includo na sua amostra;
se voc escolher 2, a sua amostra comearia com a segunda
unidade em seu quadro;
4. Selecionar a cada K a prxima unidade da srie. Com base
nos exemplos acima, poderamos formar a amostra de 100 com
incio aleatrio escolhido em 3. Ento teramos: 3, 8, 13, 18,
23... 495, 500. Usando o exemplo acima, possvel identificar
que podemos ter apenas 5 possveis amostras que podem ser
selecionadas com as cinco correspondentes partidas aleatrias
possveis:
1, 6, 11, 16... 491, 496
2, 7, 12, 17... 492, 497
3, 8, 13, 18... 493, 498
4, 9, 14, 19... 494, 499
5,10,15,20.....495, 500
Com isso possvel identificar que cada membro da populao pertence a apenas uma das cinco amostras e cada amostra
tem a mesma chance de ser selecionada, com isso cada unidade da amostra tem apenas uma chance em cinco. Essa a
mesma probabilidade de uma amostra aleatria simples, com
a diferena que na amostragem aleatria simples, qualquer
combinao de 100 unidades teria uma chance de fazer parte
45
da amostra, enquanto que com amostragem sistemtica, h

apenas cinco possveis amostras.
Em teste de software essa tcnica tambm pode ser muito
aproveitada, conforme temos nos exemplos apresentados a
seguir.
Exemplo 1: Voc precisa selecionar ao menos 1000 casos de
testes aleatrios, considerando um total de 50.000 casos de
testes existentes, utilizando a amostragem sistemtica, seria
simplesmente selecionar 50 casos de testes em cada grupo de
1000 casos, j que 50.000 / 1000 = 50.Cuidados devem ser tomados quando se utiliza amostragem sistemtica para garantir
que a lista da populao original no tenha sido ordenada de
uma forma que apresenta quaisquer fatores no aleatrios na
amostragem. Aps isso determinaramos um incio aleatrio
em 5, por exemplo, ento teramos que executar os casos de
testes 5, 55, 105, ...
Exemplo 2: Em uma auditoria solicitado realizar um teste
de aceitao na aplicao com base nos casos de testes existentes, o auditor define que deseja executar os casos de testes
um intervalo de 15 casos de testes e deseja iniciar do caso
de teste 5 de uma lista aleatria de todos os casos de testes
existentes. Desta forma, o auditor ento iniciaria do caso de
teste 5, em seguida 20, 35, 50 e assim por diante at realizar o
ciclo completo.
A vantagem da amostragem sistemtica que a seleo da
amostra fcil ( preciso apenas selecionar um nmero aleatrio no incio, o resto da amostra segue automaticamente)
e a amostra distribuda uniformemente sobre a populao
desejada.
A maior desvantagem do mtodo de amostragem sistemtica
que se existe algum ciclo na populao e esse ciclo coincide
de alguma forma com o intervalo de amostragem, os possveis
exemplos podem no ser representativos. Isto pode ser visto
no exemplo a seguir.
Exemplo 3: Vamos supor que necessrio executar uma
grande quantidade de testes em uma aplicao que possui
diversos mdulos, entre eles: Administrativo, Operacional e
Gerencial. Cada mdulo tem aproximadamente 1000 casos de
testes, incluindo testes vitais na aplicao (totalizando 3000
casos de testes). Ao ordenar a lista por mdulo, considerando
um teste vital como incio da sua amostragem, em seguida os
outros casos de testes, utilizando-se da abordagem de amostragem sistemtica tendo um intervalo de 50, pode acontecer
de executar apenas os casos de testes vitais de um mdulo, ou
ento apenas os casos de testes no vitais de cada mdulo. Com
isso, esse tipo de amostra no iria fornecer a viso completa
ou adequada da condio de cada mdulo.
em critrios de seleo como na amostragem estratificada, a

amostragem por cluster o mais heterognea possvel, ou seja,
uma amostra aleatria precisa ser feita dentro de um ou mais
grupos selecionados.
Esse tipo de amostragem utilizada em teste de software
como uma tcnica de seleo que tem por objetivo poupar
esforos, melhorar a visualizao dos resultados, reduzir o
tamanho dos testes e otimizar a deteco de falhas.
A amostragem por conglomerado dividida em duas fases,
na primeira necessrio escolher as reas que sero avaliadas,
na segunda feita uma seleo aleatria dentro de cada rea
escolhida.
Exemplo 1: A organizao tem mais de 20 projetos em fase
de testes, um novo gestor de Qualidade procura saber qual
a conformidade dos testes que so aplicados utilizando-se
de amostragem por conglomerado, com isso ele seleciona
aleatoriamente cinco projetos como representantes em sua
anlise, a partir desses cinco projetos ele determina quais sero os pontos que ele deseja visualizar, que podem ser desde
o grau de cobertura (baseando-se em casos de testes ou no),
percentual de testes automatizados e demais itens de interesse
da organizao
Amostragem por conglomerado ou cluster
Amostragem de julgamento
O quarto mtodo de amostragem estatstica chamado de

amostragem por conglomerados, tambm conhecida como
amostragem por bloco ou Cluster. Nesse tipo de amostragem
a populao que est sendo amostrada dividida em grupos
chamados clusters. Nesse tipo de amostragem, ao invs dos
subgrupos serem gerados de forma homognea baseando-se
Outro mtodo de amostragem no estatstica a amostragem

de julgamento. Na amostragem de julgamento, o responsvel
pelo levantamento utiliza-se de seu conhecimento ou experincia para selecionar os itens que sero amostrados. Um testador
mais antigo de profisso ou na empresa pode utilizar sua experincia de mercado ou na rea de testes para identificar mais
46
Amostragem casual
Existem outros tipos de amostragem que mesmo no sendo
estatsticos, podem fornecer informaes teis no momento
do levantamento de um dado de teste ou de realizar o teste,
um deles a amostragem casual. A amostragem casual leva
em considerao a convenincia. A amostragem casual normalmente mais rpida e usa tamanhos de amostra menores do
que outras tcnicas de amostragem, sua principal desvantagem
que uma vez que no tem base estatstica, generalizaes
sobre o item que ser avaliado devem ser feitas com extrema
cautela.
Exemplo1: Um gestor de testes pode pegar todos os casos
de uso de uma aplicao que j foi testada e aleatoriamente
escolher 1 para avaliar se os testes aplicados atenderam s
expectativas, se foi feito o planejamento completo desse caso
de uso e assim por diante, dependendo do objetivo da averiguao que deseja realizar.
Exemplo 2: Um campo que aceita at cinco caracteres numricos e o analista de teste escolhe um nmero aleatrio para
inserir no campo e iniciar o teste.
Simplificando, o teste casual feito rotineiramente na maioria
das empresas, s vezes, sem que as pessoas que esto realizando tenham cincia que esto utilizando de uma tcnica de
amostragem no estrutural.
en gen haria
rapidamente quais sero os pontos dentro de uma determinada

aplicao que apresentaro problemas.
Exemplo1: Uma nova verso da aplicao foi liberada no
ambiente de Homologao e a rea de Qualidade de Software
precisa garantir que a verso est funcionando corretamente,
assim como funciona no ambiente de Qualidade. Com base na
experincia, o testador pode executar os testes nos pontos mais
crticos da aplicao (que geralmente apresentam problemas,
ou que so vitais para a existncia da aplicao), para depois
realizar um teste exploratrio em toda aplicao e realizar a
liberao com a garantia solicitada.
Exemplo2: Em uma aplicao Web, o analista de teste pode escolher por iniciar os testes pelo Internet Explorer, pois pela sua
experincia o navegador que mais apresenta problemas.
Exemplo3: Em um sistema de gerao de relatrios, onde
possvel inserir filtro de data, o testador pode optar por tentar
filtrar informao referente a um nico dia como, por exemplo:
De 06/05/2014 a 06/05/2014. Isto porque conforme sua experincia, a maioria das aplicaes no trata o filtro quando a data
no tem um intervalo que no seja de ao menos um dia, nessas
situaes, embora haja informaes os relatrios costumam
no listar os dados.
Da mesma forma como o teste de amostra casual, o teste por
julgamento tambm muito utilizado sem que as pessoas saibam que esto utilizando uma tcnica. importante ressaltar
o valor dessa tcnica, pois ela enfatiza o quo importante a

experincia das pessoas e quo valiosas so as perspectivas
que cada um tem de uma mesma aplicao, quando utilizado
de uma experincia anterior, seja de outra empresa, ou apenas
de outro projeto.
As tcnicas de amostragem estatstica podem ser aplicadas
com sucesso na rea de qualidade de software. Entretanto,
assim como qualquer tcnica, preciso primeiro avaliar o
cenrio da organizao para identificar se a tcnica escolhida
atende as necessidades e realiza a cobertura desejada. Existem
diversas tcnicas em teste de software que so mais eficientes
que a tcnica de amostragem, contudo importante esclarecer
que essa tcnica utilizada em situaes onde o tempo disponvel curto e uma anlise precisa ser feita de imediato,
geralmente mais aplicada em testes de regresso ou para
situaes de auditoria.

47
Engenharia
Como aumentar a produtividade de sua

equipe de programadores
Veja como avali-los e estimular a produtividade
Fique por dentro:
A
Ivania Ramos dos Santos
ivania.ramos.santos@gmail.com
Bacharel em Sistemas de Informao pela

Faculdade Mater Dei (2008), especialista em
Engenharia de Software pela Faculdade Mater
Dei (2011). Atualmente Gerente de Servios
de TI da empresa AInova., professora na Faculdade Mater Dei, FESC e Sesi/Senai. Experincia
gesto de processos de qualidade utilizando
metodologia MPS.BR.
Marcos Vinicius De Bortolli

mvbortolli@bol.com.br
Especialista em Gesto da Informtica pela FAE/

CDE(1998) e Mestre em Inteligncia Computacional pela UFPR (2001). Foi gerente regional da
CPM - Filial Pato Branco. Atualmente Diretor
de Sistemas junto Secretaria de Cincia, Tecnologia e Inovao de Pato Branco, professor e
coordenador da ps-graduao em Engenharia
de Software na Faculdade Mater Dei, alm de
empresrio e escritor.
48
qualidade a totalidade das

caractersticas de um produto
ou servio que se baseia na
sua habilidade de satisfazer uma dada
necessidade. Outra definio de qualidade seria: software de qualidade
aquele que faz o que se espera que ele
faa. A falta de qualidade mais fcil de
definir falta de satisfao do usurio e
a medida usual da falta de qualidade
o relatrio de erros.
A garantia da qualidade de software
compreende uma variedade de tarefas
associadas a sete atividades: (1) aplicao de mtodos tcnicos; (2) realizao de
revises tcnicas formais; (3) atividades
de testes de software; (4) aplicao de
padres; (5) controle de mudanas; (6)
medio e (7) manuteno de registros
e reportagem.
A garantia estatstica da qualidade
reflete uma crescente tendncia de toda
a indstria para se tornar mais quantitativa em relao qualidade.
O objetivo deste artigo demonstrar o processo

de avaliaes profissionais peridicas sujeitas
premiao de programadores. Na primeira parte sero descritos os procedimentos que conduziram a avaliao, como classificao, tabulao
e apresentao dos dados. Posteriormente, sero descritos os procedimentos que conduziram
a premiao e finalmente os resultados obtidos
com a experincia realizada na empresa CPM
S.A. de Pato Branco. A discusso desse assunto
til para organizaes e equipes que buscam
exemplos de mtricas de produtividade.
Assim, a garantia estatstica de qualidade de software apoia-se na questo

quantitativa a respeito da frequncia de
ocorrncia de erros e inconsistncias nos
softwares rastreados ao longo de um
perodo especfico de tempo.
Para o software, a garantia estatstica
da qualidade (SQA - Software Quality
Assurance) implica em um primeiro
passo no qual as informaes sobre os
defeitos de software so coletadas e
dispostas por categorias. A partir da,
outros passos necessrios para realizar
a SQA e criar um processo de reviso
Engenharia de Software Magazine - Como aumentar a produtividade de sua equipe de programadores
en gen haria
so: (1) rastrear o defeito at sua causa; (2) considerar que 20%
do cdigo tm 80% dos defeitos; (3) corrigir os problemas que
causaram os defeitos.
As revises de software so um filtro para o processo de
engenharia de software. Ou seja, as revises so aplicadas
em vrios pontos durante o desenvolvimento de software e
servem para descobrir defeitos que possam ser eliminados. As
revises de software tm como objetivo purificar as atividades da engenharia de software. Assim, a atividade de teste
de software um elemento crtico da garantia da qualidade
de software e representa a ultima reviso de especificao,
projeto e codificao.
Com o advento das novas tecnologias e mtodos de trabalho,
e em face da diversidade de mo de obra, de clientes, fornecedores e parceiros, bem como da globalizao, muitos procedimentos e paradigmas esto sendo redefinidos. Isto objetiva
abrir espao para novas ideias, formas estratgicas e maneiras
de administrar as pessoas nas empresas, observando-se assim
um aumento na demanda por profissionais qualificados.
As mudanas so percebidas pelas organizaes e influenciam a atividade da direo, que muitas vezes, procura empregar ferramentas de gesto mais adequadas para a obteno
dos resultados organizacionais desejados.
O caso da CPM S.A era ajustado a esta realidade. Havia uma
urgente necessidade de aumentar a qualidade do servio desenvolvido na fbrica de Pato Branco, especialmente qualidade
do software.
Como era de se esperar, houveram vrias propostas relacionadas mudana de procedimentos internos, principalmente
referentes anlise esttica e teste dinmico de software.
Entende-se aqui como anlise esttica a anlise do cdigo fonte
para identificar problemas e o teste de software a execuo
do software com dados de teste atuais. Houve ento uma srie
de reunies que acabaram por resultar no seguinte trabalho
de avaliao e premiao de desempenho.
Classificao de programas
Os programas foram classificados por:
Nvel de complexidade, como Fcil, Mdio e Difcil;
Forma de processamento, como On-Line e Batch;
Tipo de solicitao, como Desenvolvimento (de programas
novos), Alterao (de programas existentes), Complemento (de
programas ainda no entregues) e Desenvolvimento com Base
(em outros programas);
Prazo de entrega (Normal e Urgente).
Foram atribudos bnus (pontos positivos) com pesos diferentes para cada categoria (Tabela 1). Estes bnus podem
ser cumulativos, ou seja, um programa padro pode valer
at 9 pontos, desde que seja uma solicitao de Desenvolvimento (3), com complexidade Difcil (3) e de processamento
On-line (3) = 9 pontos.
Como erros (pontos negativos), foram atribudos diferentes
pesos a partir de uma tabela elaborada em conjunto com todos
os envolvidos, tendo como base os procedimentos e padres da
prpria empresa. Estes erros dividem-se em categorias como:

(1) Erros de padronizao, que se referem a diferenas encontradas no programa com relao ao padro de programao
estabelecido pela fbrica; (2) Erros de lgica, que se referem a
problemas encontrados na lgica de funcionamento do programa e (3) Erros de procedimento, que se referem a problemas
de comportamento que prejudicam a equipe e os trabalhos
(Tabela 2). Todos estes erros tambm podem ser cumulativos
por programa.
Descrio
Valor
Solicitao de desenvolvimento
3,00
Solicitao de alterao
1,00
Solicitao de complemento
1,00
Solicitao de desenvolvimento com base em outro programa
2,00
Programa nvel fcil
1,00
Programa nvel mdio
3,00
Programa nvel difcil
6,00
Programa de processamento on-line
3,00
Programa de processamento batch
1,00
Programas com entrega urgente
3,00
Tabela 1. Bnus atribudos aos programas

Erros de padronizao conforme manual interno
Descrio
Valor
Erro classe 100
0,50
Erro classe 200
0,50
Erro classe 300
0,50
Erro classe 500
0,50
Erros de lgica conforme manual interno
Descrio
Valor
Erro classe 400 grave
3,00
Erro classe 400 mdio
2,00
Erro classe 400 simples
1,00
Erros de procedimento
Descrio
Valor
Entrega atrasada
1,00
Falta de bilhete
0,50
Descuido no pedido de fontes
0,50
Falta de esclarecimento de dvidas tcnicas
0,50
Falta de massa de dados
1,00
Mau levantamento de dvidas
1,00
Falta de testes
2,50
Faltar ou sair sem avisar
2,50
Faltar ou sair sem deixar responsvel
2,50
Preenchimento indevido de checklist
2,50
Falta de preenchimento relatrio de ocorrncias
2,50
Descuido no envio de fontes
2,50
Tabela 2. Erros atribudos aos programas
49
Tabulao e apresentao dos dados

Aps os testes realizados em cada programa por Analistas
de Controle de Qualidade (ACQ) da prpria fbrica, foram
lanados os bnus (pontos positivos) e diminudos os erros
(pontos negativos) de cada programador.
A diferena entre os bnus e os erros gera uma pontuao.
Esta pontuao dividida pelo nmero de programas desenvolvidos pelo programador resultou em uma mdia. Para verificar
o aproveitamento do programador, calculou-se o percentual de
erros frente ao total de bnus, variando de 0 a 100 %.
Finalmente, para fins de classificao final das posies, foi
estabelecida uma nota para cada programador, calculada com
base na soma ponderada da mdia e do aproveitamento. Em
todo o processo de tabulao e apresentao dos dados foi utilizado um sistema informatizado desenvolvido especialmente
para este fim, denominado guia.
Premiaes
Para que se possa realizar adequadamente a garantia de
qualidade de software, dados sobre o processo de engenharia
de software devem ser compilados, avaliados e divulgados.
Ento, de posse do relatrio mensal de classificao dos
programadores, uma comisso composta pelos Analistas de
Controle de Qualidade (ACQs), pelo Planejamento e Distribuio de programas (PLD), pelo Controle de Tarefas (CTF), pelo
Apoio a Linguagens (APL) e pela gerncia local da fbrica,
analisou os resultados objetivamente de acordo com critrios
estabelecidos.
Os programadores tambm foram analisados subjetivamente,
utilizando-se critrios como comportamento de equipe, proatividade e relacionamento interpessoal. Esta comisso ento definia via votao aberta pelos trs melhores programadores.
A seguir, eram divulgados os resultados dos primeiros colocados a serem premiados, bem como relatrios estatsticos de
qualidade. Estas premiaes eram determinadas no incio do
ms seguinte aos testes. O prmio estabelecido foi o pagamento
de valor equivalente a 50 horas de salrio divididos entre os

trs primeiros colocados do ms.
Apresentao dos resultados

Durante um determinado ms, todos os resultados mensais
foram compilados e analisados, resultando em uma tabela
final com o desempenho da fbrica (Tabela 3). Nesta tabela foi
acrescentada uma coluna denominada Complexidade, que determina a complexidade mdia dos programas desenvolvidos
na fbrica. Esta Complexidade obtida pela diviso do total
de Bnus pelo nmero de Programas (Pgms).
Observa-se que a complexidade mdia dos programas
aumentou em mdia 7% do 2 semestre para o 1 semestre,
enquanto que o nmero mdio de programas desenvolvidos
diminuiu apenas 2% no 2 semestre. Ou seja, os programadores fizeram mais programas de Complexidade Difcil em
menos tempo.
Outro dado importante a reduo drstica do nmero de
erros internos cometidos pelos programadores. O nmero de
erros total caiu de 1151 erros em maro, quando uma nova
turma de programadores iniciou no processo, para menos de
23 erros em dezembro. Isto configura uma reduo de 98% no
nmero de erros por ms (ver Figura 1) considerando os dois
limites, 1151 e 23. No segundo semestre, a reduo da ordem
de 86,7% frente ao primeiro semestre.
Da mesma forma, o aproveitamento total dos programadores
aumentou muito de um semestre para outro. Passou de 52,4 %
em janeiro para 98,4 % em dezembro, com um crescimento de
quase 46% de um semestre para outro (ver Figura 2).
Em perguntas informais dirigidas aos programadores e
analistas de controle de qualidade envolvidos no processo
avaliativo, descobriu-se que os principais fatores que motivaram a alta qualidade podem estar nas seguintes hipteses:
(1) a clareza dos objetivos de qualidade, (2) a premiao
financeira dos melhores resultados do ms, (3) a responsabilidade diante do controle sobre os procedimentos efetuados,
Resumo do desempenho dos PRG

Ms
Bnus
Erros
Pontuao
Pgms
Complexidade
Mdia
Aproveitamento
Nota
01
1684
801,0
883,0
312
5,4
2,8
52,4
41,94
02
1023
163,5
859,5
198
5,2
4,3
84,0
66,12
03
1461
1151,0
310,0
242
6,0
1,3
21,2
17,73
04
1385
501,5
883,5
282
4,9
3,1
63,8
49,30
05
950
202,5
747,5
185
5,1
4,0
78,7
61,79
06
1060
92,5
967,5
225
4,7
4,3
91,3
69,53
07
1287
80,5
1206,5
244
5,3
4,9
93,7
74,34
08
1223
80,0
1143,0
214
5,7
5,3
93,5
76,40
09
1796
97,0
1699,0
357
5,0
4,8
94,6
73,74
10
1281
75,5
1205,5
216
5,9
5,6
94,1
78,06
11
854
30,0
824,0
151
5,7
5,5
96,5
78,56
12
1411
23,0
1388,0
239
5,9
5,8
98,4
81,45
Tabela 3. Resumo do desempenho dos programadores
50
Engenharia de Software Magazine - Como aumentar a produtividade de sua equipe de programadores
en gen haria
(4) a competio entre o programador e os demais colegas de

trabalho, (5) soma de todas as alternativas anteriores, porm
com pesos diferentes.
Alm disso, ainda em perguntas informais somente com
os analistas de controle de qualidade responsveis pelas
avaliaes, a relao de desempenho dos programadores
praticamente espelhava a realidade da fbrica, inclusive em
comportamento. Segundo relato informal destes analistas,
os programadores com melhor desempenho da lista eram
tambm os de melhor comportamento e relacionamento
dentro da fbrica.
relacionamento podem ser preponderantes para um ambiente

de programao adequado e de alta produtividade.
A avaliao profissional peridica sujeita premiao aumentou em 98% o aproveitamento dos programadores aps o
anncio da primeira premiao. Esta avaliao tambm criou
uma cultura de qualidade na empresa que se estendeu por
todo o perodo de aplicao do processo avaliativo.
Nestes tempos de busca contnua pela qualidade, o processo
de avaliao aliado a uma poltica de recompensas demonstrou
ser eficaz e eficiente no objetivo de aumentar constantemente
o ritmo e a qualidade da programao na empresa.
Quanto aos fatores que motivaram realmente o resultado,
cabe um estudo futuro que delineie claramente o peso de cada
hiptese no conjunto. Outro resultado que merece um aprofundamento a relao do comportamento e relacionamento
do programador com seu desempenho de programao.
Links:
[BATCH] Plano Bsico de Ensaios Mainframe Batch, IT-07-ACQ-002, reviso
2, CPM S.A.,2001
[FAE] Capital Humano, FAE Business School, Curitiba: Associao Franciscana
de Ensino Senhor Bom Jesus, 2002.
Figura 1. Total de erros dos programadores
[GRAUCPM] Tabela de Determinao de Grau de Complexidade e Prazos,

MP-07-CPM-020, reviso 3, CPM S.A., 2001
[GUSTAFSON] Gustafson, David A.. Teoria e problemas de Engenharia de
Software, Bookman, Porto Alegre, 2003.
[PADRCPM] Manual de Padronizao, Treinamento e Apoio Programao,
CPM S.A.,1997
[PESSOA] Pessoa, Andr. Projetos de Sistemas de Informao. Book Express,
Rio de Janeiro, 2000.
[PLDCPM] Planejamento e Distribuio, 07-PLD-001, reviso 10, CPM S.A.,
2001
[QUALICPM] Manual da Qualidade Fbrica de Software, 07-CPM-001,
reviso 4, CPM S.A.,2001
[SHIGUNOV] Shigunov Neto, Alexandre. Avaliao de Desempenho, Book
Express, Rio de Janeiro, 2000.
Figura 2. Percentual de aproveitamento dos programadores
Isto supe que o desempenho comportamental e relacional dos programadores influi diretamente no resultado do
processo avaliativo. Esta uma hiptese que merece maior
estudo, pois em caso afirmativo, prova que comportamento e

51
Engenharia
Como detectar problemas de usabilidade e

corrigi-los - Parte 1
Solucione os problemas de usabilidade em sistemas interativos
Fique por dentro:
Atualmente, a quantidade de usurios de computadores vem aumentando consideravelmente, e como consequncia, uma parcela destes
usurios enfrentam uma maior dificuldade em
interagir com os sistemas. Isso se d principalmente porque alguns programas no possuem
uma interface com facilidade de uso. A ergonomia e a rea de usabilidade apresentam pesquisas e tcnicas que permitem aos projetistas de
sistemas computacionais interativos melhorar
a usabilidade destes sistemas.
Este artigo tem como propsito apresentar os
conceitos de usabilidade, e avaliao de usabilidade, descrevendo sua importncia nos
sistemas de hoje. Apresenta tambm os tipos
de avaliao de usabilidade e como podem ser
aplicados.
Este artigo faz parte de

um curso
Karin R. Coelho Quandt

karinquandt@hotmail.com
Analista de testes, Bacharel em Cincia da Computao, Especialista em Engenharia de Projeto

de Software.
52
om o advento da tecnologia, as
pessoas precisam mudar consideravelmente seus hbitos.
Muitas delas esto sendo obrigadas a
interagir com mquinas e equipamentos
que nem sempre so de fcil manuseio.
Para facilitar essa interao dos usurios
com as mquinas, os projetistas esto
empreendendo esforos para tornar esses
equipamentos mais simples de utilizar.
A usabilidade no diz respeito somente facilidade de uso, mas sim, de
que forma o trabalho feito: o sistema
no s deve ser amigvel, mas tambm
eficiente, seguro e sensvel a variaes
das condies de uso. A usabilidade
promove a melhoria do processo de
interao, o uso e a popularidade dos
diferentes equipamentos presentes no
nosso dia a dia, fez com que o conceito
de facilidade de manuseio se tornasse

senso comum entre usurios.
A usabilidade um conceito que vem
sendo adotado pelas empresas, pois
o interesse em desenvolver softwares
amigveis e de fcil interao est em
evidncia devido aos diversificados
perfis de usurios que atualmente tm
que interagir com os sistemas.
Engenharia de Software Magazine - Como detectar problemas de usabilidade e corrigi-los - Parte 1
en gen haria
A usabilidade um conceito que pode ser aplicado em qualquer objeto que pode proporcionar satisfao de uso para seus
usurios. A usabilidade mede a experincia de um usurio ao
interagir com um sistema web, um software desktop, tecnologia mvel ou um outro dispositivo que possa ser operado
pelo usurio. A usabilidade consiste em uma combinao de
diversos fatores: facilidade de aprendizagem, eficincia no
uso, facilidade de lembrar, frequncia e severidade de erros e
satisfao subjetiva.
Todos esses conceitos podem ser observados nos diversos
contextos de avaliao. A usabilidade uma qualidade do
uso do sistema, o desempenho do usurio depende da obteno de seus objetivos, se so atingidos com eficincia e
eficcia. Para melhor representar essas definies, a norma
ISO 9241-11 esquematiza o conceito de usabilidade que pode
ser visto na Figura 1.
Figura 1. Esquema do conceito de usabilidade. Fonte: ISO 9241-11
Uma das maiores dificuldades encontradas est em avaliar

o quanto uma interface adequada ao uso. A usabilidade
uma metodologia cientfica aplicada na criao e remodelao
de interfaces de sites, intranets, aplicativos, jogos e produtos
de modo a torn-las fceis de aprender e de usar.
A usabilidade desenvolve conhecimentos sobre os limites
e caractersticas referentes ao desempenho do homem que
esto relacionadas s interfaces e componentes do sistema.
recomendvel que o ergonomista tenha como enfoque o
desenvolvimento de solues para assegurar que a qualidade
da interao seja adequada s condies dos usurios e ao
motivo pelo qual ele ir fazer uso delas.
A usabilidade um conceito que est evoluindo, pois no tem
um significado concreto; ela considera o contexto de uso de
acordo com o ponto de vista do usurio. A usabilidade um
dos fatores do sucesso de um produto, dirigindo-se ao usurio
e condicionando a produtividade e eficincia ao conforto e
satisfao do usurio.
A web fornece um exemplo acessvel da importncia da
usabilidade, pois os usurios procuram pginas fceis de
usar, sites sem falhas, com informaes claras e com boa
localizao para que eles no se percam nas pginas e sites.

As informaes devem ser apresentadas de forma que seja de
fcil entendimento, caso contrrio, os usurios desistem da
pesquisa pois se cansam antes mesmo de ter acesso ao que
realmente desejam.
A usabilidade tem mltiplos componentes e est associada
a cinco atributos:
Fcil de aprender: o sistema deve ser de fcil aprendizado
para que o usurio obtenha resultados a curto tempo;
Eficiente: o usurio deve ter um alto nvel de produtividade
com o sistema;
Fcil de lembrar: o sistema deve ser fcil de ser lembrado mesmo que o usurio tenha ficado algum tempo sem utiliz-lo;
Minimizao de Erros: o sistema deve possuir baixas taxas de
erros, de forma que usurios cometam poucos erros durante o
uso do sistema, e mesmo que eles cometam, esses erros devem
ser de fcil recuperao.
Satisfao: o sistema deve ser agradvel de se utilizar e consequentemente deve dar satisfao para seus usurios.
A usabilidade uma combinao de fatores que atingem as
habilidades do usurio diante do sistema. Por isso, ela trata
da interao humano-computador, que observada desde o
desenvolvimento de software por meio de testes de usabilidade
com o usurio.
Assim, pode-se afirmar que a usabilidade uma qualidade
do uso do sistema, que difere pelas operaes realizadas pelos
usurios. O desempenho do usurio depende da obteno de
seus objetivos (eficcia) bem como os recursos que so gastos
para que eles possam ser atingidos (eficincia).
Todos esses conceitos esto relacionados e podem ser observados nos diferentes contextos em que se pode avaliar a
usabilidade. Eles tambm influenciam na produtividade e na
eficincia aumentando a qualidade e a usabilidade dos sistemas
oferecidos para os usurios obrigando a intensificao de testes
de usabilidade para avaliao dos softwares usados ou os que
j esto sendo produzidos.
Avaliao de Usabilidade
A avaliao da usabilidade de um software um fator a ser
considerado para o seu aprimoramento, pois a partir dela
que se descobrem os principais problemas de usabilidade que
podem gerar dificuldades para os usurios.
Para avaliar uma interface, vm sendo desenvolvidos mtodos e
ferramentas para melhor detectar as reais necessidades dos usurios. A competitividade que existe no mercado faz as empresas
buscarem produzir interfaces bem desenvolvidas. Estudos na rea
de avaliao de software indicam que os usurios esto cada vez
mais exigentes quanto s funcionalidades do sistema.
A qualidade de uma interface decidida pelos seguintes
fatores:
Funcionalidade: a interface ajuda no acesso eficiente e efetivo? A interface faz o que o usurio quer e deseja?
Consistncia: os padres dos comandos e mensagens de
ajuda esto sendo seguidos?
53
Clareza: o projeto das telas e o uso das cores so familiares

para o usurio?
Segurana: os usurios so capazes de identificar e corrigir
erros? Os usurios podem corrigi-los de forma simples?
Ajuda, explanao e mensagens de erro: as mensagens so
oferecidas de forma clara e detalhadas para que os usurios
possam entender?
Padronizao: os cenrios so apresentados de forma
padronizada?
A interface e a forma como a informao apresentada so
elementos bsicos para um bom sistema. Aquelas que no
exigem muito esforo dos usurios para realizar suas tarefas
so consideradas boas e fceis de usar. Heemann diz que,
os estudos e pesquisas sobre interfaces mostram que as que
permitem a lei do menor esforo, esto associadas aos sistemas
mais fceis de usar e aos sistemas considerados de maior valor
para os usurios.
Se o desejo fazer com que o programa seja fcil de usar e
se tornar um sistema de grande valor, recomendvel que se
adotem mtodos adequados de avaliao de usabilidade. A
escolha do mtodo apropriado depende de diversos fatores,
tais como:
Fase em que est o projeto;
Inovaes no projeto;
Quantidade de usurios esperados;
Criticidade da interface;
Custo do produto e recursos alocados para testes;
Disponibilidade de tempo;
Experincia da equipe do projeto e da equipe de avaliao.
Outros fatores que devem ser considerados para a escolha de
um mtodo de avaliao de usabilidade so:
Propsito da avaliao;
As restries de tempo, custo e disponibilidade de
equipamentos;
Quanto avaliao afeta a situao que est sendo avaliada,
bem como a confiabilidade dos mtodos;
Algumas questes prticas do tipo: Os dados so fceis de
associar? Quanto vai demorar? Quanto vai custar? Os recursos
apropriados esto disponveis?
Tcnicas de avaliao
Determinismo dos mtodos no que diz respeito assimilao

s prticas comerciais.
A Tabela 1 resume algumas das tcnicas para avaliao de
usabilidade existentes. Posteriormente elas sero tratadas com
mais detalhes.
Tcnicas de Avaliao de Usabilidade Tcnicas

Prospectivas
O uso da tcnica prospectiva consiste basicamente em avaliar
o sistema e as operaes dos usurios por meio da aplicao
de questionrios/entrevistas (ler BOX 1). Esta tcnica tem sido
comumente utilizada, pois o usurio a pessoa que melhor
conhece o sistema com relao ao uso e melhor pode dizer se
est adequado para a realizao de suas tarefas.
Esses questionrios tm devoluo reduzida, prova de que
deve ser elaborado com o mnimo de questes possveis. Em
contrapartida, empregando essa tcnica, combinada com outra
tcnica pode-se ter um aumento na efetividade de avaliaes
analticas, que so realizadas por especialistas para identificar
e solucionar problemas de usabilidade.
Os questionrios e as entrevistas so mtodos similares, j
que ambos dizem respeito coleta de dados sobre a satisfao
do usurio com a interface. A diferena que o questionrio
respondido pelo prprio usurio em papel, ou no computador,
tendo a presena fsica de uma pessoa para auxili-lo ou no. J
as entrevistas envolvem a gravao das respostas s perguntas
que o entrevistador realiza.
H dois tipos de estrutura de perguntas de questionrios
diferentes:
Perguntas abertas onde o questionado livre para fornecer
suas prprias respostas. Elas podem fornecer muitos dados,
mas podem ser difceis de analisar;
Perguntas fechadas onde o questionado escolhe a resposta
dentre algumas alternativas. So mais fceis de analisar do que as
perguntas abertas, pois h formas de classificao para seguir.
Shneiderman sugere um questionrio de avaliao da satisfao do usurio com o sistema. Esse questionrio pode auxiliar
na avaliao de alguns itens como:
Vantagens
Avaliao Heurstica
Detecta maior quantidade de problemas.

Detecta maior quantidade de problemas de maior gravidade.
Testes de usabilidade com usurios
Detecta problemas recorrentes e de maior gravidade.
Inspeo baseada em recomendaes

Explorao cognitiva
Detecta problemas gerais e recorrentes.

Pode ser usada por projetistas.
Ajuda a definir os objetivos e expectativas dos usurios.
Pode ser usada por projetistas.
Desvantagens
No detecta problemas relacionados s expectativas em usabilidade.
Requer especialista em usabilidade.
Requer vrios avaliadores.
Requer planejamento preciso para os testes (tarefas, usurios).
Requer muitos recursos (tempo, pessoal, equipamentos de gravao).
Alto custo.
No detecta problemas de consistncia.
Deixa de detectar vrios problemas de alta gravidade.
Necessita de metodologia de definio de tarefas.
Deixa de detectar problemas gerais e recorrentes.
Tabela 1. Tcnicas de avaliao de usabilidade
54
en gen haria
Tempo do usurio para aprender funes especficas de

um sistema;
Velocidade de desempenho para realizar uma tarefa;
Taxa de erros cometida pelos usurios;
Reteno de usurio de comandos com o passar do tempo.
Alm das tcnicas com participao dos usurios as entrevistas e os questionrios h tambm as que os usurios
no participam diretamente da interao, essas tcnicas so
chamadas de tcnicas analticas.
BOX 1. Posso avaliar sistema novo?
O sistema que est sendo desenvolvido pode consistir em algo totalmente novo ou em uma
atualizao de algo j existente. Em se tratando de um sistema novo, geralmente um tempo
considervel investido em pesquisa de mercado. Os designers geralmente desenvolvem
esboo de telas a fim de extrair as reaes dos usurios, pode ser aplicada a tcnica de card
sorting para a organizao de menus.
No caso de uma atualizao, a ateno voltada para a melhoria do produto, as avaliaes so
comparadas com o desempenho e as atitudes dos usurios com as verses anteriores.
Tcnicas de Avaliao de Usabilidade Tcnicas

Analticas
As tcnicas analticas so caracterizadas pelo fato do usurio
no participar diretamente do sistema durante a avaliao.
Normalmente, so os especialistas em usabilidade que utilizam
essas tcnicas. Os avaliadores se baseiam em regras, recomendaes, princpios e/ou conceitos previamente estabelecidos
para identificar os problemas de usabilidade que provavelmente afetam (ou afetaro) a interao dos usurios reais com
o sistema. A avaliao analtica pode comear em um estgio
inicial do ciclo de design quando uma interface representada
apenas por uma especificao formal ou semiformal.
Para fazer esse tipo de avaliao, necessrio um detalhamento das operaes de interfaces no que diz respeito s
interaes do usurio com o sistema.
Existem trs tipos de tcnicas analticas para avaliao de
interfaces de software: Avaliao Heurstica, Conformidade
com Recomendaes e Explorao Cognitiva.
Avaliao heurstica
A avaliao heurstica realizada por especialistas em usabilidade que percorrem a interface baseados em seus conhecimentos. A avaliao heurstica uma tcnica de avaliao
baseada em incertezas provisrias, que utiliza um conceito
semelhante ao raciocnio do jogo de xadrez. A avaliao no
segue uma sequncia lgica de passos, ela realizada atravs
de aproximaes progressivas, onde cada estgio do caminho
percorrido avaliado e, ento, especula-se sobre a natureza dos
caminhos a seguir para se aproximar do objetivo de encontrar
o maior nmero possvel de problemas de usabilidade.
Por esse tipo de avaliao ser baseado em seleo de objetos
de interface, telas, situaes de interao e incertezas provisrias, fundamental para seu sucesso que o avaliador tenha
experincia e capacidade de interpretao.
Os resultados dessa tcnica so bons, pois so julgadas as

interfaces baseadas nas competncias e conhecimentos dos
especialistas. Pelo mesmo motivo, uma tcnica barata, com
resultados rpidos e satisfatrios. Em contrapartida, para
fazer uso dela, deve-se ter o cuidado de procurar pessoas
capacitadas e com competncias necessrias para a realizao
dessa avaliao.
Os avaliadores tomam por base padres de usabilidade
gerais ou desenvolvidos por especialistas como, por exemplo,
os critrios ergonmicos, as heursticas e a Norma ISO 9241:10
(Princpios de dilogos). Ainda assim, a avaliao acaba sendo
subjetiva visto que envolve a identificao da maior parte dos
problemas de ergonomia.
Conformidade com Recomendaes

Nesse tipo de avaliao verificada a conformidade da interface em relao s necessidades dos usurios juntamente com
outras tcnicas de avaliao.
As conformidades de recomendaes so realizadas por meio
de guias, que so publicaes de carter genrico e so agrupadas de modo emprico ou validadas. A conformidade com
recomendaes realizada com guias de recomendaes, que
fornecem aos avaliadores recomendaes especficas sobre o
projeto de uma interface, tais como: como o contedo de uma
tela deveria ser organizado ou como as opes deveriam estar
arranjadas em um menu.
Essa tcnica, alm de ser utilizada como recomendao na
forma afirmativa, pode tambm ser aplicada com questes
interrogativas Checklist organizado.
Explorao cognitiva
Na avaliao cognitiva os especialistas assumem o papel
de usurios procurando simular a interao do usurio com
o sistema. Nessa avaliao so enfocados principalmente
os processos estabelecidos quando a tarefa interativa
realizada pela primeira vez pelo usurio. A explorao
cognitiva auxilia a avaliar as condies do software no que
diz respeito ao rpido aprendizado e ao dilogo do usurio
com o sistema.
A validade desta tcnica est justamente em seu enfoque
nos processos cognitivos. Para realiz-la, o avaliador tem que
prestar ateno no que conhecido, pelo usurio, da tarefa
e da operao dos sistemas informatizados. Uma vez que o
avaliador tenha todas essas informaes, ele passa a percorrer
os caminhos previstos e para cada ao ele aplica o seguinte
checklist:
O usurio tenta realizar a tarefa certa? Ao encontrar-se no
passo inicial de determinada tarefa, o usurio, baseado no que
lhe apresentado, se propor a realizar o objetivo previsto
pelo projetista?
Ele ver o objeto associado a esta tarefa? Este objeto est
suficientemente vista do usurio?
Ele reconhecer o objeto como associado tarefa? As denominaes ou representaes grficas so representativas da
tarefa e significativas para o usurio?
55
Ele saber operar o objeto? O nvel de competncia na operao de sistemas informatizados compatvel com a forma
de interao proposta?
Ele compreender o feedback fornecido pelo sistema como
um progresso na tarefa?
A explorao cognitiva tem como objetivo bsico a avaliao
de interfaces de software nas condies e facilidades oferecidas
ao usurio.
Tcnicas de Avaliao de Usabilidade - Tcnicas

Empricas
Tcnicas empricas so as tcnicas em que h a participao
direta dos usurios na avaliao do sistema. Elas consistem
em realizar testes de usabilidade com os usurios.
Aplicao das tcnicas requer ateno e cuidados, importante realizar estudos sobre as caractersticas e peculiaridades de
cada tcnica a ser utilizada, pois algumas delas so vantajosas
aplicadas ao desenvolvimento de interfaces com a participao
do usurio.
Avaliar a usabilidade no uma tarefa simples, pois vai muito
alm de saber se o sistema est atendendo as expectativas dos
usurios. A deteco de problemas de usabilidade viabiliza a
correo destes problemas e, consequentemente, contribui para
a melhoria da qualidade da interface de sistemas interativos,
isto , auxilia projetistas de software e ergonomistas a obter
uma maior usabilidade nas interfaces humano-computador.
Links e Referncias:
[1] ARTIS FACTA. De la conception au succs: La facilit dusage ou utilisalilit.
Paris. 2002.
http://www.artis-facta.com/USAB/USAB03.HTML
[2] BNARD, Vincent. Utilisabilit: que se cach-t-il derrire ce terme barbare?: Une dfinition de I utilisabilit. Paris. 2001.
http://www.veblog.com/fr/2001/1021-usability-indepth.html
[3] CYBIS, Walter de Abreu. Engenharia de usabilidade: Uma abordagem
ergonmica. Florianpolis: LabIUtil, .2003.
[4] DIAS, Cludia. Usabilidade na Web: Criando portais mais acessveis. Rio
de Janeiro: Alta Books, 2003.
[5] HEEMANN, Vivian. Avaliao ergonmica de interfaces de base de dados
por meio de checklist especializado.1997. 96 f. Dissertao (Mestrado em
Engenharia de Produo). Departamento de Engenharia de Produo,
Universidade Federal de Santa Catarina, Florianpolis, 1997.
[6] PREECE, Jenny. A guide to usability: Human factors in computing.
Reading- Harlow-Menlo Park-Berkeley-Don Mills-Sydney-Bonn-AmsterdamTokyo-Mexico city: Addison-wesley, 1993.
[7] SHNEIDERMAN, Ben. Designing the user interface: Strategies for effective. 3 ed. Reading- Harlow-Menlo Park-Berkeley-Don Mills-Sydney-BonnAmsterdam-Tokyo-Mexico city: Addison-wesley, 1998.

56
Engenharia
Teste unitrio com JUnit e ComplexGraph

Como aplicar teste unitrio com auxlio de uma ferramenta de medio de
complexidade
Felippe Moreira Fada

felippefaeda@gmail.com
aluno de mestrado em Cincia da Computao

pela Universidade Federal de Viosa, ps-graduando em Gerncia de Projetos em Engenharia
de Software pela Faculdade Governador Ozanam Coelho (FAGOC). Graduado em Cincia da
Computao pela FAGOC e tcnico em informtica pelo Centro Federal de Ensino Tecnolgico
de Minas Gerais (CEFET-MG).
Vincius Lucena Bonoto

viniciusbonoto@gmail.com
consultor na empresa de desenvolvimento de

software Tek-System Informtica. Ps-Graduando em Gerncia de Projetos em Engenharia
de Software pela Faculdade Governador Ozanam Coelho (FAGOC). Graduado em Cincia da
Computao pela FAGOC.

marcoaparaujo@gmail.com
Doutor e Mestre em Engenharia de Sistemas e

Computao pela COPPE/UFRJ, Especialista em
Mtodos Estatsticos Computacionais e Bacharel
em Informtica pela UFJF, professor dos cursos
de Computao do Instituto Federal de Educao,
Cincia e Tecnologia do Sudeste de Minas Gerais
Campus Juiz de Fora, professor do curso de Bacharelado em Cincia da Computao da FAGOC,
professor dos Cursos de Bacharelado em Sistemas
de Informao do Centro de Ensino Superior de
Juiz de Fora, da Faculdade Metodista Granbery
e da Universidade Severino Sombra, Analista de
Sistemas da Prefeitura de Juiz de Fora, Editor da
Engenharia de Software Magazine.
Fique por dentro:
competitividade no mercado de
desenvolvimento de software
vem aumentando nos ltimos
anos e manter-se competitivo nesse
mercado vem exigindo das empresas
maior qualidade nos produtos e servios oferecidos. Uma etapa fundamental
no desenvolvimento de software que
ajuda a detectar defeitos ainda no
percebidos pelos programadores, e que
verifica sua conformidade aos requisitos, a etapa de teste de software. Essa
etapa est se consolidando cada vez
mais atravs de sofisticadas tcnicas
automatizadas de teste.
Naturalmente, quando se termina
de escrever um cdigo-fonte comea o
processo de reviso procura de algum
defeito no algoritmo. Em alguns casos,
compara-se o cdigo com a especificao
e com o projeto a fim de garantir se todas
as funcionalidades foram devidamente
implementadas. Depois, o cdigo
compilado e so corrigidos problemas
Os testes unitrios so uma importante prtica

de teste que analisa em nvel de cdigo-fonte o
funcionamento de um determinado algoritmo.
Porm, identificar os casos de teste necessrios
para o teste unitrio no uma tarefa simples.
Os casos de teste precisam ter valores apropriados para uma maior eficincia ao encontrar
defeitos no cdigo, e tambm garantir uma cobertura aceitvel para o cdigo-fonte em questo. Com o objetivo de auxiliar e agilizar a identificao dos casos de teste que a ferramenta
ComplexGraph ser utilizada e demonstrada
neste artigo em um estudo de caso. Depois de
identificados os casos de teste, a ferramenta
JUnit ser utilizada para execut-los. Por fim,
ser utilizada uma ferramenta de teste de cobertura para verificar o grau de cobertura que
os casos de teste geraram.
de sintaxe. Por fim, so criados casos

de teste para mostrar que a entrada
submetida ao algoritmo retorna a sada
esperada. O teste unitrio segue essas
etapas com o objetivo de identificar os
defeitos antes que os mesmos se transformem em falhas durante a utilizao
pelos usurios.
57
O teste unitrio, tambm conhecido como teste caixa-branca

ou estrutural, um processo de teste onde o conhecimento
da estrutura interna do sistema deve ser bem conhecido. Seu
principal objetivo testar as unidades de codificao de um
software. Em sistemas orientados a objetos representam os
mtodos de cada classe, podendo ser at parte do mtodo,
dependendo de sua complexidade. Mas, para que o teste
unitrio tenha um bom desempenho, necessrio um bom
planejamento dos testes, no qual leva-se em considerao a
criao de uma quantidade razoavelmente boa de casos de
teste que atinjam uma cobertura de cdigo-fonte desejvel.
No entanto, identificar esses casos de teste no uma tarefa
simples e, caso seja feita de maneira errada, podem comprometer a qualidade do teste.
na Figura 1 por R1, R2, R3 e R4), totalizando quatro regies.

Portanto, o nmero da complexidade ciclomtica quatro.
Outro mtodo tambm utilizado aplicando a frmula: C=AV+2, onde A o nmero de arestas e V o nmero de ns do
grafo. Aplicando a frmula na Figura 1, tem-se: C=10-8+2,
totalizando 4, que o valor da complexidade ciclomtica. Por
fim, tem-se outra frmula: C=P+1, onde P o nmero de componentes conexos ou comandos de desvio, ou seja, o nmero
de ns que geram duas sadas (as condies). Aplicando essa
frmula ao exemplo tem-se: C=3+1, totalizando 4.
Complexidade Ciclomtica
Uma maneira de identificar os casos de teste utilizando
uma mtrica conhecida como complexidade ciclomtica.
Essa mtrica foi desenvolvida por Thomas McCabe em 1976
e tem como finalidade medir a complexidade lgica de uma
aplicao baseando-se em uma representao do fluxo de
controle, tambm chamado de grafo da complexidade ciclomtica. Atravs desse grafo possvel visualmente identificar
os caminhos de execuo do cdigo e que vo se tornar casos
de teste.
A mtrica da complexidade ciclomtica, alm de classificar
o cdigo-fonte quanto ao seu nvel de complexidade, tambm
pode ser utilizada no processo de elaborao dos casos de
teste utilizados na tcnica de teste unitrio. O nmero da
complexidade ciclomtica tambm corresponde ao total de
caminhos independentes do cdigo-fonte e representa o
total de casos de testes que devem ser realizados para cobrir
totalmente o cdigo, garantindo que todas as instrues
sejam executadas pelo menos uma vez durante o teste unitrio. Outro benefcio ligado a essa mtrica est na etapa de
manuteno, pois com ela possvel quantificar o quanto a
complexidade de um cdigo foi alterada durante o processo
de mudana. Muitos desenvolvedores analisam o impacto de
alguma mudana sobre o nmero ciclomtico, pois se alguma
manuteno feita e isso eleva muito esse nmero, talvez seja
necessrio rever toda a manuteno realizada.
O grafo da complexidade ciclomtica descreve o fluxo de
controle do programa, onde cada n do grafo corresponde a
um trecho de cdigo e as arestas representam os fluxos de
controle. Os fluxos podem variar dependendo da estrutura
de cdigo-fonte analisado, por exemplo, quando o n corresponde a um comando if abrem-se duas arestas, ou seja, dois
caminhos diferentes que possibilitam execues diferentes
durante a execuo do cdigo-fonte. A Figura 1 ilustra um
exemplo de grafo da complexidade ciclomtica.
O grafo da complexidade ciclomtica tem suas bases na teoria
dos grafos e oferece uma mtrica de software extremamente
til. Existem trs mtodos para se achar o nmero da complexidade ciclomtica do grafo da Figura 1. O primeiro mtodo
contar a quantidade de regies do grafo (representadas
58
Figura 1. Exemplo de Grafo da Complexidade Ciclomtica
Pode-se observar, comparando o grafo e cdigo, que torna

muito mais fcil encontrar no cdigo os pontos onde se encontram seus caminhos de execuo, facilitando a identificao
dos casos de testes a serem feitos. Os casos de teste agora so
construdos com o objetivo de passar por todas as arestas do
grafo, garantindo assim uma cobertura maior dos testes.
Aps ser aplicado o teste unitrio, essencial que seja utilizada uma ferramenta para aferir o grau de cobertura dos testes
unitrios. Esse processo chamado de teste de cobertura. Esse
teste verifica, no cdigo-fonte, os caminhos percorridos pelos
testes unitrios e, assim, ajuda a identificar as reas que no
esto sendo cobertas pelos testes. Ao final, o teste informa o
grau de cobertura dos testes unitrios e cabe ao responsvel
pelo teste avaliar esse grau segundo as necessidades de qualidade que necessitam ser alcanadas.
O objetivo deste artigo demonstrar como se pode facilitar
a obteno dos casos de teste e garantir um maior grau de
cobertura do teste unitrio utilizando uma ferramenta de
apoio. Essa ferramenta chamada de ComplexGraph. Com
ela ser possvel, a partir de um cdigo-fonte, gerar automaticamente o grafo e o nmero da complexidade ciclomtica.
Neste artigo demonstraremos como usufruir dos benefcios
dessa ferramenta e realizar o teste unitrio utilizando a
ferramenta JUnit a partir do estudo de caso. Por fim, ser
executado o teste de cobertura utilizando a ferramenta
Eclemma para conferir o grau de cobertura gerado pelo uso
da ComplexGraph com JUnit.
Engenharia de Software Magazine - Teste unitrio com JUnit e ComplexGraph
en gen haria
Estudo de Caso
Para exemplificar o uso das ferramentas propostas neste
artigo, ser utilizado um estudo de caso simples e de fcil
entendimento, que consiste em calcular a aprovao de um
aluno de graduao. O cdigo-fonte foi escrito em Java utilizando a IDE Eclipse. O estudo de caso consiste em uma classe
chamada AplicAprovacao cujo principal mtodo explorado o
calcularAprovacao apresentado na Listagem 1. Sero passados
como parmetro para esse mtodo a nota1, nota2, nota final e
frequncia do aluno e, ao final, o mtodo retornar se o aluno
foi aprovado ou no.
O mtodo funciona da seguinte maneira: primeiramente ele
verifica se o aluno possui frequncia maior que 75%, caso no
tenha, ele j reprovado direto. Se o aluno tiver frequncia
maior ou igual a 75, sero analisadas suas notas. Caso o aluno
tenha mdia menor que 30 pontos, ele tambm reprovado.
Se a mdia for maior ou igual a 70 pontos, ele aprovado. Se o
aluno obtiver mdia maior ou igual a 30 e menor que 70 pontos,
ele ter que fazer uma prova final. Portanto, ser analisada sua
mdia considerando a mdia anterior e a nota da prova final.
Se esse novo resultado for maior ou igual a 50 pontos, o aluno
est aprovado, caso contrrio estar reprovado.
Listagem 1. Mtodo calcularAprovacao.
01 public boolean calcularAprovacao(float nota1, float nota2,
02
float notafinal, int frequencia){
03 float media;
04
05 if (frequencia < 75){
06
resultado = false;
07 }
08 else{
09
media = (nota1 + nota2) / 2;
10
if (media < 30){
11
resultado = false;
12
}
13
else if (media >= 70){
14
resultado = true;
15
}
16
else if ((media + notafinal)/2 >= 50){
17
resultado = true;
18
}else{
19
resultado = false;
20
}
21 }
22
23 return resultado;
24 }
Obtendo a Complexidade Ciclomtica

Apresentado o estudo de caso, o objetivo agora obter o
nmero e grafo da complexidade ciclomtica antes de iniciar o
teste unitrio. A ferramenta utilizada neste processo chama-se
ComplexGraph, verso 1.0 (veja seo Links). Aps executar a
ferramenta, deve ser criada uma nova anlise atravs do menu
de opes. O sistema ir permitir inserir o cdigo manualmente
em uma tela conforme mostrada Figura 2, ou tambm permite
localizar o arquivo da classe onde o mtodo est contido.
Aps confirmada a insero do cdigo-fonte, deve-se dar incio anlise clicando no boto Iniciar Anlise. A ferramenta
ir fazer a leitura do cdigo-fonte fornecido e ir retornar o
grafo da complexidade ciclomtica em uma nova tela conforme

ilustrado na Figura 3.
Figura 2. Insero do cdigo-fonte na ferramenta ComplexGraph
Podem ser observadas no grafo da complexidade ciclomtica

da Figura 3 cinco regies. O que corresponde a uma complexidade ciclomtica igual a 5. Isso significa que o algoritmo possui
5 caminhos de execuo diferentes e, portanto, necessita para
ser testado com 100% de cobertura, 5 casos de testes que faam
o teste percorrer todos esses caminhos.
Pode ser observado que cada n do grafo corresponde a um
comando de desvio que pode ser if, else, case, for, while, entre outros. Alm disso, cada aresta possui um intervalo de nmeros
que correspondem s linhas de cdigo-fonte referente quele
fluxo, o que pode facilitar na localizao no cdigo-fonte. Na
tela principal da ferramenta, conforme mostra a Figura 4,
pode ser observado o cdigo-fonte e o resultado da mtrica
da complexidade ciclomtica.
Agora pode-se iniciar o processo de criao dos casos de
teste. Para o primeiro caminho, tem-se um if que corresponde
verificao de frequncia. Essa situao se refere ao caso de
teste 1, onde tem-se como entrada o valor da frequncia valendo
74, o que far que o teste retorne como sada reprovado.
Para o segundo caminho, tem-se um outro if correspondente
verificao da mdia menor que 30 e com frequncia maior
ou igual a 75. Esse ser o caso de teste 2, que ter como entrada
Nota1 igual a 29 e Nota2 igual a 30, sendo o valor limite para
a obteno de mdia menor que 30 e, alm disso, ter como
entrada frequncia igual a 75. Com esses dados, espera-se uma
sada igual a reprovado.
O caso de teste 3 refere-se verificao da mdia maior ou
igual a 70, com frequncia maior ou igual a 75. O caso de teste
ter as variveis Nota1 e Nota2 valendo 70, resultando numa
mdia igual a 70. Alm disso, a frequncia ser igual a 75.
O prximo caminho representa quando o aluno no conseguiu mdia para passar e est de final. O caso de teste 4 dever
59
considerar como entrada Nota1 e Nota2 iguais a 30 e notafinal

igual a 70. Calculando os resultados, a mdia final resultar
em 50, que faz com que o mtodo retorne aprovado.
Por fim, o ltimo caminho representa o aluno sendo reprovado com mdia final menor que 50. Para isso, o caso de teste 5
Casos de Teste
Caso de Teste 1
Caso de Teste 2
Entradas
Frequncia = 74
Frequncia = 75
Nota1 = 29
Nota2 = 30
Frequncia = 75
Nota1 = 70
Nota2 = 70
Frequncia = 75
Sada
Reprovado
Reprovado
ter como entrada Nota1 e Nota2 iguais a 30 e notafinal igual a

69, sendo suficiente para ter mdia final menor que 50, retornando assim o aluno sendo reprovado.
Resumindo, a Tabela 1 apresenta a configurao dos casos
de teste.
Nesta seo pode-se observar que o clculo da complexidade
ciclomtica e o grafo podem auxiliar mais rapidamente a identificao dos casos de teste dentro do cdigo-fonte, percorrendo
todos os caminhos de execuo do cdigo, garantindo um grau
de cobertura maior para o teste unitrio.
Executando o Teste Unitrio
Com os casos de teste definidos possvel dar incio ao teste

unitrio. Para realizar o teste unitrio em Java foi aqui utilizada
a plataforma Eclipse com o JUnit 4.0 (ver seo Links).
Depois, ser criado dentro do projeto um diretrio com desNota1 = 30
crio test. Dentro desse diretrio ser criado um pacote com
Caso de Teste 4
Aprovado
Nota2 = 30
nome academico.test. Dentro desse pacote pode-se clicar em File
NotaFinal = 70
>> New >> JUnit Test Case. Nesse momento, foi criado o arquivo
Frequncia = 75
que ir armazenar e executar os casos de teste cujo nome ser
Nota1 = 30
AplicAprovacaoTest e que apresentado na Listagem 2.
Caso de Teste 5
Reprovado
Nota2 = 30
Aps criar a classe AplicAprovacaoTest, automaticamente ser
NotaFinal = 69
registrada a importao dos pacotes da ferramenta. Alm
Tabela 1. Casos de Teste
disso, necessrio que seja inserida a importao da classe
a ser testada para que possa ser criado
o objeto.
Analisando o cdigo gerado pela criao
da classe de teste, tem-se um mtodo chamado setUp. Ele responsvel pela inicializao do teste, como a instanciao do
objeto, por exemplo. Pode ser observado
que acima do mtodo existe a anotao @
BeforeTest, significando que esse mtodo
deve ser executado pelo JUnit antes de
cada mtodo de teste. J o mtodo tearDown responsvel por finalizar o teste
podendo ser usado para liberar memria
Figura 3. Grafo da complexidade ciclomtica gerado pela ferramenta ComplexGraph
ocupada pelo objeto instanciado, por
exemplo. Nesse mtodo tem-se a anotao @AfterTest, que indica ao JUnit que o
mtodo deve ser executado logo aps cada
teste ser concludo.
Os demais mtodos apresentados no cdigo so os casos de teste. Para os mtodos
de caso de teste foi utilizada a anotao
@Test que indica ao JUnit que o mtodo
a seguir um caso de teste. O mtodo
possui a seguinte estrutura: primeiro
criam-se os atributos correspondentes aos
parmetros do mtodo calcularAprovacao
que ser testado, depois ser instanciado
o objeto do tipo AplicAprovacao, logo aps
ser invocado o mtodo calcularAprovacao
passando todos os atributos como parmetros, por fim, ser chamado o mtodo
Figura 4. Resultados da mtrica calculada pela ferramenta ComplexGraph
Caso de Teste 3
60
Aprovado
en gen haria
Listagem 2. Casos de Teste

01 public class AplicAprovacaoTest {
02
03 public AplicAprovacaoTest() {
04 }
05
06 @BeforeClass
07 public static void setUpClass() throws Exception {
08 }
09
10 @AfterClass
11 public static void tearDownClass() throws Exception {
12 }
13
14 @Before
15 public void setUp() {
16 }
17
18 @After
19 public void tearDown() {
20 }
21
22 /**
23 * Test of calcularAprovacao method, of class EstudoCaso1.
24 */
25 @Test
26 public void testFrequenciaMenor75() {
27
// Frequencia < 75
28
int frequencia = 74;
29
int nota1 = 0;
30
int nota2 = 0;
31
int notafinal = 0;
32
EstudoCaso1 instance = new EstudoCaso1();
33
boolean expResult = false;
34
boolean result = instance.calcularAprovacao(nota1, nota2,
35
notafinal, frequencia);
36
assertEquals(expResult, result);
37 }
38
39 @Test
40 public void testMediaMenor30() {
41
// Media < 30
42
43
int nota1 = 29;
44
int nota2 = 30;
45
int notafinal = 0;
46
47
assertEquals do JUnit que vai comparar o resultado do mtodo

com o resultado esperado.
No primeiro caso de teste, na linha 26, definido um aluno
que foi reprovado por insuficincia de frequncia, tendo somente o atributo frequncia igual a 74. J na linha 36, invocado
o mtodo assertEquals que foi configurado com o resultado
esperado e o resultado obtido pelo mtodo. Caso esse mtodo
encontre divergncia, o teste unitrio acusar um defeito. Para
o primeiro caso de teste, o resultado esperado false.
O segundo caso de teste apresenta um aluno sendo reprovado por ter tido mdia menor que 30 pontos. Para isso, so
definidos frequncia igual a 75, nota1 igual a 29 e nota2 igual
a 30. O valor esperado para esse teste false.
O terceiro caso de teste cobrir a opo do aluno ser aprovado
por possuir mdia maior ou igual a 70. Para isso, definida
a varivel frequncia igual a 75, a nota1 e nota2 iguais a 70.
O valor esperado para esse teste true.
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94 }

@Test
public void testMediaMaior70() {
// Media >= 70
int nota1 = 70;
int nota2 = 70;
int notafinal = 0;
boolean expResult = true;
}
@Test
public void testMediaFinalMaior50() {
// (Nota Final + Mdia)/ 2 >= 50
int nota1 = 30;
int nota2 = 30;
int notafinal = 70;
boolean expResult = true;
}
@Test
public void testMediaEntre30e70eMediaFinalMenor50() {
// Media entre 30 e 70 e Mdia na Prova Final < 50
int nota1 = 30;
int nota2 = 30;
int notafinal = 69;
}
Para o quarto caso de teste configurado um aluno que

est de final e que foi aprovado por ter mdia de final
maior ou igual a 50. A frequncia mantida igual a 75, as
notas 1 e 2 iguais a 30 e a notafinal igual a 70. Espera-se
que o aluno seja aprovado. Logo, o mtodo assertEquals
configurado para comparar o resultado com true.
Por fim, tem-se o caso de teste 5, que representa o aluno
que no conseguiu mdia e no conseguiu nota suficiente
na prova final. Com isso, sua frequncia 75, as notas 1 e
2 iguais a 30 e a nota final igual a 69, resultando false.
A classe Assert apresenta tambm outros mtodos para
definio de valores esperados alm do assertEqual. Os
principais so: assertFalse, se o parmetro definido
false; assertTrue, se o parmetro definido verdadeiro;
assertSame, se os parmetros so iguais; assertNotNull,
se o parmetro definido no nulo; e assertNull, se o
parmetro nulo.
61
Para executar o teste unitrio, basta executar a classe Aplic

AcademicoTest. Logo em seguida, ir aparecer uma interface da
ferramenta JUnit contendo o resultado do teste. Na Figura 5,
pode-se observar o resultado do teste unitrio aplicado para
os casos de teste criados. Segundo o resultado apresentado,
todos os casos de teste foram executados com sucesso, ou seja,
para os valores de entrada fornecidos, o mtodo de aferio de
aprovao do aluno reagiu como o esperado.
Figura 6. Resultado da JUnit com um defeito detectado
Figura 5. Resultado do Teste Unitrio
Entretanto, deve-se prestar bastante ateno ao elaborar casos

de teste, pois se forem estipulados valores de entrada incorretos, pode-se comprometer a validade do teste. Alm disso, se
forem configuradas as sadas esperadas do teste de maneira
errada, a qualidade do teste tambm estar comprometida. Por
isso, os testes devem ser bem planejados.
Por exemplo, suponha que na linha 13 da Listagem 1 a mdia,
em vez de ser >= 70, tenha sido codificada de forma errada,
somente > 70. Ao execute o teste novamente, o teste unitrio
ir acusar um erro no caso de teste 3, pois quando a mdia
valer 70, o mtodo ir retornar false e o esperado seria true. Esse
caso representa um defeito por um descuido na comparao
da mdia, que no seria identificado se os casos de teste no
tivessem sido bem definidos, utilizando os valores corretos
atravs da comparao dos limites das condies. A Figura 6
apresenta o resultado da ferramenta com esse defeito inserido
no cdigo-fonte.
Aplicando o Teste de Cobertura

Aps aplicado o teste de unidade, importante que seja executado o teste de cobertura para avaliar o grau de cobertura
dos casos de teste executados pelo teste de unidade.
62
O principal objetivo desse teste ajudar a identificar reas

que no esto sendo cobertas pelos casos de teste e, assim,
alertar ao desenvolvedor que faltam reas no cdigo a serem
testadas. Para efetuar o teste de cobertura ser utilizada a
ferramenta Eclemma (ver seo Link), que fornecida como
plugin para o Eclipse.
Aps a instalao do plugin deve-se habilit-lo no teste
acessando o menu Run >> Covarage..., depois clica-se em
Coverage e observa-se os resultados. O teste ir sinalizar
no cdigo-fonte a rea que foi coberta pelo teste unitrio e,
neste caso, o trecho ir ficar verde. A rea que ficar vermelha
representa que o teste no executou aquele caminho do cdigofonte, podendo o desenvolvedor identificar, criar o caso de
teste que faltou, ou corrigir o cdigo-fonte e executar o teste
unitrio novamente. Esse processo pode repetir-se at que o
desenvolvedor atinja uma cobertura desejvel.
Na Figura 7 pode ser observado o resultado do teste de cobertura para o estudo de caso proposto. Todo o trecho do cdigo
ficou verde, ou seja, os casos de teste elaborados cobriram 100%
o cdigo-fonte, garantindo assim um teste de unidade mais
eficiente e de qualidade. Na Figura 8 exibida a porcentagem
de cobertura de cada mtodo da classe.
Este artigo apresentou a aplicao do teste unitrio utilizando
a ferramenta JUnit com o apoio das ferramentas ComplexGraph
e Eclemma. Foi possvel perceber que a ComplexGraph fornece para o teste unitrio o nmero e o grafo da complexidade
ciclomtica de um cdigo-fonte favorecendo na identificao
dos casos de teste necessrios para executar o teste unitrio.
en gen haria
Ao final, foi executado o teste de cobertura com a ferramenta

Eclemma para verificar o grau de cobertura do teste unitrio.
Ao final do estudo de caso, o teste de cobertura resultou em
um grau de cobertura de 100% devido a todos os casos de testes
terem sidos rodados corretamente em todos os caminhos de
execuo do cdigo-fonte.
A ferramenta ComplexGraph ainda possui algumas limitaes, mas pode ser observado seu benefcio para o estudo de
caso aplicado. Ter uma ferramenta que informe o nmero de
casos de teste que devem ser construdos e gerar um grafo
para que o desenvolvedor localize no cdigo-fonte os caminhos de execuo, pode ajudar e facilitar na criao dos casos
de teste.
Figura 7. Resultado do Teste de Cobertura
Links:
Ferramenta ComplexGraph
http://code.google.com/p/complexgraph
Ferramenta JUnit
http://junit.org/
Ferramenta Eclemma
http://www.eclemma.org/
Figura 8. Resultado do Teste de Cobertura com o percentual de cada

classe

63
64

Engenharia de Software - Edição 70

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Engenharia de Software - Edição 70

Diunggah oleh

Hak Cipta:

Format Tersedia

Rodrigo Oliveira Spnola

Marco Antnio Pereira Arajo

Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ, Especialista em

Eduardo Oliveira Spnola

Nicolli Souza Rios Alves

Fale com o Editor!

Contedo sobre Agilidade, Artigo no estilo Prtico

06 MPS.BR: Melhorando o nvel de maturidade do processo com metodologia gil

Contedo sobre Agilidade, Artigo no estilo Prtico

12 Estudo de caso de uma Modelagem gil

Contedo sobre Agilidade

23 Desenvolvimento gil: O papel do PMO no mundo gil

Contedo sobre Agilidade

33 O que faz um Gerente de projetos e um Scrum Master?

Contedo sobre Boas Prticas, Contedo sobre Arquitetura e Desenvolvimento

42 Entendendo o Teste de Software por Amostragem

48 Como aumentar a produtividade de sua equipe de programadores

Contedo sobre Boas Prticas

52 Como detectar problemas de usabilidade e corrigi-los

[ Ivania Ramos dos Santos e Marcos Vinicius De Bortolli ]

Artigo no estilo Prtico

D seu feedback sobre esta edio!

Contedo sobre Planejamento e Desenvolvimento, Artigo no estilo Prtico

57 Teste unitrio com JUnit e ComplexGraph

Edio 05 - Engenharia de Software Magazine

MPS.BR: Melhorando o nvel de maturidade

Mestrado em Ciencias da Computano com

MPS.BR ou Melhoria de Processos do Software Brasileiro simultaneamente um movimento

Este artigo exibe um processo de software

Alguns conceitos de qualidade do MPS.

resultados esperados do processo e dos atributos dos processos so atendidos.

com o cliente e saber exatamente o que se espera do projeto,

Artefatos e procedimentos a serem entregues

Edio 70 - Engenharia de Software Magazine

mudanas e possveis novas estrias encontradas durante a

no produto entregue para verificar se tudo realmente foi

Fluxo Geral de Desenvolvimento de Sistemas

Figura 1. Fluxo Geral para Desenvolvimento de Sistemas

A seguir, este processo apresentado atravs da descrio

Detalhamento das Fases

requisitos, estrias e demais coisas que o cliente desejar, que

Figura 2. Fluxo geral para a fase de modelagem ou pr game

Edio 70 - Engenharia de Software Magazine

reunio de planejamento (a reunio visa apresentar o projeto e

Figura 3. Fluxo geral para a fase de desenvolvimento ou game

atualizao do que foi feito, do registro dos problemas, ou

A fase de finalizao concebida por meio de uma reunio

Agile Alliance. What Is Agile Software Development?

Voc gostou deste artigo?

Edio 70 - Engenharia de Software Magazine

Estudo de caso de uma Modelagem gil

Fique por dentro:

Graduado em Cincia da Computao pela

nicialmente proposta por Scott

Engenharia de Software Magazine - Estudo de caso de uma Modelagem gil

Nesse artigo veremos algumas boas prticas e

Portanto, uma exigncia que os membros de uma equipe que pratiquem a

Processo Unificado (UP)

Extreme Programming (XP)

a padronizao do cdigo fonte, o uso de design patterns e a

Edio 70 - Engenharia de Software Magazine

desenvolvimento. Dessa forma, as caractersticas do local

Figura 1. Modelo de layout de estdio de software