Pontos Por Função

magazine
engenharia
de software
Edio 44 - Ano 04
Processo
Conhea os modelos
de processo pessoal
Processo
Uma viso geral
do CMMI
Aprimore suas estimativas de tamanho de projeto
Agilidade
Requisitos para
alcanar agilidade
Agilidade
Scrum e o gerenciamento
de projetos - Parte 3
Requisitos
Gerenciando mudanas
a partir de requisitos
Modelos de processo pessoal

http://www.devmedia.com.br/post-23264-Modelos-de-processo-pessoal.html
Desenvolvimento
Desenvolvimento de aplicaes de
realidade aumentada
Desenvolvimento
Conhea tcnicas para manter
seu cdigo limpo Parte 6
Rodrigo Oliveira Spnola

rodrigo.devmedia@gmail.com
Doutorando em Engenharia de Sistemas e Computao (COPPE/UFRJ). Mestre em Engenharia de
Software (COPPE/UFRJ, 2004). Bacharel em Cincias da Computao (UNIFACS, 2001). Colaborador
da Kali Software (www.kalisoftware.com), tendo ministrado cursos na rea de Qualidade de Produtos e Processos de Software, Requisitos e Desenvolvimento Orientado a Objetos. Consultor para
implementao do MPS.BR. Atua como Gerente de Projeto e Analista de Requisitos em projetos de
consultoria na COPPE/UFRJ. Colaborador da Engenharia de Software Magazine.
Marco Antnio Pereira Arajo
Ano 4 - 44 Edio - 2012
maraujo@devmedia.com.br
Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ - Linha de Pesquisa
em Engenharia de Software, Especialista em Mtodos Estatsticos Computacionais e Bacharel em
Matemtica com Habilitao em Informtica pela UFJF, Professor e Coordenador do curso de Bacharelado em Sistemas de Informao do Centro de Ensino Superior de Juiz de Fora, Professor do
curso de Bacharelado em Sistemas de Informao da Faculdade Metodista Granbery, Professor e
Diretor do Curso Superior de Tecnologia em Anlise e Desenvolvimento de Sistemas da Fundao
Educacional D. Andr Arcoverde, Analista de Sistemas da Prefeitura de Juiz de Fora, Colaborador
da Engenharia de Software Magazine.
Corpo Editorial
Editor
Colaboradores
Eduardo Oliveira Spnola
Eduardo Oliveira Spnola
Jornalista Responsvel
Kaline Dolabella - JP24185
eduspinola@gmail.com
Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Magazine. bacharel em Cincias da Computao pela Universidade Salvador (UNIFACS) onde atualmente cursa o
mestrado em Sistemas e Computao na linha de Engenharia de Software, sendo membro do GESA
(Grupo de Engenharia de Software e Aplicaes).
Na Web
www.devmedia.com.br/central
(21) 3382-5038
Atendimento ao Leitor
A DevMedia conta com um departamento exclusivo para o atendimento ao leitor. Se
voc tiver algum problema no recebimento do seu exemplar ou precisar de algum
esclarecimento sobre assinaturas, exemplares anteriores, endereo de bancas de
jornal, entre outros, entre em contato com:
www.devmedia.com.br/mancad
(21) 2220-5338
Fale com o Editor!

muito importante para a equipe saber o que voc est achando da revista: que tipo de artigo voc
gostaria de ler, que artigo voc mais gostou e qual artigo voc menos gostou. Fique a vontade para
entrar em contato com os editores e dar a sua sugesto!
Se voc estiver interessado em publicar um artigo na revista ou no site SQL Magazine,
entre em contato com os editores, informando o ttulo e mini-resumo do tema que voc gostaria
de publicar.
Apoio
Publicidade
Para informaes sobre veiculao de anncio na revista ou no site entre em
contato com:
publicidade@devmedia.com.br
EDITORIAL
a fase inicial de um projeto, a necessidade em obter o custo, prazo e o
Neste contexto, esta edio da Engenharia de Software Magazine destaca
esforo observado em todas as empresas, pois as mesmas precisam
como tema de capa Anlise de Ponto de Funo. Para isto, trazemos um artigo
gerar um oramento para os seus clientes e avaliar uma srie de
cujo objetivo apresentar de forma simples, por meio de exemplos, o uso de
projees.
Inicialmente no se tem conhecimento de todas as caractersticas do produto
um mtodo poderoso para a soluo destes problemas recorrentes, a APF

(Anlise de Ponto de Funo).
bem como da sua real dimenso, por esse motivo necessrio utilizar tcnicas
Alm deste artigo, teremos mais sete nesta edio:
de extrao de requisitos para realizar um levantamento inicial dos mesmos e
Requisitos para agilidade no desenvolvimento de software
compreender melhor o problema. Os requisitos so condies, caractersticas
Scrum e o gerenciamento de projetos Parte 3
ou capacidades necessrias para atingir uma finalidade, categorizados na
Modelos de processo pessoal
implementao de sistemas em funcionais e no funcionais como forma de
CMMI Uma viso Geral
estabelecer critrios de qualidade.
Gerenciando mudanas a partir de requisitos
Uma vez definidos os requisitos, pode-se ento avaliar o tamanho do sistema

em termos de suas funcionalidades. Existem vrios mtodos de estimativa, a
Introduo ao desenvolvimento de aplicaes de realidade aumentada

Boas prticas para escrita de mtodos, funes e procedimentos Parte 6
APF (Anlise de Ponto de Funo) uma delas. Esse mtodo no tem como
objetivo realizar estimativas de prazo, custo e esforo para implementao
de sistema, mas sim avaliar o tamanho de um sistema em termos de suas
funcionalidades. Resulta desta avaliao o tamanho funcional do sistema
expresso em Pontos de Funo (unidade de medida do mtodo). A partir do
tamanho funcional, podem ser derivadas estimativas adicionais, como tempo
e custo.
Equipe Editorial Engenharia de Software Magazine
NDICE
Agilidade
06 - Requisitos para agilidade no desenvolvimento de software
Flavio S. Mariotti
13 - Scrum e o gerenciamento de projetos Parte 3

Fbio Cruz
Engenharia Aplicada
20 - Estimativas de tamanho em projetos de software utilizando pontos de funo
Jhoney da Silva Lopes e Jos Luis Braga
Engenharia Fundamentos
32 - CMMI Uma viso Geral
Lenildo Morais
36 - Gerenciando mudanas a partir de requisitos

Jos Alberto Zimermann, Thiago Carvalho de Sousa e Rodrigo Oliveira Spnola
Arquitetura e Desenvolvimento
42 - Introduo ao desenvolvimento de aplicaes de realidade aumentada
Andr Luis Tosato, Victor Angelo Marcorin, Thiago Salhab Alves e Paulo Barreto da Silva
47 - Boas prticas para escrita de mtodos, funes e procedimentos Parte 6

Jacimar Fernandes Tavares e Marco Antnio Pereira Arajo
Edio 05 - Engenharia de Software Magazine
Agilidade
Nesta seo voc encontra artigos voltados para as prticas e mtodos geis.
Requisitos para agilidade no

desenvolvimento de software
Necessidades requeridas para equipe, programas e empresa
De que se trata o artigo?

Este artigo apresenta uma proposta sobre nveis
de requisitos geis, prticas correspondentes aos
papis sugeridos e um modelo organizacional que
proporciona um formato de empresa gil. O objetivo
escrever os requisitos que se fazem necessrios para
a criao de uma equipe gil, programas que ofeream
suporte ao primeiro nvel e a fase e maturidade da
empresa gil.
individuais, com a adoo de alguns mtodos como

XP, Scrum, Lean entre outros. No entanto, esses
mtodos comearam a se espalhar para o nvel das
empresas e uma srie de fatores comearam a exigir
um escopo organizacional mais amplo para suportar
os desafios da governana desses novos processos.
Neste sentido, o objetivo do artigo fornecer um
modelo que ajude a obter uma viso elevada do
conceito gil e seus requisitos para maturidade de
uma empresa gil.
Em que situao o tema til?

Na ltima dcada, a criao de modelos de engenharia
de software cada vez mais geis foi a mudana mais
significativa que afetou as empresas de software
desde o advento do modelo em cascata na dcada de
1970. Nos ltimos cincos anos, as metodologias geis
comearam a se espalhar nas empresas de software.
As iniciativas geralmente comearam com equipes
Flavio S. Mariotti
flaviomariotti@gmail.com
Especialista em Engenharia e Arquitetura

de Software. Ps Graduado pelo Instituto
de Pesquisa Avanada de Tecnologia IBTA
em Engenharia de Software baseado em
SOA. Bacharel em Sistemas de Informao
pela UNIUBE e tcnico em Processamento
de Dados pela FEB. Consultor independente
no desenvolvimento de software em
arquitetura OO, SOA, GIS e Plataforma .NET.
desenvolvimento de software
se tornou um dos fatores mais
importantes da tecnologia.
O software que produzido hoje se torna rapidamente um item fundamental
para organizaes e usurios finais no
intuito de acelerar e auxiliar a execuo
de diferentes tarefas.
Nos ltimos 50 anos diferentes grupos,
especialistas e pesquisadores da rea de
Engenharia de Software Magazine - Requisitos para agilidade no desenvolvimento de software
Resumo DevMan
Este artigo discute o tema requisitos para agilidade
no desenvolvimento de software. Para isso, ser
apresentado, sob diferentes perspectivas, como
a questo da agilidade pode ser considerada em
equipes de projetos de software que trabalhem
considerando os princpios da agilidade.
TI, vm disponibilizando diversas metodologias para apoiar essa difcil tarefa de

desenvolvimento de software, tais como:
modelo cascata, espiral, RAD, RUP,
Crystal, Scrum (ler Nota Devman 1),
XP (ler Nota Devman 2), FDD (ler Nota
Devman 3), Lean, DSDM entre outros.
Com a evoluo rpida dos recursos
computacionais, o escopo do software se
altera com a mesma velocidade, exigindo
agilidade
como um dos principais itens do desenvolvimento de software

a agilidade na produo. Porm, como criar produtos com menos tempo e com a mesma eficincia? So dvidas como essas
que vem transformando nossas metodologias na tentativa de
alcanar o melhor e mais gil modelo de desenvolvimento de
software.
Contudo, ser que somente uma boa metodologia o suficiente para apoiar essa difcil misso? A resposta certamente
NO. Para se obter agilidade no processo de desenvolvimento
de software preciso aplicar o conceito nos trs pilares que
fazem parte deste trabalho, que so: equipe, programas e empresa. Esse o principal objetivo deste artigo, proporcionar
ao leitor uma breve abordagem do que se faz necessrio para
atingir a agilidade no desenvolvimento de software, quais os
requisitos para criar um time gil, quais os pilares e processos
que envolvem esse trabalho, qual o papel da empresa para dar
Nota do DevMan 1
Scrum: Scrum um framework para gerenciamento de projetos geis muito
utilizado na rea de desenvolvimento de software. Uma das principais caractersticas
do Scrum permitir o desenvolvimento de produtos complexos de uma forma
incremental e iterativa, contribuindo para decompor um grande produto complexo,
em pequenos subprodutos mais simples, mais rpidos e mais fceis de serem
desenvolvidos e entregues. No Scrum estas iteraes so chamadas de Sprints, e uma
caracterstica marcante de sua estrutura e aplicao o controle sobre os trabalhos
realizados, e a possibilidade de correo e adaptao rpida, permitindo que a equipe
altere sua forma de agir ou de pensar o mais breve possvel, evitando que problemas
ou erros causem danos maiores ao projeto.
Nota do DevMan 2
XP: O eXtreme Programming ou XP um modelo gil de desenvolvimento de
software criado em 1996 por Kent Bech no Departamento de Computao da
montadora de carros Daimler Chrysler. Ele possui muitas diferenas em relao
a outros modelos, podendo ser aplicado a projetos de alto risco e com requisitos
dinmicos (vagos ou em constante mudana), conduzidos por equipes de tamanho
mdio e pequeno.
Como todo mtodo gil, o XP procura responder com velocidade s mudanas nas
especificaes do projeto, com base em princpios, valores e prticas bem definidos.
Este mtodo enfatiza o desenvolvimento rpido garantindo a satisfao do cliente
e cumprindo as estimativas do projeto. O XP baseia-se em cinco valores para guiar
o desenvolvimento: Comunicao, Coragem, Feedback, Respeito e Simplicidade.
Segundo Beck, o mtodo oferece ainda 12 prticas, a saber: i) Jogo do planejamento;
ii) Verses pequenas; iii) Metfora; iv) Projeto simples; v) Teste; vi) Refatorao; vii)
Programao em pares; viii) Propriedade coletiva do cdigo; ix) Integrao contnua;
x) 40 horas de trabalho semanal; xi) Cliente presente; e xii) Padres de codificao.
suporte aos processos, como distribuir a responsabilidade

de cada envolvido no processo e qual a importncia dessa
distribuio.
Requisitos geis para a equipe

importante ressaltar que o modelo de equipe que ser
apresentado neste artigo tem como principal propsito auxiliar o time de desenvolvimento a se organizar ao definir
papis, distribuir responsabilidades e criar as atividades para
um projeto no modelo gil. Sendo assim, de total valia usar
esses conceitos para modelar e adequar a sua equipe na sua
realidade.
Sabemos que um dos grandes desafios fazer com que a
equipe incorpore o modelo gil para contribuir ao mximo
com o time. Recomendo aos interessados pela teoria da liderana de pessoas dar uma no lida modelo Tuckmans stages of
group development proposto pelo psiclogo americano Bruce
Wayne Tuckman.
Funes e responsabilidades da equipe

Ao estudar e analisar diversos modelos organizacionais de
uma equipe gil proposta em diferentes metodologias como
XP, Scrum, Lean, entre outros, chega-se concluso de que a
estrutura organizacional de uma equipe gil basicamente a
mesma em todas metodologias.
O Scrum, por exemplo, prope um modelo que se divide em
trs principais funes, so eles: Scrum Master (Responsvel
gil), Product Owner (Proprietrio do Produto) e o resto da
Nota do DevMan 3
FDD: O FDD uma metodologia que serve tanto para o gerenciamento de projetos
quanto para a Engenharia de Software. Isto a torna mais complexa quando comparada
com outras metodologias geis. Por exemplo, o RUP (Rational Unified Process) da IBM,
uma metodologia considerada tradicional, trata o gerenciamento de projetos como
uma disciplina dentro do seu framework, j que o seu foco est na Engenharia de
Software em si. J o SCRUM, tem no papel do Scrum Master, uma figura parecida com
a de um Gerente de Projetos formal, mas que tem seu foco na facilitao dos trabalhos
por parte da equipe tcnica. O foco dessa metodologia est na auto-organizao da
equipe e, para isso, so necessrios analistas seniores.
O ponto forte da metodologia FDD est na capacidade de realizar features. Para esta
metodologia, uma pequena feature possui um alto valor para o cliente. O exemplo de
uma feature est em um caso de uso com a funo de calcular a mdia de salrio dos
gestores, ou de realizar um relatrio integrado de vendas e assim por diante. Veja
que no estranha a meno do termo caso de uso para exemplificar uma feature,
j que a ideia similar. Essa descrio do requisito que o FDD chama de feature so
os casos de uso no RUP e as estrias utilizadas no XP. O site www.agilemodeling.
com/essays/fdd.htm destaca que uma lista de features inicialmente indicada para
que seja elaborado o planejamento do projeto com estimativas de esforo para sua
execuo. Basicamente, esta a proposta do FDD.
equipe que consiste principalmente de desenvolvedores e

testadores de software.
Composio da equipe gil

A Figura 1 representa de forma grfica o modelo organizacional de uma equipe gil. Na sequncia conheremos cada
um desses papis.
na equipe e se torna a metodologia do time, as regras so

auto-impostas, fazendo com que a participao do Responsvel
gil se torne menos frequente e necessria. Resumidamente,
as responsabilidades desta funo se dividem em:
Facilitar o progresso da equipe em direo meta;
Liderar os esforos da equipe e buscar a melhoria
contnua;
Fazer cumprir as regras do processo gil;
Eliminar obstculos.
Desenvolvedores e Testadores
A equipe se completa com os desenvolvedores e testadores.
Geralmente o tamanho de uma equipe gil limitada entre
4 at 6 desenvolvedores e de 1 at 3 testadores, idealmente
trabalhando juntos.
Desenvolvedores
Figura 1. Ilustrao do nvel de equipes
Proprietrio do produto
Como j definido no Scrum, o proprietrio do produto tem
como caracterstica atuar como a nica funo arbitrria, ou
seja, esse papel responsvel por determinar e priorizar as
necessidades dos utilizadores e gerenciar os itens acumulados
(product backlog). importante lembrar que esse artigo no
descreve Scrum como metodologia a ser seguida. Independente da metodologia que sua equipe adotou como gil,
recomendada a aplicao da funo proprietrio do produto,
j que esse papel vem mostrando verdadeiros avanos na
simplificao do trabalho exercido pela equipe.
Contudo, as responsabilidades do proprietrio do produto so ainda maiores. Segundo o princpio Agile Manisfesto
#4 - Homens de negcio e desenvolvedores devem trabalharem
juntos diariamente durante o andamento do projeto. Com base
nesse princpio, o proprietrio do produto a funo ideal
para orientar a equipe e participar diariamente com a mesma
em suas atividades no intuito de direcionar e definir suas
prioridades.
Podemos dizer ento que o proprietrio do produto o principal responsvel pela definio e priorizao de requisitos.
Portanto, a funo proprietrio do produto responsvel pelas
seguintes atribuies:
Trabalhar com todos stakeholders (gerentes, analistas, clientes
e interessados) do projeto para determinar os requisitos;
Priorizar as atividades com base no valor relativo do
cliente;
Definir motivos para iterao, atuar e elaborar relatrios,
participar e revisar processos buscando melhoria contnua.
O modelo de trabalho aplicvel aos desenvolvedores pode ser

o modelo de programao em par com outro desenvolvedor,
ou tambm emparelhado com um testador ou outro modelo
gil, de forma a operar mais independente e ter interfaces com
mltiplos testadores e desenvolvedores. Contudo, a responsabilidade desta funo basicamente a mesma, so elas:
Codificar os requisitos;
Colaborar com os testadores e proprietrios do produto
garantindo a codificao do produto de forma padronizada
conforme definio da equipe;
Codificar e executar as unit test;
Garantir o check-in e check-out do cdigo feito diariamente;
Participar ativamente na melhoria do ambiente de
desenvolvimento.
Testadores
Os testadores so parte fundamental e integrante da equipe
gil. Os testadores estaro presentes logo no primeiro cdigo a
ser liberado, e se faz necessrio passar pela aplicao de testes
e aprovao do time de testadores. A principal responsabilidade atribuda a essa funo a liberao do cdigo fonte para
produo ou continuidade do fluxo de trabalho. de extrema
importncia o cumprimento desse requisito para se obter
qualidade e agilidade no desenvolvimento de software. Outras
responsabilidades atribudas a essa funo so:
Criar casos de testes e aprovao;
Interface com os desenvolvedores e proprietrio do produto
para garantir e certificar o entendimento das funcionalidades
requeridas;
Executar os testes de aprovao;
Desenvolver teste de aprovao para a atualizao de componentes no ambiente de produo.
Responsvel gil
Especialistas
O responsvel gil geralmente o papel do lder do projeto.

Essa funo tem como responsabilidade dirigir o time para
alcanar suas metas e, em alguns projetos, importante somente na fase de transio. Quando o modelo gil imposto
No podemos deixar de ressaltar a importncia de recursos

compartilhados e interfaces para outras funes. Segundo o
princpio Agile Manifesto #11 - As melhores arquiteturas, requisitos e
projetos emergentes de equipe auto-organizadas.. Assim sendo, se faz
agilidade
necessrio estabelecer um trabalho colaborativo com especialista

que, no necessariamente fazem parte da equipe, porm contribuem com seus conhecimentos. Alguns desses papis so:
Arquitetos de software;
Especialistas de qualidades QA;
Especialistas de infraestrutura;
Administradores de bancos de dados;
Especialistas em gerenciamento de configurao;
Especialistas de implantao.
Conceito gil
Sabendo que o intuito de desenvolver software com agilidade
no exclui a principal necessidade de criar aplicativos eficientes que agregue valor ao cliente, precisamos assegurar que
as equipes geis estejam aplicando modelos simples, porm
abrangendo todos os requisitos possveis. Uma vez escutei uma
frase que dizia: O difcil fazer o simples, o complexo todo mundo
faz. Resumindo, o significado dessa frase : neste momento
precisamos garantir que a equipe no esteja sendo sobrecarregada com requisitos desnecessrios que no agregam valor
ao cliente e no geram resultado para a equipe.
Histrias de usurios
Essa funo originada do modelo XP. Histrias de usurios (User Stories) vem com a proposta de substituir o famoso
requisitos de software. Este item gil atualmente faz parte
dos modelos Scrum, XP e na maioria das outras metodologias
geis. A responsabilidade e definio desse usurio se resume
em: Uma breve descrio dos principais objetivos que levam as
necessidades dos clientes atravs de fluxo de valor.
Ao contrrio de requisitos que definem o que o sistema deve
fazer na maioria das vezes como obrigao contratual, histrias
de usurios so breves declaraes de usurios expressando
suas intenes que descrevem um recurso que o sistema precisa fazer para alguns usurios ou departamento.
A principal proposta dessa funo transmitir equipe de
desenvolvimento o que realmente traz benefcios ao usurio
agregando valor ao produto, ensinando a equipe a se concentrar no que realmente agrega valor ao negcio do usurio.
Backlog
A ltima funo que integra uma equipe gil o backlog.
O produto backlog consiste em acumular todos os recursos
necessrios a serem implementados, identificados pela equipe
gil com base em todas as histrias de usurios.
A responsabilidade dessa funo acumular os itens a serem
desenvolvidos com base nas histrias dos usurios. Embora
existam diversas tarefas a serem executas como: itens de configurao, requisitos de infraestrutura, entre outras atividades,
o principal objetivo do backlog concentrar a ateno da equipe
nas histrias de usurio.
Requisitos geis para o programa

No nvel de equipe, foi introduzido um conceito que aborda
a criao de equipes de software preparadas para definir,
desenvolver e testar o software. Neste nvel as equipes so

capacitadas e trabalham a partir de um backlog local que est
sob o gerenciamento do proprietrio do produto. O proprietrio do produto tem o controle para definir, construir e testar
seus componentes fase a fase. Com base nos princpios do Agile
Manifesto, esse o mecanismo ideal para incentivar e motivar
a equipe para produzir os resultados positivos.
No nvel de programa, ser apresentado um processo organizacional e modelo de requisitos que fornece mecanismos
para aproveitar os recursos que integram as equipes geis
para um propsito maior, ou seja, a entrega de um sistema ou
um conjunto de aplicativos para os clientes. Neste momento
os problemas so outros e a empresa ir enfrentar diferentes
desafios para executar com sucesso o conceito de agilidade.
Resumidamente, as metas neste nvel so:
Roadmap: definir e comunicar a viso do programa e manter
um roteiro;
Gerenciamento de liberao: Coordenar as atividades das equipes para definir critrios de liberao;
Gesto da qualidade: Assegurar a qualidade do sistema, desempenho, segurana, e quaisquer normas impostas anteriormente
devem ser atendidas;
Implantao: A definio de critrios para implantao deve
ser gerida no nvel de programa;
Gesto de recursos: Ajustamento dos recursos conforme
necessrio para enfrentar as limitaes e dificuldades na
capacidade do programa para entregar o valor necessrio em
tempo hbil;
Eliminao de obstculos: Os lderes e gestores de programas so responsveis por eliminar bloqueios que atrasem a
equipe.
Equipes recursos e equipes componentes

Nesta parte do artigo ser apresentado como funcionam as
equipes de recursos e componentes. Vamos fazer uma combinao e comparao para demonstrar os resultados organizacionais equipe de organizao. Em minha opinio, essa
uma das decises mais difceis para serem tomadas. Perceber
a necessidade e decidir a incluso de uma dessas duas equipes
para agilidade do projeto requer muito cuidado.
Equipes recursos
Uma equipe de recursos ou em ingls Feature Team, basicamente um time com diferentes habilidades, ou seja, uma
equipe composta com profissionais de diversas competncias
para desenvolver um recurso de ponta a ponta.
Para ilustrar a diferena entre equipes de recursos e equipes
de componentes, vamos imaginar um cenrio tpico nos projetos corporativos. Em uma arquitetura como a apresentada na
Figura 2 em que as equipes se organizam em torno de camadas,
teramos neste momento seis equipes, sendo uma para cada
camada. O modelo organizacional por equipes de componentes
dirige o time para uma variedade de problemas como:
Nvel de comunicao reduzida em todas as camadas;
Trabalha com o sentimento de que o projeto apresentado no
contrato o suficiente;
Finaliza o desenvolvimento da camada sem um produto
potencialmente utilizvel.
das necessidades da equipe de recursos. No caso do Scrum, o

proprietrio do produto ir auxiliar a equipe de componente
priorizando as necessidades de seu produto, porm quando
a equipe de componentes est a frente da equipe de recursos,
preciso, na maioria das vezes, adivinhar quais sero as
necessidades seguintes. Muitas vezes isso resulta em componentes ou estruturas que no so utilizveis pelas equipes
de recursos. Esse um claro exemplo do que chamamos de
esforos desperdiados.
Qual o melhor cenrio?

Figura 2. Ilustrao de arquitetura de projeto
A proposta da equipe de recursos seria, em vez de ter equipes

separadas por camadas da arquitetura, termos as equipes de
recursos trabalhando em todas as camadas.
Algumas vantagens podem ser obtidas neste modelo organizacional, so elas:
As equipes de recursos tm mais habilidades para avaliar
o impacto das decises de projetos. Essa habilidade adquira
pelo fato do time construir a funcionalidade de ponta a ponta,
isso maximiza o aprendizado dos membros auxiliando nas
decises que se fazem necessrias para o projeto;
Reduz o desperdcio de esforos da equipe, ou seja, o risco de
criar funcionalidade demasiada consideravelmente menor;
Garante que as pessoas certas esto falando, ou seja, uma
equipe de recursos inclui todas as habilidades necessrias para
ir da idia a execuo do recurso;
Diminui o risco de integrao do componente com os recursos, ou seja, um componente desenvolvido pela equipe
de componente s tem valor depois de integrado ao produto
da equipe de recursos, sendo assim, o esforo para integrar
o trabalho da equipe de componente ao produto precisa ser
calculado.
Embora no exista uma regra para auxiliar a tomada de

