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
68 Edio - 2014
Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ, Especialista em
Corpo Editorial Mtodos Estatsticos Computacionais e Bacharel em Matemtica com Habilitao em Infor-
mtica pela UFJF.
Editor
Rodrigo Oliveira Spnola Eduardo Oliveira Spnola
eduspinola@gmail.com
Colaboradores
Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Magazine.
Marco Antnio Pereira Arajo
Eduardo Oliveira Spnola bacharel em Cincia da Computao pela Universidade Salvador (UNIFACS).
Nicolli Souza Rios Alves

Consultora Tcnica
Daniella Costa
Nicolli Souza Rios Alves
nicolli.devmedia@gmail.com
Jornalista Responsvel Bacharel em Cincia da Computao na Universidade Salvador (UNIFACS), Mestranda em Sistemas
Kaline Dolabella - JP24185 e Computao no Programa de Ps-Graduao em Sistemas e Computao da UNIFACS na linha de
Na Web Engenharia de Software. editora da Engenharia de Software Magazine.
http://www.devmedia.com.br/revista-engenharia-de-software-magazine

Atendimento ao Leitor Fale com o Editor!

A DevMedia conta com um departamento exclusivo para o atendimento ao leitor. muito importante para a equipe saber o que voc est achando da revista: que tipo de artigo voc

Se voc tiver algum problema no recebimento do seu exemplar ou precisar de algum gostaria de ler, que artigo voc mais gostou e qual artigo voc menos gostou. Fique a vontade para

esclarecimento sobre assinaturas, exemplares anteriores, endereo de bancas de entrar em contato com os editores e dar a sua sugesto!

jornal, entre outros, entre em contato com: 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
www.devmedia.com.br/central
(21) 3382-5038 de publicar.

Publicidade
Para informaes sobre veiculao de anncio na revista ou no site entre em
contato com:
publicidade@devmedia.com.br
 Sumrio
Artigo no estilo Mentoring

06 Agile Development: Problemas e Solues no Scrum

[ Eduardo Antonio Cecilio Fernandes ]

Contedo sobre Boas Prticas

14 Groupware: Modelo de comunicao para projetos distribudos

[ Leonardo Sanches dos Santos e Alexandre LErario ]

Artigo no estilo Curso, Artigo no estilo Prtico

20 Use Case Point: Estimativas de Projeto Parte 3

[ Anderson Pinheiro Balbo, Wilson Vendramel e Maria Beatriz Felgar de Toledo ]

Contedo sobre Novidades

40 UML: A evoluo do diagrama de Caso de Uso 2.0

[ Daniel Paz de Arajo ]
Feedback
eu
s
D

Contedo sobre Boas Prticas

sobre e
46 Teste de Software: Avaliando a eficincia da equipe
[ Clia Negrini ]
s
ta
edio

Contedo sobre Boas Prticas

D seu feedback sobre esta edio!
52 BPMN e a Modelagem de Processos de Negcio
[ Edson A. Oliveira Junior, Maicon Giovane Pazin, Felipe Pereira Perez e Jaime William Dias ]
A Engenharia de Software Magazine tem que ser
feita ao seu gosto.
Para isso, precisamos saber o que voc, leitor, acha
Contedo sobre Boas Prticas da revista!

58 A engenharia de software na era Big Data www.devmedia.com.br/esmag/feedback

[ Digenes Firmiano ]
Edio 05 - Engenharia de Software Magazine 5
Agilidade
Nesta seo voc encontra artigos voltados para as prticas e mtodos geis.
Agile Development: Problemas e Solues
no Scrum
Como lidar com cada um dos ritos e papis do Scrum
Eduardo Antonio C. Fernandes
eduardofernandes@yahoo.com.br
br.linkedin.com/in/eduardoacfernandes/
Graduou-se em Egenharia de Computao e
trabalha com desenvolvimento de software
desde ento. Atualmente, trabalha no Instituto
de Pesquisas Eldorado, atuando como Lider
tcnico, Aquiteto e desenvolvedor de software,
principalmente utilizando Java e Microsoft .NET.
6 Engenharia de Software Magazine - Agile Development: Problemas e Solues no Scrum
Este artigo do tipo mentoring
saiba mais: www.devmedia.com.br/
mentoring-saibamais
S
crum um framework para desen-
volvimento de produtos. Nesse
artigo, o foco ser no desenvol-
vimento de software. interessante
notar a denominao de Scrum como
framework e no processo. Isso porque,
essa metodologia diz o que fazer, mas
no como. Por exemplo, as entregas
devem ser incrementais e interativas
a cada Sprint, provendo real valor ao
cliente. Note que no explicado como
se do essas entregas incrementais, qual
o tamanho do incremento por produto,
alm de no se definir o que valor para
o cliente. Todos esses elementos so
deixados em aberto, para que cada Time
aplique o que achar mais conveniente
para esses conceitos.
Cenrio:
Processos de desenvolvimento de software em
cascata possuem conhecidos problemas, tais
como: entregas tardias com pouco feedback
do cliente, excessiva quantidade de documen-
tao, foco demasiado em processos, entre
outros. Scrum uma metodologia que, como
um de seus objetivos, enfrenta os problemas
citados, proporcionando entregas constantes
e iterativas, documentando-se apenas o estri-
tamente necessrio, focando no produto e nas
pessoas que o desenvolvem, etc. Contudo, o
Scrum no fcil de ser implementado, prin-
cipalmente em times que esto acostumados
com processo em cascata. Esse artigo d algu-
mas dicas, em cada etapa do framework, para
que sua adoo seja feita de forma mais tran-
quila, evitando-se alguns erros comuns quando
se adota o Scrum.
Scrum vem como resposta aos proble-
mas que processos em cascata geram.
Os processos em cascata focam na
definio de processos para o sucesso
do desenvolvimento de software. Alm
disso, a entrega do produto feita aps
longas fases de anlise e desenvolvi-
mento, tendo-se feedback do cliente
 agilidade

meses depois do incio do projeto. Alm

disso, mudanas so encaradas como
problemas, pois qualquer modificao
no produto ocasiona onerosa anlise e
alterao em documentaes, at que ela
seja efetivamente aplicada ao produto.
Finalmente uma ampla documentao
vem aliada ao software, pois se acredita
que isso gere real valor ao produto.
Por outro lado, Scrum foca estritamente
no produto, sendo associado um proces-
so muito leve a ser seguido. Tambm,
entregas so feitas de forma iterativa e
contnua. Isso possibilita que o cliente
utilize o produto desde o incio do Figura 1. Viso geral do Scrum
desenvolvimento, provendo feedback
constante. Feedback outro ponto importante: eles so bem Alguns duram uma ou duas semanas, outros um ms.
vindos e esperados, sendo sempre acomodados no Sprint se- O tamanho dele descoberto, literalmente por tentativa e erro.
guinte, caso necessrio. Documentao outro ponto chave: O Time deve testar vrios tamanhos de Sprint e escolher o ideal.
Scrum no exige documentao e sim, novamente, foco no O importante que, depois de um tempo, ele tenha um tama-
produto e por isso deve-se produzir o mnimo necessrio de nho constante, j que o Sprint dita o ritmo de desenvolvimento;
artefatos. e um ritmo constante d dinamismo ao desenvolvimento.
Uma questo interessante a seguinte: Se o Scrum to
bom e simples de entender, por que difcil de ser aplica- Reunio Diria
do?. Primeiramente, porque seus principais conceitos so Reunio de durao mxima de quinze minutos onde cada
quase que opostos ao que o desenvolvedor est acostumado membro do Time deve responder a trs perguntas:
com processos em cascata. Por exemplo, a ideia de o Time ser 1. O que desenvolvi desde a ltima reunio at agora?
responsvel pelo produto e no pessoas serem responsveis 2. O que planejo fazer at a prxima Reunio Diria?
individualmente por tarefas vai contra mo do que desenvol- 3. Tenho algum impedimento?
vedores esto acostumados. Tambm, entregas curtas, intera-
tivas, com valor e mesmo assim incompletas ou simplificadas Respondendo a essas questes, o Time ter uma viso do
geram bastante discordncia, pois isso novamente contraria a progresso do Sprint, bem como a quantidade e gravidade dos
metodologia empregada em processos em cascata. Finalmente, impedimentos. importante ater-se aos quinze minutos e
Scrum foca em pessoas e no em processos e, como bem se deixar eventuais discusses para depois. Isso ser tratado com
sabe, relaes pessoais, mesmo que de trabalho, podem ser mais detalhes em tpicos seguintes.
bastante complicadas.
A seguir dada uma breve descrio de cada etapa e papel do Reunio de Planejamento
Scrum, para que o leitor menos familiarizado com o framework Onde se inicia o Sprint, o Product Owner mostra a meta e as
possa entend-lo um pouco melhor. Entretanto, o foco do estrias para o Time. O Time ento negocia tal meta com o Pro-
artigo so os conselhos a serem aplicados em cada fase dessa duct Owner. Aps isso, o Time estima as estrias e as divide em
metodologia, discutidos depois da apresentao dos mesmos. tarefas. Caso o Time perceba que a meta est muito agressiva,
Finalmente uma discusso feita sobre aspectos do Scrum. uma nova negociao com o Product Onwer feita a fim de
combinar algo factvel.
Scrum
Nessa seo feita uma breve descrio de cada etapa do Reunio de Reviso do Sprint
Scrum, bem como os papis desempenhados, para contextu- Nessa reunio o Time faz uma demonstrao das funciona-
alizar o leitor. Observe a Figura 1: ela representa alguns dos lidades desenvolvidas no Sprint atual para o Product Owner e
principais conceitos utilizados no Scrum e como eles esto eventualmente para o cliente. Ento, o Product Owner aceita ou
associados. rejeita o produto entregue no Sprint. Tambm dado valioso
feedback ao Time sobre o que foi desenvolvido e sugestes para
Sprint melhorias em Sprints futuros.
Sprint o ciclo de desenvolvimento e entregas do Scrum.
Nele feito o planejamento, desenvolvimento, testes, entrega Reunio de Retrospectiva
e reviso do processo utilizado. O tamanho do Sprint varia de Aqui o Time, junto com o ScrumMaster, discutem o que pode
projeto para projeto, de Time para Time. ser melhorado em relao ao desenvolvimento do produto.

Edio 68 - Engenharia de Software Magazine 7

Aqui se discute tudo, processos, testes, relacionamento com
o cliente e entre membros da equipe. A ideia que sempre
se busque e implemente melhorias na prtica de desenvol-
vimento de software.
Papis
O Scrum possui apenas trs papis a serem desempenhados:
ScrumMaster: Pessoa responsvel por garantir que o
Time execute o Scrum de forma adequada, bem como resolver
impedimentos.
Product Owner: Pessoa responsvel entender o produto, bem
como planejar releases e Sprints para que o software em questo
seja implementado com sucesso. O Product Owner tem um profundo
conhecimento sobre o negcio no qual o produto atua e d todo o
suporte ao Time, explicando exatamente o que deve ser desenvol-
vido. Quaisquer decises de escopo, prazo e priorizao recaem
sobre o Product Owner.
Time: Grupo de pessoas responsvel efetivamente por
desenvolver o produto. Aqui se tem Arquitetos, DBAs, Desen-
volvedores, Testadores, etc.
Ritos do Scrum: problemas e solues
Aqui so discutidos, para cada cerimnia do Scrum, alguns dos
principais problemas, bem como algumas formas resolv-los.
Reunio de Planejamento
Como mencionado anteriormente, a Reunio de Planejamento
onde se inicia o Sprint. Essa uma cerimnia em que alguns
cuidados devem ser tomados:
1. Por ser uma reunio de apresentao e posterior discusso,
tem-se que ficar atento para que a mesma no se torne muito
longa; no mximo um dia.
2. Times imaturos tendem a aceitar as metas sugeridas pelo
Product Owner, sem realmente verificar se ela atingvel.
Deve-se ter muito cuidado para no subestimar o trabalho
necessrio, principalmente porque durante a apresentao
da meta, as tarefas ainda no foram quebradas e talvez sua
complexidade ainda no seja clara.
3. O Product Onwer no deixa clara a prioridade das estrias, o
que consequentemente faz com que o Time no as implemente
na ordem correta. Caso ele no se atente a isso, ScrumMaster
deve alert-lo.
4. A segunda parte da reunio, onde se quebram as estrias em
atividades, pode ser excessivamente demorada, pois algumas
pessoas tendem a esmiuar atividades mais do que o necessrio.
O Time deve acordar na definio do detalhamento mximo de
cada atividade. E j respondendo a pergunta que vem na cabea
do leitor: sim, esse detalhamento um conceito bastante abstrato
e difcil de acordar, mas com a prtica isso se torna fcil.
5. Alguns membros do Time participam pouco da reunio ou
no prestam ateno, esperando que posteriormente outros
membros os auxiliem nas suas atividades. O ScrumMaster,
mas principalmente o Time, deve estimular cada membro
a participar ativamente da reunio para tudo fique claro
para todos.
8 Engenharia de Software Magazine - Agile Development: Problemas e Solues no Scrum
Provavelmente, muitos dos problemas acima j foram en-
frentados pelo leitor que utiliza Scrum. Aqui so dados alguns
conselhos para que essa cerimnia seja feita da maneira mais
proveitosa possvel, evitando os problemas mencionados e
outros no citados.
Na primeira parte da reunio, onde o Product Owner apre-
senta a meta e estrias, algo que deve ficar claro : o que, em
termos de funcionalidades que agregam valor, quer-se atingir
para o prximo Sprint. No basta listar estrias e dizer que as
mesmas so as metas, tem-se que criar uma meta que mostre o
que o cliente ter de real valor ao seu sistema. Veja o exemplo
na Figura 2 de uma boa meta, juntamente com suas estrias
priorizadas.
Nesse exemplo obviamente so mostradas meta e estrias
bastante modestas, j que provavelmente mais estrias ca-
beriam no Sprint. Note que a meta no d muitos detalhes
do que ser implementado. Com ela, o Time conhece o que
importante a ser desenvolvido para o Sprint que se inicia. Por
tanto, caso o Time no consiga, por exemplo, implementar a
estria de Enviar o relatrio por e-mail, o Product Owner
ainda assim poderia aprovar o Sprint, j que a meta todavia
fora considerada atingida.
Agora, na Figura 3 observe um exemplo de uma meta
ruim e estrias escritas de forma que no agreguem valor ao
produto.
Note no exemplo que a meta lista com muitos detalhes
o que deve ser desenvolvido no produto. Logo, no uma
meta e sim uma listagem de itens. O problema de se utilizar
uma meta muito descritiva que o Time no tem a noo do
que importante para o cliente, em outras palavras, no se
tem o senso de que ser agregado de importante ao produto.
Portanto, logo aps a descrio da meta, importante tam-
bm dizer ao Time como a mesma impacta positivamente
o cliente.
Veja as estrias mostradas para a segunda meta, na Figura 3:
independentemente elas no adicionam funcionalidades ao
sistema. Implementar apenas uma tela ou regras de negcio
no geram algo til para o cliente. Uma estria deve ser uma
funcionalidade completa, mesmo que seja algo mais simples
do que o objetivo final da mesma, mas seja algo que j possa
ser usado pelo cliente. Na verdade, as estrias descritas para
a segunda meta so timos exemplos de tarefas para uma
estria maior. Por exemplo, as estrias 1, 2 e 3 da Figura 3
poderiam ser tarefas de uma estria de criao de Cadastro
de Produtos, da Figura 2.
Como mencionado anteriormente, alguns times subestimam
o tamanho das tarefas, ou ainda, aceitam o que o Product
Owner prope por pura presso. de suma importncia que,
para evitar isso, o Time entenda bem o que requisitado nas
funcionalidades. Ele deve questionar o Product Owner at ter
total entendimento das estrias. O Product Owner, por sua
vez, deve exigir o melhor do Time, sendo seu trabalho fazer
com que o Time desenvolva o mximo possvel em um tempo
razovel. Em resumo, uma boa negociao deve ser feita para
acordar-se uma meta de tamanho exato para o Sprint. Isso s
 agilidade

se alcana com experincia; o Time e o Note a importncia das discusses haja impedimentos, membros do Time
Product Owner erraro por alguns Sprints nessas estimativas. Aqui fica claro se possam ajudar uns aos outros. Ainda, o
at encontrar a medida exata. todo o Time entendeu com clareza o ScrumMaster pode resolver impedimen-
Em relao segunda parte da Reunio que deve ser desenvolvido. Depois das tos nos casos em que a equipe no possa
de Planejamento, quando se quebram as estimativas, caso a equipe perceba que se ajudar (fora da Reunio Diria).
estrias em atividades, deve-se atentar concordou com uma meta no factvel, A principal dificuldade que os times
a algumas coisas para que a reunio ter- ela deve chamar o Product Owner e rene- encontram nessa cerimnia ater-se
mine em um tempo razovel. Para cada gociar a meta. estritamente ao seu propsito, que :
estria e atividades, deve-se j propor a relatar o que foi feito at agora, o que
soluo para as mesmas e quebr-las em Reunio Diria ser feito at a prxima Reunio Diria e
tarefas que durem mais ou menos um Como explicado anteriormente, a Reu- se existe algum impedimento. Essa reu-
dia. Muitas vezes, ocorrem discusses nio Diria tem o objetivo de que, cada nio deve durar no mximo 15 minutos.
longas a fim de se determinar a melhor membro da equipe, saiba exatamente Nesse rito, as pessoas no resistem
soluo para cada estria. Para evitar como anda o andamento do Sprint e, caso tentao e comeam a discutir seus
isso, devem-se anotar as solues suge-
ridas, quebrar a tarefa em atividades e
postergar tais discusses. Com algumas
solues em mos, as pessoas respons-
veis pelas tarefas podem estudar melhor
o problema e propor o melhor caminho,
durante a fase de desenvolvimento.
A descrio das tarefas algo impor-
tante. Muitas vezes, as mesmas so
descritas sem muitos detalhes, o que
posteriormente dificulta o entendimento
das atividades, pois a pessoa que traba-
lhar na tarefa no se lembrar de todos
os detalhes. Por tanto, o Time deve expe-
rimentar vrios formatos e tamanhos de
tarefas at que encontre o tamanho ideal
para as mesmas. Figura 2. Meta adequada
As estimativas, geralmente so feitas
usando Scrum Planning Poker. Tal me-
todologia, resumidamente, consiste no
seguinte: cada membro da equipe fica
com um baralho de cartas que seguem
a sequncia de Fibonacci (1, 3, 5, 8, 13,
21, 34, 55,...). Uma estria base usada
como referncia para todo o desenvolvi-
mento do produto. Para ela, um nmero
(tamanho) da sequncia de Fibonacci
utilizado. Logo, quando se estima
cada estria cada membro deve pensar:
O quo maior ou menor a estria atual
em relao base? Caso a estria base
tenha o valor de 8 e a estria atual seja
desenvolvida em metade do tempo, 5
deve ser o valor escolhido. Caso a est-
ria atual necessite de quatro vezes mais
tempo, o valor 21 deve ser escolhido.
Para cada estria as ser estimada, as
pessoas mostram, como num jogo de
Pquer, o valor que acha correto, e caso
haja discrepncia, o Time discute at
chegar a um acordo. Figura 3. Meta inadequada

Edio 68 - Engenharia de Software Magazine 9

problemas e dar solues sobre questes do projeto, no per-
cebendo que isso no o objetivo desse encontro. Essas discus-
ses fazem que as Reunies Dirias passem de 15 minutos para
uma hora, onerando bastante a performance do Time, j que
muito tempo despendido. Portanto, de suma importncia
que se execute tal reunio estritamente como ela concebida,
e fica a cargo do ScrumMaster doutrinar o Time para que isso
ocorra. O melhor conselho para que o ScrumMaster consiga
tal objetivo o seguinte: seja rgido, interrompa sempre que
o foco da reunio for desviado, at que o Time se acostume.
Talvez leve um pouco de tempo, mas com insistncia a reunio
flui corretamente.
A Figura 4 bastante ilustrativa, em como se executar uma
Reunio Diria. Veja que as pessoas esto em p, focadas no
quadro de atividades. Isso ajuda bastante o foco nas tarefas em
questo e, o fato de ficar em p, faz com que o Time tenha von-
tade de terminar mais rpido, para voltar a suas cadeiras.
Figura 4. Reunio Diria
Sprint
Na execuo do Sprint, alguns cuidados devem ser toma-
dos. O problema mais comum a necessidade de insero de
estrias ou funcionalidades novas no meio do Sprint. Muitas
vezes, Product Owners so pressionados por clientes ou gerentes
de projeto a colocar funcionalidades, consideradas emergen-
ciais, para a prxima entrega. O Time deve ter autonomia de
rejeitar tais funcionalidades, caso elas modifiquem a meta e
arrisquem o sucesso do Sprint. Caso isso no seja permitido
pela empresa, ento o sucesso do Scrum estar em perigo, pois
se sua metodologia no pode ser seguida corretamente, talvez
esse no seja o melhor modelo a ser adotado (lembre-se que o
Scrum no a bala de prata que resolve todos os problemas
e no utiliz-lo no significa fracasso). Por outro lado, caso o
pedido do Product Owner seja razovel, algo que no signifique
a mudana de meta e no resulte na falha do Sprint, o Time deve
atend-lo. Perceba que, caso novas funcionalidades realmente
sejam emergenciais e necessrias, o Sprint deve ser cancelado e
uma nova Reunio de Planejamento necessita ser agendada para
o comeo de um novo Sprint.
Outro erro comum que ocorre a no priorizao das ativi-
dades. natural para cada membro do Time, executar as ativi-
dades que seja mais proficiente. Isso geralmente significa, para
10 Engenharia de Software Magazine - Agile Development: Problemas e Solues no Scrum
muitos, comear por tarefas de prioridade menor. Portanto,
algumas atividades de menor prioridade eventualmente sero
terminadas antes de tarefas de maior prioridade. Ou ainda,
atividades de maior prioridade no esto terminadas ao passo
que vrias tarefas de menor prioridade j esto comeadas.
Perceba o principal benefcio de se terminar tarefas com prio-
ridade maior: caso o Sprint falhe e a questo de prioridade seja
atendida, as estrias de maior prioridade j estaro terminadas,
o que significa que o cliente receber o que lhe de mais valor,
mesmo que no receba tudo. Por outro lado, caso as prioridades
no sejam atendidas e o Sprint falhe, o mesmo pode terminar
com todas as estrias comeadas, mas nenhuma terminada,
portanto sem nada a ser entregue ao cliente final.
A Figura 5 mostra um exemplo do quadro de atividades de
Scrum. Note que as atividades so ordenadas por prioridade.
Tal apelo visual ajuda bastante o Time a organizar-se para
implementar tarefas de maior prioridade antes de comear
as demais.
Figura 5. Quadro de atividades
Apesar do Scrum no abordar esse assunto especificamente,
algo importantssimo que sempre fica de lado a questo de
testes. muito comum para desenvolvedores de software
postergar testes, sempre que possvel. Contudo, importante
lembrar que as entregas de cada Sprint devem ser passveis
de utilizao pelo cliente, ou seja, devem estar bem testadas e
funcionais. Em outras palavras, deve-se evitar entregar est-
rias no testadas e, ao final do projeto, fazer alguns Sprints de
Testes. O motivo simples: at se chegar nesses Sprints de Testes,
o produto no poder ser utilizado pelo cliente, o que coloca
por terra todo o conceito de entregas iterativas. Entregas s so
entregas caso possam ser utilizadas pelo cliente, caso contrrio,
so apenas prottipos detalhados sem valor agregado.
 agilidade

Reunio de Reviso do Sprint
Essa cerimnia a que menos se encontram problemas, pois
algo que o Time j est acostumado a fazer em outras meto-
dologias. Aqui, como dito anteriormente, o Time apresenta ao
Product Owner o que foi implementado para alcanar a meta.
Nessa reunio, deve-se focar no Sprint atual, ou seja, nem o
Produt Owner, nem o Time devem discutir funcionalidades
anteriores. Alm disso, perfeitamente aceitvel uma entrega
com bugs, desde que os mesmos no impeam a utilizao
do sistema. Aqui, crucial a honestidade do Product Owner
em relao ao que pensa sobre o que foi entregue. Nessa
reunio, o Time recebe feedbacks e deve aceit-los de forma
no pessoal, lembrando que a crtica ao produto e no aos
membros da equipe. uma reunio que deve ser levada com
seriedade, mesmo que o Product Onwer tenha acompanhado
todo o desenvolvimento durante o Sprint. Um fato interessante
que nessa cerimnia, rotineiramente dvidas e questiona-
mentos aparecem, os quais dificilmente seriam notados se o
escopo completo do que foi desenvolvido no Sprint, no fosse
apresentado diante do Time e do Product Owner. Uma obser-
vao interessante: sempre que possvel, conveniente trazer
o representante do cliente para assistir essa reunio. Isso faz
com que o Time receba feedback imediato do cliente final,
alm de aproxim-los, devido a estarem no mesmo ambiente
interagindo, algo que sempre gera frutos positivos.
Algo que deve merecer ateno na Reunio de Reviso do
Sprint a maneira que feedbacks so dados. importante que
o Product Owner direcione os comentrios para o Time e no
para a pessoal que implementou a funcionalidade criticada.
O mesmo vale para elogios: todo o Time deve ser elogiado e
no uma pessoa em particular. Isso d ao Time a sensao, que
verdadeira, de que todos so responsveis pelo fracasso ou
sucesso do Sprint e, num contexto mais geral, do produto. Alm
do mais, isso evita que membros da equipe tenham problemas
pessoais com o Product Owner, e vice e versa.
de outros times, contar histrias pessoais, enfim, discutir qual-
quer outro assunto que no seja o projeto. Portanto, o Time deve
se esforar para focar no assunto em questo fazendo com que
a reunio efetivamente tenha resultado e no dure toda uma
manh ou tarde, com poucas questes relevantes discutidas.
Alm disso, importante estimular que todos os membros da
equipe falem. Mesmo que seja algo redundante, todos devem
dar sua opinio. Isso melhora a integrao entre a equipe e
muitas vezes pessoas mais tmidas expem pontos de vista
bastante interessantes e diferenciados, pois falam pouco e
observam mais.
Outro bom conselho: quando se aponta um problema, deve-
se sugerir uma soluo. S reclamar, como todos sabem, no
adianta. Portanto, sempre quando uma crtica for trazida,
importante que a mesma pessoa traga uma possvel soluo.
Isso traz dois benefcios: primeiramente, j se tem algo para
comear a resolver o problema e segundo, o Time v cada um
dos seus pares de uma forma muito mais amistosa, pois se
trazendo a soluo, a pessoa que a trouxe cria para si a imagem
de algum que quer ajudar a resolver os problemas.
Algo interessante que acontece em times maduros a apa-
rente falta de necessidades de melhorias. Algumas vezes,
depois de certo tempo de trabalho, o Time no sugere mais
melhorias, pois cr que j est num ritmo bom e nada mais
pode ser aprimorado. Isso um engano. muito difcil, para
no dizer impossvel, estar em um grau de desenvolvimento
que no haja espao para aperfeioamentos.

Reunio de Retrospectiva
Essa reunio, sem dvida, a que gera as mais acaloradas
discusses. Portanto, deve-se tomar bastante cuidado para que
desavenas entre membros do Time no ocorram. Logo, alguns
conselhos so mostrados a seguir para que essa cerimnia
ocorra da maneira mais tranquila possvel. O ScrumMaster
a pessoa mais indicada para conduzir a reunio da melhor
forma possvel.
Primeiramente, como na Reunio de Reviso do Sprint, sempre
que possvel, ao fazer-se uma crtica, no direcion-la a um
membro da equipe. Crticas devem ser feitas ao Time todo,
pois o Time responsvel pelo produto. Quando se menciona
nomes, a discusso se torna pessoal, o que mina o objetivo
da reunio, que o melhoramento contnuo do processo de
desenvolvimento.
Outro ponto o seguinte: o foco da discusso deve ser o
projeto. Quando reunies em que o objetivo , entre outros,
apontar defeitos, muitas vezes o tpico principal da conversa
desviado; membros do Time comeam a reclamar da empresa,

Edio 68 - Engenharia de Software Magazine 11

 Deve-se verificar se algumas metas comuns a desenvolvi-
