Engenharia de Software - Edição 10

Conhecimento
faz diferena!
Capa ESM - Final .pdf
19.02.08
18:15:13
magazine
Engenharia de Software
Saiba seu significado e para que serve

Edio Especial
Entenda os principais conceitos sobre

Testes e Inspeo de Software
Verificao, Validao & Teste
Ferramentas Open Source e melhores
prticas na gesto de defeitos
Requisitos
Conhea os principais conceitos envolvidos

na Engenharia de Requisitos
Especial
Projeto
Entenda o conceito de Arquitetura de Software e

como trabalhar com os Estilos Arquiteturais
Processos
Melhore seus processos atravs da

anlise de risco e conformidade
Veja como integrar conceitos de

Modelos Tradicionais e geis
Veja como integrar o Processo

Unificado ao desenvolvimento Web
Mais de 60 mil downloads

na primeira edio!
Faa j sua assinatura digital! | www.devmedia.com.br/es

Faa um up grade em sua carreira.
Em um mercado cada vez mais focado em qualidade ter conhecimentos aprofundados sobre requisitos, metodologia, anlises,
testes, entre outros, pode ser a diferena entre conquistar ou no uma boa posio profissional. Sabendo disso a DevMedia
lana para os desenvolvedores brasileiros sua primeira revista digital totalmente especializada em Engenharia de Software.
Todos os meses voc ir encontrar artigos sobre Metodologias Ageis; Metodologias tradicionais (document driven);
ALM (application lifecycle management); SOA (aplicaes orientadas a servicos); Analise de sistemas; modelagem; Mtricas;
orientao objetos; UML; testes e muito mais. Assine j!
EDITORIAL
Ano 1 - 10 Edio - 2009
Impresso no Brasil
Corpo Editorial
Colaboradores
Rodrigo Oliveira Spnola
rodrigo@sqlmagazine.com.br
Marco Antnio Pereira Arajo
Eduardo Oliveira Spnola
Diagramao
Romulo Araujo - romulo@devmedia.com.br
Capa
Antonio Xavier - antonioxavier@devmedia.com.br
Na Web
www.devmedia.com.br/esmag
Apoio
Parceiro
Nos ltimos anos, os mtodos geis de desenvolvimento de software ganharam importncia em diversos segmentos da indstria
de software. Assim como os mtodos tradicionais, os mtodos geis
tm por objetivo construir sistemas de alta qualidade que atendam
s necessidades dos usurios. A principal diferena est nos princpios utilizados para atingir tal objetivo.
Os mtodos geis apresentam uma abordagem bastante pragmtica para o desenvolvimento de software. Planos detalhados so
feitos apenas para a fase atual do projeto. Para fases futuras, os planos so considerados apenas rascunhos que podem se adaptar a
mudanas conforme o time aprende e passa a conhecer melhor o
sistema e as tecnologias utilizadas.
Neste contexto, a Engenharia de Software Magazine destaca nesta
edio uma matria que apresenta algumas evidncias que motivaram o surgimento dos mtodos geis, explicando seus valores e
princpios, com nfase na Programao Extrema, um dos mtodos
geis que mais recebeu ateno nos ltimos anos.
Alm desta matria, esta edio traz mais seis artigos:
UML Casos de Uso: Entendendo os casos de uso na prtica um
estudo de caso Parte I;
Documento de Requisitos: Essencial ao Desenvolvimento de Software;
Gerncia de Reutilizao de Software;
Melhorando a Qualidade do Software e Otimizando Recursos com
Teste baseado em Riscos;
Programao Orientada a Aspectos;
Engenharia de Software: Graduao (bacharelado) em Engenharia
de Software.
Desejamos uma tima leitura!
Equipe Editorial Engenharia de Software Magazine
Atendimento ao Leitor
A DevMedia conta com um departamento exclusivo para o atendimento ao leitor.
Se voc tiver algum problema no recebimento do seu exemplar ou precisar de
algum esclarecimento sobre assinaturas, exemplares anteriores, endereo de
bancas de jornal, entre outros, entre em contato com:
Carmelita Mulin Atendimento ao Leitor
www.devmedia.com.br/central/default.asp
(21) 2215-0033
Kaline Dolabella
Gerente de Marketing e Atendimento
kalined@terra.com.br
Rodrigo Oliveira Spnola

rodrigo@sqlmagazine.com.br
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.
(21) 2215-0033
Publicidade
Para informaes sobre veiculao de anncio na revista ou no site entre em
contato com:
Kaline Dolabella
publicidade@devmedia.com.br
Fale com o Editor!

muito importante para a equipe saber o que voc est achando da revista: que tipo de artigo
voc gostaria de ler, que artigo voc mais gostou e qual artigo voc menos gostou. Fique a

maraujo@devmedia.com.br
Doutorando 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 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. colaborador da
Engenharia de Software Magazine.
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:
Rodrigo Oliveira Spnola - Colaborador
editor@sqlmagazine.com.br
Eduardo Oliveira Spnola

(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).
Caro Leitor
Para esta edio, temos um conjunto de 6 vdeo aulas. Estas vdeo aulas esto disponveis para
download no Portal da Engenharia de Software Magazine e certamente traro uma significativa contribuio para seu aprendizado. A lista de aulas publicadas pode ser vista abaixo:
Tipo: Desenvolvimento
Ttulo: Programao Orientada a Aspectos
Autor: Marco Antnio Pereira Arajo
Mini-Resumo: A Programao Orientada a Aspectos (POA) surge como uma proposta para a
construo de sistemas complexos atravs da separao de interesses, como aqueles que no
se aplicam lgica de negcios como, por exemplo, segurana, desempenho, persistncia,
integridade de dados e tratamento de erros, dentre outros. Assim, a POA prega a diviso
de um sistema em partes para uma melhor compreenso das fronteiras que definem suas
funes, onde toda parte relacionada a um interesse transportada para uma localizao
fsica separada das demais, de forma a permitir maior reusabilidade e manutenibilidade do
software. Nesta vdeo aula conheceremos alguns dos principais conceitos deste paradigma
de programao.
Tipo: Desenvolvimento
Ttulo: Desempenho em Bancos de Dados como Elemento para Melhoria das Aplicaes
Mini-Resumo: Ao trabalhar com consultas em bancos de dados, deve-se ter uma ateno maior
com relao ao seu desempenho, uma vez que consultas mal elaboradas podem degradar consideravelmente o desempenho do sistema como um todo. Para que seja possvel fazer melhorias
relativas s consultas, preciso entender como analisar seu desempenho, bem como os fatores
que contribuem para sua melhoria. Este ser o foco desta aula.
Tipo: Projeto
Ttulo: Desenvolvimento Baseado em Componentes
Mini-Resumo:Desenvolvimento Baseado em Componentes (DBC) aparece como
uma tcnica que consiste no desenvolvimento de aplicaes a partir de componentes
interoperveis, reduzindo, assim, a complexidade e o custo do desenvolvimento, e melhorando a qualidade do produto de software. Proporciona ainda o desenvolvimento de
aplicaes com mais agilidade, atravs do reuso de componentes pr-existentes e com
maior grau de confiabilidade. Nesta vdeo aulas sero apresentados alguns conceitos
desta abordagem.
Tipo: Projeto
Ttulo: Introduo Construo de Diagrama de Classes da UML Parte 18
Autor: Rodrigo Oliveira Spnola
Mini-Resumo: Esta vdeo aula d continuidade ao estudo de caso de um sistema de gesto de
festas. Neste estudo de caso, partiremos dos requisitos funcionais do software. A partir deles, ser
elaborado o diagrama de casos de uso do sistema. Com o diagrama de casos de uso elaborado,
sero especificados trs casos de uso. Por ltimo, ser elaborado o diagrama de classes com base
nos requisitos funcionais e casos de uso especificados.Nesta aula,o foco o incio da elaborao do
diagrama de classes.Para isto,faremos uso da heurstica apresentada neste treinamento.Em particular, identificaremos as classes e atributos candidatos a partir da lista de requisitos funcionais.
Tipo: Projeto
Mini-Resumo: Esta vdeo aula d continuidade ao estudo de caso de um sistema de
gesto de festas. Neste estudo de caso, partiremos dos requisitos funcionais do software.
A partir deles, ser elaborado o diagrama de casos de uso do sistema. Com o diagrama de
casos de uso elaborado, sero especificados trs casos de uso. Por ltimo, ser elaborado
o diagrama de classes com base nos requisitos funcionais e casos de uso especificados.
Nesta aula, o foco o incio da elaborao do diagrama de classes. Para isto, faremos uso
da heurstica apresentada neste treinamento. Em particular, identificaremos as classes e
atributos candidatos a partir dos casos de uso especificados.
Tipo: Projeto
Mini-Resumo: Esta vdeo aula d continuidade ao estudo de caso de um sistema de gesto de
festas.Neste estudo de caso,partiremos dos requisitos funcionais do software.A partir deles,ser
elaborado o diagrama de casos de uso do sistema. Com o diagrama de casos de uso elaborado,
sero especificados trs casos de uso.Por ltimo, ser elaborado o diagrama de classes com base
nos requisitos funcionais e casos de uso especificados. Nesta aula, finalizamos a identificao
das classes e atributos, indicando quais atributos pertencem a cada classe.
NDICE
06- Introduo Programao Extrema (XP)
Danilo Sato
18 - UML Casos de Uso - Entendendo os casos de uso na prtica um estudo de caso Parte I
Ana Cristina Melo
24 - Documento de Requisitos - Essencial ao Desenvolvimento de Software

Antnio Mendes da Silva Filho
30 - Gerncia de Reutilizao de Software

Josiane Brietzke Porto e Isabel Albertuni
36 - Melhorando a Qualidade do Software e Otimizando Recursos com Teste baseado em Riscos

Ellen Souza e Cristine Gusmo
48 - Programao Orientada a Aspectos

Thamine Chaves Leite de Abreu, Leonardo da Silva Mota e Marco Antnio Pereira Arajo
56 - Engenharia de Software - Graduao (bacharelado) em Engenharia de Software

Fbio Nogueira de Lucena, Auri Marcelo Rizzi Vincenzi, Juliano Lopes de Oliveira e Plnio de S Leito Jnior
Engenharia de Software Magaz ine
Introduo Programao Extrema (XP)

De que se trata o artigo?
Danilo Sato
danilo@dtsato.com / www.dtsato.com
Danilo Sato Desenvolvedor, Coach e Consultor da ThoughtWorks UK. Com formao

e mestrado em Cincia da Computao pelo
IME/USP no tema Mtodos geis, tambm
fundador do Dojo@SP e membro da AgilCoop. Danilo j ministrou cursos sobre diversos
assuntos relacionados a Mtodos geis e
palestrou em diversas conferencias, incluindo:
XP 2007 (Itlia), Agile 2008 (Canad), Agiles
2008 (Argentina) e Falando em Agile (Brasil).
os ltimos anos, os mtodos

geis de desenvolvimento de
software ganharam importncia em diversos segmentos da indstria
de software. Assim como os mtodos
tradicionais, os mtodos geis tm
por objetivo construir sistemas de alta
qualidade que atendam s necessidades
dos usurios. A principal diferena est
nos princpios utilizados para atingir
tal objetivo.
Os mtodos geis apresentam uma
abordagem bastante pragmtica para o
desenvolvimento de software. Planos detalhados so feitos apenas para a fase atual do projeto. Para fases futuras, os planos
so considerados apenas rascunhos que
podem se adaptar a mudanas conforme
o time aprende e passa a conhecer melhor
o sistema e as tecnologias utilizadas.
Neste artigo so apresentadas algumas
evidncias que motivaram o surgimento
dos mtodos geis, explicando seus valores e princpios, com nfase na Programao Extrema, um dos mtodos geis que
mais recebeu ateno nos ltimos anos.
Engenharia de Software Magazine - Introduo Programao Extrema (XP)
Neste artigo so apresentadas algumas

evidncias que motivaram o surgimento
dos mtodos geis, explicando seus valores
e princpios, com nfase na Programao
Extrema, um dos mtodos geis que mais
recebeu ateno nos ltimos anos.
Para que serve?

Para gerentes, tomadores de deciso e
membros de uma equipe de desenvolvimento de software, este artigo apresenta
uma introduo detalhada sobre mtodos
geis de desenvolvimento de software,
mostrando as evidncias que levaram ao
seu surgimento e abordando de forma ampla alguns dos mtodos geis mais conhecidos, focando principalmente na Programao Extrema (XP).
Em que situao o tema til?

Para quem j ouviu falar mas ainda no se
aprofundou nos assuntos relacionados a
mtodos geis, Scrum, Lean ou XP. O artigo
aborda uma ampla gama de assuntos, como:
evidncias, origens, metodologias, valores,
princpios, prticas e formas de adoo.
M etodologias geis
Evidncias
No desenvolvimento de software, comum que os requisitos mudem enquanto a implementao ainda est
acontecendo. Kajko-Mattson et al. mostram que cerca de
40% a 90% do custo durante o ciclo de vida de um projeto
gasto na fase de manuteno [1]. Muitas empresas e times
de desenvolvimento acham que mudanas so indesejveis,
pois acabam com todo o esforo gasto no planejamento.
No entanto, os requisitos geralmente mudam conforme o
cliente v o sistema sendo implantado e em funcionamento. muito difcil criar um plano no incio do projeto que
consiga prever todas as mudanas sem gastar muito esforo,
tempo e dinheiro.
Boehm chegou a afirmar que encontrar e arrumar um
defeito no software aps a entrega custa cerca de 100 vezes
mais do que encontr-lo e arrum-lo nas fases iniciais de
design [2]. Essa foi uma das principais justificativas para
os mtodos tradicionais gastarem mais tempo nas fases de
anlise de requisitos e design, apesar do prprio Boehm ter
sugerido o desenvolvimento iterativo ao invs da produo
do produto completo de uma vez [3]. Em 2001, num artigo
de Boehm e Basili, houve uma reduo no pessimismo ao
perceber que, para sistemas pequenos, o fator era mais prximo de 5:1 ao invs de 100:1 e que, mesmo para sistemas
grandes, boas prticas arquiteturais poderiam reduzir de
forma significativa o custo da mudana, encapsulando as
reas de mudana em partes pequenas e fatoradas [4].
Poppendieck [5] sugere que a principal razo das mudanas
no desenvolvimento de software que o processo de negcio ao qual o software est atrelado evolui constantemente.
Construir flexibilidade para acomodar mudanas arbitrrias
muito caro e pode ser um desperdcio. Segundo Johnson
[6], 45% das funcionalidades implementadas num sistema
tpico no so utilizadas nunca e 19% so raramente utilizadas. A melhor estratgia evitar generalizaes desnecessrias e fazer com que o sistema seja flexvel apenas nas
reas mais propcias mudana [7].
A maioria dos estudos de caso na indstria apontam para
uma taxa relativamente alta de fracassos nos projetos de
software [8]. No clssico relatrio do Standish Group de
1994, o CHAOS Report [9], 37% dos fatores relacionados aos
projetos em dificuldade estavam relacionados aos requisitos. O mesmo relatrio de 2003 aponta que apenas 52% das
funcionalidades so entregues em um projeto [10]. Outro
estudo de classificao de defeitos aponta os requisitos como
principal categoria de defeitos, com 41% [11]. Ns queremos
estabilizar os requisitos, mas eles no so estveis [12].
O Manifesto gil
Em fevereiro de 2001, um grupo formado por 17 desenvolvedores experientes, consultores e lderes da comunidade de
software se reuniu em Utah para discutir idias e procurar
uma alternativa aos processos dirigidos a documentao e
s prticas adotadas nas abordagens tradicionais da Engenharia de Software e gerncia de projetos. Dessa reunio
surgiu o Manifesto do Desenvolvimento gil de Software

[13], que destaca as diferenas com relao s abordagens
tradicionais e define seus valores:
Indivduos e interaes so mais importantes que processos e ferramentas;
Software funcionando mais importante que documentao completa e detalhada;
Colaborao com o cliente mais importante que negociao de contratos;
Adaptao a mudanas mais importante que seguir
um plano.
Apesar da importncia dos itens direita, os mtodos geis
do mais valor para os itens destacados esquerda. Alm
dos quatro valores bsicos, o manifesto gil tambm apresenta 12 princpios que auxiliam a difuso de suas idias:
A maior prioridade a satisfao do cliente por meio da
entrega rpida e contnua de software que traga valor;
Mudanas nos requisitos so aceitas, mesmo em estgios
avanados de desenvolvimento. Processos geis aceitam mudanas que traro vantagem competitiva para o cliente;
Software que funciona entregue freqentemente, em
perodos que variam de semanas a meses, quanto menor o
tempo entre uma entrega e outra melhor;
As pessoas relacionadas ao negcio e os desenvolvedores
devem trabalhar juntos no dia a dia do projeto;
Construa projetos formados por indivduos motivados,
fornecendo o ambiente e o suporte necessrio e confiando
que realizaro o trabalho;
O modo mais eficiente e eficaz de transmitir informaes
dentro e fora do time de desenvolvimento a Comunicao
face a face;
A principal medida de progresso software funcionando;
Processos geis promovem o desenvolvimento em um ritmo sustentvel. Os investidores, desenvolvedores e usurios
devem ser capazes de manter um ritmo constante;
Cuidar continuamente da excelncia tcnica e do bom
design ajuda a aprimorar a agilidade;
Simplicidade - a arte de maximizar a quantidade de trabalho no necessrio - essencial;
Os melhores requisitos, arquiteturas e design surgem de
equipes auto-gerenciadas;
Em intervalos regulares, o time reflete sobre como se
tornar mais eficiente, refinando e ajustando seu comportamento apropriadamente.
Essas caractersticas trazem dinamismo para o desenvolvimento, motivao para o time e informaes mais precisas
sobre a verdadeira situao do projeto para o cliente. Enquanto as abordagens tradicionais tm um enfoque mais
preditivo, os mtodos geis so adaptativos.
O manifesto gil apresenta uma nova filosofia para o
desenvolvimento de software. Sob seus valores e princpios aparecem diversas abordagens mais especficas, com
diferentes idias, comunidades e lderes. Cada comunidade
Edio 10 - Engenharia de Software Magazine
forma um grupo distinto, porm todas seguindo os mesmos

princpios. comum inclusive a troca de conhecimento e
prticas entre membros de diferentes comunidades, formando um eco-sistema em torno de diversos mtodos, detalhados a seguir com maior nfase na Programao Extrema.
Scrum
Desenvolvida nas dcadas de 80 e 90 por Ken Schwaber,
Jeff Sutherland, e Mike Beedle [14], o Scrum se concentra
mais nos aspectos gerenciais do desenvolvimento de software, propondo iteraes de duas semanas ou 30 dias
(chamados Sprints) com acompanhamento dirio por meio
das Reunies em P (ou stand-up meetings). Por dar menos
nfase aos aspectos tcnicos, geralmente combinada com
prticas propostas por XP e compatvel com certificaes
de qualidade como CMMI ou ISO 9001 [15].
Lean Software Development

Com base no Sistema de Produo da Toyota [16], o movimento Lean revolucionou a manufatura e, mais recentemente, o desenvolvimento de produtos e o gerenciamento
da cadeia de suprimentos (supply chain management).
Mary e Tom Poppendieck traaram os paralelos entre os
valores e prticas Lean com o desenvolvimento de software,
fornecendo sete princpios [5, 7]: Elimine Desperdcios,
Inclua a Qualidade no Processo, Crie Conhecimento,
Adie Comprometimentos, Entregue Rpido, Respeite
as Pessoas e Otimize o Todo.
Famlia Crystal
Alistair Cockburn prope uma famlia de mtodos por
acreditar que diferentes abordagens so necessrias para
equipes de tamanhos diferentes [17]. Apesar disso, todos os
mtodos dessa famlia compartilham propriedades como:
entrega freqente, Reflexo e Comunicao. Outra parte importante dos mtodos da famlia Crystal o que Cockburn
chama de habitabilidade (habitability): o mnimo de processo necessrio para que a equipe consiga ter sucesso.
Feature Driven Development (FDD)

Desenvolvida por Peter Coad e Jeff de Luca no final da dcada
de 90, a FDD define duas fases compostas por 5 processos bem
definidos e integrados: a fase de concepo e planejamento,
composta por desenvolver um modelo abrangente, construir
uma lista de funcionalidades e planejar por funcionalidade;
e a fase iterativa de construo, composta por detalhar por
funcionalidade e construir por funcionalidade [18]. Outra
caracterstica interessante da FDD a utilizao de modelos
UML em cores para representar classes com diferentes responsabilidades (chamados arqutipos) [19].
Adaptive Software Development

Proposto por Jim Highsmith, esse mtodo tenta explorar
a natureza adaptativa e a incerteza no desenvolvimento de
software [20]. Com base nas idias dos Sistemas Adaptativos
Complexos (relacionados Teoria do Caos) [21], ele prope trs fases no-lineares e possivelmente sobrepostas:
especulao (referindo-se ao paradoxo do planejamento),
colaborao e aprendizado. Por meio de iteraes curtas, a
equipe cria o conhecimento cometendo pequenas Falhas,
causadas por falsas premissas, e corrigindo-as aos poucos,
criando uma experincia mais rica e ampla.
Dynamic System Development Method (DSDM)

Desenvolvido inicialmente por um consrcio de empresas
britnicas em 1994, esse mtodo se baseou nas idias do
desenvolvimento rpido de aplicaes (Rapid Application
Development ou RAD [22]) e no desenvolvimento iterativo e
incremental [23]. O mtodo comea com duas fases iniciais:
um estudo de viabilidade que valida se o processo DSDM
apropriado para o projeto e um estudo de negcio, para entender as necessidades de negcio e definir uma arquitetura
e os requisitos iniciais. O processo prossegue com trs fases:
uma iterao para o modelo funcional define prottipos e
uma documentao de anlise inicial, uma iterao para o
design e construo do sistema, e uma ltima fase de implementao para entrega e implantao do produto. O DSDM
ainda define princpios que incluem: participao ativa do
usurio, entrega freqente, times com poder de deciso e
testes durante todo o ciclo de vida do produto.
Programao Extrema
A Programao Extrema (ou XP) foi um dos mtodos
geis que mais recebeu ateno na virada do sculo. Seu
objetivo a excelncia no desenvolvimento de software,
visando baixo custo, poucos defeitos, alta produtividade e
alto retorno de investimento. Na segunda edio do livro
Extreme Programming Explained [24], Kent Beck aprimora a definio de XP da primeira edio, enumerando suas
principais caractersticas:
XP um mtodo leve. O time s deve fazer o necessrio
para trazer valor para o cliente;
XP um mtodo que enfatiza o desenvolvimento de software. Apesar de ter implicaes em reas como marketing,
vendas ou operaes, XP no tenta resolver os problemas
diretamente ligados a elas;
XP funciona para times de qualquer tamanho. Apesar das
prticas de XP funcionarem melhor em times pequenos,
seus valores e princpios podem ser aplicados em qualquer
escala e XP se adapta a requisitos vagos ou em constante
mudana.
Histrico
As idias de XP originaram-se de conversas entre Kent
Beck e Ward Cunningham a partir de suas experincias
com desenvolvimento de software em Smalltalk. Juntos, eles
escreveram o primeiro artigo sobre cartes CRC [25] e sobre
a aplicao de padres no desenvolvimento de software [26].
Ward Cunningham foi o criador do Wiki [27] e foi no seu
Wiki que as primeiras discusses sobre XP aconteceram.
M etodologias geis
Muitas das caractersticas de XP, como Refatorao, Programao Pareada, adaptao mudana, Integrao Contnua,
desenvolvimento iterativo e nfase nos testes, so elementoschave presentes na cultura da comunidade Smalltalk desde
a dcada de 1980.
Em 1992, William Opdyke publicou sua tese de doutorado [28], contando como Kent e Ward obtinham ganhos em
produtividade usando tcnicas de refatorao. Mais tarde,
essas tcnicas seriam compiladas no livro de Martin Fowler
et al. sobre refatorao [29].
Kent Beck tambm publicou o primeiro artigo sobre testes
de unidade automatizados [30] quando desenvolveu o primeiro arcabouo para desenvolvimento de testes automatizados: o SUnit [31] para testes em Smalltalk e, mais tarde
juntamente com Erich Gamma, o JUnit [32, 33] para testes
em Java. Esse arcabouo foi portado para diversas linguagens, formando um conjunto de ferramentas que ficaram
conhecidas como famlia XUnit: JUnit (Java), CppUnit (C++),
CUnit (C), NUnit (.NET), pyUnit (Python), Test::Unit (Ruby),
dentre diversos outros [34].
Todas essas idias foram se fundindo na cabea de Kent
Beck quando, em 1996, ele foi chamado para ajudar no projeto C3, ou Chrysler Comprehensive Compensation System,
que ficou conhecido como o bero de XP. Nele, Kent Beck
utilizou pela primeira vez todas as prticas que vieram a
se tornar a Programao Extrema. Sua idia, que originou
o nome Programao Extrema, era juntar as boas prticas
de programao j conhecidas pela indstria e encar-las
como botes de volume que seriam aumentados ao valor
mximo, extremo. Se fazer reviso de cdigo era bom, fazer
Programao Pareada era reviso em tempo integral; se
fazer testes automatizados cedo era bom, escrev-los antes
do cdigo era melhor ainda.
Foi a partir dessa experincia que Kent Beck lanou, em
1999, a primeira edio do livro que difundiu XP, Extreme
Programming Explained: Embrace Change [35]. Esse livro
recebeu no mesmo ano o prmio JOLT de produtividade
da revista Software Development e, aps cinco anos de
experincia com a utilizao e consultoria de XP, Kent Beck
lanou, em parceria com a sua esposa, da rea de psicologia,
a segunda edio do livro que hoje uma das principais
referncias sobre o assunto [24].
Uma comunidade que compartilha os mesmos valores e

muitas das mesmas prticas.
Essa separao entre valores, princpios e prticas j estava
presente na primeira edio de XP, porm sua importncia
foi reforada na segunda edio. possvel ter uma viso
mais ampla do processo quando pensamos nessas trs
perspectivas.
As prticas so tcnicas utilizadas no dia-a-dia dos membros de uma equipe de XP. Elas so claras, objetivas e especficas. Prticas como Desenvolvimento Dirigido por Testes
(Test Driven Development ou TDD) [36] ou Refatorao
[29] fazem sentido somente no contexto da programao.
Em outro contexto as mesmas prticas no fariam sentido.
As prticas de XP so apresentadas nas Sees Prticas
e Comparao com as Prticas da Primeira Verso, que
compara as diferenas entre as abordagens na primeira e
na segunda edio.
Valores so critrios mais amplos e universais utilizados
para julgar uma determinada situao. possvel enxergar
o valor do Feedback em diversos contextos, desde a programao (atravs da Integrao Contnua, por exemplo) at a
Comunicao com o cliente (atravs do Ciclo Semanal e do
Ciclo Trimestral). XP uma disciplina de software baseada
em cinco valores, que sero discutidos na Seo Valores.
Os valores do razo s prticas, enquanto as prticas
evidenciam os valores. Para preencher o espao vazio entre
valores e prticas, Kent Beck apresenta os princpios de
XP. Os princpios so tcnicas intelectuais para auxiliar na
traduo de valores em prticas. Eles devem ser utilizados
quando as prticas propostas no se aplicam numa situao
especfica. Por exemplo, o princpio dos Passos Pequenos
demonstrado em diferentes prticas, como a Implantao
Diria ou o ritmo imposto pelo Desenvolvimento Dirigido
por Testes. Os princpios de XP so apresentados na Seo
Princpios.
Valores
A filosofia de trabalho proposta por XP est baseada em
5 valores que servem de base para a aplicao das prticas
e dos princpios:
Comunicao
Abordagem
Segundo Kent Beck [24], a Programao Extrema inclui:
Uma filosofia para o desenvolvimento de software baseada nos valores de Comunicao, Feedback, Simplicidade,
Coragem e Respeito;
Um conjunto de prticas comprovadamente teis para
melhorar o desenvolvimento de software. As prticas expressam os valores de XP;
Um conjunto complementar de princpios, tcnicas intelectuais que auxiliam a traduo dos valores em prticas, teis
quando as prticas existentes no resolvem seu problema
particular;
O primeiro valor do Manifesto gil prope que os indivduos e as interaes entre eles so importantes para o
desenvolvimento de software [13]. A Programao Extrema
expressa tal importncia no valor da comunicao. XP pressupe que a maioria dos problemas num projeto de software
ocorrem por dificuldade na Comunicao [12].
A comunicao evidenciada em muitas das prticas: uma
equipe de XP funciona como um time completo, trabalhando
numa rea de trabalho informativa na qual todos possam
sentar junto. A presena e o envolvimento real com o cliente
e a programao pareada tambm so prticas que fortalecem e facilitam a comunicao. Alm disso, as mtricas
para acompanhamento do projeto tambm so importantes