deciso, necessrio compreender a fundo as vantagens e
desvantagens das equipes descritas acima para uma escolha
apropriada.
Nas grandes empresas, onde h diversas equipes, recursos
e sistemas que em algumas vezes so compostos por sistemas ou componentes, o modelo de equipes provavelmente
ser uma mistura entre equipes de recursos e equipes de
componentes.
recomendado uma certa inclinao para as equipes de recursos. Alguns especialistas acreditam que uma boa estratgia
para empresa gil permanecer no 70%-30% ou 80%-20% de
equipes de recursos para equipes de componentes. O especialista em projetos geis, Chad Holdor, ou como ele gosta de
ser chamado, o Agile Ninja, publicou um vdeo em seu blog
detalhando claramente as diferenas entre equipes de recursos
e equipes de componentes e no final recomenda um modelo
gil combinando membros da equipe de componentes para
fazer a equipe gil como ilustrado na Figura 3. Esse vdeo pode
ser encontrado no endereo: http://www.scaledagiledelivery.
com/2011/04/28/component-vs-feature-team/.
O especialista em projetos geis, Mike Cohn, publicou um

artigo em seu blog apresentando alguns benefcios obtidos
com a equipe de recursos que pode ser encontrado no endereo http://blog.mountaingoatsoftware.com/the-benefits-offeature-teams.
Equipes componentes
Embora seja fortemente recomendado o uso de equipes de
recursos, existem situaes em que a equipe de componentes
apropriada. Como seu prprio nome, uma equipe de componente aquela que desenvolve um software para ser entregue
a uma outra equipe do projeto, em vez de diretamente ao
cliente. Um exemplo seria uma equipe de componente desenvolvendo uma camada de mapeamento entre a aplicao e o
banco de dados.
O gerenciamento de equipe de componentes nem sempre
uma tarefa fcil. Geralmente as equipes de componentes
trabalham paralelas s equipes de recursos. importante
garantir que a equipe de componentes tenha conhecimento
10
Figura 3. Combinando membros da equipe de componentes para fazer a

equipe de recursos
A equipe de sistemas
Como visto, as equipes geis so os motores de produo
de um software. Aprendemos que cada equipe precisa ter
habilidades necessrias para especificar, projetar, codificar e
testar os componentes e recursos de seu domnio.
agilidade
No entanto, no nvel de programa, essas equipes formadas

por pessoas podem no ter todas as caractersticas necessrias
para concluir uma soluo completa. Com isso, s vezes se faz
necessrio adicionar uma equipe que complemente as equipes
de recurso ou componentes. Essas equipes so formadas de
sistemas que podem auxiliar nos testes de sistemas, sistema
de garantia da qualidade, sistema de integrao, suporte na
infraestrutura de desenvolvimento e etc.
backlog do programa como recursos normais, ou seja, usando

o mesmo conceito de histrias de usurios. Alguns exemplos
de como esses requisitos podem ser solicitados so:
O cliente solicita que o aplicativo funcione nos principais
navegadores do mercado;
O cliente exige que uma determinada funcionalidade seja
executada em no mximo 30 segundos;
O cliente solicita disponibilidade de 99,99% do sistema.
Equipe de gerenciamento e liberao

Nas melhores prticas que procedem uma empresa gil, para
cada produto existe um time de planejamento e lanamento
que a empresa utiliza para alinhar as equipes tcnicas com as
equipes de negcios para o lanamento.
Esta equipe necessria porque, embora as equipes geis
sejam habilitadas, no tem necessariamente a visibilidade
do negcio, ou at mesmo a autoridade para decidir quando
ser a entrega do produto para o usurio final. Geralmente
essa equipe formada pelos principais membros do nvel de
programa da empresa, tais como:
Linha de negcio;
Proprietrio e gerente do produto;
Representantes de marketing;
Gerentes associados aos produtos;
Equipe de implantao do produto.
recomendado que essa equipe faa reunies semanalmente ou em um perodo adequado importncia do produto.
A reunio tem como principal foco debater a situao do
produto, tais como: status; onde estamos; se vamos cumprir
a tempo nossos objetivos; mudanas necessrias; impactos,
entre outros.
O principal intuito desse encontro promover a visibilidade
ampla e o gerenciamento snior semanal para o estado de
liberao do produto.
Roteiro ou Roadmap
A equipe de gerenciamento e liberao no final de cada frum
resulta nos dados do planejamento da verso que so usados
para atualizar a planilha de roadmap.
O roteiro deve ser composto com as datas planejadas para
os lanamentos de cada soluo, cada qual com o consultor de
recursos priorizando conforme a necessidade do negcio. A
Figura 4 representa o modelo de um roadmap.
O roteiro est sujeito a alteraes em qualquer fase do produto, essas alteraes podem ser causadas por questes como:
prioridade de negcio, fatores tcnicos entre outros fatores
imprevisveis, portanto, no se deve fazer compromissos externos com planos alm do prximo lanamento.
Requisitos no-funcionais
A viso tambm precisa conter os requisitos no-funcionais,
tais como: confiabilidade, desempenho, qualidade, compatibilidade e etc. Os requisitos no-funcionais devem ser descritos no
Figura 4. Ilustrao bsica de uma planilha de roteiros
Teste de requisitos no-funcionais

Requisitos no-funcionais, como desempenho, disponibilidade e outros do gnero, so frequentemente descritos pelo cliente
como qualidade do produto, porm devem ser aplicados no
backlog como um histrico de usurio e tratado como recurso,
assim aplicando os testes para sua qualidade. A Figura 5 ilustra
um modelo simples para aplicao de testes de qualidade nos
requisitos no-funcionais.
Figura 5. Modelo bsico de teste de requisitos no-funcionais
Geralmente a maior parte dos requisitos no-funcionais (0..*)

requerem um ou mais testes. Neste cenrio, pode ser aplicado
outro tipo de testes de aceitao. Aplica-se ento os testes
de qualidade de sistemas. Este termo indica que estes testes
devem ser executados em intervalos peridicos no intuito de
validar o sistema.
Requisitos geis para a empresa

O terceiro e ltimo requisito gil que ser apresentado neste
artigo o nvel empresa ou portflio. Nesta etapa, encontramos
a funo de gesto de portflio que inclui equipes e organizaes dedicadas gesto dos investimentos e conformidades
com a estratgia de negcio da organizao.
Para muitas fbricas de software atualmente, independente
do tamanho de seus projetos ou equipes, o modelo de equipes junto ao modelo de programas podem ser o suficiente
para gerenciar seus projetos de forma gil. No entanto, para
empresas que contm muitos produtos em que a governana
e o modelo de gesto para o desenvolvimento de novos ativos
11
de software exige novos artefatos e nveis ainda mais altos de

abstrao, a incluso do modelo de portflio pode ajudar no
gerenciamento desses novos desafios.
importante que essa administrao ocorra de forma contnua em cada um dos nveis apresentados.
Requisitos de investimento
importante ressaltar que o modelo com nveis de equipes,

programas e empresas apresentados neste artigo uma definio arbitrria. Portanto, o objetivo fornecer um modelo
mental que ajude a elevar o alcance de abstrao e escala para
se obter agilidade no desenvolvimento de software.
Em resumo, vimos um conjunto de requisitos que so otimizados
para apoiar a entrega rpida das necessidades valiosas do cliente.
Tambm vimos como as equipes geis podem alcanar a qualidade
mais alta atravs de testes funcionais e automao de teste.
No nvel de programa, foram apresentados requisitos, artefatos
e processos que so necessrios para alcanar o desenvolvimento
gil. Foi apresentado um modelo organizacional para auxiliar na
montagem de equipes otimizadas para a entrega gil de valor.
E, para concluir, introduzimos o nvel de empresa. Nesta
fase foi apresentada de forma resumida uma abordagem sobre
os temas de investimento estratgico, gesto de portflio e
arquitetura de melhoria contnua.
A equipe de portflio pode ser formada pelos gerentes ou

responsveis pelo negcio. Os membros desta equipe so os
indivduos que tem a responsabilidade final com as linhas de
negcio. Em algumas empresas, esse processo pode ser comparado aos processos de elaborao oramentria anual.
A equipe de gesto de carteira/portflio toma suas decises
com base em uma combinao das seguintes opes:
Investimento em ofertas de produtos, melhorias, suporte e
manuteno;
Investimento em novos produtos, novos servios ou trabalho
comercial para ganhar novas fatias de mercado;
Reduzir investimento para as ofertas existentes que esto
chegando ao fim de sua vida til ou lucrativa.
Para fornecer governana e visibilidade nesta fase de investimentos, a equipe de gerenciamento de portflio pode ser dirigida pelas melhores prticas de um modelo de gerenciamento
de projetos como PMO.
Arquitetura: empresa, programa e equipe
12
Mike Cohns blog Succeeding with agile

http://www.mountaingoatsoftware.com/
Chad Holdorfs blog
http://www.scaledagiledelivery.com/
Dean Leffingwell, Agile Software Requirements: Lean Requirements Practices for Teams,
Programs, and the Enterprise, Addison-Wesley Professional, 2010.
Craig Larman; Bas Vodde, Scanling Lean & Agile Development, Addison-Wesly Professional, 2008
Chris Sterling; Brent Barton, Managing Software Debt: Building for Inevitable Change, AddisonProfessional, 2010.
Mike Cohn, Succeeding with Agile: Software Development Using Scrum, Addison-Wesley
Professional, 2009
D seu feedback sobre esta edio!

A Engenharia de Software Magazine tem que ser feita ao seu gosto.
Para isso, precisamos saber o que voc, leitor, acha da revista!
D seu voto sobre este artigo, atravs do link:
www.devmedia.com.br/esmag/feedback
Feedback
eu
sobre e
s
Ao obter maturidade gil a organizao tende a continuar a

construo e conservao de uma arquitetura de responsabilidade eficaz. Ao administrar e gerenciar esses nveis de requisitos que resultam em agilidade, a empresa pode evitar alguns
acontecimentos ruins, porm comuns, como por exemplo:
Atrasos considerveis para o lanamento do produto;
Reduo do risco de criar uma arquitetura sem capacidade
de se estender, deixando o sistema frgil e instvel a mudanas,
correndo o risco de ser totalmente reescrito;
Evita o desperdcio de esforos no desenvolvimento e maus
investimentos.
Links
D
s
Equipe de gesto de portflio
edio
ta
Um conjunto de temas de investimento estabelece os objetivos

de investimento em relao empresa ou unidade de negcio.
Este tema o item que representa uma srie de iniciativas que
impulsionam os investimentos da empresa para determinada
soluo, produto ou servio.
Concluso
Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros
Scrum e o gerenciamento de projetos Parte 3

O Scrum e a sua relao de aliana com o gerenciamento de projetos tradicional

Demonstrar como utilizar os artefatos de um gerenciamento gil como o Scrum, suportando e dando
apoio aos artefatos tambm complementares do
gerenciamento tradicional, apresentando como esta
unio pode ser benfica para um mesmo projeto,
principalmente na rea de gerenciamento das comunicaes, proporcionando um acompanhamento
transparente e bem prximo da execuo do projeto.

Este artigo visa demonstrar como resolver problemas
gerados por falhas de comunicao entre a equipe do
projeto, sua gerncia snior e o cliente, apresentando
formas de eliminar os buracos causados pela falta de
Fbio Cruz
fabiorcruz@gmail.com
Graduado na rea de TI e PMP certificado com mais de 17 anos de experincia

profissional, atuando sempre na rea de
desenvolvimento de sistemas, sendo os ltimos 10 dedicados liderana de equipes
e coordenao de projetos. Atualmente
gerente de projetos na empresa americana
Ascendant Technology, voluntrio no PMI
Chapter de Santa Catarina e autor do blog
www.fabiocruz.com especializado em gerenciamento de projetos.
ndependente do mtodo utilizado

para executar e gerenciar projetos, a
comunicao continua sendo a rea
mais importante quando se fala do sucesso em projetos. Simplesmente porque
a comunicao precisa acontecer para
que o projeto seja entendido, executado
e entregue.
Outro objetivo fundamental da comunicao manter a gerncia snior das
empresas envolvidas com o projeto informadas sobre o andamento do mesmo.
informao atravs da unio de artefatos de origem

gil com outros de origem tradicional, fornecendo
reflexes e provocando aes para unir as duas abordagens em um mesmo projeto.
Resumo
Para se gerenciar projetos de desenvolvimento de
softwares preciso estar constantemente atualizado com as informaes do projeto, e ao mesmo
tempo comunicar a todos os interessados com a
frequncia necessria. Este artigo mostra como
aliar os artefatos de uma abordagem gil como o
Scrum ao gerenciamento de projetos tradicional,
gerando benefcios e melhorando a comunicao
do projeto em vrias direes.
Entende-se gerncia snior, neste caso,

como o patrocinador do projeto (Sponsor)
e as demais gerncias compostas pelo
corpo diretivo responsvel pelo projeto,
tanto na empresa executora quanto na
empresa contratante.
Esta comunicao tem o objetivo
principal de posicionar e informar.
Normalmente estes posicionamentos
so requisitados periodicamente e
geralmente incluem anlises de valor
agregado, marcos principais (milestones),
13
ltimas realizaes do perodo, principais riscos, situao financeira atual do projeto, entre outras informaes relevantes
que podem variar um pouco de acordo com o projeto e com a
necessidade de informao das gerncias.
Quando o projeto est no incio, ou quando est tudo bem
controlado e o cliente satisfeito, a comunicao visando posicionar e informar costuma ser desvalorizada, feita de uma
forma resumida demais e deixando de ser um valor real para
quem as recebe, ou seja, deixando de informar aos interessados dados importantes sobre o projeto. Este comportamento
faz parecer que a comunicao no necessria quando tudo
est indo bem.
Por outro lado, quando o projeto est com problemas, ou
em fases crticas, um simples relatrio de situao do projeto
(Status Report) pode ser um drama para um gerente ou para
uma equipe despreparada, e que principalmente no estava
informando e posicionando desde o incio do projeto. Sendo
assim, o primeiro recado que a comunicao deve ser realizada sempre, durante todo o ciclo de vida do projeto.
A tarefa de comunicar e informar sobre o andamento do
projeto deve ser simples, e obrigatria para qualquer gerente.
Porm, esta atividade que deveria ser simples, pode se tornar
um pesadelo pelo simples fato da equipe de gerenciamento
no manter informaes atualizadas e bem documentadas
sobre o projeto. Esta falta de informao centralizada faz com
a equipe tenha que sair correndo atrs dos dados no dia da
apresentao do Status Report, ou aps a ligao da gerncia
snior pedindo informaes atualizadas.
Buscando evitar este tipo de problema e facilitar a comunicao geral de um projeto, este artigo se prope a apresentar
um modelo de unio de alguns artefatos de comunicao do
gerenciamento tradicional, com outros existentes no gerenciamento gil, mais especificamente no framework do Scrum,
com o objetivo de interligar todas as partes interessadas de um
projeto atravs de informaes corretas e bem distribudas.
Conceitos de gerenciamento gil e tradicional

Alguns conceitos importantes para o entendimento do Scrum
foram descritos nas primeiras duas partes desta srie de artigos, que foram publicadas nas edies 41 e 43 da Engenharia
de Software Magazine.
O framework do Scrum uma das prticas geis mais utilizadas atualmente, principalmente por trazer benefcios ao gerenciamento de projetos de software. Um destes benefcios mais
evidentes a forma com que o Scrum propicia a visualizao
dos trabalhos do projeto de forma direta, objetiva e simples.
Apoiado na qualidade do Scrum de contribuir para uma comunicao mais eficaz e eficiente, ser demonstrado aqui como
comunicar as informaes mais relevantes para um acompanhamento de um projeto que est sendo executado. O acompanhamento poder ser realizado pelo time de execuo, pela equipe
de gerenciamento operacional e pela gerncia snior.
Mais uma vez, como nos artigos anteriores desta srie,
mostraremos como o Scrum complementa o gerenciamento
tradicional, assim como o gerenciamento tradicional apia o
14
Scrum. Porm, no iremos comparar o Scrum a nenhuma abordagem tradicional especfica, mas sim tratar o gerenciamento
de projetos como uma rea de conhecimento geral, com seus
aspectos comuns em vrias abordagens de mercado.
A primeira parte tratou de papis e responsabilidades, a
segunda falou das prticas, ferramentas e tcnicas. Por fim,
nesta terceira parte, falaremos dos artefatos existentes nas duas
abordagens, agindo de forma complementar e influenciando
diretamente no resultado da comunicao do projeto.
Gerenciamento ativo e no reativo

Antes de sair comunicando, a equipe de gesto precisa ter o
que comunicar e saber como far a distribuio das informaes
coletadas. Este pode ser o ponto mais importante, que definir
uma boa ou uma m comunicao dentro de um projeto.
Um erro bsico que parece simples de ser evitado, mas na
prtica a sua ocorrncia ainda alarmante, que os gerentes
de projetos, ou as equipes de gerenciamento, no acompanham
o projeto de perto, e no possuem informaes constantemente
atualizadas. Isso gera um problema enorme, pois quando a
informao solicitada, a gerncia precisa reagir ao pedido e
sair correndo atrs dos dados.
Este gerenciamento reativo ruim para todo o projeto, podendo
gerar insegurana e a gerao de dados falsos, alm de demonstrar falta de metodologia implantada e organizao definida.
O objetivo deve ser sempre um gerenciamento ativo, ou seja,
no basta ter um modelo (template) de Status Report pronto
para ser usado, preciso ter sempre as informaes que sero
utilizadas para montar este relatrio, e estas preferencialmente
devem ser as mais recentes possveis. Neste ponto que o
Scrum pode nos ajudar com seus artefatos e regras.
Artefatos do gerenciamento tradicional

O primeiro passo na direo de uma boa comunicao
ter as definies do que, como e quando sero realizadas as
comunicaes do projeto.
Neste ponto, o gerenciamento tradicional um forte aliado,
pois quase todas as boas prticas e metodologias tradicionais
trazem em seu contedo a orientao de se criar um plano de
gerenciamento da comunicao.
Este plano fundamental e deve ser construdo e divulgado
no incio do projeto; o quanto antes melhor. Este documento
no precisa ser extenso ou completo, pelo contrrio, a orientao que seja curto e direto.
O objetivo de um plano de gerenciamento da comunicao
determinar que tipo de informao deve ser veiculada durante
o projeto, como estas devem ser divulgadas, qual deve ser a
frequncia de circulao de cada relatrio informativo, e por
fim, quem deve receber cada um deles.
Outro artefato bem relevante e que se encaixa perfeitamente no tema comunicao, o plano de gerenciamento do
projeto. Este plano poder conter o de comunicao, alm de
geralmente ser composto pelos planos de gerenciamento de
requisitos, escopo, mudanas, riscos e qualidade. Todos estes
sub-planos fornecem informaes importantes para vrias
Engenharia de Software Magazine - Scrum e o gerenciamento de projetos Parte 3
Gerenciamento d e Projetos
partes interessadas (stakeholders) pelo projeto, e geralmente

fazem parte do que ser comunicado durante o projeto.
O plano de projeto pode conter, inclusive, informaes
pertinentes de como as metodologias de gerenciamento de
projetos sero aplicadas e como funcionaro conjuntamente
ao longo do ciclo de vida do projeto. J o plano de comunicao dever informar quais artefatos sero utilizados,
quais suas finalidades e origens conceituais (Scrum ou
tradicional).
A partir destes documentos elaborados e divulgados corretamente, todos os responsveis ou interessados ligados diretamente ou indiretamente ao projeto, podero saber o que a
equipe gerencial usar como artefatos de comunicao, alm
de como e quando cada documento ser distribudo.
Note que esta preparao para se comunicar no decorrer
do projeto, j uma comunicao efetiva, e demonstra que
h clareza e transparncia na forma com que o projeto ser
conduzido e acompanhado.
monitoramento, usaremos apenas a estria que definiremos

a partir do seguinte padro:
Como um <tipo de usurio>, eu quero <um objetivo> para
que <atenda uma necessidade>.
Pegando o nosso item de Backlog cadastro de livros e criando
uma estria com o padro apresentado, teremos o seguinte:
Como um usurio administrador, eu quero cadastrar um livro
para que ele possa ser consultado por visitantes na internet.
Como pode ser observado, possvel resumir todas as necessidades em poucas palavras, permitindo que seja possvel colocar
este texto em um post-it conforme ilustrado na Figura 1.
Artefatos do Scrum
A partir das estrias definidas, o time poder trabalhar

na reunio de planejamento da Sprint. Lembrando que esta
cerimnia parte integrante do Scrum e foi descrita em mais
detalhes na Engenharia de Software Magazine 43.
O primeiro dos artefatos importantes do Scrum o Backlog

do Produto, que o conjunto de todos os requisitos e trabalhos
necessrios para entregar o projeto. Este artefato pode incluir
regras de negcios, prottipos de tela, casos de uso, entre
outros documentos relevantes.
Partindo de um Backlog do Produto completo para o projeto,
ou para uma verso de entrega (release), se consegue obter os prximos e mais detalhados documentos que fornecero os dados
importantes para que as comunicaes do projeto aconteam.
O Backlog do Produto se transforma no Backlog da Sprint,
que dever conter apenas os trabalhos selecionados para se
entregar na prxima Sprint. A partir desta seleo de itens do
Backlog, a equipe poder ser apresentada a outro artefato do
Scrum, as estrias dos usurios.
Falamos mais sobre Backlog do Produto na edio 43 da
Engenharia de Software Magazine.
Estrias do usurio
Uma estria do usurio (user story) uma descrio resumida
que representa um item do Backlog, devendo ser sempre do
ponto de vista do usurio final do produto. Em alguns casos um
item de Backlog poder dar origem a mais de uma estria, por
questes de entendimento, ou para uma melhor visualizao ou
at por uma estratgia de abordagem gerencial e de execuo.
Um item de Backlog pode possuir diversos documentos associados a ele, alm de especificaes detalhadas. Entretanto,
uma estria resume em poucas palavras o que a funcionalidade deve fazer, servindo como um timo item para controle e
acompanhamento. aqui que comeamos a ter artefatos para
melhorar a comunicao, principalmente no nvel gerencial.
Um exemplo para um fcil entendimento um cadastro
de livros, que um item de Backlog possuindo prottipo de
tela, modelo de dados, especificao de regra de negcio e
caso de uso. Estes so todos os documentos que compem o
item de Backlog cadastro de livros, porm, para controle e
Figura 1. Estrias em post-its
Tarefas
Na primeira parte desta reunio de planejamento, o time
entende as estrias e determina o tamanho de cada uma. Esta
estimativa servir como artefato para medir o desempenho
dos trabalhos no futuro. J na segunda parte, o time detalha
melhor as estrias, decompondo-as em tarefas menores.
Estas tarefas devem ter um tamanho apropriado para que
possam ser determinadas em horas para concluso, e devem
ser independentes de outras atividades para que sejam consideradas finalizadas.
O resultado desta decomposio das estrias em tarefas
menores ser um dos mais importantes artefatos de controle
que usaremos ao longo do projeto, pois estas tarefas menores
sero utilizadas para que toda a equipe do projeto saiba o que
precisa ser realizado, o que est sendo trabalhado e o que j
foi concludo.
Uma estria uma macro atividade, que resume um conjunto
de trabalhos. Este conjunto de trabalhos poder ser ilustrado
atravs de vrias tarefas associadas, que por sua vez vo compor a estria, como ilustrado na Figura 2.
Figura 2. Decomposio da estria em tarefas
15
Estamos falando destes dois artefatos porque precisamos

de dados para acompanhamento e monitoramento do projeto
conforme ele executado, alm de contribuir para o fornecimento de informaes consolidadas e atualizadas o mais
breve possvel. Com isso, comeamos a colocar em prtica a
comunicao do projeto durante a execuo.
Laranja: Tarefas planejadas;

Verde: Tarefas no planejadas;
Vermelho: Impedimento, ou seja, obstculo que est impedindo a realizao de uma tarefa. Geralmente colocado sobre
a tarefa impedida;
Amarelo: Tarefas de teste.
Quadro de Tarefas (Taskboard)
Com este quadro montado, a comunicao do projeto comea

a tomar uma forma naturalmente clara, objetiva e transparente.
Note que o quadro de tarefas ilustrado na Figura 3 pode ser
fsico, e com isso fixado em uma parede bem visvel para todos
os interessados nas informaes ali contidas.
Qualquer um que direcionar os olhares para o taskboard ver
rapidamente um conjunto de informaes condensadas em um
nico local, tais como:
1. Quantas tarefas esto sendo realizadas simultaneamente
(fazendo), o que fornece o nmero de pessoas trabalhando
no desenvolvimento. O tamanho do time representado pelo
nmero de estrias, pois uma pessoa s pode realizar uma
tarefa de cada vez;
2. Quantas tarefas j foram concludas (feito);
3. Quantas tarefas ainda esto aguardando para serem trabalhadas (fazer);
4. Qual o nmero de tarefas no previstas, ou seja, quantas so
da cor verde. Este item evidencia rapidamente qual o esforo
aplicado em atividades no planejadas;
5. Se algum est parado devido a algum impedimento, ou
seja, quantas tarefas esto sobrepostas com outras de cor vermelha. Este item mostra claramente os momentos de falta de
produo devido a fatores externos que no foram previstos
inicialmente;
6. Se a priorizao dos trabalhos est sendo seguida conforme
o planejado, pois de acordo com a regra do Scrum, somente
depois de todas as tarefas da primeira linha estarem na coluna
feito, que podem ser iniciadas as tarefas da segunda linha.
Neste caso, pode se tomar providncias ao perceber um item
sendo realizado fora de prioridade.
Este um dos artefatos fundamentais e caractersticos do

Scrum, e possivelmente o que mais contribui para a comunicao do projeto e colaborao do time.
O quadro de tarefas nada mais do que um espao reservado para se colar ou fixar os post-its com as estrias e tarefas,
separados por colunas e cores diferentes que proporcionam
uma rpida identificao da atividade e sua situao, conforme
ilustrada na Figura 3.
Figura 3. Quadro de tarefas do Scrum
O formato mais utilizado para montar o quadro de tarefa :

Coluna 1: As estrias so colocadas uma embaixo da outra,
na sequncia da mais importante para a menos importante
de cima para baixo;
Coluna 2: As tarefas a fazer ao lado direito da sua respectiva estria;
Coluna 3: As tarefas que o time est fazendo, tambm ao
lado da sua respectiva estria;
Coluna 4: As tarefas j concludas (feito), na ltima coluna
direita, tambm seguindo a mesma linha da sua respectiva
estria;
Colunas complementares: Aps a quarta coluna pode haver
a coluna no planejados, para o agrupamento de tarefas no
previstas e que surjam ao longo do desenvolvimento, e/ou
colunas antes da feito, para separao de itens na etapa de
testes, por exemplo.
Alm das colunas distintas para cada etapa do desenvolvimento, tambm sugerido que as tarefas sejam colocadas em
post-its menores que as estrias e que seja adotada uma cor
diferente para cada tipo de tarefa, por exemplo:
16
Este quadro de tarefas tambm pode ser virtual, a partir da