mento gil j foram atingidas, tais como: testes automatizados,
poucos bugs, integrao continua, cdigo com boa qualidade,
etc. Poucos times chegam a executar todas as boas prticas
citadas. Para os que conseguem, a hora de pensar fora da
caixa e sugerir atividades que melhorem ainda mais o que
j est bom.
Papis no Scrum e principais desafios
Nesse tpico so discutidos os principais desafios de cada
papel exercido no Scrum.
Product Owner
O principal desafio do Product Owner entender o produto.
Tarefa que no tem nada de trivial. Imagine-se na situao
de criar algo que no existe. Nessa simples sentena, esse
o desafio do Product Owner. Para que isso seja possvel, aqui
vo alguns conselhos.
Primeiramente, estude muito sobre o produto a ser criado. V
alm do papel de um Analista de Requisitos. O negcio em torno
do produto a ser desenvolvido precisa ser entendido. O que tal
produto trar de ganho deve ficar perfeitamente claro. Em outras
palavras, o Product Owner precisa se tornar temporariamente
especialista no negcio referente ao que ser criado.
Alm disso, uma estratgia de priorizao e Time to Market (
o intervalo de tempo, desde a concepo at a disponibilidade
de venda de um produto. Esse conceito importante onde
produtos so considerados obsoletos rapidamente) devem ser
traados. de suma importncia que as primeiras funcionali-
dades do produto sejam as que mais tragam valor ao negcio
do cliente. Perceba como isto est intimamente ligado com a
questo de priorizao, que sempre enfatizada no Scrum.
Alm disso, um produto tem seu tempo certo para ser lanado,
ou o cliente perder mercado para a concorrncia, da vem a
importncia do Time to Market.
Outro desafio fundamental para o Product Onwer a co-
municao. Quem atuar nesse papel deve comunicar-se ade-
quadamente, tanto com o cliente, como com a equipe tcnica
que desenvolve o produto. Isso significa participar de dois
mundos distintos: o do cliente que conhece apenas jarges de
negcio do meio onde atua, e do Time de desenvolvimento, que
possui um linguajar extremamente tcnico. Por esse motivo,
profissionais que atuam nesse papel geralmente originam de
uma carreira relacionada a desenvolvimento de software, j
que esto aptos para entender o mundo dos clientes e esto
acostumados a lidar com times tcnicos.
Time
O Time engloba toda a equipe tcnica, responsvel pelo desen-
volvimento do produto. Fazer parte de um Time de Scrum no
nada simples, principalmente para quem vem do mundo de
metodologias em cascata. Profissionais, em geral, no apenas
do ramo de desenvolvimento de software, tem o hbito de de-
senvolverem atividades completas, do incio ao fim. No Scrum,
isso muda bastante. O Time tem como o objetivo acabar estria
12 Engenharia de Software Magazine - Agile Development: Problemas e Solues no Scrum
mais prioritria e apenas depois, partir para a prxima. Isso
no natural para profissionais em geral, pois durante todas
as suas vidas, pessoas so doutrinadas a trabalharem sozinhas
em atividades completas, ou mesmo que trabalhem em grupo,
dividem suas atividades de maneira a terem algo de tamanho
aceitvel, sem o desafio de priorizao de estrias.
Na Figura 2 veja o exemplo da primeira estria: Como usu-
rio desejo cadastrar e editar produtos.. Para um Time de duas
pessoas, a diviso de tal estria seria algo trivial. Por exemplo,
um dos desenvolvedores criaria a interface com o usurio e
outro a camada de negcios. Contudo, imagine agora cinco
desenvolvedores. O desafio maior. O primeiro pensamento
: existe pouca tarefa para muitas pessoas, portanto o Time
poderia decidir comear mais estrias. Muitas vezes, essa a
melhor soluo, pois, nesse exemplo, se fosse um Time de nove
pessoas, certamente no seria possvel quebrar essa estria
atividades suficientes para tantas pessoas. Entretanto, ser
que no possvel quebr-la para cinco pessoas? A resposta
a essa questo depende da arquitetura e da criatividade dos
desenvolvedores. Um software desenvolvido em MVC (Model
View Controller) poderia ter duas pessoas responsveis pela
tela: uma para o design e outra pelas interaes com Javascript,
uma pessoa desenvolvendo o Controller e mais duas na camada
de persistncia e negcios que, se tivessem baixo acoplamento
poderiam ser divididos.
Outro enorme desafio para os times a questo de testes.
Processos em cascata viciam desenvolvedores a deixarem
testes para o final do desenvolvimento. preciso reeducar
o Time a sempre testar e entregar produtos estveis e de boa
qualidade a cada Sprint. Para se alcanar isso no h segredo:
deve-se insistir nessa meta, at que a mesma seja alcanada.
Isso no acontecer no primeiro Sprint, mas o Time deve lutar
para uma melhora constante at que tal prtica seja natural.
ScrumMaster
Esse, sem dvida, o papel mais complicado do Scrum,
basicamente porque o ScrumMaster no possui autoridade
alguma sobre o Time. Ele deve persuadir a equipe a utilizar
essa metodologia sem nenhuma imposio ou poder. Tal ar-
gumentao para desenvolvedores no acostumados a isso
longa e penosa. A grande maioria deles s v valor no Scrum
depois de alguns meses utilizando o framework. Durante esse
perodo, o ScrumMaster deve ter muita pacincia e tenacidade
para lidar com inseguranas e questionamentos do Time.
Outro desafio, que infelizmente, no depende apenas do
ScrumMaster a resoluo de impedimentos. Muitas empre-
sas no do autonomia para que a pessoa que desempenha
esse papel possa de fato, por exemplo, interagir com clientes
ou com a gerncia da empresa onde trabalha, para resolver
impedimentos. A entra a criatividade: o ScrumMaster deve
ser habilidoso para persuadir outras pessoas a lhe ajudarem.
Por exemplo, ele deve convencer o Product Owner a conversar
com o cliente a fim de resolver alguma pendncia (suponha
pendncias de requisitos para a finalizao de uma estria).
Ou ainda, ele deve ter um bom relacionamento com outras

reas para conseguir, por exemplo, recursos materiais para
terminar uma estria (por exemplo, PCs com entradas seriais
para comunicao com mquinas antigas).
Alm disso, ScrumMaster deve ter profundo conhecimento
do Scrum para direcionar o Time de modo a segui-lo correta-
mente. Um concelho importante : no faa o Time adaptar-se
ao Scrum no primeiro Sprint. saudvel que o Time adapte-se
ao framework paulatinamente, para que se acostume a ele e o
processo transitrio seja o menos traumtico possvel. Reuni-
es de Retrospectiva so sempre interessantes para introduzir
novos passos e conceitos a serem seguidos no Scrum.
Scrum e uma soluo definitiva
Muito se discute se Scrum a soluo para todos os proble-
mas de processos em cascata. A resposta simples: no. Scrum
resolve vrios problemas, como o encorajamento a mudana, a
valorizao do indivduo em relao a processos, entre outras
questes mencionadas aqui. Contudo, alguns problemas ainda
permanecem.
Estimativas um problema sem soluo ainda. Apesar
das estimativas por pontos no Scrum, aps uma calibrao por
vrios Sprints, mostrar bom resultados, ainda se tem o srio
problema de entender-se e estimar um projeto de mdio a longo
prazo. Mesmo atividades simples so mal estimadas, at hoje.
Em outras palavras, no Scrum se consegue estimar estrias a
serem desenvolvidas no perodo de um Sprint, mas ainda no
se consegue estimar com exatido um projeto qualquer, com
durao de um ano, por exemplo.
Lidar com pessoas ainda um desafio, e provavelmente o ser,
por muitos anos. O Scrum ainda piora esse problema, pois
tira totalmente o foco de processo e o coloca em pessoas.
Scrum, apesar de fcil de entender, um processo dificlimo
de seguir, como discutido em tpicos anteriores.
Qualidade do cdigo
Em processos em cascata, a qualidade do cdigo era bem
controlada se o projeto possusse um arquiteto com bons
conhecimentos e autoridade. Com Scrum, como o Time res-
ponsvel pelo produto e pelo cdigo, no se permitido ter
uma pessoa com autoridade para forar membros da equipe
a codificarem com qualidade. Com frequncia, boa parte do
Time no se importa com a qualidade do cdigo. Isso gera
problemas enormes no futuro, pois, com a necessidade de
manuteno contnua e com o dinamismo muito grande dos
Sprints, cdigo mal estruturado comea fazer com que o Time
agilidade
diminua sua performance pois obrigado a interagir com c-
digo de m qualidade. Portanto, o Time deve se conscientizar e
garantir uma boa qualidade, tanto do produto, como do cdigo.
O ScrumMaster pode ajudar bastante nisso, mostrando ao Time
as vantagens de se codificar com qualidade.
Testes automatizados
Testes automatizados, de maneira alguma so obrigatrios
para o sucesso de um projeto. Principalmente se o mesmo for de
curta durao. Contudo, para a criao de produtos que tero
uma longa vida e sero extensos, recomenda-se fortemente
a criao dos mesmos. O tempo dispendido na sua criao e
manuteno ganho durante testes de regresso que so feitos
automaticamente pelos testes.
Veja o seguinte cenrio: imagine um produto onde, caso
as funcionalidades atuais quebrem algo desenvolvido
anteriormente, o desenvolvedor seja imediatamente avisado
de tal problema. Nesse mesmo produto, no so necessrios
testes de regresso nem a preocupao com funcionalidades j
desenvolvidas que atualmente esto em funcionamento. Esse
produto, necessariamente possui testes automatizados.
Entretanto, no se engane pensando que testes automatizados
so a bala de prata para problemas de testes de produtos.
Mesmo com eles, ainda podem existir erros oriundos de novas
funcionalidades que no foram detectados pelos testes automa-
tizados. Contudo, a frequncia destes ser bem menor.
Scrum, sem dvida alguma, resolve inmeros problemas de
processos em cascata. Contudo, desenvolvimento de software
ainda continua uma atividade complexa e com muitos desa-
fios. Por fim, observe que o Scrum deve ser encarado como um
framework que ajuda o desenvolvimento de software, mas
apenas uma metodologia. O sucesso do produto criado est
nas mos do Time que trabalha nele.
Links:
Manifesto gil
http://agilemanifesto.org/
Voc gostou deste artigo?
D seu voto em www.devmedia.com.br/esmag/feedback
Ajude-nos a manter a qualidade da revista!
Edio 68 - Engenharia de Software Magazine 13
Planejamento e Gerncia
Nesta seo voc encontra artigos voltados para o planejamento
e gerncia de seus projetos de software.
Groupware: Modelo de comunicao para
projetos distribudos
Um estudo utilizando ferramentas de groupware
Leonardo Sanches dos Santos
Mestrando em Computao Aplicada pela
Universidade Tecnolgica Federal do Paran na
subrea de Engenharia de Software, atuando
na linha de pesquisa de qualidade no processo
de desenvolvimento de software com equipes
geograficamente distribudas, especialista em
Anlise, Projeto e Gerncia de Sistemas com
nfase em Inteligncia em Negcios pela Uni-
versidade Estadual de Londrina e graduado em
Anlise e Desenvolvimento de Sistemas pela
Universidade Tecnolgica Federal do Paran.
Profissionalmente, atua como Gerente de Pro-
jetos na empresa BlueOri, especializada em e-
commerce para mdias e grandes empresas.
Alexandre LErario
Possui graduao em Tecnologia em Processa-
mento de Dados pela Fundao Educacional do
Municpio de Assis (1998), mestrado em Cincia
da Computao pela Universidade Federal de
So Carlos (2001) e doutorado em Engenharia
da Produo pela Poli/USP (2009). Atualmente
professor da Universidade Tecnolgica Federal
do Paran. Tem experincia na rea de Cincia
da Computao, com nfase em desenvolvi-
mento distribudo de Software.
14 Engenharia de Software Magazine - Groupware: Modelo de comunicao para projetos distribudos
Jos Augusto Fabri
Possui graduao em Tecnologia em Processa-
mento de Dados pela Fundao Educacional do
Municpio de Assis (1997), mestrado em Cincia
da Computao pela Universidade Federal de
So Carlos (1999) e Doutorado em Engenharia
de Produo pela Escola Politcnica da Univer-
sidade de So Paulo. Atualmente professor
adjunto da Universidade Tecnolgica Federal
do Paran. Atua nos seguintes temas da com-
putao: Engenharia de Software, Processo de
Produo de Software e Fbrica de Software.
A
o longo dos ltimos anos, vem
se tornando comum encontrar
empresas motivadas a aderir ao
modo de desenvolvimento de software
com equipes distribudas, ou seja, lo-
calizadas geograficamente distantes,
estando estas dispersas at mesmo entre
continentes.
Este tipo de modalidade vem ganhan-
do foras devido aos interesses das orga-
nizaes em reduzir custos de projetos,
Fique por dentro:
Para se ter qualidade em um processo de de-
senvolvimento de software com equipes geo-
graficamente distribudas necessrio ter uma
comunicao eficaz entre os envolvidos, a fim
de que haja a compreenso mtua na troca de
mensagens. Deste modo, este artigo tem como
objetivo propor um modelo de comunicao cria-
do com base em um estudo de caso aplicado em
uma empresa de desenvolvimento de software, o
qual contribuiu para o aumento da produtividade
de desenvolvimento da empresa e na qualidade
de disseminao e armazenamento das infor-
maes. Portanto, este artigo pode ser aplicvel
a todas as empresas que desejam melhorar a
qualidade do fluxo de repasse de requisitos ou in-
formaes de seus projetos, que tenham dificul-
dades ou perdas de informaes dentro do fluxo
de comunicao existente e para as organizaes
que no possuem experincia com a utilizao de
ferramentas de groupware para a realizao de
trocas de mensagens entre equipes de desenvol-
vimento distribudas.
adquirirem profissionais mais especiali-
zados, conquistar uma presena globali-
zada, alm de poder estar mais prxima
de seus clientes em modo geral.

Neste contexto, os projetos realizados necessitam de comu-
nicao entre stakeholders (envolvidos ou afetados por um
projeto ou por seus resultados, seja uma pessoa, grupo ou
organizao) fisicamente distantes para compreender como
as tarefas devem ser executadas e quais objetivos devero ser
alcanados. Deste modo, a comunicao consome recursos para
troca de informaes a fim de promover a compreenso mtua,
item essencial no gerenciamento de qualquer projeto.
Ainda nesta perspectiva, com o intuito de diminuir custos e
facilitar a comunicao entre as pessoas dispersas no espao e
tempo, as equipes utilizam-se das ferramentas de groupware
que so mediadas por computador para a realizao da comu-
nicao e gerenciamento das trocas de mensagens. Groupware
a tecnologia baseada em mdia digital que possibilita suporte
as pessoas organizadas em grupos que podem variar em ta-
manho, composio e local de trabalho.
O objetivo deste artigo apresentar um modelo de comu-
nicao para projetos distribudos de software com auxlio
de ferramentas de groupware, gerado a partir de um estudo
de caso, aplicado em uma empresa de desenvolvimento de
software contida dentro de um cenrio de Desenvolvimento
Distribudo de Software (DDS).
O estudo de caso surgiu com o propsito de levantar os
principais pontos falhos na comunicao dentro do processo
de desenvolvimento empregado pela empresa e minimizar
a constante interrupo das equipes com o fluxo de comuni-
cao, o que aumentaria consequentemente a produtividade
de entrega dos projetos. Para tanto, dados foram coletados e
analisados de forma quantitativa e qualitativa para obter uma
viso da frequncia e eficcia da comunicao. Finalmente,
um modelo de comunicao foi implantado com o objetivo de
minimizar a sobrecarga de informaes incrementadas ao pr-
prio processo de comunicao, aumentando a produtividade
de desenvolvimento e o nvel de qualidade na comunicao e
disseminao das informaes.
Os principais pontos falhos do processo
Foi necessria a realizao de um estudo para identificar se
as informaes geradas no processo de desenvolvimento dos
produtos estavam sendo armazenadas e disponibilizadas a
todos os envolvidos de forma eficiente e segura, sem que haja
centralizao de informaes em determinados membros.
Alm de utilizar os dados coletados no estudo de caso como
base para a criao do modelo de comunicao que ser propos-
to neste artigo, o qual define um fluxo padro de comunicao
para organizaes imersas em ambientes de DDS.
O objetivo do estudo de caso foi mapear o fluxo de comuni-
cao realizado entre as equipes dispersas em um cenrio de
DDS, com o intuito de coletar dados das trocas de informaes
realizadas, a fim de identificar os problemas existentes no cen-
rio atual e mapear os meios de comunicao mais utilizados.
O estudo foi executado por meio de um monitoramento rea-
lizado em um perodo aproximado de um ms, considerando
deste perodo apenas os dias teis de acordo com o calendrio
e horrios comerciais do Brasil, nos quais haviam expediente.
planejamento
Os participantes envolvidos nesta pesquisa foram os prprios
colaboradores da empresa, os quais possuem diferentes nveis
de conhecimento e funes dentro da organizao, sendo
desenvolvedores, testadores, gerentes de projetos, diretores
executivos, designers e recepcionista.
As informaes do estudo de caso foram coletadas por
meio de formulrios individuais em formato de planilha
disponibiliza em um servidor na nuvem, onde o responsvel
pela aplicao do estudo possua acesso em tempo real das
informaes preenchidas pelos participantes, podendo desta
forma monitorar se todos os membros envolvidos estavam
preenchendo os dados de forma adequada e corrigi-los se
necessrio.
A aplicao do estudo de caso em forma de questionrio teve
como objetivo facilitar a compreenso e o preenchimento das
informaes durante a rotina de trabalho dos participantes.
Cenrio
O estudo de caso deste artigo foi realizado em uma empre-
sa de desenvolvimento de software, atuante no mercado
aproximadamente seis anos e especializada em e-commerce
e aplicaes Web.
A empresa citada utiliza mtodos geis Scrum e o modelo
Kanban no processo de desenvolvimento dos softwares. O
Scrum framework baseado em pequenas iteraes, que
possui fases dinmicas e menos burocrticas em relao aos
modelos de qualidade tradicionais. J o Kanban um modelo
que fornece ainda mais transparncia ao processo e ao fluxo
que est sendo executado, o que possibilita a visualizao
clara dos gargalos, filas, variabilidade e desperdcios das
atividades, este modelo se resume em visualizar processos,
limitar o trabalho em andamento definido do ingls como
WIP (Work In Progress) e gerenciamento do lead-time (tempo
que a atividade leva para passar por todas as fases, desde a
concepo at a entrega).
A organizao atua em um cenrio de Desenvolvimento Dis-
tribudo de Software composto por quatro partes distintas:
Clientes de perfil A (clientes que possuem setor de Tecno-
logia da Informao (TI) na empresa, ou seja, participam da
construo do produto, inclusive da codificao);
Clientes de perfil B (clientes convencionais que no pos-
suem setor de TI na empresa, participam apenas da gerncia
de requisitos);
Equipe de desenvolvimento que atua de forma remota (sem
local fixo, trabalha de qualquer ambiente que haja os requisitos
mnimos para exercer suas funes);
Equipe de desenvolvimento que trabalha na sede da
organizao.
Porm, apesar das equipes estarem geograficamente dis-
tantes, a unio do trabalho das partes essencial para a
construo do produto final. A Figura 1 mostra o contexto
no qual o estudo de caso foi aplicado e como ocorre o fluxo
da comunicao e o armazenamento das informaes entre
as partes envolvidas.
Edio 68 - Engenharia de Software Magazine 15

Figura 1. Cenrio do processo de Desenvolvimento Distribudo de
Software da empresa estudada
Pode-se observar a partir das setas 1, 2 e 3 que a interao
de todas as partes se centraliza na empresa X, de forma que
ela recepciona as informaes e gerencia o repasse e o arma-
zenamento do que foi comunicado de acordo com o processo
de desenvolvimento adotado no projeto.
Os artefatos gerados durante o processo de construo do
software so armazenados em um servidor hospedado na
nuvem (servidores compartilhados e interligados por meio da
Internet) pelas partes que participam do processo de constru-
o do software como se pode observar nas setas 4, 5 e 6 da
Figura 1. As conversas formais so realizadas por meio de chamadas de
Fluxo de comunicao entre os envolvidos no projeto
As trocas de informaes entre as equipes dispersas ocorrem
de forma aleatria entre os envolvidos, de modo que as infor-
maes no so centralizadas em um membro especfico da
empresa, o qual seria responsvel por gerenciar a coleta e o
repasse das informaes. Desta forma, os clientes se comuni-
cam diretamente com os desenvolvedores para solicitao de
novas demandas, esclarecimentos de dvidas e acompanha-
mento do projeto.
A Figura 2 mostra como o fluxo de comunicao ocorre entre
os envolvidos no processo de desenvolvimento do software.
Pode se observar que os clientes tm acesso direto aos de-
senvolvedores e demais colaboradores da empresa, tanto os
clientes de perfil A, quanto os de perfil B. Com este fluxo
de comunicao as informaes se dividem entre vrios cola-
boradores, de acordo com o que exibido na Figura 2 com as
setas de 1 a 4. Deste modo, a empresa depende de todos estes
colaboradores para descentralizar as informaes retidas a eles
e dissemin-las aos demais membros, porm esta prtica nem
sempre pode acontecer, seja por indisciplina, por urgncia ou
pelo fato do colaborar no possuir qualificaes necessrias
para realizar mltiplas funes.
A comunicao entre as equipes dispersas ocorre por meio
de ligaes telefnicas e reunies distribudas com auxlio
16 Engenharia de Software Magazine - Groupware: Modelo de comunicao para projetos distribudos
de ferramentas de groupware, que so meios de comunicao
online que possibilitam trocas de informaes por meio de
mensagens instantneas, chamadas de udio e vdeo como,
por exemplo: Messenger, Skype, Google Hangouts entre
outros similares.
Figura 2. Fluxo de comunicao entre os envolvidos
udio e vdeo e documentadas por meio do correio eletrnico
(e-mail) entre os envolvidos no assunto que esteve em pauta. J
as conversas informais so realizadas por meio de mensagens
instantneas e caso haja necessidade de documentar alguma
informao relevante extrada da conversa documentado por
e-mail mantendo em cpia os interessados.
Porm, apesar de ocorrer o armazenamento de parte das
informaes obtidas na interao entre as equipes geogra-
ficamente distantes, a maneira como estas informaes so
armazenadas dificulta muito a compreenso dos membros do
projeto, pelo fato de serem persistidas na maior parte das vezes
de forma resumida e abstrata devido rotina de trabalho e
sobrecarga destes colaboradores exercendo mltiplas funes
que fogem de suas obrigaes reais.
Dados coletados
A execuo do estudo de caso teve aproximadamente um ms
de durao, porm logo na segunda semana pode-se notar que
as informaes armazenadas comearam a se repetir frequen-
temente com relao aos meios de comunicaes e ferramentas
utilizadas para a realizao das trocas de mensagens, portanto
devido ocorrncia repetitiva de informaes nos formulrios
preenchidos pelos participantes, possvel relatar que se o
estudo de caso se prolongasse por mais tempo os resultados
no sofreriam mudanas radicais.

De acordo com os dados coletados nos formulrios preen-
chidos pelos colaboradores, os meios de comunicao mais
utilizados nas trocas de mensagens entre as equipes foram:
Chamada de voz via ferramentas de comunicao online, as
mais utilizadas foram: Skype e Google Talk.
Chat, por meio de ferramentas de mensagens instantneas,
as mais utilizadas foram: Skype e Slack;
Correio Eletrnico (e-mail);
Ligao via telefone fixo e celulares;
Vdeo Conferncia, por meio de ferramentas de comunicao
de udio e vdeo, a mais utilizada foi: Google Hangouts.
Os dados coletados na pesquisa totalizaram em 806 ocorrn-
cias, divididas em:
131 ocorrncias por chamada de voz;
384 ocorrncias via chat (mensagens instantneas);
266 ocorrncias via e-mail;
10 ocorrncias com ligaes via telefone fixo e celular;
15 ocorrncias relacionadas a vdeo conferncias;
A Figura 3 mostra estatisticamente as ocorrncias mapeadas
durante o fluxo de comunicao das equipes dispersas.
Figura 3. Meios de comunicao utilizados no fluxo de comunicao
Alm dos meios de comunicao, foi mapeado o fluxo de
comunicao realizado entre a empresa e as equipes dispersas,
em que foram levantados os seguintes nmeros:
630 ocorrncias referentes a comunicao entre os clientes
de perfil A e a empresa;
101 ocorrncias referentes a comunicao entre os clientes
de perfil B e a empresa;
75 ocorrncias referentes a comunicao entre a equipe
remota e a empresa.
A Figura 4 exibe, de acordo com as ocorrncias coletadas, os
fluxos de comunicao mais frequentes.
Outras informaes relevantes puderam ser analisadas e
definidas no estudo de caso realizado. A Figura 5 mostra a pro-
poro de dados que foram gerados e armazenados fisicamente
planejamento
a partir do fluxo de comunicao no servidor que de acesso
livre a todos os envolvidos no projeto.
Com os resultados mostrados nessa ltima figura, pode-se
concluir que menos da metade de todo o fluxo de comunicao
gerado neste cenrio armazenado fisicamente (informaes
armazenadas em alguma forma, seja em documentos armaze-
nados na mquina local, repositrios virtuais ou servidor) para
serem disponibilizados para os demais colaboradores.
Figura 4. Fluxo de comunicao entre a empresa e as equipes dispersas
Figura 5. Armazenamento de informaes decorrente do fluxo de
comunicao
Modelo de comunicao
O modelo de comunicao proposto foi desenvolvido com
base no estudo de caso, tanto por meio da anlise dos dados
quantitativos, quanto qualitativos. A estrutura criada teve
como base o cenrio diversificado da empresa em que foi reali-
zada a pesquisa, alm da utilizao de algumas caractersticas
do framework Scrum para a criao dos papis existentes no
modelo.
Os objetivos do modelo so maximizar o foco e produtivi-
dade da equipe de desenvolvimento, evitando que ela seja
constantemente interrompida e que exera outras funes
que vo alm da sua principal que desenvolver software e
aumentar a qualidade da comunicao e da disseminao das
informaes entre os envolvidos estejam eles dispersos ou no,
alm de evitar a centralizao de informaes em membros
especficos.
Edio 68 - Engenharia de Software Magazine 17
 Com o intuito de alcanar os objetivos, o modelo apresenta
um papel chamado de Internal Product Owner, onde gran-
de parte das caractersticas foi herdada do papel de Product
Owner existente no Scrum, salvo algumas excees que foram
acrescentadas. Esta funo tem como objetivo intermediar
as trocas de informaes que ocorriam entre os clientes e os
desenvolvedores. Deste modo, este papel ter as seguintes
caractersticas:
Manter contato direto com os clientes, a fim de coletar todas
as informaes reportadas por eles;
Disseminar as informaes coletadas para os envolvidos
que necessitem das mesmas por meio das ferramentas de
groupware;
Documentar as informaes relevantes e torn-las pblicas
para todos os envolvidos por meio de algum repositrio que
ambos tenham acesso;
Gerenciar o backlog (lista de requisitos priorizadas) do
projeto;
Esclarecer dvidas de escopo de atividades e regras de
negcio com o cliente;
A Figura 6 exibe a estrutura do modelo de comunicao
proposto e como recomendado que o fluxo de comunicao
ocorra.
Figura 6. Modelo de comunicao proposto
De acordo com essa figura, possvel observar que para as
informaes chegarem aos desenvolvedores, primeiro so fil-
tradas pelo Internal Product Owner, o qual neste momento
detalha as atividades, documenta ou registra no backlog e
repassa para os desenvolvedores em momentos oportunos, a
fim de no tirar o foco dos mesmos nas atividades que esto
sendo desenvolvidas. Porm, vale ressaltar que mesmo com
a aplicao deste modelo, os desenvolvedores ainda podero
ter contato com os clientes, mas deve ser de forma pontual,
ou seja, algum assunto tcnico que haja a necessidade de ser
tratado apenas com os desenvolvedores.
18 Engenharia de Software Magazine - Groupware: Modelo de comunicao para projetos distribudos
Resultados
Baseado no cenrio diversificado da empresa, em que
as equipes possuem diferentes nveis de conhecimento
e papis dentro dos projetos, alm da diferena geogr-
fica das equipes, o nvel de compreenso das atividades
e consistncias das informaes devem ser mantidos
constantemente.
Com a aplicao do modelo de comunicao, pode-se
observar de forma qualitativa que a equipe de desenvolvi-
mento da empresa e a equipe remota tiveram um ganho em
relao ao foco e a produtividade na entrega das atividades,
alm da melhoria dos escopos das atividades e distribuio
de informaes por possuir um profissional focado em
gerenciar a comunicao e a gesto do conhecimento entre
as equipes dispersas.
Aps a implantao do modelo, foi executado novamente o
estudo de caso por perodo igual execuo anterior e os re-
sultados quantitativos totalizaram em 819 ocorrncias com os
clientes, sendo que 782 foram realizadas com o Product Ow-
ner Interno e apenas 37 com a equipe de desenvolvimento.
A Figura 7 exibe as ocorrncias coletadas.
Figura 7. Fluxo de comunicao (Clientes x Empresa)
De acordo com a figura, fica claro o aumento do foco da
equipe de desenvolvimento em suas atividades. Os meios
de comunicao utilizados nas trocas de informaes no
sofreram mudanas expressivas, de forma que foram ma-
peados os seguintes dados:
226 ocorrncias por chamada de voz;
312 ocorrncias via chat (mensagens instantneas);
277 ocorrncias via e-mail;
zero ocorrncias com ligaes via telefone fixo e celular;
quatro ocorrncias relacionadas a vdeo conferncias;
Na Figura 8 possvel observar a utilizao dos meios de
comunicao entre as equipes dispersas.
Com relao ao armazenamento de informaes geradas a
partir do fluxo de comunicao tambm houve aumento, de
modo que as informaes deixaram de ter dono de conhe-
cimento e ficaram disponveis de forma pblica para toda a
equipe. A Figura 9 mostra a porcentagem de comunicaes
que gerou algum tipo de armazenamento, seja por e-mail,
documento, imagens, gravao de udio e outros.