elementos de comunicao, auxiliando a equipe a melhorar
o processo de desenvolvimento e o cliente a entender o
andamento do projeto.
Simplicidade
O segundo valor de XP a simplicidade. Os membros de
uma equipe de XP esto freqentemente buscando a soluo
mais simples para resolver seus problemas atuais. Num contexto onde a adaptao a mudanas aceita [13] e encorajada,
XP promove a preocupao com o que mais simples para
resolver os problemas de hoje, evitando desperdcios com
solues genricas para problemas futuros.
Segundo Kent Beck, a simplicidade o valor intelectual
mais intenso de XP [24]. Encontrar a soluo mais simples
no uma tarefa fcil. A Seo Prticas apresenta uma das
prticas que mais ajuda os desenvolvedores numa equipe
de XP a manter a nfase constante no design simples, o
desenvolvimento dirigido por testes [36].
Feedback
importante ter uma resposta rpida sobre as aes
realizadas para se adaptar s mudanas [13]. XP promove
ciclos curtos e constantes de feedback, nos mais variados
aspectos do desenvolvimento de software. Os valores de XP
se complementam, por isso o feedback parte importante
da comunicao e da simplicidade. Diante de uma dvida
entre trs diferentes solues, tentar todas parece ser um
desperdcio, porm esta pode ser a melhor forma de descobrir qual soluo mais simples e mais fcil de lidar.
Segundo Ambler [37], a maior contribuio para o sucesso
dos mtodos geis a reduo dos ciclos de feedback. As
prticas de XP evidenciam tal valor: a programao pareada
fornece feedback em segundos enquanto o desenvolvimento dirigido por testes fornece feedback em minutos. Alm
disso, o acompanhamento em projetos XP realizado diariamente pelo tracker e o uso de ferramentas para coleta e
anlise automatizada de mtricas pode fornecer feedback
ainda mais rapidamente.
Coragem
O quarto valor de XP a coragem. Kent Beck descreve a
coragem em XP como a ao tomada diante do medo [24].
Isso no significa que os membros da equipe devem ter coragem para fazer o que quiserem sem se preocupar com as
conseqncias para o time. A coragem como valor primrio,
sem a influncia e balanceamento dos outros valores, pode
ser perigosa. No entanto, em conjunto com os outros valores,
ela muito poderosa.
Teles [38] enumera alguns pontos onde a adoo de XP exige coragem da equipe para: desenvolver software de forma
incremental; manter a nfase constante na simplicidade;
permitir ao cliente priorizar funcionalidades; incentivar
os desenvolvedores a trabalhar em par; investir tempo em
refatorao; investir tempo em testes automatizados; estimar
10
as histrias na presena do cliente; compartilhar o cdigo com todos os membros da equipe; fazer a integrao
completa do sistema diversas vezes ao dia; adotar um
ritmo sustentvel; abrir mo da documentao; propor
contratos de escopo varivel e propor a adoo de um
processo novo.
Respeito
O quinto valor, enfatizado na segunda edio de XP,
serve de base para os outros quatro valores: respeito. Se
os membros da equipe no se importam com os outros ou
com os resultados, XP no vai funcionar [24]. importante
reconhecer que a excelncia no desenvolvimento de software depende das pessoas, e elas devem se respeitar para
conseguir extrair o mximo de seu potencial.
A falta de respeito pode influenciar negativamente alguns aspectos na adoo de XP: comunicao sem respeito
criar conflitos internos; coragem sem respeito trar atitudes que vo contra o bem estar da equipe; programao
pareada um exerccio contnuo de respeito; horas-extras
excessivas iro impactar o ritmo sustentvel da equipe; a
colaborao entre a equipe e o cliente tambm exige uma
comunicao aberta e respeitosa.
Princpios
Os princpios de XP funcionam como ferramentas para
traduo dos valores em prticas. Tanto documentos longos quanto conversas dirias tm a inteno de comunicar.
Descobrir qual a forma mais eficiente depende parte do
contexto e parte dos princpios intelectuais. Nesse caso, o
princpio da humanidade sugere que a conversa satisfaz
melhor as necessidades humanas de relacionamento. Os
princpios que guiam a Programao Extrema so:
Humanidade
Pessoas desenvolvem software. importante levar em
conta as necessidades bsicas do ser humano no desenvolvimento de software, criando oportunidades para:
crescimento, contribuio, participao e relacionamento.
O grande desafio balancear as necessidades pessoais com
as necessidades do time. As prticas de XP tentam atender
tanto s necessidades de negcio quanto s necessidades
pessoais dos membros da equipe.
Economia
Os envolvidos no desenvolvimento de software tambm
devem se preocupar com os aspectos econmicos para
evitar que o projeto seja apenas um sucesso tcnico.
importante que uma equipe de XP esteja constantemente
preocupada em agregar valor de negcio ao sistema que
esto desenvolvendo. Esse princpio um dos motivos
pelos quais os clientes so responsveis pela priorizao
das histrias nas reunies de planejamento. A equipe de
XP deve resolver os problemas mais importantes primeiro,
maximizando o valor do projeto.
M etodologias geis
Benefcio Mtuo
O princpio do benefcio mtuo um dos mais importantes
de XP, porm tambm um dos mais difceis de aplicar. Todas
as atividades devem trazer benefcio a todos os envolvidos.
Escrever documentos longos um exemplo de violao desse
princpio: o programador diminui seu ritmo de produo para
escrever um documento que no tem valor agora, podendo
apenas trazer valor no futuro para algum que ir dar manuteno no seu cdigo (se a documentao continuar vlida
at l). XP resolve o problema da comunicao com o futuro
de uma forma mutuamente benfica atravs de:
Testes automatizados que ajudam o programador no
design e na implementao das funcionalidades agora, servindo como documentao e como teste de regresso para
as pessoas que iro dar manuteno no futuro;
Refatorao constante para remover complexidade desnecessria, simplificar o design e remover defeitos, deixando
o cdigo mais limpo e fcil de entender para os futuros
mantenedores;
Nomes coerentes e baseados em metforas que facilitam o
entendimento do sistema, aumentando a velocidade atual do
desenvolvimento e da integrao de novos programadores
na equipe.
Auto-Semelhana
O princpio da auto-semelhana sugere a aplicao da estrutura de uma soluo em outros contextos, inclusive em
diferentes escalas. Um exemplo sugerido por Kent Beck [24] a
aplicao de testes a priori em ambos os nveis: no s quando
desenvolvendo os testes unitrios com TDD, mas tambm para
especificar os testes de aceitao com o cliente. Dessa forma,
fica mais claro para os programadores que as histrias s esto
prontas quando passam nos testes de aceitao, reduzindo o
ciclo de feedback e simplificando o andamento da iterao.
Melhoria
XP valoriza a busca constante pela melhoria. Ao invs de
buscar a perfeio, mais importante tentar fazer o melhor
trabalho possvel hoje, e estar consciente de tudo que ser
necessrio para melhorar amanh. O princpio da melhoria
valoriza as atividades que comeam agora e se refinam ao
longo do tempo.
Diversidade
Os times devem ser formados por uma variedade de habilidades, atitudes e perspectivas. Dessa diversidade podem
surgir conflitos que devem ser vistos como oportunidades
para discusso das diferentes perspectivas. Muitas vezes o
melhor design surge a partir de solues distintas. O princpio da diversidade se expressa em XP atravs da prtica
do time completo.
Reflexo
Uma boa equipe no deve apenas fazer o seu trabalho, mas
sim refletir constantemente sobre as razes e as formas como
esto trabalhando. Os times devem analisar seus sucessos

e suas falhas, sempre em busca da melhoria contnua. A reflexo vem aps a ao. O aprendizado surge para a equipe
como resultado da reflexo sobre a ao. Para maximizar o
feedback, as equipes de XP devem refletir e estar conscientes
de seus atos.
Fluxo
Esse princpio sugere a entrega de um fluxo contnuo de
software que agrega valor ao negcio, evitando pensar em
fases discretas. Quanto maior o tamanho de uma atividade
- iterao, release, histria ou tarefa - maior o tempo gasto
at descobrir se ela foi realizada com sucesso ou no, o que
aumenta o risco do erro. Quanto maior o erro, mais difcil
a correo. Para aumentar o feedback e diminuir os riscos, a equipe de XP deve prover incrementos pequenos de
funcionalidade, fazendo entregas pequenas e freqentes.
Prticas como integrao contnua, build em 10 minutos,
implantao incremental e implantao diria evidenciam
o princpio do fluxo.
Oportunidade
Equipes de XP enxergam problemas como oportunidades
para mudana. Na busca pela excelncia, os membros do
time devem demonstrar uma atitude positiva, identificando oportunidades para aprender, melhorar e desenvolver
software de qualidade.
Redundncia
O princpio da redundncia sugere que os problemas
difceis e crticos devem ser resolvidos de vrias maneiras
diferentes. Muitas das prticas de XP, como programao pareada, integrao contnua, envolvimento real com o cliente
e desenvolvimento dirigido por testes, so redundantes na
tentativa de reduzir a quantidade de defeitos e aumentar a
qualidade do software produzido.
Falha
Complementando o princpio da redundncia, o princpio da
falha sugere que todo erro um aprendizado. Na dvida entre
trs solues diferentes, tente implementar todas, mesmo que
algumas falhem. Diante de diferentes opes de design, ao
invs de perder tempo discutindo qual a melhor soluo, vale
mais a pena implement-las paralelamente, aprendendo com
os erros e chegando num consenso atravs da experincia.
Qualidade
Sacrificar a qualidade nunca um meio eficaz de controle.
Os projetos no andam mais rpido aceitando baixa qualidade. Cada incremento na qualidade tem reflexos de melhoria
em diversas outras reas do projeto, como produtividade,
eficincia e motivao. Um projeto XP no considera a
qualidade como uma das variveis de controle. O custo e
o tempo tambm so geralmente fixos, deixando o escopo
como principal varivel na negociao com o cliente [39].
11
Passos Pequenos
O princpio dos passos pequenos complementa o princpio
do fluxo, fazendo com que os membros da equipe de XP se
perguntem sempre Qual o mnimo que preciso fazer para
garantir que estou na direo certa?. Prticas como desenvolvimento dirigido por testes e integrao contnua evidenciam o valor do ritmo imposto pelos passos pequenos. A
refatorao outro exemplo da aplicao desse princpio.
Aceitao da Responsabilidade
A responsabilidade no deve ser imposta, deve ser aceita. As
prticas refletem esse princpio ao, por exemplo, sugerir que
a pessoa responsvel por uma Histria tambm responsvel
pela sua estimativa, design, implementao e teste.
Prticas
A abordagem de apresentao das prticas de XP foi totalmente refatorada na segunda edio por Kent Beck [24].
Ao invs de exigir a utilizao de todas as 12 prticas de
uma vez, Kent Beck sugere que cada time deve se adaptar
da maneira que achar mais apropriada. Ao invs de impor
as prticas, cada mudana deve comear pelos prprios
membros da equipe. Alm disso, as prticas na segunda
edio so 24, divididas entre prticas primrias e prticas
corolrias. Prticas primrias so aquelas que podem ser
aplicadas separadamente, trazendo melhoria imediata para a
equipe. Prticas corolrias so mais difceis de implementar,
mostrando sua eficincia somente aps domnio e experincia prvia com as prticas primrias.
Prticas Primrias
Sentar Junto: A equipe de XP deve trabalhar num espao
amplo e aberto, onde todos possam ficar juntos, fortalecendo
os elos da comunicao. prefervel trocar os tradicionais
cubculos por reas de uso comum onde os membros da
equipe possam se agrupar para discutir no quadro branco,
sentar juntos para trabalhar em par e espalhar grficos e
informaes na parede.
Time Completo: Equipes de XP devem ser multi-disciplinares, com todas as habilidades necessrias para o sucesso
do projeto. A equipe deve ser formada no apenas por desenvolvedores, mas tambm por analistas de teste, analistas
de negcio, clientes, especialistas em banco de dados, especialistas em interfaces grficas, administradores de rede, etc.
Todos devem trabalhar num esprito de contribuio para a
equipe, visando o bom andamento do projeto.
rea de Trabalho Informativa: Transforme o ambiente de
trabalho num reflexo do projeto. Um observador interessado deve ser capaz de ter uma idia da evoluo do projeto
apenas andando pela rea de trabalho. Alguns exemplos de
instrumentos para espalhar essas informaes, chamados
de radiadores de informao por Cockburn [40], so: cartes
com histrias num mural, quadros brancos, notas em papel
nas paredes e grficos como, por exemplo, o burn-down
chart proposto pelo Scrum [14, 41] para acompanhar a
12
velocidade da equipe. As mtricas tambm tm papel importante na comunicao e na rea de trabalho informativa
onde elas sero atualizadas pelo tracker e apresentadas
equipe e ao cliente.
Trabalho Energizado: O ritmo de trabalho no deve
afetar a vida pessoal dos membros da equipe. Durante o
planejamento, o nmero de horas dedicadas ao projeto
deve ser definido de forma realista. Fazer horas-extra deve
ser exceo e no a regra. Os membros da equipe de XP
devem trabalhar apenas enquanto puderem ser produtivos
e se manter energizados. O desenvolvimento de software
exige criatividade que raramente aparecer em momentos
de cansao ou indisposio [42].
Programao Pareada: Os desenvolvedores trabalham
em par para realizar suas tarefas. Isso promove o trabalho
coletivo e colaborativo, une a equipe e melhora a comunicao e a qualidade do cdigo. Os pares devem ser trocados
regularmente, inclusive vrias vezes por dia. Geralmente,
a seleo dos pares depende da tarefa a ser realizada, da
disponibilidade dos membros da equipe e da experincia
de cada um. O objetivo principal espalhar o conhecimento do sistema pela equipe inteira. Como importante efeito
colateral temos tambm o compartilhamento de tcnicas e
competncias entre os membros da equipe.
Histrias: O planejamento em XP feito com histrias
escritas em pequenos cartes. Cada carto escrito pelo
cliente e deve descrever uma unidade de funcionalidade, que
geralmente representa um requisito funcional desejado. Mike
Cohn prope o seguinte formato para uma histria [43]:

Como um <usurio/papel>
Eu gostaria de <funcionalidade>
Para que <valor de negcio>
Este formato interessante, pois evidencia o valor de negcio associado a cada funcionalidade. Para cada histria, os
desenvolvedores devem dar uma estimativa sobre o tempo
para implement-la e os clientes determinam a prioridade
de cada histria. Essas informaes so utilizadas no Jogo
do Planejamento, que acontece no incio dos Ciclos Semanais
e dos Ciclos Trimestrais. A descrio no carto no deve
armazenar todas as informaes sobre a histria. Os desenvolvedores de uma equipe de XP utilizam o dilogo como
principal meio de comunicao com o cliente para elucidar
dvidas sobre os detalhes da histria. Os cartes devem
servir apenas como um lembrete desse dilogo.
As estimativas das histrias num projeto em XP so geralmente medidas em pontos ou em horas ideais. Equipes
geis separam a estimativa do tamanho/complexidade de
uma histria do tempo que ela demora para ser implementada. Enquanto o tempo real gasto na implementao pode
variar, a complexidade da histria permanece a mesma.
Uma hora ideal considera que o desenvolvedor est trabalhando focado e sem interrupo durante uma hora, porm
M etodologias geis
o tempo real gasto vai ser geralmente maior. Portanto, so

uma medida do tamanho e da complexidade de uma histria
em relao a outras histrias do mesmo projeto. O sistema
de pontos baseia-se em uma escala numrica definida pela
equipe que permite a estimativa por comparao. Uma histria de 4 pontos tem mais ou menos o dobro do tamanho
de uma histria de 2 pontos. Algumas escalas comumente
utilizadas so escalas exponenciais (1, 2, 4, 8, 16, ...) ou uma
seqncia de Fibonacci (1, 2, 3, 5, 8, ...). Segundo Cohn,
essas escalas funcionam bem pois os valores mais altos
incluem maior incerteza, refletindo a natureza preditiva
das estimativas [43].
Ciclo Semanal: O software em XP produzido de forma
iterativa e incremental. Essa prtica sugere que uma equipe
de XP deve planejar o trabalho de cada iterao uma semana
por vez. A cada semana, os membros da equipe se renem
para: refletir sobre o progresso realizado at o momento,
planejar e priorizar as histrias da semana com o cliente e
quebrar cada histria em tarefas que sero implementadas
pelos pares durante a semana (Jogo do Planejamento).
Ciclo Trimestral: As releases so planejadas a cada trimestre. O plano do trimestre de mais alto nvel, geralmente
representado por um tema. Temas so diferentes de histrias
pois, ao invs de se preocupar com os detalhes, abrangem o
todo: a forma em que o projeto se encaixa na organizao.
Durante o planejamento do trimestre, o time deve: identificar gargalos (principalmente externos equipe), iniciar
reparos e escolher as histrias mais alinhadas ao tema e
que sero implementadas durante o trimestre.
Folga: Inclua no plano algumas tarefas menores que
possam ser removidas caso ocorra um atraso. Estimativas
no devem ser consideradas um comprometimento, pois
geralmente so feitas com base na experincia pessoal de
cada desenvolvedor, estando sujeitas a erros. No entanto,
importante que o time se comprometa com as entregas para
o cliente. Para acomodar o carter subjetivo das estimativas,
um tempo de folga deve ser includo no plano, para que
eventuais atrasos no atrapalhem a entrega da iterao ou da
release, criando um vnculo de confiana e responsabilidade
entre a equipe e o cliente.
Build em 10 Minutos: O build automtico do sistema
inteiro e a bateria completa de testes deve rodar em at 10
minutos. Os itens em destaque so importantes: o build,
assim como todas as tarefas repetitivas do projeto, deve ser
automatizado, deve considerar o sistema inteiro (cdigofonte e configuraes de ambiente), deve rodar todos os
testes e deve ser rpido o suficiente. As equipe de XP devem
tentar atingir o mximo dos objetivos propostos por essa
prtica, pois quanto mais tempo o build demorar, menos ser
executado, diminuindo os ciclos de feedback e aumentando
o tempo entre a introduo e a descoberta de um erro.
Integrao Contnua: O cdigo-fonte fica armazenado num
repositrio compartilhado e cada par deve integrar suas
alteraes ao final de cada tarefa, aps garantir que tudo
est funcionando, realizando um build completo e rodando
todos os testes. Os desenvolvedores interagem com o repositrio diversas vezes por dia para trabalhar sempre numa
verso atualizada do sistema. Dessa forma, o conhecimento
do sistema se espalha por toda a equipe mais facilmente e a
dificuldade de realizar uma integrao grande se dilui em
diversas integraes pequenas e freqentes.
Desenvolvimento Dirigido por Testes: Um dos aspectos
mais importantes de XP a nfase nos testes automatizados.
Essa prtica sugere que os testes sejam escritos antes do cdigo, trazendo benefcios como: nfase no desenvolvimento
(evitando generalizaes desnecessrias), preocupao
com acoplamento e coeso (geralmente o design est com
problemas quando surge uma dificuldade para escrever o
teste), confiana (o teste verifica o comportamento agora e no
futuro) e ritmo (a prxima tarefa sempre escrever o prximo teste ou fazer o teste passar, criando o ritmo conhecido
como vermelho, verde e refatorao [36]).
Design Incremental: A simplicidade um conceito chave
que permite a adaptao a mudanas. Para minimizar o
custo com mudanas desnecessrias no futuro, os desenvolvedores devem sempre implementar o design mais simples
- e no o mais simplista - com o mnimo da complexidade
e flexibilidade necessria para atender s necessidades de
negcio atuais. Porm, deve-se tomar cuidado com a interpretao dessa prtica. Seu objetivo no minimizar o
investimento com design no curto prazo, mas sim manter
esse investimento proporcional s necessidades do sistema
conforme ele evolui. O design incremental deve ter suporte
de outras prticas, como a refatorao e os testes automatizados gerados pelo desenvolvimento dirigido por testes para
garantir que a equipe seja capaz de solucionar os problemas
futuros com rapidez.
Prticas Corolrias
Envolvimento Real com o Cliente: Faa com que as pessoas
cujas vidas e negcios sero afetados pelo sistema faam
parte da equipe. O cliente tambm deve fazer parte do time
completo. Ele deve entender as necessidades de negcio e
conhecer os verdadeiros usurios do sistema, para escrever
histrias, definir prioridades e testes de aceitao e responder
eventuais dvidas sobre as funcionalidades desejadas.
Implantao Incremental: Ao substituir um sistema legado, evite
faz-lo de uma s vez. mais seguro substituir gradualmente partes das funcionalidades, deixando os dois sistemas funcionando
ao mesmo tempo. Grandes implantaes so muito arriscadas e
tm custos humanos e econmicos muito altos [24].
Continuidade da Equipe: Mantenha equipes eficientes trabalhando juntas. Existe uma tendncia de tratar as pessoas
como recursos substituveis, que so trocadas de projetos
diversas vezes para manter a utilizao alta. No entanto, o
valor no desenvolvimento de software no surge apenas
do que as pessoas sabem ou fazem, mas tambm de seus
relacionamentos e conquistas em equipe. Ignorar o valor das
interaes e relaes para simplificar problemas de alocao
uma falsa economia [24].
13
Diminuio da Equipe: Conforme a equipe melhora sua

capacidade de produo, gradualmente reduza a carga sobre
um dos membros, mantendo os outros trabalhando normalmente. Conforme a carga diminui sobre esse membro, ele
pode ser liberado para formar novas equipes. Apesar do
prprio Kent Beck no ter tido experincias com essa prtica
[24], incluiu-a em XP com base na sua eficcia no Sistema de
Produo da Toyota [16, 5, 7]. Tentar fazer com que todos os
membros paream ocupados pode possivelmente esconder
um excesso de recursos na equipe.
Anlise de Causa Inicial: Sempre que um defeito for
encontrado, conserte o problema e suas causas. O objetivo
no apenas fazer com que esse defeito especfico nunca
mais acontea, mas tambm que o time nunca mais cometa
o mesmo erro em outras situaes. O processo de XP para
consertar um defeito : escrever um teste de aceitao
automatizado que demonstre o problema, assim como o
comportamento esperado; escrever um teste unitrio com
o menor escopo que tambm reproduz o defeito; corrigir o
sistema, fazendo todos os testes passarem e, por fim, tentar
descobrir a causa inicial do defeito no ter sido detectado
anteriormente, realizando as mudanas necessrias para
evitar que o erro acontea novamente.
Cdigo Compartilhado: O repositrio do cdigo-fonte
compartilhado por toda a equipe e qualquer um pode
fazer melhorias em qualquer parte do sistema. Ao invs de
identificar responsveis por cada parte do cdigo, o time
completo responsvel pelo sistema inteiro. Com isso, os
membros da equipe adquirem uma ampla viso do sistema, facilitando a execuo de refatoraes e espalhando o
conhecimento por toda a equipe.
Cdigo e Testes: Os nicos artefatos mantidos pela equipe
so o cdigo e os testes. Documentao deve ser evitada e,
caso estritamente necessria, deve ser gerada a partir do
cdigo e dos testes. A principal forma de comunicao em
uma equipe de XP a conversa. Artefatos que se tornem
obsoletos com o tempo no agregam valor ao sistema e ao
negcio. Eliminar desperdcios permite melhorar as reas
que agregam valor, aquelas que definem o que o sistema faz
hoje e o que a equipe pode fazer com o sistema amanh.
Repositrio de Cdigo Unificado: A equipe deve desenvolver em um repositrio nico. Ramificaes podem existir,
mas devem ser evitadas. Quanto maior o nmero de verses
concorrentes do mesmo cdigo, maior o trabalho de sincronizao e mais difcil o entendimento pela equipe. Linhas
paralelas devem ser integradas rapidamente e os motivos de
sua existncia devem ser reconsiderados constantemente e
no tidos como verdade absoluta.
Implantao Diria: Coloque novas verses do sistema
em produo toda noite. Dessa forma, o ciclo de feedback
entre o que est sendo feito pelo programador e o que est
sendo utilizado pelo usurio sempre rpido e eficiente.
Para que essa prtica seja eficaz, muitas outras devem estar
funcionando bem. preciso garantir que o nmero de defeitos seja baixo e que as ferramentas de build e implantao
14
automatizem todo o processo de entrega, possibilitando

inclusive voltar uma verso, caso necessrio.
Contrato de Escopo Negocivel: Contratos devem fixar
tempo, custo e qualidade, deixando o escopo preciso aberto
para negociao. As equipes de XP se adaptam a mudanas, permitindo que o cliente faa correes no escopo do
software conforme seu aprendizado do sistema evolui. Em
XP, o escopo revisado freqentemente para garantir que a
equipe est sempre trabalhando no que mais importante
para o cliente.
Pague-Pelo-Uso: Essa prtica sugere a utilizao do dinheiro como feedback final. Em sistemas pay-per-use, voc cobra
a cada vez que o sistema utilizado. A conexo do fluxo de
economia ao desenvolvimento de software prov informaes precisas e atualizadas para direcionar melhorias no
sistema. No modelo mais utilizado pela indstria, o cliente
paga a cada release, porm isso coloca os interesses da equipe de desenvolvimento e do cliente em conflito. Enquanto
a equipe deseja um nmero maior de releases com pouca
funcionalidade, o cliente deseja o menor nmero possvel de
releases contendo o mximo de funcionalidade. Essa tenso
gera problemas de comunicao e feedback.
Comparao com as Prticas da Primeira Verso

Devido mudana na abordagem de apresentao das prticas de XP, Kent Beck transformou as 12 prticas originais
em 24 prticas divididas em prticas primrias e prticas
corolrias, conforme descrito na Seo Prticas. Algumas
prticas da primeira verso ainda aparecem de forma subjetiva na descrio das novas prticas, mas para ter uma
melhor base de comparao, importante descrev-las como
foram apresentadas na primeira edio do livro [35]:
Refatorao: A refatorao uma tcnica sistemtica para
reestruturar o cdigo existente, alterando sua estrutura
interna, porm mantendo seu comportamento externo [29].
Alguns exemplos de refatoraes so: a remoo de cdigo
duplicado, a mudana do nome de um mtodo ou varivel e
a extrao de um trecho de cdigo para um mtodo auxiliar.
O objetivo sempre tornar o cdigo e o design mais simples,
legvel, limpo e preparado para mudanas.
Metfora: Todos os membros da equipe, incluindo programadores e clientes, devem conversar sobre o sistema numa
linguagem comum. Essa linguagem deve ser entendida tanto
pelas pessoas tcnicas, quanto pelas pessoas de negcio.
Isso pode ser obtido atravs de uma metfora comum que
relaciona abstraes do sistema com objetos de um certo
domnio, existentes no mundo real. Essa uma das prticas
mais difceis de introduzir em uma equipe inexperiente,
pois est diretamente ligada comunicao e ao modo como
as pessoas esto dispostas a compartilhar seus desejos e
suas idias. Essa prtica estava bastante alinhada com um
padro descrito por Ward Cunningham, que ficou conhecido como Sistema de Nomes [44]. Mais recentemente, o uso
dessa linguagem ubqua para representar conceitos do domnio no cdigo-fonte ficou popularizada com a tcnica de
M etodologias geis
modelagem definida por Eric Evans, conhecida como Design

Dirigido pelo Domnio (Domain Driven Design) [45].
Padronizao de Cdigo: Antes de dar incio implementao, o time define um conjunto de padres de codificao para
escrita do cdigo do sistema. Isso torna o cdigo homogneo
e mais fcil de entender, melhora a comunicao, facilita a
refatorao e promove a propriedade coletiva do cdigo.
A Tabela 1 uma adaptao do autor com base num artigo
de Michele Marchesi [46] onde apresentada uma comparao entre a primeira e a segunda edio de XP, com destaque
para a relao entre as prticas novas e as prticas originais.
As prticas entre parnteses so aquelas que no aparecem
explicitamente na nova edio de XP.
Adaptaes das Prticas de XP

A adoo de um mtodo gil como XP no depende simplesmente da aplicao direta das prticas. O ciclo emprico de
inspeo e adaptao dos mtodos geis sugere que as equipes
estejam em busca freqente de melhoria e algumas adaptaes
so permitidas. Conforme XP comeou a ser utilizada em mais
projetos, uma nova prtica foi sugerida: Conserte XP quando
ela falha [47]. Uma boa fonte de inspirao para tais adaptaes so as prticas sugeridas em outros mtodos geis [48]:
Reunies em P: prtica utilizada em Scrum [14, 41] que
consiste numa reunio informal curta e diria, realizada no
incio do dia de trabalho na qual cada membro da equipe
responde a trs perguntas: O que fez ontem?, O que
pretende fazer hoje? e Quais problemas impedem o seu
progresso?. Os membros da equipe participam dessa Reunio em P para garantir que sua durao seja curta. Alm
disso, eventuais problemas que forem levantados devero
ser discutidos posteriormente apenas pelos interessados nos
problemas especficos.
Tabela de Comparao entre as prticas de XP

Primeira Edio
Segunda Edio
Programao Pareada
Programao Pareada
Verses Pequenas
Ciclo Semanal, Implantao Incremental e Implantao Diria
Integrao Contnua
Integrao Contnua
Desenvolvimento Dirigido por Testes Desenvolvimento Dirigido por Testes

Jogo do Planejamento
Histrias, Ciclo Semanal, Ciclo Trimestral e Folga
Cliente com os Desenvolvedores
Time Completo e Envolvimento Real com o Cliente
(Refatorao)
Design Incremental
Design Simples
Design Incremental
(Padronizao de Cdigo)
Cdigo Compartilhado
Propriedade Coletiva do Cdigo
Cdigo Compartilhado e Repositrio de Cdigo Unificado
(Metfora)
Design Incremental
Ritmo Sustentvel
Trabalho Energizado e Folga
Tabela 1. Comparao entre as prticas da primeira e da segunda edio

de XP, adaptado de [46]
Retrospectivas: prtica originada na Famlia Crystal [17]

e tambm conhecida como Reflection Workshops. Elas so
reunies realizadas ao final de cada iterao na qual o processo de desenvolvimento avaliado, a equipe discute as
lies aprendidas com a experincia e planeja as mudanas
para o prximo ciclo de desenvolvimento [49]. Existem diversos formatos para as reunies de retrospectiva, mas no
mais comum a equipe discute O que funcionou bem?, O
que pode melhorar? e Quais problemas nos preocupam?.
Normalmente, ao final da reunio, o time ter um conjunto
de aes em cada uma das categorias acima e poder prioriz-las e escolher as mais importantes para implementar
na prxima iterao. As aes escolhidas devem ser capturadas em um pster, que ser anexado rea de Trabalho
Informativa. Para garantir que as idias sejam discutidas
abertamente, comum evitar dar nome aos culpados. Essa
prtica enfatizada na diretiva principal das retrospectivas,
proposta por Kerth [49]:
No importa o que for descoberto, ns entendemos e acreditamos que todos fizeram o melhor
trabalho possvel, dado o conhecimento na poca,
as habilidades e os recursos disponveis na situao
em questo.
Papis na Equipe de XP
A prtica do Time Completo sugere que uma equipe de
XP seja formada por uma variedade de pessoas, com todas
as caractersticas e habilidades necessrias para o sucesso
do projeto. A primeira edio de XP [35] estava muito mais
voltada para programadores, porm, na segunda edio
[24], Kent Beck descreve a importncia da valorizao de
todos os outros papis dentro de uma equipe. Vale ressaltar
que os papis podem ser assumidos por pessoas diferentes,
em momentos distintos e que uma mesma pessoa pode desempenhar mais de um papel. A idia proporcionar um
ambiente produtivo no qual cada membro possa contribuir
da melhor forma para o projeto. Alguns dos papis que
podem fazer parte de uma equipe de XP so:
Programadores: Responsveis por estimar histrias e
tarefas, quebrar histrias em tarefas, escrever testes e cdigo, automatizar processos tediosos e melhorar o design
do sistema. Existem dois papis especiais para programadores. Geralmente, o mais experiente em XP atua como
coach (treinador), verificando e auxiliando os membros
na execuo das prticas no dia-a-dia. J o tracker est
constantemente coletando e compartilhando dados sobre o
andamento do projeto e do processo. O tracker responsvel
por criar e espalhar cartazes e grficos na rea de Trabalho
Informativa.
Arquitetos: Procuram e executam refatoraes de larga
escala no sistema, escrevem testes de carga automatizados
para definir cenrios de estresse e auxiliam os programadores no particionamento do sistema, mantendo a nfase
no design de alto nvel.
15
16
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
Este artigo apresentou um dos mtodos geis mais conhecidos, a Programao Extrema, descrevendo seus valores,
princpios e prticas. A escolha da melhor forma de adotar
XP deve levar em conta todos os fatores discutidos neste
artigo e a abordagem de implantao pode variar de equipe
para equipe. Enquanto algumas se sentem confortveis com
a abordagem mais rgida proposta na primeira edio, aplicando todas as 12 prticas de uma vez, outras podem preferir
comear de forma mais gradual, com algumas das prticas
primrias antes de partir para as prticas corolrias.
XP no deve ser utilizado em organizaes cujos valores reais no se alinham com os valores de XP. Organizaes que preferem dar valor a segredos, isolamento,
complexidade, timidez e falta de respeito (manifestada
como prepotncia ou excesso de autoritarismo) no
tero sucesso com a adoo de XP. Vale ressaltar ainda
que uma adoo de sucesso de XP precisa abraar os
valores e princpios por trs das prticas. A adoo de
algumas prticas pode trazer um pequeno benefcio no
curto prazo, mas as melhorias mais amplas propostas
por XP s sero atingidas se houver sinergia entre os
valores da equipe e de XP. Um grande choque cultural
pode prejudicar a adoo de XP [51].
O discurso de XP mudou desde seu lanamento em
1999: enquanto a primeira edio enfatizava mais
como XP funciona, a segunda edio enfatiza muito
mais o por qu. Enquanto a primeira edio era mais
voltada para os programadores, a segunda edio tem
um discurso mais inclusivo e flexvel, trazendo benefcios para todos os envolvidos no desenvolvimento
de software.
D
s
Discusso das Formas de Adoo e Concluses
Kent Beck discute sobre os diferentes estilos de adoo fazendo uma analogia com as formas de se entrar
numa piscina [50]: alguns preferem entrar de forma
cuidadosa e gradual, um p de cada vez, evitando
grandes estragos, porm gastando mais tempo; outros
preferem entrar de uma vez, no estilo bola de canho,
espalhando bastante gua e passando por uma fase inicial catica, que pode trazer maiores benefcios no curto
prazo; por fim, equipes que precisam de um resultado
rpido sem o risco da fase catica, podem adotar o estilo
mergulho de cabea com a ajuda de um treinador
externo, que vai tornar a entrada na gua mais suave,
pela experincia adquirida em outras situaes.
Kent Beck ainda sugere alguns pontos de ateno que
devem ser discutidos pela equipe para escolher a forma
de adoo mais apropriada:
Em quanto tempo o time precisa dos resultados?
O quo dramtico devem ser os resultados?
Quanto a organizao est disposta a gastar em
ajuda externa?
O quo forte so as relaes entre os membros da
equipe e entre a equipe e o resto da organizao?
edio
ta
Analistas de Teste: Trabalham com o cliente e com os