utilizao de softwares de gerenciamento gil de projetos que
permitem o cadastramento, acompanhamento e divulgao
completa do taskboard. Um exemplo de uma ferramenta com
estas funes o Rational Team Concert (RTC), que permite
o cadastro de projetos, de times, de Backlogs, de estrias e de
tarefas, alm do acompanhamento da taskboard e do grfico
de Burndown.
Outro detalhe importante sobre o taskboard que os prprios
integrantes do time mantm as tarefas atualizadas no quadro
pelo menos uma vez por dia, com influncia principalmente da
cerimnia conhecida como reunio diria, que pode ser vista em
maiores detalhes na segunda parte desta srie de artigos.
Grfico de Burndown
A Sprint a principal iterao no Scrum, e ela nos ajuda a dimensionar os trabalhos e controlar o projeto em ciclos menores
de at um ms. Maiores detalhes sobre as Sprints podem ser encontrados na Edio 42 da Engenharia de Software Magazine.
A Sprint contm um conjunto de trabalhos a ser realizado em
um determinado espao de tempo, por isso ela muito til para
acompanhar a evoluo do projeto. Porm, como fazer este acompanhamento e saber se o projeto est atrasado ou adiantado?
A resposta no to difcil quanto parece, principalmente
depois de termos falado sobre o Backlog da Sprint, estrias
e tarefas.
Todas as tarefas que precisam ser realizadas dentro da Sprint
esto no taskboard, no entanto apenas olhar para o quadro de tarefas no diz a equipe de gerenciamento se o projeto est em dia ou
no. Para resolver este problema entra em ao o ltimo artefato
do Scrum que nos interessa aqui, o grfico de Burndown.
O Scrum como abordagem gil se preocupa com o esforo
restante para se terminar o trabalho, e no com o que j foi
concludo. Em outras palavras, o que importa no controle
do Scrum a quantidade de tarefas que ainda precisam ser
completadas at o final da Sprint.
O grfico de Burndown representa visualmente a soma
das estimativas dos esforos restantes para se terminar os
trabalhos contidos no Backlog da Sprint. Por isso, olhando o
grfico ilustrado na Figura 4, temos esquerda uma coluna
com a quantidade de trabalho que precisa ser completada,
sendo que no primeiro dia da Sprint o trabalho restante ser
igual ao trabalho total.
Figura 4. Grfico de Burndown.
Os dias esto na linha inferior do grfico, e o acompanhamento simples. Em resumo, o dia atual deve ter menos trabalho
restante do que o dia anterior. Visualmente podemos fazer uma
comparao fcil que nos ajudar muito na identificao da
evoluo dos trabalhos, permitindo saber se esto adiantados
ou atrasados, da seguinte forma:
1. No primeiro dia da Sprint, monte o grfico colocando na
coluna da esquerda a quantidade de trabalho necessrio para
completar a Sprint;
2. Na linha inferior coloque os dias em que a Sprint ocorrer;
3. Por fim, trace uma linha ligando o total de trabalhos que
precisam ser completados (coluna esquerda) ao ltimo dia da
Sprint ( direita). Esta linha representar a velocidade mdia
do time para atingir a meta da Sprint;
4. Ao final de cada dia da Sprint, ou no mximo no incio de

cada dia, marque no quadro a quantidade de trabalho restante
na coluna referente ao dia especfico;
5. Trace uma nova reta ligando os pontos marcados com o total
de trabalho restante a cada dia. Pronto, voc ter a velocidade
real do time.
Na ilustrao da Figura 4, a linha vermelha representa a
estimativa dos trabalhos a serem completados por dia, ou seja,
a velocidade esperada marcada no incio da Sprint.
A linha azul mostra a velocidade real do time de acordo com
os trabalhos que esto sendo completados a cada dia. Caso a
linha azul (real) esteja acima da linha vermelha (estimada), a
Sprint est atrasada, caso contrrio, est adiantada.
Para a opo do quadro fsico fixado em uma parede, o time
do projeto pode atualizar as tarefas antes ou durante as reunies dirias, que a melhor opo.
Para a opo de taskboards virtuais atravs de softwares, opte
por ferramentas que se integrem com os ambientes de desenvolvimento e j atualizem automaticamente as tarefas em tempo
real. Por exemplo, quando um desenvolvedor encerra uma tarefa
pela ferramenta de desenvolvimento, esta por sua vez atualiza
o software que mantm a taskboard tambm atualizada.
Comunicao visual
Seguindo as etapas descritas, e principalmente usando os
artefatos sugeridos pelo Scrum, teremos uma comunicao
visual muito eficiente. A equipe de execuo e gerncia do
projeto, bem como a gerncia snior que tenha acesso ao quadro de tarefas e ao grfico de Burndown, ter total acesso ao
andamento do projeto.
Informaes como quantidade de trabalho estimado e realizado, equipe alocada, planejamento, imprevistos, velocidade,
riscos e atrasos podero ser visualizados por todos, mantendo
todas as informaes relevantes claras e transparentes.
O impacto visual tem ainda uma caracterstica importantssima. Provavelmente muitas pessoas olham para estas evidncias destacadas e pensam: Mas com isso os meus erros e os da
minha equipe ficaro a mostra!. Exatamente! E por isso que
este modelo de trabalho se torna to interessante.
Os problemas e falhas realmente ficaro evidenciados, se
tornando um problema para os times que no buscam melhorar
e corrigir seus defeitos. Para os demais, os resultados sero os
melhores possveis, porque a prpria equipe buscar a cada
iterao (Sprint) melhorar os seus resultados.
Os bons times buscaro transformar o taskboard em uma
evidncia de seu bom trabalho, e no em um problema que
mostra para todos os seus erros. Esta qualidade que o Scrum
proporciona pode ser entendida como um processo de melhoria contnua.
Comunicao formal
Com os trabalhos sendo realizados conforme as definies
do tradicional plano de gerenciamento do projeto e seguindo
as cerimnias, regras e artefatos do Scrum descritos at agora,
17
Figura 5. Cronograma com milestones
no vo faltar dados para se montar relatrios de situao e

informaes relevantes para reunies de acompanhamento.
Mesmo com metodologias geis de gerenciamento de projetos, como Scrum, haver momentos em que ser preciso
gerar documentos formais para divulgao s gerncias, patrocinadores, clientes, parceiros, e outros. Alm de que estes
relatrios podem ser oficiais para aceite e/ou recebimento de
parcelas financeiras de trabalho completado ou simplesmente
para acompanhamento gerencial.
A partir do plano de comunicao realizado no incio do projeto, a equipe gerencial ter no planejamento oficial do projeto
alguns documentos conhecidos como meios de comunicao,
podendo ser, por exemplo:
1.Cronograma de tarefas atualizado, principalmente evidenciando milestones, disponibilizado na internet em sites seguros
com acesso restrito;
2. Relatrios de situao divulgados semanalmente por
e-mail;
3. Apresentaes executivas para o comit gestor, realizadas
mensalmente.
Cronograma Macro (milestones)

O cronograma uma ferramenta muito importante e interessante para apoiar os trabalhos do gerente de projetos,
porm pode ser extremamente penosa e atrapalhar quando
mal utilizada.
O detalhamento excessivo um problema comumente encontrado nos cronogramas, e que dificulta muito o seu uso.
Se este documento fosse criado apenas uma vez e nunca mais
alterado, tudo bem, mas na vida real dos projetos isso quase
impossvel. Quanto mais detalhado o cronograma, mais manuteno ele ter.
Para evitar este problema, uma sugesto utilizar este documento de apoio sem grande detalhamento de itens, tarefas ou
nveis. Monte um cronograma mais macro e apenas com fases,
milestones e iteraes (Sprints), como ilustrado na Figura 5.
Perceba que o cronograma fica mais enxuto, mas sem deixar
de fornecer as informaes importantes sobre datas e etapas
concludas. Claro que ele s funcionar corretamente se no
18
incio do projeto for divulgado o contedo previsto dentro de

cada fase e etapa ilustrada no cronograma.
A boa comunicao fica evidente quando h eliminao de
duplicidades e de excesso de dados em relatrios de acompanhamento peridicos. Se voc precisar colocar todas as informaes
do seu projeto, detalhadas ao mximo, em todos os seus relatrios de situao semanal ou mensal, com certeza houve falhas
graves de comunicao inicial, e estas continuam ocorrendo.
Relatrios de situao (Status Report)

Dependendo do tamanho, complexidade, valor ou importncia de um projeto, os interessados nele podem querer
informaes resumidas sobre a sua situao semanalmente,
quinzenalmente, mensalmente ou em outra frequncia prdefinida. Por isso de suma importncia que a equipe de
gerenciamento do projeto esteja preparada para fornecer as
informaes relevantes sempre que necessrio.
O Status Report um documento geralmente muito requisitado e utilizado por gerentes do mundo inteiro. O formato
ideal aquele que consegue condensar todas as informaes
importantes em uma nica pgina. Principalmente porque o
objetivo deste relatrio informar rapidamente qual a situao
do projeto, e para isso ele precisa ser objetivo para que quem
o receba o leia na ntegra.
A equipe gerencial precisa ser clara e direta com problemas,
solues, dificuldades, fracassos e at mesmo com os sucessos
e resultados obtidos. Ento no preciso fazer documentos extensos e cansativos. Informe o que preciso, e se for necessrio,
o interessado solicitar uma reunio ou documentos auxiliares
para esclarecimentos e maiores detalhes.
Um contedo interessante para um Status Report objetivo
apontar a situao geral dos trabalhos completados, podendo
ser atrasado, em dia ou adiantado, e a situao financeira do
projeto, apontando se os gastos esto dentro do previsto, abaixo
ou acima do oramento.
Como complemento, a equipe gerencial pode colocar a fase
em que o projeto se encontra e as ltimas realizaes. Alm do
apontamento de riscos para os prximos perodos e eventuais
obstculos que estejam impedindo os trabalhos.
Alm dos cronogramas e relatrios divulgados para os

stakeholders do projeto, frequentemente h necessidade de apresentaes executivas para um comit gestor, como presidentes,
diretores e conselheiros.
Mais uma vez os materiais j gerados e utilizados para execuo, acompanhamento e comunicao do projeto sero teis.
Geralmente os gerentes montam apresentaes em ferramentas como o Microsoft PowerPoint, e resumem os dados do
ltimo cronograma atualizado e do ltimo Status Report para
compor a apresentao.
Dependendo do projeto a apresentao focada mais na
parte financeira, ou mais na parte de valor agregado e tarefas
completadas, no costumando fugir muito disso. Mais uma
vez as informaes necessrias para a montagem de uma
apresentao como esta podem ser coletadas, acompanhadas e
resumidas atravs dos processos descritos neste artigo, ficando
mais fcil e rpido resgat-las no momento oportuno.
Concluso
Links
Introduo ao Scrum, blog FabioCruz.com
www.fabiorcruz.wordpress.com/outros/introducao
Introduo ao PMBOK, blog FabioCruz.com
www.fabiorcruz.wordpress.com/pmbok%c2%ae/introducao
Scrum Guide 2011, escrito por Ken Schwaber e Jeff Sutherland
www.scrum.org/scrumguides

Feedback
eu
19
sobre e
s
Tendo a comunicao como principal ferramenta de trabalho

para se atingir o objetivo do projeto, possvel se alcanar
excelentes resultados. Principalmente quando se segue boas
prticas e teorias reconhecidas pelo mercado, tais como o
Scrum, combinando-as com experincias reais em projetos que
foram bem sucedidos com a ajuda de uma boa comunicao.
Como foi demonstrado, o Scrum uma tima abordagem
para melhorar a comunicao de todo o time do projeto
durante a execuo do mesmo, mostrando claramente quais
trabalhos devem ser feitos, ou esto sendo realizados, ou j
foram completados.
Os artefatos deste gerenciamento gil tambm fornecem
informaes sobre velocidade e tamanho da equipe, riscos
evidentes atravs de impedimentos ou obstculos aos trabalhos do time, alm da situao atual do projeto, mostrando a
evoluo de tarefas completadas.
D
s
Reunies de comit executivo
O Scrum ainda fornece informaes para as comunicaes

mais formais e que precisam seguir linhas mais oficiais de divulgao, aprovao e registro, tais como cronogramas, relatrios
de situao e apresentaes executivas para comits gestores.
Esta unio de modelos tradicionais com o gil mais uma vez
se mostra positiva, e quando bem aplicada e complementada,
apia de forma bem dinmica e objetiva as equipes de gerenciamento de projetos.
Conforme o uso em conjunto destes dois modelos for cada
vez mais aplicado, e os resultados forem expressivamente
positivos, mais ficar evidente que no podemos considerar o
tradicional melhor que o gil, e nem to pouco o gil melhor
que o tradicional.
As equipes de gerenciamento de projetos modernas e que
querem sobreviver neste mercado rpido, furioso e muitas
vezes cruel, no podem se apegar a apenas um conjunto de
conceitos, e precisam se adaptar, observar e acompanhar as
mudanas do mercado, das tecnologias e das metodologias.
Nada perfeito, nem os seres humanos, nem as mquinas e
nem to pouco os processos ou modelos, portanto, quando se
tem em mente que se pode unir os melhores pontos positivos
de cada abordagem, buscando uma melhor metodologia de
aplicao, as chances de sucesso so bem maiores do que
apostar todas as fichas em apenas uma delas.
Lembre-se sempre que o objetivo principal do gerenciamento
de projetos, independente da abordagem, se resume a entregar
um projeto com sucesso. Por isso pense sobre a possibilidade
de unio de um modelo gil como o Scrum a um modelo tradicional, somando os pontos positivos, subtraindo os pontos
negativos, e obtendo como resultado final o sucesso de forma
mais controlada, fcil e segura.
edio
ta
Todas estas informaes so encontradas facilmente com o

resultado da aplicao das cerimnias do Scrum como a reunio diria, review e retrospectiva. Outra fonte de informao
a anlise das tarefas controladas pelo taskboard, e pela situao
do projeto mostrado no grfico Burndown.
Por isso to importante seguir as boas prticas de um
modelo ou metodologia. No s burocracia, so passos na
direo de solucionar problemas rotineiros e que podem ser
evitados. Seguindo as cerimnias, regras e artefatos do Scrum,
naturalmente ser gerado insumo para realizar a comunicao
do projeto de forma rpida, segura e eficiente.
Engenharia
Estimativas de tamanho em projetos de

software utilizando pontos de funo
Um tutorial voltado para micro e pequenas empresas
Jhoney da Silva Lopes

jhoney.lopes@gmail.com
Graduando em Cincia da Computao

pela Universidade Federal de Viosa (UFV).
Atualmente Diretor Presidente da empresa jnior No Bugs (www.nobugs.com.
br), Assessor da presidncia da Skep Design
(www.skepdesign.com) e Diretor VicePresidente de O Primeiro Plano. reas de
interesse: Engenharia de Software, Empreendedorismo, Gerenciamento de Projetos e
Business Intelligence.
Jos Luis Braga

zeluis@dpi.ufv.br
Ps-doutoramento em Tecnologias da Informao na University of Florida. Doutor

em Informtica pelo Departamento de Informtica da PUC-Rio. Mestre em Cincias
da Computao pelo Departamento de Cincia da Computao da UFMG. Atualmente Professor Titular do Departamento de
Informtica do Centro de Cincias Exatas
e Tecnolgicas da Universidade Federal
de Viosa-MG. Atua na rea de Cincia da
Computao, com nfase em Engenharia
de Software e Sistemas de Informao.
reas de Interesse: Qualidade de Software
com Foco em Processos, Engenharia de
Software Experimental, Engenharia de
Software Apoiada por Ontologias, Engenharia de Software Baseada em Agentes,
Sistemas de Apoio Deciso.
20
Resumo
Estimativa de software com derivaes em custo, prazo e esforo uma necessidade comum entre as empresas de TI. Nesse contexto, o objetivo deste artigo
apresentar de forma simples, por meio de exemplos,
o uso de um mtodo poderoso para a soluo destes
problemas recorrentes, a APF (Anlise de Ponto de
Funo).
Anlise de Ponto de Funo um mtodo de medio
do tamanho funcional de um software, com base em
operaes extradas dos requisitos funcionais. A partir
dessa medio inicial de tamanho, derivam-se outras
medidas como, por exemplo, o tempo necessrio para
desenvolvimento, e uma estimativa inicial de custos.
APF tem por definio medir o que o software deve
fazer, e no como ele deve ser construdo, portanto o
processo de medio fundamentado em uma avaliao padronizada dos requisitos lgicos do usurio.
Na fase inicial de um projeto, a necessidade em obter o custo, prazo e o esforo observado em todas
as empresas, pois as mesmas precisam gerar um
oramento para os seus clientes e avaliar uma srie
de projees. Este artigo organiza de forma simples e introdutria conhecimentos sobre a Anlise
de Ponto de Funo.
Inicialmente no se tem conhecimento de todas as
caractersticas do produto bem como da sua real
dimenso, por esse motivo necessrio utilizar
tcnicas de extrao de requisitos para realizar um
levantamento inicial dos mesmos e compreender
melhor o problema. Os requisitos so condies, caractersticas ou capacidades necessrias para atingir
uma finalidade, categorizados na implementao
de sistemas em funcionais e no funcionais como
forma de estabelecer critrios de qualidade.
Uma vez definidos os requisitos, pode-se ento
avaliar o tamanho do sistema em termos de suas
funcionalidades. Existem vrios mtodos de estimativa, a APF (Anlise de Ponto de Funo) uma
delas. Esse mtodo no tem como objetivo realizar
estimativas de prazo, custo e esforo para implementao de sistema, mas sim avaliar o tamanho
de um sistema em termos de suas funcionalidades.
Resulta desta avaliao o tamanho funcional do
sistema expresso em Pontos de Funo (unidade
de medida do mtodo). A partir do tamanho funcional, podem ser derivadas estimativas adicionais, como tempo e custo.

Na fase inicial de um projeto, existe a necessidade de obter o custo, prazo e o esforo de implementao para estabelecimento de contratos de
desenvolvimento. Anlise de Ponto de Funo
um mtodo de medio do tamanho funcional de
software que permite fazer essas avaliaes com
base em informaes disponveis nas fases iniciais
dos projetos. O uso do mtodo profissionaliza a
avaliao inicial de tamanho, permitindo repetio do processo e aumento do nvel de maturidade
no gerenciamento de projetos.
Engenharia de Software Magazine - Estimativas de tamanho em projetos de software utilizando pontos de funo
ste artigo apresentar uma viso geral sobre todos os

passos necessrios para utilizao da anlise de ponto
de funo, para a realizao de estimativas na fase
inicial de um projeto de desenvolvimento, proporcionando
ao leitor uma viso restrita do mtodo, mas suficiente para
estimar um projeto em sua fase inicial e, com isso, realizar
derivaes de acordo com suas necessidades.
A anlise por pontos de funo surgiu em 1979 na IBM
(International Business Machines) e foi desenvolvida por Alan
Albrecht. A aceitao foi muito grande, e uma quantidade
cada vez maior de pessoas comearam a utilizar o mtodo,
resultando na criao do IFPUG (International Function Point
Users Group). Hoje o mtodo mantido e evoludo pelo IFPUG
e fundamenta-se em seis passos:
1. Determinar o tipo de contagem;
2. Identificar o escopo da contagem e a fronteira da
aplicao;
3. Contar funes:
a. Tipo dados;
b. Tipo transao;
4. Determinar a contagem de pontos de f uno no
ajustados;
5. Determinar o valor do fator de ajuste;
6. Calcular o nmero dos pontos de funo ajustados.
a viso do desenvolvedor, ou seja, uma viso tcnica. Na APF

o que importa a viso do negcio e quem possui essa viso
o usurio, lembrando que usurio na APF possui um conceito amplo e no somente a pessoa que ir interagir com o
software final.
Nota do DevMan 2
Funcionalidade: Funcionalidade o conjunto de tarefas fornecidas pelo sistema para
poder realizar transao, processamento e armazenamento dos dados dos usurios.
Determinar o tipo de contagem

O primeiro passo para a contagem ser determinar qual o tipo
de contagem a ser realizada, como pode ser visto na Figura 1.
Na APF existem trs tipos de contagem:
Projeto de desenvolvimento;
Projeto de melhoria;
Aplicao.
Como foi dito, a APF um mtodo que visa medir o tamanho funcional de um software do ponto de vista do usurio e
possui como unidade de medida o ponto de funo (PF) (ler
Nota do DevMan 1).
Nota do DevMan 1
Usurio: Em Anlise de Ponto de Funo, usurio possui um conceito mais amplo:
qualquer entidade que se relacione com o sistema ou que produza um nus ao mesmo. Ex: Pessoa, aplicao, leis, restries, etc.
importante perceber que para a APF o usurio no somente a pessoa que interage com o sistema.
Possui como base os seguintes objetivos:

Medir as funcionalidades (ler Nota do DevMan 2) implementadas no sistema;
Medir esforo de implementao e de manuteno do software, independente de tecnologia, ou seja, a APF leva em considerao o que o software faz e no como ele construdo;
Simplicidade, o trabalho para aplicar a APF deve ser o mnimo possvel, ele no deve ser um nus no desenvolvimento
do software.
importante ter em mente, durante todo o processo da
utilizao do mtodo de anlise de pontos de funo, que o
usurio quem define o que faz parte ou no do projeto, diferentemente de alguns mtodos que levam em considerao
Figura 1. Passos para a contagem dos pontos de funo (VAZQUEZ, 2009)
Este artigo tem por objetivo apresentar a soluo de contagem

para projeto de desenvolvimento, mas sero apresentadas as
diferenas entre elas.
Projeto de desenvolvimento
caracterizado como projeto de desenvolvimento, um novo projeto desde a fase de extrao de requisitos (ler Nota do DevMan 3)
at a instalao do mesmo. Neste tipo de projeto so contadas
na APF todas as funcionalidades fornecidas aos usurios at a
instalao do sistema, ou seja, funcionalidades de converso (ler
Nota do DevMan 4) tambm so contadas. S se pode saber todos
os requisitos de um sistema aps o trmino do projeto, sendo
assim, toda a contagem de um projeto de desenvolvimento pode
ser entendida como estimativa e no medio.
Projeto de melhoria
O projeto de melhoria mede todas as funcionalidades novas, modificadas e excludas de um determinado sistema.
Ao trmino de um projeto de melhoria a aplicao dever
ser contada com o intuito de atualizar o valor em pontos de
funo da mesma.
21
Nota do DevMan 3
Requisitos: So as necessidades e caractersticas que o sistema deve ter para atingir as expectativas do cliente. A extrao dos requisitos consiste em uma parte crtica
na elaborao de uma proposta, ela parte determinante do sucesso ou fracasso de
um projeto.
Nota do DevMan 4
Funes de Converso: Para um entendimento considere o exemplo: um sistema
A possui uma lista de funcionrios cadastrados, o sistema B sendo contado dever
incluir todos esses funcionrios em sua base de dados, essa funcionalidade ser disparada uma nica vez que durante a instalao do sistema, sendo caracterizada como
funo de converso.
Nota do DevMan 5
Escopo do Projeto: Escopo do projeto o trabalho que precisa ser realizado para
entregar um produto, servio ou resultado com as caractersticas e funes especificadas (PMBOK, 2004), o escopo da contagem tudo aquilo que deve ser contado.
Uma sugesto simples para no errar nesta etapa seguir

a regra do IFPUG que determinar a fronteira da aplicao
baseado no Ponto de Vista do Usurio. O usurio define o que ele
entende sobre as atribuies do sistema e de cada aplicao.
Considera-se o exemplo apresentado na Figura 2, que mostra
trs aplicaes, AP01, AP02 e AP03, separadas por fronteiras
(crculos tracejados) e cada uma dessas aplicaes interagem
umas com as outras, esta interao feita a partir do que
chamado de arquivos lgicos, que aparecem na figura como
quadrados preenchidos de preto.
Aplicao
Entende-se por contagem do tipo aplicao um software
instalado, ou seja, a contagem aps o trmino de um projeto
de desenvolvimento. Neste caso, no se leva em considerao
as funes do tipo converso.
Aplicando o conhecimento Determinar o tipo de

contagem
Neste artigo ser realizada a contagem de um projeto
simples, extrado da base de projetos da No Bugs - Empresa
Jnior do Bacharelado em Cincia da Computao da Universidade Federal de Viosa.
O foco deste artigo so as derivaes dos pontos de funo
para auxiliar na elaborao da proposta do projeto para o
cliente. A sua contagem ser de um projeto de desenvolvimento, um sistema simples de locao de veculos.
Identificar o escopo da contagem

O segundo passo para a contagem identificar o escopo
da contagem e a fronteira da aplicao, como pode ser
visto na Figura 1. Muitas vezes a identificao do escopo
e da fronteira da aplicao no so levados to a srio,
principalmente por empresas que no utilizam gerncia
de projetos no gerenciamento do desenvolvimento de
software.
Esta uma etapa crucial para o andamento do projeto,
a definio de um escopo (ler Nota do DevMan 5) errado
pode acarretar em prejuzos para o projeto ou at a perda
total dele. O escopo define quais funes sero includas
na contagem, ele pode abranger todas as funcionalidades,
apenas as funes utilizadas ou funes especficas.
A fronteira da aplicao a linha que separa uma aplicao de outra. Dentro de um escopo de contagem pode
existir mais de uma aplicao a ser contada, por isso
importante definir qual a sua fronteira.
22
Figura 2. Arquivos lgicos e fronteiras das aplicaes
Aplicando o conhecimento Identificar o escopo da

contagem
Como foi visto, nesta etapa devemos definir o escopo da
contagem e a fronteira da aplicao. No exemplo deste artigo,
trata-se de software destinado a uma empresa que realiza
locao de automveis, o sistema simples e composto por
uma nica aplicao.
Contar funes do tipo dados

O terceiro passo para a contagem dividido em duas partes, contar funes do tipo dados e contar funes do tipo
transao, como pode ser visto na Figura 1. Funes do tipo
dados o nome designado s funcionalidades fornecidas para
o armazenamento de dados na aplicao sendo contada (ler
Nota do DevMan 6), so caracterizados como arquivos lgicos e
eles podem ser mantidos pela aplicao ou lida de outra, como
pode ser visto na Figura 2.
Arquivos lgicos que esto dentro da fronteira da aplicao
e mantidos pela mesma so chamados de Arquivos Lgicos
Internos (ALI), j os arquivos lgicos lidos de outra aplicao