Figura 8. Meios de comunicao utilizados no fluxo de comunicao
Figura 9. Armazenamento de informaes
Com a atribuio de uma funo especfica para gerenciar o
fluxo de comunicao e disseminao de informaes, a figura
exibe o aumento significativo de informaes armazenadas
em comparao aos dados coletados antes da aplicao do
modelo.
Os resultados gerados com o uso da abordagem foram po-
sitivos tanto na melhora do foco e produtividade das equipes
de desenvolvimento, quanto na qualidade no fluxo de comu-
nicao e gesto do conhecimento da empresa.
planejamento
Alm destes benefcios, com a implantao do modelo
de comunicao proposto foi possvel tambm aumentar a
qualidade dos escopos dos projetos e a disseminao das in-
formaes a todos os envolvidos, pelo fato de que a empresa
passou a ter uma funo especfica para coletar as informaes
externas e armazen-las de forma pblica a toda a equipe,
evitando desta forma a centralizao de conhecimento em
pessoas especficas.
Referncias:
[1] F. S. F. Soares, L. M. R. de Sousa Mariz, Y. C. Cavalcanti, J. P. Rodrigues, M. G.
Neto,. R. Bastos, A. C. M. Almeida, D. T. V. Pereira, T. da Silva Arajo, R. S. Cor-
reia et al., Adoo de scrum em uma fbrica de desenvolvimento distribudo
de software, Centro de InformticaUFPERecifePEBrasil, 2007.
[2] C. Trindade, A. Moraes, and S. Meira, Comunicao em equipes distribu-
das de desenvolvimento de software: Reviso sistemtica, in ESELAW08:
Proceedings of the 5th Experimental Software Engineering Latin American
Workshop, 2008.
[3] E. Carmel, Global software teams: collaborating across borders and time
zones. Upper Saddle River, NJ, USA: Prentice Hall PTR, 1999.
[4] L. E. Chaves, F. H. Silveira, G. Pech, and M. F. d. S. Carneiro, Gerenciamento
de comunicao em projetos. Editora FGV, 2006.
[5] H. Fuks; M. Gerosa; M. G. Pimentel. Projeto de Comunicao em Groupwa-
re: Desenvolvimento, Interface e Utilizao. In: XXII Jornada de Atualizao
em Informtica, Anais do XXIII Congresso da Sociedade Brasileira de Com-
putao V. 2003. p. 295-338
Voc gostou deste artigo?
D seu voto em www.devmedia.com.br/esmag/feedback
Ajude-nos a manter a qualidade da revista!
Edio 68 - Engenharia de Software Magazine 19
Planejamento e Gerncia
Nesta seo voc encontra artigos voltados para o planejamento
e gerncia de seus projetos de software.
Use Case Point: Estimativas de Projeto
Parte 3
Da arquitetura civil interao humano-computador
Anderson Pinheiro Balbo
anderson.balbo@gmail.com
Possui graduao em Informtica com nfase
em Gesto de Negcios pela Faculdade de
Tecnologia da Zona Leste, especializao em
Engenharia de Software pelo Instituto de Com-
putao-UNICAMP e especializao em Gesto
de Projetos em TI pela Fundao Carlos Alberto
Vanzolini-USP. Atualmente supervisor de TI na
Caixa Econmica Federal.
Wilson Vendramel
wilson.vendramel@fatec.sp.gov.br
Possui especializao em Engenharia de Software
e mestrado em Cincia da Computao pelo Ins-
tituto de Computao-UNICAMP, e especializao
em Melhoria de Processo de Software pela Uni-
versidade Federal de Lavras. Atuou como Espe-
cialista de Sistemas na IBM Brasil. Atualmente
professor do IFSP de Bragana Paulista e da FATEC
Zona Leste e So Caetano do Sul. Tem interesse
nas reas de Engenharia de Software, Banco de
Dados, Gesto de Projetos e BPM.
Maria Beatriz Felgar de Toledo
beatriz@ic.unicamp.br
Possui graduao e mestrado em Cincia da
Computao pelo Instituto de Computao-
UNICAMP e doutorado em Sistemas Distribu-
dos pela Universidade de Lancaster, Inglaterra.
Atualmente professora associada na Univer-
sidade Estadual de Campinas. Tem interesse
nas reas de gesto de processos de negcio,
servios Web, Web semntica e arquiteturas
orientadas a servios.
20 Engenharia de Software Magazine - Use Case Point: Estimativas de Projeto Parte 3
Fique por dentro:
Realizar estimativas sempre um desafio.
Quando o assunto desenvolvimento de
Este artigo faz software, o assunto fica ainda mais complexo.
So tantas variveis a serem consideradas que
parte de um curso
fica difcil ter uma garantia de que as estima-
tivas refletem de perto o problema que ser
tratado. Neste artigo apresentaremos um caso
prtico do uso de pontos por caso de uso. Vere-
mos como ele pode ser til nesta difcil tarefa
A
s empresas de informtica de- de estimar esforo em projetos de software.
senvolvem seus projetos com
base no prazo estipulado pelo
cliente e no custo necessrio para a pro- Em 1981, em Software Engineering
duo de um determinado software. Economics, Dr. Barry Boehm forneceu
O custo dos produtos fornecidos por parmetros que contribussem para
essas empresas divergiu por muitos determinar o custo de software, apre-
anos, pois at ento no havia uma m- sentando o mtodo COnstructive COst
trica para o clculo do esforo humano MOdel, conhecido como COCOMO.
na criao do software requerido. No Embora eficiente, esse modelo apre-
era levado em considerao o esforo sentou limitaes quanto s abordagens
empenhado para a construo do pro- orientadas a objetos, levando a adoo do
duto, por exemplo, e no havia frmulas modelo de Anlise de Pontos de Funo,
matemticas suficientes gerao das pela IFPUG. O paradigma da contagem
estimativas. de linhas de cdigo para medio deixou
Com isso, o software era vendido por de ser o critrio de contagem principal,
um preo estipulado de forma superfi- e os projetos passaram a contar com as
cial, sem que todos os critrios necess- funcionalidades do sistema como fator
rios fossem considerados. de mensurao.

Em 1993, Karner apresentou o UCP (Use Case Points) como
um novo conceito de medio, permitindo que as estimativas
fossem levantadas desde a anlise dos requisitos. Esse modelo
tende a tornar-se um grande fator competitivo para as organi-
zaes, pois estas podem apresentar as estimativas de custo e
prazo ao cliente com maior preciso antes mesmo do incio do
desenvolvimento. No estudo de caso apresentado neste artigo,
o modelo utilizado para as medies ser o Use Case Point.
A metodologia adotada para este estudo de caso a anlise
dos dados atuais da empresa ABC e a entrevista com o seu res-
ponsvel, de forma a obter as estimativas de custo. A entrevista
uma das mais importantes fontes de informao ao se compor
um estudo de caso, pois apesar do risco de sua ambiguidade,
quando bem elaborada direciona a dados objetivos.
Os resultados obtidos sero comparados com os j existentes,
e sua preciso ser analisada quanto ao cumprimento de prazo,
custo e esforo; por fim, ser verificada a sua viabilidade de
aplicao.
Descrio da empresa do estudo de caso
O estudo de caso deste artigo foi baseado no sistema corpo-
rativo para automao e gesto de laboratrios - ABCLIMS,
desenvolvido pela empresa de engenharia ABC, responsvel
tambm pela manuteno do sistema.
O ABCLIMS hoje utilizado por mais de 500 profissionais
em 40 diferentes laboratrios fsico-qumico, bacteriolgico e
hidrobiolgico. A ABC vem oferecendo desde o ano de 1996
solues em tecnologia para o setor laboratorial, destinadas
s reas de siderurgia, energia eltrica, meio ambiente, txtil,
gs e saneamento bsico, a fim de atender s necessidades de
seus clientes no controle de qualidade de gua e esgoto, alm
da telemetria de processos e sistemas de produo.
O sistema ABCLIMS foi desenvolvido com base em modelos
utilizados em diversos pases onde h o controle de qualidade
da gua. O MPLA (Modelo de Processos de Laboratrio de
Anlise) o modelo que identifica os processos laboratoriais,
conforme a Figura 1.
Figura 1. Modelo de Processos de Laboratrio de Anlise
ABCLIMS
O sistema a ser analisado, para estimativa neste estudo de
caso, um sistema para Automao e Gesto de Laboratrios
Fsico-qumicos e Microbiolgicos de Controle de Qualidade
planejamento
(Laboratory Information and Management System - LIMS),
da ABC, denominado ABCLIMS. Esse sistema viabiliza a
automatizao da programao de coleta das amostras, coleta
automtica dos resultados das anlises e gerenciamento de
todas as atividades de todos os laboratrios. O controle da
amostra feito atravs do uso de cdigo de barras, data e hora,
instrumento, alm da metodologia utilizada e o responsvel
pelas anlises (ver Figura 2).
Figura 2. Elementos do controle de amostra para o ABCLIMS
Outra funo do sistema a viabilizao da anlise de quali-
dade da matria-prima e dos produtos finais, alm de permitir
o rastreamento do processo.
O sistema ABCLIMS possui vrios mdulos, e os principais
so: ABClab e ABCMaster, subsistemas responsveis respectiva-
mente por anlises laboratoriais, e a correta utilizao de meto-
dologias e procedimentos de anlise de qualidade da gua.
ABClab
A funo do ABClab automatizar os processos de anlise
laboratorial, conectando-se aos instrumentos de anlise de
modo que os resultados gerados nestes sejam enviados dire-
tamente para o sistema.
Entre as informaes vinculadas aos resultados, esto os
responsveis pela coleta da amostra, as condies de campo,
recepo da amostra no laboratrio, identificao do instru-
mento e mtodo utilizado, e o responsvel pela anlise.
Tambm so extradas informaes sobre as condies de
aferio dos instrumentos, controle dos limites de deteco
dos instrumentos, validade e identificao dos reagentes
provenientes da anlise, condies de aferio e identifica-
o das vidrarias usadas na anlise, e a conformidade dos
resultados aferidos.
O ABClab possui uma interface simples com o usurio (ver
Figura 3), e um conjunto apropriado de funcionalidades para
a coleta e verificao dos resultados das anlises, atendendo
s exigncias de normas de qualidade como a ISO-17025, que
determina os requisitos exigveis aos laboratrios de ensaio
e calibrao.
Os dados para anlise so recebidos atravs do PocketLab,
que o sistema instalado nos microcomputadores de bolso,
Edio 68 - Engenharia de Software Magazine 21
utilizados pelos analistas para coleta eficaz dos dados, sem
que haja a necessidade de anotao em papel, possibilitando
que tais dados sejam transferidos quando o PocketLab est
conectado com o ABCMaster.
ABCMaster
O mdulo ABCMaster conta com as opes de Cadastro,
Superviso e Relatrios. O Gerador de relatrios permite que
o usurio configure relatrios do gnero qualitativo, quanti-
tativo, alm de laudos, balanos das anlises, resultados, log
de acesso e operaes (ver Figura 4). H diversas opes de
filtragem das opes, possibilitando ao gestor a anlise dos
resultados por diferentes ngulos.
Figura 3. Interface do sistema ABCLIMS - ABClab
Figura 4. Interface do ABCMaster
O Cadastro conta com sessenta telas de cadastro e configu-
rao, e permite definir caractersticas de anlise, frmulas,
algoritmos, instrumentos, vidraria, reagentes, direitos de
acesso aos usurios, grupo de anlises, normas, regulamen-
taes governamentais, reas, equipe de trabalho, clientes e
fornecedores, entre outros (ver Tabela 1).
22 Engenharia de Software Magazine - Use Case Point: Estimativas de Projeto Parte 3
Opo de Cadastro Itens de Cadastro
Anlise, Grupos de Anlise, Frmulas e Algoritmos de Clculo.
Instrumentos, Mtodos Analticos.
Interfaces com os Instrumentos, Bancada e Laboratrios.
EPIs e Carta Controle (CEP).
Observaes e Grupos de Observaes.
Amostragem: Embalagens, Frascos e Preservaes.
Cadastro Geral
Produtos Qumicos, Reagentes, Vidrarias e Grupos de Vidrarias.
Clientes, Fornecedores e Ramos de Atividades.
Usurios, Cargos, Funes, Atribuies e Direitos de Acesso por
Menu.
Organograma empresarial com nveis hierrquicos.
Produtos (matria-prima e acabados) e Pontos de Coleta.
rea de recepo e amostragem de matrias-primas.
Almoxarifados e depsitos especficos.
Pontos de Coleta Pontos de processo produtivo.
rea, Reator, Embaladora, etc.
Mensagens e Alarmes de desvios e anomalias.
rgos de Regulamentao e Normalizao (oficiais e internos).
Regulamentaes e Normas (USEPA, AOAC, GLP, ISO, USP, ABNT,
Normas, Regulamentaes e
ASTM, etc.).
Necessidades do Cliente
Usurios e Grupos de Usurios com diferentes Direitos de Acesso,
por item de Menu.
Cargos e Atribuies.
Administrativo Programa de Treinamento.
Organograma da Empresa.
Tabela 1. Funcionalidades do Cadastro do sistema ABCLIMS
A Superviso oferece recursos para a gesto da capacidade
dos laboratrios e a emisso dos relatrios gerenciais com
opes de filtros avanados, assim como suporta a verificao
dos resultados das anlises e a solicitao de novas anlises,
se for o caso. Tambm trata da distribuio das informaes
ao longo da empresa, controlando e restringindo o acesso dos
usurios de acordo com as suas responsabilidades. Quando
integrado ao ABClab, o ABCMaster oferece as vantagens exi-
bidas na Tabela 2.
Relatrio de entrevista inicial
Alm do estudo do sistema ABCLIMS e dos seus mdulos,
para a elaborao do estudo de caso tambm foi realizada en-
trevista com o responsvel pela empresa ABC. Com base nas
respostas fornecidas pelo representante da ABC, foi possvel
esclarecer algumas informaes que contribuem para o dire-
cionamento e entendimento do negcio. Portanto, essa entre-
vista tem a finalidade de auxiliar nos estudos da empresa.
Em primeiro lugar, a ABC conta com uma metodologia
prpria de desenvolvimento. Essa afirmao pde ser cons-
tatada ao analisar o processo atual, reforando a necessidade
de adaptaes nesse processo por parte do seu representante,

que atendam s necessidades das estimativas, e que o torne
aderente aos processos de melhoria de software, como o MPS
.BR, por exemplo.
Contudo, a empresa conta com a atividade de levantamento
de requisitos, o que constitui parcialmente uma disciplina do
RUP, atravs de entrevistas nos locais onde esto os clientes, e
da elaborao da Especificao de Requisitos Funcionais.
Entre as respostas fornecidas pelo gestor, aquela que melhor
se adapta realidade deste estudo de caso refere-se ao fator
de produtividade. Uma vez afirmado que no h o clculo
para esse fator, pode-se considerar que a empresa tem como
base a sua experincia na mensurao da produtividade para
a realizao de projetos.
N Vantagens da integrao do ABCMaster com o ABClab
1 Acelera todo o processo de coleta dos resultados das anlises.
2 Os resultados das anlises so gravados diretamente no Servidor de Arquivos.
3 As tarefas so agendadas, com as amostras a serem analisadas.
Possibilidade de escolha da amostra em uma lista na tela, que possui somente as amostras
4
permitidas.
5 Aumento da confiabilidade e agilidade do processo
6 Possibilidade de utilizao de microcomputadores.
7 Utilizao da mesma interface (Windows) por parte de todos os funcionrios da empresa.
8 Distribuio das tarefas no laboratrio.
9 Organizao e sistematizao na realizao das anlises.
10 Reduo da quantidade de relatrios impressos.
11 Agilizao dos processos de consulta.
Tabela 2. Vantagens da integrao do ABCMaster com o ABClab
Alm disso, outra afirmao que conduz necessidade de
uso das estimativas refere-se resposta quanto obteno dos
indicadores do projeto. Uma vez que se trata de indicadores ob-
tidos de forma emprica, h um maior risco de distoro quanto
ao prazo estimado para o projeto, o que pode ser reavaliado
atravs de mtodos de medio, como o Use Case Point.
Aps anlise do sistema e o levantamento de informaes
com o gestor, foi possvel determinar a necessidade de aplica-
o de estimativas que se tornassem viveis com a realidade
da empresa, e que possibilitasse ao gestor a mensurao da
produtividade requerida para que posteriormente fosse gerado
o custo e prazo necessrio ao projeto.
Os recursos utilizados foram a extrao das funcionalidades
do sistema na viso do usurio, alm do levantamento de in-
formaes complementares para a gerao dos componentes
das estimativas.
Estimativa de Custo atravs do Use Case Point
Para o clculo do custo estimado no desenvolvimento do
sistema ABCLIMS para o cliente, foi utilizado o mtodo de me-
dio Use Case Point, por possibilitar o levantamento de dados
para estimativas a partir do levantamento de requisitos.
As medies do Use Case Point levam em considerao os
fatores citados a seguir:
planejamento
Atores: dada a sua interao com as funcionalidades do
sistema, so essenciais para a determinao da complexidade
do mesmo;
Casos de uso: constituem o sistema em questo, pois so as
aes geradas por outro caso de uso ou ator que permitem o
funcionamento do sistema;
Fatores de complexidade tcnica: so os requisitos funcionais
do aplicativo, obtidos a partir do levantamento de requisitos,
e que direta ou indiretamente influenciam no funcionamento
do sistema;
Fatores ambientais: caracterizam os requisitos no-funcio-
nais, integrando o processo de desenvolvimento, pois tratam
de fatores como a dificuldade de entendimento do sistema, o
que tambm interfere no seu funcionamento e influencia no
seu nvel de complexidade.
Para os casos de uso considera-se a contagem das transaes
dos cenrios que compem cada caso de uso. A necessidade de
se avaliar a complexidade dos casos de uso atravs dos seus
cenrios foi um importante fator que levou elaborao destes,
auxiliando no entendimento do sistema, medida que as suas
funcionalidades eram rastreadas e os passos que compem
esses cenrios eram descritos.
Uma recomendao necessria para o sucesso das estimativas
do projeto com a tcnica UCP est na correta interpretao
dos cenrios por parte do analista ou de outro profissional
responsvel pela elaborao desses artefatos, pois de outro
modo o esforo para a obteno dessas estimativas pode ser
prejudicado.
Inicialmente foi estudado o sistema ABCLIMS pela viso
top-down, atravs de uma avaliao inicial contextual do sis-
tema, que permitisse o levantamento seus mdulos internos,
gerando com isso uma viso mais detalhada do sistema com
o levantamento dos casos de uso para cada mdulo.
A avaliao dos casos de uso em mdulos separados, em um
segundo instante, facilita na descrio posterior dos cenrios,
pois os diagramas de caso de uso possibilitam a anlise da
interao dos atores com o sistema. Ao fim dessa anlise, ser
obtida a estimativa para o sistema ABCLIMS, levando em conta
os atores (papis relevantes ao estudo de caso desse projeto),
casos de uso (os seus respectivos cenrios), e os fatores de
ajuste para essa estimativa.
O sistema ABCLIMS teve as suas funcionalidades reconhe-
cidas, e os casos de uso fundamentais, assim como os atores,
foram extrados dos requisitos a fim de obter as complexidades
associadas.
Na Figura 5 nota-se a presena de quatro atores interagindo
com o sistema principal. So eles o Supervisor, os Analistas B
e Q (respectivamente Bilogo e Qumico, generalizados pelo
papel de Analista), e o Equipamento (mdulo ABClab). O ator
Usurio na refere-se aos atores Supervisor e Analistas.
O Analista trata-se de um ser humano com limitaes para
acesso ao sistema (no possui as mesmas permisses de acesso
que o Supervisor ou outro ator do diagrama). Entretanto, no
cabe ao UCP investigar as limitaes e prioridades de acesso
Edio 68 - Engenharia de Software Magazine 23
ao sistema, mas sim a forma como os atores interagem com
ele, e quem so esses atores.
Dessa forma, o ator Analista interage com o sistema ABCLI-
MS atravs de uma interface grfica, e por se tratar de um
humano, o classificamos como complexo (classificao que
se estende aos Analistas B e Q); quanto aos atores Usurio e
Supervisor, estes se enquadram nas mesmas caractersticas,
recebendo a mesma classificao.
Na Figura 7 constata-se que o menu Gerador de Relatrios
contm ao todo dezesseis opes diferentes para impresso
de relatrios.
Na Figura 8 percebe-se que o Supervisor e os Analistas B e
Q so encarregados de cadastrar a programao das amostras.
Dada a importncia dessa atividade para o prosseguimento
das demais, fundamental restringir o acesso apenas a esse
grupo, pois estes possuem o conhecimento adequado.

Figura 7. Menu Gerador de Relatrios do mdulo ABCMaster - ABCLIMS

Figura 5. Diagrama de Casos de Uso do sistema ABCLIMS

O ator Equipamento que acessa o mdulo ABClab um sistema

externo, e este repassa dados como os resultados das anlises
das amostras para o ABCLIMS atravs de protocolos de comu-
nicao. Portanto, trata-se de um ator de complexidade mdia.
Na Figura 6 nota-se que o ator Supervisor utiliza o menu
de Superviso com permisso para gerenciar as amostras
(validar resultados), configurar a carta de controle e emitir o
laudo da amostra.

Figura 6. Menu Superviso do mdulo ABCMaster - ABCLIMS Figura 8. Mdulo Cadastros do sistema ABCMaster - ABCLIMS

24 Engenharia de Software Magazine - Use Case Point: Estimativas de Projeto Parte 3

 planejamento

O ABClab, ao fazer a leitura dos dados enviados pelos

instrumentos, verifica se este instrumento est cadastrado
no sistema, para em seguida aceit-los. O Analista tambm
pode utilizar diretamente o ABClab para inserir os dados da
anlise, desde que seja credenciado para tal, e que a anlise
seja realizada em um equipamento habilitado (calibrado) (ver
Figura 9).

Figura 10. Mdulo Cadastrar Filtro - ABCLIMS

Ator Complexidade Peso

Analista Bilogo Complexo 3
Figura 9. Mdulo ABClab - ABCLIMS Analista Qumico Complexo 3
Supervisor Complexo 3
Em seguida, so geradas as informaes que daro suporte Equipamento Mdio 2
deciso. Essas informaes so obtidas pela filtragem dos
Tabela 3. Atores que interagem com o sistema ABCLIMS
dados analisados.
possvel, por exemplo, verificar quais so os pontos de Para a contagem dos pesos dos casos de uso no ajustados
saneamento com maior ou menor ndice de micro-organismos sero consideradas as transaes efetuadas pelos cenrios
prejudiciais sade (viso geogrfica). As vises administra- correspondentes aos CSU (Caso de Uso). A seguir sero apre-
tiva e operacional se encarregam respectivamente de coorde- sentados os cenrios dos casos de uso considerados para a
nar as aes necessrias garantia da qualidade da gua e contagem do UUCW.
execuo dessa atividade.
Embora haja um sistema pr-existente, o diagrama de casos Caso de Uso Acessar
de uso para a filtragem das informaes poderia ser obtido Sumrio: O objetivo deste caso de uso demonstrar a fun-
com o adequado levantamento dos requisitos que compem cionalidade acessar do mdulo ABCMaster dentre os vrios
esse mdulo. A Figura 10 representa as aes executveis pelo mdulos do sistema ABCLIMS.
gerenciamento e superviso de amostras quanto s possibili- Atores: Usurio (Supervisor ou Analistas).
dades de filtragem. Precondies: O Usurio dever se autenticar no sistema cor-
Com base nos mdulos vistos anteriormente e no sistema porativo e ter direito de acesso ao mdulo ABClab e subitens,
ABCLIMS, foi feito o levantamento dos elementos relevantes conforme permisso de acesso.
para os Pontos por Caso de Uso. As estimativas sero inicia-
das pela contagem dos pesos dos atores, cujas complexidades Fluxo Principal
j foram esclarecidas. Os clculos dos pesos dos atores no 1. O Usurio acessa o mdulo ABCMaster;
ajustados so descritos na Tabela 3. 2. O Usurio fornece a sua identificao e a senha;
Dessa forma, tem-se que: 3. O Sistema verifica permisso de acesso e disponibiliza
as funcionalidades de acordo com os direitos de acesso do
UAW = 1 x quantidade (ator simples) + 2 x quantidade Usurio;
(ator mdio) + 3 x quantidade (ator complexo) 4. O Sistema gera log de acesso inicial e passa a registrar todas
UAW = 0 x 1 + 1 x 2 + 31x 3 = 0 + 2 + 9 = 1 as operaes executadas pelo Usurio.

Edio 68 - Engenharia de Software Magazine 25

Fluxos Alternativos
a) Passo 3 (nome do usurio ou senha invlidos): o Sistema
informa o erro ao Usurio e solicita a este que entre com seus
dados de novo retornando assim ao passo 2.
Pontos de Incluso
a) Este caso de uso utiliza outros pontos de incluso que esto
descritos no fluxo de eventos, so eles:
- Verificar Permisso;
- Gerar Log de Acesso Inicial.
Caso de Uso Aplicar Filtros
Sumrio: O objetivo deste caso de uso aplicar filtros que
sero usados como parmetros para gerar relatrios que se-
ro disponibilizados pelo sistema ABCLIMS. As taxonomias
disponveis neste mdulo so: Viso Administrativa, Viso
Geogrfica e Viso Operacional.
Atores: Supervisor ou Analistas (Analista B e Analista Q).
Precondies: O Supervisor ou Analistas devero se auten-
ticar no sistema corporativo e ter direitos de acesso funcio-
nalidade de Aplicar Filtros e a demais subitens, conforme
permisso de acesso.
Fluxo Principal
1. O Supervisor ou Analistas selecionam o item aplicar filtros
dentre as opes fornecidas pelo sistema ABCLIMS;
2. O Sistema fornece a opo de aplicar um novo filtro ou um
filtro existente;
3. O Sistema apresentar uma lista com as opes de filtros que
podem ser aplicados conforme opo escolhida e permisso
de acesso destinada ao usurio;
4. O Supervisor ou Analistas escolhem uma das vises
disponveis:
- Viso administrativa;
- Viso geogrfica;
- Viso operacional.
5. O Supervisor ou Analistas escolhem a opo desejada;
6. O Supervisor ou Analistas fornecem os parmetros
requeridos;
7. O Sistema registra os parmetros inseridos;
8. O Sistema apresenta o resultado da pesquisa com base na
opo e parmetros escolhidos;
9. O Sistema fornece a opo de salvar o modelo usado na
busca;
10. O Supervisor ou Analistas saem da opo de aplicar
filtro.
Fluxos Alternativos
a) Passo 2 (aplicar filtro existente):
- O Sistema exibe uma lista com os filtros salvos anterior-
mente que podem ser disponibilizados e o caso de uso
segue ao passo 3;
- Caso no existam filtros salvos anteriormente, o Sistema
informa a ausncia de filtros salvos e o caso de uso retorna
ao passo 3.
26 Engenharia de Software Magazine - Use Case Point: Estimativas de Projeto Parte 3
a) Passo 9 (salvar filtro):
- O Sistema disponibiliza campos para o detalhamento
do filtro, e grava o filtro usado. O caso de uso retorna ao
passo 10;
- Caso o filtro a ser salvo possua o mesmo nome de um
salvo anteriormente, o sistema gera um alerta e o caso de
uso retorna ao passo anterior do Fluxo Alternativo salvar
filtro.
Caso de Uso Aplicar Filtros de Viso Administrativa
Sumrio: O objetivo deste caso de uso aplicar filtros que
sero usados como parmetros para gerao de relatrios,
consultas e programao de coletas que sero disponibilizados
pelo sistema ABCLIMS.
Atores: Supervisor ou Analistas (Analista B e Analista Q).
Precondies: O Supervisor ou Analistas devero se autenti-
car no sistema corporativo e ter direitos de acesso aos mdulos
ABCMaster e ABClab dos vrios mdulos do sistema ABCLIMS
e a demais subitens, conforme permisso de acesso.
Fluxo Principal
1. O Supervisor ou Analistas selecionam a opo Viso Ad-
ministrativa, dentro do item Aplicar Filtros fornecido pelo
sistema ABCLIMS.
2. O Supervisor ou Analistas fornecem um ou mais parmetros
para a criao do filtro:
- Presidncia;
- Assessoria;
- Diretoria;
- Superintendncia;
- Departamento;
- Diviso;
- Encarregados e Gestores.
3. O Sistema registra os parmetros inseridos;
4. O Sistema apresenta o resultado da pesquisa com base na
opo e parmetros escolhidos;
5. O Sistema fornece a opo de salvar o modelo usado na
busca;
6. O Supervisor ou Analistas saem da opo de aplicar filtro.
Fluxos Alternativos:
a) Passo 5 (salvar filtro):
- O Sistema disponibiliza campos para o detalhamento
do filtro, e grava o filtro usado. O caso de uso retorna ao
passo 6;
- Caso o filtro a ser salvo possua o mesmo nome de um
salvo anteriormente, o Sistema gera um alerta e o caso de
uso retorna ao passo anterior do Fluxo Alternativo salvar
filtro.
Caso de Uso Aplicar Filtros de Viso Geogrfica
Sumrio: O objetivo deste caso de uso aplicar filtros que
sero usados como parmetros para gerao de relatrios,
consultas e programao de coletas que sero disponibilizados
pelo sistema ABCLIMS.