analistas de negcio para escrever testes de aceitao automatizados, definindo os cenrios de sucesso e erro de cada
histria. Alm disso, tambm treinam os programadores
em tcnicas e ferramentas de teste.
Analistas de Negcio: Trabalham com o cliente para definir as histrias do sistema e auxiliam os programadores
a interpretar o valor de negcio de cada funcionalidade.
Projetistas de Interao: Avaliam o modo como o sistema
est sendo utilizado pelos usurios finais, identificando e
sugerindo novas histrias e melhorias na interface grfica.
Gerentes de Projeto: Facilitam a comunicao dentro do
time, removendo empecilhos e coordenando a comunicao com pessoas externas equipe do projeto (fornecedores, clientes externos ou o resto da organizao).
Gerentes de Produto: Escrevem e priorizam histrias
para o ciclo semanal e definem os temas para o ciclo
trimestral. Alm disso, encorajam a comunicao entre
a equipe e o cliente para garantir que as preocupaes e
necessidades mais imediatas do cliente e do usurio final
sejam atendidas.
Executivos: Trazem confiana, coragem e responsabilidade para a equipe. Alm disso, avaliam os objetivos do
time em relao s metas da organizao, monitorando e
facilitando a criao de um ambiente voltado melhoria
contnua.
Redatores Tcnicos: Por olharem o sistema do ponto de
vista do usurio final, os redatores tcnicos trazem feedback rpido sobre as funcionalidade do sistema e estreitam
o relacionamento da equipe com o cliente, levantando
dvidas e sugerindo melhorias.
Usurios: Por utilizar o sistema diariamente, podem
ajudar a escrever e escolher histrias e tomar decises
de domnio durante o desenvolvimento. Por representar
toda a comunidade de usurios, interessante que tenham
experincia com sistemas similares para tomar as decises
mais adequadas.
Recursos Humanos: Cuidam de problemas burocrticos
como contratao e avaliaes. Kent Beck sugere a avaliao do time ao invs de avaliaes individuais para evitar
conflitos internos que atrapalhem o bom andamento do
projeto [24].
M etodologias geis
Referncias
[1] Mira Kajko-Mattsson, Ulf Westblom, Stefan Forssander, Gunnar Andersson, Mats
[26] Kent Beck and Ward Cunningham. Using pattern languages for object-oriented programs.
Medin, Sari Ebarasi, Tord Fahlgren, Sven-Erik Johansson, Stefan Tornquist, and Margareta
Technical Report CR8743, Tektronix, Inc., September 1987. Presented at the OOPSLA-87 Workshop
Holmgren. Taxonomy of problem management activities. In Proceedings of the Fifth European
on Specification and Design for Object-Oriented Programming.
Conference on Software Maintenance and Reengineering, pages 110, 2001.
[27] Bo Leuf and Ward Cunningham. The Wiki Way: Quick Collaboration on the Web.
[2] Barry W. Boehm. Industrial software metrics top 10 list. IEEE Software, 4(5):8485, Set 1987.
Addison-Wesley Professional, 2001.
[3] Barry W. Boehm and Philip N. Papaccio. Understanding and controlling software
[28] William F. Opdyke. Refactoring Object-Oriented Frameworks. PhD thesis, University of Illinois,
costs. IEEE Transactions on Software Engineering, 14(10):14621477, Oct 1988.
1992.
[4] Barry W. Boehm and Victor R. Basili. Software defect reduction top 10 list. Computer,
[29] Martin Fowler, Kent Beck, John Brant, William Opdyke, and Don Roberts. Refactoring:
34(1):135137, Jan 2001.
Improving the Design of Existing Code. Addison-Wesley Professional, 1999.
[5] Mary Poppendieck and Tom Poppendieck. Lean Software Development: An Agile Toolkit for
[30] Kent Beck. Simple smalltalk testing: With patterns. Technical report, First Class Software, Inc.,
Software Development Managers. Addison-Wesley Professional, 2003.
Outubro 1994. Disponvel em: www.xprogramming.com/testfram.htm.
[6] Jim Johnson. ROI, its your job. Keynote Speech at Third International Conference
[31] Kent Beck. SUnit project. Disponvel em: sunit.sourceforge.net/. Acessado em: 30/10/2006.
on Extreme Programming (XP2002), May 2002.
[32] Kent Beck and Erich Gamma. Test infected: Programmers love writing tests. Java
[7] Mary Poppendieck and Tom Poppendieck. Implementing Lean Software Development: From
Report, 3(7), July 1998. Acessado em Jan/06.
Concept to Cash. Addison-Wesley Professional, 2006.
[33] Kent Beck and Erich Gamma. JUnit project. Disponvel em: www.junit.org/. Acessado em:
[8] Jim Johnson, et al. CHAOS in the new millenium. Technical report, Standish Group, 2000.
30/10/2006.
[9] The CHAOS report. Technical report, Standish Group, 1994.
[34] xUnit family. Disponvel em: www.xprogramming.com/software.htm. Acessado em: 30/05/2007.
[10] The CHAOS report. Technical report, Standish Group, 2003.
[35] Kent Beck. Extreme Programming Explained: Embrace Change.Addison-Wesley Professional, 1999.
[11] Frederick T. Sheldon, Krishna M. Kavi, Robert C. Tausworth, James T. Yu, Ralph
[36] Kent Beck. Test Driven Development: By Example. Addison-Wesley Professional, 2003.
Brettschneider, and William W. Everett. Reliability measurement: From theory to practice. IEEE
[37] Scott Ambler. Crossing the chasm. Dr. Dobbs Journal, disponvel em: www.ddj.com/dept/
Software, 9(4):1320, Jul 1992.
architect/187200223, May 2006. Acessado em: 30/10/2006.
[12] Craig Larman. Agile and Iterative Development: A Managers Guide. Addison-Wesley
[38] Vincius Manhes Teles. Extreme Programming: Aprenda como encantar seus usurios
Professional, 2003.
desenvolvendo software com agilidade e alta qualidade. Editora Novatec, 2004.
[13] Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham,
[39] Kent Beck and Martin Fowler. Planning Extreme Programming. Addison-Wesley
Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian
Professional, 2000.
Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, and Dave Thomas.
Manifesto for agile software development. Disponvel em: www.agilemanifesto.org, 2001. Acessado
em: 30/10/2006.
[14] Ken Schwaber and Mike Beedle. Agile Software Development with Scrum. Prentice Hall, 2001.
[15] Christ Vriens. Certifying for CMM level 2 and ISO9001 with XP@scrum. In Agile
Development Conference, pages 120124. IEEE Computer Society, 2003.
[16] Taiichi Ohno. Toyota Production System: Beyond Large-Scale Production. Productivity Press, 1998.
[17] Alistair Cockburn. Crystal Clear: A Human-Powered Methodology for Small Teams. AddisonWesley Professional, 2004.
[18] Stephen R. Palmer and John M. Felsing. A Practical Guide to Feature Driven Development.
Prentice Hall, 2002.
[19] Peter Coad, Jeff de Luca, and Eric Lefebvre. Java Modeling Color with UML: Enterprise
Components and Process with Cdrom. Prentice Hall, 1999.
[20] Jim Highsmith. Messy, exciting, and anxiety-ridden: Adaptive software development. In
American Programmer, volume 10, 1997.
[40] Alistair Cockburn. Agile Software Development: The Cooperative Game. Addison
Wesley Professional, 2nd edition, 2006.
[41] Ken Schwaber. Agile Project Management with Scrum. Microsoft Press, 2004.
[42] Tom Demarco and Timothy Lister. Peopleware: Productive Projects and Teams. Dorset House
Publishing Company, Incorporated, 2nd edition, 1999.
[43] Mike Cohn. Agile Estimating and Planning. Prentice Hall PTR, 2005.
[44] Ward Cunningham. System of names. Disponvel em: c2.com/cgi/wiki?SystemOfNames.
Acessado em: 30/05/2007.
[45] Eric Evans. Domain-Driven Design: Tackling Complexity in the Heart of Software.
Addison-Wesley Professional, 2003.
[46] Michele Marchesi. The new XP. Disponvel em: www.agilexp.org/downloads/TheNewXP.pdf.
Acessado em: 30/05/2007.
[47] Don Wells. Fix XP when it breaks. Disponvel em: www.extremeprogramming.org/rules/fixit.html.
Acessado em 31/05/2007.
[48] Danilo Sato, Dairton Bassi, and Alfredo Goldman. Extending extreme programming with
[21] M. Mitchell Waldrop. Complexity: The Emerging Science at the Edge of Order and Chaos. Simon
practices from other methodologies. In 1st Workshop on Rapid Application Development (WDRA07)
& Schuster, 1992.
in the Brazilian Symposium of Software Quality (SBQS07), 2007.
[22] James Martin. Rapid Application Development. Macmillan Publishing Co., 1991.
[49] Norman L. Kerth. Project Retrospectives: A Handbook for Team Reviews. Dorset House
[23] Jennifer Stapleton. DSDM: A framework for business centered development. Addison- Wesley
Publishing Company, 2001.
Professional, 1997.
[50] Kent Beck and Cynthia Andres. Getting started with XP: Toe dipping, racing dives, and cannonballs.
[24] Kent Beck and Cynthia Andres. Extreme Programming Explained: Embrace Change. Addison-
Disponvel em: www.threeriversinstitute.org/ToeDipping.pdf. Acessado em: 30/10/2006.
Wesley Professional, 2nd edition, 2004.
[51] Laurent Bossavit. The unbearable lightness of programming: a tale of two cultures.Whitepaper,
[25] Kent Beck and Ward Cunningham. A laboratory for teaching object-oriented thinking. In
disponvel em: www.exoftware.com/i/white_paper/file/6/The_20unbearable_20.pdf. Acessado em:
OOPSLA, pages 16, October 1989.
30/10/2006.
17
UML Casos de Uso

Entendendo os casos de uso na prtica um estudo de caso Parte I
ste artigo apresentar uma das principais ferramentas oferecidas pela

UML o caso de uso, demonstrando sua utilizao na prtica, por meio do
desenvolvimento de um estudo de caso.
Nessa primeira parte detalharemos o
problema, os requisitos e extrairemos os
casos de uso necessrios implementao.
Escreveremos os primeiros cenrios, com
seus respectivos prottipos, preparando o
sistema para se tornar funcional.
O problema
Ana Cristina Melo
informatica@anacristinamelo.com.br
especialista em Anlise de Sistemas e professora de graduao e ps-graduao da

Universidade Estcio de S. Atua em anlise
e programao h 21 anos. Autora do livro
Desenvolvendo aplicaes com UML do
conceitual implementao, na segunda
edio, e Exercitando modelagem em UML.
Palestrante em alguns eventos, entre eles,
Congresso Fenasoft, OD e Sepai.
18
No artigo anterior, explicamos o caso de

uso como uma das principais ferramentas
para capturar os requisitos do sistema.
Neste usaremos os conceitos apresentados para desenvolver um estudo de
caso. preciso ressaltar que os modelos
de documentos aqui apresentados so
oriundos da experincia da autora como
analista de sistemas, servindo apenas
como exemplo para os profissionais da
Engenharia de Software Magazine - UML Casos de Uso
Este artigo apresenta o caso de uso de uma

maneira prtica. Ser desenvolvido um estudo
de caso, passando por todas as fases da modelagem dos requisitos quanto aos casos de uso.
Para que serve?

Fornecer aos desenvolvedores ou estudantes da rea de sistemas uma linha de
entendimento com o intuito de orient-los
a escrever seus prprios casos de uso.

Para quem ainda no conhece como escrever um caso de uso, ou para quem j o faz
h algum tempo, mas no tem conseguido
o sucesso esperado.
rea. E que os requisitos descritos tm

objetivo somente como exerccio, no representando, na prtica, as necessidades
de um sistema deste tipo.
Suponha que um analista XYZ tenha
aberto uma consultoria e, dentre os primeiros clientes, surja o dono de uma pequena papelaria, com uma nica filial,
desejando informatizar sua empresa.
Requisitos
O analista marca algumas reunies e aps estabelecer o

escopo do sistema, d incio ao levantamento dos requisitos.
De posse desses requisitos, seu trabalho model-los, de tal
forma que represente a expectativa desse cliente. Para essa
modelagem, ele utiliza os casos de uso, pois pretende fazer
uso da tecnologia de orientao a objetos. Os casos de uso e
seus prottipos so apresentados para o cliente, que sugere
alteraes. Esse processo perdura ciclicamente at que o cliente
d sua aprovao para o analista.
Ento, o projeto estar pronto para uma nova etapa, no
qual as classes sero identificadas e o sistema comear a ser
implementado.
Vamos acompan har como ficou essa fase inicial da
modelagem.
O levantamento de requisitos
O analista XYZ, aps cada reunio elaborou uma ata que foi
devidamente encaminhada para o cliente, a fim de validar
com o mesmo o entendimento dos requisitos. Na Tabela 1 vemos o exemplo de uma dessas atas, representando a primeira
reunio ocorrida.
Aps todas as reunies, o analista XYZ preparou um nico
documento consolidando todos os requisitos. Esses requisitos
esto listados abaixo:
ATA DE REUNIO
Data da reunio: 10/10/2008
Participantes: XYZ analista de sistemas

MNO diretor da Papelaria ABC
Assunto: Levantamento de requisitos
O sr. MNO apresentou ao sr. XYZ a papelaria ABC, que tem cerca de 800 m2, c om sees arrumadas
por tipo de item: cadernos e fichrios, pastas, papis para impresso etc.
A papelaria conta com vendedores que atendem ao pblico, recebendo comisso pelas vendas
efetuadas. A comisso tem variao de acordo com a poca do ano. No perodo de janeiro a maro,
a comisso de 7% sobre as vendas. Nos outros meses de 5%. Alm disso, todo vendedor possui
um salrio fixo. No h cotas a serem alcanadas.
Aps escolher os produtos, com a ajuda ou no de um vendedor, o cliente deve se dirigir a um
deles para tirar o pedido de venda. Esse pedido conter todos os produtos e liberar para o caixa
apenas o pagamento. S existe um caixa na papelaria, responsvel apenas pelo recebimento do
pagamento.
Se um cliente tiver dvidas sobre a existncia de um produto ou sobre o preo do mesmo, poder
consultar um dos vendedores, que far a pesquisa no sistema.
Todos os produtos recebem um cdigo que no est associado ao cdigo de barras. So coladas
etiquetas com esses cdigos em todos os produtos. Da mesma forma, em cada prateleira h uma
etiqueta com o nome dos produtos, seu cdigo e o preo atualizado. Assim, nos produtos no h
etiqueta de preo.
O sr. MNO solicitou que alm do sistema que registrar as vendas, seja disponibilizado um mdulo
para controlar o estoque.
(...)
Pendncias para a prxima reunio:
- O sr. MNO far uma lista de todos os relatrios que deseja, contendo todas as informaes
necessrias e detalhes de emisso, como freqncia.
Tabela 1. Exemplo da ata de reunio com o levantamento de requisitos
O sistema conter dois mdulos principais: gestor de estoque/vendas e pdv (ponto de vendas).
No ser foco dessa verso a gesto de fornecedores, pagamento dos funcionrios e controle de contas a pagar.
A papelaria conta com vendedores que atendem ao pblico,
recebendo comisso pelas vendas efetuadas.
Para a gesto de estoque/vendas, so desejveis os seguintes
controles:
- cadastro de produtos
- cadastro de fabricantes
- cadastro de vendedores
- atualizao de estoque
- registro de troca e devoluo de produto
- consulta de preos
- registro de vendas
- emisso de etiquetas de venda
- relatrio de reposio
- consulta de faturamento dirio, semanal ou mensal
- atualizar preos e lanar promoes de produtos
Para o PDV, so desejveis os seguintes controles:
- registro de pagamento das vendas
- realizar retirada de capital
- suprimento de capital (entrada de capital no caixa)
- abertura do caixa
- fechamento do caixa
O cadastro de produtos ser feito pelo departamento de estoque, e para cada produto preciso registrar: cdigo (gerado
automaticamente pelo sistema), nome do produto (ex: caderno
universitrio), detalhes sobre o produto (ex: 256 folhas), unidade de venda (ex: unidade, kit, pacote, metro etc), fabricante, cor,
percentual de lucro, tipo de produto (ex: cadernos e fichrios,
papis para impresso etc) e a foto do produto.
Nenhum produto pode ser excludo do estoque, apenas desativado, por meio de uma data, que determinar que a partir
daquele momento no mais poder ser vendido. Nenhum
produto com itens ainda em estoque pode ser desativado.
O estoque de cada produto ser automaticamente gerado no
momento do cadastramento do produto. O estoque ser inicializado com zero, porm deve ser informada a quantidade mnima
de estoque, que identificar a necessidade de reposio.
As entradas no estoque so feitas a partir das notas fiscais de
compras e so responsabilidade do departamento de estoque.
No haver controle dos fornecedores, mas ser preciso manter um cadastro com o nome dos fornecedores, para a futura
verso do sistema. Para cada nota fiscal, armazenar nmero,
data de emisso e fornecedor. A cada entrada de produto no
estoque, deve ser registrado: quantidade e valor de custo. O
sistema dever apresentar o valor atual de venda e calcular o
novo preo de venda do produto com base no valor de compra. Caber ao usurio confirmar o novo preo ou manter o
existente. Deve-se manter um histrico dos preos.
Atualizaes de preos e cadastramento de promoes devem ser feitas pela gerncia. As promoes de produtos devem
ser cadastradas por perodo (ex: preo promocional da cola 90g
no perodo de 01/01/2009 a 15/01/2009).
19
O registro da venda ser feito pelo vendedor e se dar a

partir do cdigo do produto. Se o vendedor no souber o cdigo, poder fazer a pesquisa pelo nome. Para cada produto
informada a quantidade comprada. Ao final de uma venda,
gerada uma nota com todos os produtos, contendo um nmero
de venda e o total a pagar. Essa nota deve ser paga no caixa. O
supervisor poder autorizar um desconto para a venda total.
Isso se dar no momento do registro da venda. So formas
de pagamento aceitas: dinheiro, dbito e carto de crdito.
Para dbito e carto de crdito, o sistema no se conectar
administradora de carto ou aos sistemas bancrios. O sistema
apenas aguardar a confirmao do caixa quanto autorizao
externa. Contudo, deve-se registrar qual a bandeira do carto
e os quatro ltimos dgitos do mesmo.
Durante a venda, qualquer item pode ser cancelado, desde
que autorizado pelo Supervisor.
Modelando o diagrama de casos de uso
Figura 1. Diagrama de casos de uso para o sistema gestor da papelaria
Um produto pode conter variaes. Toda variao de um

produto ser um produto com cdigo prprio, contudo seus
dados principais (nome, fabricante e tipo do produto) so
alterveis apenas no produto principal.
O cadastro de fabricantes ser feito pelo departamento de
estoque e deve conter apenas um cdigo gerado pelo sistema
e o nome.
O cadastro de vendedores ser feito pela gerncia da papelaria e deve conter apenas seu cdigo e nome. A comisso a
mesma para todos os vendedores, respeitando-se os percentuais estipulados para as pocas do ano. Sendo assim, cadastra-se
o perodo inicial e final (dd/mm/yyyy) e a comisso que ser
paga sobre as vendas, independente dos vendedores.
A troca ou devoluo de produto ser feita pela gerncia da
papelaria. Para ambos os casos, o produto deve retornar ao
estoque, e o cliente receber um vale-troca que s poder ser
utilizado no mesmo dia.
A consulta de preos poder ser feita pelo cdigo e/ou pela
descrio (abrangendo detalhes, cor e fabricante), possibilitando
a localizao de uma lista de produtos que atenda ao critrio,
ou at mesmo a lista de produtos que pertenam a um mesmo
grupo (variao). Pode ser efetuada pelo vendedor, supervisor
ou pela gerncia da papelaria.
20
De posse dos requisitos, o analista pde dimensionar o tamanho do sistema, e chegar ao seu diagrama de casos de uso.
Todos os cadastros so representados como casos de uso
de manuteno (incluso, alterao, excluso e/ou consulta),
identificados pelo verbo manter. (ex: Manter Produto indica
cadastro, alterao, desativao e pesquisa de produto).
Num primeiro momento, foram identificados todos os atores
responsveis por atuar nesse sistema. Para cada ator, verificamse suas responsabilidades. De cada uma dessas responsabilidades, nasce um ou mais casos de uso.
Ao determinar um caso de uso, devemos ter em mente seu
carter bem definido de funcionalidade. No podemos estabelecer um caso de uso tipo mil e uma utilidades. Um caso
de uso deve se encerrar num objetivo nico.
Diante do exposto, o analista chegou seguinte lista de casos
de uso, descrita na Tabela 2.
LISTA DE CASOS DE USO
Ator: Departamento de estoque
- Manter Produto
- Manter Tipo de Produto
- Manter Unidade de Venda
- Registrar Entrada em Estoque
- Gerar relatrio de reposio
Ator: Vendedor
- Manter Fabricante
- Manter Fornecedor
- Manter Cor
- Emitir etiquetas de vendas
- Consultar Produtos e Preos
- Registrar Vendas
Ator: Gerncia
- Manter Vendedor
- Registrar Troca e Devoluo
- Consultar Faturamento
- Atualizar preos e lanar promoes de produtos - Realizar retirada de capital do caixa
Ator: Supervisor
- Cancelar item de venda
- Abrir o caixa
Ator: Caixa
- Realizar retirada de capital do caixa

- Fechar o caixa
- Registrar pagamento de venda
- Inserir suprimento de capital
Tabela 2. Lista de casos de uso
Requisitos
Listagem 1. UC Manter Produto

Descrio: Este caso de uso tem por objetivo manter o cadastro
de produtos, permitindo a incluso, alterao, desativao ou
consulta de produtos.
Atores: Departamento de Estoque
Pr-condio: existir cadastro prvio de fabricantes, tipos de
produto, unidades de venda e cores.
Cenrio principal:
1.
O sistema prepara uma lista de produtos cadastrados, exibindo
para cada um: cdigo, nome do produto, detalhes, cor, fabricante e
cdigo do produto principal (se for um produto variao).

1.1.
O usurio pode pesquisar um produto, informando os
seguintes critrios:
- cdigo (com a opo de todas as variaes do produto localizado) ou
- descrio do produto (trecho ou integral) e/ou
- fabricante (trecho ou integral)
2.
O sistema habilita as seguintes opes para o usurio:
2.1.
Incluso de produto
2.2.
Incluso por variao de produto
2.2.1.
Para incluir uma variao, o usurio deve selecionar o
produto principal
2.3.
Alterao de produto
2.3.1.
Para alterao, o usurio deve pr-selecionar o produto
2.4.
Desativao de produto: opo habilitada apenas para
produtos que estejam com o saldo em estoque igual a zero.
2.4.1.
Para desativao, o usurio deve pr-selecionar o produto
3.
Para a opo de Incluso ou Alterao:
3.1.
O sistema prepara uma lista de todos os fabricantes cadastrados.
3.2.
O sistema prepara uma lista de todos os tipos de produtos
cadastrados.
3.3.
O sistema prepara uma lista de todas as unidades de venda
cadastradas.
3.4.
O sistema prepara uma lista de todas as cores cadastradas.
3.5.
No caso de alterao, o sistema exibe o cdigo do produto,
desabilitado para ediao.
3.6.
O usurio informa/edita:
3.6.1.
nome do produto
3.6.2.
detalhes do produto
3.6.3.
cor, selecionada da lista previamente preparada
3.6.4.
fabricante, selecionado da lista previamente preparada
3.6.5.
unidade de venda, selecionada da lista previamente
preparada
3.6.6.
percentual de lucro
3.6.7.
tipo do produto, selecionado da lista previamente
preparada
3.6.8.
no caso de incluso: quantidade mnima em estoque
3.6.9.
foto do produto
- Estoque inicial = zero

- Qtd Mnima de Estoque = quantidade informada pelo usurio
(item 3.6.8 ou 4.5.5)
6.3.
Para opo de Incluso por variao de produto:
6.3.1.
O sistema automaticamente associa o produto de variao
ao produto principal.

Cenrios alternativos:
Pesquisa de produto
1.a. A pesquisa de produto deve desconsiderar caixa alta e baixa,
acentuao e realizar a localizao dos trechos em qualquer
ordem que os mesmos apaream no cadastro.
1.b. A pesquisa da descrio deve ser feita ao mesmo tempo nos
campos: nome do produto, detalhes e cor, retornando os
produtos que contenham os critrios de pesquisa em qualquer um
desses campos.
Permisso da opo de Incluso por variao de produto
2.a. Se o usurio selecionar um produto que seja de variao,
exibir mensagem de erro e retornar ao passo 1.
Duplicidade de nome do produto + fabricante + detalhes
3.a. Se j houver cadastrado o mesmo nome do produto com os
mesmos detalhes e mesmo fabricante, que no seja uma
variao de produto, o sistema deve exibir mensagem de erro, e
retornar ao passo 2.
Alterao de Variao de Produto
3.b. No caso de alterao de um produto que seja variao de
outro, o sistema deve permitir a edio somente dos campos:
detalhes, cor, unidade de venda e percentual de lucro,
exibindo o cdigo do produto principal e o cdigo do produto
de variao.
Figura 2. Prottipo (1) do UC Manter Produto Tela principal

da manuteno
4.
Para a opo de Incluso por variao de produto:
4.1.
O sistema prepara uma lista de todas as unidades de venda
cadastradas.
4.2.
O sistema prepara uma lista de todas as cores cadastradas.
4.3.
O sistema automaticamente exibe as informaes do produto
principal:
4.3.1.
nome do produto
4.3.2.
fabricante
4.3.3.
tipo do produto
4.4.
O sistema libera a incluso de um novo produto, com base na
variao do produto j existente.
4.5.
O usurio informa:
4.5.1.
detalhes do produto
4.5.2.
unidade de venda, selecionada da lista previamente
preparada
4.5.3.
cor, selecionada da lista previamente preparada
4.5.4.
percentual de lucro
4.5.5.
quantidade mnima em estoque
4.5.6.
foto do produto
Figura 3. Prottipo (2) do UC Manter Produto Alterao de

produto
5.
Para a opo de Desativao:
5.1.
O usurio informa a data da desativao.
6.
O usurio confirma a operao.
6.1.
O sistema atualiza o cadastro de produtos.
6.2.
Para a opo de Incluso (individual ou como variao de
produto):
6.2.1.
O sistema gera automaticamente um cdigo de produto.
6.2.2.
O estoque inicial do sistema criado, com as seguintes
informaes:
Figura 4. Prottipo (3) do UC Manter Produto Alterao de

variao de produto
21
Listagem 2. UC Registrar Entrada em Estoque

Descrio: Este caso de uso tem por objetivo registrar entrada
de produtos, disponibilizando-os para venda.
Atores: Departamento de Estoque
Pr-condio: existir cadastro prvio de fornecedores e
produtos.
Cenrio principal:
1.
O sistema prepara uma lista de todos os fornecedores
cadastrados.
2.
O usurio informa:
2.1.
Nmero da Nota Fiscal
2.2.
Data da Nota Fiscal
2.3.
Fornecedor, selecionado da lista previamente preparada
3.
Para cada produto da nota fiscal:
3.1.
O usurio informa:
3.1.1.
cdigo do produto
3.1.1.1.
O sistema pesquisa e exibe o nome do produto, os
detalhes, a cor e o fabricante.
3.1.1.2.
O sistema exibe a quantidade atual em estoque.
3.1.2.
quantidade adquirida
3.1.3.
valor unitrio da compra
3.2.
O sistema verifica o preo atual de venda do produto.
3.3.
O sistema calcula e exibe a sugesto de novo preo de
venda, considerando o seguinte clculo:
3.3.1.
novo preo = valor unitrio da compra x percentual de
lucro do produto
detalhes, cor, fabricante, qtd adquirida, nova quantidade em

estoque, valor unitrio de compra, valor normal de venda vigente.
4.
O sistema atualiza o cadastro de estoque.
4.1.
Em caso de alterao do preo de venda:
4.1.1.
O sistema cadastra o novo preo de venda associando
seu incio de vigncia data atual.
4.2.
Para cada produto atualizado, o sistema acrescenta na
quantidade em estoque do produto a quantidade adquirida.
Nota fiscal em duplicidade
2.a. Se j houver o mesmo nmero de nota fiscal para o mesmo
fornecedor, o sistema deve exibir mensagem de erro e
Pesquisa de produto
3.a. O usurio poder localizar um produto por seu cdigo
ou utilizando a consulta de produtos. Include UC Consultar
Produtos e Preos.
Exibio de preo atual de venda
3.b. Se o produto estiver em poca de promoo, o sistema deve
apresentar o preo normal fora da promoo, o preo
promocional e seu perodo de vigncia.
Produto inexistente
3.c. Se o cdigo do produto no existir, o sistema deve exibir
mensagem de erro e chamar a Pesquisa de Produto.
Produto desativado
3.d. Se o produto informado pelo usurio estiver com o status
de desativado, o sistema deve exibir mensagem de erro e
3.4.
O usurio confirma o preo vigente ou o novo preo sugerido.
3.5.
O sistema exibe todos os produtos que esto sendo
cadastrados, contendo para cada um: cdigo, nome do produto,
Listagem 3. UC Consultar Produtos e Preos

Descrio: Este caso de uso tem por objetivo fornecer mecanismos
de localizao de produtos, bem como conferir o preo oferecido
para um determinado produto
Atores: Departamento de Estoque, Vendedor e Gerncia
Pr-condio: identificar o chamador do caso de uso
Cenrio principal:
1.
O usurio informa os critrios de busca:
- cdigo (com a opo de todas as variaes do produto localizado)ou
- descrio do produto (trecho ou integral) e/ou
- fabricante (trecho ou integral)
2.
O sistema pesquisa e exibe os produtos que satisfaam os
critrios informados, exibindo para cada um:
2.1.
cdigo do produto
2.2.
nome do produto
2.3.
detalhes
2.4.
cor
2.5.
fabricante
2.6.
preo de venda
2.7.
unidade de venda
2.8.
tipo do produto
2.9.
quantidade em estoque
2.10.
foto do produto
Figura 5. Prottipo do UC Registrar Entrada em Estoque
3.
Se o chamador do caso de uso assim necessitar, o usurio pode
selecionar um produto.
Ps-condio: retornar o produto selecionado, se for o caso.
Pesquisa de produto
1.a. A pesquisa de produto deve desconsiderar caixa alta e baixa,
acentuao e realizar a localizao dos trechos em qualquer
ordem que os mesmos apaream no cadastro.
1.b. A pesquisa da descrio deve ser feita ao mesmo tempo nos
campos: nome do produto, detalhes e cor, retornando os
produtos que contenham os critrios de pesquisa em qualquer um
desses campos.
22
Figura 6. Prottipo do UC Consultar Produtos e Preos
Requisitos
Concluso
No prximo artigo, veremos em detalhes casos de uso de outros
formatos, como o de relatrio, registro de pagamento (com as
diversas formas de pagamento), consulta em tela e o de processamento e controle (como abertura e fechamento de caixa).
Feedback
eu
23
sobre e
s
Diagrama feito, hora de trabalhar. At ento o analista tem