so chamados de Arquivos de Interface Externa (AIE).
Nota do DevMan 6
Aplicao Contada: Como visto, um projeto pode ser composto por vrias aplicaes internas que interagem umas com as outras, conforme a Figura 2. Quando um
projeto possui mais de uma aplicao, diz-se da aplicao sendo contada a que no
momento est sendo analisada, j projetos que possuem apenas uma aplicao, o
termo aplicao sendo contada refere-se a todo o projeto.
Arquivo Lgico Interno

Grupo lgico de dados persistentes e que so mantidos dentro
da fronteira da aplicao e alterados por meio de processos
elementares. Um processo elementar a menor unidade de
atividade significativa para o usurio final (VAZQUEZ,2009).
a menor funcionalidade disponibilizada ao usurio.
Considerando a Figura 2, a AP01 possui trs arquivos lgicos
internos (ALI). primeira vista, parecer que cada tabela do
banco de dados da aplicao ser um ALI. Essa uma maneira
simples de entender o que seria um arquivo lgico, mas sero
mostrados alguns exemplos de que um erro pensar dessa
forma, pois um grupo de tabelas pode ser considerado como
um nico arquivo lgico, dependendo da forma como utilizado pela aplicao.
Exemplos de ALI:
Arquivo de configurao, conexo, segurana (senhas) mantidos pela aplicao;
Tabelas ou grupos de tabelas do banco de dados mantidas
pela aplicao.
No so exemplos:
Arquivos temporrios ou de backup;
Tabelas temporrias ou views.
Arquivo de Interface Externa
Grupo lgico de dados persistentes mantidos dentro da fronteira de outra aplicao, mas requerido ou referenciado pela
aplicao que est sendo contada, ou seja, a aplicao sendo
contada acessa os dados presentes neste arquivo lgico, mas
o mesmo no est dentro da aplicao que est sendo contada
e sim em outra. Nesse caso denomina-se esse arquivo lgico
de arquivo de interface externa (AIE).
Considerando a Figura 2, a AP01 referencia arquivos lgicos
da AP02 e AP03, estes so os arquivos denominados de AIE.
Exemplos de AIE:
Dados de segurana armazenados em arquivos lgicos e
mantidos por aplicaes especficas a este fim;
Dados salariais armazenados na aplicao financeira, mas
utilizados pela aplicao contada.
No exemplo:
Dados armazenados na aplicao sendo contada e utilizados
por uma aplicao externa. Nesse caso a sua aplicao possui
um ALI e outra aplicao reconhece esses dados vindos de
um AIE.
Determinao da complexidade e da contribuio
Complexidade o grau de influncia que um arquivo lgico
tem para o tamanho funcional do sistema. A contribuio
a converso do grau de complexidade em pontos de funo.
A complexidade calculada a partir da contagem dos tipos de
dados e dos tipos de registro.
Tipos de dados (TD)
um campo no recursivo de dado, nico e reconhecido pelo
usurio, em uma viso geral e limitada. Por exemplo, poderiam
ser os atributos de uma tabela.
Tipos de Registro (TR)
caracterizado por ser um subgrupo de dados.
Em uma anlise mope, quando um agrupamento de tabelas
reconhecido pelo usurio como um nico arquivo lgico,
ALI ou AIE, a tabela reconhecida pelo usurio contada e as
demais se tornam simplesmente tipos de registro, ou seja, essas
tabelas extras no pertencem viso do negcio, pois o usurio
no as reconhece. Mas seus atributos so reconhecidos e, por
este motivo, devem gerar um impacto na contagem, sendo
denominado subgrupo de dados. Esses campos pertencentes
viso do negcio e reconhecidos pelo usurio so atribudos
aos demais arquivos lgicos que esto relacionados com esses
tipos de registro.
Considera-se como exemplo uma especializao, onde a
Figura 3 representa essa especializao na viso do usurio,
com os seguintes campos: id_func (cdigo de identificao do
funcionrio), salrio, cro (nmero do registro para dentistas),
bolsa (bonificao no salrio dos auxiliares).
Figura 3. Especializao na viso do usurio

Na modelagem, foram separados os diferentes tipos de funcionrios, como pode ser visto na Figura 4.
Neste exemplo contam-se os funcionrios como uma ALI ou
AIE, pois como foi apresentado, o usurio no reconhece funcionrios como entidades diferentes, mas para a modelagem o
desenvolvedor optou por separar estes funcionrios devido aos
atributos que os especializam. Como estas entidades criadas na
viso do desenvolvedor possuem atributos reconhecidos pelo
23
usurio, esse grupo de tabelas se constitui em uma ALI ou AIE

com trs tipos de registro e esses atributos reconhecidos devem
ser contados como atributo de funcionrios. So contados trs
tipos de registro, pois todo arquivo lgico um tipo de registro
dele mesmo e os atributos so somados a funcionrios, pois
somente ele reconhecido pelo usurio.
importante perceber que esta soluo adotada uma vez que
o usurio enxerga Auxiliar e Dentista como Funcionrio, e no
como entidades separadas, como pode ser visto na Figura 5.
imprescindvel entender que um mesmo problema pode ter uma
contagem diferente com vises de negcios diferentes, ou seja,
o importante o ponto de vista do usurio para a APF.
Tabela de contribuio
A tabela de contribuio padronizada pelo IFPUG, e todos
os usurios do mtodo de anlise de pontos de funo utilizam
os mesmos valores.
Aps identificar a complexidade de cada ALI e AIE do
sistema, possvel determinar a contribuio desses para a
contagem dos pontos de funo.
Aps verificar na Tabela 1 a complexidade do ALI ou AIE, a
tarefa para estabelecer a contribuio muito simples, basta
saber a complexidade do seu arquivo lgico e se o mesmo
um ALI ou AIE e verificar o valor na Tabela 2.
Tipo de Funo
Baixa
Mdia
Alta
Arquivo Lgico Interno
7 PF
10 PF
15 PF
Arquivo de Interface Externa
5 PF
7 PF
10 PF
Tabela 2. Tabela de contribuio
Aplicando o conhecimento Contar Funes do tipo

dados
Figura 4. Especializao um tipo de registro
Para facilitar a identificao dos tipos de arquivos, deve-se

elaborar um modelo lgico. Uma dica geral e objetiva contar
um arquivo lgico ALI ou AIE para cada tabela reconhecida
pelo usurio, ou seja, se a tabela existe no ponto de vista do
usurio ela deve ser contada, caso contrrio no deve ser contada. Se o usurio no reconhece a tabela, mas reconhece os
tipos de dados presentes na mesma, provavelmente essa tabela
ser um tipo de registro.
A Figura 6 apresenta um esquema para classificar um arquivo lgico.
Figura 5. Viso do Negcio
Tipos de Registro
Tabela de complexidade
A tabela de complexidade padronizada pelo IFPUG, todos
os mesmos valores.
Aps o entendimento sobre tipo de dados e tipo de registro,
os mesmos sero utilizados para definir a complexidade do
arquivo lgico. Realiza-se a contagem dos tipos de registro e
tipos de dados de cada arquivo lgico, depois se verifica na
Tabela 1 o valor de cada um e o intervalo que pertence. Com
isso, define-se a ALI ou AIE como sendo de complexidade
baixa, mdia ou alta.
1
25
>5
Tipos de Dados
< 20
20 50
Baixa
Baixa
Baixa
Mdia
Mdia
Alta
Tabela 1. Complexidade ALI e AIE
24
> 50
Mdia
Alta
Alta
Figura 6. Fluxo para classificao do tipo lgico
Passos para uma estimativa da contagem desta etapa

a) Elabora-se um modelo lgico seu projeto, como exemplificado na Figura 7.
Identificam-se todas as tabelas reconhecidas pelo usurio, ou
seja, as que fazem parte da viso do negcio, classificando-as
como ALI ou AIE (vide Tabela 3).
Descrio
Tipo
Qtd. TDs
Qtd. TRs
Complexidade
Usurio
ALI
Baixa
Cliente
ALI
Baixa
Carro
ALI
Baixa
Tabela 5. Complexidade
d) Determinao da contribuio de cada arquivo lgico e

realizao a soma de todos.
Para determinar a contribuio basta verificar na Tabela 2 o
ponto de funo referente a cada complexidade, o resultado
apresentado na Tabela 6.
Figura 7. Modelo lgico

Descrio
Tipo
Usurio
ALI
Cliente
ALI
Carro
ALI
Descrio
Tabela 3. Classificao dos arquivos lgicos
Na Figura 7 as tabelas Usurio, Cliente e Carro foram caracterizadas como arquivo lgico interno e Aluga foi definida
como tipo de registro de Cliente e Carro, pois a mesma no
reconhecida pelo usurio, mas os seus atributos so.
b) Faz-se uma anlise da todas as tabelas que no esto na
viso do negcio:
Se a tabela no pertence viso do negcio, mas os seus
tipos de dados pertencem, deve-se cont-la como um tipo de
registro para cada arquivo lgico relacionado a ela, e atribuir
os seus tipos de dados a cada um deles;
Se nem a tabela nem os seus tipos de dados pertencem viso
do negcio, deve ser descartada da contagem.
A tabela Aluga foi considerada um tipo de registro, pois na
viso do negcio, os campos hora_aluguel e data_aluguel so
reconhecidos pelo usurio e por este motivo eles foram somados
aos tipos de dados de Cliente e Carro, conforme a Tabela 4.
Descrio
Tipo
Qtd. TDs
Qtd. TRs
Usurio
ALI
Cliente
ALI
Carro
ALI
Tabela 4. Tipo de Dado (TD) e Tipo de Registro (TR)
Quando se tem uma relao entre mais de um arquivo lgico

com uma entidade definida como tipo de registro, devem-se
identificar todos os atributos reconhecidos pelo usurio presentes nesta entidade tipo de registro e som-los a todos os
arquivos lgicos que se relacionam com esta entidade. Isso
necessrio, pois estes atributos influenciam aos demais arquivos lgicos e geram impacto no desenvolvimento do projeto.
c) Determinao da complexidade de cada arquivo lgico.
Para definir a complexidade basta analisar a quantidade de
tipos de dados mais as quantidades de tipos de registro e conferir na Tabela 1. O resultado apresentado na Tabela 5.
Tipo
Qtd. TDs
Qtd. TRs
Complexidade
Contribuio
Usurio
ALI
Baixa
Cliente
ALI
Baixa
Carro
ALI
Baixa
Total de Pontos de Funo =
21
Tabela 6. Contagem das funes do tipo dados
Contar funes do tipo transao

O terceiro passo para a contagem dividido em duas partes,
contar funes do tipo dados e contar funes do tipo transao, como pode ser visto na Figura 1. Agora que foi aprendido
como contar funes do tipo dados, pode-se dar continuidade
contagem da aplicao. As funes do tipo transao so as
funcionalidades base para o funcionamento do sistema, essas
funes so chamadas de processos elementares e so classificadas em Entradas Externas, Sadas Externas e Consultas
Externas.
Um processo elementar a menor unidade de uma funo
disponvel ao usurio. Por exemplo, consultar clientes pode ser
entendido como uma funo, mas o mesmo no pode ser entendido como um processo elementar, uma vez que podem ser
realizadas inmeras consultas diferentes aos clientes: consultar
clientes pelo nome, consultar clientes em dbito, consultar
registro de clientes, e outras mais. Pode-se perceber que cada
consulta uma funcionalidade nica e independente. Desta
forma, para determinar um processo elementar necessrio
identificar todas as funcionalidades nicas e independentes
de uma funo.
Uma observao importante que um processo elementar
deve ser nico. Por exemplo, consultas que diferem umas das
outras pela organizao dos dados gerados, no podem ser
consideradas diferentes.
Entrada Externa (EE)
Uma entrada externa um processo de controle, ela tambm
realiza o processamento de dados do sistema e direciona o
mesmo para atender os requisitos da aplicao. A principal
inteno da EE realizar operaes que visam manter (incluir,
alterar ou excluir) dados de um ou mais arquivos lgicos internos, realizando processamento, transao e armazenamento
de dados dos usurios do software.
25
Uma EE deve ser nica e no necessitar de aes anteriores e

nem sucessores. Por exemplo, no envio de um e-mail, escrever
o destinatrio, o assunto e o corpo do e-mail no podem ser
entendidos como EE, pois no se constituem uma operao
completa, mas o conjunto de todas estas, e clicar no boto de
envio que se caracteriza como uma EE.
Exemplos de Entrada Externa:
Transaes destinadas a manter ALI, incluir funcionrio,
excluir funcionrio, alterar funcionrio e etc.;
Operaes;
Processos destinados a realizar registros, por exemplo, em
um sistema de ponto eletrnico o usurio registra entrada e
sada.
No so exemplos de Entrada Externa:
Telas de filtro;
Preenchimento de campos de dados;
Telas de login;
Gerar relatrios.
De modo geral, EEs possuem nomes caractersticos, como
incluir, alterar, salvar, excluir, editar, encaminhar, submeter
e registrar, dentre outros.
Sada Externa (SE)
Processo elementar destinado apresentao de informao
ao usurio ou a outra aplicao externa que utilize clculos
para processar essas informaes.
A principal inteno de uma SE apresentar informao para
o usurio a partir de lgica de processamento, ou seja, as informaes apresentadas devem passar por um processamento,
elas no devem ser simplesmente uma consulta simples. Este
processamento pode ter como objetivo manter ALIs ou alterar
o comportamento do sistema.
de uma ALI e/ou AIE. Esse processamento no deve possuir

lgica matemtica, nem qualquer tipo de clculo, no deve
gerar dados derivados e nem alterar o comportamento do
sistema. A CE uma consulta simples e direta, com o retorno
da informao requisitada pelo usurio.
Exemplos de Consulta Externa:
Consultar clientes pelo nome;
Apresentar dados em formato grfico a partir de recuperao
simples.
No so exemplos de Consulta Externa:
Relatrios financeiros, gerados a partir de clculos;
Telas de filtro.
Determinao da complexidade e da contribuio
Complexidade o grau de influncia que um processo elementar tem para o tamanho funcional do sistema. A contribuio
a converso do grau de complexidade em pontos de funo.
Essa complexidade calculada a partir da contagem dos tipos
de dados e dos arquivos referenciados.
Tipos de dados (TD)
um campo no recursivo de dado, nico e reconhecido pelo
usurio, ou seja, cada campo preenchido ou apresentado ao
usurio. Por exemplo, em um formulrio os campos nome, CPF,
endereo, o boto de confirmao, uma janela de mensagem
de erro, dentre outros, so tipos de dados. J em um relatrio,
o cdigo do produto, o nome, a descrio, o valor, so tipos de
dados. Em um grfico, o raciocnio o mesmo, conta-se um
tipo de dado para o nome do produto, um para a quantidade
e um para o valor, no total tem-se trs tipos de dados neste
relatrio, como pode ser visto na Figura 8.
Exemplos de Sada Externa:

Tela para liberar acesso (tela de login), sendo os dados da
transao criptografados;
Relatrios financeiros, supondo esses gerados por clculos;
Consultas complexas com processamento de dados a partir
de clculos;
Apresentao de grficos com dados processados a partir
de clculos.
No so exemplos de Sada Externa:
Telas de filtro;
Consultas simples, sem processamento de dados utilizando
clculos.
Consulta Externa (CE)
Processo elementar que apresenta informao ao usurio ou
a outra aplicao externa por meio de recuperao simples.
Uma CE tem como principal inteno apresentar informaes
ao usurio por meio de uma simples recuperao de dados
26
Figura 8. Apresentao de relatrio grfico

Arquivo Referenciado (AR)
Um arquivo referenciado todo arquivo lgico lido, pode ser
um ALI ou AIE, ou todo arquivo lgico mantido, nesse caso
s pode ser um ALI. Um tipo de registro no um arquivo
lgico, ele pertence a um arquivo lgico. No se deve contar
tipos de registro e arquivos lgicos lidos vrias vezes. Esses
so contados apenas uma nica vez.
Arquivos Referenciados
Tabela de complexidade
A tabela de complexidade padronizada pelo IFPUG, todos
os mesmos valores.
Aps o entendimento sobre tipo de dado e arquivo referenciado, pode-se utiliz-lo para definir a complexidade do processo
elementar. Realiza-se a contagem dos tipos de dados e dos
arquivos referenciados de cada processo elementar, depois
verifica-se na Tabela 7 ou na Tabela 8 o valor de cada um e o
intervalo a que ele pertence, com isso definindo a EE, SE ou
CE como sendo de complexidade baixa, mdia ou alta.
Tipos de Dados
<5
5 15
> 15
<2
Baixa
Baixa
Mdia
2
>2
Baixa
Mdia
Mdia
Alta
Alta
Alta
Arquivos
Referenciados
Tabela 7. Complexidade Entrada Externa (EE)
<2
23
>3
Tipos de Dados
<6
6 19
Baixa
Baixa
Baixa
Mdia
Mdia
Alta
> 19
Mdia
Alta
Alta
Tabela 8. Complexidade Sada Externa (SE) e Consulta Externa (CE)
importante perceber que a Tabela 7 destinada a EE e a Tabela

8 a SE e CE. Essa diferena importante uma vez que processos
elementares destinados a apresentar informao, possuem normalmente mais tipos de dados e referenciam mais arquivos.
Tabela de contribuio
A tabela de contribuio padronizada pelo IFPUG, todos os
usurios do mtodo de anlise de pontos de funo utilizam
os mesmos valores.
Aps identificar a complexidade de cada processo elementar
do sistema, possvel determinar a contribuio desses para
a contagem dos pontos de funo.
Aps a definio da complexidade do seu processo elementar,
definir a sua contribuio muito simples, basta saber a complexidade do seu processo elementar e se o mesmo uma EE,
SE ou CE e utilizar o valor correspondente na Tabela 9.
Tipo de Funo
Baixa
Mdia
Alta
Entrada Externa
3 PF
4 PF
6 PF
Sada Externa
4 PF
5 PF
7 PF
Consulta Externa
3 PF
4 PF
6 PF
Tabela 9. Tabela de Contribuio
Aplicando o conhecimento Contar funes do tipo

transao
Para finalizar o terceiro passo, deve-se determinar a contagem das funes do tipo transao.
Figura 9. Fluxo para classificao do processo elementar
O fluxo da Figura 9 foi idealizado para facilitar o entendimento

do processo de determinao dos tipos de processo elementar.
Esta uma viso geral, o importante saber qual a finalidade
do seu processo elementar. Por exemplo, um cadastro uma EE
que pode apresentar informaes ao final do processamento
que no o torna uma CE ou SE, pois sua finalidade poderia
ser cadastrar.
Outra dica, quando no se reconhece a classificao de uma
funo de transao, pode ser que esta ainda no seja um
processo elementar, cabe ento reconhecer todos os processos elementares no interior desta funo antes de verificar a
classificao em Entrada Externa (EE), Consulta Externa (CE)
ou Sada Externa (SE).
Como primeiro passo para a contagem, deve-se identificar
todos os processos elementares e classific-los quanto ao seu
tipo, conforme a Tabela 10.
Determinam-se ento os tipos de dados e os arquivos referenciados (vide Tabela 11). Neste passo necessrio analisar
cada processo elementar e definir seus tipos de dados e os
arquivos que referencia.
Este passo mais relevante quando os tipos de dados ou
os arquivos referenciados esto na fronteira da mudana da
complexidade. Longe da fronteira, erros neste ponto no iro
influenciar na contagem.
Verifica-se a complexidade, aps definir os tipos de dados e
os arquivos referenciados, determinando a complexidade de
27
Descrio
Tipo
Descrio
Tipo
Qtd. TDs
Qtd. ARs
Complexidade
Incluir Cliente
EE
Incluir Cliente
EE
Baixa
Excluir Cliente
EE
Excluir Cliente
EE
Baixa
Alterar Cliente
EE
Alterar Cliente
EE
Baixa
Incluir Usurio
EE
Incluir Usurio
EE
Baixa
Excluir Usurio
EE
Excluir Usurio
EE
Baixa
Alterar Usurio
EE
Alterar Usurio
EE
Baixa
Incluir Automveis
EE
Incluir Automveis
EE
Mdia
Excluir Automveis
EE
Excluir Automveis
EE
Baixa
Alterar Automveis
EE
Alterar Automveis
EE
Baixa
Registrar Locao
EE
Registrar Locao
EE
Baixa
Finalizar Locao
EE
Finalizar Locao
EE
Baixa
Login (com criptografia)
SE
SE
Baixa
Consulta clientes por nome
CE
CE
Baixa
Consulta carros alugados
CE
CE
Baixa
Consulta data do aluguel
CE
CE
Baixa
Consulta clientes com carro alugado
CE
CE
Mdia
Consulta carro mais alugado
CE
CE
Baixa
Consulta cliente que mais aluga
CE
CE
Baixa
Tabela 12. Complexidade
Tabela 10. Tipos dos processos elementares

Descrio
Tipo
Qtd. TDs
Qtd. ARs
Descrio
Tipo
Qtd. TDs
Qtd. ARs Complexidade
Contribuio
Incluir Cliente
EE
Incluir Cliente
EE
Baixa
Excluir Cliente
EE
Excluir Cliente
EE
Baixa
Alterar Cliente
EE
Alterar Cliente
EE
Baixa
Incluir Usurio
EE
Incluir Usurio
EE
Baixa
Excluir Usurio
EE
Alterar Usurio
EE
Excluir Usurio
EE
Baixa
Incluir Automveis
EE
Alterar Usurio
EE
Baixa
Excluir Automveis
EE
Incluir Automveis
EE
Mdia
Alterar Automveis
EE
Excluir Automveis
EE
Baixa
Registrar Locao
EE
Alterar Automveis
EE
Baixa
Finalizar Locao
EE
Registrar Locao
EE
Baixa
SE
Finalizar Locao
EE
Baixa
CE
CE
Login (com criptografia) SE
Baixa
CE
CE
Baixa
CE
CE
Consulta clientes por

nome
Consulta carros
alugados
CE
Baixa
CE
Consulta data do aluguel CE
Baixa
Mdia
Baixa
Baixa
Tabela 11. Tipos de Dados (TD) e Arquivos Referenciados (AR)
cada processo elementar consultando a Tabela 7 ou Tabela 8.

O resultado pode ser visto na Tabela 12.
A seguir, determina-se a contribuio de cada processo elementar e realiza-se a soma de todos, conforme Tabela 13.
Para determinar a contribuio basta verificar na Tabela 9 o
ponto de funo referente a cada complexidade.
28
Consulta clientes com

CE
carro alugado
Consulta carro mais
CE
alugado
Consulta cliente que
CE
mais aluga
Total de Pontos de Funo =
Tabela 13. Contagem das funes do tipo transao
57
Pontos de funo no ajustados
Aplicando o conhecimento Fator de ajuste
O quarto passo para a contagem determinar a contagem dos

pontos de funo no ajustados, como pode ser visto na Figura 1.
Neste ponto entende-se a relao de um arquivo lgico com
um processo elementar.
Na Figura 10 tem-se um exemplo de uma aplicao AP01 com
um ALI e uma srie de processos elementares. Ela realiza uma
leitura de um arquivo lgico da aplicao AP02. Esse arquivo
lgico localiza-se fora da fronteira da aplicao AP01 e deve
ser classificado como um AIE.
No ser feita anlise para esta etapa, uma vez que a mesma
instituda opcional pelo IFPUG e pode aumentar o erro na
estimativa.
Para o nosso exemplo, deve-se considerar:
Valor de ponto de funo no ajustado (VAF) = 1;
Realizar o clculo dos pontos de funo ajustados

O sexto e ltimo passo para a contagem calcular os pontos
de funo ajustados, como pode ser visto na Figura 1.
Esta a etapa final para obter o tamanho funcional do seu
projeto. Existem trs tipos de contagem, como j foi dito: Projeto
de Desenvolvimento, Projeto de Melhoria e Aplicao.
Como este artigo visa contagem de projeto de desenvolvimento, no sero tecidos detalhes dos demais tipos de contagem.
Para determinar os pontos de funo ajustados para projeto
de desenvolvimento necessrio aplicar a seguinte frmula
apresentada na Tabela 15.
DFP = (UFP + CFP) x VAF
Figura 10. Relao arquivo lgico e processo elementar
Agora se deve realizar a contagem dos pontos de funo no

ajustados. Esta anlise simples. Deve-se apenas somar as
contribuies das funes do tipo dado com as contribuies
das funes do tipo transao.
Aplicando o conhecimento Pontos de funo no

ajustados
Para realizar a determinao dos pontos de funo no ajustados, deve-se somar as contribuies de todas as funes do
tipo dado e do tipo transao (ver Tabela 14).
Descrio
Contribuio
Funes do tipo dado
21 PF
Funes do tipo transao
57 PF
Total de Pontos de Funo No Ajustados =
78 PF
Tabela 14. Pontos de funo no ajustados
Determinar o fator de ajuste

O quinto passo para a contagem determinar o valor do fator
de ajuste, como pode ser visto na Figura 1.
Para o quinto passo deve-se determinar o fator de ajuste, mas
essa anlise no ser feita e ser atribudo o valor do fator de
ajuste como um. A adoo desse valor ser melhor compreendida no exemplo apresentado.
O fator de ajuste, pelo seu carter subjetivo e o impacto gerado na contagem, podendo ser de +35% a -35%, fez com que
vrios utilizadores do mtodo de anlise de ponto de funo
ignorassem essa etapa antes mesmo do IFPUG classific-la
como opcional em 2002.
Onde:
DFP: Nmero de pontos de funo do projeto de desenvolvimento;
UFP: Nmero de pontos de funo no ajustados das funes disponveis aos usurios aps a
instalao;
CFP: Nmero de pontos de funo no ajustados das funes de converso, ou seja, as funes
transitrias que so inutilizadas aps a instalao;
VAF: Valor do fator de ajuste.
Tabela 15. Tabela da frmula dos pontos de funo de projeto de
desenvolvimento
Aplicando o conhecimento Pontos de funo ajustados