Atores: Supervisor ou Analistas (Analista B e Analista Q).
Precondies: O Supervisor ou Analistas devero se autenti-
car no sistema corporativo e ter direito de acesso aos mdulos
ABCMaster e ABCLab dos vrios mdulos do sistema ABCLI-
MS e a demais subitens, conforme permisso de acesso.
Fluxo Principal
1. O Supervisor ou Analistas selecionam a opo Viso Geo-
grfica, dentro do item Aplicar Filtros fornecido pelo sistema
ABCLIMS;
2. O Supervisor ou Analistas fornecem um ou mais parmetros
para a criao do filtro:
- Cidade;
- rea;
- Bairro;
- Logradouro (ttulo do logradouro, preposio e tipo de
logradouro);
- Endereo.
3. O Sistema registra os parmetros inseridos;
4. O Sistema apresenta o resultado da pesquisa com base na
opo e parmetros escolhidos;
5. O Sistema fornece a opo de salvar o modelo usado na
busca;
6. O Supervisor ou Analistas saem da opo de aplicar filtro.
Fluxos Alternativos:
a) Passo 5 (salvar filtro):
- O Sistema disponibiliza campos para o detalhamento
do filtro, e grava o filtro usado. O caso de uso retorna ao
passo 6;
- Caso o filtro a ser salvo possua o mesmo nome de um
salvo anteriormente, o Sistema gera um alerta e o caso de
uso retorna ao passo anterior do Fluxo Alternativo salvar
filtro.
Caso de Uso Aplicar Filtros de Viso Operacional
Sumrio: O objetivo deste caso de uso aplicar filtros que
sero usados como parmetros para gerao de relatrios,
consultas e programao de coletas que sero disponibilizados
pelo sistema ABCLIMS.
Atores: Supervisor ou Analistas (Analista B e Analista Q).
Precondies: O Supervisor dever se autenticar no sistema
corporativo e ter direito de acesso aos mdulos ABCMaster e
ABCLab dos vrios mdulos do sistema ABCLIMS e a demais
subitens, conforme permisso de acesso.
Fluxo Principal
1. O Supervisor ou Analistas selecionam a opo Viso Opera-
cional, dentro do item Aplicar Filtros fornecido pelo sistema
ABCLIMS;
2. O Supervisor ou Analistas fornecem um ou mais parmetros
para a criao do filtro:
- Componente (identificao);
- Elemento;
- Sistema.
planejamento
3. O Sistema registra os parmetros inseridos;
4. O Sistema apresenta o resultado da pesquisa com base na
opo e parmetros escolhidos;
5. O Sistema fornece a opo de salvar o modelo usado na busca;
6. O Supervisor ou Analistas saem da opo de aplicar filtro.
Fluxos Alternativos:
a) Passo 5 (salvar filtro):
- O Sistema disponibiliza campos para o detalhamento
do filtro, e grava o filtro usado. O caso de uso segue ao
passo 6;
- Caso o filtro a ser salvo possua o mesmo nome de um salvo
anteriormente, o Sistema gera um alerta e o caso de uso re-
torna ao passo anterior do fluxo alternativo Salvar filtro.
Caso de Uso Superviso
Sumrio: O objetivo deste caso de uso a utilizao da fun-
cionalidade Superviso conforme as taxonomias propostas para
gerenciar amostra, configurar carta controle e emitir laudo.
Atores: Supervisor.
Precondies: O Supervisor dever se autenticar no sistema
corporativo e ter direito de acesso a funcionalidade de Super-
viso e em subitens, conforme permisso de acesso.
Fluxo Principal
1. O Supervisor seleciona a opo Superviso dentre as
opes fornecidas pelo sistema ABCLIMS;
2. O Sistema apresentar uma lista com as taxonomias propos-
tas para superviso conforme permisso de acesso destinada
ao usurio;
3. O Supervisor fornece um ou mais parmetros para a criao
do filtro:
- Gerenciar Amostras;
- Configurar Carta Controle;
- Emitir Laudo.
4. O Supervisor escolhe a opo desejada;
5. O Sistema mostra tipificaes para opo escolhida;
6. O Supervisor escolhe a tipificao desejada;
7. O Sistema executa comando solicitado;
8. O Supervisor utiliza a opo Aplicar Filtro;
9. O Supervisor fornece os parmetros requeridos;
10. O Sistema executa comando solicitado.
Fluxos Alternativos:
a) Passo 9: Caso o Supervisor fornea parmetros incorretos
ou inexistentes, o Sistema retorna a informao do ocorrido
ao Supervisor e retorna ao passo 8.
Pontos de Incluso
a) Passo 8: Aplicar Filtro.
Pontos de Extenso
b) Passo 3: Emitir Laudo (este ponto de extenso s execu-
tado caso o Supervisor opte por Emitir o Laudo a partir da
opo Gerenciar Amostras).
Edio 68 - Engenharia de Software Magazine 27
Caso de Uso Gerenciar Amostra
Sumrio: O objetivo deste caso de uso a utilizao da
funcionalidade Gerenciar Amostra do menu Superviso, que
permite o gerenciamento das anlises efetuadas, como um
visto eletrnico, permitindo assim a liberao das anlises uma
a uma ou em grupo, e onde tambm possvel nesse mdulo
do sistema emitir laudos das anlises.
Atores: Supervisor.
Precondies: O Supervisor dever se autenticar no sis-
tema corporativo e ter direito de acesso funcionalidade
de Superviso e a demais subitens, conforme permisso
de acesso.
Fluxo Principal
1. O Supervisor seleciona a opo Gerenciar Amostra do
menu Superviso dentre as opes fornecidas pelo sistema
ABCLIMS;
2. O Sistema apresentar as TAGs disponveis para a opo
Gerenciar Amostra, como:
- Amostras Localizadas;
- Anlises Pendentes;
- Anlises Realizadas/Liberadas.
3. Atravs da opo Aplicar Filtro, o Supervisor define campos
Origem, Situao e Amostra, ou quais Amostras deseja-se
encontrar para serem trabalhadas;
4. O Sistema retorna as amostras solicitadas que atendam ao
filtro definido pelo Supervisor e os seus respectivos status;
5. O Supervisor seleciona a Amostra que deseja trabalhar e
define o Laboratrio e o rgo Regulamentador para a amostra
selecionada;
6. O Sistema apresentar nas tabelas Pendentes, Realizadas e
Liberadas a relao de anlises nestas situaes para a amostra
selecionada;
7. O Supervisor seleciona as anlises nas janelas e as torna
liberadas, realizadas ou pendentes atravs de botes de
navegao;
8. O Supervisor, ao clicar com o boto direito do mouse sobre
alguma amostra localizada, poder ajustar algumas configu-
raes para estas, como:
- Ajustar Datas e Horas da chegada da planilha e da coleta
da amostra;
- Modificar Procedncia ;
- Inserir Anlises ;
- Modificar Padres.
9. O Sistema apresenta tambm uma lista de botes que podem
ser utilizados pelo usurio, como:
- Laudo - Emite o Laudo da Anlise selecionada;
- Liberar - Libera todas as Anlises de todas as Amostras
Localizadas. Este boto s habilita quando est selecionado
um Laboratrio que no seja (Todos);
- Parar - Para o processo de Liberao das Anlises;
Observao - Insere uma Observao para a Anlise.
10. O Supervisor tem a opo de clicar no boto Encerrar para
finalizar o processo.
28 Engenharia de Software Magazine - Use Case Point: Estimativas de Projeto Parte 3
Fluxos Alternativos:
a) Passo 3: Caso as opo escolhidas no constem no cadastro,
o Sistema traz a informao ao Supervisor para que este se
certifique que as suas escolhas foram as corretas e retorna
ao passo 3;
b) Passo 5: Caso as opo escolhidas no constem no cadastro,
o Sistema traz a informao ao Supervisor para que este se
certifique que as suas escolhas foram as corretas e retorna
ao passo 5;
Pontos de Incluso
a) Passo 3: Aplicar Filtro.
Pontos de Extenso
Passo 12: Emitir Laudo (este ponto de extenso s executado
caso o Supervisor opte por Emitir o Laudo a partir da opo
Gerenciar Amostra).
Caso de Uso Configurar Carta Controle
Sumrio: O objetivo deste caso de uso a utilizao da fun-
cionalidade Configurar Carta Controle do menu Superviso.
A Carta Controle visa no somente determinar estimativas
de preciso e exatido dos resultados analticos, mas tambm
verificar se os resultados se enquadram dentro das metas pre-
estabelecidas. A carta controle destina-se, principalmente,
determinao da tendncia de impreciso do mtodo, quando
os resultados estiverem fora dos limites e indicar anomalias.
Atores: Supervisor.
Precondies: O Supervisor dever se autenticar no sistema
corporativo e ter direito de acesso a funcionalidade de Super-
viso e em subitens, conforme permisso de acesso.
Fluxo Principal
1. O Supervisor seleciona a opo Carta Controle do menu
Superviso dentre as opes fornecidas pelo Sistema
ABCLIMS;
2. O Sistema apresentar uma tabela Resultados Padro por
Anlise, onde constaro as amostras e seus status como
segue:
- Excludo - A amostra no est na Carta Controle;
- Carta - A amostra est na Carta Controle, porm no est
sendo utilizada para o clculo dos limites;
- Clculo - A amostra est Carta Controle e est sendo uti-
lizada para o clculo dos limites.
3. Para definir os status da amostra, o Supervisor clica com o
boto direito sobre a mesma e altera o status de acordo com
as opes citadas no passo anterior;
4. O Sistema altera o status da amostra.
Fluxos Alternativos:
Passo 3: Caso o Supervisor altere para um status j con-
figurado, o Sistema informar que no possvel executar a
ao solicitada, pois o mesmo tipo de status j fora definido
anteriormente. O Sistema retorna ao passo 2.
 planejamento

Caso de Uso Emitir Laudo propostas para: pontos de coleta, produtos/solues, anlises,
Sumrio: O objetivo deste caso de uso a utilizao da fun- usurio, regulamentaes governamentais, programao de
cionalidade Emitir Laudo do menu Superviso. coleta, entre outros.
Atores: Supervisor. Ator Primrio: Supervisor.
Precondies: O Supervisor dever se autenticar no sistema Atores Secundrios: Analistas (Analista B e Analista Q).
corporativo e ter direito de acesso a funcionalidade de Super- Precondies: O Supervisor dever se autenticar no Sistema
viso e a demais subitens, conforme permisso de acesso. corporativo e ter direito de acesso a funcionalidade de Ca-
dastro e subitens, conforme permisso de acesso.
Fluxo Principal
1. O Supervisor seleciona o item Emitir Documentos dentre Fluxo Principal
as opes fornecidas pelo Sistema ABCLIMS para o menu 1. O Supervisor seleciona o item Cadastro dentre as opes
Superviso; fornecidas pelo sistema ABCLIMS;
2. O Sistema apresentar uma lista com as taxonomias propos- 2. O Sistema apresentar uma lista com as taxonomias propos-
tas para emitir laudo conforme permisso de acesso destinada tas para cadastros conforme permisso de acesso destinada
ao Supervisor; ao Supervisor;
3. O Supervisor clica no menu Superviso para emitir laudo; 3. O Supervisor pode escolher a opo desejada para as tipi-
4. O Sistema apresentar uma tabela Resultados Padro por An- ficaes existentes:
lise, onde constaro as amostras e seus status como segue: - Pontos de Coleta;
- Anlise de Metais Pesados; - Produtos e Solues;
- Bacteriolgico de gua; - Anlise;
- Biolgico de Esgoto; - Programao;
- Boletim Hidrobiolgico; - Administrativo.
- Fsico Qumico de gua; 4. O Supervisor escolhe a ao que deseja realizar (Incluir,
- Fsico Qumico de Esgoto; Alterar, Remover e Consultar);
- Hidrobiolgico; 5. O Supervisor fornece os parmetros requeridos;
- Hidrobiolgico Qualitativo de gua; 6. O Sistema mostra tipificaes para opo escolhida;
- Hidrobiolgico Qualitativo de Esgoto; 7. O Supervisor escolhe a tipificao desejada;
- Hidrobiolgico Quantitativo de gua; 8. O Sistema executa o comando solicitado.
Isolamento de Vibrio Cholerae;
- Produto Qumico. Fluxos Alternativos:
5. O Supervisor informa o nmero da amostra e as opes de a) Passo 5 (Incluir): Caso o Supervisor fornea algum parmetro
impresso como segue: incorreto ou caso os dados a serem cadastrados j existam, o
- Responsvel; Sistema informa a condio existente e retorna ao passo 5 para
- Gerente; que o Supervisor reveja a sua ao;
- Alinhado abaixo; b) Passo 5 (Alterar): Caso o Supervisor fornea algum parmetro
- Incerteza de Medio; incorreto o Sistema informa a condio existente e retorna ao
- Total como Rodap; passo 5 para que o Supervisor reveja a sua ao;
- Retrato; c) Passo 5 (Remover) Caso o Supervisor fornea algum parme-
- Agrupar Laudos. tro incorreto ou caso os dados a serem excludos no existam,
6. O Sistema aplica filtro de acordo com a escolha do bem como haja uma condio especial que impea a excluso
Supervisor; dos dados, o Sistema informa a condio existente e retorna ao
7. O Sistema disponibiliza documento para impresso. passo 5 para que o Supervisor reveja a sua ao;
d) Passo 5 (Consultar): Caso o Supervisor fornea algum pa-
Fluxos Alternativos: rmetro incorreto ou caso os dados a serem consultados no
a) Passo 6: Caso o nmero da amostra no conste no cadastro, existam, o Sistema informa a condio existente e retorna ao
o Sistema traz a informao ao Supervisor para que este se passo 5 para que o Supervisor reveja a sua ao.
certifique que as suas escolhas foram as corretas, e retorna
ao passo 5. Pontos de Incluso
Passo 5: Aplicar Filtro.
Pontos de Incluso
Passo 6: Aplicar Filtro. Caso de Uso Cadastrar Filtros
Sumrio: O objetivo deste caso de uso o cadastro de filtros
Caso de Uso Cadastrar (Inserir, Alterar, Remover e Consultar) conforme as taxonomias
Sumrio: O objetivo deste caso de uso o cadastro (Inse- propostas pelo Modelo de Viso Corporativa: viso adminis-
rir, Alterar, Remover e Consultar) conforme as taxonomias trativa, viso geogrfica e operacional.

Edio 68 - Engenharia de Software Magazine 29

 Ator Primrio: Supervisor.
Atores Secundrios: Analistas (Analista B e Analista Q).
Precondies: O Supervisor dever se autenticar no siste-
ma corporativo e ter direito de acesso a funcionalidade de
Cadastrar Filtro e a demais subitens, conforme permisso
de acesso.
Fluxo Principal
1. O Supervisor seleciona o item Cadastrar Filtro dentre as
opes fornecidas pelo sistema ABCLIMS;
2. O Sistema apresentar uma lista com as taxonomias pro-
postas para cadastros de filtros conforme permisso de acesso
destinada ao Administrador;
3. O Supervisor pode escolher a opo desejada para as tipi-
ficaes existentes:
- Viso Administrativa;
- Viso Geogrfica;
- Viso Operacional.
4. O Supervisor escolhe a ao que deseja realizar (Incluir,
Alterar, Remover e Consultar);
5. O Supervisor fornece os parmetros requeridos;
6. O Sistema mostra tipificaes para opo escolhida;
7. O Supervisor escolhe a tipificao desejada;
8. O Sistema executa o comando solicitado.
Fluxos Alternativos:
a) Passo 5 (Incluir): Caso o Supervisor fornea algum pa-
rmetro incorreto ou caso os dados a serem cadastrados j
existam, o Sistema informa a condio existente e retorna
ao passo 5 para que o Supervisor reveja a sua ao;
b) Passo 5 (Alterar): Caso o Supervisor fornea algum par-
metro incorreto o Sistema informa a condio existente e re-
torna ao passo 5 para que o Supervisor reveja a sua ao;
c) Passo 5 (Remover) Caso o Supervisor fornea algum
parmetro incorreto ou caso os dados a serem excludos
no existam, bem como haja uma condio especial que
impea a excluso dos dados, o Sistema informa a condio
existente e retorna ao passo 5 para que o Supervisor reveja
a sua ao;
d) Passo 5 (Consultar): Caso o Supervisor fornea algum pa-
rmetro incorreto ou caso os dados a serem consultados no
existam, o Sistema informa a condio existente e retorna ao
passo 5 para que o Supervisor reveja a sua ao.
Caso de Uso Cadastrar Filtros de Viso Administrativa
Sumrio: O objetivo deste caso de uso o cadastro de filtros
(Inserir, Alterar, Remover e Consultar) conforme proposto pelo
Modelo de Viso Corporativa: viso administrativa.
Ator Primrio: Supervisor.
Atores Secundrios: Analistas (Analista B e Analista Q).
Precondies: O Supervisor dever se autenticar no siste-
ma corporativo e ter direito de acesso a funcionalidade de
Cadastrar Filtro e a demais subitens, conforme permisso
de acesso.
30 Engenharia de Software Magazine - Use Case Point: Estimativas de Projeto Parte 3
Fluxo Principal
1. O Supervisor seleciona o item Cadastrar Filtro - Viso Admi-
nistrativa dentre as opes fornecidas pelo sistema ABCLIMS;
2. O Sistema apresentar uma lista com as taxonomias pro-
postas para cadastros de filtros conforme permisso de acesso
destinada ao Supervisor;
3. O Supervisor escolhe a operao que deseja realizar (Incluir,
Alterar, Remover e Consultar);
4. O Supervisor fornece os parmetros requeridos:
- Presidncia;
- Assessoria;
- Diretoria;
- Superintendncia;
- Departamento;
- Diviso;
- Encarregados e Gestores.
5. O Sistema mostra tipificaes para opo escolhida;
6. O Supervisor escolhe a tipificao desejada;
7. O Sistema executa comando solicitado.
Fluxos Alternativos:
a) Passo 5 (Incluir): Caso o Supervisor fornea algum parmetro
incorreto ou caso os dados a serem cadastrados j existam, o
Sistema informa a condio existente e retorna ao passo 5 para
que o Supervisor reveja a sua ao;
b) Passo 5 (Alterar): Caso o Supervisor fornea algum parme-
tro incorreto o Sistema informa a condio existente e retorna
ao passo 5 para que o Supervisor reveja a sua ao;
c) Passo 5 (Remover) Caso o Supervisor fornea algum parme-
tro incorreto ou caso os dados a serem excludos no existam,
bem como haja uma condio especial que impea a excluso
dos dados, o Sistema informa a condio existente e retorna
ao passo 5 para que o Supervisor reveja a sua ao;
d) Passo 5 (Consultar): Caso o Supervisor fornea algum pa-
rmetro incorreto ou caso os dados a serem consultados no
existam, o Sistema informa a condio existente e retorna ao
passo 5 para que o Supervisor reveja a sua ao.
Caso de Uso Cadastrar Filtros de Viso Geogrfica
Sumrio: O objetivo deste caso de uso o cadastro de filtros
(Inserir, Alterar, Remover e Consultar) conforme proposto pelo
Modelo de Viso Corporativa: viso geogrfica.
Ator Primrio: Supervisor.
Atores Secundrios: Analistas (Analista B e Analista Q).
Precondies: O Supervisor dever se autenticar no sistema
corporativo e ter direito de acesso a funcionalidade de Cadas-
trar Filtro e subitens conforme permisso de acesso.
Fluxo Principal
1. O Supervisor seleciona o item Cadastrar Filtro - Viso Geo-
grfica dentre as opes fornecidas pelo sistema ABCLIMS;
2. O Sistema apresentar uma lista com as taxonomias pro-
postas para cadastros de filtros conforme permisso de acesso
destinada ao Supervisor;

3. O Supervisor escolhe a operao que deseja realizar (Incluir,
Alterar, Remover e Consultar);
4. O Supervisor fornece os parmetros requeridos:
- Cidade;
- rea;
- Bairro;
- Logradouro (ttulo do logradouro, preposio e tipo de
logradouro);
- Endereo.
5. O Sistema mostra tipificaes para opo escolhida;
6. O Supervisor escolhe a tipificao desejada;
7. O Sistema executa comando solicitado.
Fluxos Alternativos:
a) Passo 5 (Incluir): Caso o Supervisor fornea algum pa-
rmetro incorreto ou caso os dados a serem cadastrados j
existam, o Sistema informa a condio existente e retorna
ao passo 5 para que o Supervisor reveja a sua ao;
b) Passo 5 (Alterar): Caso o Supervisor fornea algum par-
metro incorreto o Sistema informa a condio existente e re-
torna ao passo 5 para que o Supervisor reveja a sua ao;
c) Passo 5 (Remover) Caso o Supervisor fornea algum
parmetro incorreto ou caso os dados a serem excludos
no existam, bem como haja uma condio especial que
impea a excluso dos dados, o Sistema informa a condio
existente e retorna ao passo 5 para que o Supervisor reveja
a sua ao;
d) Passo 5 (Consultar): Caso o Supervisor fornea algum pa-
rmetro incorreto ou caso os dados a serem consultados no
existam, o Sistema informa a condio existente e retorna ao
passo 5 para que o Supervisor reveja a sua ao.
Caso de Uso Cadastrar Filtros de Viso Operacional
Sumrio: O objetivo deste caso de uso o cadastro de filtros
(Inserir, Alterar, Remover e Consultar) conforme proposto pelo
Modelo de Viso Corporativa: viso operacional.
Ator Primrio: Supervisor.
Atores Secundrios: Analistas (Analista B e Analista Q).
Precondies: O Supervisor dever se autenticar no sistema
corporativo e ter direito de acesso a funcionalidade de Cadas-
trar Filtro e subitens conforme permisso de acesso.
Fluxo Principal
1. O Supervisor seleciona o item Cadastrar Filtro - Viso
Operacional dentre as opes fornecidas pelo sistema
ABCLIMS;
2. O Sistema apresentar uma lista com as taxonomias pro-
postas para cadastros de filtros conforme permisso de acesso
destinada ao Supervisor;
3. O Supervisor escolhe a operao que deseja realizar (Incluir,
Alterar, Remover e Consultar);
4. O Supervisor fornece os parmetros requeridos:
- Componente (identificao);
- Elemento;
- Sistema.
planejamento
5. O Sistema mostra tipificaes para opo escolhida;
6. O Supervisor escolhe a tipificao desejada;
7. O Sistema executa comando solicitado.
Fluxos Alternativos:
a) Passo 5 (Incluir): Caso o Supervisor fornea algum parmetro
incorreto ou caso os dados a serem cadastrados j existam, o
Sistema informa a condio existente e retorna ao passo 5 para
que o Supervisor reveja a sua ao;
b) Passo 5 (Alterar): Caso o Supervisor fornea algum parme-
tro incorreto o Sistema informa a condio existente e retorna
ao passo 5 para que o Supervisor reveja a sua ao;
c) Passo 5 (Remover) Caso o Supervisor fornea algum parme-
tro incorreto ou caso os dados a serem excludos no existam,
bem como haja uma condio especial que impea a excluso
dos dados, o Sistema informa a condio existente e retorna
ao passo 5 para que o Supervisor reveja a sua ao;
d) Passo 5 (Consultar): Caso o Supervisor fornea algum pa-
rmetro incorreto ou caso os dados a serem consultados no
existam, o Sistema informa a condio existente e retorna ao
passo 5 para que o Supervisor reveja a sua ao.
Caso de Uso Realizar Anlises
Sumrio: O objetivo deste caso de uso cadastrar dados de
anlise para levantamento das principais caractersticas da
amostra colhida.
Ator Primrio: Analistas (Analista B e Analista Q).
Atores Secundrios: Equipamento.
Precondies: O Analista dever se autenticar no sistema
corporativo e ter direito de acesso ao mdulo ABCLab e a
demais subitens conforme permisso de acesso.
Fluxo Principal
1. O Analista informa o nome e a senha de Identificao de
Usurio;
2. O Sistema verifica se o usurio tem permisso para acessar
o mdulo ABCLab do sistema ABCLIMS;
3. O Analista verifica se o microcomputador (posto de coleta)
usado para acesso est cadastrado (autorizado) para receber
as informaes do Analista;
4. O Analista seleciona o item Realizar Anlises dentre as op-
es fornecidas pelo mdulo ABCLab do sistema ABCLIMS;
5. O Analista verifica lista de pendncias;
6. O Analista define configuraes (Equipamentos, Mtodos
e Frmulas);
7. O Analista define a frmula da anlise;
8. O Sistema exibe os valores intermedirios da frmula
escolhida;
9. O Analista insere Padro de Controle de Instrumento;
10. O Analista efetua a leitura dos dados provenientes do
equipamento;
11. O Analista insere os dados de anlise da amostra manual-
mente, caso necessrio;
12. O Sistema fornece a opo de calcular os dados;
13. O Analista seleciona a opo de confirmar os dados;
Edio 68 - Engenharia de Software Magazine 31
14. Se o Analista terminou a anlise, ele sai da opo de Re-
alizar Anlises ou ABCLab.
Fluxos Alternativos:
a) Passo 2: O Sistema informa ao Analista que este no possui
permisso para cadastro de anlises. O Sistema solicita ao
Analista que procure pelo Administrador do Sistema, para
obter informaes de acesso;
b) Passo 3: Solicitar Cadastramento do Posto (Esta opo
disparada caso o posto de coleta no esteja cadastrado). O
Sistema solicita ao Analista que procure pelo Administrador
do Sistema, para obter o cadastro do posto de coleta;
c) Passo 8: Caso j exista um Padro de Controle de Instrumento
ou o Analista opte por no gerar um novo padro, o Sistema
da sequncia ao prximo passo do fluxo;
d) Passo 9: Caso o Analista opte por no efetuar a leitura do equi-
pamento, o Sistema d sequncia ao prximo passo do fluxo.
Pontos de Incluso
Os pontos de incluso esto descritos dentro do fluxo bsico
de eventos, porm podemos tipific-los como:
- Verificar Permisso;
- Verificar Posto;
- Gerar Log de Acesso Inicial;
- Verificar Lista de Pendncias;
- Definir Configuraes (Equipamentos, Mtodos e
Frmulas);
- Inserir Padro de Controle do Instrumento;
- Definir Valores Intermedirios.
Pontos de Extenso
Este caso de uso utiliza pontos de extenso que esto descritos
no fluxo bsico de eventos, porm podemos tipific-los como:
- Solicitar Cadastro do Posto;
- Fazer Leitura.
Caso de Uso Fazer Leitura
Sumrio: O objetivo deste caso de uso fazer leitura para
levantamento das principais caractersticas da amostra colhida
atravs da utilizao de equipamento para anlise.
Ator Primrio: Analistas (Analista B e Analista Q).
Atores Secundrios: Equipamento.
Precondies: O Analista dever se autenticar no sistema
corporativo e ter direito de acesso ao mdulo ABCLab e em
subitens conforme permisso de acesso.
Fluxo Principal
1. O Analista clica em Fazer Leitura para que possa efetuar a
leitura dos dados provenientes do equipamento;
2. O Sistema verifica se o equipamento a ser utilizado est
cadastrado;
3. O Sistema informa ao Analista que o equipamento est
disponvel para anlise;
4. O Analista insere Padro de Controle de Instrumento;
5. O Analista define a frmula da anlise;
32 Engenharia de Software Magazine - Use Case Point: Estimativas de Projeto Parte 3
6. O Sistema exibe os valores intermedirios da frmula
escolhida;
7. O Sistema fornece a opo de calcular os dados;
8. O Analista seleciona a opo de confirmar os dados;
9. Se o Analista terminou a anlise, ele repete o procedimento
at que a lista de amostras pendentes fique vazia.
Fluxos Alternativos:
a) Passo 2: Solicitar Cadastramento do Posto (esta opo
disparada caso o posto de coleta no esteja cadastrado).
O Sistema solicita ao Analista que procure pelo Administrador
do Sistema, para obter o cadastro do posto de coleta;
b) Passo 4: Caso j exista um Padro de Controle de Instrumen-
to ou o Analista opte por no gerar um novo padro, o Sistema
d sequncia ao prximo passo do fluxo.
Pontos de Incluso
Os pontos de incluso esto descritos dentro do fluxo bsico
de eventos, porm podemos tipific-los como Verificar Equi-
pamento Cadastrado.
Pontos de Extenso
Este caso de uso utiliza pontos de extenso que esto descritos
no fluxo bsico de eventos, porm podemos tipific-los como
Definir Valores Intermedirios.
Caso de Uso Gerar Relatrios
Sumrio: O objetivo deste caso de uso gerar relatrios que
sero disponibilizados pelo sistema ABCLIMS. As taxonomias
disponveis neste mdulo so: Acumulado de Bacteriologia,
Anomalias, Anlises Pendentes, Balano das Anlises, Coletas,
Inspeo de Recebimento, Controle Quantitativo, Comprovan-
te de Recebimento, Formulrio de Clera, Parmetros de Qua-
lidade, Quantidades por Laboratrio, Rastreamento, Registro
de Amostras, Resultado Dirio, Resumo Geral de Controle
(Grfico), Pontos de Coleta e Preos das Anlises.
Ator Primrio: Supervisor.
Atores Secundrios: Analistas (Analista B e Analista Q).
Precondies: O Supervisor dever se autenticar no sistema
corporativo e ter direito de acesso a funcionalidade de Gerar
Relatrio e em subitens conforme permisso de acesso.
Fluxo Principal
1. O Supervisor seleciona o item Gerar Relatrios dentre as
opes fornecidas pelo sistema ABCLIMS;
2. O Sistema apresentar uma lista com as opes de relatrios
conforme permisso de acesso destinada ao Supervisor;
3. O Supervisor escolhe a opo desejada conforme segue:
- Acumulado de Bacteriologia;
- Balano de Anlises;
- Coletas;
- Inspeo de Recebimento;
- Controle Quantitativo;
- Comprovante de Recebimento;
- Coleta;
 planejamento

- Parmetros de Qualidade; Pontos por Caso de Uso se distanciar de um resultado preciso.

- Quantidades por Laboratrio; A fim de evitar erros conceituais de contagem das transaes
- Anomalias (Anomalias Reincidentes); para os casos de uso, segue outra considerao a ser feita: o
- Rastreamento; que no deve ser considerado uma transao so passos do
- Registro de Anlises; fluxo de eventos que:
- Secretaria; (i) descrevem o incio e o fim do caso de uso;
- Resultado Dirio; (ii) detalham a interao entre o sistema e o ator;
- Resumo Geral de Controle; (iii) solicitem escolhas com valores fixos (sem leitura de dados);
- Cadastrar Pontos de Coleta; (iv) faam leituras auxiliares de dados que j tenham sido feitas
- Preo das Anlises. em outros fluxos do mesmo caso de uso; e
4. O Sistema verifica histrico; (v) usem fluxos alternativos do caso de uso de validaes
5. O Sistema apresenta o relatrio ao Supervisor conforme simples e que contenham mensagens de erro.
opo de comando escolhida: Conforme foi detalhado nos cenrios de casos de uso do sis-
- Salvar Modelo de Filtro; tema ABCLIMS, h sete casos de uso de complexidade mdia
- Visualizar Impresso (Exportar); e 10 de complexidade simples. Para os mdulos que compem
- Exportar para Excel; o ABCLIMS, foram obtidos os seguintes dados:
- Imprimir;
- Excluir; UUCW = 5 x quantidade (caso de uso simples) + 10 x quantidade
- Sair. (caso de uso mdio) + 15 x quantidade (caso de uso complexo)
6. O Supervisor escolhe o comando desejado; UUCW = 11 x 5 + 6 x 10 + 0 x 15 = 115
7. O Sistema executa comando solicitado.
Transaes por Caso de Uso Tipos de Fluxos
Fluxos Alternativos CSU Principal Alternativos Exceo Total
a) Passo 4 (Verificao de Histrico):
Acessar 1 1 0 2
- Caso no exista histrico, o Sistema informa ao Supervisor
Dados Inexistentes e o caso de uso retorna ao passo 3; Aplicar Filtros 1 2 0 3
- Caso os parmetros estejam incorretos, o Sistema infor- Aplicar Filtros de Viso Administrativa 1 1 0 2
ma ao Supervisor Parmetros Incorretos e o caso de uso Aplicar Filtros de Viso Geogrfica 1 1 0 2
retorna ao passo 3. Aplicar Filtros de Viso Operacional 1 1 0 2
b) Passo 7 (Salvar Modelo de Filtro): Caso o modelo a ser salvo Superviso 1 1 0 2
j exista com o mesmo nome, o Sistema fornece uma lista de
Gerenciar Amostra 1 2 0 3
opes a serem executadas: sobrescrever modelo existente,
Configurar Carta Controle 1 1 0 2
salvar com nome diferente e cancelar a operao. O caso de
uso retorna ao passo 5. Emitir Laudo 1 1 0 2
Cadastrar 1 4 0 5
Pontos de Incluso: Cadastrar Filtros 1 4 0 5
Passo 4: Aplicar Filtro. Cadastrar Filtros de Viso Administrativa 1 4 0 5
Cadastrar Filtros de Viso Geogrfica 1 4 0 5
Uma vez conhecidos os fluxos de eventos, pode-se fazer a con- Cadastrar Filtros de Viso Operacional 1 4 0 5
tagem das transaes para obteno do UUCW, e em seguida
Realizar Anlises 1 4 0 5
aplicar a somatria dos valores obtidos (ver Tabela 4).
Fazer Leitura 1 2 0 3
O que pode ser considerado uma transao so passos do
fluxo de eventos do caso de uso que: Gerar Relatrios 1 2 0 3
(i) contm campos de entrada com valores passveis de escolha; Total 17 39 0 56
(ii) apresentem retorno de consultas com filtros preenchidos Tabela 4. Transaes por Caso de Uso
por buscas em bancos de dados;
(iii) proporcionem validaes complexas de negcio; Aps os clculos dos atores e dos casos de uso, a etapa que
(iv) contm gerao de relatrio; segue a que considera os fatores tcnicos e ambientais como
(v) apresentem funcionalidades de consultas auxiliares como elementos de influncia no desenvolvimento de um projeto.
casos de uso de extenso; (vi) existam validaes simples de O sistema deve ser colocado em evidncia quanto a treze
campo de entrada de dados. questionamentos propostos e pontuados de 0 a 5. Aps anlise
do sistema ABCLIMS e seu contexto na ABC, foi definida a
Portanto, extremamente importante para a contagem dos pontuao para cada questo levantada, de acordo com as ca-
casos de uso que os cenrios sejam adequadamente elaborados, ractersticas que condizem com a realidade do sistema e aps
caso contrrio h grande probabilidade de o valor final para os entrevista com um engenheiro gerente de projetos da ABC.