apenas um nome de caso de uso. Isso timo para estabelecer
o escopo de seu trabalho, mas no diz praticamente nada sobre
o que o sistema deve fazer. O mximo de informao que se
tem quem executar cada tarefa.
Assim, para cada caso de uso, o analista ir escrever seus
cenrios. Mas baseado em que? Baseado nos requisitos levantados. No cabe ao analista, e muito menos ao programador
que receber essa documentao, inventar nenhum requisito,
nenhuma regra. Ora, sendo assim, preciso que tudo o que
seja relevante esteja dito nos cenrios de caso de uso. Ento,
significa que os requisitos tambm precisam estar detalhados.
Se no estiverem, hora de voltar um passo e ter mais uma
reunio com o cliente.
Na Listagem 1, apresentamos a descrio do caso de uso
Manter produto. Para que o analista possa chegar escrita
desse caso de uso, ele deve buscar nos requisitos tudo o que
seja inerente ao cadastramento ou manuteno de um produto
dentro do sistema, incluindo suas regras. A partir do caso de
uso escrito, o analista desenha um prottipo para o mesmo,
que ajudar no s o analista a validar o que foi escrito, como
o cliente para que entenda melhor a soluo apresentada. As
Figuras 2, 3 e 4 apresentam os prottipos para o caso de uso
Manter Produto. Repare que um caso de uso no precisa estar
relacionado a somente uma tela, da mesma forma que uma
tela pode conter mais de um caso de uso associado a ela. Um
prottipo pode ser desenhado em qualquer ferramenta, at
mesmo desenhado mo (o que, profissionalmente, no
muito recomendvel).
Repare que os itens 1 e 2 do cenrio principal so refletidos
no prottipo (1) Figura 2. Nessa tela (ou rascunho de tela)
apresentada a consulta de produtos descrita no item 1, exatamente com os campos citados no caso de uso. Esse sincronismo
importante. Imagine o quanto confuso poderia ficar um
programador que lesse no caso de uso a exigncia de exibir
nome, detalhes e fabricante no resultado da pesquisa, e ao se
deparar com o prottipo, encontrasse tambm o campo de cor.
Lembre-se que isso um documento e precisa ser validado com
o cliente. Assim, se ele aprovar esses campos, ento o produto
final tem que refletir essa aprovao.
Acima da grid de produtos aparece uma rea para os critrios de pesquisa, de acordo com o que descrito no item 1.1.
As regras de pesquisa (explicitadas no cenrio alternativo),
nesse caso, no so visveis no prottipo, mas so sugeridas,
pois repare que o exemplo determina caderno brochura 1/4,
e o resultado localiza os produtos com a palavra caderno
brochura no nome do produto e 1/4 em detalhes. O item 2 do
cenrio principal informa que o sistema habilita algumas
opes ao usurio. Essa visualizao vista na rea de cima
da tela do prottipo (1).
D
s
Escrevendo os cenrios dos casos de uso
J o prottipo (Figura 3) apresenta a tela que ser utilizada para as opes de Incluso e Alterao. Repare
que o prprio caso de uso, no item 3, unifica esse cadastro,
simplificando a edio. Contudo, tudo o que particular a
cada opo citado explicitamente, como o caso de exibio
do cdigo do produto que s acontece quando da opo de
Alterao. Os itens 3.1 a 3.5 determinam a ao do sistema antes que a rotina comece a ser operada pelo usurio.
Quando o usurio acessa uma tela dessas de cadastro, as
combos de cores, fabricantes, unidades de venda e tipos
de produto j devem vir preenchidas com o que j existe
cadastrado no sistema.
O prottipo da Figura 4 apresenta a tela que ser utilizada
para a opo de Incluso por variao de produto e Alterao, se essa pertencer a um produto que seja variao.
Considerando o mesmo princpio que o Manter Produto, s
que de uma forma mais simples, so escritos os casos de uso
Manter Fabricante, Manter Tipo de Produto, Manter Fornecedor,
Manter Unidade de Venda, Manter Cor e Manter Vendedor, que
tm por objetivo apenas o cadastramento do nome, sendo
o cdigo apenas uma chave interna que no interessar ao
usurio final, que ir trabalhar apenas com o nome.
Assim, veremos na Listagem 2 o caso de uso Registrar Entrada em Estoque. O objetivo desse caso de uso dar entrada
nas compras efetuadas pela Papelaria. A partir de cada compra inserida, o estoque atualizado e os preos de venda so
disponibilizados. Esse caso de uso faz uma chamada a outro
caso de uso, responsvel apenas pela consulta de produtos e
preos. Esse caso de uso usado em outros lugares, e por este
motivo para que haja reutilizao de suas funcionalidades, o
relacionamento com ele feito pelo esteretipo de incluso.
Os cenrios do caso de uso Consultar Produtos e Preos podem ser vistos na Listagem 3. Repare que esse caso de uso
acessvel por vrios atores, e todos eles so relacionados
na seo correspondente. Para que no haja sobrecarga de
nomes durante a escrita do caso de uso, sempre uma boa
prtica substituir o nome do ator (durante a descrio do
cenrio) pelo termo genrico usurio.
A Figura 5 apresentar o prottipo do caso de uso Registrar
Entrada em Estoque, enquanto que a Figura 6 apresentar o
prottipo do caso de uso Consultar Produtos e Preos.
edio
ta
A partir da lista de casos de uso, j podemos represent-la

no Diagrama de Casos de Uso, conforme demonstrado na
Figura 1.
Documento de Requisitos
Essencial ao Desenvolvimento de Software

Apresenta o documento de requisitos de software,
destacando-o como um dos principais documentos
pertinentes ao processo de desenvolvimento de
software e ilustrando como ele deve ser elaborado.
Para que serve?
Antonio Mendes da Silva Filho

antoniom.silvafilho@gmail.com
Professor e consultor em rea de tecnologia

da informao e comunicao com mais de
20 anos de experincia profissional, autor do
livros Arquitetura de Software e Programando com XML, ambos pela Editora Campus/Elsevier, tem mais de 30 artigos publicados em
eventos nacionais e internacionais, colunista
para Cincia e Tecnologia pela Revista Espao
Acadmico com mais de 80 artigos publicados,
tendo feitos palestras em eventos nacionais e
exterior. Foi Professor Visitante da University
of Texas at Dallas e da University of Ottawa.
Formado em Engenharia Eltrica pela Universidade de Pernambuco, com Mestrado em
Engenharia Eltrica pela Universidade Federal
da Paraba (Campina Grande), Mestrado em
Engenharia da Computao pela University of
Waterloo e Doutor em Cincia da Computao
pela Univesidade Federal de Pernambuco.
24
m engenheiro de software um
profissional que deve ter a habilidade de antecipar e gerenciar
mudanas de requisitos de um produto
de software. Alm disso, ele precisa saber
se expressar e comunicar-se bem a fim
de capturar e registrar adequadamente
o documento de requisitos. Os principais problemas no desenvolvimento de
um sistema de software decorrem do
entendimento errado entre engenheiro
de software (produtor), responsvel em
apresentar o documento de requisitos, e
usurio (consumidor). Um documento
de requisitos de software precisa ser
claro, consistente e completo, porque
esse documento servir de referncia
aos desenvolvedores, gerente de projeto,
Engenharia de Software Magazine - Documento de Requisitos
Informar o leitor sobre quais elementos considerar

quando da elaborao de um documento de requisitos, levando em considerao o pblico alvo do
documento que engloba cliente, desenvolvedores
e gerentes, dentre outros.

Durante o desenvolvimento de um sistema de
software, no qual h a necessidade de elaborar o
documento descrevendo o conjunto de requisitos
do sistema de modo a informar tanto equipe de
projeto quanto cliente, o que ser implementado.
engenheiros de software (responsveis

pelos testes e manuteno do sistema),
alm de servir de base para definir o
escopo das funcionalidades a serem
registradas num contrato. Perceba que
os requisitos compreendem o cerne de
qualquer produto e mudanas sobre eles
Engen haria de Requisitos
podem ocorrer ao longo do ciclo de vida de um software. Este

artigo trata da importncia do documento de requisitos de
software e exemplifica como ele pode ser elaborado.
Requisitos de Software
Desenvolver um sistema de software requer um processo, o
qual informa um conjunto de atividades a serem realizadas,
quem as executam, quais artefatos de entrada so necessrios
e quais artefatos de sada so produzidos. Nesse sentido, detectar erros ou quaisquer outros problemas como, por exemplo,
inconsistncia e falta de clareza de suma importncia de
modo a tornar o processo mais efetivo sob o ponto de vista
de custo. Adwicionalmente, envolver o usurio no processo
determinante para o sucesso do produto e do processo. Dentro
deste contexto, entender adequadamente o requisito essencial
e essa tarefa do engenheiro de software. Um requisito compreende uma caracterstica ou funcionalidade que o sistema
deve possuir ou uma restrio que deve satisfazer para atender
uma necessidade do usurio. Dessa forma, o engenheiro de
software, desempenhando o papel de engenheiro de requisitos,
deve executar duas atividades essenciais para a elaborao do
documento de requisitos:
Elicitao de requisitos atividade na qual os requisitos do
sistema a ser desenvolvido so levantados;
Anlise de requisitos atividade na qual os requisitos so
analisados e confirmados pelos principais interessados do
projeto (isto , os stakeholders) que incluem cliente, usurio
final e gerente de projetos, dentre outros.
Considera-se ainda que a elicitao de requisitos objetiva
definir caractersticas do sistema sob a perspectiva do cliente,
enquanto que a anlise de requisitos visa obter a especificao
de requisitos, do ponto de vista tcnico, conforme entendimento dos desenvolvedores.
Durante a realizao destas atividades, o engenheiro de
software est preocupado em levantar, entender, analisar
e, por fim, documentar os requisitos. Para tanto, ele deve
concentrar-se nas caractersticas do sistema e atributos de
qualidade, e no em como obt-los. Aqui, preciso identificar
quais requisitos fazem parte ou no do escopo do sistema a
ser desenvolvido, ou em outras palavras, entender a interface
do sistema considerado e o ambiente externo.
importante ressaltar a necessidade de definir o limite, ou
tambm denominado escopo do sistema, a fim de tratar os
requisitos funcionais e no funcionais do sistema. Alm disso,
quando da elaborao do documento de requisitos, o engenheiro de software deve levar em considerao os diferentes
pontos de vistas dos stakeholders de modo que o documento
resultante possa comunicar adequadamente o conjunto de
requisitos do sistema a ser construdo.
O documento de requisitos delimita o escopo do conjunto
de funcionalidades que um sistema deve prover, bem como
descreve os atributos de qualidade que devem ser suportados.
Este documento deve ser elaborado de maneira precisa,

completa, consistente e, principalmente, compreensvel aos
stakeholders (isto , os principais interessados no sistema).
Note que o documento de requisitos ser lido por vrias pessoas interessadas no projeto como, por exemplo, cliente, gerente
de projeto, engenheiro de testes e programadores, e, portanto,
precisa comunicar com clareza os requisitos do sistema. Dessa
forma, tem-se que um documento de requisitos:
elaborado pelo engenheiro de software e compreende o
conjunto de requisitos do sistema a ser desenvolvido;
Deve ser analisado e confirmado pelos stakeholders;
Integra e relaciona um conjunto de perspectivas dos interessados do projeto;
Itens de um
1. Introduo
2. Requisitos Funcionais
3. Requisitos No-Funcionais
4. Escopo No-Contemplado
5. Documentao Complementar
6. Apndice
Contedo
Contm uma descrio dos objetivos do documento, o pblico
ao qual ele se destina e, em linhas gerais, o propsito e escopo
do projeto a ser desenvolvido. Pode adicionalmente conter
termos e abreviaes usadas, tipos de prioridades atribudas aos
requisitos, alm de informar como o documento deve evoluir.
Esta seo descreve, de maneira sumarizada, as principais
funcionalidades que o sistema de software ir realizar.Por exemplo,
num sistema de biblioteca,esta seo deveria conter uma descrio
das funcionalidades de autenticao de usurio e controle de
acesso. Observe que o sumrio das funcionalidades de um sistema
se faz necessrio para permitir o entendimento das funcionalidades
do sistema pelos diversos stakeholders. O engenheiro de software
deve organizar o conjunto de funcionalidades do sistema de
modo a torn-las mais compreensveis aos clientes e demais
stakeholders. Vale ainda ressaltar que o documento de requisitos
pode ser complementado por outro documento como, por
exemplo, especificaes de casos de uso.
Apresenta-se uma descrio geral de outros requisitos do
produto que limitam opes de desenvolvimento do sistema.
Isto inclui a descrio de requisitos de segurana, confiabilidade,
timeout de sesso de usurio, usabilidade, dentre outros.
Esta seo considera os requisitos do produto, do processo, da
interface grfica e da plataforma tecnolgica empregada.
Contm descrio das funcionalidades no contempladas no
escopo do sistema a ser desenvolvido. Outra denominao
dada a esta seo escopo negativo. Isto visa garantir s
partes interessadas no sistema (isto , cliente e equipe de
desenvolvimento) quais funcionalidades fazem parte ou no
do conjunto a ser implementado.
Exemplos desses documentos compreendem atas de reunies
nas quais ocorrero levantamento e validao de requisitos,
bem como o plano de projeto.
Trata-se de uma seo que pode conter, por exemplo,
levantamento de perfil de usurios do sistema a ser
desenvolvido e descrio do problema a ser automatizado pelo
sistema de software. importante observar que o apndice
no parte do documento de requisitos e serve apenas como
informao de apoio para os leitores do documento.
Tabela 1 Relao de itens de um documento de requisitos.
25
1. Introduo
Este documento descreve um sistema que prover
notcias e contedo online, denominado de Sistema
Exemplo, a ser desenvolvido para a Empresa XYZ. Seu
propsito prover notcias sobre os mais variados contedos, permitindo acesso integral apenas aos usurios
leitores cadastrados no sistema.
Viso geral do documento
Esta introduo fornece as informaes necessrias
para utilizar este documento, explicitando seus objetivos e as convenes que foram adotadas no texto. As
demais sees apresentam a especificao do sistema
Exemplo e esto organizadas como descrito abaixo.
Requisitos funcionais: compreende o conjunto de
requisitos funcionais do sistema a ser desenvolvido,
descrevendo suas prioridades.
Requisitos no funcionais: contm os requisitos no
funcionais do sistema a ser desenvolvido, divididos em requisitos de produto, processo e plataforma tecnolgica.
Escopo no contemplado: descreve as funcionalidades que so relacionadas com o sistema, mas que no
fazem parte do escopo do mesmo e, portanto, no sero
implementadas.
Documentao complementar: compreende um
conjunto de documentos complementares que contm
informaes relacionadas ao projeto.
Termos e convenes
Esta parte do documento explica os conceitos de termos importantes que sero citados no decorrer deste
documento, conforme descrito no quadro abaixo.
Termo
Requisitos funcionais
Requisitos no funcionais
Requisitos no tcnicos
Descrio
Requisitos de software que compe o sistema, descrevendo
aes que o sistema dever executar quando solicitado.
Requisitos de software que compem o sistema, descrevendo
atributos de qualidade que o sistema deve possuir, ou restries
que ele deve satisfazer.
Requisitos no relacionados ao software como, por exemplo,
material de divulgao do projeto (eventos, relatrios tcnicos e
outras publicaes). Esses requisitos esto fora do escopo deste
documento, podendo ser includos no Plano do Projeto.
Quadro 1. Exemplo da Seo 1 do Documento de Requisitos.
Prioridades dos requisitos

A atribuio de prioridade dos requisitos pode ser de trs
tipos: essencial, importante e desejvel. A prioridade dos
requisitos pode ser usada no gerenciamento do escopo do
projeto e na definio das prioridades para o desenvolvimento do sistema.
Essencial: requisito sem o qual o sistema no entra em
funcionamento. Requisitos essenciais so requisitos imprescindveis, devendo ser disponibilizados na implantao
do sistema.
Importante: requisito sem o qual o sistema entra em
funcionamento, mas de forma no satisfatria. Requisitos
importantes no impedem a implantao do sistema, mas
devem ser implementados o mais breve possvel.
Desejvel: requisito que, embora no implementado,
ainda permite o sistema funcionar de modo satisfatrio
sem comprometer as funcionalidades bsicas do sistema.
Requisito desejvel um requisito que pode ser entregue em
qualquer momento sem prejuzo para os servios oferecidos
pelo sistema.
Serve como mecanismo de comunicao para os stakeholders

(i.e. as partes interessadas do projeto);
Captura e documenta os requisitos do projeto e serve de
referncia para testes, manuteno e evoluo do sistema.
O documento de requisitos de um projeto tem o objetivo de
documentar o escopo do sistema a ser desenvolvido. Nesse
sentido, o documento de requisitos deve conter:
Introduo e viso geral do documento
Descrio de requisitos funcionais
Descrio de requisitos no-funcionais
Escopo no contemplado (de funcionalidades)
Documentao de apoio
importante perceber a importncia do documento de
requisitos como determinante para o sucesso de um projeto.
Ele identifica quais funcionalidades fazem parte ou no do
escopo do sistema. A seo seguinte apresenta um exemplo
26
de um documento de projeto ilustrando e complementando

os pontos destacados acima.
Exemplificando o Documento de Requisitos

O engenheiro de software, ao elaborar o documento de requisitos, deve buscar um compromisso de comunicar bem as
funcionalidades do sistema a ser desenvolvido e da definio
em detalhes com clareza e consistncia para os programadores e engenheiros de testes (responsveis pela implementao do sistema e elaborao e execuo de plano de testes,
respectivamente).
A Tabela 1 apresenta uma relao dos itens consideradas imprescindveis em um documento de requisitos. A relao de itens
destacados na Tabela 1 no pressupe a inteno de ser completo,
mas de apontar os itens considerados como obrigatrios num
documento de requisitos. Cabe destacar que os itens sugeridos
para compor um documento de requisitos, conforme apresentado na Tabela 1, leva em considerao as recomendaes de
2. Requisitos Funcionais
2.1 Controle de Acesso
Esta seo apresenta a descrio das funcionalidades de
controle de acesso de usurios alm das funcionalidades
para superviso dos acessos ocorridos.
RF01 - Solicitar cadastro no servio de recomendao
Este requisito permite aos usurios solicitar Empresa
XYZ o seu cadastramento no Sistema Exemplo. Essas
solicitaes ficam pendentes de aceitao at que sejam
validadas e aprovadas por parte de um funcionrio da
Empresa XYZ.
Prioridade:
x Essencial
Importante
Desejvel
RF04 Autenticar usurio

Este requisito faz a autenticao do usurio atravs de seu
login e senha e, em seguida, exibe um menu de opes de
acordo com as funcionalidades permitidas ao usurio em
conformidade com seu perfil de acesso. Toda vez que o
usurio efetuar um login no sistema, dever ser registrada
a abertura de um log de acesso do usurio.
Prioridade:
Prioridade:
x Essencial
Importante
Desejvel
RF03 - Alterar senha de acesso

Este requisito permite ao usurio trocar sua senha de acesso ao sistema. Para efetivar a troca de senha, os seguintes
critrios de segurana sero verificados: tamanho mnimo
e mximo da senha, definio de perodo de validade da
senha e reuso de senhas anteriores. Estes critrios devero
ser definidos no banco de dados. A gerncia dos critrios de
segurana da senha dever ser controlada por um sistema
gerenciador de banco de dados (SGBD).
Prioridade:
x Essencial
Importante
Desejvel
Importante
Desejvel
RF05 Consultar permisses de acesso

Este requisito permite que um funcionrio da Empresa
XYZ consulte as permisses de acesso de usurios ao sistema, obtendo informao sobre o tipo de acesso e expirao
da permisso de acesso ao sistema.
Prioridade:
RF02 Registrar cadastro de usurio no servio de

recomendao
Este requisito permite que um funcionrio da Empresa
XYZ valide o cadastro e libere o acesso de um usurio ao
Sistema Exemplo efetuando o seu registro aps o usurio
confirmar leitura e aceitao (via Internet) do Termo de
Responsabilidade de Acesso e Uso do Sistema Exemplo.
x Essencial
Essencial
x Importante
Desejvel
RF06 Cancelar acesso de usurio

Este requisito permite que qualquer usurio autorizado
(cadastrado) cancele o acesso aos contedos do sistema.
Os dados dos usurios para cancelar o acesso ao sistema
devem estar definidos no banco de dados.
Prioridade:
Essencial
x Importante
Desejvel
2.2 Outros Servios

Esta seo descreve as funcionalidades para efetuar
alteraes nos cadastros de usurios, bem como alterao
cadastral de dependentes.
RF06 Alterar cadastro de usurio
Este requisito permite que um usurio possa alterar diretamente seus dados cadastrais no sistema Exemplo, bem
como fazer a incluso ou excluso de usurios dependentes
para acesso ao contedo do sistema.
Prioridade:
Essencial
Importante
Desejvel
documento padro IEEE-Std 830-1998 recomendado pelo IEEE

e referenciado no quadro de links deste artigo.
O contedo exato das sees que compem um documento de
requisitos, de um modo geral, varia de empresa para empresa.
As subsees, destacadas nos Quadros 1 a 5, ilustram o contedo que compe um documento de requisitos. O propsito do
sistema Exemplo, usado aqui apenas com fins ilustrativos,
similar ao de um sistema como o de portais de jornais e revistas e outros provedores de contedo que permitem o acesso a
contedo, como o portal UOL, apenas a clientes devidamente
cadastrados no sistema.
Note que o Quadro 1 apresenta uma viso geral do documento e identifica um subconjunto de termos e convenes que
pode caracterizar o projeto. Todo e qualquer termo, conveno
adotada ou abreviaes deveriam ser apresentadas nesta seo
a fim de comunicar s partes envolvidas e interessadas (i.e. os
stakeholders) o seu significado. Isto visa prover os stakeholders
com as denominaes corretas empregadas no projeto.
A seo seguintwe apresenta a segunda parte do documento
de requisitos que contm descrio dos Requisitos Funcionais
(RFs), conforme ilustrado no Quadro 2.
O Quadro 2 apresenta a descrio de um conjunto de
27
3. Requisitos No Funcionais
3.1 Requisitos do Produto
Esta seo apresenta a descrio do conjunto de requisitos do Sistema Exemplo para prover contedo para
usurios cadastrados.
RNF01 Segurana
O Sistema Exemplo da empresa XYZ deve dispor de
mecanismos de segurana para a autenticao de usurios e controle de acesso a contedos e funcionalidades
do sistema, garantindo o acesso apenas para usurios
cadastrados. O site dever utilizar protocolo HTTPS, com
uso de certificado digital, garantindo a autenticao do
servidor, bem como proteo e confidencialidade das
informaes em trnsito.
Prioridade:
x Essencial
Importante
3.2 Requisitos do Processo

Esta seo apresenta a descrio dos requisitos relativos ao processo utilizado no desenvolvimento do
sistema Exemplo.
RNF06 Arquitetura de software
A implementao do sistema Exemplo deve empregar
uma arquitetura de 3 (trs) camadas: apresentao,
negcio e dados.
Prioridade:
Importante
Desejvel
RNF03 Usabilidade
O sistema Exemplo deve prover o usurio com interface
simples e intuitiva, de fcil navegao para facilitar o uso
do mesmo por parte dos usurios.
Prioridade:
x Essencial
Importante
Desejvel
RNF04 Apresentao da interface grfica

O sistema Exemplo deve fazer uso, exclusivamente, da
lngua Portuguesa para todo e qualquer texto apresentado no portal de contedos e adicionalmente deve ser
executado no browser Internet Explorer, verso 6.0 ou
superior, com resoluo 800 x 600.
Prioridade:
x Essencial
Importante
Desejvel
RNF05 Ajuda online

O sistema Exemplo deve prover os usurios com Ajuda
online para orient-lo quanto ao acesso e uso das funcionalidades do sistema Exemplo.
Prioridade:
Essencial
x Importante
Desejvel
28
Desejvel
RNF07 Linguagem de programao adotada

A implementao do sistema Exemplo deve utilizar
a linguagem Java, adotando padro J2EE.
Prioridade:
x Essencial
Importante
Desejvel
RNF02 Senha criptografada

O sistema Exemplo dever prover o usurio com senha
criptografada. O sistema Exemplo deve fazer uso de um
algoritmo que no permita obter a senha criptografada.
Este mecanismo de criptografia dever ser implementado
pelo sistema gerenciador de banco de dados (SGBD).
Prioridade:
x Essencial
x Essencial
Importante
Desejvel
3.2 Requisitos de Tecnologia Adotada

Esta seo apresenta a descrio dos requisitos relativos s tecnologias adotadas no desenvolvimento do
sistema Exemplo.
RNF08 Disponibilidade
O portal de contedos do sistema Exemplo dever
estar disponvel aos usurios 24 horas por dia e 7 dias
por semana.
Prioridade:
x Essencial
Importante
Desejvel
RNF09 Banco de dados

A implementao do sistema Exemplo deve empregar
o SQL Server 2005 Enterprise Edition como servidor
de banco de dados.
Prioridade:
x Essencial
Importante
Desejvel
RNF10 Componentizao
Cada componente do sistema Exemplo deve ser um
JAR, os quais devero ser includos em um arquivo
WAR (centralizador). Os arquivos JAR ficaro em
projetos distintos.
Prioridade:
x Essencial
Importante
Desejvel
4. Escopo No Contemplado
Esta seo apresenta um conjunto de funcionalidades
e requisitos que no esto contemplados no escopo do
Sistema Exemplo.
4.1 Controle de acesso:
Realizao de bloqueio de acesso aos usuri os que possuam mensalidades em atraso junto empresa XYZ.
Cadastro (incluso, alterao, excluso) de tipos de usurios.
4.2 Outros servios

Atualizao de informaes do portal de contedos.
Mecanismo de FAQ e de busca aos contedos do
portal.
Atendimento a consultas atravs de e-mail.
4.3 Segurana
Definio das polticas de segurana necessrias
administrao do Sistema Exemplo.
5. Documentao Complementar
Esta seo apresenta documentao de apoio, referenciando um conjunto de outros documentos que
complementam e suportam as informaes contidas no
documento de requisitos.
Ata de Reunio Levantamento de Requisitos do Mdulo
A do Sistema Exemplo, 12/01/2009.
Ata de Reunio Levantamento de Requisitos do Mdulo B do Sistema Exemplo, 13/01/2009.

Ata de Reunio Levantamento de Requisitos do Mdulo C do Sistema Exemplo, 14/01/2009.
Ata de Reunio Validao de Requisitos do Sistema
Exemplo, 15/01/2009.
Plano de Projeto do Sistema Exemplo.
requisitos funcionais de um sistema Exemplo. Perceba que

o objetivo no foi de ser completo, mas o de ilustrar como a
seo que descreve os requisitos funcionais de um documento
de requisitos poderia ser elaborada. Note tambm que as
informaes apresentadas neste documento tm a inteno
de comunicar s partes envolvidas e interessadas o conjunto
de requisitos funcionais do sistema a ser desenvolvido.
A seo seguinte apresenta a terceira parte do documento
de requisitos que compreende a descrio dos Requisitos
No Funcionais (RNFs), conforme ilustrado no Quadro 3.
O Quadro 3 apresenta a descrio de um conjunto de requisitos no funcionais do sistema Exemplo. Vale ressaltar que
apenas alguns requisitos no funcionais so apresentados
para ilustrar como essa seo do documento de requisitos
poderia ser elaborada.
A seo seguinte apresenta a quarta parte do documento
de requisitos que descreve o escopo no contemplado, conforme ilustrado no Quadro 4.
O Quadro 4 apresenta a descrio de um conjunto de
funcionalidades e requisitos no contemplados na implementao do Sistema Exemplo. Finalmente, o Quadro 5
apresenta a quinta parte do documento de requisitos que
lista um conjunto de documentos complementares.
Portanto, o engenheiro de software deve ter em mente que

tanto cliente quanto gerente de negcios, gerente de projeto,
desenvolvedores e engenheiros de testes iro consultar as
informaes contidas nesse documento. Este artigo destacou
a relevncia desse documento de projeto e apresentou o
conjunto de sees que compem o documento de requisitos
ilustrando-o para um sistema exemplo.
Links
Writing a Software Requirements Document
http://www2.sims.berkeley.edu/courses/is208/s02/ReqsDoc.pdf
IEEE Standard 830-1998
http://standards.ieee.org/reading/ieee/std_public/description/se/830-1998_desc.html
Military Standard Defense System Software Development DOD-STD-2167
www.everyspec.com/DoD/DoD-STD/download.php?spec=DOD-STD-2167.000278.pdf
Software Documentation
http://en.wikipedia.org/wiki/Software_documentation
Requirements Engineering A Roadmap
http://www.cs.toronto.edu/~sme/papers/2000/ICSE2000.pdf
Requirements Engineering A Good Practice Guide
http://www.comp.lancs.ac.uk/computing/resources/re-gpg/

Feedback
eu
edio
ta
29
sobre e
s
Requisitos de software compreendem a essncia de

um produto, os quais definem as funcionalidades que o
sistema deve prover e restries que ele deve satisfazer.
Documentar bem os requisitos de software atividade de
suma importncia para um engenheiro de software que
deve levar em considerao o pblico diverso que far uso
desse documento.
D
s
Comentrios Finais
Gerncia de Reutilizao de Software

Josiane Brietzke Porto
josiane_brietzke@hotmail.com
Ps-graduada em Melhoria de Processos de

Software pela UFLA em 2008. Bacharel em Cincia da Computao pelo Unilasalle em 2005.
Autora de artigos na rea de qualidade de
software (ASSE 2005, WIS 2005, CLEI Eletronic
Journal, W2MPSBR, SBQS 2007, W6-MPS.BR
e Engenharia de Software Magazine). Experincia de mais de 5 anos na rea de TI atuando
em desenvolvimento de software e de mais de
4 anos na rea de qualidade e melhoria de processos. Implementadora MR-MPS desde 2004,
Certified Quality Improvement Associate (CQIA)
desde 2006 e integrante desde 2008 do Comit
Setorial de Informtica - Programa Qualidade
RS. Atua desde 2005 na Qualit Informtica em
projetos de melhoria de processos baseados em
MPS.BR e PGQP.
Isabel Albertuni
ialbertuni@gmail.com
Graduada em Anlise de Sistemas pela