Todos os valores estimados at este ponto sero utilizados para
determinar os pontos de funo ajustados. Para terminar a contagem do projeto de desenvolvimento, deve-se substituir os valores
estimados at aqui na frmula apresentada na Tabela 16.
A aplicao contada no possui funes de converso, por este
motivo foi somado zero s funes disponveis aps a instalao.
Assim, a aplicao contada possui um tamanho funcional
estimado em 78 pontos de funo.
DFP = (UFP + CFP) x VAF
Onde:
DFP: Nmero de pontos de funo do projeto de desenvolvimento;
UFP: Nmero de pontos de funo no ajustados das funes disponveis aps a instalao;
CFP: Nmero de pontos de funo no ajustados das funes de converso;
VAF: Valor do fator de ajuste.
Resultado:
DFP = (78 + 0) x 1
DFP = 78 Pontos de Funo
Tabela 16. Valor total dos Pontos de Funo ajustados
Derivaes
Neste ponto j se possui o tamanho funcional da aplicao,
agora sero apresentadas as derivaes que podem ser realizadas com ele.
29
At aqui se utilizou a APF na perspectiva de produto, agora

pode-se fazer uma anlise na perspectiva de processo (esforo,
custo e prazo). Independente da derivao, o importante possuir
um histrico de projeto, s assim ser possvel estimar esforo,
custo e prazo de forma satisfatria. Na primeira vez que aplicar
estas estimativas o erro ser grande, mas conforme for ampliando
a base de histricos de projetos, o erro tender a diminuir.
Esforo
Para calcular o esforo necessrio conhecer quantos pontos
de funo so produzidos em uma hora e saber quantas horas
de trabalho so consideradas em um ms na empresa.
A estimativa de esforo pode ser:
Pontos de Funo por Homem Ms (PF/HM);
Pontos de Funo por Hora (PF/H).
Tem-se por base que a taxa de produtividade medida em
hora por ponto de funo (H/PF). Cada linguagem ou tecnologia demandam um esforo diferente, essas caractersticas
no influenciam nos pontos de funo, mas sim no esforo
que demanda produzir cada ponto de funo.
Existem vrios editais para licitao de desenvolvimento de
sistemas, que incluem tabelas de produtividade mnima no
desenvolvimento de projetos.
A Tabela 17 foi retirada do edital da ACINE (Agncia Nacional do Cinema), que define a produtividade mnima de PF que
a empresa dever produzir por linguagem no tempo definido.
Por exemplo, uma empresa que concorrer a esse edital, dever
ter competncia de produzir no mnimo um PF a cada quinze
horas na linguagem Java.
Desenvolvimento e manuteno de sistemas
Tecnologia
Produtividade Mnima
Java
15 h/PF
ASP (Vbscript e Javascript)
10 h/PF
PHP
11 h/PF
JSP
13 h/PF
HTML
7 h/PF
Cold Fusion
11 h/PF
Delphi
9 h/PF
Crystal reports
9 h/PF
PL/SQL
9 h/PF
Visual Basic
9 h/PF
Tabela 17. Tabela de produtividade mnima ACINE
Utilizar bases de editais (sem o conhecimento sobre o projeto) ou de outras empresas, constitui um risco muito grande,
pois a produtividade intrnseca de cada empresa, pois essas
possuem funcionrios e processos diferenciados.
Custo
A estimativa do custo de um projeto a informao primordial na hora de elaborar uma proposta, este no pode exceder
30
s expectativas do cliente e nem ter um valor inferior ao necessrio para o funcionamento da empresa.
Como na determinao do esforo, o custo tambm estimado a partir de dados da empresa, neste caso necessrio ter o
conhecimento do custo da hora da equipe de desenvolvimento
ou o valor de um ponto de funo para sua empresa.
O custo de um Ponto de Funo dado por:
Custo por hora vezes a quantidade de horas necessrias para
produzir um Ponto de Funo (C/H x H/PF).
Prazo
O prazo um fator crtico a ser determinado pois, para
estimativas, pode-se supor que o prazo uma funo linear
com o recurso, o que uma suposio falha. Por exemplo, se
um projeto desenvolvido por dois desenvolvedores gasta um
prazo de dois meses, alocar mais dois desenvolvedores para
o projeto no necessariamente implica que o mesmo ir durar
apenas um ms.
A anlise emprica mostra que essa linearidade no existe,
uma mulher demora nove meses para gerar um beb, nove mulheres no geram um beb em um ms (VAZQUEZ, 2009).
Quanto maior o tamanho funcional de um projeto, maior ser
o prazo e maior ser o erro. Para projetos pequenos o erro
aceitvel, mas novamente volta-se ao ponto de que a melhor
maneira de evitar esses erros possuir uma base histrica dos
projetos desenvolvidos.
O prazo derivado da seguinte forma:
Prazo a relao de esforo por recurso (Prazo= Esforo/
Recurso).
Aplicando o conhecimento Derivaes

At aqui definiu-se o tamanho funcional do sistema exemplo,
agora utilizando de um dos benefcios do mtodo de anlise
de ponto de funo que a realizao de derivaes a partir da
quantidade de pontos de funo estimados, sero realizadas
derivaes quanto ao esforo, custo e prazo necessrios para
o desenvolvimento do software.
Esforo
A aplicao de exemplo foi estimada em 78 pontos de funo. Ser considerada uma empresa que possui uma taxa de
produtividade mnima em Java de 5 H/PF e com uma carga de
trabalho de 130 horas por homem-ms. Essa empresa gastaria
390 horas para produzir o sistema, ou trs meses, conforme
a Tabela 18.
Custo
Suponha que a hora de trabalho custe R$ 20,00 e, como
produzido um ponto de funo a cada cinco horas, o valor do
ponto de funo de R$ 100,00.
Estima-se que o esforo necessrio para produzir a aplicao
de exemplo de 390 horas, e a mesma possui 78 pontos de
funo.
Pode-se assim inferir que a aplicao tem um custo de aproximadamente R$ 7.800,00, conforme a Tabela 19.
Esforo = H/PF x Tamanho do projeto em PF

Onde:
H: Hora;
PF: Pontos de funo.
Resultado:
Esforo = 5 x 78
Esforo = 390 horas
Tabela 18. Valor total em horas do esforo para desenvolver o projeto
fase de construo de 65% e voc possui o esforo e custo para

o desenvolvimento desta fase, pode-se extrapolar um de cada
vez para todas as fases, depois so feitos ajustes necessrios
de acordo com cada empresa.
Utilizando dos valores obtidos neste artigo, segue o exemplo para extrapolar o esforo para a construo do sistema,
no esforo para a realizao da fase de concepo do projeto,
conforme a Tabela 22.
Extrapolando Esforo Construo em Esforo Iniciao
Custo = Tamanho do projeto em PF x Custo do Ponto de Funo

Resultado:
Custo = 78 x R$ 100,00
Custo = R$ 7.800,00
65% - 390 (horas)

05% - X (horas)
X = 30 horas
Tabela 22. Esforo total extrapolado para realizao da fase de concepo
Tabela 19. Custo total para elaborao do projeto
Prazo
Foi definido que o esforo necessrio para produzir a aplicao de 390 horas ou trs meses. Suponha que esta empresa
possua dois funcionrios habilitados a desenvolver o projeto
na tecnologia estabelecida.
Utilizando dessas informaes conclui-se que o prazo
para a entrega do sistema ser de um ms e meio, conforme
a Tabela 20.
O prazo pode ser obtido a partir do esforo necessrio para

produzir e dos recursos disponveis.
Assim, deve-se realizar anlise histrica dos projetos e construir uma tabela especfica para cada organizao, mas observando cada projeto, pois ajustes sero sempre necessrios.
Referncias
1. VAZQUEZ,C.E. , SIMES,G.S. , ALBERT,R.M. Anlise de ponto de funo medio, estimativa e
gerenciamento de projetos de software. So Paulo, Editora rica, 2009
Prazo = Esforo / Recurso

Prazo = 3 / 2
Prazo = 1 ms e 15 dias
2. Softex. MPS.BR - Melhoria de processo do software brasileiro - Guia geral, 2009
Tabela 20. Prazo total para elaborao do projeto
3. IFPUG(International Function Point Users Group). Disponvel em: <http://www.ifpug.org>.
Consideraes finais
4. BFPUG(Brazilian Function Point Users Group). Disponvel em: <http://www.bfpug.com.br>.
Elaborao
20%
30%
Construo
65%
50%
Transio
10%
10%
Para extrapolar os resultados obtidos nas derivaes da APF,

basta fazer uma regra de trs simples. Se o esforo destinado
7. DEKKERS, C. Desmistificando Pontos de Funo: Entendendo a Terminologia. IT Metrics

Strategies, out. 1998
8. HAZAN, Cludia Anlise de Pontos por Funo agosto , 2001 . disponvel em http://www.
inf.ufes.br/~falbo/download/aulas/es-g/2005-1/APF.pdf.
9. ACINE. Anexo XVIII Tabelas de produtividade mnima, 2008. Disponvel em: <http://www.
ancine.gov.br/media/concorrencia0012008/AnexoXVIII.pdf>.
10. Philippe Kruchten.The Rational Unified Process: An Introduction. Boston, Editora Pearson
Education, 2003

Feedback
eu
31
sobre e
s
Tabela 21. Distribuio de esforo e programao em projetos de mdio

porte (Philippe Kruchten, 2003)
6. DEKKERS, C. Pontos de Funo e Medidas - O Que um Ponto de Funo?. QAI Journal, dez. 1998
D
s
Esforo
Programao
Concepo
5%
10%
5. PMI (Project Management Institute). Um Guia do Conjunto de Conhecimentos em

Gerenciamentos de Projetos (PMBOK). Estados Unidos: PMI Publications, 2004
edio
ta
A APF pode ser usada para estimar desenvolvimento, melhoria e aplicao. Todas as formas de estimativa e derivaes so
referentes fase de construo, mas de conhecimento que na
produo de um sistema, tm-se ainda as fases de concepo,
elaborao e transio. importante dizer que as dicas que
sero passadas no possuem nenhuma ligao com o mtodo
de APF, mas sim uma observao de como extrapolar os valores derivados de esforo, prazo e custo em todo o processo
de produo do sistema.
Embora o ciclo de vida varie muito por empresas e projetos
diferentes, um projeto mdio, possui a distribuio de esforo
e programao como apresentado na Tabela 21.
Engenharia
CMMI Uma viso Geral

Um modelo de maturidade para o processo de construo de software

Demonstrar, atravs de uma viso geral, como o modelo de qualidade CMMI pode contribuir no processo
de desenvolvimento de software. Voc conhecer os
conceitos, caractersticas, objetivos e representaes
referentes a este modelo de qualidade.
Lenildo Morais
lenildojmorais@gmail.com
analista de sistemas e analista de testes.

Atualmente est cursando mestrado no
centro de informtica da UFPE em engenharia de software com nfase em testes
e qualidade de software.
32
o longo dos ltimos anos, tanto

as empresas de desenvolvimento de soft ware quanto
seus clientes tm se preocupado com
problemas que so comumente identificados durante a execuo dos projetos,
tais como: prazos e oramentos no
cumpridos, insatisfao de ambos os
lados, produtos com erros, entre outros.
No entanto, h algum tempo, existe um
consenso na Engenharia de Software de
que estes problemas esto, em grande
parte, relacionados ao fato de que o
desenvolvimento de sistemas muitas
vezes realizado de forma artesanal,
ou atravs de mtodos improvisados
pelos desenvolvedores. Tais mtodos
dependem mais do talento individual
do desenvolvedor que de uma slida
formao que oriente suas atividades.
Engenharia de Software Magazine - CMMI Uma viso Geral

Nos projetos de desenvolvimento de software,
que adotam polticas de qualidade, sobretudo
quando se deseja buscar mercados externos ou
expandir seus clientes internos aumentando a
satisfao dos mesmos.
Resumo
Este artigo tem como propsito apresentar
uma viso geral sobre maturidade dos processos de desenvolvimento de software, visando a
qualidade do produto gerado e a consequente
satisfao dos seus clientes, atravs do modelo de referncia CMMI. Trata-se de um modelo
internacional, desenvolvido pelo Software Engineering Institute SEI, que pode dar suporte
s organizaes que procuram aprimorar seus
processos de desenvolvimento de software,
tornando-se assim mais competitivas.
processo
Um processo definido e controlado pode garantir um produto

de qualidade, sobretudo do ponto de vista do desenvolvimento de software. O Capability Maturity Model Integration,
ou CMMI, como chamado, um modelo de referncia que
prov uma orientao para o desenvolvimento de processos
de software, procurando nortear a organizao no sentido de
implementar a melhoria contnua do processo de software (ler
Nota do DevMan 1).
relacionados principalmente qualidade, custos e prazos. Com

isso, o CMMI pode ser aplicado em uma organizao em etapas
consecutivas, representando a ideia de maturidade (avaliada
por estgios) da organizao, ou de maneira contnua, onde
medida a capacidade em processos individuais, conforme
ilustrado na Figura 1.
Nota do DevMan
CMMI e MPS.BR: Desde a dcada de 1990, vrios modelos de maturidade de
processos vm sendo propostos com o objetivo de auxiliar na melhoria da qualidade
dos processos de software adotados pelas organizaes. Entre eles podemos citar os
modelos CMM, Spice ISO/IEC 15504, CMMI e mais recentemente, no Brasil, o MPSBR. Atualmente as organizaes que desenvolvem software esto atentas s necessidades da adoo de processos de desenvolvimento de software melhor definidos, e
observam-se movimentos dessas organizaes em busca de certificaes de qualidade de processos de software, notadamente as certificaes CMMI e/ou MPS.BR.
O MPS.BR define um modelo de melhoria e avaliao de processos de software
com o foco nas pequenas e mdias empresas brasileiras, de modo a atender as suas
necessidades de negcio e ser reconhecido nacional e internacionalmente como um
modelo aplicvel indstria de software. Ele estabelece um modelo de processos de
software e um mtodo de avaliao de processos de modo a garantir que o MPS.BR
est sendo empregado de forma coerente com as suas definies.
Para isso, o modelo contempla duas representaes que

permitem empresa desenvolvedora do software utilizar o
caminho de melhoria mais adequado. Estas representaes
esto divididas em nveis de maturidade, priorizando de forma
lgica as aes a serem realizadas. Assim, quanto maior o nvel,
maior a maturidade da organizao, o que pode se traduzir em
maior qualidade do produto final, com maior previsibilidade
em cronogramas e oramentos.
O objetivo do CMMI servir de guia para a melhoria de processos na organizao, assim como auxiliar a habilidade dos
profissionais em gerenciar o desenvolvimento e manuteno
de produtos ou servios de software, alm de proporcionar a
visibilidade apropriada do processo de desenvolvimento para
todos os envolvidos no projeto. Isto particularmente importante em grandes projetos que possuem equipes envolvendo
dezenas de pessoas, pois, sem o apoio desses modelos de
maturidade de processos de software como o CMMI, torna-se
ainda mais difcil manter o controle do projeto.
Com a utilizao de nveis, o CMMI descreve um caminho
evolutivo recomendado para uma organizao que deseja
melhorar os processos utilizados para a construo de seus
produtos e servios. Quando uma organizao atinge um nvel
de maturidade, considera-se que seus processos alcanaram
uma determinada capacidade, ou seja, tem mecanismos que
garantem a repetio sucessiva de bons resultados futuros
Figura 1. Capacidade e Maturidade Organizacional
O CMMI possui cinco nveis de maturidade, onde no primeiro

a empresa desenvolve sistemas baseando-se apenas na experincia dos recursos humanos da organizao; e no ltimo, h
um processo organizado e flexvel, com um planejamento eficiente e continuamente aprimorado. Este modelo define reas
de processo, sendo cada uma com suas metas e prticas, e para
que uma empresa alcance nveis de maturidade superiores,
dever cumprir estas metas, compreendidas em cada rea de
processo (Process Area PA). As PAs funcionam como uma
coleo de prticas que representam o nvel de maturidade.
Representaes do CMMI
O CMMI possui duas representaes: a estagiada e a contnua. A representao estagiada permite que as organizaes
melhorem um conjunto de processos inter-relacionados e, de
forma incremental, tratem sucessivos conjuntos de PAs. A representao contnua, por sua vez, permite que as organizaes
melhorem de forma incremental os processos correspondentes
a uma ou mais PAs, sendo a empresa responsvel por selecionar em que reas de processo ela ser avaliada.
A seg ui r apresenta mos u ma descr io para estas
representaes:
Representao por Estgios: Esta representao preocupa-se
com os processos da organizao como um todo, oferecendo
uma abordagem estruturada e sistemtica para a melhoria
de um estgio por vez. Atingir um estgio significa que uma
estrutura de processo adequada foi estabelecida como base
para o prximo estgio.
As reas de processo (PAs) so organizadas por nveis de
maturidade. Elas vo do nvel inicial (nvel 1) ao nvel em
otimizao (nvel 5), e sugerem uma ordem para a implementao das reas de processo. Cada nvel possui vrias PAs,
e cada PA possui objetivos, prticas genricas e especficas,
assegurando assim uma base de melhoria adequada para o
prximo nvel de maturidade.
33
Na representao por estgios, quando uma organizao atinge as prticas necessrias para estar em um nvel, subentendese que ela atingiu todos os requisitos necessrios dos nveis
imediatamente anteriores.
Os nveis esto descritos da seguinte forma:
a) Nvel 1 Inicial. o nvel de maturidade CMMI mais baixo.
Em geral, as organizaes desse nvel tm processos imprevisveis que so pobremente controlados e reativos. Neste nvel
de maturidade no h PAs, os processos so normalmente imprevisveis e caticos, e a organizao geralmente no fornece
um ambiente estvel;
b) Nvel 2 Gerenciado. Neste nvel, os projetos da organizao tm a garantia de que os requisitos so gerenciados,
planejados, executados, medidos e controlados. Quando essas
prticas so adequadas, os projetos so executados e controlados de acordo com o planejado. O gerenciamento de projetos
o foco principal deste nvel;
c) Nvel 3 Definido. Nvel em que todos os objetivos especficos e genricos atribudos para os nveis de maturidade 2 e 3
foram alcanados, e os processos so mais bem caracterizados,
alcanando melhor entendimento, sendo descritos em padres,
procedimentos, ferramentas e mtodos. O foco neste nvel a
padronizao do processo;
d) Nvel 4 - Quantitativamente Gerenciado. Neste nvel, os
objetivos especficos e genricos atribudos para os nveis
de maturidade 2, 3 e 4 foram alcanados e os processos so
medidos e controlados. O foco neste nvel o gerenciamento
quantitativo;
e) Nvel 5 Em Otimizao. o nvel mais alto de maturidade
CMMI, onde uma organizao atinge todos os objetivos especficos atribudos para os nveis de maturidade 2, 3, 4 e 5. Neste nvel
os processos tm como foco principal a melhoria contnua.
Representao Contnua: Na representao contnua, o foco
ou componentes principais so as reas de processo. Existem
metas e prticas de dois tipos: especficas a uma determinada
rea de processo, e genricas, aplicveis indistintamente a
todas as reas de processo.
Nesta representao, as reas de processo so agrupadas por
categorias afins que renem caminhos de melhoria indicando
a evoluo para cada uma destas reas.
A representao contnua contempla quatro disciplinas: Gerncia de Processos, Gerncia de Projeto, Engenharia e Suporte.
As reas de processo relativas disciplina de Gerncia de Processos contm atividades relacionadas para definir, planejar,
implantar, monitorar, controlar, medir e melhorar processos.
As reas de processo relativas categoria de Gerncia de Projeto contm as atividades de planejar, monitorar e controlar o
projeto. A categoria de Engenharia refere-se s atividades de
desenvolvimento de sistemas de software. Por fim, as atribuies de fornecer suporte ao desenvolvimento e manuteno
de produtos so relativas categoria de Suporte.
A partir da avaliao e do atendimento dessas prticas e metas, possvel classificar o nvel de capacidade de cada rea de
processo em uma escala de 0 a 5 do seguinte modo [3]:
34
Engenharia de Software Magazine - CMMI Uma viso Geral
a) Nvel 0 Incompleto. Um processo parcialmente realizado

ou no, onde um ou mais objetivos especficos do processo
no so satisfeitos [3];
b) Nvel 1 Realizado. Um processo realizado satisfaz todos
os objetivos especficos da rea de processo e produz algum
trabalho [3];
c) Nvel 2 Gerenciado. Um processo de capacidade nvel 2
um processo realizado (nvel 1) que tambm planejado e
executado de acordo com polticas pr-definidas. Emprega pessoas hbeis com os recursos adequados para produzir sadas
adequadas, envolve os stakeholders principais e monitorado,
controlado, revisto e avaliado quanto aderncia sua descrio. A gerncia do processo relacionada com a realizao
de objetivos especficos estabelecidos para o processo, como
custo, cronograma e qualidade [3];
d) Nvel 3 Definido: Um processo definido um processo
gerenciado e ajustado para o conjunto padro de processos da
organizao de acordo com as suas polticas de conduta. Esse
conjunto estabelecido e melhorado com o tempo e descreve
os elementos fundamentais de processos que so esperados
nos processos definidos [3];
e) Nvel 4 - Gerenciado quantitativamente: Um processo
neste nvel definido e controlado com a ajuda de tcnicas
quantitativas e estatsticas. A qualidade e o desempenho do
processo so compreendidos em termos estatsticos e so geridos durante sua vida. Objetivos quantitativos para qualidade
e desempenho de processos so estabelecidos e usados como
critrio na gerncia do processo [3];
f) Nvel 5 Em otimizao: Um processo em otimizao
gerenciado quantitativamente, alterado e adaptado para atender aos objetivos de negcio atuais e projetados. Tal processo
enfatiza a melhoria contnua atravs de aprimoramentos tecnolgicos inovadores e incrementais, selecionados com base em
uma compreenso quantitativa de sua contribuio esperada
obteno da melhoria de processos [3].
Representao por Estgios X Contnua

A representao contnua usa nveis de capacidade para
medir a melhoria de processos, enquanto a representao por
estgios utiliza nveis de maturidade para medir a melhoria
de capacidade da organizao. A principal diferena a forma
como cada representao aplicada. Os nveis de capacidade
so aplicados na melhoria de processos de cada rea de uma
organizao. Eles esto dispostos em seis nveis de capacidade,
numerados de 0 a 5, onde cada nvel possui um conjunto de
prticas gerais e especficas.
Na representao por estgios, os nveis de maturidade no
servem para analisar reas do processo, mas sim para indicar
melhorias na organizao como um todo. Ao fazer a avaliao
de uma organizao, possvel mapear os valores de capacidade do processo para a maturidade organizacional. Se no h
certeza sobre quais processos escolher para serem melhorados,
a representao por estgios uma boa opo. Ela fornece
um conjunto especfico de processos para melhorar em cada
estgio, determinado por mais de uma dcada de experincia
processo
Representao Contnua
Representao por Estgios
Permite livre escolha da sequncia de melhorias, de forma a melhor satisfazer aos Permite que as organizaes tenham um caminho de melhoria pr-definido e testado.
objetivos estratgicos e mitigar as reas de risco da organizao.
Permite visibilidade crescente da capacidade alcanada em cada rea de processo.
Foca em um conjunto de processos que fornece organizao uma capacidade especfica caracterizada por cada
nvel de maturidade.
Permite que melhorias em diferentes processos sejam realizadas em diferentes nveis. Resume os resultados de melhoria de processo em uma forma simples: um nico nmero que representa o nvel
de maturidade.
Reflete uma abordagem mais recente que ainda no dispe de dados para demonstrar Baseia-se em uma histria relativamente longa de utilizao, com estudos de casos e dados que demonstram o
seu retorno do investimento.
retorno do investimento.
Tabela 1. Comparao entre as representaes contnua e por estgios
A utilizao de metodologias em desenvolvimento de software, mais do que uma ferramenta, condio obrigatria
para se obter a melhoria nos processos, a qualidade necessria
[1] Uma viso geral do CMMI

http://www.dromostg.com.br/CMMI.PDF
[2] Anlise de uma Organizao de Software utilizando o Modelo CMMI/SEI
http://www2.dem.inpe.br/ijar/Qualidade%20de%20Software/PDFs/CMMI-Artigo.pdf
[3] Modelo de Qualidade CMMI
Rosngela Penteado
[4] CMMI - Uma Viso Geral
Carlos Jos Locoselli e Joo Carlos Neto

Feedback
eu
35
sobre e
s
Concluses
Links
D
s
A Tabela 1 compara cada representao e pode auxiliar

na determinao da representao mais adequada para a
organizao.
e o cumprimento dos prazos, to importantes nos ambientes

competitivos do presente momento.
Dessa forma, o objetivo de muitas empresas tem sido obter
qualificaes CMMI para atender as exigncias explcitas do
mercado. O CMMI (Capability Maturity Model Integration)
descreve princpios e prticas relacionadas ao processo de desenvolvimento de produtos e servios tecnolgicos. O modelo
visa ajudar organizaes envolvidas com o desenvolvimento
de software a melhorar a capacidade de seus processos, por
meio de um caminho evolucionrio que considera desde processos com resultados imprevisveis, e at mesmo caticos, a
processos disciplinados e definidos, com resultados previsveis
e com possibilidade de melhoria contnua.
edio
ta
e pesquisas em melhoria de processo. Todavia, existem trs

categorias de fatores que podem influenciar na deciso de qual
representao ser a mais adequada:
a) Estratgico: Se uma organizao com foco em linha de produto decidir melhorar seus processos na organizao como
um todo, pode ser mais bem atendida pela representao por
estgios, uma vez que a representao por estgios auxilia na
escolha dos conjuntos de processos onde focar a melhoria. A
considerao mais importante a ser feita a identificao dos
objetivos estratgicos a serem apoiados pelo programa de melhoria de processo e a forma como esses objetivos estratgicos
se alinham s duas representaes;
b) Culturais: Esto relacionados com a capacidade da organizao em implantar um programa de melhoria de processo.
Por exemplo, uma organizao pode escolher a representao
contnua se sua cultura corporativa basear-se em processos e
for experiente em melhoria de processo. J uma organizao
pouco experiente em melhoria de processo pode escolher a
representao por estgios, uma vez que essa representao
fornece orientaes adicionais sobre a sequncia em que as
mudanas devem ocorrer;
c) Legado: Caso uma organizao tenha experincia com outro
modelo que utiliza uma representao por estgios, pode ser
mais prudente continuar utilizando essa representao no
CMMI, principalmente se j investiu e implantou processos
associados representao por estgios. O mesmo raciocnio
pode ser aplicado para a representao contnua.
Engenharia
Gerenciando mudanas a partir de requisitos

Uma das aplicaes da matriz de rastreabilidade

Este artigo apresenta alguns aspectos tericos
associados engenharia de requisitos, e em particular, manipulao da matriz de rastreabilidade.
Alm disso, tambm sero discutidos alguns aspectos associados gesto de mudanas.
Jos Alberto Zimermann
jazimermann@gmail.com
Rodrigo.devmedia@gmail.com
Bacharel em Cincia da Computao pela