Edio 68 - Engenharia de Software Magazine 33

A seguir so detalhados cada um dos fatores de complexidade
tcnica (Technical Complexity Factor - TCF) que pontuaro
o sistema.
O TCF sistema distribudo est relacionado a dados ou
processamento distribudo entre vrias unidades de proces-
samento (CPU). Atravs de levantamento de dados da ABC, o
gerente de projetos classificou esse TCF com pontuao 0, uma
vez esclarecido que compete ao Banco de Dados a utilizao das
CPUs, sendo que a aplicao no faz diferena entre elas:
0. A aplicao no auxilia na transferncia de dados ou pro-
cessamento entre as CPUs da instalao.
1. A aplicao prepara dados para o usurio final processar em
outra CPU da instalao. Por exemplo, planilhas eletrnicas
ou gerenciadores de banco de dados de PC.
2. Os dados so preparados para transferncia, transferidos
e processados em uma outra CPU da instalao (mas NO
para processamento pelo usurio final como visto no item 1).
3. Processamento distribudo e transferncia de dados on-line
apenas em uma direo.
4. Processamento distribudo e transferncia de dados on-line
em ambas as direes.
5. As funes de processamento so executadas dinamicamen-
te na CPU mais apropriada.
O TCF tempo de resposta identifica os objetivos de desem-
penho da aplicao estabelecidos e aprovados pelo usurio.
O problema da gesto de laboratrios crtico em relao
ao horrio de operao, sendo que as transaes no podem
representar intervalos de tempo grandes para os usurios.
O gerente de projetos classificou esse TCF com pontuao 3,
aps anlise das descries abaixo:
0. Nenhuma exigncia especial de desempenho foi fixada
pelo usurio.
1. Requisitos de desempenho foram estabelecidos e revisados,
mas nenhuma ao especial foi necessria.
2. O tempo de resposta crtico durante as horas de pico. O
intervalo de tempo limite (deadline) do processamento sem-
pre para o prximo dia til. Nenhuma considerao especial
para utilizao de CPU foi requerida.
3. O tempo de resposta crtico durante todo o horrio de
utilizao. Os requisitos de prazo de processamento com
outros sistemas so limitantes. No foi necessrio nenhum
procedimento especial para utilizao de CPU.
4. Os requisitos de desempenho estabelecidos pelo usurio
so rigorosos o bastante para requerer tarefas de anlise de
desempenho na fase de anlise e projeto da aplicao.
5. Alm do descrito no Pontuao 4, ferramentas de anlise
de desempenho foram usadas nas fases de projeto, desenvol-
vimento e/ou implementao a fim de proporcionar a desem-
penho estabelecida pelo usurio.
O TCF eficincia (ver Tabela 5) evidencia as funes on-
line fornecidas em um projeto da aplicao para o usurio
final. Mais do que apresentar todas as funes adaptadas aos
sistemas ABCLIMS, o processamento especial de auditoria
34 Engenharia de Software Magazine - Use Case Point: Estimativas de Projeto Parte 3
e/ou de segurana atende norma ISO 17025 referente a esse
processo, e o processamento matemtico extensivo conta
com ferramentas de apoio (SLOPE e Intercept, por exemplo).
A pontuao aplicada, portanto, 5. Esse TCF pode ser dividido
nas seguintes categorias:
Menus;
Documentao/Help on-line;
Movimento automtico do cursor;
Movimento de Tela (scrolling) vertical e horizontal;
Impresso remota (via transaes on-line);
Teclas de Funo pr-definidas;
Execuo de jobs batch a partir de transaes on-line;
Seleo de dados da tela via movimentao do cursor;
Uso intenso de vdeo reverso, brilho intensificado, sublinha-
do, cores e outros recursos de vdeo;
Documentao de transaes on-line via hard copy;
Interface para mouse;
Pop-up Windows;
O mnimo possvel de telas para executar as funes do
negcio;
Fcil navegao entre telas (por exemplo, atravs de teclas
de funo);
Suporte bilnge (suporta dois idiomas, contar como quatro
itens);
Suporte multilnge (suporta mais de dois idiomas, contar
como seis itens).
Pontuao Descrio do Fator de Complexidade Tcnica 3
0 A aplicao no apresenta nenhum dos itens acima.
1 Apresenta de 1 a 3 dos itens acima.
2 Apresenta de 4 a 5 dos itens acima.
Apresenta 6 ou mais dos itens acima, mas no h nenhum requisito do usurio
3
relacionado eficincia.
Apresenta 6 ou mais dos itens acima, e os requisitos estabelecidos para eficincia
4 do usurio so rigorosos o suficiente para que a fase de projeto da aplicao inclua
fatores para: minimizar a digitao, maximizar os defaults, utilizar templates etc.
Apresenta 6 ou mais dos itens acima, e os requisitos estabelecidos para eficincia
do usurio so rigorosos o suficiente para que seja necessrio o uso de ferramentas
5
e processos especiais para demonstrar que os objetivos de eficincia foram
alcanados.
Tabela 5. TCF eficincia
Para a anlise do TCF complexidade do processamento (ver
Tabela 6), foi considerada a grande quantidade de equipamen-
tos ligados ao sistema (distribuio de 50 a 60 equipamentos
nos postos), alm de todos os itens abaixo terem sido validados
como presentes na empresa, classificando o fator com pontua-
o 5. Esse TCF pode ser dividido nas seguintes categorias:
Processamento especial de auditoria e/ou de segurana;
Processamento lgico extensivo;
Processamento matemtico extensivo;
Grande quantidade de processamento de excees, resultante
de transaes incompletas que necessitam de reprocessamento.
Por exemplo: transaes incompletas de ATMs causadas por

interrupes de comunicao, valores de dados ausentes ou
validaes de erros;
Processamento complexo para manipular mltiplas possi-
bilidades de entrada/sada. Por exemplo: mltiplos meios e
independncia de equipamentos.
Pontuao Descrio do Fator de Complexidade Tcnica 4
0 No apresenta nenhum dos itens acima.
1 Apresenta um dos itens acima.
2 Apresenta dois dos itens acima.
3 Apresenta trs dos itens acima.
4 Apresenta quatro dos itens acima.
5 Apresenta todos os itens acima.
Tabela 6. TCF complexidade do processamento
Para a pontuao do TCF cdigo deve ser reutilizado, avalia-
se que a aplicao e o seu cdigo foram especificamente pro-
jetados, desenvolvidos e suportados para serem reutilizados
em outras aplicaes. As caractersticas da aplicao utilizada
na ABC se enquadram na pontuao 5:
0. No apresenta cdigo reutilizvel.
1. O cdigo reutilizvel usado somente dentro da prpria
aplicao.
2. Menos de 10% da aplicao foi feita, levando-se em conta o
seu uso por outras aplicaes.
3. 10% ou mais da aplicao foi feita, levando-se em conta a
sua utilizao por outras aplicaes.
4. A aplicao foi projetada e documentada para facilitar a
reutilizao de cdigo e a aplicao customizada pelo usurio
no nvel do cdigo fonte.
5. A aplicao foi projetada e documentada para facilitar a reu-
tilizao de cdigo e a aplicao customizada para uso atravs
de parmetros que podem ser atualizados pelo usurio.
Atravs do TCF facilidade de instalao, so analisados o
plano de implantao e converso de dados e/ou ferramentas
de converso de dados, averiguando tambm se foi prepara-
do e testado durante a fase de testes dos sistemas. Esse fator
recebeu, portanto, pontuao 3, aps anlise dos itens abaixo
pelo gerente de projetos:
0. Nenhuma considerao especial foi feita pelo usurio
e nenhum procedimento especial foi requerido para a
implantao.
1. Nenhuma considerao especial foi feita pelo usurio, mas
um procedimento especial foi requerido para a implantao.
2. Requisitos de implantao e converso de dados foram fi-
xados pelo usurio, e roteiros de implantao e converso de
dados foram preparados e testados. O impacto da converso
de dados no projeto no considerado importante.
3. Requisitos de implantao e converso de dados foram fi-
xados pelo usurio e roteiros de implantao e converso de
dados foram preparados e testados. O impacto da converso
de dados no projeto considerado importante.
planejamento
4. Alm do descrito no item 2, ferramentas automatizadas
de implantao e converso de dados foram preparadas e
testadas.
5. Alm do descrito no item 3, ferramentas automatizadas
de implantao e converso de dados foram preparadas e
testadas.
O TCF facilidade de uso (ver Tabela 7) refere-se ao de-
senvolvimento e testes de procedimentos efetivos de ini-
cializao, backup e recuperao. A aplicao minimiza a
necessidade de atividades manuais, tais como montagem
de fitas magnticas, manuseio de formulrios e interveno
manual do operador. Nesse caso, a participao de um pro-
fissional na preparao de realizao de backup caracteriza
o fator com pontuao 1.
Pontuao Descrio do Fator de Complexidade Tcnica 7
Nenhuma considerao especial sobre facilidade operacional, alm dos
0
procedimentos normais de backup, foi feita pelo usurio.
Procedimentos eficientes de inicializao, backup e recuperao foram preparados,
1
mas a interveno do operador necessria.
Procedimentos eficientes de inicializao, backup e recuperao foram preparados,
2
mas nenhuma interveno do operador necessria (contar como dois itens).
3 A aplicao minimiza a operao de montagem de fitas magnticas.
4 A aplicao minimiza a necessidade de manuseio de formulrios.
A aplicao foi projetada para no precisar de interveno do operador no seu
5 funcionamento normal. Apenas a inicializao e parada do sistema ficam a cargo do
operador. A recuperao automtica de erros uma caracterstica da aplicao.
Tabela 7. TCF facilidade de uso
Para o TCF portabilidade verificado se a aplicao foi espe-
cificamente projetada, desenvolvida e suportada para ser ins-
talada em mltiplas plataformas (Windows, Unix, Linux, etc.).
A plataforma utilizada tanto pela ABC quanto pelos clientes
o Windows, de modo que no h requerimento para instalao
da aplicao em outra plataforma. A pontuao dada a esse
fator 0, ao considerar os itens descritos abaixo:
0. Nenhuma solicitao do usurio para considerar a necessi-
dade de instalar a aplicao em mais de uma plataforma.
1. Necessidade de instalao em mltiplas plataformas foi
levada em considerao no projeto do sistema e a aplicao
foi projetada para operar somente em ambientes idnticos de
hardware e software.
2. Idem ao item 2, somente em ambientes similares de hardware
e software.
3. Necessidade de instalao em mltiplas plataformas foi
levada em considerao no projeto do sistema e a aplicao foi
projetada para operar inclusive em plataformas diferentes.
4. Um plano de documentao e manuteno foi elaborado e
testado para suportar a aplicao em mltiplas plataformas e
a aplicao atende aos itens 1 e 2.
5. Um plano de documentao e manuteno foi elaborado e
testado para suportar a aplicao em mltiplas plataformas se
a aplicao atende ao item 3.
Edio 68 - Engenharia de Software Magazine 35
 O TCF facilidade de alteraes (ver Tabela 8) abrange se a
aplicao foi especificamente projetada, desenvolvida para
suportar manuteno, visando facilidade de mudanas.
Para esse TCF foi dada a pontuao 5, pois todos os relat-
rios so dinmicos e o usurio escolhe mais de 30 opes de
filtros e colunas. Esse TCF pode ser dividido nas seguintes
categorias:
Capacidade de consultas/relatrios flexveis est disponvel;
Dados de controle do negcio so agrupados em tabelas
passveis de manuteno pelo usurio.
Pontuao Descrio do Fator de Complexidade Tcnica 9
Nenhum requisito especial do usurio para projetar a aplicao, visando minimizar
0
ou facilitar mudanas.
fornecido recurso da consulta/relatrios flexveis capaz de manipular solicitaes
1 simples de consulta (query requests). Por exemplo: lgica de and/or aplicada a
somente um Arquivo Lgico Interno (contar como um item).
fornecido recurso de consulta/relatrios flexveis capaz de manipular solicitaes
2 de consulta (query requests) de mdia complexidade. Por exemplo: lgica de and/
or aplicada a mais de um Arquivo Lgico Interno (contar como dois itens).
fornecido recurso de consulta/relatrios flexveis capaz de manipular solicitaes
complexas de consulta (query requests). Por exemplo: combinaes de lgica
3 segurana da aplicao.
de and/or aplicadas a um ou mais Arquivos Lgicos Internos (contar como trs
itens).
Dados de controle so mantidos em tabelas que so atualizadas pelo usurio
4 atravs de processos on-line e interativos, mas as alteraes s so efetivadas no
prximo dia til.
Dados de controle so mantidos em tabelas que podem ser atualizadas pelo
5 usurio atravs de processos on-line e interativos e as alteraes so efetivadas
imediatamente (contar como dois itens).
Tabela 8. TCF facilidade de alteraes
No TCF uso concorrente verificada a quantidade de acessos
simultneos aplicao. A pontuao recebida da ABC para
esse item 5, pois o gerente de projetos justifica que o controle
de acesso com ferramenta permite 150 acessos simultneos
aplicao:
0. No esperado acesso simultneo.
1. So esperados acessos simultneos esporadicamente.
2. Acessos simultneos so esperados.
3. Acessos simultneos so esperados diariamente.
4. Muitos acessos simultneos foram fixados pelo usurio
para a aplicao, o que fora a execuo de tarefas de anlise
de desempenho na fase de projeto da aplicao.
5. Requer o uso de ferramentas controle de acesso nas fases
de projeto desenvolvimento e/ou implantao, alm das con-
sideraes acima.
O TCF recursos de segurana (ver Tabela 9) indica o nvel de
segurana requerido para a aplicao. A pontuao aplicada
para esse fator 5, uma vez que os laboratrios tm uma grande
exigncia de segurana e auditoria, atendendo aos requisitos
para certificao da norma ISO 17025.
Atravs da TCF permite acesso por terceiros, avaliada a
necessidade de se fazer consideraes especiais no projeto do
36 Engenharia de Software Magazine - Use Case Point: Estimativas de Projeto Parte 3
sistema para que a configurao do equipamento no fique
sobrecarregada. A pontuao 0 aplicada a esse fator significa
que no h a necessidade de restries operacionais que so-
brecarregassem o equipamento:
0. No h restries operacionais explcitas ou implcitas.
1. Existem restries operacionais, mas so menos restritivas
do que aplicaes tpicas. Nenhum esforo extra necessrio
para suplantar as restries.
2. Algumas consideraes sobre tempo e segurana so
necessrias.
3. Necessidades especiais de processador para uma parte
especfica da aplicao.
4. Restries operacionais estabelecidas requerem ateno es-
pecial no nvel de processador central ou processador dedicado
para executar a aplicao.
5. Alm do descrito acima, existem sobrecargas no nvel
das unidades de processamento (CPUs) distribudas da
instalao.
Pontuao Descrio do Fator de Complexidade Tcnica 11
Nenhuma solicitao do usurio para considerar a necessidade de controle de
0
Necessidade de controle de segurana foi levada em considerao no projeto do
1
sistema.
Necessidade de controle de segurana foi levada em considerao no projeto
2 do sistema e a aplicao foi projetada para ser acessada somente por usurios
autorizados.
Necessidade de controle de segurana foi levada em considerao no projeto
3 do sistema e a aplicao foi projetada para ser acessada somente por usurios
autorizados. O acesso ser controlado e auditado.
Um plano de segurana foi elaborado e testado para suportar o controle de acesso
4
aplicao.
Um plano de segurana foi elaborado e testado para suportar o controle de acesso
5
aplicao e a auditoria.
Tabela 9. TCF recursos de segurana
O TCF necessidade de treinamento refere-se s necessidades
de preparao da equipe para entendimento da aplicao.
O sistema conta com recursos de um Help On-Line, e os vrios
analistas tm treinamentos especficos para as atividades que iro
exercer no sistema, possibilitando que esse fator fosse classificado
com a pontuao 5, considerando os itens listados abaixo:
0- Nenhuma solicitao do usurio para considerar a necessi-
dade de treinamento especial.
1- Necessidade de treinamento especial foi levada em consi-
derao no projeto do sistema.
2- Necessidade de treinamento foi levada em considerao no
projeto do sistema e a aplicao foi projetada para ser acessada
com facilidade pelos usurios.
3- Necessidade de treinamento especial foi levada em consi-
derao no projeto do sistema e a aplicao foi projetada para
ser utilizada por usurios de diversos nveis.
4-5- Um plano de treinamento foi elaborado e testado para
facilitar o uso da aplicao.
 planejamento

Com base nos dados sobre os fatores de complexidade tcnica 4 - A maioria da equipe tem dois anos de experincia.
apresentados nos quadros acima, a pontuao apresentada 5 - Todos os membros so experientes.
na Tabela 10 foi gerada (subtotal) de acordo com o projeto
desenvolvido. Pontuao Descrio do Fator Ambiental 1

0 A equipe no familiar com o processo de desenvolvimento de software.

Descrio dos fatores tcnicos Peso (P i) Fi Subtotal
Sistema distribudo 2 0 0 A equipe tem conhecimento terico do processo de desenvolvimento de
1
software.
Tempo de resposta 1 3 3
Um ou mais membros utilizou o processo uma ou poucas vezes a CPU da instalao
Eficincia 1 5 5 2-3
(mas NO para processamento pelo usurio final como visto no item 1).
Complexidade do processamento 1 5 5 Pelo menos a metade dos membros da equipe tem experincia no uso do processo
3-4
Cdigo deve ser reutilizado 1 5 5 em diferentes projetos.
Facilidade de instalao 0,5 3 1,5 5 Toda a equipe tem experincia no uso do processo em vrios projetos diferentes.
Facilidade de uso 0,5 1 0,5
Tabela 11. EF familiaridade com o processo de desenvolvimento de
Portabilidade 2 0 0 software
Facilidade de alteraes 1 5 5
Uso concorrente 1 5 5 O EF experincia em Orientao a Objetos mede a experin-
Recursos de segurana 1 5 5 cia da equipe com anlise e projeto OO, modelagem de casos
Permite acesso por terceiros 1 0 0 de uso, classes e componentes. Para esse fator foi levado em
conta a experincia acima de dois anos da maioria da equipe
Necessidade de treinamento 1 5 5
(pontuao 4):
Total 40
0 - A equipe no familiar com anlise e projeto Orientao
Tabela 10. Fatores de Complexidade Tcnica para o sistema ABCLIMS a Objetos.
1 - Todos os membros tem menos de 1 ano de experincia.
A partir destas informaes, tem-se que: 2-3 - Todos os membros tm de 1 a 1 ano de experincia.
1
3
4 - A maioria da equipe tem mais de 2 anos de experincia.
6 + (0,01 Fi x Pi )
TCF = 0,0
i=1
, onde TCF o valor total da complexidade 5 - Todos os membros so experientes (mais de 2 anos).
tcnica.
O EF capacidade do analista (ver Tabela 12) indica a expe-
TCF = 0,06 + (0,01 x 40) = 0,46 rincia do analista com anlise de requisitos e modelagem.
Nessa avaliao foi aplicada a pontuao 5 (quatro analistas
Sabe-se que o sucesso de um projeto no depende apenas programadores, componentes da equipe, tm mais de trs anos
de fatores tcnicos ou um bom levantamento de requisitos. de experincia).
O conhecimento desse sistema e a equipe que o integra, por Para o EF motivao (ver Tabela 13), referente motivao
exemplo, so elementos fundamentais de anlise. Conforme total da equipe, foi dada pontuao 3, pois segundo o gerente
em artigos anteriores desta srie, os fatores ambientais (En- de projetos, todos os componentes da equipe esto predispos-
vironmental Factor - EF) so previstos na estimativa de UCP. tos realizao de um bom trabalho.
Com base nesses fatores, seguem as caractersticas a serem
pontuadas. Pontuao Descrio do Fator Ambiental 4
O EF familiaridade com o processo de desenvolvimento 0 O analista do projeto novato.
de software (ver Tabela 11) indica a experincia da equipe 1-2 Possui experincia de poucos projetos.
com processos/mtodos para o desenvolvimento do proje-
3-4 Pelo menos 2 anos de experincia com vrios projetos.
to, como o RUP, por exemplo. Para esse fator foi aplicada a
pontuao 0, dada a no familiaridade com o processo de 5 Pelo menos 3 anos de experincia com projetos variados.
desenvolvimento. Tabela 12. EF capacidade do analista
O EF experincia na aplicao indica a experincia com dife-
rentes tipos de aplicao ou com o tipo de aplicao que est
sendo desenvolvida. Para esse fator foi dada a pontuao 2, Pontuao Descrio do Fator Ambiental 5
considerando que alguns membros da equipe j possuem mais 0 No motivada.
de um ano e meio de experincia para a aplicao: 1-2 Pouca motivada.
0 - Todos os membros da equipe so novatos.
3-4 A equipe est motivada para fazer um bom trabalho.
1-2 - Poucos membros da equipe possuem alguma experincia
(de 1 a 1 ano). Os outros so novatos. 5 A equipe est muito motivada e inspirada.
3 - Todos os membros tm mais de 1 ano de experincia. Tabela 13. EF motivao

Edio 68 - Engenharia de Software Magazine 37

 O EF estabilidade dos requisitos mede o grau de mudana Descrio dos fatores ambientais Peso (P i) Fi Subtotal
de requisitos e inseguranas sobre o significado dos requeri- Familiaridade com o processo de desenvolvimento de software 1,5 0 0
mentos. Esse fator foi classificado com pontuao 3, visto que a Experincia na aplicao 0,5 2 1
ABC tem 10 anos de experincia na realizao dessa atividade,
Experincia em Orientao a Objetos 1 4 4
de forma a facilitar para no existirem mudanas:
Capacidade do analista 0,5 5 2,5
0 - Requisitos muito instveis com mudanas frequentes.
1-2 - Requisitos instveis. Clientes demandam algumas mu- Motivao 1 3 3
danas realizadas em diversos intervalos. Estabilidade dos requisitos 2 3 6
3-4 - Estabilidade global. Pequenas mudanas so necessrias. Empregados em tempo parcial -1 4 -4
5 - Requisitos estveis ao longo do desenvolvimento Dificuldade com linguagem de programao -1 0 0
Total 10,5
O EF empregados em tempo parcial mede a estabi-
lidade da equipe e a influncia do trabalho parcial na Tabela 14. Fatores Ambientais para o sistema ABCLIMS
produtividade. Considerando que mais da metade dos
componentes da equipe dedicam seu tempo parcialmen- A partir desse resultado, pode-se obter o nmero de homem-
te a esse projeto, foi aplicada a pontuao 4 pelo geren- horas adotando a proporo de um ponto de caso de uso para
te de projetos, considerando os itens descritos abaixo: cada vinte homem-horas. Schneider e Winters (2001) reco-
0 - No tem membro com dedicao parcial. mendam essa proporo para projetos com equipe estvel e
1-2 - Poucos membros (20%) trabalham em perodo parcial. experiente, podendo variar para at 28 HH/UCP em equipes
3-4 - A metade dos membros da equipe trabalha em perodo com menor experincia.
parcial. A aplicao de 28 HH/UCP de produtividade neste estudo de
5 - Todos os membros da equipe trabalham em perodo parcial. caso est de acordo com o proposto por Schneider e Winters.
Dessa forma, pode-se calcular a produtividade total requerida
O EF dificuldade com linguagem de programao indica a para atender aos casos de uso solicitados como:
experincia com ferramentas primrias de desenvolvimento Total Homem-Horas = 62,887 x 28 1760,84 HH
e com a linguagem de programao escolhida. A pontuao 0
aplicada a esse fator ambiental significa que todos os compo- A produtividade de 1760,84 homem-horas para os casos de
nentes da equipe tm mais de trs anos de experincia no uso uso aplicados ao sistema ABCLIMS permite ao gerente de-
das ferramentas de desenvolvimento: terminar um custo e o tempo padro por homem-hora para o
0 - Todos os membros da equipe so programadores projeto, por se tratar de uma unidade de medida. Atravs da
experientes. anlise do grfico apresentado na Figura 11, nota-se que h
1 - A maioria dos membros da equipe possuem mais de dois uma variao de 1239,16 no valor estimado para o desenvol-
anos de experincia. vimento do ABCLIMS em relao ao valor real fornecido pela
2 - Todos os membros tm mais de 1 ano de experincia. ABC (3000 homem-horas) para implementao do sistema.
3 - A maioria da equipe tem mais de um ano de experincia. Essa diferena pode ser justificada pela pontuao aplicada
4 - Poucos membros da equipe tm alguma experincia (um aos fatores ambientais, pois o valor estimado atravs do UCP
ano). Os outros so novatos. leva em conta critrios como a experincia da equipe, e esta
5 - Todos os membros da equipe so novatos. experincia est sujeita rotatividade de pessoas no projeto,
e at mesmo contratao de novos integrantes.
Com base nos dados sobre os fatores ambientais elaborados e
apresentados nas tabelas anteriores, a pontuao apresentada
na Tabela 14 foi gerada (subtotal) de acordo com o projeto
desenvolvido.
A partir destas informaes, tem-se que:
8
F = 1,4 + (0,03 Fi x Pi )
E
i=1
, onde EF o valor total da complexi-
dade ambiental.
EF = 1,4 + (-0,03 x 10,5) = 1,085

Com os pesos no ajustados dos atores e dos casos de uso, o

prximo passo calcular o peso no ajustado dos Pontos por
Caso de Uso:

UCP = (UAW + UUCW) x TCF x EF

UCP = (11 + 115) x 0,46 x 1,085 62,887 Figura 11. Estimativas com e sem TCF em relao produtividade real

38 Engenharia de Software Magazine - Use Case Point: Estimativas de Projeto Parte 3


Quanto utilizao dos fatores de complexidade tcnica para
o clculo dos pontos por caso de uso, verifica-se que a no
adoo desse fator gera uma diferena para o projeto (2067,04
homem-horas em relao ao valor estimado com TCF) que pode
levar a equipe a grandes distores no clculo das estimativas,
caso no considerem esses fatores de funcionalidade.
Embora parea ser complexo, o uso da tcnica apresentada
neste artigo pode ser assimilada facilmente. Seu uso nos pro-
jetos faz com que se torne prtica e entendamos mais a fundo
os detalhes que podem tornar seu uso ainda mais eficaz.
Voc gostou deste artigo?
D seu voto em www.devmedia.com.br/esmag/feedback
Ajude-nos a manter a qualidade da revista!
planejamento
Referncias:
[1] BEZERRA, E. Princpios de Anlise e Projeto de Sistemas com UML. Rio de
Janeiro: Elsevier, 2002.
[2] CARROLL, E.R. Estimating Software Based on Use Case Point. In: Conferen-
ce on Object Oriented Programming Systems Languages and Applications,
20., San Diego, 2005. Practitioner report. Nova Iorque: ACM Press, 2005.
p.257-265.
[3] ROCHA, A.R.C.; MALDONADO, J.C.; WEBER, K.C. Qualidade de Software:
Teoria e Prtica. So Paulo: Pearson Education do Brasil/Makron Books
Ltda, 2001.
[4] TONSIG, S.L. Engenharia de Software: anlise e projeto de sistemas. So
Paulo: Futura, 2003.
[5] CARROLL, E.R. Estimating Software Based on Use Case Point. In: CON-
FERENCE ON OBJECT ORIENTED PROGRAMMING SYSTEMS LANGUAGES AND
APPLICATIONS, 20., San Diego, 2005. Practitioner report. Nova Iorque: ACM
Press, 2005. p.257-265.
[6] KARNER, G. Resource Estimation for Objectory Projects. Kista: Objective
Systems SF AB, 1993.
Edio 68 - Engenharia de Software Magazine 39
Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros
UML: A evoluo do diagrama de Caso de Uso 2.0
Abordagem prtica da evoluo do modelo mais famoso da UML
Daniel Paz de Arajo
Atua como professor de ps-graduao no Se-
nac So Paulo e analista de sistemas na Matera
Systems. Realiza pesquisas sobre articulaes
entre arte, educao e tecnologia, sendo autor
de artigos tcnicos e palestrante nas reas.
Possui formao de Bacharel em Cincias da
Computao pela Universidade Jos do Rosrio
Vellano em Minas Gerais; Mestre em Processos
Cognitivos e Ambientes Digitais pelo curso de
Tecnologias da Inteligncia e Design Digital, da
Pontifcia Universidade Catlica de So Paulo -
PUCSP; MBA em Gesto da Tecnologia da Infor-
mao e Especializao em Docncia no Ensino
Superior pela Fundao Getlio Vargas - FGV,
e; doutorando em Artes Visuais na linha de
Multimeios e Arte pela Universidade Estadual
de Campinas UNICAMP. Em seu site http://
www.araujo.co esto publicados contedos
sobre temas diversos.
40 Engenharia de Software Magazine - UML: A evoluo do diagrama de Caso de Uso 2.0
O
Caso de Uso 2.0 surgiu como
uma forma de representar as
atuais prticas dos casos de uso,
representando tcnicas bem sucedidas
adotadas pela comunidade. No houve
alterao terica dos casos de uso, mas
sim na forma com que os analistas rea-
lizam seu levantamento, detalhamento,
organizao e comunicao. Seu foco
identificar e detalhar requisitos de forma
enxuta, ou seja, evitando desperdcios.
Os requisitos so as necessidades que
o sistema dever satisfazer e por isso
devem ser claros, tangveis e com valor
para o cliente. Eles so comunicados
pelas partes interessadas no sistema, ou
seja, pessoas, grupos ou organizaes que
Fique por dentro:
Este artigo descreve a aplicao de casos de
uso de maneira gil e escalvel, baseada na
evoluo tcnica definida por Ivar Jacobson
como Caso de Uso 2.0. Sero apresentados os
fundamentos para desenvolvimento orientado
a casos de uso. Um caso de uso representa as
possveis maneiras que um usurio pode utilizar
um sistema para atingir um objetivo especfico.
Eles permitem definir o escopo de um sistema e
gerenciar o desenvolvimento incremental, tan-
to para pequenas equipes geis quanto grandes
projetos de sistemas complexos, suportando
sua anlise, modelagem, planejamento, avalia-
o, monitoramento e testes.
afetam ou so afetadas pela necessidade
identificada. Casos de Uso 2.0 auxiliam
a captura de requisitos bem como possi-
bilita analisar as influncias e impactos
nos elementos envolvidos em um sistema.
Qualquer mudana, seja devido uma
lio aprendida, alterao no escopo ou
nova funcionalidade, resultam em alte-
raes nos casos de uso e sua influncia
nos elementos do sistema podem ser fa-
cilmente analisadas pelo modelo de casos