FARGS em 2008. Autora de artigos na rea
de qualidade de software (SBQS 2007, W6MPS.BR e Engenharia de Software Magazine). Experincia de mais de 6 anos na rea de
TI atuando em desenvolvimento de software
e de 3 anos na rea de qualidade e melhoria de processos. Integrante desde 2008 do
Comit Setorial de Informtica - Programa
Qualidade RS. Atua desde 2006 na Qualit
Informtica em projetos de melhoria de processos baseados em MPS.BR e PGQP.
30
Neste artigo apresenta-se o processo de Gerncia de Reutilizao de Software, sua contribuio para as organizaes intensivas em
software, alm de benefcios e dificuldades
na implementao de suas prticas.
Para que serve?
ais recentemente temos um

cenrio de demanda por uma
melhor qualidade de software. Demanda porque ter uma qualidade
adequada no mais um diferencial de
negcio, mas sim uma condio bsica
para negcios. Qualidade de software
em um sentido mais amplo, incluindo
uma composio de fatores como os
prazos menores, custos menores, menor
quantidade de defeitos, menos insatisfaes de uma maneira geral, maior
qualidade dos produtos desenvolvidos,
maior previsibilidade, maior produtividade, maior competitividade e melhores
resultados de negcio [Salviano 2006a].
Segundo Salviano (2006a), a melhoria
de processo de software tem mostrado na
Engenharia de Software Magazine - Gerncia de Reutilizao de Software
Serve para esclarecimento e melhor entendimento do tema por profissionais da rea de

qualidade e pelas organizaes que pretendem implementar Gerncia de Reutilizao
de Software.

A adoo de prticas de reutilizao de software surge como uma maneira da organizao melhorar a produtividade das equipes, reduzir custos e melhorar a qualidade
de seus produtos.
prtica ser uma abordagem vivel, eficaz

e eficiente para a necessria melhoria das
organizaes intensivas em software. A
comunidade tem relatado vrios casos de
sucesso como, por exemplo, Herbsleb et
al. [1994], DACS [1999] e Card [2002].
Processo
A melhoria de processo de software baseada em modelos (em

ingls, model based software process improvement) pode ser definida
como: uma abordagem para melhoria das organizaes intensivas
em software, baseada em modelos de capacidade de processo, que
orienta aes para alterao dos processos utilizados para aquisio, fornecimento, desenvolvimento, manuteno e/ou suporte
de sistemas de software, com o objetivo de estabelecer processos
que satisfaam de forma mais eficiente e eficaz os objetivos e
necessidades de negcio da organizao [Salviano 2006a].
Diante deste cenrio e utilizando a abordagem de melhoria
de processo de software, a adoo de prticas de reutilizao
de software surge como uma maneira da organizao melhorar a produtividade das equipes, reduzir custos e melhorar a
qualidade de seus produtos.
Neste sentido, o processo Gerncia de Reutilizao de
Software tem como objetivo definir procedimentos tanto
administrativos quanto tcnicos para utilizao de ativos reutilizveis em uma organizao, estabelecendo e controlando
uma biblioteca para o armazenamento e recuperao destes
ativos [IEEE, 2004].
Neste artigo apresenta-se o processo de Gerncia de Reutilizao de Software, sua contribuio para as organizaes
intensivas em software, alm de benefcios e dificuldades
na implementao de suas prticas. Para isso, o artigo est
organizado da seguinte forma: a seo 2 apresenta uma viso
geral sobre a Gerncia de Reutilizao de Software; a seo 3
descreve este processo no MPS.BR, nvel de maturidade Parcialmente Definido (E); a seo 4 trata da implementao das
prticas deste processo numa organizao; e por fim, a seo
5 trata das consideraes finais.
Gerncia de Reutilizao de Software

Conforme Werner (2007), a reutilizao inerente ao processo
de soluo de problemas utilizado pelos seres humanos. Na
medida em que solues so encontradas, estas so utilizadas em problemas similares e nossa capacidade de abstrao
garante a adaptao necessria ao novo contexto. O problema, portanto, no a falta de reutilizao na Engenharia de
Software, mas a falta de uma sistemtica ampla e formal para
realiz-la.
Segundo Krueger (1992), reutilizao de software a disciplina responsvel pela criao de sistemas de software a
partir de software preexistente. Reutilizao de software
consiste no processo de reaproveitar artefatos e conhecimentos de softwares j existentes na organizao para construir
novos, reduzindo tempo e custo e melhorando a qualidade
destes produtos [Porto, 2008]. Por isso, mecanismos para a
manuteno e recuperao destes ativos devem ser implementados, assim como uma biblioteca de ativos de processo,
no qual a recuperao de ativos utilizados em outros projetos
possam ser adaptados (quando necessrio) e reutilizados em
novos projetos [SEI, 2006].
Atravs de reutilizao de software, alguns benefcios podem
ser obtidos como [Werner 2007] [CRUISE 2007]:
melhores ndices de produtividade;
produtos de melhor qualidade, mais confiveis, consistentes

e padronizados;
reduo dos custos e esforo envolvidos no desenvolvimento
e manuteno de software;
maior flexibilidade na estrutura do software produzido,
facilitando sua manuteno e evoluo;
tamanho de equipe menor, levando a uma melhor comunicao e maior produtividade, entre outros.
Por outro lado, existem algumas dificuldades relacionadas
[Werner 2007] [CRUISE 2007]:
identificao, recuperao e modificao de artefatos
reutilizveis;
compreenso dos artefatos recuperados;
qualidade de artefatos reutilizveis;
composio de aplicaes a partir de componentes;
barreiras psicolgicas, legais e econmicas;
necessidade da criao de incentivos reutilizao;
falta de apoio da alta direo;
gerenciamento de projetos com reutilizao de software;
estrutura organizacional inadequada, entre outros.
Conforme relatam Werner (2007) e CRUISE (2007), atualmente existem vrias iniciativas nacionais e internacionais
na rea de reutilizao de software a fim de investigar,
desenvolver e colocar em prtica esta tcnica.
Segundo Porto (2008), na indstria de software gacha e
mais especificamente, no contexto do projeto Cooperativa
MPS.BR - SOFTSUL, os resultados de uma pesquisa conduzida com empresas cooperadas demonstram que as prticas
de reutilizao de software adotadas ainda so bem iniciais
e desassociadas de um programa de reutilizao, polticas
de incentivo ou estratgias da organizao.
Conforme Becker (2008), as prticas de reuso adotadas com
maior freqncia nos projetos das empresas desta pesquisa so:
frameworks de mercado e desenvolvidos para uso prprio;
padres de projeto;
adaptao de artefatos a partir de templates ou artefatos
criados em projetos semelhantes;
polticas de incentivos no so adotadas, porm existem
iniciativas e prticas isoladas de integrantes das equipes;
componentes prontos e outros desenvolvidos para reuso, sem
adotar um repositrio para compartilhamento;
adoo de knowledge base com componentes reusveis, porm
pouco disseminada;
tcnicas e experincias de reuso so divulgadas em ferramenta wiki;
lies aprendidas em projetos de domnios semelhantes.
Conforme Porto (2008), este cenrio ainda apresenta organizaes que no esto preparadas para adotar a reutilizao de
software de uma maneira sistemtica, necessitando de disseminao de conhecimento e de pesquisas como, por exemplo,
das instituies nacionais COPPE/UFRJ (2008), RISE (2008) e
COMPOSE (2008).
31
Segundo CRUISE (2007), processos de software se referem a

todas as atividades necessrias para produzir e gerenciar software, enquanto isto, processos de reutilizao de software so
um subconjunto de atividades necessrias para desenvolver
e reutilizar ativos.
Conforme Werner (2007), o processo de Gerncia de Reutilizao est dividido nos seguintes sub-processos:
Planejamento de Reutilizao: propsito de definir uma
estratgia de reutilizao e um plano para implementao
dentro da empresa;
Criao de Artefatos: propsito de produzir software e
produtos associados para a reutilizao (desenvolvimento
para reutilizao);
Gerncia de Artefatos: propsito de coletar, avaliar, descrever
e organizar artefatos reutilizveis para garantir sua disponibilizao aos processos de criao e utilizao;
Utilizao de Artefatos: propsito de compor sistemas a partir
de artefatos reutilizveis (desenvolvimento com reutilizao).
A seguir, na Tabela 1, um resumo apresentado a fim de demonstrar o tratamento adotado pelas normas e modelos de qualidade para os processos de reutilizao de software. A partir deste
resumo, se observa certa similaridade e conservao no contedo
ISO/IEC 15504-5:
2006
[Salviano 2006a]
REU.1 Gerncia de Ativos Reusveis: propsito de gerenciar a vida de

ativos reusveis da concepo at a aposentadoria;
REU.2 Gerncia de Programa de Reuso: propsito de planejar,
estabelecer, gerenciar, controlar e monitorar um programa de reuso de uma
organizao e explorar de forma sistemtica oportunidades de reuso;
REU.3 Engenharia de Domnio: propsito de desenvolver e manter
modelos de domnio, arquiteturas de domnio e artefatos para o domnio.
Gesto de Ativos: propsito de gerenciar a vida dos ativos reutilizveis,
desde sua concepo at a sua descontinuao;
Gesto de Programa de Reuso: propsito de planejar, estabelecer,

NBR ISO/IEC 12207
gerenciar, controlar e monitorar um programa de reuso da organizao e,
[Machado 2006]
sistematicamente, explorar as oportunidades de reuso;
Engenharia de Domnio: propsito de desenvolver e manter modelos,
arquiteturas e ativos de domnio.
Integrao da Reutilizao nos Processos Primrios do Ciclo de
Vida: propsito de tratar como a reutilizao impacta nos processos de
aquisio, fornecimento, desenvolvimento, operao e manuteno;
IEEE 1517-2004
[Werner 2007]
Suporte Reutilizao: propsito de gerenciar os ativos;

Ciclo de Vida Organizacional da Reutilizao: propsito de
administrar o programa de reutilizao;
Reutilizao entre Projetos: propsito de tratar a engenharia de domnio.
Gerncia de Reutilizao (GRU): propsito de gerenciar o ciclo de vida
dos ativos reutilizveis;
MR-MPS
[MPS.BR 2007c]
Desenvolvimento para Reutilizao (DRU): propsito de identificar

oportunidades de reutilizao sistemtica na organizao e, se possvel,
desenvolver um programa de reutilizao para desenvolver ativos a partir
de engenharia de domnio de aplicao.
Tabela 1. Reutilizao de Software nas Normas e Modelos [Porto, 2008]
32
dos objetivos principais destes processos [Porto, 2008].

Na prxima seo so apresentados com maior detalhamento
o programa MPS.BR e seus componentes (entre eles, o MRMPS) e, na seqncia, uma viso geral deste processo no nvel
de maturidade E.
Gerncia de Reutilizao no MPS.BR Nvel E

O programa MPS.BR foi criado em 2003 e seu objetivo a
melhoria de processo do software brasileiro. Este programa
est sob a coordenao da Associao para Promoo da
Excelncia do Software Brasileiro (SOFTEX), com apoio do
Ministrio da Cincia e Tecnologia (MCT), da Financiadora
de Estudos e Projetos (FINEP) e do Banco Interamericano de
Desenvolvimento (BID).
O MPS.BR baseia-se em conceitos de maturidade e capacidade de processo para a avaliao e melhoria da qualidade e
produtividade de produtos de software e servios correlatos.
Este programa est estruturado nos seguintes componentes:
Modelo de Referncia (MR-MPS), Mtodo de Avaliao (MAMPS) e Modelo e Negcio (MN-MPS) [MPS.BR 2007c].
O MR-MPS possui sete nveis de maturidade seqenciais
e acumulativos, que so: A (Em Otimizao), B (Gerenciado
Quantitativamente), C (Definido), D (Largamente Definido),
E (Parcialmente Definido), F (Gerenciado) e G (Parcialmente
Gerenciado).
O nvel de maturidade E tem como foco principal a padronizao dos processos da organizao, por meio da definio
de processos padro. Estes devem ser definidos a partir dos
processos e melhores prticas j existentes na organizao,
o que constitui o primeiro passo de uma contnua avaliao
e melhoria dos processos. A definio de processos padro
inclui, alm dos processos do nvel E, todos os processos que
pertencem aos nveis G e F do MR-MPS [MPS.BR 2007d].
Neste nvel de maturidade tambm so exigidos o estabelecimento de uma biblioteca de ativos e de um repositrio de
medidas. E, ainda, a organizao deve tambm neste nvel
implementar uma estratgia de gerenciamento de ativos reutilizveis para aumentar a eficincia e a eficcia dos processos de
software da organizao por meio da reutilizao de produtos
de trabalho projetados para utilizao em mltiplos contextos
[MPS.BR 2007d].
Este nvel formado pelos processos de Gerncia de Projetos (GPR Evoluo), Avaliao e Melhoria do Processo
Organizacional (AMP), Definio do Processo Organizacional (DFP), Gerncia de Recursos Humanos (GRH) e Gerncia
de Reutilizao (GRU), alm dos outros seis processos dos
nveis G e F. No que se refere a atributos de processo,
formado pelos atributos AP 3.1 (O processo definido) e
AP 3.2 (O processo est implementado), alm dos outros
trs atributos de processo dos nveis G e F, conforme pode
ser visto na Tabela 2.
O processo GRU abordado com maior nvel de detalhamento nesta seo em funo de ser objeto deste artigo. Para
maiores detalhes sobre o nvel E e demais processos, consulte
MPS.BR (2007d).
Processo
O processo GRU tem como objetivo definir procedimentos

tanto administrativos quanto tcnicos para utilizao de ativos
reutilizveis em uma organizao, estabelecendo e controlando
uma biblioteca para o armazenamento e recuperao destes
ativos. Entende-se como ativo reutilizvel qualquer artefato
relacionado a software que esteja preparado, isto , empacotado de maneira prpria a ser reutilizado pelos processos da
organizao [MPS.BR 2007d].
De acordo com MPS.BR (2007d), para que estes ativos possam ser usados de maneira efetiva, necessrio estabelecer
um procedimento sistemtico de armazenamento, recuperao e divulgao. Assim, o processo se apresenta como
instrumento a ser aplicado neste contexto, promovendo
mecanismos para estabelecimento e manuteno de uma
infra-estrutura que torne vivel a reutilizao de ativos em
uma organizao.
Conforme definido na seo anterior, o propsito de GRU no
MR-MPS gerenciar o ciclo de vida dos ativos reutilizveis.
Isto , o modo como os ativos devem ser usados na organizao
no cabe GRU. Seu objetivo corresponde em prticas para
viabilizar a seleo e a recuperao de ativos.
A seguir, so listados os resultados esperados de GRU que
precisam ser observados e implementados para se obter sucesso no objetivo do processo [MPS.BR 2007d]:
GRU1: Uma estratgia de gerenciamento de ativos documentada, contemplando a definio de ativo reutilizvel,
alm dos critrios para aceitao, certificao, classificao,
descontinuidade e avaliao de ativos reutilizveis;
GRU2: Um mecanismo de armazenamento e recuperao
de ativos reutilizveis implantado;
GRU3: (Nos nveis E e D) Os dados de utilizao dos ativos
reutilizveis so registrados;
GRU4: Os ativos reutilizveis so periodicamente mantidos,
segundo os critrios definidos, e suas modificaes so controladas ao longo do seu ciclo de vida.
GRU5: Os usurios de ativos reutilizveis so notificados
sobre problemas detectados, modificaes realizadas, novas
verses disponibilizadas e descontinuidade de ativos.
Na Tabela 2 so apresentados os atributos de processo, ou
seja, as caractersticas mensurveis da capacidade do processo
que tambm precisam ser observadas e implementadas para
GRU no nvel de maturidade E.
A seo seguinte prope uma forma de GRU ser implementada em organizaes intensivas em software. Esta forma
pretende servir apenas como referncia, pois este processo
deve ser implementado de acordo com as caractersticas e
necessidades de negcio de cada organizao.
Implementando o processo de Gerncia de Reutilizao

de Software
Uma forma de implementar processos na organizao por
meio do modelo IDEAL, desenvolvido pelo Software Enginnering Institute (SEI) afim de apoiar na melhoria de processo de
software [SEI, 2008].
Atributos de Processo (AP) / Resultados Esperados (RAP)

RAP1.1 O processo executado.
RAP 1. O processo atinge seus resultados definidos.
AP2.1 O processo gerenciado.
RAP 2. Existe uma poltica organizacional estabelecida e mantida para o processo.
RAP 3. A execuo do processo planejada.
RAP 4 (A partir do Nvel F). Medidas so planejadas e coletadas para monitorao da execuo
do processo.
RAP 5. Os recursos necessrios para a execuo do processo so identificados e disponibilizados.
RAP 6. As pessoas que executam o processo so competentes em termos de formao, treinamento
e experincia.
RAP 7. A comunicao entre as partes interessadas no processo gerenciada de forma a garantir
o seu envolvimento no projeto.
RAP 8. Mtodos adequados para monitorar a eficcia e adequao do processo so determinados.
RAP 9 (A partir do Nvel F) A aderncia dos processos executados s descries de processo, padres
e procedimentos avaliada objetivamente e so tratadas as no conformidades.
AP 2.2 Os produtos de trabalho do processo so gerenciados.
RAP 10. Requisitos para documentao e controle dos produtos de trabalho so estabelecidos.
RAP 11. Os produtos de trabalho so documentados e colocados em nveis apropriados de
controle.
RAP 12. Os produtos de trabalho so avaliados objetivamente com relao aos padres,
procedimentos e requisitos aplicveis e so tratadas as no conformidades.
AP 3.1 O processo definido
RAP 13. Um processo padro definido, incluindo diretrizes para sua adaptao para o processo
definido.
RAP 14. A seqncia e interao do processo padro com outros processos so determinadas.
AP3.2 O processo est implementado
RAP 15. Dados apropriados so coletados e analisados, constituindo uma base para o entendimento
do comportamento do processo, para demonstrar a adequao e a eficcia do processo, e avaliar
onde pode ser feita a melhoria contnua do processo.
Tabela 2. Atributos de Processo Aplicveis GRU [MPS.BR 2007d]
Suas fases correspondem a:

Initiating (Incio): identificao da necessidade com
estmulo melhoria, definio de escopo, patrocnio,
intra-estrutura;
Diagnosing (Diagnstico): consiste em avaliar o status atual
e identificar as prticas correntes, identificao de pontos
fracos, pontos fortes e oportunidades de melhorias;
Establishing (Estabelecimento): planejamento das aes a
serem realizadas, definio das prioridades, alocao de
equipes envolvidas;
Acting (Ao): por em prtica o planejamento e aes necessrias para o desenvolvimento e implantao do processo
e melhorias;
Learning (Aprendizado): documentao e anlise das
aes.
Apresentamos na Tabela 3 uma forma de implementao
do processo de GRU,
Este modelo pode ser realizado de forma cclica, ou seja,
quando identificadas melhorias, pode-se retornar a atividade de diagnstico ou ento direto para etapa de ao,
33
Implantao de GRU com base no Modelo IDEAL
Incio
Diagnstico
Estabelecimento
Ao
Aprendizado
Identificar a necessidade de aplicao do processo de GRU. Uma forma

de realizar este levantamento identificar a relevncia da aplicao do
processo no contexto atual, verificando o grau (Baixo, Mdio ou Alto) da
Importncia da aplicao e o Risco com relao a manter as prticas atuais
da empresa. Nesta etapa tambm ser definido o escopo em que ser
desenvolvido, neste caso, a aplicao do processo de GRU.
Identificar a situao atual com base nas prticas existentes na
organizao, que atendam ao processo de GRU. Uma forma prtica para
este levantamento identificar os pontos fracos, pontos fortes e melhorias
de acordo com os resultados esperados de GRU (GRU1 a GRU5).
Definir metas, cronograma, plano de ao para atender as necessidades
de melhoria, de acordo com os pontos levantados no diagnstico para
atendimento completo dos resultados esperados. Esta etapa consiste
no planejamento da implantao do processo, assim como ocorre no
planejamento de um projeto de software, identificar os recursos necessrios
(infra-estrutura, recursos humanos, ferramentas, financeiro, etc),
treinamentos (se necessrio), aplicao em projetos piloto e envolvidos.
Consiste na realizao do planejado, executar as atividades necessrias
para a implementao do processo de GRU. Por exemplo: reunies para
definio do processo, documentao do processo, prover treinamentos
para as equipes pilotos, aplicao do piloto.
Nesta etapa, so verificadas e analisadas as aes realizadas para identificar
melhorias e aplic-las. Para isto, indicadores podem ser definidos para melhor
controle, bem como aplicao de auditorias, a partir delas possvel identificar
melhorias tanto no processo definido quanto na aplicao do mesmo, sendo
possvel melhor capacitao dos envolvidos na realizao do processo.
Tabela 3. Exemplo de Ciclo de Implementao e Melhoria do Processo de GRU
at a adequao do processo de forma que atenda todos os

resultados esperados do processo de GRU.
A definio do processo de GRU pode ser feita com
base na notao ETVX (Entry criteria, Task, Verification,
and eXit criteria), na qual so identificados o propsito, os
critrios de entradas, entradas, atividades, verificao e
critrios de sada, bem como responsveis pela realizao
de cada atividade, verificao e responsveis por artefatos
(Radice, 1988).
A Figura 1 representa uma forma de definir o processo
de GRU com esta notao adaptada. A representao est
na primeira atividade Identificar Ativos Reutilizveis
para exemplo de aplicao. Tendo como Critrios de Entrada os Critrios para Seleo de Ativos Reutilizveis
(um guia que orienta e apresenta a classificao para
ativos reutilizveis); Entrada representada por artefatos
e componentes de software; Atividade Identificar Ativos
Reutilizveis; Verificao atravs da reviso dos artefatos/
componentes propostos para ativos reutilizveis e por
fim, a sada desta atividade resulta na Lista de Artefatos
revisados e elencados a Ativos reutilizveis.
Outro ponto a ser considerado na implementao de GRU
deve ser a forma como o processo ser medido e monitorado na organizao. De acordo com Filho (2008), esta
definio foi uma das principais dificuldades na implantao deste processo. Nesta experincia, foram levados
em considerao aspectos como verificao de alcance
dos objetivos do processo, utilidade na identificao de
Figura 1. Exemplo de Implementao do processo de Gerncia de Reutilizao com a notao ETVX
34
Processo
Referncias
oportunidades de melhoria, representatividade da mtrica

e custo de medio associado. Sendo que foram identificados dois indicadores: taxa de reutilizao dos ativos e
evoluo da base de ativos reutilizveis.
Becker,Carlos (2008)Reuso de Software no Contexto das Empresas da Cooperativa MPS.BR - SOFTSUL,

In: II Simpsio Brasileiro de Componentes, Arquiteturas e Reutilizao de Software, Porto Alegre.
Concluso
COPPE/UFRJ (2008) Laboratrio de Engenharia de Software Equipe de Reutilizao de
A Gerncia de Reutilizao deve apoiar a organizao a

reaproveitar artefatos e partes de software, melhorando
a qualidade do produto, garantida pela utilizao de ativos j testados e reutilizados em outros projetos, assim
como o ganho de produtividade, atalhando etapas de
desenvolvimento.
Vimos neste artigo que Gerncia de Reutilizao proporciona outros benefcios organizao como reduo do
custo e esforos envolvidos no processo de desenvolvimento, bem como otimizao da flexibilidade da estrutura do
software, que facilitar sua manuteno posteriormente.
Todavia, cuidados devem ser tomados para no onerar a
aplicao deste processo, no qual seu objetivo gerenciar
o ciclo de vida dos ativos reutilizveis. O mecanismo de
como ser gerenciado, desde critrios para captao de
ativos reutilizveis, controle de uso a manuteno destes,
deve ser feito de acordo com o perfil da empresa. De acordo com Filho (2008), o uso de controles manuais poder
tornar o processo exaustivo e propenso a erros, podendo
ser minimizado com processos automatizados.
Embora seja um processo recente no MR-MPS (desde
junho 2007), quando bem implementado, seus resultados
esto voltados a objetivos estratgicos de qualquer organizao: melhorar a produtividade e a reduo de custo
de desenvolvimento.
Filho, Reinaldo C. Silva; Katsurayama, Anne Elise; Santos, Gleison; Murta, Leonardo; Rocha,
Ana Regina (2008) A Experincia na Implantao do Processo de Gerncia de Reutilizao no
Laboratrio de Engenharia de Software da COPPE/UFRJ,In: IV Workshop de Implementadores
(W2 MPS.BR) e II Workshop de Empresas (W6 MPS.BR), Belo Horizonte.
IEEE (2004) Std 1517 - IEEE Standard for Information Technology - Software Life Cycle
Processes - Reuse Processes, Institute of Electrical and Electronics Engineers.
Krueger, C.W. (1992) Software Reuse, In: ACM Computing Surveys, Vol. 24, N 02.
Machado, Cristina ngela Filipak (2006) Definindo Processos do Ciclo de Vida de Software
usando a Norma NBR ISO/IEC 12207 e suas Ementas 1 e 2, Curso de Ps-Graduao Latu
Sensu a Distncia: Melhoria de Processo de Software, UFLA, Lavras.
MPS.BR (2007a) SOFTEX MPS.BR Implementaes em Grupos de Empresas G1, http://
www.softex.br/mpsbr/_implementacoes/MPS.BR_SOFTSUL.pdf.
MPS.BR (2007b) SOFTEX MPS.BR Avaliaes MA-MPS Qualit Nvel F do MPS.BR, http://
www.softex.br/mpsbr/_avaliacoes/avaliacao.asp?id=1434.
MPS.BR (2007c) SOFTEX - MPS.BR Guia Geral, http://www.softex.br/mpsbr/_guias/MPS.
BR_Guia_Geral_V1.2.pdf.
MPS.BR (2007d) SOFTEX - MPS.BR Guia de Implementao Parte 3: Nvel E, http://www.
softex.br/mpsBr/_guias/MPS.BR_Guia_de_Implementacao_Parte_3_v1.1.pdf.
RISE (2008) Reuse in Software Engineering, http://www.rise.com.br.
COMPOSE
www.compose.ufpb.br
Salviano, Clnio Figueiredo (2006a) Melhoria e Avaliao de Processo de Software com o

Modelo ISO/IEC 15504-5:2006, Curso de Ps-Graduao Latu Sensu a Distncia: Melhoria de
Processo de Software, UFLA, Lavras.
COPPE/UFRJ - Reutilizao de Software

http://reuse.cos.ufrj.br
Salviano, Clnio Figueiredo (2006b) Uma Proposta Orientada a Perfis de Capacidade de

Processo para Evoluo da Melhoria de Processo de Software,Tese de Doutorado, Faculdade de
Engenharia Eltrica e de Computao da Universidade Estadual de Campinas (FEEC-Unicamp).
SEI. SOFTWARE ENGINEERING INSTITUTE.CMMI for Development (CMMI-DEV), Version 1.2,
Technical report CMU/SEI-2006-TR-008. Pittsburgh, PA: Software Engineering Institute,
Carnegie Mellon University, 2006.
C.R.U.I.S.E Component Reuse in Software Engineering

http://cruise.cesar.org.br/index.html.
SEI. SOFTWARE ENGINEERING INSTITUTE (2008) The IDEAL Model,http://www.sei.cmu.edu/ideal/.
Feedback
eu
sobre e
s
edio
ta
D
s
RISE - Reuse in Software Engineering

http://www.rise.com.br
CRUISE (2007) C.R.U.I.S.E wComponent Reuse in Software Engineering, http://cruise.cesar.

org.br/index.html.
Radice, Ronald A.; Phillips, Richard W (1988) Software Engineering, An Industrial Approach,
Englewood Cliffs, New Jersey: Prentice Hall.
MPS.BR
www.softex.br/mpsbr/_home/default.asp

Software, http://reuse.cos.ufrj.br.
Porto, Josiane Brietzke (2008) Gerncia de Reutilizao Alinhada ao MPS.BR Nvel E,Monografia de
Ps-graduao em Melhoria de Processo de Software, Universidade Federal de Lavras (UFLA), Lavras.
Links
COMPOSE (2008) Component Oriented Service Engineering, http://www.compose.ufpb.br.
Werner, Cludia Maria Lima (2007) Gerncia de Reutilizao de Software, Minicurso de

Gerncia de Reuso MPS.BR, SOFTEX, Belo Horizonte.
Werner, Cludia Maria Lima (2008) GLOBO Cincia Reutilizao de Software, http://reuse.
cos.ufrj.br/files/videos/20080624_GloboCiencia.html.
35
Melhorando a Qualidade do Software e

Otimizando Recursos com Teste baseado em Riscos
Apresentao de uma viso geral da abordagem
de teste baseado em riscos e tcnicas disponveis
para o planejamento, projeto e execuo de testes
de software.
Ellen Souza
eprs@dsc.upe.br
Professora Assistente do Curso de Bacharelado em Sistemas de Informao da Unidade Acadmica de Serra Talhada (UAST) da
Universidade Federal Rural de Pernambuco
(UFRPE). Mestre em Engenharia da Computao pela Universidade de Pernambuco (UPE).
Residente do Curso Seqencial de Formao
Complementar em Teste de Software pelo
Centro de Informtica (CIn) da Universidade
Federal de Pernambuco (UFPE), em parceria
com a Motorola. Graduada em Cincia da
Computao pela Universidade Catlica de
Pernambuco (UNICAP).
Cristine Gusmo
cristine@dsc.upe.br
Professora Assistente do Departamento de

Sistemas e Computao da Escola Politcnica
da Universidade de Pernambuco (POLI UPE),
onde leciona vrias disciplinas na graduao e
ps-graduao (especializao e mestrado) e
das Faculdades Integradas Barros Melo. Doutora e Mestre em Cincia da Computao pela
Universidade Federal de Pernambuco. Graduada em Engenharia Eltrica Eletrotcnica
pela Universidade Federal de Pernambuco.
36
Para que serve?

Fornecer uma motivao para o uso da abordagem de
teste baseado em riscos, destacando seus benefcios,
limitaes e aplicaes.
s empresas, de forma geral, tm

despertado para a importncia
da atividade de teste de software como forma de melhorar a qualidade dos seus produtos e manterem-se
competitivas no mercado. Alm disso, a
complexidade das tecnologias utilizadas
e dos softwares produzidos tem crescido, tornando-se necessria a utilizao
de processos, tcnicas e ferramentas
que permitam a realizao de teste de
software de maneira sistematizada, com
o objetivo de aumentar a qualidade do
software com o menor custo possvel.
Da mesma forma, a gerncia de riscos tem sido fortemente debatida,
estudada e utilizada em ambientes de

O processo de teste de software exerce um importante papel dentro da garantia de qualidade
de software assegurando que os requisitos satisfazem as necessidades das partes envolvidas.
Este processo, entretanto, requer bastante esforo, dentro de restries de custo e prazo. A abordagem de teste baseado em riscos permite identificar funcionalidades com grande probabilidade
de apresentar falhas, de forma a alocar melhor os
recursos disponveis, diminuindo o tempo e custo
necessrios para se testar. Este artigo apresenta
a abordagem de teste baseado em riscos, suas
aplicaes, limitaes, bem como as tcnicas disponveis para o planejamento, projeto e execuo
de testes funcionais e estruturais.
Engenharia de Software Magazine - Melhorando a Qualidade do Software e Otimizando Recursos com Teste baseado em Riscos
Validao, Verificao e Teste
desenvolvimento de software com o propsito de administrar