Universidade Regional de Blumenau
(FURB). Atua como Analista de Sistemas
na empresa Dynamix Software, situada
em Blumenau, SC e tambm como desenvolvedor Java para o ambienteWeb. Possui conhecimento nos frameworks JBoss
Seam,Struts,Hibernate,entre outros.
Editor Chefe SQL Magazine | WebMobile |

Engenharia de Software Magazine
Thiago Carvalho de Sousa

thiagocsousa@gmail.com
Doutorando em Engenharia de Computao e Sistemas Digitais (EP-USP). Mestre e

Bacharel em Cincia da Computao (IMEUSP). Trabalha h mais de 10 anos com desenvolvimento de software, atuando como
gerente de projetos, analista de negcios
e requisitos em grandes multinacionais,
incluindo a Oracle, Johnson & Johnson
e Goodyear, bem como ministrando a
disciplina de engenharia de software em
diversas faculdades, tais como a Unifieo,
CEUT e Faete.
36
crescente busca pela qualidade

de um produto exige cada vez
mais que as empresas fabricantes de software busquem um processo
ou um modelo no qual se siga uma metodologia de trabalho de conhecimento
de todos os envolvidos. Neste contexto,
diversas empresas optam por processos
que contribuam no gerenciamento de
mudanas. O objetivo do controle de
mudanas assegurar que as alteraes
feitas em um projeto sejam consistentes
e passveis de mensurar o impacto que
iro gerar.
Engenharia de Software Magazine - Gerenciando mudanas a partir de requisitos

Gerir mudanas uma atividade fundamental
em projetos de desenvolvimento de software.
natural que os requisitos mudem e evoluam
ao longo do tempo. Cabe equipe de desenvolvimento gerenciar isto da melhor forma com
intuito de minimizar impactos negativos no
andamento do projeto.
Resumo
Este artigo trata do assunto gesto de mudanas.
Este assunto ser analisado sob a perspectiva da
engenharia de requisitos. Assim, inicialmente
so apresentados conceitos importantes para
o entendimento do assunto como: engenharia
de requisitos, gerncia de requisitos, matriz de
rastreabilidade e gesto de mudanas. Ao final,
apresentada uma abordagem que pode ser
utilizada nas atividades de gesto de mudanas
com o objetivo de priorizar e avaliar as mudanas solicitadas por clientes nos requisitos.
requisitos
No mercado, existem diversas ferramentas que contemplam

as fases de elaborao e desenvolvimento de um sistema, auxiliando inclusive a implantao e uso de processos de software
bem definidos.
Comumente percebe-se que dentro da rea de informtica
as empresas encontram dificuldades em gerir o processo de
mudana em virtude de fatores como a velocidade e dinmica
com que elas ocorrem. As mudanas no software so feitas
em resposta a solicitaes de modificao de requisitos de
um projeto e isso deve ser feito de maneira que a estrutura
fundamental j existente permanea estvel.
Sommerville afirma que 65% da manuteno de um sistema
est relacionada implementao de novos requisitos, 18% na
modificao de requisitos j existentes e 17% na correo de
defeitos de um sistema. Desta maneira, a manuteno pode
ser considerada como uma extenso do processo de desenvolvimento de software, com atividades associadas s de
especificao, projeto, implementao e testes.
Neste sentido, dentro do processo de manuteno, Pressman afirma que um dos problemas clssicos associados
manuteno a dificuldade em se rastrear a evoluo do
software, uma vez que as mudanas no esto devidamente
documentadas. J Borges defende que para se obter o controle
e estabilidade de requisitos, durante o projeto de desenvolvimento, necessrio acompanhar quantitativamente as
alteraes em requisitos. Isto permite mensurar o tamanho
das alteraes, em termos de esforo empregado na manuteno dos artefatos.
Considerando este contexto, este artigo apresenta alguns
aspectos tericos associados engenharia de requisitos, e em
particular, manipulao da matriz de rastreabilidade. Alm
disso, tambm sero discutidos alguns aspectos associados
gesto de mudanas.
Alguns fundamentos
Nesta seo discutiremos alguns fundamentos tericos importantes ao estudarmos o assunto gesto de mudanas no
contexto da engenharia de requisitos. Para isso, descreveremos
inicialmente as fases de um processo de desenvolvimento de
software e a gerncia de requisitos. Em seguida, so explicados os benefcios da gesto de mudanas em um projeto,
mostrando os estgios em que ela deve ser executada. Feito
isto, apresentaremos o conceito e as funcionalidades da rastreabilidade de requisitos e artefatos. Por fim, apresentamos
a metodologia AHP, enfatizando o seu funcionamento e como
pode ser aplicada.
Processos de desenvolvimento de software
Um processo de software pode ser definido como sendo uma
srie de atividades e resultados que possui como finalidade
gerar um produto de software. Os processos de softwares so
complexos e devem seguir uma srie de procedimentos a fim
de garantir um produto que atenda as diversas necessidades
do cliente. Neste sentido, existem diversos processos que tm
como caractersticas comuns as seguintes fases:
especificao: onde ocorre a definio das funcionalidades

do software, indicando inclusive, as suas restries;
projeto e implementao de software: nesta etapa onde
ocorre o desenvolvimento do software, atendendo a especificao anteriormente descrita;
validao do software: o software necessita ser validado,
garantindo que ele atenda as necessidades do cliente;
evoluo do software: o software pode evoluir para atender
as necessidades mutveis do cliente.
Engenharia de requisitos
Existem diferentes definies encontradas na literatura tcnica para engenharia de requisitos:
Termo usado para descrever as atividades relacionadas investigao e definio de escopo de um sistema de software;
Processo sistemtico de desenvolvimento de requisitos atravs
de um processo cooperativo de anlise onde os resultados das
observaes so codificados em uma variedade de formatos e a
acurcia das observaes constantemente verificada;
Processo de descobrir, analisar, documentar e verificar as
funes e restries do sistema.
Embora coerentes, estas definies podem ser melhoradas.
Perceba que elas referem-se apenas s atividades relacionadas
produo de requisitos. Entretanto, nada dito a respeito da
gerncia destas atividades, tambm conhecida como gerncia
de requisitos. Com isto em mente, podemos evoluir a definio
de engenharia de requisitos para: termo usado para descrever
as atividades relacionadas produo (levantamento, registro,
validao e verificao) e gerncia (controle de mudanas, gerncia de configurao, rastreabilidade, gerncia de qualidade
dos requisitos) de requisitos.
Neste ponto podemos citar alguns dos principais objetivos
da engenharia de requisitos:
estabelecer uma viso comum entre o cliente e a equipe de
projeto em relao aos requisitos que sero atendidos pelo
projeto de software;
registrar e acompanhar requisitos ao longo de todo o processo
de desenvolvimento;
documentar e controlar os requisitos alocados para estabelecer uma baseline para uso gerencial e da engenharia de
software;
manter planos, artefatos e atividades de software consistentes
com os requisitos alocados.
Gerncia de requisitos
Requisitos so por natureza volteis. Diversos fatores contribuem para sua instabilidade ao longo do tempo. Mudanas
externas no ambiente (mudanas de legislao, mudanas no
mercado, mudana no posicionamento estratgico da empresa), erros incorridos no processo de requisitos, entre outros.
Todos esses fatores fazem com que seja necessrio alterar os
requisitos. Tais alteraes precisam ser conduzidas de forma
ordenada para que no se perca controle sobre o prazo e o
custo do desenvolvimento.
37
Denominamos a atividade de administrar os requisitos ao

longo do tempo de gerenciamento de requisitos.
Ao se colocar um software em uso, novos requisitos so
detectados como necessrios e os j existentes so alterados
medida que o sistema utilizado. Partes dos requisitos podem
ser modificadas para corrigir erros encontrados na operao ou
at mesmo para melhorar o desempenho da aplicao.
importante que o projeto de software seja atualizado com a
evoluo do sistema a partir da incluso, alterao ou excluso
de requisitos, a fim de se identificar de maneira clara quais
so os componentes envolvidos nas alteraes de um sistema.
justamente neste contexto que se destaca a rea de gerncia
de requisitos.
Sommerville afirma que os requisitos nos grandes sistemas
esto em constante modificao.
A gerncia de requisitos est associada ao processo de controle do processo de desenvolvimento tendo como referncia a
base de requisitos. Segundo Tocchetto, o principal objetivo do
gerenciamento de requisitos descobrir, organizar, comunicar
e administrar o impacto das mudanas de requisitos de um
software. Desta maneira, tem-se que os principais benefcios
do gerenciamento de requisitos so:
maior controle em projetos de grande porte;
aumento da qualidade de software e maior satisfao do
cliente;
diminuio dos custos de projeto e atrasos.
Gesto de mudanas
O processo de manuteno explicado por Sommerville ao se
iniciar um conjunto de pedidos de mudana por parte dos usurios, gerentes ou clientes. Custo e impacto devem ser analisados
para se verificar quanto do sistema ser afetado pela alterao e
quanto poder custar para desenvolver esta mudana.
Assim sendo, em uma situao ideal, o estgio de desenvolvimento de alteraes dever modificar especificao, projeto
e implementao do sistema, com o objetivo de refletir no
software. Desta maneira, os novos requisitos que refletem as
mudanas no sistema so propostos, analisados e validados,
para que a mudana seja consistente e no impacte de maneira
negativa no restante do sistema.
Neste contexto, a gerncia de mudana tem o objetivo de garantir
que as mudanas sejam realizadas com sucesso, sem que haja
perda da qualidade do software. Para que isso ocorra, necessrio
que esta fase da manuteno do software controle as solicitaes
de manuteno, aprove as solicitaes e a partir da, estabelea
como a modificao ser implementada e quais restries que
devero ser respeitadas, definindo de maneira clara qual o escopo
da alterao. Ainda segundo Sommerville, existem trs estgios
em um processo de gerenciamento de mudanas:
anlise do problema e especificao da mudana;
anlise e custo da mudana;
implementao de mudanas.
Nestes estgios so utilizadas informaes de rastreabilidade
para se estimar o tamanho e o custo da mudana. O custo da
38
mudana estimado em termos das modificaes no documento de requisitos e, se apropriado, no projeto de sistemas
e na implementao. Desta maneira, entende-se que muito
importante possuir o documento de requisitos e o projeto de
software constantemente atualizados.
Rastreabilidade de requisitos
A rastreabilidade uma tcnica que prov o relacionamento
entre diversos requisitos, projeto e a sua implementao. ela
quem auxilia no entendimento dos relacionamentos que existem entre os requisitos e o projeto de software desenvolvido.
Em resumo, podemos dizer que a rastreabilidade a habilidade
de descobrir o histrico de cada funcionalidade do sistema.
Neste sentido, a rastreabilidade permite garantir como e
porque os artefatos atendem os requisitos dos clientes, sendo
uma forma fundamental para entender os relacionamentos
existentes entre requisitos e outros artefatos que fazem parte
do processo de software. Desta maneira, a elaborao de
um projeto de software deve produzir requisitos que sejam
rastreveis, ou seja, que sejam capazes de serem rastreados a
partir da sua origem.
Por outro lado, temos tambm que um dos maiores desafios
da engenharia de requisitos criar um mecanismo que possibilite a criao de links entre os requisitos e os cdigos fontes.
Desta maneira, um dos benefcios que a rastreabilidade oferece
a possibilidade de se cruzar as informaes especificadas na
fase de projeto (requisitos) e os itens desenvolvidos na fase de
implementao, que so os cdigos fontes.
A rastreabilidade permite que as estimativas de custos das
alteraes em requisitos de um projeto possam ser mais precisas. Tambm permite que as mudanas possam ocorrer sem
a dependncia do engenheiro ou programador de conhecerem
as reas afetadas por tais mudanas.
possvel afirmar que a manuteno da rastreabilidade
pode ser um trabalho penoso, extenso e at mesmo invivel,
quando no auxiliado por uma ferramenta especializada. Isso
explicado por Richardson e Green que afirmam que programadores so relutantes em manter os documentos do projeto
atualizados, quebrando assim, o mecanismo que possibilita
ocorrer a rastreabilidade.
Classificao da rastreabilidade
Segundo Genvigir, existem duas maneiras de se efetuar a
rastreabilidade:
forward: rastreabilidade efetuada em um requisito at seus
refinamentos;
backward: rastreabilidade efetuada de um refinamento at
sua origem.
Ainda de acordo com Genvigir, um processo de rastreabilidade falho caso no seja possvel realizar um destes dois
tipos de rastreabilidade. Isto est ligado ao fato de que estas
capacidades so propriedades bsicas para a realizao da
atividade de rastreabilidade. possvel classificar ainda a
rastreabilidade quanto aos seus tipos:
requisitos
horizontal: rastreabilidade efetuada entre verses ou variaes de uma base de artefatos. Ocorre em uma determinada
fase do ciclo de vida do projeto;
vertical: rastreabilidade que ocorre entre requisitos e artefatos
produzidos pelo processo de desenvolvimento do projeto.
Uma viso sobre os tipos de rastreabilidade apresentada na
Figura 1. Perceba que ao trabalharmos com a rastreabilidade
vertical estamos lidando com artefatos presentes em diferentes
atividades do desenvolvimento. Por outro lado, ao trabalharmos com a rastreabilidade horizontal, estamos mapeando
conceitos dentro de uma mesma atividade ou artefato base.
sendo possvel assim mapear os valores das fases do projeto,

tendo-se desta forma o real custo de cada um deles a partir da
aplicao de uma mtrica.
Este mtodo baseia-se no mtodo newtoniano e cartesiano
de pensar, que busca tratar a complexidade com a decomposio e diviso do problema em fatores, que podem ainda ser
decompostos em novos fatores at o nvel mais baixo, claros e
dimensionveis e estabelecendo relaes para sintetizar.
Etapas para a construo de um pensamento analtico
Segundo Costa, possvel definir duas etapas de pensamento
analtico:
construo de hierarquias: no mtodo AHP o problema
estruturado em nveis, facilitando desta forma, a melhor
compreenso e avaliao deste. A Figura 2 apresenta esta
estrutura do pensamento analtico. Para aplicar o AHP necessrio que tanto os critrios quanto as alternativas possam
ser estruturadas de forma hierrquica, sendo que no primeiro
nvel a hierarquia corresponde ao propsito geral do problema,
o segundo e o terceiro s alternativas do problema;
Figura 2. Representao de uma estrutura hierrquica
Figura 1. Rastreabilidade horizontal e vertical
Agora que conhecemos alguns dos fundamentos da engenharia de requisitos relacionados gesto de mudanas, vamos
apresentar uma abordagem que pode ser utilizada na tarefa
de definio de prioridades a partir das informaes contidas
na matriz de rastreabilidade.
Conhecendo a metodologia AHP
A metodologia AHP foi criada por Saaty com o objetivo de
ponderar as caractersticas qualitativas, permitindo assim, a
ponderao e priorizao de cada um dos requisitos de um
projeto que esto inseridos no projeto. O funcionamento deste
processo se d pela atribuio de pesos a fatores individuais,
do menos influente ao mais influente. AHP utiliza-se de uma
matriz quadrada que permite avaliar a importncia de uma
caracterstica sobre a outra. A partir disso, o processo permite
obter o valor percentual de cada um dos requisitos e assim,
mapear o valor das fases do projeto.
Segundo Tocchetto, o processo AHP permite obter o valor
em percentual de cada requisito que faz parte do projeto,
definio de prioridades: fundamenta-se na habilidade do ser

humano de perceber o relacionamento entre objetos e situaes
observadas, comparando pares, sob um mesmo foco, critrio ou
mesmo julgamento. Para se cumprir este princpio, necessrio
que o julgamento ocorra entre um par de elementos, aplicando
a escala definida na Tabela 1. Esta comparao se d atravs da
montagem de uma matriz entre os elementos, onde i representa
o elemento de uma linha e j um elemento da coluna.
Segundo Marins, Souza e Barros, a quantidade de julgamentos para a construo de uma matriz de julgamentos genrica
A n (n-1)/2, onde n o nmero de elementos pertencentes a
esta matriz. Os elementos de A so definidos pelas condies
apresentadas na Figura 3.
Figura 3. Condies para a definio de uma matriz de julgamento
O processo de aplicao da metodologia AHP

Para se entender o funcionamento do processo de clculo
do AHP, pode-se considerar o exemplo descrito a seguir.
39
Escala
Definio
Descrio
Menos importante
Duas atividades contribuem igualmente para o objetivo
Importncia pequena
A experincia e o julgamento favorecem levemente uma atividade em relao outra
Importncia grande ou essencial
A experincia e o julgamento favorecem fortemente uma atividade em relao outra
Importncia muito grande
Uma atividade fortemente favorecida. Sua dominao de importncia demonstrada na prtica
Importncia absoluta
A evidncia favorece uma atividade em relao outra com o mais alto grau de certeza
2, 4, 6, 8
Valores intermedirios. Se na atividade j (coluna) recebe um dos Quando se deseja maior compromisso. uma designao razovel
valores acima, quando comparada com a atividade j (coluna),
ento j (coluna) tem o mesmo valor recproco de i (linha)
Razo da escala
Se a consistncia tiver de ser forada para obter n valores numricos para completar a matriz.
Racionais
Tabela 1. Escala numrica da metodologia AHP
Para tal, ser considerado um projeto que contm trs requisitos, os quais so:
requisito 1;
requisito 2;
requisito 3.
no processo. O clculo do auto-vetor se d atravs da expresso

definida na Figura 4.
O relacionamento realizado entre os requisitos do projeto

apresentado atravs da Tabela 2.
Requisito 1
Requisito 2
Requisito 3
Requisito
Requisito 1
a12
a13
Requisito 2
a21 = 1/a12
a23 = 1/a32
Requisito 3
a31 = 1/a13
a32
Tabela 2. Matriz de importncia entre os requisitos
A partir da definio desta matriz, deve-se incluir os valores

para cada par de requisitos, de acordo com a escala proposta
pelo autor do processo e apresentada na Tabela 1.
Deve-se observar que a insero de valores para a definio
da matriz de importncia feita a partir de definio de um
critrio ou julgamento. Assim, os valores so inseridos na
matriz de acordo com a escala de importncia estabelecida
pelo julgamento. Na Tabela 3 possvel verificar a formao
da matriz.
Requisito 1
Requisito 2
Requisito 3
Requisito 1
1/3
Requisito 2
Requisito 3
1/5
Tabela 3. Matriz de importncia
Aps a definio, necessrio efetuar o clculo do auto-vetor

e a sua normalizao, para cada um dos requisitos envolvidos
40
J a normalizao do auto-vetor se d com base na expresso

apresentada na Figura 5.
Figura 5. Expresso para a normalizao do auto-vetor
Conforme observado por Tocchetto, as premissas que devem

ser seguidas para a insero de valores so:
Se aij = , ento aji = 1/ , diferente de 0;
Se o requisito i julgado com igual importncia ao requisito
j, ento aij = 1, aji = 1 e aii = 1.
Requisito
Figura 4. Expresso para a obteno do auto-vetor
A partir da definio e conhecimento das frmulas apresentadas nas Figuras 4 e 5, pode-se exemplific-las, aplicando as
frmulas para o Requisito 1, que :
somatrio da coluna do Requisito 1: T = 1 + 3 + 0,5 = 4,5;
primeira linha da primeira coluna normalizada: (1 * 100) /
4,5 = 22,22 / 100 = 0,22;
segunda linha da primeira coluna normalizada: (3 * 100) /
4,5 = 66,66 / 100 = 0,66;
terceira linha da primeira coluna normalizada: (0,5 * 100) /
4,5 = 11,11 / 100 = 0,11.
Este processo de normalizao deve ser feito com todos
os requisitos envolvidos no processo. Segundo Tocchetto, a
utilizao do vetor T normalizado serve para quantificar e
ponderar a importncia de vrias caractersticas de um requisito. Voc pode acompanhar o resultado da normalizao
do vetor na Tabela 4.
Requisito
Requisito 1
Requisito 2
Requisito 3
Resultado
Requisito 1
0,22
0,21
0,25
0,68
Requisito 2
0,67
0,65
0,63
1,95
Requisito 3
0,11
0,13
0,12
0,36
Tabela 4. Matriz com os valores normalizados
requisitos
Requisito normalizado
Importncia (%)
1/3
0,68
22,44
1/3
1,95
64,35
1/3
0,36
11,88
Concluso
A engenharia de requisitos define, sem dvida, um dos mais
importantes conjuntos de atividades a serem realizadas em

Feedback
eu
Referncias
APACHE SOFTWARE FOUNDATION.Apache log4j 1.2.[S.l.], 2011.<http://logging.apache.org/log4j/1.2//>.
BATISTA, Raphael M. Ferramenta de gerncia de requisitos de software integrada com Enterprise
Architect. 2007. 67 f. Trabalho de Concluso de Curso (Bacharelado em Cincias da Computao)
Centro de Cincias Exatas e Naturais, Universidade Regional de Blumenau, Blumenau. <http://
campeche.inf.furb.br/tccs/2007-I/2007-1raphaelmarcosbatistavf.pdf>.
BELTRO FILHO, Mauro F. de H. Gingway uma ferramenta para criao de aplicaes GingaNCL interativas para TV digital. 2008. 59 f. Monografia (Bacharelado em Cincia da Computao)
Centro de Informtica, Universidade Federal de Pernambuco, Recife. <http://www.cin.ufpe.
br/~tg/2008-2/mfhbf.pdf>.
Computao Aplicada Instituto Nacional de Pesquisas Espaciais, So Jos dos Campos. <http://
mtc-m18.sid.inpe.br/col/sid.inpe.br/mtc-m18%4080/2009/03.02.14.17/doc/publicacao.pdf>.
HAMILTON,Vivien L.;BEEBY,Martin.Issues of traceability in integration tools.In:IEE COLLOQUIUM ON TOOLS
ANDTECHNIQUES FOR MAINTAININGTRACEABILITY DURING DESIGN,1.,1991,Londres.Procedings. Londres:
IEEE, 1991. p. 4/1-4/2. <http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=182212>.
HAROLD, Elliotte R. Processing XML with Java. [S.l.], 2001. <http://www.cafeconleche.org/books/xmljava/>.
HAZAN, Claudia; LEITE, Julio C. S. P. Indicadores para a gerncia de requisitos. In: WORKSHOP EM
ENGENHARIA DE REQUISITOS, 6., 2003, Piracicaba. Anais eletrnicos... Rio de Janeiro: PUC-RIO, 2003. No
paginado. <http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER03/claudia_hazan.pdf>.
BORGES, Eduardo P. Um modelo de medio para processos de desenvolvimento de software.

2003. 154 f. Dissertao (Mestrado em Cincia da Computao) Departamento de Cincia da
Computao, Universidade Federal de Minas Gerais, Belo Horizonte. <http://homepages.dcc.ufmg.
br/~wilson/pesquisa/DissertacaoEduardo.pdf>.
HENKELS, Andr. Drawcode: um plugin do eclipse para gerao de cdigo a partir de diagramas de
classe e diagramas N-S. 2007. 101 f. Trabalho de Concluso de Curso (Bacharelado em Cincias da
Computao) - Centro de Cincias Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.
BON, Jonas; VASSEUR, Alexandre. AspectWerkz: plain Java AOP 2.0 API. [S.l.], 2005. <http://
aspectwerkz.codehaus.org>.
HUNTER, Jason; MCLAUGHLIN, Brett. JDOM: FAQ. [S.l.], 2007. <http://www.jdom.org/docs/faq.

html#a0000>.
BURNETTE, Ed. Eclipse IDE guia de bolso. Traduo Joo Torello. Porto Alegre: Bookman, 2006.
JASPERFORGE. IReport: JasperForge. [S.l.], 2011. <http://jasperforge.org/projects/ireport>.
COSTA, Helder G. Introduo ao mtodo de anlise hierrquica: anlise multicritrio no auxlio

deciso. Niteri: Universidade Federal Fluminense, 2002.
LOPES, Luiz H. C. Sistema web para gesto de pautas e atas de reunies. 2008. 55 f. Monografia (Curso
de Especializao em Informtica Empresarial) Universidade Estadual Paulista, Guaratinguet.
<http://www.feg.unesp.br/ceie/Monografias-Texto/CEIE0805.pdf>.
ECLIPSE FOUNDATION. About the eclipse foundation. [S.l.], 2011. <http://www.eclipse.org/org/>

FEIGENBAUM, Barry. SWT, Swing or AWT: which is right for you? [S.l.], 2006. <http://www.ibm.
com/developerworks/grid/library/os-swingswt/>
FERREIRA, Felype S. Implementao e anlise de uma linha de produtos de software. 2009. 67
f. Projeto de Graduao (Bacharelado em Cincia da Computao) Centro de Informtica,
Universidade Federal de Pernambuco, Recife. <http://www.cin.ufpe.br/~tg/2009-2/fsf2.pdf>.
GENVIGIR, Elias C. Um modelo para rastreabilidade de requisitos de software baseado em
generalizao de elos e atributos. 2009. 200 f. Teste de Doutorado do Curso de Ps Graduao em
MARINS, Cristiano S.; SOUZA, Daniela de O.; BARROS, Magno da S. O uso do mtodo de anlise
hierrquica (AHP) na tomada de decises gerenciais: um estudo de caso. In: SIMPSIO BRASILEIRO
DE PESQUISA OPERACIONAL - PESQUISA OPERACIONAL NA GESTO DO CONHECIMENTO, 41., 2009,
Porto Seguro. Anais eletrnico... Rio de Janeiro: Universidade Federal Fluminense, 2009. p. 17781788. <http://www.ic.uff.br/~emitacc/AMD/Artigo%204.pdf>.
OLIVEIRA, Fabricio. Software de apoio gerncia de solicitao de mudanas. 2006. 72 f. Trabalho
de Concluso de Curso (Bacharelado em Cincias da Computao) Centro de Cincias Exatas e
Naturais, Universidade Regional de Blumenau, Blumenau.
41
sobre e
s
Tabela 5. Importncia de cada requisito
D
s
Fator 1/n
projetos de desenvolvimento de software. Neste contexto,

vimos neste artigo que gerir mudanas uma atividade
fundamental em projetos de desenvolvimento de software.
natural que os requisitos mudem e evoluam ao longo do
tempo. Cabe equipe de desenvolvimento gerenciar isto da
melhor forma com intuito de minimizar impactos negativos
no andamento do projeto.
edio
ta
Desta maneira, o percentual de importncia de cada requisito