de uso. A qualidade da soluo sistematizada verificada por
um conjunto de testes, confirmando se os casos de uso e suas
fatias foram implementadas com sucesso. Os princpios bsicos
para aplicao com sucesso de casos de uso so:
1. Manter a simplicidade atravs de histrias: Contar hist-
rias a melhor forma de comunicar o que um sistema deve
fazer, e manter a equipe trabalhando com foco nos mesmos
objetivos. Os casos de uso capturam os objetivos do sistema.
Para entender um caso de uso devemos contar histrias. As
histrias abordam como atingir um objetivo com sucesso, e
como lidar com quaisquer problemas que podem ocorrer no
caminho. Quando se utiliza histrias como uma tcnica para
comunicar requisitos essencial certificar que estas sero
capturadas de forma que sejam executveis e testveis. Um
conjunto de casos de teste acompanham cada narrativa de caso
de uso para completar sua descrio. Os casos de teste so a
parte mais importante de uma descrio de caso de uso, mais
importante at que a narrativa do caso de uso. Isso porque
eles tornam as histrias reais, e seu uso pode demonstrar de
forma inequvoca se o sistema est fazendo o que supostamente
deveria fazer. o caso de teste que define o que implementar
com sucesso no caso de uso;
2. Entender a viso geral: independentemente do tamanho ou
complexidade do sistema que ser desenvolvido, essencial
que se tenha a viso geral do que ser feito. Sem uma compre-
enso do todo, ser difcil tomar as decises corretas sobre o
que incluir ou no no sistema, seus custos e valores que sero
agregados. Isso no significa capturar todos os requisitos,
mas necessrio criar uma viso que permita entender todo
o escopo e acompanhar o progresso do desenvolvimento do
sistema. Os modelos de caso de uso reconhecem o fato de que
os sistemas suportam vrios objetivos de diferentes partes in-
teressadas. Nestes modelos os interessados que usam o sistema
e contribuem para a realizao dos objetivos so representados
como atores, e as maneiras que o sistema ser utilizado para
alcanar esses objetivos so modelados como casos de uso;
3. Focar no valor: Ao avaliar como um sistema ser usado,
fundamental se concentrar no valor que ser proporcionado
a todas as partes interessadas. Os casos de uso proporcionam
esse foco, concentrando-se sobre como o sistema ser usado
para atingir uma meta especfica para determinado usurio.
O ideal comear pela a maneira mais simples possvel de
alcanar um objetivo e a partir da capturar as maneiras al-
ternativas de alcanar o objetivo e como lidar com quaisquer
problemas que possam ocorrer. Isso ir permitir que as formas
mais valiosas de se utilizar o sistema possam ser identifica-
das e permitir que outras de menor valor sejam adicionadas
posteriormente;
4. Construir em partes: a maioria dos sistemas tm muitos re-
quisitos, muitos dependentes de outros requisitos que devero
ser implementados antes que se possa entregar algo de valor.
O sistema deve ser construdo em partes, cada uma tendo valor
claro para os usurios. Inicialmente deve-se identificar qual o
objetivo fundamental do sistema e a partir disso definir o que
ter mais valor. Este objetivo deve ser quebrado em pequenas
en gen haria
partes ou fatias. Esta uma das principais caractersticas do
Caso de Uso 2.0, onde os casos de uso so fatiados para pro-
porcionar itens de trabalho de tamanhos adequados e evoluir
o sistema a cada fatia. A melhor maneira para identificar as
fatias consider-las como histrias de usurio. Cada histria
pode ser definida como parte da narrativa do caso de uso e
podem ser acompanhadas por casos de testes. Os casos de
testes so fundamentais para descrio das fatias de caso de
uso pois eles fazem a histria se tornar real. A primeira fatia
provavelmente conter o fluxo bsico e um caso de teste. Fatias
podem ser adicionadas para completar o fluxo e os casos de
teste. As fatias devem ser criadas do tamanho apropriado para
conduzir seu desenvolvimento, mantendo o foco no valor e
completude de cada caso de uso;
5. Entregar em incrementos: normalmente os sistemas no
so produzidos de uma s vez, mas evoludos atravs de uma
srie de iteraes. Cada incremento entregue em uma iterao
baseado no incremento anterior, seja para adicionar novas
funcionalidades ou melhorar a qualidade. Da mesma forma,
os casos de uso devem considerar entregas incrementais, po-
dendo ser utilizados para planejar as entregas. A anlise dos
casos de uso permite que conjuntos de requisitos relacionados
sejam priorizados ou adiados para outras verses. Ao utilizar
os casos de uso na abordagem de entregas, o objetivo de cada
iterao fica claro para toda a equipe;
6. Adaptar para conhecer as necessidades: o trabalho de
desenvolvimento de software varia bastante em cada projeto
por envolver necessidades, ferramentas e equipes diferentes.
Por este motivo, as tcnicas utilizadas devem ser flexveis
e adaptveis suficientemente para atender a estas questes.
Requisitos menos detalhados so adequados para projetos em
que o cliente est bem prximo da equipe de desenvolvimento.
Por outro lado, em muitas situaes este tipo de colaborao
no possvel, o que acaba exigindo um nvel mais detalhado
dos requisitos, tornando-os mais pesados. Com foco na neces-
sidade de adaptao, Caso de Uso 2.0 permite que o requisito
seja to leve quanto for preciso. As histrias capturadas por
pequenas equipes colaborativas podem ser escritas mo em
cartes ou ndices. Equipes maiores e distribudas podem ter
narrativas mais detalhadas em documentos. Cabe equipe
decidir o nvel de detalhe adequado dos requisitos, acrescen-
tando mais informaes naturalmente ao se depararem com
situaes mais complexas.
Fatias de casos de uso
Sistemas de software so construdos para atender a diversos
requisitos dos usurios. Tais necessidades so organizadas em
casos de uso, normalmente grandes ou em grande quantidade.
Para entregar o sistema de forma incremental necessrio divi-
dir os casos de uso em pedaos menores para que possam fluir
atravs do processo de desenvolvimento e sejam priorizados,
implementados e testados.
Uma maneira eficiente para fazer tal diviso fatiar os casos
de uso. Uma fatia de um caso de uso uma ou mais histrias
selecionadas de um caso de uso para formar um item de
Edio 68 - Engenharia de Software Magazine 41
trabalho que possua valor claro para o cliente. A fatia de caso
de uso a caracterstica mais importante do Caso de Uso 2.0,
pois auxilia no direcionamento do desenvolvimento como
um todo. Ela permite que os casos de uso sejam divididos
em itens de trabalho pequenos, independentes e entregveis,
facilita a ordenao, e priorizao das funcionalidades, alm
de interligar os diferentes processos de desenvolvimento de
sistemas como anlise, projeto, construo e testes, em uma
abordagem guiada por casos de uso. Desde a identificao
inicial at sua aceitao final, as fatias de caso de uso evoluem
naturalmente, sendo ajustadas para que representem adequa-
damente o entendimento do requisito. Os estados de uma fatia
de caso de uso so:
1. Definida: as histrias abordadas esto esclarecidas;
2. Preparada: a fatia foi detalhada e os casos de teste esto
escritos;
3. Analisada: o impacto da fatia nos componentes do sistema
foi compreendido;
4. Implementada: a fatia foi codificada e est preparada para
ser testada;
5. Verificada: a fatia foi testada e est pronta para ser
entregue.
A anlise dos estados das fatias auxilia na avaliao do
progresso em entender e implementar os casos de uso. Como
as fatias so independentes, elas podem ser tratadas paralela-
mente aps terem sido organizadas por prioridades e depen-
dncias. Sua organizao permite a otimizao do trabalho ao
direcionar cada conjunto de fatias para a equipe adequada a
realizar as atividades daquele momento.
Histrias
As histrias detalham os casos de uso e devem ser adequadas
para que as partes interessadas identifique o valor de cada uma
delas. Cada histria dever ser acompanhada de um ou mais
casos de teste. As histrias so muito teis para se identificar
as fatias de caso de uso com o tamanho adequado, alm dos
casos de teste corretos. Existem diferentes abordagens para
identificao e estruturao das histrias em casos de uso.
Normalmente adota-se uma das alternativas:
De cima para baixo: os casos de uso so identificados, o
fluxo bsico descrito e posteriormente so criados os fluxos
alternativos com base no fluxo bsico;
De baixo para cima: realizado um brainstorm de algumas
histrias que so analisadas e agrupadas por temas para iden-
tificao do caso de uso, fluxo bsico e fluxos alternativos.
Trabalhando com casos de uso
O primeiro passo a identificao dos atores e principais casos
de uso. Atravs desta anlise ser possvel definir claramente
os objetivos e comportamentos esperados do sistema, planejar o
escopo das verses a serem entregas, definir como o sistema ser
testado e finalmente o valor que o produto final oferecer.
Para que esta anlise seja mais eficaz, o ideal identificar os
atores e casos de uso em conjunto com o cliente ou usurio.
42 Engenharia de Software Magazine - UML: A evoluo do diagrama de Caso de Uso 2.0
Como normalmente o cliente ou usurio no domina a mo-
delagem de casos de uso, para simplificar o entendimento
pode-se simplesmente litar quais usurios iro realizar quais
objetivos no sistema. No necessrio nem adequado identifi-
car inicialmente todos os casos de uso de sistema, mas apenas
aqueles que oferecero maior valor s partes interessadas.
Outros atores e casos de uso podero ser encontrados durante
o detalhamento dos requisitos.
Gerenciando fatias de caso de uso
Os casos de uso e as fatias devem ser organizados de forma
que os mais importantes, ou seja, o que tem mais valor do
ponto de vista do cliente, sejam abordados primeiro. Como os
casos de uso e as fatias so o foco do trabalho da equipe, utilize
tcnicas de gesto visual, como o Kanban, por exemplo, para
torn-los visveis e tangveis para a equipe.
Assim como feito com os casos de uso, o acompanhamento
da evoluo das suas fatias tambm importante para a gesto
do desenvolvimento do software. Para isso, as fatias devem
ser organizadas atravs de nomenclatura, estado e prioridade.
Alm disso, as fatias devem ter outras informaes essenciais
para sua implementao com sucesso:
Histria(s) envolvidas;
Referncia aos casos de uso que definem as histrias;
Referncia aos casos de teste;
Estimativa do trabalho necessrio para implementar e testar
a fatia.
Outros atributos podem ser adicionados quando necessrio
como, por exemplo, a origem do caso de uso, seu responsvel
ou incremento em que ela dever ser entregue.
Modelo de Caso de Uso
Um modelo de caso de uso uma representao de todas
as formas teis de usar um sistema, e o valor que eles iro
fornecer. Ele permite que as equipes cheguem a um acordo
sobre as caractersticas e funcionalidades do sistema, alm de
estabelecer limites e escopos pela identificao de atores e casos
de uso, alm de possibilitar o gerenciamento dos requisitos.
Os modelos de caso de uso podem ser organizados em quadros
brancos, slides, documentos ou em ferramentas prprias para
modelagem. Seu nvel de detalhe pode variar de acordo com
o momento e a necessidade:
Valor: o primeiro passo para modelagem de casos de uso
identificar os atores e objetivos mais importantes;
Limite do sistema: identificar a relao do sistema com
outros elementos;
Estruturado: evita informaes redundantes como sequn-
cias ou padres de interao.
O modelo de casos de uso deve mostrar claramente o valor
que as partes interessadas recebero do sistema que est sendo
trabalhado. Deve-se ter cuidado com o nvel de detalhes do
modelo para seja til no desenvolvimento do sistema, evitando
incluso de informaes desnecessrias para a equipe.

Narrativa de Caso de Uso
O propsito da narrativa de caso de uso contar uma hist-
ria sobre como o sistema e seus atores trabalham juntos para
chegar a um objetivo. As narrativas de caso de uso:
Descrevem histrias usadas para explorar requisitos e iden-
tificar as fatias de caso de uso;
Descrevem uma sequncia de aes, incluindo variante, que
um sistema e os atores podem executar;
So representados por um conjunto de fluxos que descrevem
as possveis sequencias;
Capturam informaes necessrias para apoiar outras ati-
vidades de desenvolvimento.
As narrativas podem ser feitas em diferentes nveis de deta-
lhamento, de acordo com o momento e a sua necessidade:
Breve descrio: apenas identifica o objetivo do caso de uso
e qual ator ir realiza-lo;
Estrutura com marcadores: o caso de uso estruturado
para que se possa entender sua complexidade. Este nvel de
detalhe permite o fatiamento do caso de uso para que seja
desenvolvido por partes;
Estrutura essencial: captura as responsabilidades sem
definir quais partes do caso de uso sero realizadas pelo ator
ou pelo sistema;
Detalhado: cobrem a ausncia de especializaes dentro da
equipe, falta de acesso s partes interessadas ou a dificuldade
de comunicao sobre requisitos complexos.
Realizao de Caso de Uso
O objetivo da realizao de um caso de uso representar
como os elementos do sistema colaboram em conjunto para
executar um caso de uso. As realizaes de caso de uso:
Identificam os elementos e suas responsabilidades ao exe-
cutar um caso de uso;
Descrevem a interao dos elementos para executar o caso
de uso;
Traduzem a linguagem de negcios para a linguagem do
desenvolvedor que ir implementar o sistema.
As realizaes de caso de uso podem ser representadas em
diversos formatos, de acordo com a necessidade. Normalmente
as realizaes incluem tabelas simples, storyboards, diagramas
de sequncia, colaborao e de fluxo de dados. O detalhamento
da realizao varia de acordo com o momento e necessidade:
Elementos de execuo: captura apenas os elementos que
iro participar do caso de uso;
Responsabilidades: fornecem uma definio de alto nvel do
que cada elemento deve fazer, armazenar e controlar;
Definio da Interao: definio completa das aes neces- os itens de maior valor.
srias de cada elemento envolvido no caso de uso.
Caso de Teste
O objetivo de um caso de teste definir claramente o signifi-
cado de completar com sucesso uma fatia. Eles permitem que
os testes sejam especificados antes da implementao da fatia
en gen haria
e fornecem mecanismos para verificar se os requisitos esto
sendo atendidos alm de ser uma forma de avaliar a qualidade
do sistema. O nvel de detalhamento de um caso de teste varia
de acordo com o momento e a necessidade:
Ideias de teste: apenas captura a ideia inicial por trs do caso
de teste e a qual fatia ela se aplica. Mais detalhes devero ser
adicionados se o teste for executvel;
Cenrio escolhido: escolhido um caminho no conjunto
de cenrios de testes possveis para cumprir a ideia de teste,
definindo claramente se a fatia est pronta;
Identificao de variveis: um caso de teste recebe entradas,
manipula os estados do sistema e produz resultados. Tais vari-
veis aparecem como entradas, estados internos e sadas;
Conjunto de variveis: fornece explicitamente valores espe-
cficos para todas as variveis envolvidas no caso de testes;
Automatizado: deve ser considerado se o caso de teste for
executado muitas vezes ou se for necessrio suportar muitos
testes diferentes.
Os casos de teste sero usados durante todo o tempo de
vida do sistema, e no apenas durante a implementao dos
casos de uso, mas para avaliar impactos e testar regresso e
integrao com outros componentes. A estrutura dos casos de
uso bem feita leva a casos de testes bem feitos. Cada histria
descrita na narrativa do caso de uso dever ter pelo menos
um caso de teste.
Implementando fatias de caso de uso
Normalmente os casos de uso, mesmo os mais simples, co-
brem vrias histrias. Para criar itens de trabalho de tamanhos
mais adequados os casos devem ser fatiados, simplificando a
escolha pelas histrias a serem implementadas. Para maior
assertividade, este processo de fatiar os casos de uso pode ser
realizado com apoio das partes interessadas para se certificar
que as histrias tm valor e podem ser executadas e testadas.
O fluxo bsico do caso de uso mais importante provavelmente
fornecer a fatia de maior valor.
No indicado que todos os casos de uso sejam fatiados de
uma s vez, pois necessrio apenas que haja fatias suficientes
para atender s necessidades imediatas da equipe. Tambm
no preciso que o caso de uso seja completamente fatiado,
mas que apenas sejam retiradas as fatias necessrias para
o progresso do trabalho. Neste sentido, pode ser adotado o
modelo puxado onde os analistas buscam por novas fatias
medida que eles tenham capacidade para trabalh-las. Alm
de criar itens de tamanho adequado para o trabalho da equipe,
as fatias permitem que o escopo seja ajustado dentro do prazo
e oramento disponveis, e que as partes interessadas recebam
Uma vez que as fatias foram identificadas, organizadas
e separadas para o desenvolvimento, preciso prepar-las
para que sejam implementadas. Para tal necessrio que seja
definido claramente o significado de implementar a fatia com
sucesso, quais as caractersticas exigidas do sistema como,
por exemplo, requisitos no funcionais e focar nos testes
Edio 68 - Engenharia de Software Magazine 43
que devero ser satisfeitos. Com base nessas informaes
possvel fazer uma anlise para entender a influncia da
implementao da fatia em relao aos demais elementos do
sistema, definindo suas responsabilidades e como deve ser a
integrao entre eles.
medida que a equipe evolui na compreenso do sistema e
sua arquitetura, ser mais fcil analisar as fatias. O software
ser implementado fatia por fatia que exigiro mudanas em
uma ou mais partes do sistema. Os testes devero ser realizados
independentemente para verificar se a fatia foi implementada
com sucesso. Para garantir a integrao de uma fatia com as
demais partes, o software dever ser retestado e integrado com
todo o sistema se for o caso, para verificar se todas as novas
fatias no impactaram outras partes.
O modelo de casos de uso deve ser revisto continuamente
durante o projeto, principalmente devido s lies aprendidas
e mudanas em prioridades ou em requisitos. Tais mudanas
podem afetar diretamente fatias ou casos de uso inteiros que j
foram ou no implementados. A evoluo do modelo de casos
de uso pode levar identificao de novas histrias, exigindo
a reviso de todo o modelo.
Casos de uso no servem apenas para sistemas que tem uso
intensivo de interao com o usurio, podendo ser aplicados
at em sistemas embarcados que tm pouca ou nenhuma
interao humana. Para que casos de uso sejam utilizados
apropriadamente para qualquer sistema, basta manter o foco
em sua relao com o mundo exterior, seja ele um ser humano
ou outro sistema.
Outra abordagem bastante utilizada sua aplicao para
entender requisitos de negcio, identificando a situao atual e
projetando melhores processos de negcio. Alm dos requisitos
44 Engenharia de Software Magazine - UML: A evoluo do diagrama de Caso de Uso 2.0
funcionais normalmente modelados com casos de uso, as ca-
ractersticas no funcionais de um sistema tambm podem ser
representadas, como parte dos prprios casos de uso. Quando
se est construindo arquitetura em camadas com componentes
de segurana, gerenciamento de dados ou transaes, podem
ser criados casos de uso tcnicos do sistema, contendo os
requisitos que iro direcionar a infraestrutura da aplicao.
Nestes casos, as fatias podem ser transversais, pois afetam o
comportamento do sistema em diversos pontos.
Um dos pontos mais interessantes sobre casos de uso
que eles permitem gerenciar o escopo em alto nvel, sem a
necessidade de detalhar todas as histrias, possibilitando a
priorizao e quebra do trabalho em tamanhos adequados
para a equipe com entregas de valor ao cliente.
Referncias:
JACOBSON, I. at all. The Essence of Software Engineering: Applying the SEMAT
Kernel. Addison-Wesley Professional: 2013
BITTNER, K. SPENCE, I. Use Case Modelling. Addison-Wesley: 2002
JACOBSON, I. BITTNER, K. SPENCE, I. Use Case 2.0: The Guide to Succeding
with Use Cases.
Voc gostou deste artigo?
D seu voto em www.devmedia.com.br/esmag/feedback
Ajude-nos a manter a qualidade da revista!
 en gen haria

Edio 68 - Engenharia de Software Magazine 45

Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros
Teste de Software: Avaliando a eficincia da
equipe
O desafio de medir a eficincia sem ser exclusivamente por mtricas
Clia Negrini
celianegrini@hotmail.com
Graduada na rea de TI, certificada pela
ISTQB(Certified Tester Foundation Level) e
pela ScrumAlliance(CSM- Certified Scrum
Master), com 13 anos de atuao na rea de
tecnologia, sendo os ltimos 8 anos dedicados
a Qualidade de Software. Atualmente coor-
denadora de testes e qualidade na empresa
VALID Certificadora Digital.
46 Engenharia de Software Magazine - Teste de Software: Avaliando a eficincia da equipe
P
ara gerenciar um esforo de teste,
gerentes de testes, coordenadores
de testes e testadores precisam de
informaes que iro auxili-los a tomar
decises oportunas e informadas. Esta
informao geralmente chamada de
Mtrica, mas alm de auxiliar a realizar
medidas, mtricas tambm pode ser
utilizada para identificar necessidades
de aprimoramento do profissional, as-
sim como oportunidades de melhoria
de processos. Com isso podemos afir-
mar que Mtricas um grande aliado
quando o tema medir algo, porm
preciso tomar cuidado, pois devem ser
usadas para o bem, ajudando a orientar
a equipe, e no para punir. Mtricas
usadas de forma errada podem ser
desanimadoras.
Mas ser que a nica forma de medir gestor da rea de testes deve ter o co-
a eficincia de uma equipe de teste se
baseando apenas em mtricas? Ou de-
vemos levar em conta o aspecto pessoal
Fique por dentro:
Equipes de testes possuem seus pontos fortes e
fracos, medir esses pontos um desafio e mui-
tas vezes utilizar apenas um conjunto de mtri-
cas no dar a viso correta sobre a eficincia
da equipe, preciso considerar a particularida-
de do ambiente ao qual a equipe est inserida,
a influncia de fatores externos e a realidade de
cada organizao. Neste contexto, este artigo
apresentar de forma sucinta sinais que leva-
ro gestores a considerar diversas situaes an-
tes de avaliar uma equipe, onde nmeros sem
contexto so apenas nmeros que nem sempre
refletem a condio real de cada profissional.
do profissional? Mtricas por si s so
apenas nmeros que nem sempre refle-
tem a condio real de cada profissional.
Quando a equipe de teste prxima
e o acompanhamento feito de perto,
existem muitos fatores to importantes
quanto os nmeros que precisam ser
levados em conta. Desta forma, um
nhecimento necessrio para avaliar o
contexto e assim realizar o levantamento
de forma eficaz.

Antes de iniciar qualquer medio preciso perguntar: existe
um processo? Ele est claro para todos? Ele seguido? Pode
no parecer, mas para que a entrega de um software ocorra
com uma boa qualidade, o processo deve ser seguido desde
o incio, ou seja, desde a fase de levantamento de requisitos.
Esta uma das etapas mais importantes no planejamento de
desenvolvimento de um software, quando um projeto tem
um levantamento de requisitos inadequado, ou a equipe
no disponibiliza tempo suficiente para essa fase do projeto,
existe uma grande tendncia em haver falhas no decorrer do
desenvolvimento e consequentemente durante os testes. Ao
final, o que ser entregue no ser condizente com o que o
cliente pediu.
Em situaes em que o documento de requisitos no existe,
ou que novos requisitos foram solicitados no decorrer do de-
senvolvimento e no foram documentados, considerando que
o planejamento dos testes j aconteceu, como o profissional de
testes ter tempo para inserir novas condies de testes? Ser
que ele no teve que fazer rapidamente? Ser que ele foi infor-
mado dessas alteraes de requisitos? Qual foi a antecedncia
que isso aconteceu? Tudo precisa ser levado em conta.
Esse apenas um exemplo de fatores que podem afetar um
bom desempenho de um profissional de testes. Por esse mo-
tivo, levar em considerao apenas as mtricas no uma boa liderana executiva pelo menos uma vez em um trimestre,
maneira de avaliar uma equipe de testes, preciso considerar
a particularidade do ambiente ao qual ela est inserida e a
realidade de cada organizao.
Por que medir o processo de teste?
Existe uma presso muito grande para que o processo de teste
de software seja rentvel e eficiente o suficiente para atender
as demandas de realizar a atividade com um baixo custo e a
entrega de um software com qualidade. A melhor forma de
avaliar a eficcia de um processo de teste conseguindo medir
a produtividade da equipe de qualidade envolvida, mas no
deixando de considerar a eficincia de como o trabalho solici-
tado executado. Mtricas ajudam a medir a produtividade de
uma equipe, mas tambm auxiliam a melhorar procedimentos
de teste, mtodos utilizados, ferramentas, entre outros. Colher
dados e realizar a anlise adequada oferece a oportunidade
para as organizaes de aprender com a prpria histria e criar
uma maturidade no processo.
A medida um instrumento que permite que a gesto
identifique eventos importantes e tendncias, auxiliando
na tomada de decises. Alm disso, medies ajudam na
avaliao de riscos, que por sua vez diminui a probabilidade
de surpresas inesperadas em diferentes fases do processo de
teste. Organizaes que conseguem medir o processo de sua
equipe de teste so capazes de prever os custos e trabalhar
com cronogramas mais prximos da realidade, aumentando
assim a rentabilidade do seu negcio.
Podemos dizer inclusive que no possvel avaliar se uma
aplicao estvel, sem conhecer a frequncia que uma equipe 2. Question (Questes)
de teste encontra defeitos, independente da fase que seu pro-
jeto se encontra. Dessa forma, possvel tambm quantificar
en gen haria
o desempenho da rea de desenvolvimento, avaliando, por
exemplo, se ao corrigir um erro so inseridos mais cinco ou
se o problema base foi definitivamente resolvido. Esse tipo
de levantamento auxiliar a identificar reas de risco que
necessitaro de mais testes e mais ateno.
Medir o processo de teste no ajuda apenas a medir a efici-
ncia de uma equipe de testes, mas tambm a encontrar falhas
no processo como um todo.
Por onde comear?
Mtricas ajudam a medir o progresso e a qualidade de um
esforo de teste de software. Elas tambm podem ser aprovei-
tadas para avaliar o desempenho do passado, o estado atual
e a prever tendncias futuras. Mtricas eficazes so simples,
objetivas, mensurveis e significativas e tm dados facilmente
coletados.
Para iniciar a medio, o gestor ou o responsvel por essa
atividade precisa entender os processos que envolvem a cria-
o de mtricas:
Identificar a Mtrica: Inicialmente preciso identificar
os objetivos a serem alcanados, seno correr o risco de
perder tempo e dinheiro na medio de itens desnecessrios.
O programa de mtricas deve ser conduzido e revisado pela
pois a coleta de mtricas uma atividade intensa que precisa
de fontes de dados certos e aceitao por toda a organizao
(e no apenas de teste);
Identificar o que pode ser medido: Identificar dentro de um
processo de teste o que pode ser medido de forma objetiva, essa
informao poder ser usada como base para iniciar a definio
de todas as mtricas. Pedir ajuda a todos participantes de TI
ajudar a ter uma mtrica mais eficaz;
Frequncia: Estabelecer qual informao ser possvel ras-
trear e qual a frequncia que essas mtricas sero geradas.
Uma tcnica que pode ser utilizada para auxiliar na medio
a Goal-Question-Metric (GQM). A ideia bsica derivar m-
tricas de software a partir de perguntas e objetivos.
O processo de definio de um programa de mtricas deve
ser baseado nas necessidades de informao de cada nvel
organizacional. Isto obtido a partir do levantamento de in-
formaes junto s reas interessadas. O paradigma do GQM
foi proposto como uma abordagem orientada a objetivos para
a medio de produtos e processos. Essa metodologia baseia-se
na premissa de que, para ganhar uma medida prtica, deve-se
primeiro entender e especificar os objetivos dos artefatos de
software sendo medidos e os objetivos do processo de medio.
Para que isso seja feito, preciso responder as trs perguntas
bsicas dessa tcnica:
1. Goal (Objetivo)
Quais so as metas/objetivos?
Exemplo: Melhorar a eficincia dos testes manuais?
Quais questes se deseja responder?
Exemplo: Qual a eficincia dos testes manuais?
Edio 68 - Engenharia de Software Magazine 47
3. Metric (Mtricas)
Quais mtricas podero ajudar?
Exemplo: Nmeros de Bugs encontrados em QA X Nmero
de Bugs encontrados em Homologao/Produo.
Independente da tcnica utilizada muito importante des-
tacar que no coerente a tomada de decises levando como
base unicamente as mtricas. Deve-se tambm tomar cuidado
com mtricas difceis, pois devem ser analisadas com
cuidado,
alm dos modelos utilizados para a apresentao de dados que
devem ser autoexplicativos.
Mtricas chave para Teste de Software
A rea de teste de software a responsvel por apresentar
a vulnerabilidade de um software, assim como sua eficcia.
Desta forma, utilizar a mtrica certa fundamental. Abaixo
so listadas algumas mtricas que permitiro medir vrios
aspectos de eficincia:
1. Acompanhamento dos Casos de Testes: Acompanhar os
casos de testes planejados x os testes executados dentro do tem-
po estipulado, considerando fatores externos que podem ter
influenciado na execuo. O objetivo dessa mtrica identificar
de perto o progresso dos testes e visualizar facilmente qualquer
desvio, permitindo tomar aes iniciais sobre qualquer indcio
de que a atividade de teste est atrasada. Essa mtrica ajuda a
identificar a eficincia de um analista de teste;
2. Acompanhamento dos Defeitos: Acompanhar os bugs iden-
tificados pelo analista de teste um bom indicador, preciso
apenas tomar certo cuidado com essa mtrica, pois poucos
defeitos nem sempre indicam uma boa qualidade do software,
podem significar uma m cobertura dos testes, ou uma m
compreenso do analista de teste no momento da execuo.
Mas tambm pode sinalizar um bom desenvolvimento e o
software realmente estar com uma tima qualidade;
3. Defeitos por Severidade: Essa mtrica complementar m-
trica anterior (Acompanhamento dos Defeitos), pois podemos
ter softwares distintos com a mesma quantidade de bugs, ou
quantidade aproximada de bugs, mas ao medirmos a severida-
de dos defeitos ser possvel identificar que para um software X
que tem, por exemplo, 50 bugs, 30 so de prioridade baixa, 25 de
prioridade mdia e cinco de prioridade alta. Ao mesmo tempo
podemos ter um software Y com os mesmos 50 bugs, porm
com 20 bugs bloqueantes, 15 bugs de prioridade alta e 15 de
prioridade mdia. Nesse caso, embora a quantidade final seja
a mesma, a severidade indica claramente a deficincia de um
deles, ento nmeros sem a severidade no sero um indicador
suficiente para apontar a realidade de cada projeto;
4. Casos de Teste por Prioridade: Alguns casos de teste podem
ser mais importantes do que outros, portanto, comum atribuir
prioridades / pontuao para eles. Quando usamos essas
pontuaes prioridades / teste, pode-se fornecer uma manei-
ra mais precisa para controlar o andamento do teste de uma
forma normalizada. Com base nos resultados dos testes
possvel identificar a importncia em um teste de prioridade
maior que falhou com outro de uma prioridade menor. Essa
48 Engenharia de Software Magazine - Teste de Software: Avaliando a eficincia da equipe
medio auxiliar quando testes de prioridade alta falharam
mais do que o esperado;
5. Tempo dispensado em cada Fase de Teste: A medio do
tempo utilizado pela equipe de teste em cada fase do projeto
fundamental. Essa medida auxiliar a identificar fases com
maior tempo gasto e direcionar aes de melhoria para trazer
otimizao na execuo. Por exemplo, se a mtrica apontar que
a atividade Gerao de Massa de Testes est levando muito
tempo, algumas aes de melhoria podem ser realizadas a
fim de otimizar essa atividade, que pode ser desde a criao
de uma equipe exclusiva para gerao de massa de testes, at
mesmo alocar outro recurso de teste para auxiliar esse recurso
nesse projeto por determinado tempo;
6. Produtividade: Mtricas de produtividade combinam
vrias medidas e parmetros com esforo gasto no soft-
ware, elas ajudam a descobrir a capacidade da equipe.
Cada empresa tem sua prpria frmula para capturar as
mtricas de produtividade, algumas utilizam contagem
de erros, nmero de testes escritos x tempo, o nmero de
testes executados, % de testes automatizados em compa-
rao com os testes manuais e % de cobertura de cdigo.
O maior problema de todas as medidas de produtividade
que elas s fazem sentido se no forem ignoradas variveis
dependentes, como: motivao, ferramentas, habilidade
inerente, processos e at mesmo o ambiente fsico. Ou seja,
no existe uma frmula simples para medir o desempenho
de um indivduo e muitas vezes elas so muito subjetivas,
e influenciadas por fatores externos;
7. Eficincia dos Testes X Erros de Produo: Erros encon-
trados no ambiente de produo so reportados por usurios
ou clientes e podem indicar problema na qualidade do teste.
Isto por que preciso considerar que no existe zero bugs,
por mais que uma equipe se esforce, nunca ser possvel
entrar com um software em produo com nenhum defeito.
Mas existem situaes que indicam o contrrio, que bugs
de severidade alta so encontrados e isso precisa ser me-
dido. Para realizar essa medio preciso excluir os bugs
detectados pelos analistas de testes no ambiente de teste e
que foi decidido que no seria solucionado para entrada em
produo. Para calcular essa mtrica, preciso ter um siste-
ma de rastreamento de bugs para todos aqueles encontrados
durante a fase de testes, alm de ter que se definir uma forma
de rastrear bugs encontrados em produo. A maioria das
organizaes possui um help-desk ou suporte tcnico com
esses dados, por isso geralmente apenas uma questo de
descobrir como separar e agrupar as informaes das duas
bases de dados (muitas vezes distintas). preciso tambm
definir uma janela de tempo, isso depende de quanto tempo
leva para os seus clientes ou usurios para utilizar ao menos
80% das funcionalidades da aplicao em produo, definido
isso possvel realizar um comparativo dos bugs detectados
em produo X bugs detectados durante os testes e avaliar se
a quantidade detectada em produo muito elevada, ou se
os bugs so crticos e com isso ter uma medida da eficincia
da equipe de testes envolvida.