oportunidades, aumentando a probabilidade de entregar o
software com o menor custo, no menor tempo possvel e com
maior qualidade.
A atividade de teste de software, no entanto, complexa e
demanda tempo considervel para ser realizada, chegando a
custar at metade do valor inicial de desenvolvimento de um
software.
O teste baseado em riscos (RBT Risk-based Testing), por
sua vez, permite priorizar esforos e alocar recursos para os
componentes de software que necessitam ser testados mais
cuidadosamente a partir da identificao, anlise e controle
dos riscos tcnicos associados aos requisitos do software.
O consultor James Bach considerado o pai da abordagem de
Teste baseado em Riscos. Ele descreveu a idia em seu artigo
intitulado: The Challenge of Good Enough Software, em outubro de
1995, na revista American Programmer. Somente em 1999, [Bach
1999] apresenta uma tcnica baseada em heursticas para RBT e
desde ento, diversas tcnicas tm sido propostas e utilizadas
para testar produtos de software com diferentes domnios,
em empresas como IBM [Chen 2002] e outras. Estas tcnicas
so apresentadas neste artigo, destacando seus pontos fortes,
aplicaes e limitaes.
Por que Realizar Teste baseado em Riscos?

bastante freqente organizaes depararem-se com restries
de tempo e recursos para o desenvolvimento de software, em
especial, para realizao de teste de software. A abordagem RBT
permite justamente fazer melhor uso dos recursos disponveis,
priorizando os requisitos do software que necessitam ser testados prioritariamente. Assim, a quantidade de teste planejada e
realizada para o software ser na proporo do risco envolvido.
Quanto maior o risco, mais teste necessrio. Da mesma forma
que requisitos ou funcionalidades com baixa exposio ao risco
no necessitam ser testados exaustivamente.
Alm disso, de acordo com estudos realizados, os defeitos com
maior severidade podem ser descobertos mais cedo, tendo em
vista que os requisitos mais problemticos sero testados prioritariamente, e conseqentemente serem corrigidos mais cedo.
RBT tambm uma valiosa ferramenta para o gerente de
teste que pode planejar as atividades e alocar/solicitar recursos
considerando, no somente a informao das funcionalidades
do software que esto em desenvolvimento ou manuteno,
mas tambm quais riscos esto associados a cada funcionalidade e quais funcionalidades so mais crticas com relao
ao teste de software.
Por fim, como conseqncia de uma atividade de teste bem
planejada, a qualidade do software melhorada.
Teste de Software no baseado em Riscos?

consenso que a realizao de qualquer atividade de teste
diminui o risco de um software apresentar falhas em produo. Teste primariamente uma forma de controlar os
riscos associados aos requisitos ou funcionalidades de um
software. A partir dessas definies podem surgir as seguintes
perguntas: Porque ento o termo Teste baseado em Riscos?

Esse termo no parece redundante? De certa forma, o termo
sim redundante, entretanto ele utilizado para destacar um
conjunto de atividades da gerncia de riscos que pode ser
utilizado para estabelecer melhorias nos processos de teste
de software, tais como:
1. Identificar riscos associados aos requisitos ou funcionalidades do software.
2. Analisar e Priorizar os riscos identificados, atravs dos valores de probabilidade de ocorrncia e impacto. Como os riscos
esto associados aos requisitos, estes ltimos so priorizados
indiretamente.
3. Projetar casos de teste com base nas estratgias para tratamento dos riscos identificados. Um ou mais casos de teste
podem ser projetados para mitigar um risco.
4. Controlar os riscos priorizados atravs da execuo dos
casos de teste. Quando executamos um caso de teste baseado
em riscos e este falha, o software necessita ser corrigido para
que o risco seja mitigado.
Os processos de teste disponveis na literatura tratam os
riscos associados aos requisitos de software de forma ad hoc
[Bach 1999]. Casos de teste so planejados, projetados, executados e controlados com o propsito de diminuir riscos. Mas
que riscos so estes que esto sendo tratados? So os riscos
mais importantes? As funcionalidades que apresentam maior
risco foram testadas adequadamente? Essas e outras perguntas
podem ser respondidas com a adoo de processo ou tcnicas
de teste baseado em riscos.
Quais Riscos so Tratados pela Abordagem RBT?

O Instituto de Engenharia de Software (SEI) [Carr et al. 1993]
define risco como a possibilidade de sofrer perdas nos objetivos do projeto, tais como: impactar na qualidade do produto
final, atrasar cronograma, aumentar custos ou mesmo falhar
o projeto.
Os riscos de software podem ser classificados de diversas
formas. Neste artigo, apresentada a classificao definida
pelo SEI, que fornece uma taxonomia para os riscos de acordo
com a sua origem (Figura 1):
1. Engenharia de Produto: problemas no produto que esto
relacionados s aes tcnicas; tambm conhecidos como
riscos tcnicos.
2. Ambiente de Desenvolvimento: problemas no processo
(desenvolvimento) produtivo do software.
3. Restries dos Programas: problemas que acontecem no
projeto e no processo devido a aes da gerncia.
A Figura 1 apresenta um subconjunto da classificao de
riscos de software definida pelo SEI [Carr et al 1993]. Os riscos
relacionados engenharia de produto so os que podem ser
tratados pelo teste de software, mais especificamente os que
esto relacionados aos requisitos do software, como estabilidade, completude, claridade, viabilidade, validade, precedente,
escala e outros. O risco est associado possibilidade de uma
37
de teste de software, projetando casos de teste apenas para

os requisitos prioritrios.
A Figura 2 apresenta o modelo de atividades do processo
de gerncia de riscos, alterado por [Amland 1999] para incluir
elementos relevantes ao teste baseado em risco. As caixas
ovais representam as alteraes realizadas por Amland e
so artefatos produzidos ou atividades do teste de software
realizadas com o apoio de atividades (retngulos) do processo de gerncia de riscos.
Figura 1. Classificao dos riscos de software.

Figura 2. Atividades relevantes para o teste baseado em riscos [Amland 1999].
funcionalidade do software funcionar de forma inadequada,

ou at mesmo no funcionar.
Para exemplificar, suponha que a funcionalidade Cadastrar
Usurio foi definida, documentada e ser implementada. Ao
revisar a funcionalidade, a equipe de testes identificou que
um dos fluxos no est muito claro, muito complexo ou
gerou margem para diversas interpretaes. Prontamente,
o analista de teste projeta um caso de teste para verificar
se esse fluxo foi implementado da forma correta pelos desenvolvedores e mitigar o risco identificado.
Aps a identificao dos riscos, estes necessitam ser priorizados de acordo com a sua probabilidade de ocorrncia e
impacto. Alguns estudos [Amland 1999] indicam que funcionalidades extensas, complexas, desenvolvidas sob presso,
com pouco tempo e por desenvolvedores inexperientes ou
sem conhecimento da tecnologia utilizada, possuem uma
grande probabilidade de apresentar falhas. Similarmente
acontece com funcionalidades que esto em constante
manuteno ou que tm apresentado muitas falhas. Esses
indcios nos ajudam a identificar a probabilidade de ocorrncia de falhas.
Com relao ao impacto, uma forma bastante simples de
priorizar os riscos verificando o impacto de ocorrncia
de uma falha em uma funcionalidade para o cliente. Se a
atividade fim de um cliente vender livros e existe um risco
associado funcionalidade de venda, o seu impacto bastante alto, uma vez que o cliente poder ter srios prejuzos
caso as vendas no possam ser realizadas.
Tcnicas e Processo de Teste baseado em Riscos

Nesta seo, so apresentadas algumas das tcnicas e processos disponveis para a abordagem de teste baseado em
riscos, que utilizada, mais fortemente, no planejamento e na
estratgia de execuo dos casos de testes [Bach 1999]. Seu uso,
entretanto recomendado tambm j na de fase construo ou
projeto dos casos de teste, como forma de otimizar o processo
38
Para cada atividade do ciclo de vida do processo de teste

de software, h uma correspondente na gerncia de riscos,
com o intuito de fornecer o tratamento e acompanhamento
adequado para os riscos tcnicos identificados.
A atividade de identificao de riscos produz como resultado um lista de riscos associados aos requisitos a serem
testados. A partir da avaliao qualitativa e/ou quantitativa, os riscos so priorizados. Tambm, estratgias para
mitigao dos riscos so elaboradas de acordo com sua
prioridade e estas informaes servem como base para
criao do plano de testes.
Quando os testes ou inspees so realizados, os riscos
so mitigados, ou pelo menos, so minimizados para que
o impacto dos fatores de riscos seja menor. A comunicao
dos riscos fornece os dados para definio e acompanhamento dos riscos atravs de um conjunto de mtricas.
Tcnica Baseada em Heurstica

[Bach 1999] define uma tcnica baseada em heurstica
utilizando duas abordagens distintas para a atividade de
identificao dos riscos: na abordagem Inside-Out, o
software estudado e questionado repetidamente, o que
pode dar errado neste produto; na abordagem Outside-In,
uma lista de potenciais riscos utilizada, juntamente com
detalhes do software. Para cada risco, identificado se este
se aplica ou no a uma determinada funcionalidade.
Nessa tcnica, trs tipos de listas so utilizadas para
auxiliar a identificao dos riscos:
1 - Lista de categorias de critrios de qualidade: so categorias desenvolvidas para atenderem a diferentes tipos
de requisitos. Um exemplo deste tipo de lista apresentado
na Tabela 1, que foi desenvolvida a partir dos critrios
do padro ISO 9126 e HP FURPS (Functionality, Usability,
Reliability, Performance, Supportability).
Capacidade
O requisito realiza a funo requerida?
Confiabilidade
A funcionalidade resiste a falhas em todas as situaes?
Usabilidade
Quo fcil a utilizao da funcionalidade pelo usurio?
Instalabilidade
A principal dificuldade dessa abordagem est no conhecimento prvio do negcio a fim de realizar a anlise dos riscos da
maneira mais fiel possvel. Existe a possibilidade da anlise ter
sido realizada de forma errada e, conseqentemente, os verdadeiros riscos no terem sido atacados da forma correta.
Quo fcil a instalao do software?
Manutenibilidade Quo econmicas so as manutenes corretivas e evolutivas?

Portabilidade
Quo econmica a portabilidade para outra plataforma?
Tcnica Baseada em Mtricas
Tabela 1. Lista de categorias de critrios de qualidade [Bach 1999].
2 - Listas genricas de riscos: so aquelas que possuem riscos universais a qualquer sistema. Um exemplo mostrado na Tabela 2.
Complexo
Novo
Modificado
Qualquer coisa desproporcionalmente grande.
Esta tcnica foi desenvolvida por [Amland 1999] e consiste

em um conjunto de mtricas para a anlise de riscos com o
objetivo de subsidiar um processo de teste. Essas mtricas
foram aplicadas em estudo de caso de uma aplicao de instituio financeira. Existem trs fontes de anlise de riscos
representadas pela Equao 1:
Qualquer coisa que no possua histrico no produto.

Qualquer coisa que tenha sido modificada ou melhorada.
Crtico
Qualquer coisa cuja falha poderia causar um dano substancial.
Preciso
Qualquer coisa que deva atender a requisitos exatos.
Popular
Que ser muito usado.
Equao 1. Clculo para exposio do risco [Amland 1999].
Terceirizado
Qualquer coisa usada no seu produto, mas que foi desenvolvida fora do projeto.
Distribudo
Qualquer coisa que esteja espalhada em relao a tempo ou espao, e que

seus elementos devam trabalhar juntos.
Qualquer coisa com uma histria recente de falha.
Falhou
recentemente
Tabela 2. Lista genrica de riscos [Bach 1999].
3 - Os catlogos de risco: So listas de riscos que pertencem

a um domnio em particular. A Tabela 3 apresenta uma verso
resumida do que seria um catlogo de riscos para o instalador
de um software.
Instalao dos arquivos errados.
Arquivos corrompidos.
Hardware no foi configurado de forma apropriada.
Outras aplicaes corrompidas.
O protetor de tela interfere no instalador.
No h deteco de aplicaes incompatveis.
O instalador silenciosamente substitui ou modifica arquivos crticos ou parmetros.
O processo de instalao muito lento.
O processo requer o constante monitoramento do usurio.
O processo de instalao confuso.
Tabela 3. Catlogo de riscos para um instalador [Bach 1999].
Aps a identificao dos riscos usando umas das abordagens

explicadas anteriormente, valores so atribudos a cada um dos
riscos em uma escala de interesse. Os requisitos associados aos
riscos com maior valor so testados primeiramente.
CUSTO
1 - Qualidade da funo (rea) a ser testada: projetos de m

qualidade, programador inexperiente, funcionalidade complexa, e outras variveis resultam em funes com maior exposio a falhas. Essa funo corresponde probabilidade P(f).
2 - As conseqncias de uma falha em uma funo do ponto
de vista de um cliente em uma situao de produo podem
ser representadas pela probabilidade de ameaa legal, perda de
posicionamento no mercado e pelo no cumprimento de regulamentaes governamentais por causa de falhas, entre outras. Estas
conseqncias representam o custo para o consumidor C(c).
3 - As conseqncias de uma falha em uma funo do ponto
de vista do vendedor do servio esto relacionadas probabilidade de publicidade negativa, altos custos de manuteno
de software, e outros, devido a uma funo com falhas. Estas
conseqncias representam o custo para o vendedor C(v).
Tendo em vista o grau de exposio ao risco Re(f), as reas
com risco mais alto tm a maior prioridade nos testes. Durante os testes, medida que falhas vo ocorrendo, os graus de
exposio ao risco vo sendo atualizados e a prioridade das
funcionalidades pode ser modificada.
Um exemplo do grau de exposio ao risco para a funo
Fechar Contas mostrado na Tabela 4. O Custo calculado
atravs da mdia aritmtica de C(v) e C(c). Os nmeros entre
parnteses so os pesos definidos para cada mtrica. A probabilidade calculada como a mdia ponderada das mtricas,
dividida pela maior mdia ponderada de todas as mtricas,
resultando em uma probabilidade na faixa de [0,1].
A tcnica definida por Amland foi utilizada para testar dois mdulos de uma aplicao financeira contendo,
PROBABILIDADE
Funo
C(v)
C(c)
Mdia
Fechar Conta
Nova Funo
(5)
2
Qualidade
(5)
2
Tamanho
(1)
2
Complexidade
(3)
3
Mdia
Ponderada
7,75
Probabilidade
Exposio ao Risco
0,74
1,48
Tabela 4. Exposio ao risco para a funo Fechar Contas [Amland 1999].
39
respectivamente, doze e trezentas funcionalidades. Sendo que,

para o segundo, por falta de tempo, foram avaliadas as vinte
funcionalidades mais importantes definidas pelo cliente. Um
dos maiores problemas relatados por Amland foi a falta de
conhecimento de algumas funcionalidades, que dificultou a
anlise e produziu resultados no confiveis.
Um nvel mnimo de teste foi definido para as funcionalidades com baixa exposio ao risco e testes extras foram definidos
para funcionalidades com maior exposio ao risco. O cliente
avaliou o produto entregue como de excelente qualidade. O
nmero de defeitos encontrados foi similar ao das verses anteriores. No entanto, o tempo gasto para concluir os testes foi
menor e o nmero de recursos utilizados tambm foi menor.
O grande desafio para definio da tcnica, segundo
Amland, foi a identificao dos indicadores de custo de falha
e de qualidade. Foi utilizada uma abordagem simples, mas
satisfatria de acordo com os estudos apresentados. Assim,
como na maioria das tcnicas, mantido foco somente na
anlise dos riscos.
Tcnica para Cdigo-fonte Orientado a Objetos

A idia desta tcnica que, atravs da aplicao de mtricas
de complexidade de software orientado a objetos, pode-se chegar a classes que possuem maior probabilidade de apresentar
falhas. Seis mtricas de medio de projetos orientadas a objeto
so utilizadas, identificadas e aplicadas pelo SATC (Software
Assurance Technology Center) da NASA (Goddard Space Flight Center). Segundo os autores, foi comprovado [Rosenberg et
al 1999] que o cdigo mais complexo tem uma maior incidncia
de erros ou problemas. As mtricas so:
1 - Nmero de mtodos (Number of Methods NOM): a
contagem dos diferentes mtodos existentes em uma classe.
2 - Nmero ponderado de mtodos por classe (The Weighted
Methods per Class WMC): a soma ponderada dos mtodos
em uma classe.
3 - Acoplamento entre objetos (Coupling Between Objects
CBO): a contagem do nmero de outras classes nas quais
uma classe est acoplada.
4 - A resposta a uma classe (The Response for a Class RFC):
a cardinalidade do conjunto de todos os mtodos que podem
ser invocados em resposta a uma mensagem para um objeto
da classe.
5 - Profundidade na rvore (Depth in Tree DIT): o nmero
de saltos saindo de uma classe at a raiz da hierarquia de classes.
Quando existe herana mltipla, a maior DIT utilizada.
6 - Nmero de filhos (Number of Children NOC): o nmero
de subclasses que herdam diretamente da classe na hierarquia.
Por mais de trs anos, o SATC tem coletado e analisado
cdigo orientado a objetos escritos tanto em C++ quanto em
Java. Mais de 20.000 classes de mais de 15 programas foram
analisadas. Os seguintes valores limites para as mtricas individuais, apresentados na Tabela 5, foram derivados do estudo
da distribuio das mtricas coletadas.
Uma mtrica nunca dever ser utilizada sozinha para avaliar
40
MTRICA
OBSERVAO
NOM
Preferencialmente menor que 20 e aceitvel at 40.
WMC
Preferencialmente menor que 25 e aceitvel at 40.
CBO
Aceitvel at 5.
RFC
Aceitvel at 50.
DIT
Aceitvel at 5.
NOC
No h consenso. Quanto maior, maior a probabilidade de erro.
Tabela 5. Valores limites para mtricas individuais.
os riscos do cdigo. So necessrias, pelo menos, duas ou trs

mtricas para dar uma indicao de problema em potencial.
Portanto, para cada projeto, o SATC cria uma tabela de classes
que possuem alto risco. Classes que tm ao menos duas mtricas
que excedem os limites recomendados possuem alto risco.
A Tabela 6 mostra um exemplo de mtricas para classes de
um projeto Java. As clulas em vermelho representam mtricas
fora do limite aceitvel.
CLASSE
NO. MTODOS
CBO
RFC
RFC/NOM
WMC
DIT
NOC
54
536
9.9
175
168
24
71
33
240
7.2
105
54
361
6.7
117
62
378
6.1
163
10
63
235
3.7
156
11
81
10
285
3.5
161
12
42
127
69
13
20
17
324
16.2
139
14
46
186
238
Tabela 6. Mtricas coletadas de um projeto Java.
A anlise das classes fcil de ser aplicada, inclusive pode

ser realizada de forma automtica. No entanto, os autores no
propem estratgias de testes para o cdigo, tampouco formas
de rastreamento das funcionalidades impactadas por classes
com alto risco de falhas.
Tcnica para Teste de Regresso baseado em Riscos

Essa tcnica define uma estratgia para execuo de testes de
regresso baseada em especificao [Chen 2002]. A justificativa
principal que teste de regresso baseado em cdigo bom para
teste de unidade, mas tem problemas de escalabilidade. medida que o tamanho do sistema cresce, torna-se difcil gerenciar a
informaes dos testes e criar matrizes de rastreabilidade. Nesta
tcnica, dois conjuntos de testes de regresso so definidos:
1 - Testes de regresso para os componentes que foram alterados: pelo menos um teste executado para cada componente
inserido ou alterado.
2 - Testes de regresso baseados em riscos para os componentes que aparentemente no sofreram modificaes: para
estes, uma anlise de riscos realizada a partir de questionrios submetidos aos participantes do projeto.
Essa tcnica utiliza as mtricas de anlise de risco desenvolvidas por Amland e apresentadas anteriormente.
A fase de seleo de casos de teste envolve os seguintes
passos:
1 - Estimar o custo de cada caso de teste. Ou seja, o custo que
uma falha possa causar. O custo calculado da mesma forma
proposta por [Amland 1999];
2 - Derivar a severidade para cada caso de teste. Esse valor
computado a partir do nmero de defeitos e da severidade
destes defeitos;
3 - Calcular o grau de exposio de risco para cada caso de
teste. A exposio ao risco calculada a partir do custo e da
severidade, e;
4 - Selecionar os casos de teste que tm os maiores valores
de exposio ao risco.
utilizao do sistema, seguindo a teoria de Pareto, que afirma

que vinte por cento das funcionalidades permitem ao usurio
realizar oitenta por cento do seu trabalho.
A Figura 3 apresenta o esforo necessrio para eliminar
todos os riscos identificados (reta em vermelho). Seguindo
a idia de Pareto, a relao entre risco e esforo ficaria mais
parecida com o grfico representado pela linha em azul. Logo,
diminuir o risco em cinqenta por cento pode ser alcanado
em um curto espao de tempo se uma priorizao dos testes
feita a partir
A seleo de cenrios baseados em riscos deve obedecer

duas regras:
1 - Selecionar os cenrios para cobrir os casos de teste mais
crticos, e;
2 - Garantir que os cenrios cubram tantos casos de teste
quanto possvel.
A seleo de cenrios baseado em riscos tem os seguintes
passos:
1 - Calcular a exposio de riscos para cada cenrio. Calculado a partir da soma da exposio ao risco dos casos de testes
associado a este cenrio;
2 - Selecionar os cenrios com maior exposio ao risco;
3 - Atualizar a matriz de rastreabilidade, removendo os
cenrios selecionados e os testes j cobertos e recalculando a
exposio ao risco, e;
4 - Repetir os passos 1, 2 e 3, o quanto necessrio.
Esta tcnica se mostrou bastante eficiente de acordo com
os resultados apresentados. Alm disso, a anlise realizada
atravs de questionrios submetidos aos desenvolvedores,
com questes que os mesmos dominam, no constituiu uma
tarefa complexa. Com a ajuda de ferramentas, todo o processo
realizado de forma rpida.
Como a abordagem toma como base a documentao do
sistema, essa deve encontrar-se sempre atualizada. Riscos no
so identificados nesta tcnica e assume-se que os casos de
testes j esto prontos. Dependendo da quantidade de casos
de testes, essa tcnica pode ser invivel, uma vez que a anlise
de riscos feita a partir dos casos de teste.
Tcnica RBT baseada em Uso

Esta tcnica define uma estratgia baseada em uso, onde
qualquer atividade de teste implica em uma diminuio dos
riscos [Besson 2004]. De acordo com o autor, independente da
quantidade de testes executados, sempre haver um risco. A
idia investir o mnimo de esforo em teste possvel para
maximizar a reduo dos riscos.
Os esforos de teste so controlados tomando como base a
de uma anlise dos riscos.

Figura 3. Esforo necessrio para reduzir em 50% os riscos.
A tcnica dividida em cinco passos:

1 - Identificar funcionalidades vitais que podem previnir
o usurio de utilizar o sistema se um defeito for encontrado,
ou seja, um defeito com alta severidade. Uma forma eficiente
de listar essas funcionalidades a partir de pesquisas com os
usurios finais do sistema, especialistas no domnio do sistema
ou atravs de dados esttisticos de uso de verses anteriores.
Uma vez que o risco aumenta com a frequencia de uso, as
funcionalidades mais usadas tero maior risco.
2 - Projetar casos de teste para cada funcionalidade listada
no Passo 1.
3 - Estimar tamanho (em horas ou minutos) do esforo necessrio para executar os casos de teste identificados.
4 - Ordenar os casos de teste em ordem ascendente, de acordo
com o esforo. Dessa forma, os casos de teste com menor esforo
so executados primeiro.
5 - Iniciar a execuo dos casos de teste na ordem estabelecida
no Passo 4 at que o tempo termine.
A anlise dos riscos , de certa forma, fcil de ser realizada,
uma vez que o usurio especifica as funes que so mais
utilizadas no sistema, ou seja, as funes que permitem ao
usurio realizar oitenta por cento das suas atividades.
Como a execuo dos testes baseada em esforo, os testes
que gastam menos tempo so executados primeiro at que o
tempo acabe. Essa tcnica pode ser til em culturas organizacionais avessas ao teste.
No entanto, esta tcnica no garante que as funcionalidades
41
que esto sendo atacadas sejam as mais propensas a apresentar falhas.

Modelo de Processo de Teste de Software baseado em Riscos
O RBTProcess um modelo de processo de teste de software
baseado em riscos proposto por [Souza e Gusmo 2008], construdo a partir de atividades presentes no gerenciamento de
riscos e nos processos de teste de software disponveis na literatura. O RBTProcess possui quatro fases distintas juntamente
com seus marcos e atividades, como mostrado na Figura 4.
1 - Planejamento: esta fase tem como foco o planejamento
inicial dos testes com base na anlise dos riscos. O marco desta
fase a priorizao dos requisitos atravs da identificao e
anlise dos riscos.
2 - Projeto: nesta fase, os casos de teste planejados so projetados com base na anlise dos riscos. O marco desta fase
a criao de casos de teste que verificam a existncia ou no
dos riscos identificados.
3 - Execuo: os casos de teste planejados e projetados so
executados. O marco desta fase a mitigao dos riscos identificados atravs da execuo de casos de teste que verificam
a existncia ou no dos riscos identificados.
4 - Controle: os resultados da execuo dos testes so coletados e controlados. Na disciplina Avaliar Testes, verificado
o conjunto de nmeros, estratgias, tempo de execuo e
solicitaes de mudana dos testes. Na disciplina Controlar
Riscos, realizado o acompanhamento dos riscos. Os riscos
mitigados so eliminados da lista de riscos identificados e
serve de entrada para o planejamento da prxima iterao. O
marco desta fase o controle dos riscos mitigados.
sem saber que esto identificando riscos. A Tabela 7 apresenta

um exemplo das questes contidas no TBQ para o elemento
Requisito da classe Engenharia de Produto. Neste exemplo,
caso o entrevistado responda sim, indica a existncia de
riscos na funcionalidade ou requisito analisado.
Classe: Engenharia de Produto
Elemento: Requisito
Atributo:
[01] Os requisitos da funcionalidade esto mudando enquanto ela est sendo

desenvolvida?
Estabilidade
Se SIM, qual parte da funcionalidade est mudando?
Atributo:
[02] Ainda existe algo para ser especificado nesta funcionalidade?
Completude
Se SIM, qual parte da funcionalidade no est especificada?
Tabela 7. Questes de estabilidade e completude para o elemento Requisito.
Aps a identificao dos riscos atravs do TBQ, realizada

uma reunio brainstorm com toda a equipe de desenvolvimento
a fim de validar os riscos levantados na atividade anterior. So
utilizadas as listas de riscos propostas por [Bach 1999] para
guiar a reunio.
O artefato de sada dessa disciplina uma lista de riscos
identificados para cada requisito.
2 - Analisar Riscos: tem como objetivo a priorizao dos
requisitos a serem testados com base na anlise dos riscos
tcnicos identificados. A frmula utilizada para priorizao
dos riscos foi proposta por [Amland 1999] com algumas
adaptaes. Para a probabilidade P(f), calculada a mdia dos
valores atribudos s mtricas Nova Funcionalidade, Projeto/
Qualidade, Tamanho, Complexidade e Dependncia. Sendo
que a ltima foi proposta neste processo e corresponde ao nvel
de dependncia com as demais funcionalidades do software.
Os participantes desta atividade so os mesmos que realizaram a identificao dos riscos. Um guia fornecido para atribuio dos indicadores das mtricas de acordo com a atividade
realizada pelo participante. Para a mtrica de qualidade, por
exemplo, so sugeridos os valores apresentados na Tabela 8.
Se a pessoa que est respondendo o questionrio um desenvolvedor e no tem conhecimento da linguagem e ambiente
de desenvolvimento, ela deve informar o valor uma para a
mtrica de Projeto/Qualidade.
Indicador
Figura 4. Pgina do RBTProcess [Souza e Gusmo 2008].
A seguir, uma breve descrio das disciplinas que compem

o modelo de processo:
1 - Identificar Riscos: nesta disciplina, os riscos so identificados atravs de questionrio baseado em taxonomia de
riscos (Taxonomy Based Questionnaire TBQ). O objetivo
do TBQ diminuir o nvel de abstrao da atividade de identificao de riscos, uma vez que os engenheiros de teste tm
conhecimento bsico sobre identificao de riscos. A equipe
do projeto responde a perguntas relacionadas aos requisitos,
42
Desenvolvedor
Testador
Analista de requisitos
No tem conhecimento das Funcionalidade no Requisito est estvel

tecnologias/ferramentas apresentou defeitos
1
utilizadas no desenvolvi- nas ltimas verses
mento do software
Tem conhecimento razovel Funcionalidade apre- Requisito ou funcionalidas tecnologias/ferramentas sentou alguns defeitos dade tem sofrido poucas
2
utilizadas no desenvolvi- nas ltimas verses
alteraes
mento do software
Domina a tecnologias/ferra- Funcionalidade apre- Requisito ou funcionali3
mentas utilizadas no desen- sentou muitos defeitos dade tem sofrido muitas
volvimento do software
nas ltimas verses
alteraes
Tabela 8. Exemplo de indicadores para a mtrica de Projeto/Qualidade
3 - .Planejar Testes: tem como objetivo direcionar e controlar

as atividades de teste com base na avaliao de riscos. Consiste na definio dos requisitos que sero testados ou no,
tomando, como base, a anlise dos riscos. A priorizao dos
requisitos realizada a partir dos valores de exposio ao risco.
O RBTProcess sugere que, a cada iterao, sejam testados, por
exemplo, um conjunto de requisitos de acordo com a sua prioridade. Os requisitos classificados como de baixa prioridade
somente so testados se houver tempo disponvel.
Diversas estratgias podem ser utilizadas com base na
anlise dos riscos. Uma delas , por exemplo, a automao
dos testes para os requisitos classificados como de alta
prioridade.
4 - Projetar Testes: tem como objetivo identificar e descrever os casos de teste para os requisitos a serem testados
com base na anlise de riscos. Consiste na identificao
dos cenrios, alm da definio da abordagem e tipo de
testes que sero utilizados. O processo sugere diferentes
coberturas para os requisitos de acordo com sua importncia: i. requisitos com baixa exposio ao riscos: testar
somente os cenrios relacionados aos riscos caso haja
tempo disponvel; ii. requisitos com mdia exposio ao
riscos: testar os cenrios relacionados aos riscos, fluxo
principal e fluxos alterados/includos e iii. requisitos com
alta exposio ao riscos: testar os cenrios relacionados
aos riscos e todos os fluxos do requisito (principal, exceo
e alternativo).
Para cada risco identificado, testes so criados com o propsito de mitigar os fatores de riscos. O estilo de criao dos
casos de testes para execuo recomendado pelo processo
independente, de forma que os casos de testes possam ser
executados em qualquer ordem.
5 - Executar Testes: esta a atividade em que, de fato, os
riscos so mitigados atravs da execuo de casos de teste
baseado em riscos. Tem como objetivo executar testes e
verificar a corretude do software, avaliando os resultados
e registrando os problemas encontrados. O testador responsvel por esta atividade e executa os testes na ordem de
priorizao definida pela anlise dos riscos.
6 - Avaliar Testes: tem como objetivo medir quantitativamente e qualitativamente o progresso dos testes e gerar um
relatrio de avaliao. O projetista de testes avalia o resultado
da execuo dos casos de teste sem se preocupar com os riscos que foram mitigados. Esta atividade no sofre alteraes
para a abordagem de teste baseado em riscos, uma vez que
todo o controle a acompanhamento dos riscos est definido
na disciplina Controlar Riscos, sob a responsabilidade do
analista de riscos.
7 - Controlar Riscos: essa disciplina responsvel pelo
acompanhamento dos riscos identificados. O analista de
riscos responsvel pela identificao e documentao do
percentual de riscos mitigados por funcionalidade. Alm
da criao do relatrio de avaliao dos riscos, o analista
de riscos responsvel pela atualizao do documento de
identificao e anlise dos riscos, principal entrada para a
atividade de planejamento dos testes.