apresentado atravs da Tabela 5. Assim, tem-se que:
o requisito 1 equivale aproximadamente a 22,44% do projeto;
o requisito 2 equivale aproximadamente a 64,35% do projeto;
o requisito 3 equivale aproximadamente a 11,88% do projeto.
Nesta seo voc encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software
Introduo ao desenvolvimento de
aplicaes de realidade aumentada
Andr Luis Tosato da Cruz
Paulo C. Barreto da Silva
andreluistosatoo@gmail.com
paulo.b@aedu.com
Graduando em Cincia da Computao pela

Faculdade Anhanguera de Santa Barbara
(2011), atualmente trabalhando como Assistente de Desenvolvimento(Delphi e c#) e
possui interesse por programao.
Graduado em Anlise de Sistemas pelo

Centro Universitrio Salesiano de So Paulo
(2003) e Ps-graduado pela Universidade
Estadual de Campinas - UNICAMP na rea
de Orientao a Objetos (2005). Professor
da Anhanguera Educacional SA e Analista
de Sistemas na Papirus Indstria de Papel
SA. Possui experincia de 12 anos na rea
de Cincia da Computao, com nfase em
Sistemas de Informao, atuando principalmente nos seguintes temas: anlise de
sistemas, programao orientada a objetos, programao estruturada, desenvolvimento de sistemas, UML (Linguagem de
Modelagem Unificada), gesto de projetos,
linguagem de programao C e Java.
Victor Angelo Marcorin

victor.am.ccomp@gmail.com
Graduando em Cincia da Computao pela

Faculdade Anhanguera de Santa Barbara
(2011). Estagirio na rea da computao
recm-contratado pela ItalyTex. Possui conhecimentos na rea de desenvolvimento de
softwares e manuteno de computadores.
Thiago Salhab Alves

thiago.alves@aedu.com
Graduado em Cincia da Computao pela

Universidade Metodista de Piracicaba
UNIMEP (2004) e Mestre em Cincia da
Computao pela Universidade Metodista de
Piracicaba - UNIMEP (2008). Professor e Coordenador do curso de Cincia da Computao
da Faculdade Anhanguera de Santa Brbara.
Possui seis anos de experincia na rea de
Cincia da Computao com nfase em Engenharia de Software.
42
Realidade Virtual vem revolucionando a rea da educao

com suas caractersticas que
permitem ao usurio vivenciar situaes
atravs de navegao e interao em
mundos virtuais.
A Realidade Aumentada pode ser
definida como uma combinao do
ambiente real com o ambiente virtual.
Este artigo apresenta os conceitos de desenvolvimento de sistemas que adotam o conceito de Realidade Aumentada. Este artigo serve como base para
estudantes e profissionais da rea de computao
que estejam interessados em conhecer os aspectos
fundamentais da Realidade Aumentada como ferramenta de apoio.

Como embasamento para projetos que desejem
adotar ferramentas grficas de simulao. Projetos
que utilizem a incluso de objetos virtuais interativos com o objetivo de demonstrar um ambiente
virtual prximo da experincia real.
Resumo
A Realidade Aumentada pode ser definida como uma
combinao do ambiente real com o ambiente virtual.
Neste contexto, este artigo apresenta conceitualmente o tema e, na sequncia, faz uma introduo ao desenvolvimento de aplicaes desta natureza.
Atualmente, ela o tipo de interface com

o usurio que tem chamado mais a ateno pelo fato de permitir aos usurios
executar tarefas de forma mais intuitiva
e eficiente. As interfaces de Realidade
Engenharia de Software Magazine - Introduo ao desenvolvimento de aplicaes de realidade aumentada
Aumentada devem aumentar a percepo do usurio sobre o

mundo real adicionando informaes virtuais nele.
Um dos problemas na rea da educao manter a motivao
dos alunos no aprendizado de um determinado contedo.
Muitas vezes faltam recursos para os professores de anatomia
auxiliar a formao dos educandos e tambm motivao por
parte deles, principalmente na rea mdica, em funo da
complexidade do corpo humano.
Neste contexto, este artigo apresenta uma introduo ao
desenvolvimento de aplicaes em realidade aumentada, enfatizando as possibilidades existentes para a rea da educao
e mdica (ler Nota do DevMan 1).
Nota do DevMan 1
Aprendizagem de Anatomia Humana
Segundo Braz [1], vrios alunos ingressantes em cursos que possuem a matria de
Anatomia Humana passam por vrias dificuldades no entendimento da matria devido a vrios motivos: a dificuldade do aluno com a terminologia anatmica, o pequeno
tamanho das estruturas, o preparo inadequado das peas e vrios fatores individuais
como falta de motivao, ateno e o medo ou receio existente quando o aluno se
depara com os cadveres humanos.
Em uma experincia de aula, uma professora dividiu 132 alunos do Curso de Farmcia em duas turmas, onde em uma, ela aplicou os mtodos de ensino tradicionais e na
outra, foram utilizados os mesmos mtodos, s que aps a aula, os alunos permaneciam no laboratrio para interagir com as estruturas estudadas em sala, e aps essa
interao foi proposto para os alunos que explicassem as estruturas para o professor
e colegas.
Ao final do estudo, a primeira turma teve uma mdia de 35,17% e a segunda turma
obteve uma mdia de 56,67%, ento chegou-se concluso que tendo-se mais contato e mais facilidade para ver as estruturas a serem estudadas, o aluno tem um maior
aproveitamento do curso.
utilizando dispositivos tecnolgicos como webcams, cmeras

digitais, culos digitais, entre outros.
Pelo fato de utilizar os movimentos do corpo como uma
forma de interao com o computador atravs de dispositivos
caractersticos da tecnologia, a Realidade Virtual considerada
como a forma mais avanada de comunicao entre pessoas
e computadores.
Segundo Kirner e Zorzal [4], a Realidade Aumentada pode
ser definida como uma tecnologia atravs da qual se incrementa ou aumenta a viso que um utilizador tem do mundo
real com a adio de imagens virtuais, usando tcnicas de
viso por computador e de Computao Grfica/Realidade
Virtual, resultando na sobreposio de objetos virtuais com
o mundo real.
Esta tecnologia possibilita que o usurio tenha uma interao
atrativa e motivadora com o ambiente, propiciando ento o desenvolvimento de habilidades e construo do conhecimento.
Aplicaes de Realidade Aumentada

cada vez mais comum nos depararmos com vrias aplicaes
da Realidade Aumentada atualmente, j utilizada na Educao,
Medicina, Jogos, Design, Engenharia e dentre outros.
Uma de suas aplicaes mais recentes foi a campanha da
nova fragrncia da Empresa AXE, que tinha como slogan da
campanha Even Angels will fall... (At os Anjos cairo...),
onde colocaram um marcador no meio de uma estao de
metr, e quando a pessoa passava e olhava para cima, aparecia
um anjo no telo da estao (ver Figura 1).
Contextualizando
Realidade Aumentada mais um das vertentes da Realidade
Virtual, porm enquanto a Realidade Virtual tem como princpio a insero do usurio em um ambiente fictcio gerado
por computador, isentando este de todo ou quase todos os
sentidos reais, a Realidade Aumentada insere objetos virtuais
em um ambiente real sem ocultar do usurio o que est a sua
volta. Como o prprio nome diz, seu objetivo aumentar a
complexidade do mundo real inserindo objetos virtuais e tudo
isto em tempo de execuo real.
Esta tecnologia est cada vez mais inserida em nosso cotidiano, pois j existem aplicaes em celulares, jogos, simuladores,
inclusive aplicaes na rea mdica e artstica.
Realidade aumentada uma especializao da realidade virtual, baseada na insero de objetos virtuais em uma cena real,
podendo o usurio interagir com o objeto em tempo real.
Realidade Aumentada
A Realidade Aumentada uma tecnologia que possibilita a
incluso de objetos virtuais interativos em um ambiente real,
Figura 1. Campanha Publicitria da empresa AXE com RA
Medicina
A Realidade Aumentada j est ajudando pessoas que sofrem
de varizes. Dr. KasuoMiyake (Especialista no tratamento de
varizes) ajustou o equipamento VeinViewer, uma espcie de
viso de raios X, que auxilia na coleta de sangue e na medicao intravenosa, e o adaptou utilizando RA para auxiliar no
tratamento de varizes, dispensando cirurgia. Segundo Miyake,
esta tcnica j evitou cirurgias em 86% dos casos desde 2007
(ver Figura 2).
Aps analisar a aplicabilidade da realidade aumentada no
cotidiano das pessoas, Sabbatini [6] concluiu que j existe
disponvel no mercado uma vasta gama de equipamentos
43
baseados em realidade aumentada, sendo a rea mdica a mais

avanada no assunto.
O uso de equipamentos baseados em realidade aumentada
tem permitido o amplo treinamento de suturas como mostrado
nas Figuras 3 e 4, insero de cateter na veia subclvia, discotomia vertebral laparoscpica, dentre muitas outras coisas.
Os passos apresentados na Figura 5 so descritos da seguinte

maneira:
Captura da cena com o marcador;
Identificado o smbolo encontrado, o software busca pela
imagem 3D referente ao cdigo do marcador;
Procura a posio da imagem 3D de acordo com a posio
do marcador;
Volta a identificar o marcador para calcular o posicionamento do objeto 3D;
Por fim, insere o objeto virtual no meio real de acordo com
os dados encontrados;
O resultado final exibido ao final desses passos.
Figura 2. Aplicando RA para o Tratamento de Varizes
Figura 5. Funcionamento de RA pela posio do Marcador

Figura 3. Exemplo de uma aplicao da realidade virtual na medicina
Simulao de micro suturas
A disposio do objeto pode ser interferida de vrias maneiras, como brilho de luz sobre a parte escura do marcador, colocar qualquer objeto que esconda esta mesma parte do marcador
tambm ocasiona a perda da imagem, e para movimentos mais
rpidos necessrio o uso de um objeto de captura de grande
preciso (ver Figura 6).
Figura 4. Treinamento de Suturas
Funcionamento da Realidade Aumentada

A realidade aumentada possui seu funcionamento baseado
na captura de uma imagem codificada e devolvendo sobre
esta uma figura em 3D com total mobilidade e execuo em
tempo real, pois de acordo com a posio do marcador a figura
projetada ajustada.
44
Figura 6. Amostra da RA
Ferramentas para Desenvolvimento

Atualmente temos vrias ferramentas disponveis para o
desenvolvimento de realidade aumentada. Um das ferramentas
o FLARToolKit. Segundo Tomohiko Koyama, um de seus
desenvolvedores, uma verso baseada no NyARToolKit
(ARToolKit para Java), adaptada para o Flash, que possvel

de ser incorporado em pginas Web. Para o desenvolvimento
de aplicaes com o FLARToolkit necessrio ter objetos 3D
desenvolvidos nas principais engines 3D do Flash como o Papervision 3D, Away 3D, entre outros e utilizar programao
em ActionScript, alm de ter um ambiente de desenvolvimento
para Flash (ver Figura 7).
ARToolKit
O ARToolKit uma biblioteca Open Source desenvolvido em
linguagem C e C++ para o desenvolvimento de aplicaes em
realidade aumentada. No site http://www.hitl.washington.
edu/artoolkit/download/ pode ser feito o download do pacote
de desenvolvimento.
Segundo o site oficial do ARToolKit escrito por Phillip Lamb,
o desenvolvimento do ARToolKit comeou em 1999 quando
Hirokazo Kato chegou ao instituto HITLab (Human Interface
Tecnology Laboratory) da Universidade de Washington.
O ARToolKit foi apresentado pela primeira vez no SIGGRAPH Special Interest Group on GRAPHics and Interactive
Techniques (conferncia de profissionais em computao
grfica iniciada em 1974), uma verso para Windows usando
o directshow (uma biblioteca de rotinas prontas, uma API, desenvolvida pela Microsoft).
Hirokazo Kato e M. Billinghurst, os dois principais criadores
do ARToolKit, ainda trabalham no projeto.
Arquitetura do ARToolKit
Figura 7. Aplicao usando FLARToolkit
O funcionamento desta tecnologia se d basicamente da

seguinte forma:
A cmera captura imagens do mundo real e as envia ao
computador;
O software procura em frames do filme todas as formas
quadradas;
Se entre estes quadrados ele detectar um marcador, atravs
de algoritmos matemticos calculada a posio da cmera
em relao ao marcador;
Depois de calculada a posio da cmera, o modelo grfico
inserido na mesma posio da cena;
Sendo o modelo inserido na cena do mundo real, ele tem por
posio relativa o marcador;
A sada final exibida, dando ao usurio a iluso de sobreposio do objeto cena real;
Um exemplo de sada pode ser observado na Figura 8, onde
o objeto virtual inserido em cima do marcador.
Na Figura 9, a rea em vermelho corresponde s aplicaes

em realidade aumentada. Em seguida vem o ARToolkit que
interage com as bibliotecas OpenGL, a GLUT, a Standard Library e Video Library. O OpenGL a biblioteca que cuida da
parte grfica da aplicao.
Figura 9. Arquitetura do ArtoolKit (HITLab, University of Washington)
A GLUT (OpenGL Utility Toolkit) uma biblioteca que faz

a comunicao e o suporte do OpenGL com o hardware e que
proporciona ainda o uso de uma API (Application Programming Interface), com menus, botes e suporte a joystick. Mesmo
no sendo um aplicativo de cdigo aberto, a GLUT pode ser
usada livremente.
A Standard API e a Video Library so APIs padro do sistema
operacional utilizado.
Principais estruturas do Artoolkit
Figura 8. Imagem inserida sobre o marcador
O ARToolKit utiliza algumas estruturas para que se guarde as

informaes necessrias para a manipulao das cenas. Tomando
como base a documentao desta biblioteca vamos descrever as
principais estruturas. Para isso, a Tabela 1 mostra as principais
funes do ARToolKit juntamente com seus significados.
45
Funo
Descrio
ARMarkerInfo
Principal estrutura utilizada em marcadores para guardar as informaes do contorno do marcador depois que este foi detectado.
ARMarkerInfo2
Estrutura interna usada para a deteco dos marcadores: armazena as informaes do contorno dos marcadores.
ARMat
a estrutura que guarda a matriz baseada em alocaes dinmica.
ARMultiEachMakerInfoT
Estrutura para vrios marcadores. Possui estrutura similar ao ARMakerInfo porm para mltiplos marcadores.
ARMultiMarkerinfoT
Estrutura utilizada para monitorar mltiplos marcadores.
ARParam
Estrutura que contem os principais parmetros para a representao da cmera.
ArPrevinfo
Estrutura que guarda o histrico de deteco de marcadores e transformaes de matriz.
ARVec
Estrutura de vetores com alocao dinmica.
Tabela 1. Principais funes do ARToolKit
A relao entre a cmera e os marcadores
Concluso
O ARToolKit calcula a posio do marcador e da cmera

atravs do sistema de coordenadas, com o uso do sistema
de matriz, possibilitando calcular a posio na qual o objeto
virtual vai ser inserido (ver Figura 10).
Neste artigo foram apresentados os conceitos bsicos da

Realidade Aumentada. Foi possvel identificar os benefcios
que a Realidade Aumentada tem proporcionado para as diversas reas de conhecimento, notadamente para a rea da
sade e educao.
Assim, espera-se ter contribudo para o entendimento da
realidade aumentada, assim como as possibilidades que esta
tecnologia pode alcanar.
Referncias
Augmented Reality Page: http://www.se.rit.edu/~jrv/research/ar/
HITLab - Human Interface Technology Laboratory: http://www.hitl.washington.edu/home/
Figura 10. Exemplo de marcador
Depois que a imagem capturada ela transformada em

uma imagem binria e atravs de algoritmos computacionais,
onde so reconhecidos os padres quadrados e recuperada a
posio de cada um dos quatros vrtices com estes valores,
calculada a posio do objeto que vai ser sobreposto na imagem
analisada conforme a Figura 10.
Neste sistema, cada quadro de imagem do ambiente capturado transformado para binrio para facilitar o reconhecimento
e a posio espacial do marcador a ser localizado. Feito isto,
para cada imagem de vdeo, o desenho interior do marcador
reconhecido comparado com os gabaritos de marcadores
pr-definidos (ver Figura 11).
Realidade Aumentada - Home: www.realidadeaumentada.com.br

1. BRAZ, Paula Regina Pereira. Mtodo Didtico Aplicado ao Ensino da Anatomia Humana.
Anurio da Produo Acadmica Docente, Valinhos, n. , p.303-310, 19 mar. 2010.
2. FAZOLLI, Fernando Yuki. Realidade Aumenta: Monografia do Bacharelado em Cincia da
Computao. Santa Brbara D Oeste: Faculdade Anhanguera de Santa Barbara, 2009.
3. GOMES, Wneiton Luiz; KIRNER, Cludio. Desenvolvimento de Aplicaes Educacionais na
Medicina Com Realidade Aumentada. Bazar: Software e Conhecimento Livres, 2006.
4. KIRNER, Claudio; ZORZAL, Ezequiel. Jogos Educacionais em Ambiente de Realidade
Aumentada. Workshop de Realidade Aumentada, Piracicaba, 2005. Disponvel em: <http://
www.realidadeaumentada.com.br/artigos/14534.pdf> Acesso em 27 de Junho de 2011.
5. MILGRAM, P. et al. Augmented Reality: A Class of Displays on the Reality-Virtuality Continuum,
Telemanipulador and Telepresence Technologies, SPIE, V. 2351, p. 282-292, 1994.
6. SABBATINI, R. M. E. O diagnstico mdico por computador. Informdica, 1(1): 5-10, maro/
abril de 1993.
Figura 11. Sequncia do reconhecimento do marcador (HITLab,

University of Washington)
46
sobre e
s

Feedback
eu
edio
ta
D
s
7. TORI, Romero; KIRNER, Claudio; SISCOUTO, Robson. Fundamentos e Tecnologia de Realidade

Virtual e Aumentada. Belm: VIII Symposium On Virtual Reality, 2006.
Nesta seo voc encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software
Boas prticas para escrita de mtodos,

funes e procedimentos Parte 6
Mantendo Limites e Casos de Teste Unitrios Limpos
Resumo
Aborda o tema Cdigo Limpo com o objetivo de mostrar como o desenvolvedor pode us-lo para melhorar
a qualidade do cdigo-fonte de suas aplicaes. Neste
sentido, este artigo prov conhecimento ao desenvolvedor sobre como transformar cdigos considerados
ruins em bons cdigos demonstrando atravs de
exemplos prticos as teorias aqui abordadas.
Esta srie de artigos tem discutido os aspectos

que permeiam o assunto Cdigo Limpo, seguindo
a linha de raciocnio que prope um aumento na
qualidade do cdigo das aplicaes existentes ou
proporcionar conhecimento de como criar projetos
de cdigo melhores quando se est iniciando um
novo projeto. Neste contexto, cdigo limpo se refere a um conjunto de caractersticas desejveis de
serem encontradas no cdigo de nossa aplicao.
Algumas dessas caractersticas so: ter um cdigo
que atenda os requisitos de eficincia, lgica do
negcio bem modelada e definida em forma de
cdigo fonte, mecanismos de tratamento de erro
bem definidos e cdigo que no d margem necessidade da realizao de novas otimizaes.
Jacimar Fernandes Tavares

jacimar.tavares@hotmail.com
Ps Graduando em Gesto de Projetos de

TI Universidade Federal de Juiz de Fora
UFJF
Bacharel em Cincia da Computao FAGOC
- Faculdade Governador Ozanam Coelho,
Atua como administrador financeiro na
empresa Transporte JR.

maraujo@devmedia.com.br
Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ,

Especialista em Mtodos Estatsticos Computacionais e Bacharel em Informtica pela
UFJF, professor do curso de Bacharelado em
Cincia da Computao da FAGOC, professor
dos Cursos de Bacharelado em Sistemas de
Informao do Centro de Ensino Superior
de Juiz de Fora e da Faculdade Metodista
Granbery, Analista de Sistemas da Prefeitura de Juiz de Fora, Editor da Engenharia de
Software Magazine.

O tema se torna fundamental para desenvolvedores que buscam cada vez mais melhorar suas
aplicaes ao focar em qualidade de cdigo. Essa
tarefa ser possvel graas ao conhecimento adquirido sobre limpeza de cdigo.
relao existente entre um software desenvolvido por uma

equipe, e que faz uso de cdigo
de terceiros, requer alguns cuidados,
como conhecer bem o cdigo a ser utilizado ou conhecer o que ele capaz de
fornecer em termos de funcionalidades.
Estabelecer a forma como o software
em desenvolvimento e o cdigo de
terceiros devem se comunicar uma
tarefa que envolve algumas verificaes.
Uma dessas verificaes consiste em

conhecer as funcionalidades que podero ser utilizadas e as funcionalidades
que no podero ser utilizadas, por
exemplo, uma funcionalidade na qual
um dos usurios do sistema no deve
ter acesso. Conhecidas as funcionalidades que se pode acessar e as que
no se pode, devem-se estabelecer os
limites, isto , criar mecanismos para
controlar o acesso a tais funcionalidades.
47
A forma como esses mecanismos so construdos, em alguns

casos, leva a escrita de cdigo que no considerado limpo.
Um dos objetivos deste artigo falar sobre esses mecanismos
que estabelecem limites e como mant-los limpos. A seo
Limites a responsvel por abordar este tema.
Em outro cenrio, agora abordando o tema teste unitrio de
software, necessrio entender alguns conceitos seguindo as
recomendaes de cdigo limpo.
Escrever casos de teste unitrio uma tarefa que envolve o conhecimento sobre as teorias envolvidas no processo de definio
de casos de teste e tambm consiste em saber como escrever casos
de teste de acordo com o que necessrio para um mtodo poder
ser considerado devidamente testado. Caso ainda no se tenha
esse conhecimento, o artigo sobre Teste unitrio com NUnit (ler
edio 43 da Engenharia de Software Magazine) poder ajudar
neste sentido.
O que alguns desenvolvedores no se preocupam est relacionado qualidade do cdigo de teste que esto implementando.
Qualidade de cdigo, referentes a cdigo de teste, passa pelas
teorias sobre cdigo limpo. Um dos objetivos da seo Teste
de Unidade mostrar como devem ser mantidos os cdigos de
teste criados para testar os mtodos das aplicaes.
Limites
Nesta seo abordaremos a importncia de estabelecer limites
para testar aplicaes. Esta seo d nfase a cdigo de terceiros
que muita das vezes so inseridos em algumas aplicaes devido, entre outras coisas, a necessidade de adquirir, por exemplo,
um componente de terceiros. Ao se conhecer os limites que o
cdigo ou componente de terceiros possuem, torna-se possvel
conhecer seu funcionamento e suas limitaes. Com base nestas informaes fica mais fcil saber quando uma nova verso
do cdigo ou componente de terceiros mais recomendada
ao projeto atual do que a verso antiga dos mesmos que est
sendo mantida no projeto.
Evitar que uma verso do cdigo ou componente permanea no projeto sem se ter a certeza que realmente til por
satisfazer alguma das necessidades do projeto uma prtica
que contribui para se ter um cdigo limpo. Dentre todos os
objetivos desta seo, manter o cdigo limpo, incluindo o
limite entre a aplicao e os cdigos de terceiros, o objetivo
principal.
Estabelecendo os limites entre o cdigo criado e o cdigo
de terceiros
Conceitua-se cdigo criado como o cdigo que est sendo implementado ou foi implementado em uma aplicao.
Conceitua-se cdigo de terceiros como qualquer cdigo que foi
implementado por outra empresa, equipe ou desenvolvedor,
cujo propsito satisfaz a alguma necessidade que se tem no
momento, e a razo pela qual o cdigo est sendo comprado/
obtido para ser utilizado.
Cdigos de terceiros geralmente so genricos, isto , tendem
a abranger grande quantidade de necessidades, podendo ser
utilizado em muitos cenrios diferentes. Isso faz com que o
48
cdigo de terceiros muitas das vezes tenha mais funcionalidades do que normalmente se precisa quando se opta por
utiliz-lo.
Caso seja possvel refator-lo, isto , modific-lo a fim de
remover cdigos que no sero utilizados no instante em que
se deseja apenas uma funcionalidade, aconselhvel que o
faa, mas nem sempre se pode alterar tais cdigos.
Existem diversos tipos de cdigo de terceiros, dentre eles os
que so oferecidos em forma de componentes e classes, entre
outras formas.
Partindo do princpio de que no se pode alterar o cdigo de
terceiros que se est utilizando, ser definido um exemplo de
como utilizar o cdigo de terceiros sem expor mais funcionalidades do que o necessrio.
Considerando uma classe de uma biblioteca de classes que
disponibilizada juntamente com um ambiente de desenvolvimento Java ou .Net, pode-se ter vrios mtodos de diferentes
funes, das quais apenas algumas precisam ser utilizadas.
Como exemplo, considere o cdigo da Listagem 1.
Listagem 1. Cdigo da classe Aluno.
1. public class Aluno

2. {
3. ...
4. public ArrayList listaAlunos = new ArrayList();
5. ...
6. public void adicionarAlunoLista(Aluno aluno)
7. {
8.
listaAlunos.Add(aluno);
9. }
10.
11.
12.
13.
14.
15. }
public ArrayList recuperarListaAlunos()

{
return listaAlunos;
}
...
A Listagem 1 possui o cdigo da classe Aluno, que utiliza

cdigo de terceiros, isto , cdigo da biblioteca de classes do
.Net Framework, mais precisamente da classe ArrayList, que
fornece objetos que atuam como lista de dados. Ao disponibilizar essa classe, o .Net Framework disponibiliza tambm
uma srie de mtodos que permitem a manipulao dos objetos
da classe ArrayList. O cdigo da Listagem 1 utiliza apenas o
mtodo .Add e retorna uma lista com os alunos existentes.
A Listagem 2 mostra o cdigo cliente da classe Aluno.
No cdigo cliente da Listagem 2 possvel verificar que, para
adicionar um objeto aluno lista de alunos da classe Aluno,
invocado o mtodo adicionarAlunoLista, linha 2 da Listagem 2.
Para recuperar a lista de alunos invocado o mtodo recuperarListaAlunos, linha 4, tambm da Listagem 2.
No se deve permitir que outras operaes sejam realizadas com
a lista de alunos da classe Aluno da Listagem 1 alm das operaes
que so realizadas pelo cdigo cliente da Listagem 2. Tambm no
se deve permitir outra forma de acesso lista de alunos da classe
Aluno, como por exemplo, acessar seu mtodo .Add.
Engenharia de Software Magazine - Boas prticas para escrita de mtodos, funes e procedimentos Parte 6
Listagem 2. Cdigo cliente da classe Aluno.
1. ...
2. aluno.adicionarAlunoLista(aluno);
3. ...
4. ArrayList lista = aluno.recuperarListaAlunos();
5. ...
O cdigo, da forma como est escrito, permite que as operaes

que no podem ser realizadas aconteam, caso um desenvolvedor
escreva cdigo cliente de forma que as utilize. Nesse caso, estaria
violando o princpio estabelecido de que s se pode recuperar e
adicionar utilizando os mtodos definidos na Listagem 1. O fato
de um desenvolvedor poder burlar facilmente essa regra fere os
princpios de limite estabelecidos para o acesso a lista de alunos
da classe Aluno. Para que se respeitem os limites impostos, devese criar, portanto, uma estratgia que iniba a quebra da regra e
tambm que estabelea um limite para o acesso ao cdigo de
terceiros, isto , ao cdigo da classe ArrayList, do .Net Framework.
A estratgia definida a criao de uma interface para a classe
Aluno, com pode ser visto nas Listagens 3 e 4.
Listagem 3. Classe Aluno modificada.
1. public class Aluno: IAluno

2. {
3. private ArrayList listaAlunos = new ArrayList();
4.
5.
6.
7.
public void adicionarAlunoLista(Aluno aluno)

{
listaAlunos.Add(aluno);
}
8. public ArrayList recuperarListaAlunos()

9. {
10.
return listaAlunos;
11. }
12. }
Listagem 4. Interface da classe Aluno.
1. public interface IAluno

2. {
3. void adicionarAlunoLista(Aluno aluno);
4. ArrayList recuperarListaAlunos();
5. }
Na Listagem 4 est definida a interface com a classe Aluno,

isto , o novo meio de acesso classe Aluno, que o cdigo cliente passar a utilizar. Os mtodos da classe Aluno que podem
ser manipulados esto devidamente declarados na interface.
No entanto, para evitar que um desenvolvedor acesse outro
mtodo que manipula a lista de alunos da classe Aluno, foi
alterado o modificador de acesso da lista de alunos de pblico
para privado (linha 3, Listagem 3). A partir deste momento,
o acesso classe Aluno deve ser feito pela sua interface e no
mais diretamente aos mtodos da classe Aluno. Os limites
esto estabelecidos, uma vez que no mais possvel acessar
outros mtodos que manipulam a lista de alunos da classe
Aluno que no sejam os declarados na interface. O cdigo da

Listagem 5 mostra o cdigo cliente da classe Aluno depois
das modificaes geradas a partir da criao da interface da
classe Aluno.
Listagem 5. Cdigo cliente da interface de Aluno.
1. ...
2. alunoJose.adicionarAlunoLista(aluno);
3. ...
4. ArrayList lista = aluno.recuperarListaAlunos();
5. ...
Outro ponto importante sobre cdigo de terceiros gira em

torno do tempo que gasto para entender o que eles realmente
fazem. Cdigo limpo (MARTIN, 2009) sugere que, ao invs da
leitura da documentao sobre o que o cdigo a ser utilizado
pode proporcionar em termos de funcionalidades, melhor
criar casos de teste para testar se as funcionalidades que se
espera encontrar realmente existem no cdigo de terceiros e se
realmente funcionam como espera-se que funcione. Os testes
criados so chamados de testes de aprendizagem, pois permitem que ao testar o cdigo de terceiros, tambm seja obtido
certo conhecimento acerca do que o cdigo capaz de fazer.
Sendo assim, proporciona aprendizado sobre o cdigo a ser
utilizado, alm de se ter a certeza de que ele no contm erros,
uma vez que foi testado por quem vai us-lo tambm.
Outro benefcio da criao de casos de testes para cdigos de
terceiros gira em torno da disponibilizao de novas verses do
cdigo. Sempre que um terceiro lanar novas verses do cdigo,
ser possvel, atravs de um novo teste com os casos de testes
escritos para a verso antiga, saber se a verso nova ainda possui
as mesmas funcionalidades que a anterior, e se a nova verso vai
servir no lugar da verso antiga que est sendo utilizada em alguma aplicao. Caso os testes detectem que, por exemplo, uma
sada no mais formatada como na verso antiga, rapidamente
poder ser feita uma anlise acerca da utilizao ou no da nova
verso, analisando os prs e contras da adeso.
Concluindo limites
Como visto nos exemplos das listagens apresentadas at
o momento, possvel perceber que h pontos importantes
a se considerar quando se est lidando com limites que vo
at o ponto que se pode modificar, isto , limites que vo at
aonde comea o cdigo de terceiros. Controlar estes limites, e
fazer com que o cdigo de terceiros no prejudique o cdigo
da aplicao que o invoca, a tarefa do desenvolvedor. Como
geralmente cdigos de terceiros possuem vrios recursos,
muitas vezes mais do que necessrio para a finalidade que
se aplica, interessante que o desenvolvedor saiba preparar
sua aplicao para se relacionar bem com o cdigo de terceiros.
Isso deve ser feito atravs do estabelecimento de limites que
possuem cdigo que pode ser considerado limpo.
As mesmas regras que valem para a utilizao de uma simples
classe de uma biblioteca de classes valem para o relacionamento
com outras aplicaes. Estabelecer os limites entre o cdigo
49
desenvolvido e o cdigo de uma aplicao que se est integrando

essencial. Nesse sentido, importante saber que as aplicaes
que esto sendo integradas ao sistema podem possuir muitas
funcionalidades que podem no ser acessadas, ou as que sero
acessadas fornecem dados formatados diferentemente do esperado. Sabendo dessas particularidades, importante que o desenvolvedor implemente mecanismos que permitam a comunicao
de forma simples e limpa com a aplicao que se est integrando
e que tambm controle os limites entre as aplicaes.
Testes de unidade
Esta seo se faz necessria devido a um problema encontrado em casos de testes escritos para testes de unidade: cdigo
ilegvel. Manter um cdigo limpo inclui manter o cdigo dos
casos de testes limpos tambm. De certa forma, manter apenas o cdigo do sistema limpo no garantia de facilidade
de interpretao. O tempo gasto para entender e manter o
cdigo fonte de um sistema pode ser maior se o cuidado que
o desenvolvedor teve em mant-lo limpo no for o mesmo
como o cdigo utilizado para testes unitrios. Assim, escrever
casos de testes limpos o objetivo desta seo. Caso o leitor
no esteja familiarizado com testes unitrios utilizando NUnit,
recomendada a leitura do artigo sobre testes unitrios com
NUnit na prtica (ver Nota do DevMan 1).
Recomendaes para se obter bons casos de testes
A tarefa de definir cdigo de teste unitrio deve seguir algumas recomendaes, segundo (MARTIN, 2009). A primeira das
recomendaes gira em torno da velocidade com que um teste
executado. Um teste no deve ser lento para executar, isto , deve
ser escrito de tal forma que possa ser executado de forma rpida.
Caso um teste no execute de forma rpida, possivelmente ser
necessria a limpeza do cdigo de teste rapidamente.
A segunda recomendao revela que o acoplamento entre
cdigos de teste deve ser reduzido, de preferncia eliminado.
Um trecho de cdigo de teste no deve estar contido no corpo
de outro cdigo de teste. Cada mtodo de teste deve testar
um mtodo da aplicao, e no pode ser utilizado no todo ou
em partes para testar outros mtodos que no seja o que por
natureza foi definido para ser testado por ele.
A terceira recomendao acerca da portabilidade dos casos
de teste. Um teste deve poder ser executado sobre o projeto
desenvolvido, em qualquer lugar onde o projeto esteja, no
somente em um local especfico, como a mquina do desenvolvedor. importante se ter uma estratgia que permita que os
testes sejam executados em um sistema mesmo que o sistema
no esteja na mquina na qual foi concebido.
Outras duas recomendaes sobre como os casos de teste devem ser concebidos e mantidos giram em torno da capacidade
de validao de um caso de teste e sobre o momento ideal para
se definir um caso de teste.
Sobre a capacidade de validao de um caso de teste, deve-se
atentar para o tipo de sada que o teste fornece. A comparao
deve ser bem clara, bem como a sada que o teste fornece. Deve
ser possvel identificar rapidamente, caso o teste falhe, o motivo
50
da falha ao comparar as sadas. Caso o teste falho necessite de

uma anlise de sada mais profunda, pode ser sintoma de que
o mtodo de teste no foi to bem escrito como deveria.
J a ltima recomendao revela a importncia do momento
certo para se definir o caso de teste, que deve ser no mesmo
instante em que o cdigo de produo for concebido. Cdigo
Limpo (MARTIN, 2009) sugere que o mtodo de teste seja
escrito antes mesmo do mtodo a ser testado. Posteriormente,
deve-se atentar para que o mtodo da aplicao seja escrito de
forma simples, de forma que possa ser testado.
Limpando casos de teste
Considere a Listagem 6 de cdigo. Ela possui uma classe
chamada OperacoesMatematicas.
Listagem 6. Classe OperacoesMatematicas
1. public class OperacoesMatematicas

2. {
3. private String mensagem;
4. public void setMensagem(String texto)
5. {
6.
mensagem = texto;
7. }
8. public String obterMensagem()
9. {
10.
return mensagem;
11. }
12. public String dividirDoisNumeros(String primeiroValor, String segundoValor)
13. {
14.
try
15. {
16.
UInt32 numero1 = Convert.ToUInt32(primeiroValor);
17.
UInt32 numero2 = Convert.ToUInt32(segundoValor);
18.
UInt32 resultado = numero1 / numero2;
19.
mensagem = Resultado: + resultado;
20.
return mensagem;
21.
}
22.
catch (DivideByZeroException)
23.
{
24.
mensagem = Impossivel fazer diviso com 0;
25.
return mensagem;
26.
}
27.
catch (FormatException)
28.
{
29.
mensagem = No foi possivel a diviso. Entrada Invlida;
30.
return mensagem;
31.
}
32.
catch (OverflowException)
33.
{
34.
mensagem = No foi possivel a diviso com nmeros Negativos;
35.
return mensagem;
36.
}
37. }
38. }
OperacoesMatematicas possui um mtodo chamado dividirDoisNumeros. Esse mtodo simples, consiste em apenas
efetuar uma operao de diviso entre dois nmeros. Esse o
cenrio inicial para aplicao de um caso de teste, no qual posteriormente ser possvel ver a aplicao de algumas tcnicas
de cdigo limpo. O mtodo OperacoesMatematicas possui um
fluxo normal, caso os dados inseridos sejam corretos no sentido de permitir a diviso de forma natural, e outros fluxos de
exceo, que permitem que, caso alguma exceo seja levantada, a mesma seja capturada e envie uma mensagem ao usurio
sobre o ocorrido. Testes neste sentido devem ser capazes de
identificar se o mtodo funciona com o esperado.
A Listagem 7 possui uma classe chamada TOperacoesMatematicas, que possui os casos de teste escritos para testar o
mtodo dividirDoisNumeros da Listagem 6.
Na Listagem 7, linha 3, tem-se a instanciao de um objeto
da classe OperacoesMatematicas, classe que possui o mtodo
dividirDoisNumeros, mtodo que ser testado. A instanciao
desse objeto permitir a comunicao com a classe OperacoesMatematicas. A classe da Listagem 7 recebeu o mesmo nome
da classe da Listagem 6, a diferena est na primeira letra, T,
que ser utilizado para deixar claro que a classe uma classe
que possui cdigo de teste.
Na classe da Listagem 7 existem quatro mtodos de teste. O
primeiro deles, linhas 5 a 11, permite descobrir se o clculo de
diviso ser feito de forma correta. Para isso, espera-se que o
resultado seja 5, em relao ao resultado da diviso do numero
10 por 2 (linha 9). O segundo mtodo, linhas 13 a 26, permitir descobrir se ser levantada uma exceo, caso o segundo
nmero da diviso for zero. O mtodo de teste das linhas 28
a 41 permitir o teste do cenrio onde uma exceo ser lanada caso seja inserido algum valor que no um nmero. J
o ltimo caso de teste, linhas 43 a 56, permite descobrir se o
mtodo a ser testado realmente emite mensagem de tentativa
de diviso com nmeros negativos.
Todos os casos de teste escritos para o mtodo dividirDoisNumeros (Listagem 6) passam no teste, o que indica que o mtodo
escrito funciona como o esperado. Os casos de teste escritos
cumpriram seus objetivos. Muitas equipes de desenvolvimento
os descartariam neste momento, mas o melhor a fazer mantlos guardados para futuros testes neste mesmo mtodo.
Cdigo Limpo (MARTIN, 2009) sugere que os casos de teste
sejam mantidos, isto , sejam armazenados, mas que, alm
disso, tambm possam evoluir assim como o cdigo dos mtodos da aplicao. Essa evoluo diz respeito limpeza do
cdigo dos casos de teste. Deve-se atentar para que as tcnicas
de limpeza de cdigo sejam sempre aplicadas no s ao cdigo
da aplicao, mas tambm ao cdigo de teste.
Alm da aplicao das tcnicas de cdigo limpo, os casos de
teste tambm devem estar de acordo com as recomendaes
descritas nesta seo, em Recomendaes para se obter bons
casos de testes. Analisando os casos de teste apresentados na
Listagem 7, pode-se perceber que a primeira recomendao
se encaixa nestes testes. Os testes da Listagem 7 executam
rapidamente.
Sobre a segunda recomendao, pode ser visto que os
casos de teste executam de forma independente, isto , no
precisam do resultado um do outro para executar. A terceira
recomendao revela que os casos de teste devem permitir
a execuo em outros locais e no somente a mquina em
que foi concebido. Essa recomendao se aplica a esses casos
de teste, pois possvel rodar esses testes em outro local.
Listagem 7. Cdigo da classe TOperacoesMatematicas.
1. public class TOperacoesMatematicas

2. {
3. private OperacoesMatematicas operacao = new OperacoesMatematicas();
4. [Test]
5. public void test1()
6. {
7.
UInt32 n1 = 10;
8.
UInt32 n2 = 2;
9.
UInt32 result = n1 / n2;
10.
Assert.AreEqual(5, result);
11. }
12. [Test]
13. public void test2()
14. {
15.
try
16.
{
17.
UInt32 n1 = 10;
18.
UInt32 n2 = 0;
19.
20.
}
21.
22.
{
23.
operacao.setMensagem( Impossivel fazer diviso com 0);
24.
}
25.
Assert.AreEqual( Impossivel fazer diviso com 0, operacao.
obterMensagem());
26.
}
27.
[Test]
28.
public void test3()
29.
{
30.
try
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57. }
UInt32 n1 = Convert.ToUInt32(sdsd);
UInt32 n2 = 2;
}
{
operacao.setMensagem( No foi possivel a diviso. Entrada
Invlida);
}
Assert.AreEqual( No foi possivel a diviso. Entrada Invlida,
operacao.obterMensagem());
}
[Test]
public void test4()
{
try
{
UInt32 n1 = Convert.ToUInt32(-10);
UInt32 n2 = 2;
}
{
operacao.setMensagem( No foi possivel a diviso com
nmeros Negativos);
}
Assert.AreEqual( No foi possivel a diviso com nmeros
Negativos, operacao.obterMensagem());
}
51
Basta levar o projeto para ser executado em outra mquina.