Esses so alguns exemplos de mtricas que podem ser uti-
lizados para medir e analisar a eficincia de uma equipe de
testes.
Por que mtricas de testes podem falhar
Mtricas de teste so utilizadas para a melhoria contnua,
mas muitas organizaes no so bem sucedidas quando o
desejado medir algo. Em sua maioria gostam de ver mtricas,
mas se queixam que as equipes no sabem medir o trabalho
que realizam.
Mas o que exatamente est faltando para essas empresas
que no conseguem medir o prprio trabalho? Tcnicas e
definio de mtricas esto disponveis em diversas fontes,
qual a grande dificuldade na medio? Veja trs grandes erros
na hora de medir:
1. Relatrios de Mtricas focados apenas para o trabalho
interno de testes: Nessas situaes esto esquecendo empresas
terceirizadas de testes envolvidas no projeto. Aqui o respon-
svel pela mtrica quer mostrar o quo boa a sua equipe, se
esquecendo de monitorar o trabalho como um todo para ter o
cenrio real. possvel sim mostrar a eficincia de sua equipe,
desde que seja uma mtrica agregada da mtrica master que
mede o esforo total de ambas as equipes de testes, interna (da
prpria organizao) e externa (funcionrios terceirizados);
2. Relatrios com dados vagos: Dados no interessantes aos
envolvidos no processo e nas partes interessadas. Mtricas
precisam dizer algo, precisam atender a necessidades dos
envolvidos para que os mesmos tomem as aes necessrias
para que a melhoria acontea;
3. Relatrios que focam apenas o trabalho da equipe de teste:
mtricas devem sim focar o trabalho da equipe de testes, mas
tambm devem trazer dados externos que influenciam nesse
trabalho, por exemplo: posso ter uma mtrica de casos de tes-
tes executados x casos de testes que falharam, esse um tipo
de mtrica que ir interessar muito o gestor de testes, mas se
acrescentarmos a isso a quantidade de casos que falharam x
bugs detectados, isso ajudar o gestor de desenvolvimento a
identificar uma funcionalidade que falhou e a partir dela foram
gerados muitos erros.
Embora o foco seja medir o trabalho de teste e assim analisar
sua eficincia, difcil avaliar de forma separada a eficincia
de uma equipe teste sem avaliar todo o processo envolvido
para que o teste acontea. Por esse motivo, muitas vezes ser
necessrio no meio das mtricas de teste, ter mtricas que
envolvem o desenvolvimento.
Fatores que afetam a eficincia dos testes
O objetivo principal do teste de software revelar defeitos
de forma eficiente (ou seja, o mnimo de tempo e de custo) e
eficaz (ou seja, detectar o mximo de falhas). Leva tempo para
entender o que testar, para gerar casos de teste, para executar
o conjunto de testes e analisar os resultados. E no decorrer
desse fluxo podem surgir fatores que atrapalhem a eficincia
deles, abaixo cito alguns:
en gen haria
Falha no Processo: Existe um processo? Ele est claro para
todos? Ele seguido? Ter um processo definido primordial
para que as atividades fluam com maior naturalidade, pois
sem ele as pessoas tendem a querer pular fases, ultrapassar
barreiras, o que no saudvel para ningum. Alm de ter um
processo, ele precisa ser divulgado e cobrado de todos os envol-
vidos. A ausncia de uma parte do processo pode influenciar
diretamente os testes, seja ela qual for, desde a falta de uma ata
de reunio at requisitos que so passados verbalmente. Cada
detalhe importante para o analista de teste envolvido, se um
processo existe, ele precisa ser seguido, para assim auxiliar a
equipe de teste a garantir a qualidade da entrega;
Ausncia do Documento de Requisitos: Em situaes em
que o documento de requisitos no existe, ou que novos re-
quisitos foram solicitados no decorrer do desenvolvimento do
software e no foram documentados, considerando que o pla-
nejamento dos testes j aconteceu, como o profissional de testes
ter tempo para inserir novas condies de testes? Ser que ele
no teve que fazer rapidamente? Ser que ele foi informado
dessas alteraes de requisitos? Qual foi a antecedncia que
isso aconteceu? Tudo precisa ser levado em conta, o documento
de requisitos a alma do software e se ele no existe, ou est
desatualizado, isso ir influenciar diretamente na eficincia
dos testes, pois se a equipe de testes no consegue realizar um
planejamento adequado, ela no tem como testar um software
da forma esperada e nem com a eficincia desejada;
Excesso de Detalhes: Enquanto boa documentao do pro-
jeto um fator positivo, tambm verdade que produzir uma
documentao detalhada demais pode ser algo negativo, um
bom exemplo para isso no momento de criar casos de testes.
Casos de testes com muito detalhe ao invs de ajudar pode at
atrapalhar, mas tudo vai depender do cenrio da empresa. Se
considerarmos que quem preparou os casos de teste quem
executar, o detalhamento exagerado nessa situao pode at
ser considerada uma ineficincia, casos de testes objetivos, que
indicam a situao a ser gerada, com os detalhes necessrios,
costumam ser mais eficientes;
Presso do Tempo: A presso do tempo outro fator a ser
considerado.A presso no deve ser uma desculpa para as-
sumir riscos indevidos, no entanto, uma razo para tomar
decises cuidadosas e planejar de forma inteligente todo o
processo de teste. Entregar um projeto dentro de um tempo
estipulado, antes da execuo adequada s para cumprir pra-
zos no indicado, essa atitude poder fazer com que o teste
no seja feito de forma eficiente;
Resultados: Os resultados dos testes influenciam direta-
mente a eficincia do analista de teste envolvido na execuo.
Quando um defeito identificado e comea a passar por vrios
ciclos de correes, retestes, reaberturas, isso poder levar a um
esforo muito maior do que o esperado, pois aps a correo
de um bug que foi e voltou muitas vezes, as chances da corre-
o ter afetado outras funcionalidades do sistema grande e
nesses casos ser necessrio retestar partes j testadas, o que
desmotiva e dispersa o analista de teste envolvido. Com isso,
as chances de ocorrerem erros nesse processo so grandes.
Edio 68 - Engenharia de Software Magazine 49

Esses so alguns exemplos de fatores que podem igualar
um bom desempenho de um profissional de testes. preciso
cautela na hora de analisar uma equipe e sempre considerar
a particularidade do ambiente ao qual ela est inserida e a
realidade de cada organizao.
Como melhorar a eficincia do teste
A eficincia de teste medida dividindo-se o nmero de
defeitos encontrados em um teste pelo esforo necessrio para
realizar o teste. Alm disso, as medidas de eficincia de teste
no s podem mostrar os custos de encontrar defeitos, tais
medidas tambm podem determinar os custos relativos ao
encontrar defeitos em diferentes fases.
Um processo de teste eficiente aquele em que o produto
atinge um nvel adequado de qualidade com o menor cus-
to. Para alcanar o teste eficiente, investigaes devem ser
feitas para encontrar tcnicas que aumentem a eficincia do
teste e removam gargalos no processo. Para realizar uma
avaliao do cenrio da organizao preciso fazer alguns
questionamentos:
So utilizadas tcnicas de testes? Quais so as tcnicas
utilizadas?
Os profissionais de testes so qualificados? Qual o tempo
mdio de experincia de cada um?
O tamanho da sua equipe compatvel com a quantidade
de projetos que a empresa demanda?
Em que fase do projeto a equipe de teste envolvida?
O processo de teste est aderente ao desenvolvimento do
software? Ele funciona?
A equipe de teste independente ou subordinada ao gestor
da rea de desenvolvimento?
Esses questionamentos ajudaro no somente a encontrar
problemas dentro da equipe, mas tambm problemas organi-
zacionais, que influenciam diretamente no desempenho das
atividades. Muitas vezes, uma equipe ineficiente no significa
uma equipe com m vontade ou com m qualificao, mas
tambm uma equipe com muita influncia externa com itens
que precisam ser solucionados para que possa trabalhar de
forma independente e com a estrutura necessria para realizar
o seu papel de forma adequada. Existem duas frmulas que
auxiliaro a calcular a eficincia dos testes, conforme citado
no Guia ISTQB:
Eficincia teste = (nmero total de defeitos encontrados em
unidade + sistema + integrao) / (nmero total de defeitos
encontrados em unidade + integrao + sistema + testes de
aceitao do usurio);
Eficincia Teste = (Nmero de defeitos resolvidos / N total
de defeitos enviados) * 100.
Assim que identificado o problema com base nas respostas
dadas acima, a busca deve ser por corrigir ou aprimorar tc-
nicas utilizadas, diminuindo assim o custo e aumentando a
eficincia. Uma tcnica muito utilizada para diminuir custos
50 Engenharia de Software Magazine - Teste de Software: Avaliando a eficincia da equipe
a automao de testes, mas preciso tomar cuidado, pois
no comeo ela gera mais gastos, considerando que o analista
envolvido precisar ficar mais tempo focado para automatizar,
ou ento em alguns casos ser necessrio ter outro analista de
teste dedicado apenas em automao.
O que faz um bom testador de software?
O teste essencial em qualquer projeto de software, porm
para ter testes bem sucedidos, voc precisa de testadores talen-
tosos. Infelizmente, muito difcil encontrar bons testadores,
em parte porque possveis talentos se vo, pois na comunidade
de software muitos consideram testar uma atividade indicada
para pessoas com habilidades analticas e de resoluo de
problemas menores.
Um testador tem que ser um profissional completo, justa-
mente por precisar ter a capacidade de avaliar o trabalho de
diversos profissionais. Abaixo apresentamos uma relao
das caractersticas que precisam ser consideradas na hora de
avaliar e contratar um profissional da rea de testes:
1. Paixo pelo que faz: encontrar bugs aparentemente imposs-
veis de serem encontrados, em combinaes que provavelmen-
te seriam feitas apenas pelo cliente final, traz uma satisfao
enorme para quem trabalha nessa rea, e no alegria por ter
identificado a falha de outro profissional, mas por ter detec-
tado um erro que poderia ir para o ambiente de produo e
causar transtornos;
2. Habilidade tcnica: deve-se ter habilidades de codificao o
suficiente para entender o sistema em teste, se comunicar com
os desenvolvedores e escrever testes automatizados. Isso no
indica que ele precisa ser um programador, mas que precisa
ter um conhecimento tcnico bsico necessrio para ser usado
em momentos oportunos. Se falarmos de automao, esse co-
nhecimento precisa ser um pouco maior, j que muita coisa de
cdigo precisa ser escrita e entendida na hora de automatizar.
importante destacar que ter habilidade tcnica no significa
ter mais conhecimento em cdigo do que em teste, para ser um
bom analista de teste funcional o ideal que haja um equilbrio
entre as duas coisas;
3. Capacidade estratgica: Para um testador ser eficiente em
sua funo, ele precisa ser capaz de analisar situaes de neg-
cio e simular todos os cenrios possveis. Ele deve ser capaz de
desenvolver um mapeamento lgico baseado nas relaes entre
os elementos apresentados e a realidade do cliente, criando
assim combinaes para evitar um bug em produo;
4. Capacidade de trabalhar sem superviso direta: A ne-
cessidade de poder tomar aes de forma independente e
rapidamente, a identificao de uma necessidade tcnica ou
de negcios relacionados com o esforo de teste de software,
e a capacidade de saber quais as medidas tomar sem a ne-
cessidade de aprovao gerencial (e tambm a capacidade de
saber quando no avanar sem um gesto) uma habilidade
essencial;
5. Capacidade de se comunicar: possuir habilidade de comu-
nicao verbal e escrita e essa comunicao deve ser eficiente,
clara, sem julgamento alheio, baseada em fatos e dados. Deve

saber relatar um bug de forma concisa, ter a habilidade de fazer
um planejamento coerente, saber responder um e-mail que
no gere ambiguidade de informaes e conseguir escrever
relatrios para a gesto;
6. Capacidade na estratgia de negcios: Entre as caracters-
ticas dos grandes testadores, est a habilidade de entender a
estratgia global dos negcios da empresa em que atua, per-
mitindo assim que identifique pontos fortes e fracos de um
sistema de software estratgico.
No existe uma frmula simples para medir e analisar o
desempenho de um indivduo, mas primordial para o apri-
moramento e acompanhamento do profissional gerenciado que
uma avaliao baseada em mtricas seja feita. Avaliaes de de-
sempenho individuais so muitas vezes um pouco subjetivas,
en gen haria
e influenciadas por fatores externos, tais como: motivao, fer-
ramentas, habilidade, processos e at mesmo o ambiente fsico.
Realizar a coleta dos dados estratgicos auxiliar nas decises,
mas no deve ser a nica medida utilizada para avaliar, o ideal
fazer a juno desses dados com os fatores externos citados,
pois eles influenciam no resultado final.
Voc gostou deste artigo?
D seu voto em www.devmedia.com.br/esmag/feedback
Ajude-nos a manter a qualidade da revista!
Edio 68 - Engenharia de Software Magazine 51
Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros
BPMN e a Modelagem de Processos de
Negcio
Edson A. Oliveira Junior
edson@din.uem.br
Professor de Engenharia de Software na Uni-
versidade Estadual de Maring (UEM). Doutor
em Cincia da Computao pelo Instituto de
Cincias Matemticas e de Computao (ICMC) ltimos anos, diversas empresas tm
da Universidade de So Paulo (USP).
Maicon Giovane Pazin
maiconpazin@gmail.com
Graduado em Informtica pela Universidade Es-
tadual de Maring. Trabalha com sistemas para
Web, com experincia em tecnologias como
PHP, JavaScript, CSS, HTML5 e Java.
Felipe Pereira Perez
fpproducoes@gmail.com
Graduado em Cincias da Computao pela
Universidade Estadual de Mato Grosso do Sul
(UEMS), mestrando em Cincia da computao
pela Universidade Estadual de Maring.
Jaime William Dias
jaimewdias@gmail.com
Graduado em Sistemas de Informao pela Uni-
versidade Paranaense. Especialista em Progra-
mao Orientado a Objetos pelo Centro Univer-
sitrio Cesumar.Trabalha com sistemas para Web
e Desktop, com experincia em tecnologias como
Delphi, PHP, JavaScript, CSS, HTML5 e JAVA.
52 Engenharia de Software Magazine - BPMN e a Modelagem de Processos de Negcio
P
ara um negcio ter sucesso, todas
as atividades de uma organizao
devem ser executadas de forma
correta para se atingir um objetivo. Nos
buscado formas de analisar e melhorar
essas atividades. O conceito de gerencia-
mento dos processos de negcios surgiu
como uma soluo que une a gesto de
negcios e tecnologia da informao
com foco na otimizao dos resultados
das organizaes atravs da melhoria
desses processos.
O processo de negcio define todas as
atividades de uma empresa e as relaes
que existem entre elas. Um efetivo geren-
ciamento dessas atividades contempla-
do com diversos benefcios, como a dimi-
nuio dos custos operacionais, a melhor
organizao das operaes realizadas e
o aumento na qualidade dos produtos
criados ou servios prestados.
A representao de processos de
negcio realizada com o intuito de
entender e melhorar a estrutura de uma
organizao e suas atividades. Dessa
Fique por dentro:
Neste artigo ser apresentado um estudo sobre
os conceitos relacionados definio, gerencia-
mento e evoluo de processos de negcios que
so formados pelo conjunto de atividades ou
tarefas estruturadas para alcanar os objetivos
de qualquer organizao. Tambm ser apre-
sentada a modelagem de um processo de neg-
cio que demonstra o uso de uma das principais
notaes utilizadas para esta finalidade. Esse
tema til para gerentes, analistas e gestores
de negcios, alm de estudantes e engenheiros
interessados em obter conhecimentos sobre
processos de negcio e as tarefas relacionadas
ao gerenciamento e evoluo dos mesmos em
busca de melhorias.
forma, possvel distinguir todos os
processos realizados bem como os
participantes que a executam, recursos
utilizados e produzidos e informaes
relacionadas.
A modelagem de processo de negcio
a representao dos processos na
forma de um modelo, que identifica e
especifica atravs de tcnicas e nota-
es especficas. Os modelos devem
ser representados de forma intuitiva e
 en gen haria

simplificada para permitir documen- colaborao entre organizaes. Na em todas suas fases. O GPN deve ser
tao e entendimento dos processos da Figura 2 pode ser observado o PN de executado para se alcanar trs pontos
organizao. uma agncia de viagens, bem como, o PN muito importantes para uma empresa,
de uma companhia area e a interao tais como: clareza na direo estra-
Processos de Negcio entre elas. Para a agncia de viagens o ato tgica, alinhamento dos recursos da
Processo de Negcio (PN) um con- de contatar a companhia area apenas organizao e crescente disciplinas nas
junto de um ou mais procedimentos ou uma atividade de seu PN. Por outro lado, operaes dirias.
atividades relacionadas, que quando em a companhia area envolve diversas ati- O GPN atua em diversos nveis de
conjunto realizam o objetivo de negcio vidades com restries e a necessidade abstrao, conforme a Figura 3. No nvel
especificado de uma organizao. Por de uma comunicao com a agncia mais alto onde so definidas todas as
meio da execuo dos PN a organizao para caso no haja vagas e precisem ser estratgias de negcio da organizao.
est realizando seu propsito. revistas as datas da viagem. A partir delas so obtidas as metas, que
O gerenciamento do PN dentro de uma As atividades de um PN podem ser so os alvos que sero alcanados para
organizao a beneficia em diversos classificadas em trs tipos. As atividades que a estratgia seja realizada. Para que
sentidos. Com um bom gerenciamento manuais, que so realizadas sem auxlio isso acontea necessrio que todos os
possvel ter a descrio precisa e no de sistemas de informao. As ativi- envolvidos exeram as atividades de-
ambgua das atividades, maior eficincia dades de interao com o usurio, que signadas. Dessa forma, essas atividades
na coordenao do trabalho, obteno dependem de um colaborador apoiado devem ser descritas atravs de um PN or-
precisa do andamento dos processos e a um sistema de informao e as ativi- ganizacional. Em um nvel abaixo est o
padronizao das atividades. dades de sistema, que so realizadas de PN operacional que especifica as ativida-
O gerenciamento adequado do PN no foram autnoma, sem a interao com des, seus relacionamentos e dependn-
apenas proporciona a reduo de custos o usurio. cias, conforme exemplo apresentado na
e erros na execuo dos processos, mas Figura 1. Para que todo o PN seja execu-
tambm aumenta o controle sobre eles, re- Gerenciamento de Processos de tado necessrio sua implementao.
sultando na maior qualidade da execuo, Negcio Como j apresentado, o PN o meio que
nos resultados e assim na organizao O Gerenciamento de Processos de Ne- integra todas as atividades realizadas em
como um todo. O PN pode ser relaciona- gcio (GPN) compreende em sua defini- uma organizao. O GPN acontece efeti-
do forma como a organizao atinge as o, o aperfeioamento e administrao vamente quando todas essas atividades
metas propostas em seu negcio, sendo dos PNs de determinada organizao so realizadas em total sincronia.
a meta o objetivo central da organizao.
Para que essa meta seja atingida, diversas
atividades devem ser realizadas, esse
conjunto de atividades define o PN.
Para uma organizao executar uma
determinada atividade, como entregar
um produto, existem diversas tarefas
relacionadas. Isso pode incluir o rece-
bimento do material, fabricao, con-
Figura 1. PN de uma agncia de Viagens
trole de qualidade, estoque, etc. O PN
descreve essas atividades, bem como
sua ordem de execuo e as restries
provenientes delas.
A Figura 1 apresenta o PN de uma
agncia de viagens que possui o objetivo
de oferecer pacotes tursticos ao cliente. A
primeira atividade obter junto ao cliente
o destino para o qual ele deseja viajar.
Aps isso so executadas atividades como
contatar uma companhia area, o hotel e
com uma empresa de aluguel de veculos.
Por fim, aps definido o pacote turstico,
ele enviado para aprovao do cliente
e o PN da agncia encerrado.
Um benefcio do gerenciamento dos
PN a representao adequada da Figura 2. PN Interorganizacional

Edio 68 - Engenharia de Software Magazine 53


Figura 3. Nveis do GPN
Modelagem de processos de negcio (MPN)
A Modelagem de processos de negcio (MPN) geralmente
realizada por analistas de negcios e gestores com o intuito de
analisar e melhorar os processos e a qualidade dos produtos
ou servios de uma organizao. Para isso, necessrio ter um
conhecimento de como esses processos esto estruturados.
Utilizando tcnicas e notaes de MPN possvel identificar
as atividades realizadas, os participantes envolvidos, os re-
cursos consumidos ou produzidos, e quais informaes so
compartilhadas. Com a modelagem pronta, possvel ampliar
o entendimento e possveis melhorias do negcio, identificar
atividades candidatas a automao, definir sistemas de suporte
ao negcio e identificar oportunidades de terceirizao caso
seja uma soluo interessante para a empresa.
MPN pode ser entendido como um conjunto de modelos
de atividades e restries de execuo entre elas. A MPN
refere-se representao efetiva dos processos, em termos de
um modelo, usando uma linguagem de processos. O termo
modelagem de processo de negcio usado para caracterizar
a identificao e especificao dos processos de negcio.
O propsito da modelagem de processo fornecer uma
perspectiva simplificada da estrutura do negcio, com um
meio para atingir o fim, permitindo comunicar, documentar
e entender as atividades da organizao. Existem diferentes
usos para a MPN:
Melhor representar ou entender como uma organizao
funciona (ou alguma parte dela);
Usar/explicar o conhecimento adquirido e a experincia
para usos futuros;
Racionalizar e assegurar o fluxo de informaes;
Projetar ou reprojetar e especificar uma parte da organizao
(aspecto funcional, comportamental, informacional, organiza-
cional ou estrutural);
Analisar alguns aspectos da organizao (anlise econmica,
organizacional, quantitativa, qualitativa, layout e outras);
Si mu la r o compor ta mento de a lg u mas pa r tes da
organizao;
Realizar melhores decises sobre as operaes e organizao
da empresa;
Controlar, coordenar ou monitorar algumas partes da orga-
nizao (isto , alguns processos).
54 Engenharia de Software Magazine - BPMN e a Modelagem de Processos de Negcio
Para a modelagem de processos de negcio utiliza-se a
cadeia de eventos de uma organizao desde a compra de
suprimentos, vendas, retorno de produtos, etc. Nesse contexto,
informaes e documentos so utilizados pelos analistas de
negcios e gestores, gerando um fluxo de como as atividades
so realizadas, desde seu incio at alcanar o objetivo do
processo. Para desenvolver um projeto de modelagem de
processos, so necessrios os seguintes itens:
Mtodo: sequncia de passos para levantamento e modela-
gem de informaes;
Meta-modelo: informaes a serem modeladas;
Notao: smbolos e regras para representar as informaes;
Ferramenta: apoio computacional para documentao das
informaes.
Programas de gerenciamento de mudanas so tipicamente
utilizados para promover melhorias nos processos de negcios.
Com os avanos na tecnologia de fornecedores de plataformas
de grande porte, a viso de modelos de PN tornam-se ple-
namente executveis (e capazes de simulaes e engenharia
round-trip) chegando cada vez mais perto da realidade.
Modelos de processos de negcio
O termo Modelo de Negcio usado para uma ampla gama
de descries formais e informais para representar aspec-
tos centrais de um negcio, incluindo o motivo, as ofertas,
as estratgias, infraestrutura, estruturas organizacionais,
prticas comerciais, e os processos operacionais e polticos.
Os modelos de processos de negcio necessitam sempre de
uma fundamentao formal. As razes conhecidas incluem:
modelos formais no permitem qualquer ambiguidade; e mo-
delos formais elevam o potencial de anlise. desejvel que um
modelo de processo de negcio possa ser entendido por todas
as pessoas envolvidas da maneira mais simples possvel. Isso
pode, por exemplo, ser alcanado atravs do uso de represen-
taes grficas.
Os objetivos de modelos de processos de negcio se resu-
mem em seis perguntas sobre a organizao, cujas respostas
produzem grandes insumos que auxiliam na construo do
modelo da organizao e seu negcio. A Figura 4 apresenta
essas perguntas, que so: O que feito? Quem faz? Quando?
Onde? Por qu? Como?
Para qualquer MPN, alguns elementos so essenciais para a
representao completa do modelo de negcio de uma orga-
nizao. Esses elementos so:
Evento: acontecimento que inicia a execuo (inicial), afeta
o comportamento (intermedirio) ou conclui um processo
(final);
Atividades: conjunto de aes realizadas;
Atores: responsveis pelas atividades;
Entradas/Sadas: insumos necessrios para o processo ser
executado (entrada) e gerado ao final do processo (sadas);
Regras: restries que causam dependncias entre atividades;
Recursos: entidade que pode ser fsica, abstrata ou informa-
o que faz parte da realizao da atividade.
 en gen haria