Em um primeiro momento, o RBTProcess aparece como um
processo pesado mas, de acordo com os estudos realizados,
as atividades da gerncia de riscos de software includas no
processo no exigem muitos esforos. Os resultados obtidos
no estudo de caso forneceram uma forte indicao de que
a abordagem RBT permite: concentrar os esforos de teste
nos requisitos de software que possuem maior probabilidade de apresentar falhas e mostrar que os defeitos, com
maior severidade, podem ser descobertos mais cedo, tendo
em vista que os requisitos mais problemticos so testados
prioritariamente
Anlise Comparativa
Com exceo da tcnica para cdigo-fonte orientado a
objetos, todas as outras utilizam a abordagem funcional ou
caixa-preta para construo dos casos de testes no nvel de
sistema. Apenas a tcnica baseada em heurstica e o RBTProcess propem diferentes formas de identificao de riscos.
A tcnica baseada em mtricas objetiva reduo do custo
da fase de teste do projeto e a reduo de futuros custo de
manuteno do software em potencial atravs da otimizao
do processo de teste. As mtricas propostas levam em considerao que funcionalidades complexas, novas, construdas
com pouca qualidade e grandes (tamanho) possuem mais
probabilidade de apresentar falhas. A tcnica no fornece
nenhuma orientao sobre a criao dos casos de teste.
A tcnica baseada em riscos para teste de regresso objetiva
reduzir a quantidade de casos de teste a serem executados,
alm de possibilitar que as reas mais crticas sejam testadas
prioritariamente. Nesta tcnica, assume-se que os casos de
teste j esto prontos.
A tcnica baseada em uso utiliza a informao de percentual de uso da funcionalidade para priorizao. Isto a torna
fcil de ser utilizada. No entanto, no garante que as funcionalidades que esto sendo atacadas sejam as mais propensas
a apresentarem falhas e precisem ser mais bem testadas.
A finalidade do RBTProcess fornecer conhecimento e recursos necessrios para que os engenheiros de teste possam
utilizar a abordagem RBT em todas as atividades do teste
de software, atravs da definio de disciplinas e papis, e
fornecimento de artefatos, guias, templates e mtricas.
A Tabela 9 apresenta uma anlise comparativa das principais tcnicas e processo apresentados neste artigo. Para
a comparao, foram elencadas atividades mnimas de
gerncia de riscos e teste de software.
Consideraes Finais
Apesar da abordagem RBT se mostrar simples, engenheiros de teste ainda encontram dificuldades em aplic-la na
prtica [Goldsmith 2006], principalmente, porque a anlise
de riscos algo complexo e necessita de conhecimento para
sua aplicao. No existem ainda ferramentas comerciais
especficas para RBT o que, provavelmente, dificulta sua
aplicao e disseminao.
43
CONTROLAR RISCOS
No faz meno
a esta atividade
No fornece detalhes para

esta atividade
Mtricas especficas No faz meno a No faz meno a esta Ordem de exposio

para Teste de Software esta atividade
atividade
ao risco
No faz meno
a esta atividade
No faz meno
a esta atividade
Fornece um conjunto
de mtricas para controle de
progresso dos testes
No fornece detalhes
para esta atividade
No faz meno
a esta atividade
No fornece detalhes
para esta atividade
No faz meno
a esta atividade
Inclui atividade
de avaliao
de processo de teste
No faz meno
a esta atividade
Conjunto de mtricas
para controle de
progresso dos testes
PROJETAR
TESTES
EXECUTAR
TESTES
AVALIAR TESTES
Baseada
em Mtricas
Equao de Barry No faz meno a No fornece detalhes Matriz de rastreabilidade

Boehm
esta atividade
para esta atividade
PLANEJAR
TESTES
IDENTIFICAR
RISCOS
Listas de critrios
de qualidade, genricas
e catlogo de riscos
No faz meno a esta
atividade
ANALISAR RISCOS
TCNICA/
PROCESSO
Baseada em
Heurstica
Baseada em Uso
No faz meno a esta Utiliza a informao No faz meno a No faz meno a esta Percentual de uso da
atividade
de percentual de uso esta atividade
atividade
funcionalidade e tempo de
execuo do caso de teste
Testes
No faz meno a
Mtrica proposta por No fornece
Leva em considerao Ordem de exposio
de Regresso
esta atividade
Amland
detalhes para
que os casos de teste ao risco
esta atividade
esto prontos
Cdigo Fonte Orien- No faz meno a
Mtrica para cdigo No faz meno a No faz meno a esta No faz meno a
tado a Objetos
esta atividade
fonte OO
esta atividade
atividade
esta atividade
RBTProcess
Questionrio, listas
Mtrica proposta
Planeja as
Indica tipos de testes de Ordem de exposio
e reunio de brainstorm
por Amland
iteraes de
acordo com a exposio ao risco
com adaptaes
acordo com a
ao risco
exposio ao risco
Tabela 9. Anlise comparativa das principais abordagens RBT.
consenso entre os autores das tcnicas apresentadas

neste artigo, que a abordagem RBT permite reduzir esforos
de teste e identificar funcionalidades crticas, entretanto,
nenhum autor informa o percentual de esforo reduzido e
a confiabilidade alcanada com a adoo da abordagem.
44
sobre e
s

[Amland 1999] Amland, S. (1999) Risk Based Testing and Metrics: Risk analysis
fundamentals and metrics for software testing including a financial application case study, 5o
International Conference EuroSTAR99.
[Bach 1999] Bach, J. (2009) James Bach on Risk-Based Testing: How to conduct heuristic
risk analysis@, Software Testing & Quality Engineering Magazine, p.23-28.
[Besson 2004] Besson, S. (2004) A Strategy for Risk-Based Testing, disponvel em
<StickyMinds.com>.
[Carr et al 1993] Carr, M. J.; Konda, S.L.; Monarch, I.; Ulrich, F. C.; Walker, C. (1993)
Taxonomy Based Risk Identification,Technical Report CMU/SEI-93-TR-6. Software Engineering
Institute, Carnegie Mellon University/USA.
[Chen 2002] Chen, Y. (2002) Specification-based Regression Testing Measurement with
Risk Analysis, dissertao de Mestrado, University of Ottawa/Canada.
[Goldsmith 2006] Goldsmith, R. (2006) Early and Effective: The Perks of Risk-based
Testing, Software Test and Performance Magazine, v.3, p.24-30.
Feedback
eu
edio
ta
D
s
A constante busca pelo desenvolvimento de software com

melhor qualidade e com baixo custo tem motivado inmeras
pesquisas na rea engenharia de software, em especial na
rea de teste baseado em riscos.
Ferramentas esto em desenvolvimento [Souza e Gusmo
2008] visando auxiliar na utilizao e disseminao da
abordagem RBT que tem muito a contribuir na qualidade
de software.
Referncias
[Rosenberg et al 1999] Rosenberg, L. H.; Stapko, R.; Gallo, A. (1999) Risk-based Object
Oriented Testing 24o Annual Software Engineering Workshop, NASA SEW24.
[Souza e Gusmo 2008] Souza, E.; Gusmo C. (2008) RBTProcess - Modelo de Processo
de Teste de Software baseado em Riscos, 13 WTES - Workshop de Teses e Dissertaes em
Engenharia de Software, SBES08.
45
46
47
Programao Orientada a Aspectos

Um exemplo prtico utilizando AspectJ
Thamine Chaves Leite de Abreu
thamine.abreu@gmail.com
maraujo@devmedia.com.br
Atualmente cursa especializao em Desenvolvimento de Aplicaes para Web no Centro de

Ensino Superior de Juiz de Fora (CES/JF), Bacharel em Sistemas de Informao pela Universidade Severino Sombra (USS), Desenvolvedor de
Sistemas Web na Granbery Consultoria Jnior
em projeto para a Fundao COPPETEC, possui
experincia de 3 anos em desenvolvimento de
sistemas Java (web/desktop).
Doutorando e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ, Especialista em Mtodos Estatsticos Computacionais e
Bacharel em Matemtica com Habilitao em
Informtica pela UFJF, 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.
Leonardo da Silva Mota
48
Para que serve?

Demonstrar a utilizao da orientao a aspectos em conjunto com conceitos de Orientao
a Objetos (OO), permitindo a compreenso das
estruturas bsicas em AspectJ e sua relao com
a linguagem Java.

Na construo de sistemas complexos, criando alternativas atravs da separao de interesses, que permitam maior reusabilidade e
manutenibilidade do software.
leonardo.smota@hotmail.com
Atualmente cursa especializao em Desenvolvimento de Aplicaes para Web no Centro

de Ensino Superior de Juiz de Fora (CES/JF),
Bacharel em Sistemas de Informao pela
Universidade Severino Sombra (USS), Desenvolvedor de Sistemas Web na Granbery
Consultoria Jnior em projeto para a Fundao COPPETEC, programador certificado Java
(SCJP), atuou como professor assistente no
curso de Sistemas de Informao da USS e dos
cursos de informtica da Fundao de Apoio a
Escola Tcnica (FAETEC), possui experincia de
3 anos em desenvolvimento de sistemas Java
(web/desktop).
Apresenta fundamentos da programao orientada a aspectos, atravs do AspectJ, uma extenso da linguagem Java, exemplificando seu uso
e seus principais componentes atravs de um
estudo de caso.
Engenharia de Software busca

o aperfeioamento dos produtos
de software, atravs de tcnicas
e mtodos para facilitar sua reutilizao, manuteno e evoluo. Dentre as
diversas prticas de desenvolvimento
sugeridas, uma das mais consolidadas e
Engenharia de Software Magazine - Programao Orientada a Aspectos
eficientes, a diviso de um sistema em

partes para compreenso das fronteiras
que definem suas funes. Essa diviso
pode ser conhecida tambm como separao de interesses (separation of concerns).
O ideal nessa abordagem seria que toda
parte relacionada a um interesse fosse
Desenvolvimento
transportada para uma localizao fsica separada das demais,

que se relacionam a outros interesses, facilitando seu estudo
e compreenso.
O paradigma de orientao a objetos emprega a separao de
interesses atravs dos objetos, seus estados e operaes, visando
a reduo da complexidade no desenvolvimento de software e
aumentando sua produtividade. Embora a Orientao a Objetos
(OO) d suporte a essa diviso, ela ainda no totalmente contemplada, devido aos interesses sistmicos no serem tratados
da forma adequada e muitas vezes se encontrarem espalhados
por todo o sistema. Interesses sistmicos so requisitos que no
se aplicam lgica de negcios como, por exemplo, segurana,
desempenho, persistncia, integridade de dados e tratamento
de erros, dentre outros. Em decorrncia disso, os sistemas OO
mais complexos tendem a ter forte acoplamento, fraca coeso e
grande redundncia, o que dificulta sua compreenso, manuteno, evoluo e reutilizao. Quando um interesse se espalha
por todo o sistema e se mistura entre outras funcionalidades,
denominado de interesse transversal, ou crosscutting concern.
Como exemplo de interesses transversais pode-se citar logging,
segurana, tratamento de erros, persistncia de dados ou autenticao, entre outros.
A Programao Orientada a Aspectos surge com uma boa proposta para solucionar esse problema, atravs do encapsulamento
dos crosscutting concern em mdulos separados do restante do
cdigo. Esses mdulos so denominados aspectos. Dessa forma,
ao invs dos interesses estarem espalhados pelo cdigo do sistema, eles so combinados nos locais desejados (ver Figura 1).
A idia permitir que os objetos tratem apenas dos interesses
de negcio a que so destinados sem se importar com a forma
com que os interesses sistmicos sero tratados pelos aspectos.
Por isso, o ideal que um objeto no saiba da existncia de um
aspecto, sendo obrigao deste acessar e tratar os interesses
sistmicos de acordo com a necessidade de um objeto.
Figura 1. Diferena entre interesses transversais espalhados no sistema e

a abordagem de modularizao atravs dos aspectos.
Dentro desse contexto, este artigo tem por objetivo apresentar

o desenvolvimento de sistemas utilizando AspectJ, uma extenso da linguagem Java, atravs da ferramenta AJDT AspectJ
Development Tool (ver seo Links) auxiliando na criao de
aspectos que sero desenvolvidos atravs de um estudo de
caso em Java, que permitir ao leitor maior entendimento dos
conceitos abordados. A plataforma utilizada para a realizao

do estudo de caso foi a IDE Eclipse. Para o entendimento da
linguagem, faz-se necessrio a compreenso dos conceitos
bsicos sobre o desenvolvimento orientado a aspectos, que
sero explicados na seo seguinte.
Fundamentos bsicos da Programao Orientada a

Aspectos (POA)
Programao de Orientada a Aspectos (POA) foi criada para
complementar a programao orientada a objetos atravs de
novos conceitos e tcnicas de modularizao de cdigo. Para
isso, a programao orientada a aspectos envolve basicamente
trs etapas de desenvolvimento (ver Figura 2):
1 - Decomposio aspectural (aspectual decomposition): nesta
etapa, os interesses transversais so identificados e separados
dos interesses de negcio;
2 - Implementao de interesses (concern implementation): cada
interesse identificado programado separadamente, dando
origem aos aspectos;
3 - Recomposio aspectural (aspectual recomposition): aps
a implementao dos aspectos, realizada a integrao dos
aspectos com os componentes desenvolvidos, atravs do combinador aspectural, ou aspect weaver.
Figura 2. Etapas do processo de desenvolvimento orientado a aspectos
Um programa desenvolvido utilizando-se a POA composto

pelos seguintes elementos:
1 - Linguagem de componentes: responsvel pela implementao dos interesses de negcio, sendo a linguagem base para
a construo do sistema, no prevendo nada a respeito do que
deve ser implementado na linguagem de aspectos.
2 - Linguagem de aspectos: responsvel pela implementao
de estruturas que iro definir o comportamento de um aspecto
e a forma como este ser executado.
3 - Combinador de aspectos (aspect weaver): semelhante a um
compilador, porm no gera um programa compilado e sim,
um novo cdigo que combina os componentes escritos em
linguagem de componentes com os escritos em linguagem
de aspectos.
Introduo ao AspectJ
Para a implementao dos conceitos de POA, foi criada pela
equipe da Xerox Parc, em 1997, o AspectJ (ver seo Links), que
atua basicamente como uma extenso da linguagem Java. Alm
dos elementos oferecidos pela POO (Programao Orientada
a Objetos) como classes, mtodos e atributos, dentre outros,
so acrescentados novos conceitos e construes ao AspectJ,
apresentados a seguir:
49
Pontos de Juno ou Join Points: so pontos na execuo

do programa Java onde o aspecto ser aplicado como, por
exemplo, em chamadas de mtodos, chamadas de construtores, execuo de tratamento de excees, pr-inicializao de
objetos, dentre outros.
Pontos de Corte ou Pointcut: so construes que permitem
indicar em que join points o aspecto ir interceptar a execuo
da aplicao. Ou seja, ele indica em que situaes o aspecto
entrar em ao. Possui a seguinte sintaxe: pointcut <nome>
(argumentos): corpo;
Para que um pointcut seja definido, necessrio que haja pelo
menos um designador, que seria a situao de interceptao
pelo aspecto. O designador se localiza no corpo da declarao
do pointcut. A Tabela 1 mostra os principais designadores e
suas funes.
Advice: os pointcuts selecionam em que pontos de juno
sero executadas as aes de determinado aspecto, porm
quem indica esse comportamento so os advices. Existem trs
tipos de advices:
before: executado antes da ao do join point que foi definido
no pointcut. Sua sintaxe bsica : before(): <nome do pointcut>{
<corpo> }
after: executado depois da ao do join point que foi definido
no pointcut. Sua sintaxe bsica : after(): <nome do pointcut>{
<corpo> }
Existem ainda trs variaes desse advice:
Designador
call(Signature)
execution(Signature)
get(Signature)
set(Signature)
this(Type pattern)
target(Type pattern)
args(Type pattern)
within(Type pattern)
handler(ExceptionType)
after(): ser sempre executado;

after() returning: s ser executado caso o join point
(normalmente um mtodo) retorne algo, caso ele no chegue
a essa linha, esse advice nunca ser executado;
after() thowing: ser executado caso o join point (normalmente um mtodo) lance uma exceo.
around: ser executado no lugar do join point que foi definido
no pointcut. Dentro desse advice ainda pode-se chamar a execuo do join point original. Sua sintaxe bsica : around():<nome
do pointcut>{ <corpo> }
Declarao entre tipos ou Inter-Type: so declaraes de
membros e classes que interferem na hierarquia e estrutura
de classes do programa Java. A sintaxe para a declarao de
um atributo a seguinte:
<modificador de acesso> <tipo> <nome da classe>.<nome
do atributo> = <atribuio>;
Caso os atributos ou mtodos sejam declarados com modificador de acesso private, ficaro restritos ao escopo do aspecto, caso sejam declarados como public, podem interferir no
programa Java, causando conflitos caso haja outros membros
com o mesmo nome.
Aspectos ou Aspects: so unidades que modularizam os interesses transversais (crosscutting concern), atravs do encapsulamento dos pontos de juno, pontos de corte, advices e declaraes
entre tipos. Sua declarao bsica : aspect <nome do aspecto> {}
Funo
call (String Cliente.salvarDados()); interceptar toda chamada ao mtodo salvarDados()

existente na classe Cliente, que tenha como tipo de retorno uma String.
execution (boolean Cliente.defineCategoria(Categoria c)); interceptar a execuo do
mtodo defineCategoria(Categoria c) existente na classe Cliente, que tenha como tipo de
retorno um booleano.
Os atributos definidos em get sero interceptados toda vez em que forem get(String Cliente.nome); interceptar os acessos varivel nome, da classe Cliente.
acessados. Sua identificao feita de acordo com a assinatura definida.
Os atributos definidos em set sero interceptados toda vez em que forem set(String Cliente.nome); interceptar as atribuies feitas varivel nome, da classe Cliente.
atribudos. Sua identificao feita de acordo com a assinatura definida.
O tipo definido em this, indica que qualquer ponto de juno em que o objeto this(cliente); interceptar os pontos de juno que definam o tipo da instncia cliente.
corrente uma instncia de Type (uma classe qualquer) ser interceptado. Desta
forma, pode-se utilizar a referncia instncia Type para disponibiliz-la a outros
componentes do AspectJ.
O tipo definido em target indica que qualquer ponto de juno em que o objeto target(cliente); interceptar os pontos de juno que definam o tipo da instncia cliente.
alvo uma instncia de Type (uma classe qualquer) ser interceptado. Desta
forma, pode-se utilizar a referncia instncia Type para disponibiliz-la a outros
componentes do AspectJ.
Qualquer declarao de argumentos que respeitem a ordem e os tipos definidos Args(int,int); capturar no pointcut declaraes que contenham dois inteiros como
em args ser interceptada.
argumento, disponibilizando-os aos advices.
Qualquer join point que ocorra em uma instncia de Type ser interceptado.
within(Cliente) interceptar qualquer join point que ocorra na classe cliente.
Qualquer join point que declarar o tipo da exceo em handler ser interceptado. handler(IOException); interceptar todo join point que declare uma exceo do tipo
IOException.
Tabela 1. Designadores de pointcuts.
50
Exemplo
Os mtodos/construtores declarados em call sero interceptados sempre que

forem chamados. Sua identificao feita de acordo com a assinatura definida.
Os mtodos/construtores declarados em execution sero interceptados durante
sua execuo. Sua identificao feita de acordo com a assinatura definida.
Desenvolvimento
Ambiente de desenvolvimento
Esta seo tem como objetivo explicar a instalao da ferramenta AJDT para o melhor entendimento da utilizao de
aspectos, de modo que no sero abordadas todas as funcionalidades, somente as de maior relevncia. A ferramenta j
possui a linguagem AspectJ integrada, portanto, basta installa para iniciar um projeto utilizando aspectos.
Para instalar a AJDT, necessrio clicar na opo Help /
Software Updates / Find and Install. Na janela seguinte devese selecionar a opo New Remote Site e, logo em seguida,
ser necessrio nomear o plug-in que ser instalado. Para
o exemplo, nomeamos de AJDT e, no campo URL, deve ser
colocada a URL de instalao do plug-in, conforme a Figura
3. De acordo com a verso do Eclipse, a URL de download
pode ser diferente e, no estudo de caso, utilizou-se a verso
3.2. Para saber mais detalhes sobre outras URLs de instalao
deve-se visitar o site do AJDT (seo Links).
Figura 4. Informaes sobre a instalao da AJDT
Para a criao de um novo projeto que utilize o AspectJ,

clique com o boto direito do mouse em qualquer rea branca do Package Explorer e selecione New / Project / AspectJ
Project / Next. Na janela que ser exibida, deve-se nomear
o projeto. No estudo de caso, o nomeamos como CadastroClientes (ver Figura 5).
Figura 3. Instalao do plugin da AJDT
Clicando em OK, ser exibida uma janela mostrando a ferramenta que ser instalada. Selecione-a e clique em Next. Na
janela seguinte, basta aceitar o termo de compromisso e clicar
novamente em Next. Na prxima janela, deve-se clicar em
Finish. A partir desse momento ser efetuado o download da
ferramenta. Aps isso, ser apresentada uma janela para a instalao do plug-in, que exibir as informaes sobre o que ser
instalado (ver Figura 4). Clique em Install All. Aps completar
a instalao, ser exibido um aviso recomendando restartar o
Eclipse e, para que a instalao tenha efeito, clique em Yes.
Estudo de caso
Utilizaremos um fragmento de cdigo de um sistema de
cadastro de clientes e trataremos de um interesse sistmico
bsico, o logging, que ser utilizado para registrar todas as
possveis excees geradas pelo sistema.
Figura 5. Janela de criao de um projeto AspectJ
Clique em Finish para finalizar a criao do Projeto. Aps

criado, podemos inserir pacotes e classes como se estivssemos em um projeto Java. O diferencial que podemos criar
aspectos tambm. Para isso, clique com o boto direito sobre
o nome do projeto ou pacote desejado e escolha a opo New
/ Other, localize a pasta AspectJ e, aps expandi-la, escolha a
opo Aspect (ver Figura 6).
51
responsvel pela declarao de uma classe. Em seu lugar, ser

encontrada a declarao de um aspecto atravs da palavra
chave aspect. Logo aps a declarao do aspecto, declaramos
tambm o pointcut no qual queremos que o aspecto incida,
atravs das seguintes linhas extradas da Listagem 1:
pointcut tratamentoExcecao(Exception e): handler(Exception+)
&& !within(this) && args(e);
Figura 6. Criao de um aspecto.
Aps selecionar esta opo, clique em Next. Na tela seguinte,

ser necessrio nomear o aspecto. No estudo de caso o nomeamos como TratarExcecoes, clicando em Finish para finalizar sua
criao. O arquivo criado tem extenso .aj. A Listagem 1 mostra o cdigo fonte do aspecto, que ser explicado em seguida.
O propsito desse aspecto tratar todas as excees geradas
pelo sistema e inseri-las em um log, indicando a classe e o problema que ocorreu. Para isso, utilizamos tambm o log4j, uma
API que permite escrever em arquivos e/ou exibir mensagens
previamente configuradas no console da IDE, como auxlio
depurao de cdigo. O log4j no o foco do artigo, para mais
informaes acesse o site cujo endereo est na seo Links.
A primeira linha aps as importaes das classes faz a
declarao do aspecto, que foi nomeado como TratarExcecoes. importante verificar a ausncia da palavra-chave class
Assim, apresenta a declarao do pointcut cujo nome tratamentoExcecao e que tem como argumento um objeto do tipo
Exception. Aps a declarao, comeamos a definir em que join
points o nosso pointcut ir atuar. O designador handler indica que
interceptar qualquer ponto do programa que declarar uma
exceo do tipo Exception ou, como o indicado no caractere
+, qualquer uma de suas subclasses.
Alm de handler, utilizamos tambm o designador within
que, nesse caso, no considera as excees declaradas dentro
do prprio aspecto, indicado pelo operador de negao !. Por
fim, o args captura os argumentos passados como parmetros
no pointcut. seu dever expor o contexto (informao capturada
do join point, no caso a referncia ao objeto Exception) desejado
para que o advice possa us-lo. Resumindo, a funo desse
pointcut tratar todas as excees que ocorram no programa,
desconsiderando as excees que possam ocorrer dentro do
prprio aspecto e capturando a exceo lanada.
No estudo de caso, utilizamos alguns operadores e caracteres
especiais. Caso algum deles fossem trocados, a forma como o
pointcut interceptaria os join points seria alterada. A Tabela 2 lista
os caracteres especiais que podem ser utilizados no AspectJ.
Caractere
Funo
Qualquer subclasse da classe informada antes do caractere
Qualquer seqncia de caractere, no contendo pontos
..
Qualquer seqncia de caractere, podendo conter pontos
Tabela 2. Caracteres especiais do AspectJ
Listagem 1. Aspecto TratarExcecoes

package aspectos;
import java.io.IOException;
import java.io.InputStream;
import java.util.Properties;
import org.apache.log4j.BasicConfigurator;
import org.apache.log4j.Logger;
import org.apache.log4j.PropertyConfigurator;
public aspect TratarExcecoes {
pointcut tratamentoExcecao(Exception e): handler
(Exception+) && !within(this) && args(e);

before(Exception e): tratamentoExcecao(e){

Object o = thisJoinPointStaticPart.
getSourceLocation();

getLogger(o, e);
}

private static Logger logger = null;

52
ublic Logger getLogger(Object o, Exception excecao){

p
if (logger == null) { //logger ainda nao configurado
Properties propriedades = new Properties();

InputStream fis = getClass().getClassLoader().
getResourceAsStream
(log4j.properties);
try {

propriedades.load(fis);
} catch (IOException e) {
BasicConfigurator.configure()
((Logger)Logger.getLogger()).error(e);
}
PropertyConfigurator.configure(propriedades);
((Logger)Logger.getLogger(geral)).error
((+o.toString()+) - + excecao);
}
return logger;
}
}
Desenvolvimento
Aps a declarao do pointcut, declaramos um advice, que

ir executar uma ao especificada nele. No estudo de caso,
sua funo escrever a mensagem de exceo capturada no
pointcut tratamentoExcecao em um log, conforme as linhas
abaixo, extradas da Listagem 1:
before(Exception e): tratamentoExcecao(e){
Object o = thisJoinPointStaticPart.getSourceLocation();

getLogger(o, e);

}
O advice ser aplicado antes da execuo dos join points,

interceptados no pointcut. Isso fica explcito ao utilizarmos
o tipo before. Como o objetivo escrever a exceo em um
log e trabalhar com o pointcut tratamentoExcecao, devemos declarar no advice o argumento declarado no pointcut
(Exception e). Aps a declarao do advice, deve-se mostrar
a qual pointcut este ser vinculado. Essa situao est representada no trecho tratamentoExcecao(e) no qual tambm
captura a referncia exceo declarada, atravs da varivel
de referncia e.
A ao do advice s inicializada na linha seguinte, onde se
obtm o objeto thisJoinPointStaticPart para retornar a localizao (atravs do mtodo getSourceLocation()) de onde ocorreu
o erro no programa de componentes e o atribui varivel de
referncia o, do tipo Object. Logo abaixo o mtodo getLogger
chamado, passando como parmetro as referncias aos objetos
obtidos anteriormente.
No exemplo, foi utilizado um objeto reflexivo para recuperar
a localizao de onde a exceo ocorreu no programa Java.
Reflexo a capacidade de um programa reconhecer detalhes
internos em tempo de execuo que no estavam disponveis
no momento da compilao do programa. Existem trs objetos
que utilizam a reflexo para retornar informaes sobre onde
o aspecto est sendo executado. Eles podem ser chamados em
qualquer lugar de um advice:
thisJoinPoint: contm informaes dinmicas (objetos,
variveis, etc.) sobre o join point.
thisJoinPointStaticPart: contm informaes estticas
(nome, assinatura, etc.) sobre o join point.
thisJoinPointEnclosingStaticPart: contm informaes
estticas (nome, assinatura, etc.) sobre o contexto que contm o
join point. Caso o ponto de juno seja uma chamada de mtodo,
o contexto a execuo do mtodo onde feita a chamada.
Dentro do prprio advice declaramos uma varivel esttica
logger, do tipo Logger, que ser utilizada para realizar o
logging das excees. Logo aps essa instruo, declaramos
o mtodo getLogger que o responsvel pela insero das
mensagens de exceo. Este mtodo poderia estar dentro de
uma classe, porm, como o objetivo deixar o cdigo do programa de componentes o mais conciso possvel, com apenas
mtodos que tratam de interesses do negcio da aplicao,
ele foi inserido no prprio aspecto. Basicamente, no escopo
do mtodo um objeto do tipo InputStream configurado de
acordo com o arquivo de propriedades log4j.properties, localizado na raiz do projeto, e a exibio da mensagem de erro
acionada. O ponto principal desse mtodo, de acordo com a
abordagem POA, apresentada na linha abaixo, extradas do

mtodo getLogger da Listagem 1:
((Logger)Logger.getLogger(geral)).error((+o.toString()+)-+
excecao);
As referncias o e excecao foram criadas atravs do

objeto reflexivo e da captura da mensagem de erro, respectivamente. Isso s foi possvel com o uso do advice, que permitiu
a manipulao dos objetos e a passagem de suas referncias
ao mtodo getLogger(), o que tornou o cdigo mais simples
e de fcil leitura.
A seguir, na Listagem 2, ser exibido um trecho de cdigo
de uma classe Java que pode lanar excees. O cdigo bem
simples e foi criado apenas a ttulo de demonstrao de como
o cdigo na linguagem de componentes se comportar. Os
locais onde podem ser lanadas excees foram destacados
para facilitar a visualizao do cdigo.
Listagem 2. Mtodo main da classe Principal.java

public static void main(String[] args) {
try{

BufferedReader buf = new BufferedReader(new
InputStreamReader(System.in));

Integer opcao = 0;
do{
System.out.println(**Menu**);
System.out.println(Escolha uma
opo);
System.out.println(1 - Cadastrar
Cliente);
System.out.println(2 - Sair);
opcao = Integer.parseInt
(buf.readLine());
String nome = null;
Integer telefone= null;
String endereco= null;

switch(opcao){

case 1:{

System.out.println(Digite
o nome do cliente:);

nome = buf.readLine();
System.out.println(Digite
o telefone do cliente:);
telefone = Integer.
parseInt(buf.readLine());
System.out.println(Digite o
endereo do cliente:);

endereco = buf.readLine();

Cliente cliente = new
Cliente(null, nome,
endereco, telefone);

ClienteDAO clienteDAO =
(ClienteDAO)GenericDAO.
getDAO(cliente);

clienteDAO.save(cliente);

}

}

}
while(opcao == 1);

}
catch(Exception e){

}
}
Pode-se notar que as possveis excees foram tratadas

atravs dos blocos try e catch mas, na verdade, no h nenhum
tipo de tratamento dentro do catch. o aspecto TratarExcecoes
que incidir sobre essa declarao e realizar toda a ao.
Nesse contexto, podero surgir diversas dvidas, uma delas
53
o porqu devem-se declarar os blocos try/catch se iremos tratar