Ela deve apenas possuir a instalao do NUnit.
A recomendao de nmero quatro mostra que os casos
de teste devem ser facilmente verificados, no que se refere
s sadas por eles produzidas. As sadas produzidas pelos
mtodos das linhas 13 a 56 mostram que, caso um teste falhe,
possvel identificar facilmente o motivo, pois os retornos
mostraro duas mensagens, em cada mtodo de teste, sendo
uma mensagem esperada e outra mensagem encontrada.
Caso sejam diferentes, possvel identificar a diferena no
mesmo instante. O mtodo de teste das linhas 5 a 11 mostrar,
em caso de falha, dois nmeros, um nmero esperado e o
outro encontrado, o que permite facilmente a comparao. A
ultima recomendao acerca do momento em que o caso de
teste foi definido, no caso da Listagem 7, definido no mesmo
instante em que o mtodo dividirDoisNumeros, Listagem 6,
foi definido.
Os casos de teste da Listagem 7 foram definidos de acordo
com as recomendaes desta seo. Resta neste instante verificar se eles foram implementados seguindo os princpios
de cdigo limpo, que diz respeito aplicao das tcnicas de
limpeza de cdigo.
Em primeira anlise, possvel perceber que os casos de
teste da Listagem 7 no possuem nomes significativos, o que
dificulta o entendimento, apensar de serem simples, sobre o
funcionamento do caso de teste. Nesse sentido, os casos de
teste evidenciam a necessidade de uma evoluo, ou seja,
aplicao de tcnicas de cdigo limpo referente mudana
para nomes significativos. A Listagem 8 mostra o resultado
destas mudanas.
A utilizao de nomes significativos permitiu que os casos
de testes se tornassem mais condizentes com seus propsitos.
Os casos de teste da Listagem 7 apresentavam nomes que
permitiam apenas saber, em primeira anlise, que se referiam
a um conjunto de quatro mtodos de teste, mas seus nomes
no demonstravam a relao existente com o mtodo dividirDoisNumeros, da classe OperacoesMatematicas.
A partir das modificaes da Listagem 8, possvel perceber
facilmente que os quatro casos de teste existentes referem-se
ao mtodo dividirDoisNumeros. Cada um dos casos de teste
refere-se a uma parte do mtodo que est sendo testada. O
nome testarDividirDoisNumeros, juntamente com o nmero
do caso de teste, no caso de um a quatro, permite visualizar
que existem quatro diferentes testes para o mtodo dividirDoisNumeros. Alm da mudana do nome dos casos de teste,
foram alterados os nomes das variveis de todos os mtodos
de teste. Os antigos nomes no revelavam a real inteno das
variveis. Com estas mudanas, os casos de testes agora refletem melhor seus propsitos.
Os casos de teste da Listagem 8 executam perfeitamente
sobre os mtodos que testam. A Figura 1 mostra os casos de
teste ao serem executados.
Os casos de teste possuem nomes significativos, mas ainda
possuem outros problemas. Se analisados, os casos de teste
mostram uma grande quantidade de cdigo similar entre os
52
Listagem 8. Cdigo da Listagem 7 modificado.

2. {
4. [Test]
5. public void testarDividirDoisNumeros1()
6. {
7.
UInt32 numero1 = 10;
8.
UInt32 numero2 = 2;
9.
10.
Assert.AreEqual(5, resultado);
11. }
12. [Test]
14. {
15.
try
16.
{
17.
UInt32 numero1 = 10;
18.
UInt32 numero2 = 0;
19.
20.
}
21.
22.
{
23.
operacao.setMensagem( Impossivel fazer diviso com 0);
24.
}
25.
Assert.AreEqual( Impossivel fazer diviso com 0, operacao.
obterMensagem());
26. }
27. [Test]
29. {
30.
try
31.
{
32.
UInt32 numero1 = Convert.ToUInt32(sdsd);
33.
UInt32 numero2 = 2;
34.
35.
}
36.
37.
{
38.
operacao.setMensagem( No foi possivel a diviso.
Entrada Invlida);
39.
}
40.
operacao.obterMensagem());
41. }
42. [Test]
44. {
45.
try
46.
{
47.
UInt32 numero1 = Convert.ToUInt32(-10);
48.
UInt32 numero2 = 2;
49.
50.
}
51.
52.
{
53.
operacao.setMensagem( No foi possivel a diviso com
nmeros Negativos);
54.
}
55.
Negativos, operacao.obterMensagem());
56. }
57. }
casos de teste, como pode ser visto nas linhas 7 a 9, 17 a 19, 32 a

34 e 47 a 49 (Listagem 8), alm de outros trechos de cdigo que
no deveriam estar no corpo do mtodo. Sendo assim, torna-se
necessria a modificao dos casos de teste para eliminar o
cdigo duplicado. O objetivo da remoo do cdigo duplicado
tambm eliminar cdigo que foi copiado do mtodo a ser
testado. A Listagem 9 apresenta os casos de teste da Listagem 8
depois da remoo da duplicao.
passados os valores, em strings sdsd e 0 e, por ltimo, o quarto

mtodo, que realiza os testes com os valores -10 e 2, em forma
de strings, como pode ser visto na linha 26.
Os mtodos de teste foram alterados e, portanto devem ser testados novamente, para certificar que as mudanas ocorridas nos
mtodos no afetaram seus funcionamentos. O resultado dos
testes pode ser visto na Figura 2, que deixa claro que os testes
foram executados com sucesso, o que indica que a remoo de
cdigo duplicado e fora de contexto ocorreu como planejado.
Figura 1. Casos de teste sendo executados
Listagem 9. Cdigo da Listagem 8 modificado.
Concluso
A srie sobre Cdigo Limpo vem cumprindo seu objetivo
que o de prover conhecimento sobre como melhorar a qualidade de cdigo das aplicaes. A cada novo artigo, diferentes
sees vm sendo apresentadas, cada uma com um propsito
especfico, mas todas contribuindo para a obteno de cdigo
considerado limpo.
Neste artigo foram apresentadas as sees Limites e Teste de
Unidade. A seo Limites contribui para a melhoria do cdigo
que estabelece os limites existentes entre a aplicao e o cdigo
de terceiros, e a seo Teste de Unidade destaca a importncia
de manter guardados os casos de teste escritos, mas mais importante do que isto, mant-los sempre limpos, fazendo com que a
qualidade do cdigo de teste evolua sempre juntamente com a
qualidade do cdigo da aplicao que ele testa.
Referncia

D
s
MARTIN, Robert C, 2009. Cdigo Limpo: Habilidades Prticas do Agile Software, 1ed. Rio de
Janeiro: Alta Books, 2009.
Feedback
eu
53
sobre e
s
Os mtodos de teste da Listagem 9, em relao aos mesmos

mtodos da Listagem 8, possuem diferenas significativas. A
primeira delas a remoo de cdigo duplicado. A segunda
refere-se ao fato de que as alteraes que os mtodos de teste
sofreram melhoraram a qualidade do cdigo de teste ao fazer
chamada ao mtodo a ser testado ao invs de carregar o cdigo
semelhante ao do mtodo testado.
Em detalhes, as mudanas ocorridas nos mtodos da Listagem 9
fazem o mtodo das linhas 4 a 9 receber o resultado do mtodo
que est sendo testado, ao passar para ele duas strings com
valores 10 e 2. O resultado recebido comparado ao resultado
esperado, como pode ser visto na linha 8. O mesmo ocorre com
os demais mtodos. No segundo mtodo, so testados os valores,
passados como strings 10 e 2 (linha 13). No terceiro mtodo so
Figura 2. Mtodos de teste executados com sucesso
edio
ta

2. {
4. [Test]
6. {
7.
String resultado = operacao.dividirDoisNumeros(10, 2);
8.
Assert.AreEqual( Resultado: 5, resultado);
9. }
10. [Test]
12. {
13.
String resultado = operacao.dividirDoisNumeros(10, 0);
14.
Assert.AreEqual( Impossivel fazer diviso com 0, resultado);
15. }
16. [Test]
18. {
19.
String resultado = operacao.dividirDoisNumeros(sdsd, 0);
20.
resultado);
21. }
22. [Test]
24. {
25.
String resultado = operacao.dividirDoisNumeros(-10, 2);
26.
Negativos, resultado);
27. }
28. }
Assista ao vdeo e descubra mais

sobre a Campus Party Brasil
54

Idioma

Pontos Por Função

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Pontos Por Função

Enviado por

Direitos autorais:

Formatos disponíveis

magazine

Aprimore suas estimativas de tamanho de projeto

Modelos de processo pessoal

Rodrigo Oliveira Spnola

Marco Antnio Pereira Arajo

Ano 4 - 44 Edio - 2012

Eduardo Oliveira Spnola

Fale com o Editor!

a fase inicial de um projeto, a necessidade em obter o custo, prazo e o

Neste contexto, esta edio da Engenharia de Software Magazine destaca

esforo observado em todas as empresas, pois as mesmas precisam

gerar um oramento para os seus clientes e avaliar uma srie de

cujo objetivo apresentar de forma simples, por meio de exemplos, o uso de

um mtodo poderoso para a soluo destes problemas recorrentes, a APF

Alm deste artigo, teremos mais sete nesta edio:

de extrao de requisitos para realizar um levantamento inicial dos mesmos e

Requisitos para agilidade no desenvolvimento de software

compreender melhor o problema. Os requisitos so condies, caractersticas

Scrum e o gerenciamento de projetos Parte 3

ou capacidades necessrias para atingir uma finalidade, categorizados na

Modelos de processo pessoal

implementao de sistemas em funcionais e no funcionais como forma de

CMMI Uma viso Geral

estabelecer critrios de qualidade.

Gerenciando mudanas a partir de requisitos

Uma vez definidos os requisitos, pode-se ento avaliar o tamanho do sistema

Introduo ao desenvolvimento de aplicaes de realidade aumentada

Equipe Editorial Engenharia de Software Magazine

13 - Scrum e o gerenciamento de projetos Parte 3

36 - Gerenciando mudanas a partir de requisitos

47 - Boas prticas para escrita de mtodos, funes e procedimentos Parte 6

Edio 05 - Engenharia de Software Magazine

Requisitos para agilidade no

De que se trata o artigo?

individuais, com a adoo de alguns mtodos como

Em que situao o tema til?

Especialista em Engenharia e Arquitetura

Engenharia de Software Magazine - Requisitos para agilidade no desenvolvimento de software

TI, vm disponibilizando diversas metodologias para apoiar essa difcil tarefa de

como um dos principais itens do desenvolvimento de software

suporte aos processos, como distribuir a responsabilidade

Requisitos geis para a equipe

Funes e responsabilidades da equipe

Edio 44 - Engenharia de Software Magazine

equipe que consiste principalmente de desenvolvedores e

Composio da equipe gil

na equipe e se torna a metodologia do time, as regras so

O modelo de trabalho aplicvel aos desenvolvedores pode ser

O responsvel gil geralmente o papel do lder do projeto.

No podemos deixar de ressaltar a importncia de recursos

Engenharia de Software Magazine - Requisitos para agilidade no desenvolvimento de software

necessrio estabelecer um trabalho colaborativo com especialista

Requisitos geis para o programa

desenvolver e testar o software. Neste nvel as equipes so

Equipes recursos e equipes componentes

Edio 44 - Engenharia de Software Magazine

das necessidades da equipe de recursos. No caso do Scrum, o

Qual o melhor cenrio?

A proposta da equipe de recursos seria, em vez de ter equipes

Embora no exista uma regra para auxiliar a tomada de

O especialista em projetos geis, Mike Cohn, publicou um

Figura 3. Combinando membros da equipe de componentes para fazer a

Engenharia de Software Magazine - Requisitos para agilidade no desenvolvimento de software