Notaes e ferramentas
O processo de identificao de melhorias
por meio da MPN se torna mais fcil com
o envolvimento da Tecnologia da Informa-
o (TI). Atualmente, a utilizao de TI
o principal passo para o desenvolvimento
de um modelo de processo de negcio.
Por outro lado, os modelos de processos
de negcio podem ser to complexos que
o uso de uma linguagem formal para a
sua especificao a nica maneira de
garantir que as interpretaes alternativas
sejam eliminadas. Dessa forma, existe a
necessidade de uma interao contnua
entre tecnologia e linguagens formais para
automatizar o processo de modelagem de Figura 4. Perguntas que auxiliam a construo da viso da organizao [5]
processos de negcios.
Contextualizando, a MPN utilizada com o objetivo de e abstrata um processo de negcio. Redes de Petri possuem
facilitar a visualizao e entendimento de um processo de modelos bem definidos e sem ambiguidade;
negcio por meio de uma representao grfica. A modelagem Redes de Workflow: constituem uma classe especfica de
desses processos pode ser realizada em diversos nveis, usando redes de Petri adequadas para expressar modelos de proces-
diferentes tcnicas. Algumas abordagens para modelagem de sos de negcio. Essa abordagem melhora a rede de Petri com
processos de negcio so: conceitos e 19 notaes que facilitam a representao de pro-
Redes de Petri: possui diferentes classes (numerosas ex- cessos de negcios. Essa abordagem fornece ainda mecanismos
tenses). Essa notao permite especificar de maneira formal avanados de modelagem;

Edio 68 - Engenharia de Software Magazine 55

 WS-BPEL: mais do que uma notao para a modelagem, o O BPMN atualmente uma notao padro para modelagem
WS-BPEL uma linguagem para a especificao e execuo de de processos de negcio e tem como finalidade prover recursos
processos de negcio usando servios eletrnicos; para que a modelagem possa ser feita. O objetivo da metodologia
BPMN (Business Process Modeling Notation): desenvol- BPMN projetar solues empresariais completas, abordando e
vida sob a coordenao da OMG (Object Management Group), modelando de forma integral os seguintes aspectos:
combina as vantagens de ser simples, utilizar uma notao Processos de Negcio (Cadeias de atividades);
conveniente e semntica clara. Regras do Negcio (Polticas; diretrizes, etc.);
Informao (Grupos de dados; Elementos de dados; Objetos
Ferramentas Utilizao entidades e atributos);
Microsoft Visio 18.2 % Tecnologia da Informao (Sistemas aplicativos; estrut. har-
dware; Comunicao, etc.);
Itp-Commerce Process Modeler 7.8 %
Recursos Humanos (Pessoas e estrutura organizacional);
Sparx Systems Enterprise Architect 6.9 % Mtrica de Performance (Ciclos de tempos; Volumes; Valo-
Visual Paradigm Visual Architect 6.2 % res, etc.).
Telelogic System Architect 5.7 %
A Tabela 1 apresenta a lista das ferramentas mais populares
Intalio BPMS 5.0 %
que suportam BPMN. Conforme os dados da tabela, a Microsoft
ILOG Jviews 3.8 % Visio com os stencils de BPMN a ferramenta mais popular
IDS Scheer ARIS 3.3 % para modelagem de processos de negcio. Essa ferramenta
Casewise Corporate Modeler 3.3 % seguida pela Itp-Commerce, que possui um plug-in do Visio
Holocentric Modeler 2.8 %
que estende sua capacidade com um mecanismo de simulao,
atributos adicionais e opes de anlise.
iGrafx FlowCharter 2.4 %
MagicDraw 1.9 % Notaes e ferramentas
Inhouse solution 1.9 % Para muitas organizaes, a modelagem do processo de ne-
Savvion Process Modeler 1.4 % gcio essencial para o entendimento de fluxos complexos de
negcios. Como um exemplo de utilizao, foi modelada neste
Tibco Business Studio 1.4 %
artigo a integrao de alguns mdulos de um sistema real
Appian BPM Suite 1.4 % criado para a prefeitura de uma cidade utilizando o BPMN.
Outros 15.6 % O exemplo inclui os mdulos de compra, licitao, material,
Vrios 10.9 % patrimonial e contbil com o objetivo de entender todos os pas-
sos de aquisio de algum material ou bem para a prefeitura.
Tabela 1. Lista de ferramentas para BPMN e o grau de utilizao [6] A ferramenta utilizada para a modelagem foi o Astah

Figura 5. Exemplo de MPN do fluxo de compra de um sistema real para a prefeitura de uma cidade

56 Engenharia de Software Magazine - BPMN e a Modelagem de Processos de Negcio


Community desenvolvido na plataforma Java para modela-
gens baseadas na UML. A Figura 5 apresenta a modelo do
exemplo.
No exemplo apresentado, o ponto de partida do fluxo pode
ser iniciado em qualquer setor da prefeitura ao solicitar-se
qualquer tipo de material, registrando-se assim uma solicitao
de compra. O setor de licitaes gerencia as solicitaes a fim
de realizar as licitaes necessrias para suprir as necessidades
dos setores da prefeitura. Algumas modalidades de licitaes
exigem um empenho prvio para serem realizadas, outras s
sero empenhadas depois da requisio de compra, aps a
licitao ser homologada. A requisio de compra feito pelo
setor que solicitou o material e representa o reconhecimento da
dvida pela prefeitura. Aps uma solicitao formal de compra
pela prefeitura, o fornecedor tem a garantia de compra e pode
fornecer os produtos.
O setor de materiais tem a responsabilidade de receber os
produtos e fazer seu controle de estoque e almoxarifado.
Neste momento realizada a liquidao do empenho, ou
seja, na entrega do produto entregue tambm a nota fiscal
da empresa fornecedora. Depois de liquidado um empenho
a prefeitura pode efetuar o seu pagamento. Ao efetuar uma
liquidao qualquer acionado o setor patrimonial que alm
de controlar os bens patrimoniais da prefeitura dispara eventos
contbeis para a contabilidade, onde tambm feito o balano
patrimonial da prefeitura.
O setor contbil esta presente na maioria dos fluxos da
prefeitura, pois tudo deve ser contabilizado para prestao
de contas aos rgos superiores. Sendo assim, ao realizar-se
um empenho, liquidao, recebimento de material ou bem
patrimonial, tudo deve ser contabilizado. O setor patrimonial
registra todo material adquirido pela prefeitura e realiza o
tombamento dos bens. Estes podem ser classificados como
bens mveis, imveis ou intangveis.
O processo de negcio de uma organizao o conjunto de
atividades ou tarefas estruturadas que produzem um produ-
to ou servio. Para se manterem competitivas no mercado,
en gen haria
as organizaes tm buscado formas de analisar e melhorar
suas estratgias de negcio. Isso envolve gerenciamento dos
processos de negcio, que compreende a unio da gesto de
negcios e a tecnologia da informao como forma de otimizar
dos resultados.
Links:
1. AALST, W. M. P. van der; TER HOFSTEDE. A.H.; WESKE, M. Business process
management: a survey. In: W.M.P. van der Aalst, A.H.M. ter Hofstede and M.
Weske, Editors, International Conference on Business Process Management
(BPM 2003), v. 2678 Lecture Notes in Computer Science, Springer-Verlag,
Berlin, pp. 112, 2003a.
2. AALST, W. M. P. van der; HOFSTEDE, A. H. M. ter; WESKE, M. Business Pro-
cess Management: A Survey. In: AALST, W.M.P. van der, HOFSTEDE, A.H.M.
ter; WESKE, M. (Org.) INTERNATIONAL CONFERENCE ON BUSINESS PROCESS
MANAGEMENT (BPM 2003), Lecture Notes in Computer Science. Berlin:
Springer-Verlag, p. 1-12, 2003b.
3. ASTAH. Astah Community. Online, 2013. Disponvel em http://astah.net/
editions/community (Acessado em 03/11/2013).
4. CRUZ, Tadeu. Workflow II: A Tecnologia que Revolucionou Processos.
Editora E-papers, ISBN: 8576500191, 2004.
5. MAC KNIGHT, D. Elicitao de Requisitos de Software a partir do Modelo
de Negcio. Dissertao (Mestrado em Informtica) Universidade Fede-
ral do Rio de Janeiro Instituto de Matemtica / Ncleo de Computao
Eletrnica, 2004.
6. VALDARES, Lear; SINIMBU, Allan; DAMASCENO, Laila. BPMN Modeling
Who, Where, How and Why, 2008.
Voc gostou deste artigo?
D seu voto em www.devmedia.com.br/esmag/feedback
Ajude-nos a manter a qualidade da revista!
Edio 68 - Engenharia de Software Magazine 57
Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros
A engenharia de software na era Big Data
Como nos preparar?
Digenes Firmiano
diogenesjf@gmail.com
Gestor Snior de Engenharia de Software atuan-
do nas reas de Engenharia de Software, Arqui-
tetura, Metodologia e Desenvolvimento de Sis-
temas. Formado em Cincia da Computao na
Universidade de Braslia, sendo ps-graduado
com MBA em Gerenciamento de Projetos tendo
feito vrios cursos de aperfeioamento em sua
rea de atuao. professor de disciplinas como
Gerncia de Projetos, Engenharia de Software,
Sistemas de Informao e Programao. Possui
experincia profissional de mais de 15 anos em
tecnologia da informao sendo especialista
em metodologias de software, arquitetura de
sistemas e gerncia de projetos de software.
58 Engenharia de Software Magazine - A engenharia de software na era Big Data
A
vida digital uma realidade.
Segundo a ANATEL, at no-
vembro de 2013, mais de 270
milhes de celulares estaro nas mos
da populao brasileira. Segundo o
Facebook, a base de clientes divulgada
em setembro de 2013 de 1.11 bilhes
de usurios cadastrados no mundo. A
quantidade de dados produzidos nos
ltimos dois anos maior que em toda
a histria da humanidade. E a quan-
tidade de dados produzidos continua
crescendo. A previso para 2015 de
quadruplicar a quantidade de dados
armazenados em 2013 e para 2020 a
previso de uma quantidade de dados
12 vezes maior que em 2013. Alm do
grande aumento do volume de dados, a
variedade de formas de gerao de da- ser necessrio realizar uma troca de
dos aumenta cada vez mais. Existe uma
grande tendncia de que cada vez mais
aparelhos eletrnicos sejam capazes de tem empresas de seguro que instalam
estar conectados Internet. Num futuro
muito prximo, sua geladeira te avisar a vida do cliente. Porm, estas mesmas
quando estiver algum produto faltando
ou quando a data de validade do seu
iogurte est chegando.
Fique por dentro:
Apresentar os conceitos relacionados ao tema
Big Data, seus impactos na sociedade e de que
forma a engenharia de software deve se pre-
parar para lidar com estas novidades. Na vida
digital que temos hoje em dia, a quantidade de
dados produzidos tem crescido absurdamen-
te. fundamental saber lidar com estas novas
necessidades aos softwares modernos e como
deveremos nos preparar para isto. A engenha-
ria de software precisa estar preparada tanto
para novas necessidades de conhecimento
quanto para saber aproveitar dos conceitos de
Big Data.
A era digital trouxe e ainda traz uma
srie de facilidades. Quem no gostaria
de ser avisado pelo seu seguro quando
leo ou quando os seus pneus precisam
ser trocados. Isto j possvel. Exis-
sensores nos veculos para facilitar
empresas coletam todas as informaes
que seu carro gera como trajetos, velo-
cidade mdia, locais onde estaciona e

quilometragem rodada, por exemplo. Com essas informaes,
possvel calcular mais precisamente se um cliente mais
prudente no trnsito ou se vive correndo pelas ruas s 3 horas
da manh. Com isso, possvel saber qual a melhor aplice de
seguro para cada carro sem precisar realizar entrevistas com
o cliente e estar sujeito a mentiras.
J possvel hoje em dia revolucionar a medicina. O acom-
panhamento dos pacientes pode ser feito por meio de sensores
instalados no paciente, como por exemplo, em um relgio, que
capta frequncia cardaca, presso arterial, nvel de glicose
dentre outros. O tal relgio pode inclusive ter alguma funo
que envie um sinal para o mdico quando o paciente apresentar
algum quadro facilmente identificvel como presso extrema-
mente alta, batimentos fora de controle ou quadros de infarto.
Estes avanos salvariam muitas vidas. Porm, empresas de
plano de sade tem planejado utilizar estas informaes junta-
mente com informaes de pronturios, quantidades de visitas
aos mdicos e resultados de exames para calcular qual o valor
a ser cobrado de cada paciente. Alm disso, estas informaes
poderiam ser inclusive utilizadas por empresas para analisar
os perfis dos candidatos a uma determinada vaga e recusar
o mesmo por perfil mdico inadequado. At que ponto esta
quantidade de informaes interessante?
Recentemente, a questo da privacidade dos dados foi ampla-
mente abordada com a divulgao das informaes coletadas
pela agncia de segurana americana NSA (National Security
Agency) sobre governos e empresas brasileiras. Vm sendo
discutido ainda o Marco Regulatrio da Internet. As questes
que ficam so: at que ponto regular a Internet resolve o pro-
blema? As informaes privadas concedidas por livre vontade
no podero ser utilizadas pelas empresas? Restringir o acesso
s informaes do governo suficiente? possvel realmente Desde a validade de um produto avisada por uma geladeira
restringir o acesso s informaes privadas?
Na nossa vida nos prximos anos, temas como privacidade e
tica devem ser amplamente discutidos no que tange o aspecto
da vida digital. Qual a soluo? Regredir e voltar poca
onde no podamos armazenar e processar tanta informao?
Proibir qualquer tipo de acesso informao? Criar ilhas de
informao como se prope no marco regulatrio? No so
leis pouco abrangentes que resolvero o problema. preciso,
primeiramente, esclarecer e entender o que possvel de se
fazer hoje em dia e o que ser possvel no futuro prximo.
O advento que tem tornado tudo isso possvel um conceito
chamado de Big Data.
O que Big Data?
O conceito de Big Data no surge do nada. Na verdade ele
no novo, mas est recebendo uma grande ateno por al-
gumas razes, como o barateamento do armazenamento de
dados, a proliferao de sensores e tecnologia de captura de
dados. Dados esto sendo coletados em grande escala. Eles so
provenientes das mais diversas fontes, como: dados gerados
por sistemas, sensores, cmeras, satlites, aparelhos eletrni-
cos, redes sociais, etc. No existe uma definio precisa sobre
o termo Big Data, existindo vrias definies na literatura.
en gen haria
O termo Big Data pode ser interpretado como dados grandes
ou grande volume de dados. Mas esta no uma definio
completa. O IDC define da seguinte maneira: As tecnolo-
gias Big Data descrevem uma nova gerao de tecnologias e
arquiteturas, projetadas economicamente para extrair valor
de volumes muito grandes de uma larga variedade de dados,
permitindo alta velocidade de captura, descoberta e anlise.
Percebemos, ento, que no se define Big Data apenas em
funo do tamanho do volume de dados, e sim na capacidade
de manipul-los.
O Big Data pode ser resumido em cinco caractersticas, mais
conhecidas como os 5 Vs, a saber:
Volume Grandes volumes de dados so produzidos e so
coletados. Um exemplo desse aspecto so os experimentos
cientficos do CERN, que geram cerca de 40 Terabytes de da-
dos por segundo, tamanho capaz de armazenar por volta de
13 milhes de msicas ou 40 mil filmes;
Velocidade Rapidez com que os dados so produzidos
e precisam ser analisados. Muitas aplicaes necessitam de
resposta em tempo real, como deteces em fraudes, recomen-
daes baseadas em redes sociais;
Variedade Existe uma grande variedade de dados, pro-
veniente de vrias fontes, podendo ser estruturados ou no.
Alguns exemplos so dados gerados por sistemas transacio-
nais, sensores, cmeras, satlites, redes sociais, etc.;
Veracidade extremamente importante avaliar se to-
dos estes dados coletados realmente tm alguma utilidade.
Na Internet e na mdia, sabemos que muitas informaes que
circulam so falsas. Tomar decises com base informaes
errneas podem gerar problemas gravssimos;
Valor Os dados gerados devem apoiar a tomada de deciso.
que pode ter valor para uma famlia at a quantidade de
curtidas em um determinado evento no Facebook que marca
uma manifestao, que pode ser de grande valia para a polcia
da cidade alvo.
O uso da tecnologia de Big Data
Com as tecnologias que possumos atualmente, possvel
analisar grandes volumes de informao em tempo real,
como, por exemplo, ao entrar em uma pgina de notcias na
Internet, visualizar os anncios de acordo com o perfil de
consumo do usurio. Indo mais frente, um Shopping Center
poder instalar cmeras que reconheam a face dos clientes,
identifique os perfis deles no Facebook ou Twitter, analise em
quais lojas que ele fica por mais tempo em frente vitrine ou
comprando e envie promoes dessas lojas para estes clientes
pelas mdias.
possvel ainda o uso destas tecnologias na forma de fazer
poltica. O candidato em campanha, na hora do discurso,
poder estar munido de todas as informaes sobre um de-
terminado municpio ou cidade como obras requeridas pela
populao, reclamaes feitas e outras informaes. O discurso
pode ser personalizado para cada pequena comunidade e
impacto gerado no eleitor gigantesco.
Edio 68 - Engenharia de Software Magazine 59
 Todo ser humano gosta de exclusivida-
de. O fato de fazer o cidado ou o cliente
como nico pode ser determinante na
hora do voto ou da venda. At que ponto
o uso desta informao tico? Aquele
que tem a mquina pblica na mo tem
muito mais informaes do que aquele
que no tem.
O uso de cmeras e sensores pode ser
utilizado no combate ao crime. Identifica-
o facial, anlise de comportamento dos
cidados e deteco preditiva de crimes
podem se tornar realidade num futuro
bem prximo. A segurana mais prxima
implica necessariamente em viver em um
Big Brother. As cmeras espalhadas na
cidade estariam analisando o compor-
tamento de cada ser humano e qualquer
deslize pode ser fatal. A anlise de com-
portamento, se mal usada, pode inclusive
ser utilizada para prejudicar as pessoas.
Todos ns seramos como artistas, vigia-
dos por paparazzi que aguardam apenas
um motivo para um clique.
O uso de informaes externas cole-
tadas de mdias digitais, por exemplo,
para prever riscos tambm se tornar
importante para as empresas. Nos
mercados financeiros, os analistas j
acompanham de perto e agregam uma
gama de relatrios estatsticos a reas
que impactam as expectativas e reaes
do mercado, tais como desemprego, con-
fiana do consumidor e o PIB. Os fundos
multimercados e outros sempre tentaram
sair frente dessas publicaes ao fazer
Figura 1. Metodologias para anlise de Big Data Fonte: Data Science with Hadoop. Alpine Labs
60 Engenharia de Software Magazine - A engenharia de software na era Big Data
seus clculos de forma independente.
Com o Big Data, existem empresas que
esto reunindo dados bem detalhados
que podem nos ajudar a construir uma
imagem do mundo quase em tempo real.
Uma queda nas remessas da FedEx ou um
aumento nos leiles do eBay, por exemplo,
pode significar uma queda na confiana
do consumidor. Ou ser que um ligeiro
aumento no nmero de downloads dos
filmes da Amazon Prime podem indicar
que mais pessoas esto preferindo ficar
em casa em vez de sair para jantar e com-
prar ingressos para o cinema?
A implementao do big data, seja para
deteco de fraudes, melhoria na segu-
rana, ou outros benefcios bem inten-
cionados, cria outro conjunto de riscos.
Os consumidores voluntariamente for-
necem informaes pessoais em troca de
experincias personalizadas e servios
melhores. Est implcito nessa troca
que a empresa se responsabiliza pela sal-
vaguarda dessas informaes. Violaes
dos dados dos consumidores podem
estragar relacionamentos com clientes
e marcas e tm custos reais concretos,
tais como gesto de crises, reparaes e
monitoramento de crdito para todos os
clientes/funcionrios. As empresas que
podem ser transparentes com relao os conceitos de Big Data. No mundo cor-
coleta e uso de informaes ao mesmo
tempo em que demonstram que a gesto
de risco ciberntico tem alta prioridade,
tero uma vantagem competitiva.
Como vemos, a tecnologia est e estar
disponvel para mudar e revolucionar a
vida das pessoas. A forma como interagi-
mos, a medicina, a poltica, a segurana
pblica, as compras, praticamente tudo
pode ser influenciado por essa revoluo
digital. uma via de mo nica. A vida
digital j est enraizada em nossas vidas
e no conseguimos viver sem. Quem
imagina sua vida sem um celular? E sem
Internet? Desta forma, parece inevitvel
encarar os contratempos que essa realida-
de nos trs. Mas de que forma todas estas
tecnologias iro impactar o dia a dia do
profissional de TI? A forma de construir
softwares muda? A engenharia de sof-
tware ser impactada pelos benefcios e
malefcios do Big Data? Os profissionais
de TI de hoje em dia esto preparados?
O impacto do Big Data na
engenharia de software
A construo de softwares para atender
a estas novas tecnologias exige uma mu-
dana na forma de pensar. Os softwares
orientados a Big Data ultrapassam os
limites geralmente impostos nas arquite-
turas tradicionais e questes geralmente
propostas como escalabilidade, volume,
desempenho e quantidade de interfaces
provavelmente tero novas respostas com
porativo, so inmeras as ocasies onde
os arquitetos embasam suas negativas
em uma ou outra soluo a um cliente
considerando estes aspectos no funcio-
nais citados. Entretanto, considerando os
aspectos de solues de Big Data, muitas
dessas solues sero possveis e devem
ser considerados novos aparatos de soft-
ware como frameworks e ferramentas
no consideradas at ento.
A metodologia e a abordagem de solu-
es de Big Data tambm so diferentes.
Na construo de uma soluo de Big
Data, muitas vezes o que se busca so
respostas a perguntas no convencio-
nais, que no podem ser respondidas
de maneira tradicional. Explorao dos
dados, preparao, minerao e anlises
devem ser consideradas. Tais metodo-
logias ainda so bastante novas e ainda
carecem de maturao. Entretanto, j se
encontram nas literaturas algumas refe-
rncias a novas metodologias conforme
demonstrado na Figura 1.
 en gen haria

Na estrutura proposta pela Alpine

Labs, so propostas as fases de explora-
o, preparao dos dados, modelagem,
avaliao e publicao. A construo de
software realizada em todas as fases e
os softwares construdos variam desde
pequenas bibliotecas para realizao
de um determinado tipo de anlise at
softwares complexos de anlise estats-
tica. No modelo proposto pela Oracle, Figura 2. Modelo proposto pela Oracle. Fonte: Oracle Big Data Reference Architecture
por exemplo, so previstas quatro fases,
coleta de dados, organizao, anlise e
deciso, conforme exposto na Figura 2.
Nesta abordagem, so necessrios
softwares que possam realizar desde
a coleta aos dados gerados em diversas
fontes como mdias sociais, celulares,
sensores, arquivos e outras diversas
fontes at softwares de deciso. Nesta
abordagem fica clara a necessidade de
um conjunto de softwares para cobrir
a soluo de Big Data como um todo.
A Apache Foundation possui um modelo
de solues que aborda a ampla gama de
frameworks e bibliotecas que ela possui.
Veja a Figura 3.
No conjunto de solues da Apache,
fica clara a quantidade de softwares
necessrios para diversas solues de Figura 3. Framework de Big Data da Apache - Fonte: Apache Big Data Framework In Reference
Big Data, desde solues de anlises Architecture

Edio 68 - Engenharia de Software Magazine 61

em Real-Time at solues de anlise Batch ou solues de
anlise Interativa. Abaixo, em uma abordagem mais ampla
proposta pelo autor, sugerido um fluxo de atuao em Big
Data considerando as diversas necessidades de software de
forma a abarcar todo o processo de construo de solues de
Big Data (observe a Figura 4).
A metodologia proposta aborda cinco fases para construo
de solues de Big Data sendo elas: explorao dos dados,
preparao dos dados, minerao e integrao, gerao dos
dados analticos e avaliao e visualizao. Cada fase possui
um objetivo e pode utilizar de uma ampla variabilidade de
softwares. O modelo apresentado serve apenas como ilustrao
para as diversas fases necessrias para o novo profissional na
construo de softwares de Big Data.
Estes novos profissionais devem estar cientes da ampla
gama de solues e da ampla variedade de frameworks que
devem trabalhar. O trabalho com solues de Big Data exige
tambm uma mudana de ponto de vista. Volumes de dados
expressivos, agora devem ser considerados e podem ser tra-
balhados inclusive com amplas variedades de fontes, como
mdias sociais, documentos, bancos de dados tradicionais,
dentre outros como a prpria Internet, por exemplo. Devem ser
consideradas tambm, possibilidades de solues Real Time.
O Facebook, por exemplo, na apresentao de informaes
de propaganda, utiliza-se de dados de navegao do usurio
em tempo real e realiza atualizaes das novas propagandas
sugeridas ao usurio. So necessrias novas solues para
Figura 4. Metodologia de Big Data proposta
62 Engenharia de Software Magazine - A engenharia de software na era Big Data
atingir este nvel de velocidade da informao necessria,
uma vez que se deve considerar que o Facebook com dados
na ordem de Petabytes.
Diante dos novos desafios, ser fundamental entender os
conceitos de Big Data desde o profissional recm-formado at
os profissionais com vrios anos de experincia. Os desafios
dos sistemas modernos fatalmente incluiro conceitos como
volumes expressivos, alta demanda por velocidade ou ampla
variedade de fontes de dados. Os novos desafios, muitas ve-
zes incluiro conceitos de estatstica, capacidade analtica e
exigiro um alto poder de aprendizado. Surge nesse contexto
uma nova perspectiva profissional, o cientista de dados. Este
profissional deve possuir conhecimentos de tecnologia e
estatstica e aliar estas duas caractersticas para potencializar
o uso do Big Data. As demandas de infraestrutura tambm
sero aumentadas e cada vez mais se faz necessrio pensar
em escalabilidade.
O potencial do Big Data
Por fim, aps verificar as novas expectativas sobre o uso de
Big Data e os pontos relevantes a serem considerados, vale
ressaltar uma abordagem sobre o aproveitamento do potencial
do Big Data:
Deve-se manter o objetivo final em mente ao lidar com a
compilao de dados, marketing digital ou outras iniciativas
de base tecnolgica. Existem muitos benefcios intangveis do
big data: melhor atendimento ao cliente, mais envolvimento,
a unificao do tom de voz da marca
e mais conhecimento sobre o cliente.
Todos so objetivos nobres, assim como
algumas novas tecnologias, como um
painel sempre ativo na rede social ou
um mecanismo de recomendao no seu
site da internet. Mas nada melhor do
que o crescimento das vendas. Deve-se
orientar o uso de Big Data considerando
os objetivos finais do cliente e no deixar-
se distrair com os ganhos parciais que
podem ser alcanados;
Pense grande, comece pequeno e
ganhe escala rapidamente. Integrar os
dados de diversas fontes por meio de
pontos de contato e canais requer um
pensamento grande, mas isso no
necessariamente significa investimentos
macios. Voc pode comear pequeno.
Rastrear as vendas atuais dos revende-
dores foi inicialmente um passo pequeno
para o fabricante de bebidas na Amrica
Latina, o teste foi realizado em uma nica
cidade durante algumas semanas. Isso
criou uma informao em tempo real
que a empresa usou para melhorar as
vendas e os itinerrios de entrega. Com
um modelo comprovado, a empresa, em
 en gen haria

seguida, ampliou a regio de atuao e comeou a integrar os solues e a quantidade de benefcios associados sobrepe
dados de consumo reais dos clientes por meio do rastreamento s dificuldades geradas aos profissionais de TI. Diante disso,
dos celulares; necessria a conscientizao desde j dos novos conceitos
Entender o poder da informao em tempo real. Big data visando maturar o processo de construo de solues orien-
no comparvel implantao de um projeto de CRM ou tadas a Big Data.
ao esforo de implementao de um ERP. As informaes de
vendas dirias ajudaram o fabricante de bebidas a ajustar Referncias e Links:
imediatamente as vendas, entregas, logstica e programas
promocionais e de marketing. Mantenha em mente, entre- Barlow, M. (2013). Real-Time Big Data Analytics: Emerging Architecture:
tanto, que cada caso um caso. O que ser importante para OReilly.
uma determinada soluo? Pode ser necessrio verificar as
Magalhes, R. P. (2013) Big Data: Transformando dados em riqueza.
tendncias trimestralmente ou a cada seis meses. O uso do
Hornick, M. Learning R Series, Oracle, 2013.
Big Data deve ter como objetivo manter-se atualizado, e no
resolver todos os problemas. Sashikanth, V. Making Big Data Analytics accessible via the R environment,
Oracle, 2013.
O uso das novas tecnologias de Big Data em todas as reas
DAVENPORT, Thomas, H. At the Big Data Crossroads: turning towards a
tende a seguir um caminho de inevitvel aderncia e im- smarter travel experience. Amadeus 2013.
plantao. As vantagens do uso so inmeras. O uso destas
tecnologias pode revolucionar desde a forma como o cliente IBM. What is big data?
se relaciona com as lojas at a medicina, a segurana pblica, http://www-01.ibm.com/software/data/bigdata/.
a educao, a poltica, enfim, a revoluo que se inicia uma Big Data Definition - MIKE2.0, the open source methodology for Information
tendncia que veio para ficar. A vida dos profissionais de TI Development.
e da engenharia de software ser revolucionada pelo uso de
tais tecnologias. Ser necessria uma mudana na forma de White, Tom. Hadoop: The Definitive Guide. 2009. 1st Edition. OReilly
Media. Pg 3.
pensar destes profissionais. A metodologia de construo de
softwares orientados a Big Data bem diferente das metodo-
logias tradicionais de construo de software e, ao utilizar Voc gostou deste artigo?
estes novos conceitos, ser necessrio aprender cada vez mais
tecnologias e frameworks. D seu voto em www.devmedia.com.br/esmag/feedback
Apesar das dificuldades, ser de fundamental importncia
Ajude-nos a manter a qualidade da revista!
a imerso nestes novos conceitos. Parece inevitvel fugir das
tendncias de utilizao de Big Data nos novos projetos de

Edio 68 - Engenharia de Software Magazine 63

64 Engenharia de Software Magazine - A engenharia de software na era Big Data
 en gen haria

Edio 68 - Engenharia de Software Magazine 65