todas as excees no aspecto. Devemos declar-los, pois em
vrios pontos do cdigo, chamamos mtodos que so possveis
candidatos a lanar excees e o compilador Java nos fora a
trat-los ou lan-los (atravs da clusula throws), justamente
pelo fato do programa Java no saber absolutamente nada
sobre o aspecto. Ao se deparar com um mtodo que declara
lanar uma exceo (throws), o AspectJ no consegue capturla e, por isso, no exemplo foram utilizados os blocos para o
tratamento da mesma.
Para rodar a aplicao, basta clicar com o boto direito do
mouse sobre o nome do projeto, selecionar Run / Aspect/Java
Application. Caso seja necessrio, uma janela ser exibida para
a escolha da classe principal, ou seja, que contm o mtodo
main. Aps escolh-la, clique em Ok.
Aps rodar o sistema, uma exceo pode ser forada ao
no preencher o telefone do cliente. Como o telefone
necessrio para a converso a ser realizada, o programa
lana uma exceo e pra sua execuo, alm de adicionar
a seguinte linha no log de erros: 16/01/09 10:51 ERROR
(Principal.java:42) - java.lang.NumberFormatException: For
input string: . O aspecto registra essa linha atravs do
mtodo getLogger(), que basicamente configura e carrega
as especificaes do arquivo de propriedades do log4j e,
atravs das referncias o (que a localizao de onde foi
lanada a exceo) e exception (que a exceo), as informa
no log, registrando-as.
escolha as opes Visualiser e Visualiser Menu, clicando

em OK (ver Figura 7). Na parte inferior da IDE, sero
exibidos os dois visualizadores escolhidos.
Clique sobre o nome do projeto (CadastroClientes),
localizado no Package Explorer, e o visualizador exibir
as classes do sistema. Para identificar as classes que podem ser interceptadas pelo aspecto, basta observar que
as mesmas so exibidas em branco com uma marcao
em azul, que indica a posio dos pontos de juno que
foram especificados no aspecto. As classes que no sero interceptadas, ou seja, que no possuem os pontos
de juno definidos, so representadas em preto (ver
Figura 8). A linha azul indica a incidncia do aspecto
TratarExcecoes.
Figura 8. Visualizao dos possveis join points que tratam excees
Utilitrios da ferramenta AJDT

A ferramenta AJDT possui alguns mecanismos para a visualizao de como um determinado aspecto est incidindo
sobre as classes do sistema. Para exibir o visualizador, no
menu Window, escolha a opo Show View / Other. Na
janela que ser exibida, expanda o diretrio Visualiser, e
Figura 7. Visualizadores da ferramenta AJDT
54
Como possvel observar na figura, existem apenas

dois lugares que tratam excees, e que poderiam ser
capturados pelo aspecto. Um deles na classe Principal.
java e o outro no prprio aspecto, mais precisamente no
mtodo getLogger. A indicao de que h um ponto de
juno declarado em determinado local no garante que
o mesmo ser realmente interceptado, pois isso depende
das regras definidas no pointcut. Neste exemplo, estamos
capturando todos os lugares que tratam excees, exceto dentro do prprio aspecto, embora este esteja sendo
classificado, atravs da figura, como sendo um local de
possvel interceptao.
Ainda neste visualizador, existem opes exibidas no
canto superior direito:
Zoom in : aumenta o zoom de visualizao das classes
afetadas.
Zoom out
: diminui o zoom de visualizao das
classes afetadas.
Fit to view
: expande as classes de forma que sua
visualizao se ajusta ao tamanho da tela.
Limit visualization to affected bars : limita a exibio
somente s classes afetadas pelo aspecto (ver Figura 9).
Change to group view
: exibe os possveis join points
onde o aspecto poder interceptar, organizados por pacotes
(ver Figura 10). Pode-se notar que as classes de cada pacote
continuam sendo exibidas, s que agrupadas.
Change to member view : exibe os possveis join points
onde o aspecto poder interceptar, organizados por classes,
que a opo padro.
O Visualiser Menu (ver Figura 11) exibe o nome do
Desenvolvimento
Figura 11. Visualiser Menu

Figura 9. Visualizao limit visualization to affected bars
Concluso
Este artigo mostrou alguns dos principais fundamentos e
caractersticas do AspectJ, uma extenso da linguagem Java
que implementa a programao orientada a aspectos, visando a manutenibilidade e reusabilidade de cdigo, atravs da
modularizao de interesses sistmicos. O AspectJ se mostra
muito eficiente, principalmente pelo fato de integrar-se aos
conceitos da OO. Uma das suas principais vantagens o fato
do programa principal no saber nada a respeito dos aspectos,
o que o torna independente e coeso.
aspecto, ao lado de uma caixa de seleo de cores e um componente de seleo. Esta caixa indica a cor de identificao
do aspecto quando este for exibido no Visualiser. Neste caso,
utilizamos a cor padro, que azul. Caso o projeto tenha mais
de um aspecto, cada um poder ter uma cor que o representa
para que possa ser identificado facilmente atravs das classes
ou pacotes do projeto. Essa cor pode ser trocada, bastando-se
clicar sobre a caixa de seleo de cores. A outra opo a habilitao (ou no) da exibio do aspecto no Visualizer.
log4j
http://logging.apache.org/log4j

Feedback
eu
edio
ta
AJDT
http://www.eclipse.org/ajdt/downloads
55
sobre e
s
Figura 10. Visualizao change to group view.
D
s
Links
Engenharia de Software
Graduao (bacharelado) em Engenharia de Software
Proposta pedaggica de curso de graduao (bacharelado) em Engenharia de Software. Noutras
palavras, organizao do curso (escritrio de
projetos e fbrica de software), disciplinas, instrumentos didticos e outros.
Fbio Nogueira de Lucena

Para que serve?
fabio@inf.ufg.br
Professor associado do Instituto de Informtica (UFG), Doutor em computao (Unicamp),

PMP, Implementador do MPS.BR(r), SCJA, SCJP,
SCWCD e SCMAD.
Auri Marcelo Rizzo Vincenzi

auri@inf.ufg.br
Professor adjunto do Instituto de Informtica

(UFG), Doutor em computao (ICMC/USP
e University of Texas at Dallas) e particularmente interessado em testes de software.
Juliano Lopes de Oliveira

juliano@inf.ufg.br
Professor associado do Instituto de Informtica (UFG), Doutor em computao (Unicamp),

Diretor de pesquisa da Estratgia Tecnologia
da Informao Ltda (empresa Avaliadora do
MPS.BR) e atualmente possui intensa atuao em implementao, avaliao e melhoria
de processos de software.
Plnio de S Leito Jnior

plinio@inf.ufg.br
Doutor em computao.
56
educao em Engenharia de
Software , seno o fator de
maior influncia, um dos mais
relevantes na capacidade de produo
de software de um pas. Neste artigo
apresentada uma proposta de formao
de um perfil altamente qualificado para
o desenvolvimento de software tanto
para o mercado local quanto global.
O egresso deste curso deve adquirir
uma base slida e sustentvel para uma
promissora carreira na indstria de
software. O curso inovador em vrios
aspectos ao adotar prticasmais efetivas
para a formao do egresso e surge no
contexto de uma comunidade formada
por quase mil empresas de TI.
Engenharia de Software Magazine - Engenharia de Software
Permitir que profissionais em atuao discutam e

forneam orientaes acerca de como se aprender
Engenharia de Software.Tais profissionais sabem
o que relevante, como dominar esta rea e assim
por diante.Tradicionalmente, atuais profissionais
so oriundos de cursos como Cincia da Computao, Engenharia de Computao, Sistemas de
Informao e outros como Matemtica e engenharias, por exemplo. Em tais cursos, em geral,
Engenharia de Software tema de uma disciplina
e, portanto, a rea no tratada adequadamente.

O ensino de Engenharia de Software pode ser
considerado um fator importante e de grande
impacto na capacidade de produo de software
de um pas. Portanto, este um tema de interesse
dos atuais profissionais, agremiaes de empresas produtoras de software, alm de instituies
de ensino interessadas em iniciativas similares.
Educa o
Contexto
Software parte de praticamente todo e qualquer sistema
moderno. Em conseqncia, a formao do profissional
que produz tal objeto torna-se interesse de muitos, seja
por questes ticas ou profissionais. Adicionalmente, a
demanda existente por mo-de-obra qualificada tem crescido mais do que a oferta, o que comumente apresentado
como motivo de preocupao para o crescimento do setor
em muitos pases. Em Gois h iniciativas em curso por
meio do Arranjo Produtivo Local de Software, capitaneado
pelo SEBRAE-GO e pela comunidade de empresas do setor,
que engloba cerca de mil empresas. O objetivo expandir
a atuao das empresas deste grupo no valioso mercado
de software.
A definio e abertura do curso de Engenharia de Software contribui com estas iniciativas, e insumo de outra que
visa a elaborao de uma verso do curso a ser explorada
completamente por meio da TV Digital.
O curso superior em Engenharia de Software forma bacharis, ou seja, o egresso no engenheiro. Embora no seja
comum no Brasil, existe uma quantidade grande de cursos
com este foco ao redor do mundo, onde o primeiro deles
encontra-se em atividade desde 1985, no Imperial College
(Londres) [1]. Houve significativo esforo para acomodar
o que de melhor orientaes da ACM [2] e IEEE Computer
Society [3] oferecem, juntamente com normas internacionais, a anlise de outros cursos similares pelo mundo, e a
experincia do Instituto de Informtica (responsvel pelo
curso) acumulada em mais de duas dcadas de ensino superior e mais de uma dezena de especializaes na rea, alm
do curso de mestrado em computao. Tal instituto uma
unidade da Universidade Federal de Gois (UFG).
No restante do texto fornecida uma viso panormica do
projeto pedaggico, compilada dos aspectos considerados
mais relevantes e ditada pelo espao disponvel. O projeto
pedaggico na ntegra pode ser obtido em [4].
Fundamentao do curso
O escopo do conhecimento abordado pelo curso baseouse no Software Engineering Body of Knowledge (SWEBOK) [5].
Neste sentido, o curso no inventa ou exerce um perigoso
papel de definir o que faz parte ou no da Engenharia
de Software. Ao contrrio, limita-se ao que o documento
sugere. Convm ressaltar, contudo, que a forma de trabalhar este conhecimento confere personalidade distinta a
cada curso.
Em [1] so apresentadas vrias orientaes acerca da organizao de cursos de graduao em Engenharia de Software.
semelhana deste e de outros documentos empregados,
no se teve a pretenso de segui-los rigorosamente, nem
tampouco de negligenci-los (aqui suficiente esclarecer
que algumas decises se espelharam em contribuies aqui
reutilizadas). Em geral, escolhas foram estabelecidas em prol
do contexto onde o curso est inserido.
Da perspectiva de processo de software foi eleito o MPS.
BR(r) [6], enquanto gerncia de projetos adota o PMBOK [7].

Naturalmente que as fontes no so excludentes e, neste
caso, a fonte mais especfica foi empregada. Ou seja, embora
o MPS.BR contemple gerncia de projeto, este assunto foi
abordado da perspectiva do PMBOK.
Os danos que podem ser causados por software e a dependncia da sociedade moderna por tais objetos tornam
aspectos ticos relevantes. Neste sentido, o curso adota o
cdigo de tica [8] como base para a postura esperada do
egresso do curso.
Quando se pensa em mercado global imprescindvel
alinhar a linguagem empregada pelo fornecedor com uma
fonte respeitada internacionalmente e acessvel aos clientes.
Neste caso, o padro IEEE Std 12207-2008 [9] prescreveu a
lngua adotada. Embora relevante, esta norma no suficiente para atender padres de qualidade capazes de conferir
distino entre fornecedores de software. Da mesma forma,
esta norma til profissionalizao da engenharia de
software ao mesmo tempo em que tambm no suficiente
para tal. Para tratar estas questes, em todas as disciplinas
do curso (assunto de outra seo deste artigo), onde aplicvel
e disponvel, normas internacionais foram adotadas. Por
exemplo, a disciplina Gerncia de Projetos destaca o padro
IEEE Std 1058-1998 [10] para a documentao do plano de
um projeto. De forma similar, para a documentao a ser
oferecida aos usurios a referncia o padro IEEE Std
1063-2001 [11]. Estas e outras normas no devem ser equivocadamente interpretadas como restries a serem atendidas.
Ao contrrio, sabe-se que qualquer aplicao inteligente da
engenharia de software exige a personalizao do processo
de software para o projeto, para a equipe que ir execut-lo
e condizente com a cultura da organizao. Isto nos remete
a outro padro, IEEE Std 1074-2006 [12].
Outro componente tpico da definio de cursos superiores
a perspectiva tecnolgica. Neste caso, foi adotada Java
e tecnologias correlatas como eixo principal para unir
disciplinas. O objetivo potencializar o que se aprendeu
em um semestre naqueles vindouros. Por exemplo, caso se
adota Java como linguagem de programao ao aprender a
programar, ento esta mesma linguagem ser ainda mais
dominada ao trmino da disciplina de Estrutura de Dados.
Desta forma, ao ilustrar programao distribuda usando
Java, faz-se uso de base j conhecida e oferece ao estudante a
possibilidade de lidar com as dificuldades da programao
distribuda sem se distrair com idiossincrasias sintticas de
outras linguagens. Dito isto, Java e tecnologias correlatas
pode ser substituda por outra. Acreditamos, contudo, que
a adoo clara de uma trilha tecnolgica aconselhvel, e
com resultados diferentes de se adotar mais de uma, o que
consideramos ser o mesmo resultado quando no se adota
nenhuma especfica. Por fim, a escolha tambm deve ser
compatvel com o perfil dos docentes.
Estas foram as principais bases de fundamentao do curso. Estar fundamentado em fontes respeitadas, contudo, no
suficiente. A dinmica do curso igualmente relevante.
57
Curso orientado por projetos

Internalizar os conceitos da Engenharia de Software exige
preparao. Para tal optou-se pela execuo de projetos.
Tudo no curso ocorre no mbito de um ou mais projetos.
Ou seja, o curso tratado como uma organizao baseada
em projetos (no funcional nem matricial). Isto vlido
para a gesto propriamente dita do curso (administrao)
e para o principal servio que oferece: ensino. Neste ltimo
caso os projetos podem ser classificados em acadmicos
(h um projeto para cada estudante do curso) e naqueles
executados no mbito da Fbrica de Software (principal
laboratrio do curso).
Sabemos que uma Fbrica de Software no bem-vista por
todos. Independente do significado atribudo, para o curso
se resume no ambiente onde a Engenharia de Software
instanciada.
O primeiro tipo de projeto tem como objetivo a formao do estudante no tempo, no custo e com a qualidade
esperados. Destes itens talvez o custo merea pequena
observao: custo de um estudante dado pela razo da
quantidade de horas que o estudante levou em disciplinas
pela quantidade de horas do curso (perto de 3000 horas).
Naturalmente, quanto maior a razo maior o custo, onde
o custo esperado 1. Este custo pode ser inferior a 1.0, caso
ocorram aproveitamentos.
O segundo tipo de projeto visa complementar a formao
do estudante, seja por criar oportunidade de contato com
assunto alm do contedo das disciplinas ou por fomentar o
exerccio prtico do conhecimento distribudo entre elas. Por
exemplo,o desenvolvimento de uma aplicao para o iPhone pode envolver o emprego de Objective-C (apenas para
ilustrar que o mundo no se resume trilha tecnolgica
adotada nas disciplinas e discutida anteriormente).
Para gerenciar todos estes projetos necessria uma organizao distinta do que encontramos normalmente.
Ou seja, o estudante ter que cumprir satisfatoriamente

cinqenta edies desta disciplina. Esta a disciplina que
permite a prtica de Engenharia de Software por meio da
participao em projetos, da o nome pacote de trabalho
(elemento de mais baixo nvel em uma Estrutura Analtica
de Projeto ou da conhecida sigla em ingls WBS). Duas
outras disciplinas envolvem mais de uma edio: Leitura
de Software e Integrao. Cada uma destas ocorre em oito
edies, ou seja, o estudante estar matriculado nestas
duas disciplinas em todos os oito semestres previstos para
a concluso do curso.
As disciplinas do curso so apresentadas classificadas
conforme as vrias reas que contribuem com o curso.
Outras interpretaes so admissveis. Tentou-se seguir a
classificao apresentada pelo SWEBOK [5], onde a Engenharia de Software possui corpo de conhecimento prprio
e apoiado sobre outras reas como Cincia da Computao
e Matemtica. A classificao apresentada abaixo distribui
as disciplinas do curso em quatro grupos: (a) Gerncia de
Projeto; (b) Matemtica, (c) Cincia da Computao e (d)
Engenharia de Software. A exceo a disciplina Pacote de
Trabalho, que pode ser atribuda a qualquer uma destas quatro reas, uma outra rea ou combinao destas. Detalhes
sobre esta disciplina so fornecidos adiante. Desta forma,
excetuando-se a disciplina Pacote de Trabalho, a distribuio
de percentuais por estas quatro reas , respectivamente:
15%, 1%, 40% e 43%, conforme ilustrado na Figura 1. Adicionalmente, se considerarmos uma possvel distribuio das
800 horas atribudas a Pacote de Trabalho, o resultado tambm
ilustrado na Figura 1, onde os percentuais relativos podem
passar por mudana considervel.
Organizao do curso
Projetos da Fbrica de Software so definidos pelo escritrio
de projetos, que tambm responsvel pela gesto destes e
daqueles acadmicos (um para cada estudante). Por exemplo,
atribuio do escritrio de projetos selecionar e detalhar
projetos relevantes para execuo no mbito da Fbrica, bem
como o acompanhamento dos projetos por meio de ndices
(conforme sugerido acima). Tambm responsabilidade
desta unidade organizacional, entre outras, a alocao de
professores para ministrar disciplinas, por exemplo. Ou seja,
o trabalho comumente atribudo coordenao de um curso
superior passa para o Escritrio de Projeto. Coordenador
do curso, docentes e funcionrios so distribudos entre
estas unidades.
Estrutura curricular
Algumas disciplinas do curso ocorrem em mais de uma
edio. Por exemplo, Pacote de Trabalho perfaz um total de
800 horas, distribudas em 50 edies de 16 horas cada.
58
Figura 1. Percentuais de carga horria do curso por rea de contribuio

sem contemplar as edies da disciplina Pacote de Trabalho (grfico da
esquerda), e contemplando-as (grfico da direita)
Atente-se para o fato de no estarem includas as disciplinas optativas nos grficos acima. Algumas destas incluem
Pesquisa Operacional e Engenharia Econmica. A primeira til
no tratamento de alguns problemas. A segunda, de grande
relevncia para empreendimentos que visam produzir software, em particular porque tais iniciativas envolvem valores
no desprezveis.
Educa o
Gerncia de Projeto contribui com Gerncia de Projeto de

Software e Integrao. Matemtica contribui com Matemtica
Discreta. A Cincia da computao (rea de base da Engenharia
de Software) contribui com:
Introduo Computao;
Introduo Programao;
Estrutura de Dados;
Arquitetura de Computadores;
Banco de Dados;
Redes de Computadores;
Sistema Operacional;
Linguagens de Programao;
Interao Homem-Computador;
tica, normas e postura profissional;
Integrao de Aplicaes;
Desenvolvimento de Software Concorrente;
Desenvolvimento de Software para Persistncia;
Desenvolvimento de Software para a Web;
Construo de Software;
Tcnicas Avanadas de Construo de Software.
As disciplinas de Engenharia de Software incluem:
Introduo Engenharia de Software;
Mtodo de Desenvolvimento de Software;
Engenharia de Software;
Requisitos de Software;
Processo de Software;
Segurana;
Projeto Detalhado de Software;
Arquitetura de Software;
Gerncia de Configurao de Software;
Qualidade de Software;
Verificao e Validao;
Manuteno de Software;
Mtodos e Ferramentas da Engenharia de Software;
Mercado interno e externo de software;
Leitura de Software.
A ementa de cada uma destas disciplinas est detalhada
no projeto pedaggico do curso [4]. A descrio da ementa
de cada disciplina contm, alm do que convencionalmente
oferecido: (a) o processo pertinente disciplina segundo o
MPS.BR [6]; (b) o mesmo para o padro IEEE Std 12207-2008
[9] e (c) as tecnologias pertinentes disciplina (segundo a
trilha Java adotada), dentre outras informaes. Trs disciplinas, contudo, merecem destaque, Integrao, Leitura de
Software e Pacote de Trabalho, por no serem encontradas em
cursos similares.
Integrao tem como principal objetivo manter em sintonia todo o curso, ou seja, manter docentes, discentes e
as unidades organizacionais mencionadas acima sintonizadas. Por exemplo, esta disciplina ser empregada como
instrumento de comunicao para distribuir informaes
e gerenciar expectativas. Aes como esta poderiam ser
informalmente executadas pela coordenao do curso,
o que incompatvel com a nfase na gesto de projetos

adotada no curso e carente na regio, mesmo porque exige
esforo no s da administrao, mas tambm de membros de um projeto (os estudantes). Tem efeito similar
rea de integrao conforme o PMBOK [7]. Esta disciplina
compulsria, todo estudante estar matriculado nesta
disciplina em todos os semestres do curso, assim como
na disciplina Leitura de Software.
Leitura de Software, como sugere o nome, uma
disciplina onde se l software. Da mesma forma que
estudantes de literatura lem clssicos, engenheiros de
software tambm devem estar ambientados com bons
exemplares do que eles iro produzir. Isto comum em
vrias outras reas. Por exemplo, estudantes de artes
dedicam-se observao de ensaios fotogrficos. Engenheiros civis analisam plantas disponveis de obras.
Estudantes de medicina estudam laudos emitidos por
especialistas. O mesmo fazem estudantes de direito sobre
processos julgados. Acreditamos que benefcio similar
obtido por estas outras profisses tambm se aplica
engenharia de software.
A familiaridade com o cdigo aberto de um produto de
sucesso, por exemplo, permite que o estudante crie um
referencial til aos empreendimentos com os quais ir se
envolver. Desde a formatao do cdigo, arquitetura de
software, solues e tecnologias adotadas, at questes
como a gerncia de configurao e gesto do projeto,
dentre outras, podem ser exploradas e contribuir com
a formao do egresso. Por fim, em mais uma tentativa
de esclarecer e elucidar o objetivo e justificativa desta
disciplina, convm ressaltar que a produo de software
nos dias atuais faz uso extensivo de padres (padres
de projeto, padres de anlise, padres arquiteturais e
outros). Um padro permite reutilizar conhecimento
que se mostrou til em determinado domnio, ou seja,
no so exatamente produzidos, mas aproveitados de
empreendimentos anteriores. Um bom engenheiro de
software deve ser capaz de ler um software e perceber
aspectos positivos e negativos.
Pacote de Trabalho. Esta a disciplina com maior carga
horria total: 800 horas. Em cada edio, a ementa correspondente definida por um pacote de trabalho (pedao
do esforo de um projeto). Projeto este que pode estar em
execuo na Fbrica de Software ou ser o projeto acadmico
de cada estudante. No primeiro caso a nfase est na prtica
da Engenharia de Software, no segundo, na complementao da formao do estudante. Estes objetivos podem
estar combinados em um nico projeto. Por exemplo, um
projeto em execuo na Fbrica de Software pode conter
pacotes de trabalho para desenvolver, implementar e testar
algoritmo paralelo para usufruir do grande nmero de ncleos presente nas atuais placas grficas. Naturalmente, em
tal projeto tambm devem constar pacotes de trabalhos dedicados a treinamento no ambiente de desenvolvimento em
questo, inclusive na linguagem empregada e fundamentos
59
60
Links e referncias
[1] Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering, ACM
e IEEE Computer Society, 2004.
[2] Association for Computing Machinery. URL: http://www.acm.org/.
[3] IEEE Computer Society. URL: http://www.computer.org/.
[4] Projeto Pedaggico do Curso Superior em Engenharia de Software. URL: http://
engenhariadesoftware.inf.br/.
[5] Software Engineering Body of Knowledge (SWEBOK). URL: http://www.swebok.org/.
[6] Melhoria de Processo do Software Brasileiro (MPS.BR). URL: http://www.softex.br/mpsbr/.
[7] A Guide to the Project Management Body of Knowledge (PMBOK), 4th edition, PMI, 2008.
[8] Software Engineering Code of Ethics and Professional Practice. URL: http://www.acm.org/
about/se-code.
[9] IEEE Std 12207-2008, Systems and software engineering - Software life cycle processes.
[10] IEEE Std 1058-1998, IEEE Standard for Software Project Management Plans.
[11] IEEE Std 1063-2001, IEEE Standard for Software User Documentation.
[12] IEEE Std 1074-2006, IEEE Standard for Developing a Software Project Life Cycle Process.
[13] Software Engineering Education in India: Issues and Challenges, Kirti Garg e Vasudeva
Varma, 21st CSEET, 2008.

Feedback
eu
sobre e
s
A seo anterior exibe a concentrao de esforos nas disciplinas de Engenharia de Software. Em um curso de Engenharia
de Software parece natural. Convm, contudo, apresentar uma
fundamentao, baseada na percepo da maturidade do contexto
local (empresas de TI). As informaes abaixo omitiram propositadamente valores e percentuais, mas fornecem uma noo do
desenvolvimento das empresas da regio conforme percebido
pela academia.
Da perspectiva de pessoal, neste contexto, observa-se clara presena de dois tipos de profissionais: aqueles hbeis em aspectos de
construo (baixo nvel) e hbeis administradores (alm do escopo
deste texto). Dito de outra forma, em sua maioria, localmente
encontram-se profissionais com desenvoltura em ferramentas
de controle de verso, mas que praticamente desconhecem gerncia de configurao. H pessoas a frente de projetos, mas que
desconhecem e no aplicam tcnicas de medida de desempenho
como valor agregado. H pessoas responsveis por garantia da
qualidade, mas que a reduz a testes e assim por diante. Um indicador a formao dos profissionais em atividade. Em pesquisa
recente, um percentual pequeno era formado (qualquer que seja
o curso superior).
Da perspectiva das empresas, neste contexto, observam-se iniciativas para melhoria do cenrio corrente, mas ainda de resultados tmidos para a economia do estado. So poucas empresas com
iniciativas de melhoria de processos de software, por exemplo. So
poucas as empresas entre as maiores, conforme estudo anual da
revista INFO (em geral destacam-se apenas trs empresas).
Trata-se de um cenrio que, respeitando excees, tem muito
a crescer. No preciso muito esforo para detectar que dentre
quase mil empresas que produzem software, justamente Engenharia de Software uma rea pouco dominada. Todo o curso
foi elaborado com base nesta concluso. Respeitando diferenas
de maturidade, a carncia de profissionais em Engenharia de
Software no um problema localizado, mas atual e que ocorre
em outras partes [13].
Software conhecido pelo mercado vultoso. Participar deste

mercado de forma efetiva no se faz apenas com vontade, nem
mesmo suficiente uma equipe empreendedora com boas
idias. Se no houver competncia, no sentido de conhecimento, habilidade e atitude, ento provavelmente no haver
o sucesso. O curso de Engenharia de Software apresentado tem
como viso ser um vetor reconhecido na produo de software e no
progresso regional por meio da atuao de seus egressos. Para
atingir isto o curso se concentra na competncia do profissional que pretende formar. Acreditamos que esta uma ao
imprescindvel para o progresso deste setor (qualquer que seja
a regio) e capaz de trazer frutos para a sociedade.
D
s
Por que tais disciplinas em nfase?
Consideraes finais
edio
ta
sobre o assunto. Neste sentido, a disciplina Pacote de Trabalho

tambm um instrumento poderoso de adaptao do curso.
O exemplo tambm no por acaso, mas para ilustrar que
pesquisa, estudantes do mestrado e do curso podemcoexistir
em um mesmo projeto. Em tempo, o mesmo vlido para a
extenso, pois um projeto pode ter como patrocinador uma
empresa, pode ser gerenciado por uma empresa, pode ter
como membros funcionrios experientes de uma empresa
(alm de estudantes do curso). Nesta outra perspectiva, a
disciplina Pacote de Trabalho tambm oferece mecanismo
de integrao entre ensino, pesquisa e extenso.
Educa o
AMIGO
Existem coisas
que no
conseguimos
ficar sem!
...s pra lembrar,

sua assinatura pode
estar acabando!
Renove J!
www.devmedia.com.br/renovacao
Para mais informaes:
www.devmedia.com.br/central
61
62

Engenharia de Software - Edição 10

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Engenharia de Software - Edição 10

Cargado por

Copyright:

Formatos disponibles

Conhecimento

Capa ESM - Final .pdf

Entenda os principais conceitos sobre

Conhea os principais conceitos envolvidos

Entenda o conceito de Arquitetura de Software e

Melhore seus processos atravs da

Veja como integrar conceitos de

Veja como integrar o Processo

Mais de 60 mil downloads

Faa j sua assinatura digital! | www.devmedia.com.br/es

Ano 1 - 10 Edio - 2009

Rodrigo Oliveira Spnola

Fale com o Editor!

Marco Antnio Pereira Arajo

vontade para entrar em contato com os editores e dar a sua sugesto!

Eduardo Oliveira Spnola

24 - Documento de Requisitos - Essencial ao Desenvolvimento de Software

30 - Gerncia de Reutilizao de Software

36 - Melhorando a Qualidade do Software e Otimizando Recursos com Teste baseado em Riscos

48 - Programao Orientada a Aspectos

56 - Engenharia de Software - Graduao (bacharelado) em Engenharia de Software

Engenharia de Software Magaz ine

Introduo Programao Extrema (XP)

Danilo Sato Desenvolvedor, Coach e Consultor da ThoughtWorks UK. Com formao

os ltimos anos, os mtodos

Engenharia de Software Magazine - Introduo Programao Extrema (XP)

Neste artigo so apresentadas algumas

Para que serve?

Em que situao o tema til?

surgiu o Manifesto do Desenvolvimento gil de Software

Edio 10 - Engenharia de Software Magazine

forma um grupo distinto, porm todas seguindo os mesmos

Lean Software Development

Feature Driven Development (FDD)

Adaptive Software Development

Dynamic System Development Method (DSDM)

Engenharia de Software Magazine - Introduo Programao Extrema (XP)

Uma comunidade que compartilha os mesmos valores e

Edio 10 - Engenharia de Software Magazine

para acompanhamento do projeto tambm so importantes

Engenharia de Software Magazine - Introduo Programao Extrema (XP)

esto trabalhando. Os times devem analisar seus sucessos

Edio 10 - Engenharia de Software Magazine

Engenharia de Software Magazine - Introduo Programao Extrema (XP)

o tempo real gasto vai ser geralmente maior. Portanto, so

Edio 10 - Engenharia de Software Magazine

Diminuio da Equipe: Conforme a equipe melhora sua

automatizem todo o processo de entrega, possibilitando

Comparao com as Prticas da Primeira Verso

Engenharia de Software Magazine - Introduo Programao Extrema (XP)

modelagem definida por Eric Evans, conhecida como Design

Adaptaes das Prticas de XP

Tabela de Comparao entre as prticas de XP

Ciclo Semanal, Implantao Incremental e Implantao Diria

Desenvolvimento Dirigido por Testes Desenvolvimento Dirigido por Testes

Histrias, Ciclo Semanal, Ciclo Trimestral e Folga

Cliente com os Desenvolvedores

Time Completo e Envolvimento Real com o Cliente

Propriedade Coletiva do Cdigo

Cdigo Compartilhado e Repositrio de Cdigo Unificado

Trabalho Energizado e Folga

Tabela 1. Comparao entre as prticas da primeira e da segunda edio

Retrospectivas: prtica originada na Famlia Crystal [17]

Edio 10 - Engenharia de Software Magazine