Engenharia de Software

engenharia
Saiba seu significado e para que serve

magazine
de software
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 Projeto
Conhea os principais conceitos envolvidos Entenda o conceito de Arquitetura de Software e
na Engenharia de Requisitos como trabalhar com os Estilos Arquiteturais

Especial Processos
Melhore seus processos atravs da Veja como integrar conceitos de Veja como integrar o Processo
anlise de risco e conformidade Modelos Tradicionais e geis Unificado ao desenvolvimento Web
 Atendimento ao Leitor

engenharia

magazine
A DevMedia conta com um departamento exclusivo para o atendimento ao
leitor. Se voc tiver algum problema no recebimento do seu exemplar ou

de software
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) 2220-5375
Ano 1 - 1 Edio 2007 - - Impresso no Brasil
Kaline Dolabella
Gerente de Marketing e Atendimento
kalined@terra.com.br
Corpo Editorial (21) 2220-5375

Colaboradores Publicidade
Rodrigo Oliveira Spnola Para informaes sobre veiculao de anncio na revista ou no site entre
rodrigo@sqlmagazine.com.br em contato com:

Marco Antnio Pereira Arajo Kaline Dolabella

Eduardo Oliveira Spnola publicidade@devmedia.com.br

Fale com o Editor!

muito importante para a equipe saber o que voc est achando da revista: que tipo de
Editor de Arte
Vinicius O. Andrade artigo voc gostaria de ler, que artigo voc mais gostou e qual artigo voc menos gostou.
viniciusoandrade@gmail.com Fique a vontade para entrar em contato com os editores e dar a sua sugesto!
Se voc estiver interessado em publicar um artigo na revista ou no site SQL Magazine,
Capa entre em contato com os editores, informando o ttulo e mini-resumo do tema que voc
Vinicius O. Andrade gostaria de publicar:
viniciusoandrade@gmail.com
Rodrigo Oliveira Spnola - Colaborador
Na Web editor@sqlmagazine.com.br
www.devmedia.com.br/esm

Apoio Parceiros:

NDICE
NDICE
04 - Alguns Fundamentos da Engenharia de Software
Wilson de Pdua Paula Filho
10 - Melhorando Processos Atravs da Anlise de Risco e Conformidade
Rafael Espinha, Joo Sousa

22 - Agilidade ou Controle Operacional? Os dois!

Alexandre Bartie

28 - O processo unificado integrado ao desenvolvimento Web

Rodrigo S. Prudente de Aquino

38 - Arquitetura de Software
Antonio Mendes da Silva Filho

46 - Introduo Engenharia de Requisitos

Ana Luiza vila e Rodrigo Oliveira Spnola

54 - Introduo a Teste de Software

Arilo Cludio Dias Neto

60 - Gesto de defeitos
Cristiano Caetano
68 - Introduo Inspeo de Software
Marcos Kalinowski e Rodrigo Oliveira Spnola
EDITORIAL
Engenharia de Software a aplicao de abordagens siste- Alguns Fundamentos da Engenharia de Software
mticas, disciplinadas e quantificveis no desenvolvimento Melhorando Processos Atravs da Anlise de Risco e Con-
e manuteno de software. Desta forma, se preocupa em formidade
como realizar as diversas atividades envolvidas no processo Agilidade ou Controle Operacional? Os dois!
de desenvolvimento de software de forma que se tenha um O Processo Unificado Integrado ao Desenvolvimento Web
produto elaborado com maior qualidade e menor custo. Arquitetura de Software: Desenvolvimento orientado para
Neste contexto, uma rea de conhecimento bastante arquitetura
abrangente envolvendo desde atividades mais tcnicas como Introduo Engenharia de Requisitos
programao at reas mais gerenciais como controle de Introduo a Teste de Software
qualidade nos processos utilizados. Gesto de defeitos: Ferramentas Open Source e melhores
Embora a Engenharia de Software seja um tema bastante prticas na gesto de defeitos
abordado em diferentes congressos de escopo nacional e in- Introduo Inspeo de Software: Aumento da
ternacional, a indstria brasileira ainda carente de conhe- qualidade atravs de verificaes intermedirias
cimento nesta rea. H carncia na difuso de conhecimento
em diferentes reas, por exemplo: engenharia de requisitos, Desejamos uma tima leitura!
gerncia de projetos, processo de desenvolvimento de sof-
tware, inspeo e teste de software, metodologias geis, Equipe Editorial Engenharia de Software Magazine
controle de qualidade.
Todos sabem que importante, mas o saber como fazer
ainda uma realidade um pouco distante, embora procurada.
Aliado a isso, no existe uma revista especializada no as-
sunto, e os detentores do conhecimento esto, na maioria
das vezes, em centros acadmicos. Se por um lado temos
o conhecimento necessrio concentrado em alguns profis-
sionais, por outro lado, temos um vasto campo, formado por Rodrigo Oliveira Spnola
profissionais e empresas que tm interesse no assunto, mas rodrigo@sqlmagazine.com.br
no tm acesso fcil a informaes tcnicas da rea. Doutorando em Engenharia de Sistemas e Computao (COPPE/UFRJ).
Mestre em Engenharia de Software (COPPE/UFRJ, 2004). Bacharel em
Neste contexto a DevMedia - editora das revistas ClubeDel-
Cincias da Computao (UNIFACS, 2001). Colaborador da Kali Software
phi, .Net Magazine, SQL Magazine, Java Magazine e WebMo-
(www.kalisoftware.com), tendo ministrado cursos na rea de Qualidade
bile est lanando no mercado editorial brasileiro a Enge-
de Produtos e Processos de Software, Requisitos e Desenvolvimento Orien-
nharia de Software Magazine. Esta preencher uma lacuna
tado a Objetos. Consultor para implementao do MPS.BR. Atua como
que existe no mercado editorial brasileiro - Engenharia de Gerente de Projeto e Analista de Requisitos em projetos de consultoria na
Software Aplicada. O objetivo levar ao mercado brasileiro COPPE/UFRJ. Colaborador da Engenharia de Software Magazine.
de desenvolvimento de software conceitos e prticas asso-
ciadas ao uso da engenharia de software. As principais re-
as de conhecimento abordadas sero (no esto limitadas
a estas): Engenharia de Requisitos; Anlise de Sistemas;
Modelagem de Software; Metodologias de Desenvolvimento
de Software; Orientao a Objetos; UML Unified Modeling
Marco Antnio Pereira Arajo
(maraujo@devmedia.com.br)
Language; Processos de Desenvolvimento Software; Verifica-
Doutorando e Mestre em Engenharia de Sistemas e Computao pela
o, Validao e Teste; Projeto de Sistemas; Programao;
COPPE/UFRJ Linha de Pesquisa em Engenharia de Software, Especialista
Manuteno de Sistemas; Planejamento e Gerncia de Proje- em Mtodos Estatsticos Computacionais e Bacharel em Matemtica com
to; Qualidade de Software; Mtricas de Software; Ferramen- Habilitao em Informtica pela UFJF, Professor dos Cursos de Bacharelado
tas CASE; Modelos de Maturidade; Arquiteturas de Software; em Sistemas de Informao do Centro de Ensino Superior de Juiz de Fora
Componentes de Software; Padres de Projeto; Usabilidade; e da Faculdade Metodista Granbery, Analista de Sistemas da Prefeitura de
Refatorao de Cdigo. Juiz de Fora. editor da Engenharia de Software Magazine.
Aliada revista, ser lanado o Portal da Engenharia de
Software Magazine cujo objetivo complementar os assun-
tos abordados na revista atravs da publicao de artigos e
vdeo aulas.
O objetivo e principal motivador desta iniciativa termos no
Eduardo Oliveira Spnola
(eduspinola@gmail.com)
cenrio Nacional uma base de conhecimento em Engenharia
Editor das revistas Engenharia de Software Magazine, SQL Magazine,
de Software Aplicada. Vrios sero os beneficiados, desde
WebMobile. bacharel em Cincias da Computao pela Universidade
empresas e profissionais da rea de software at estudan-
Salvador (UNIFACS) onde atualmente cursa o mestrado em Sistemas e
tes em nvel de graduao e ps-graduao. Computao na linha de Engenharia de Software, sendo membro do GESA
Esta primeira edio traz nove artigos escritos por profis- (Grupo de Engenharia de Software e Aplicaes).
sionais altamente qualificados no mercado e nos centros de
pesquisa:

Edio 01 - Engenharia de Software Magazine 3

 Alguns Fundamentos da Engenharia de
Software
Wilson de Pdua Paula Filho
(wppf@ieee.org)
Engenheiro Mecnico pelo ITA, Doutor em
Engenharia Eltrica pela Escola Politcnica da
USP, Professor Titular aposentado do Departa-
mento de Cincia da Computao da UFMG.
Autor dos Livros Engenharia de Software:
Fundamentos, Mtodos e Padres e Multi-
mdia: Conceitos e Aplicaes. Atualmente
consultor em Engenharia de Software e traba-
lha no Synergia Laboratrio de Engenharia
de Software e Sistemas da UFMG.
4 Engenharia de Software Magazine Alguns Fundamentos da Engenharia de Software
O que Engenharia de Software?
a mesma coisa que Cincia da Com-
putao? Ou uma entre muitas espe-
cialidades da Cincia da Computao?
Ou dos Sistemas de Informao, ou do
Processamento de Dados, ou da Inform-
tica, ou da Tecnologia da Informao? Ou
uma especialidade diferente de todas
as anteriores?
Na maioria das instituies brasileiras
de ensino superior, o conjunto de co-
nhecimentos e tcnicas conhecido como
Engenharia de Software ensinado em
uma ou duas disciplinas dos cursos que
tm os nomes de Cincia da Computao,
Informtica ou Sistemas de Informao.
Raramente, em mais disciplinas, muitas
vezes opcionais, e muitas vezes oferecidas
apenas em nvel de ps-graduao. Algu-
mas instituies oferecem cursos de ps-
graduao em Engenharia de Software,
geralmente no nvel de especializao.
O uso do termo para designar uma
carreira profissional tambm no muito
comum, mesmo em organizaes que pro-
duzem grande quantidade de software, ou
at naquelas em que o desenvolvimento
de software atividade fim. Programas
e exames de certificao em Engenharia
de Software so pouco conhecidos, ao
contrrio do que acontece com algumas
linguagens e tecnologias usados por esses
profissionais.
Em outros pases, a situao um pouco
diferente. Algumas universidades ameri-
canas oferecem programas de graduao,
mestrado e doutorado na rea. O IEEE
(Institute of Electrical and Electronics Engi-
neers), principal organizao internacional
de profissionais de Engenharia Eltrica,
atravs da Computer Society, que forma o
seu ramo em Computao, oferece a qua-
lificao de Profissional Certificado para
o Desenvolvimento de Software.
Cincia, Engenharia e Valor
Sem pretender fazer distines defini-
tivas, vamos explorar o que dizem os di-
cionrios. O Dicionrio Aurlio Eletrnico
V.2.0 assim define Cincia e Engenharia:

Cincia - Conjunto organizado de conheci-
mentos relativos a um determinado objeto, es-
pecialmente os obtidos mediante a observao, a
experincia dos fatos e um mtodo prprio.
Engenharia - Arte de aplicar conhecimen-
tos cientficos e empricos e certas habilitaes
especficas criao de estruturas, dispositi-
vos e processos que se utilizam para converter
recursos naturais em formas adequadas ao
atendimento das necessidades humanas.
V-se que, pelas definies acima, a
Cincia focaliza acumulao do conheci-
mento atravs do mtodo cientfico, com
base em experimentos e observaes. J
a Engenharia aplica esses conhecimen-
tos ao atendimento das necessidades
humanas. Embora o conhecimento seja
certamente uma necessidade humana,
trata-se de uma entre vrias outras,
sejam necessidades materiais, como
alimentao, moradia, segurana, ou
imateriais, como afeio ou auto-estima.
A tudo aquilo que satisfaz a necessidades,
atribui-se um valor. A Engenharia est,
portanto, ligada noo de valor, e a En-
genharia de Software busca gerar valor
com o processamento de informao. A
noo de valor tem muitas conseqn-
cias prticas importantes, e, de fato, a
teoria conhecida como Engenharia de
Software Baseada em Valor representa
uma importante escola de pensamento
dentro da rea.
Arte, Tcnica, Artesanato, Indstria?
Outros termos constantes da definio
de Engenharia podem ser explorados
de vrias formas, com conseqncias
interessantes. Por exemplo, usada a
palavra Arte, que o mesmo dicionrio
define como a capacidade que tem o
homem de pr em prtica uma idia,
valendo-se da faculdade de dominar a
matria, ou a utilizao de tal capa-
cidade, com vistas a um resultado que
pode ser obtido por meios diferentes.
Na Engenharia de Software, a matria
dominada pelas faculdades humanas
consiste em mquinas de processamento
da informao, devidamente configura-
das e programadas. Nesse sentido, os
conceitos de Arte e Tcnica so bem
prximos; alis, a palavra grega techn
significa, exatamente, Arte.
O termo Arte abre outras discusses.
No poucos programadores se conside-
ram como artistas, no sentido de pratican-
engenharia
tes das Belas Artes, e valorizam critrios tosos, e, em certos casos, at riscos vida
estticos na criao de seus programas. humana; muitas vezes empreendimentos
Isso pode ter conseqncias boas e ruins, de software so afetados por um contexto
do ponto de vista de gerar valor. Por um econmico, poltico ou social.
lado, a busca da elegncia pode levar
economia e simplicidade de formas, Produtos e Ciclos de Vida
fazendo com que resultados de melhor A ntima relao entre a Engenharia de
qualidade sejam obtidos de maneira mais Software e a noo de valor significa que
produtiva. E, principalmente, levando essa profisso trata o software como pro-
a escrever programas que possam ser duto. Esto fora do escopo da Engenharia
mais facilmente reutilizados, mantidos e de Software programas que so feitos
expandidos. Por outro lado, a auto-satisfa- com objetivo exclusivamente ldico: a
o do programador pode ter como preo diverso do programador. Esto fora de
A ntima relao entre a Engenharia de Software e a noo
de valor significa que essa profisso trata o software como
produto.
os interesses de quem est pagando pelo seu escopo tambm pequenos programas
trabalho dele, ou de quem o usar. Seja, descartveis, feitos por algum apenas
por exemplo, produzindo programas que para resolver um problema dessa pessoa,
ningum entende, seno o prprio autor e que no sero utilizados por outros.
(e, depois de certo tempo, nem ele mesmo). Mas, se um desses programas interessar
Seja, como outro exemplo, introduzindo a outras pessoas, e assim passar a ter va-
funes que o autor achou interessantes, lor, aparecero demandas para melhorar
mas no so realmente necessrias, nem suas qualidades, aumentar suas funes,
foram solicitadas. prolongar sua vida. E aparecer quem
E muito prxima de Arte est a esteja disposto a investir nisso, com a
palavra Artesanato, que lembra pro- expectativa de ganhar dinheiro. Nesse
duo caseira, em pequena escala, sem momento, o programa entrou no escopo
a utilizao de mtodos industriais, que da Engenharia de Software e se tornou um
so caracterizados pela padronizao e produto. Muitos dos produtos de software
pela repetio. E, realmente, parece mais mais usados seguiram esse caminho.
difcil aplicar esses mtodos industriais Todo produto tem usurios: aqueles que
na confeco de software, do que nos efetivamente usam o produto. Alguns
ramos da engenharia do mundo material. produtos so feitos por encomenda de um
Nestes, as leis fsicas impem limites cliente: aquele que pagar por sua produ-
claramente visveis ao que pode ser feito. o. Outros, chamados de produtos de
Na Engenharia de Software, a criativida- prateleira, so vendidos no mercado aber-
de no limitada por leis fsicas, e sim to, a quem se interessar. Neste caso, quem
pela capacidade humana de entender e faz o papel do cliente quem define que
dominar a complexidade. recursos e funes se esperam do produto;
Mas no se pode escapar do fato de que a talvez um departamento de vendas, ou de
Engenharia de Software tem que resolver marketing, ou de definio de produtos de
muitos problemas de ordem industrial. uma organizao, ou at, para produtos
Raramente possvel construir software menores, os prprios desenvolvedores, co-
profissional sem envolver equipes, s ve- locando o chapu de investidores de risco.
zes de dezenas ou at centenas de pessoas; E existem todos os casos intermedirios,
raramente possvel trabalhar na rea em que um produto parcialmente pronto
sem a presso de prazos e oramentos completado, adaptado ou incrementado,
apertados; freqentemente defeitos de por encomenda de um cliente.
software podem acarretar prejuzos vul- Como todo produto industrial, o produ-
Edio 01 Engenharia de Software Magazine 5
to de software tem seu ciclo de vida:
ele concebido para tentar atender a
uma necessidade;
especificado, quando essas necessida-
des so traduzidas em requisitos viveis;
desenvolvido, transformando-se
em um conjunto formado por cdigo e
outros itens, como modelos, documentos
e dados;
passa por algum procedimento de
aceitao e entregue a um cliente;
entra em operao, usado, e sofre
atividades de manuteno, quando ne-
cessrio;
retirado de operao ao final de sua
vida til.
O ciclo de vida compreende muitas ativi-
dades, que so assunto das diferentes re-
as da Engenharia de Software. A Figura 1
mostra um modelo do ciclo de vida do sof-
tware, usando a notao conhecida como
UML (Unified Modeling Language). Essa
Figura 1. Modelo UML do ciclo de vida do software
6 Engenharia de Software Magazine Alguns Fundamentos da Engenharia de Software
notao usada para descrever muitos
aspectos diferentes do desenvolvimento
de software, inclusive as seqncias de
atividades que compem esse desenvol-
vimento. O tipo especfico de diagrama
que mostrado na figura o Diagrama de
Atividades, que representa uma evoluo
dos tradicionais fluxogramas, usados pe-
los programadores h dcadas.
interessante observar que a codifica-
o, que representa a escrita final de um
programa em forma inteligvel para um
computador, apenas uma pequena parte
do ciclo de vida. Muitas pessoas, inclu-
sive alguns profissionais da informtica,
acham que a codificao a nica tarefa
de um engenheiro de software.
Nos Diagramas de Atividades da UML,
a bolinha cheia representa Incio; a boli-
nha com um anel adicional representa
fim; cada retngulo simples de cantos
arredondados representa uma ao, ou
seja, uma atividade simples, da qual no
mostram detalhes; cada seta representa
uma transio entre atividades; as barras
paralelas representam incio e trmino
de atividades executadas em paralelo;
um retngulo de cantos arredondados
com detalhes internos representa uma
atividade estruturada, que composta
de outras atividades.
Projetos, Atividades e Estruturas
Analticas
Normalmente, o software desenvolvi-
do dentro de projetos. Todo projeto tem
uma data de incio, uma data de fim, uma
equipe e outros recursos. O responsvel
por um projeto chamado de gerente de
projeto. O trabalho realizado dentro de um
projeto pode ser descrito por um conjunto
de atividades, que podem possuir relaes
de dependncia, paralelismo, e decom-
posio em atividades mais elementares,
como no diagrama da Figura 1.
As atividades so delimitadas por mar-
cos, isto , pontos que representam esta-
dos significativos do projeto. Geralmente,
os marcos so associados a resultados
concretos: documentos, modelos ou por-
es do produto, que podem fazer parte
do conjunto prometido aos clientes, ou
ter apenas utilizao interna ao projeto. O
prprio produto um resultado concreto
associado ao marco de concluso do pro-
jeto, que pode ser utilizado sozinho, ou
como componente de um sistema.
O PMI (Project Management Institute)
uma organizao internacional, com
sees em muitos pases, inclusive o
Brasil, que tem o objetivo de promover e
difundir boas prticas de gesto de pro-
jetos. Para isso, administra programas de
certificao de profissionais nessa rea, e
publica o guia conhecido PMBOK (Project
Management Body of Knowledge).
Nesse guia, define-se um projeto como
um empreendimento temporrio reali-
zado para criar um produto, servio ou
resultado distinto. Um produto, por sua
vez, definido como um objeto produzi-
do, quantificvel e que pode ser um item
final ou um item componente. Uma ativi-
dade definida como um componente de
trabalho realizado durante o andamento
de um projeto.
Os relacionamentos entre as atividades
que compem um projeto so mostrados
em uma estrutura analtica, que o PM-
BOK define como uma decomposio hie-
rrquica orientada entrega do trabalho
 engenharia

a ser executado pela equipe do projeto,
para atingir os objetivos do projeto e
criar as entregas necessrias. Estruturas
analticas de projeto podem ser apresen-
tadas de muitas maneiras. Diagramas de
atividade so uma das representaes
mais usadas atualmente. Outro tipo
de representao usual fornecida por
planilhas e cronogramas, como aqueles
que so produzidos pela ferramenta Mi-
crosoft Project (Figura 2).
Modelos de Referncia e Fatores de
Produo
O PMBOK um exemplo de modelo de
referncia: uma estrutura de conheci-
mento que organiza conceitos, prticas
e padres de uma rea. No caso do
PMBOK, a rea focalizada a gesto de
projetos de qualquer natureza, cobrindo
assuntos como integrao, escopo, tempo,
custos, qualidade, recursos humanos,
comunicaes, riscos e aquisies.
Outro modelo de referncia importante
na Engenharia de Software o CMMI
(Capability Maturity Model Integration), que
foi formulado pelo Software Engineering
Institute da Carnegie-Mellon University. O
CMMI foi encomendado e patrocinado
pelo Departamento de Defesa ameri-
cano, popularmente conhecido como
Pentgono, que o utiliza para avaliao
da capacidade de seus fornecedores de
software. Sendo o Pentgono provavel-
mente a maior organizao compradora
de software do mundo, o CMMI tem
grande aceitao da indstria americana
de software, e considervel influncia no
resto do mundo. A rigor, suas prticas no
so restritas indstria de software, po-
dendo ser aplicadas ao desenvolvimento
de outros tipos de produtos.
Os conceitos do CMMI tm razes em
comum com o PMBOK, como se pode
observar pela similaridade das definies
que adota:
Produto - Resultado que se pretende entre-
gar a um cliente ou usurio.
Projeto - Conjunto gerido de recursos
inter-relacionados, que entrega um ou mais
produtos a um cliente ou usurio, com incio
definido e que, tipicamente, opera conforme
um plano.
Estrutura analtica do projeto - Um ar-
ranjo dos elementos do trabalho e dos relaciona-
mentos deles entre si e com o produto final.
Ao contrrio do PMBOK, o CMMI no
se limita aos conhecimentos sobre gesto
de projetos. Cobre tambm reas tcni-
cas, e focaliza principalmente a aplicao
dos processos ao desenvolvimento de
produtos. Um processo, segundo o IEEE,
uma seqncia de passos executados
com um determinado objetivo; segundo
o PMBOK, um conjunto de aes e
atividades inter-relacionadas, realizadas
para obter um conjunto especificado de
produtos, resultados ou servios.
Um projeto representa a execuo de
um processo, e um processo uma receita
que seguida durante a realizao um

Figura 2. Cronograma de um projeto.

Edio 01 Engenharia de Software Magazine 7

projeto; em outras palavras, o projeto
o empreendimento que concretiza uma
abstrao, que o processo. No se deve
confundir um processo (digamos, uma
receita de bolo) com o respectivo produto
(o bolo) ou com a execuo do processo
atravs de um projeto (a confeco de
um bolo por determinada pessoa, em
determinado dia).
Processos, pessoas e tecnologia consti-
tuem os fatores de produo, que deter-
minam o grau de sucesso dos projetos,
ou seja: se eles conseguem entregar um
produto de qualidade suficiente, dentro
de um prazo aceitvel e com custos vi-
veis. Portanto, desses fatores dependem
a rentabilidade e a sobrevivncia das
organizaes produtoras.
Para muitos profissionais, a tecnologia
o fator mais atraente; muitas vezes, h um
otimismo exagerado quanto aos resulta-
dos da aplicao de novas tecnologias.
Entretanto, tecnologias aparentemente
promissoras podem levar para um beco
sem sada, e, s vezes, tecnologias con-
sideradas inferiores pelos especialistas
lanam razes permanentes, graas a for-
as de mercado. Alm disso, a tecnologia
s se paga quando colocada nas mos de
pessoas capacitadas, trabalhando dentro
de processos adequados. Toda introduo
de nova tecnologia tem uma curva de
aprendizado: as pessoas precisam ser
treinadas, cometem inicialmente muitos
erros e, por isso, podem at se tornarem
8 Engenharia de Software Magazine Alguns Fundamentos da Engenharia de Software
menos produtivas, durante algum tempo.
Algumas tecnologias mais complexas s
se pagam depois de muitos projetos.
Investir na capacitao das pessoas
certamente necessrio. Entretanto, for-
mar pessoas difcil, caro e demorado.
Recrutar pessoas capacitadas tambm:
no h sinais de que a oferta de pessoas
com alta qualificao no desenvolvi-
mento de software venha a se igualar
demanda, em futuro prximo. Alm
disso, muitas pessoas produzem menos
que a sua capacidade permitiria, por
falta de liderana, por deficincia de fer-
ramentas e suporte, ou por inadequao
de processos.
Dos investimentos nos fatores de pro-
duo, os investimentos nos processos
so geralmente aqueles que podem trazer
retorno em prazo mais curto. Processos
tambm no fazem milagres, mas a
melhoria dos processos costuma trazer
benefcios em prazos relativamente cur-
tos, como ilustrado por inmeros relatos
de experincia publicados. No mnimo,
contribuem para reduzir o desperdcio
e o retrabalho, o que geralmente j traz
ganhos muito significativos.
A melhoria dos trs fatores (tecnolo-
gias, pessoas e processos) tambm requer
seu prprio processo: ela deve ser feita
em etapas bem-definidas e controladas,
para que as organizaes, em prazos
relativamente curtos, possam avaliar se
seu investimento est tendo o retorno
esperado. E a principal contribuio de
modelos de referncia como o CMMI
indicar o caminho das pedras e o mapa da
mina: onde a experincia coletada indica
que o investimento em melhorias mais
rentvel, em cada passo da evoluo das
organizaes.
Concluso
A Engenharia de Software visa criao
de produtos de software que atendam as
necessidades de pessoas e instituies e,
portanto, tenham valor econmico. Para
isso, usa conhecimentos cientficos, tc-
nicos e gerenciais, tanto tericos quanto
empricos. Ela atinge seus objetivos de
produzir software com alta qualidade
e produtividade quanto praticada por
profissionais treinados e bem informa-
dos, utilizando tecnologias adequadas,
dentro de processos que tirem proveito
tanto da criatividade quando da raciona-
lizao do trabalho.
Links
SEI
http://www.sei.cmu.edu/
CMMI
http://www.sei.cmu.edu/cmmi/
PMI Brasil
http://www.pmi.org.br/
 Desde 2004 Trazendo Teoria para a Prtica

Treinamento e Consultoria
em Engenharia de Software

Profissionais com ampla experincia prtica (Consusltores Certificados) e

acadmica (Professores Universitrios, Mestres e Doutores)

Know-how para implementar processos de software de acordo com modelos

de qualidade (MPS e CMMI) e maximizar o retorno de investimento

Certificados emitidos pela Kali Software

Cursos 2008: Inscries Abertas Aulas aos sbados na Zona Sul do Rio, prximo ao metr
Para outras localidades, por favor entre em contato

Maro | Abril Processos de Software com nfase em CMMI e MPS 32 horas

Teste de Software 16 horas

Maio |Junho Engenharia de Requisitos 32 horas

Gerncia de Configurao de Software 16 horas

Julho | Agosto Gerncia de Projetos de Software 32 horas

Projeto Orientado a Objetos com UML e Padres 32 horas

Confira as ementas, investementos e condies de pagamento: www.kalisoftware.com

Oferecemos tambm cursos de programao (Java, Java para Web e Ajax)
Inscrio e outras informaes: info@kalisoftware.com

kalisoftware.com | info@kalisoftware.com
 Melhorando Processos Atravs da Anlise de
Risco e Conformidade
Rafael Espinha
rafael.espinha@primeup.com.br
Engenheiro de Computao e Mestre em
Engenharia de Software pela PUC-Rio. Foi
pesquisador do Laboratrio de Engenharia a
de Software da PUC-Rio e atualmente con-
sultor e diretor da PrimeUp, onde desenvolve
projetos na rea de melhoria de processos e
qualidade de software. Possui cursos e certifi-
caes em CMMI e MPS.BR.
Joo Sousa
joaomss@primeup.com.br
Bacharel em Informtica pela UERJ e ps-
graduado pela UFRJ. Possui mais de 15 anos
de experincia no desenvolvimento de sis-
temas e melhoria de processos. Atualmente
consultor da PrimeUp, onde desenvolve
projetos na rea de melhoria de processos e
qualidade de software.
10 Engenharia de Software Magazine Melhorando Processos Atravs da Anlise de Risco e Conformidade
U
m dos fatores importantes para
a construo de um software
de qualidade o processo de
desenvolvimento utilizado e como este
implantado na organizao. A inexistn-
cia ou a no utilizao de processos bem
definidos e de boas prticas de desen-
volvimento, mesmo que informais, faz
com que o desenvolvimento de software
seja realizado de forma ad-hoc, ficando
altamente dependente da experincia e
do conhecimento das pessoas envolvidas.
Este cenrio resulta na realizao de pro-
jetos cujos resultados so imprevisveis,
onde cada um realiza as suas atividades
da forma que lhe convm, e dificulta a
reutilizao de boas prticas e de lies
aprendidas.
Com a crescente demanda por qualida-
de dos produtos de software, a adoo
de modelos de maturidade, normas de
qualidade e guias de boas prticas na
definio de processos tem se tornado
cada vez mais freqente. Modelos como
CMMI-DEV e MPS.BR e normas como a
ISO/IEC 15504 e 12207 definem um con-
junto de boas prticas e caractersticas
que devem estar presentes em um pro-
cesso para que este possa ser gerenciado
e resulte na entrega de produtos de qua-
lidade. Entretanto, como tm o objetivo
de serem aplicveis a quase todo tipo de
organizao, estes modelos ou normas
muitas vezes no definem como estas
boas prticas e caractersticas devem ser
implementadas e implantadas. Uma das
maiores dificuldades de organizaes
que iniciam um programa de melhoria
de processos enfrentam a dificuldade
de adaptar este conjunto de boas prticas
para a sua realidade, identificando quais
reas so mais relevantes e devem ser
abordadas com maior urgncia. Cada or-
ganizao possui polticas, crenas e uma
cultura especfica, que deve ser levada em
conta para que as melhorias sejam bem
aceitas e realmente contribuam com um
desenvolvimento mais eficiente.
Para orientar a necessidade de adapta-
o apresentada acima, utilizamos o con-
 proc esso

ceito de risco associado no utilizao
das boas prticas de desenvolvimento
de software nos projetos e processos da
organizao. Consideramos tambm que
a qualidade do produto (software) est
diretamente relacionada qualidade dos
processos utilizados na sua produo e
ao conhecimento tcnico que os usurios
deste processo tm sobre as prticas de-
finidas (institucionalizao do processo).
Partindo-se destas premissas pode-se
concluir que qualquer risco qualidade e
institucionalizao do processo se refle-
te em riscos na qualidade do produto que
ser entregue e, consequentemente, em
riscos para a organizao. Sendo assim,
aes de gerncia de risco nos processos
podem contribuir diretamente com a
garantia da qualidade do produto final
e fornecem dados que permitem identi-
ficar quais aes devem ser tomadas com
maior urgncia.
Neste artigo apresentamos uma abor-
dagem de anlise de processos na qual
identificado de forma customizada tanto
o nvel de conformidade (quantidade de
recomendaes do modelo de referncia
implementadas nos processos da organi-
zao) quanto o nvel de risco (quantidade
de riscos presentes no processo de desen-
volvimento devido s recomendaes no
implementadas) em cada rea de processo.
Dessa maneira, uma anlise dos processos
da organizao fornece duas classes de
dados para a tomada de deciso e dire-
cionamento de recursos, indicando o que
deve ser feito para melhorar o processo
(conformidade) e quais aes devem ser
tomadas primeiro (risco).
Uma das formas mais indicadas para a
definio e implantao de processos de
maneira eficiente a utilizao de um
ciclo de melhoria contnua. Esta forma
pode ser comparada ao desenvolvimento
iterativo de um sistema, onde o processo
definido e implantado na organizao em
fases direcionadas pelas necessidades e
caractersticas da organizao. O modelo
IDEAL, desenvolvido pelo Software Engi-
neering Institute (SEI), ilustra a utilizao
deste conceito. A implantao deste ciclo
de melhoria faz com que os processos de
uma organizao sejam constantemente
avaliados e melhorados.
No modelo IDEAL destacam-se duas
fases: Diagnstico e Estabelecimento. A
fase de Diagnstico consiste em avaliar o
ambiente produtivo e identificar as opor-
tunidades de melhoria. Em geral, nesta
fase realizado um estudo no qual um
cenrio esperado definido e o cenrio
atual avaliado segundo algum critrio
de qualidade (Gap Analysis). O cenrio
esperado pode ser definido a partir de um
ou mais modelos ou normas de referncia,
como, CMMI-DEV 1.2 ou ISO 9001:2000.
Dessa forma, obtm-se a diferena entre
o que se espera dos processos da organi-
zao e onde eles realmente esto. A partir
da, elaboram-se planos de ao para que
esta distncia seja diminuda ou elimina-
da, a partir da priorizao e seleo dos
planos de ao que sero implantados
(fase de Estabelecimento).
Por mais controlada e precisa que seja a execuo de uma
atividade de desenvolvimento, sempre existe o risco, mes-
mo que muito remoto, de algo dar errado.
A abordagem que apresentaremos
facilita a realizao das fases de Diag-
nstico e Estabelecimento de um ciclo de
melhoria contnua, identificando clara-
mente os riscos associados aos processos
definidos (Diagnstico) e fornecendo um
critrio de priorizao destes riscos (Es-
tabelecimento). Para isso, so utilizadas
uma estratgia de avaliao e atividades
de avaliao e melhoria de processos
de desenvolvimento de software. A
avaliao verifica tanto a dimenso de
conformidade entre o processo e modelos
de maturidade ou normas de qualidade,
quanto dimenso dos riscos que a no vimento, sempre existe o risco, mesmo
utilizao das boas prticas definidas que muito remoto, de algo dar errado.
nestas referncias oferecem qualidade
do produto desenvolvido pela organiza-
o e aos seus objetivos de negcio. Esta
ferramenta tambm indica como estes
pontos podem ser solucionados de forma
que a organizao obtenha uma maior
qualidade ou resultados a partir deste
ciclo. O diferencial desta abordagem a
utilizao da anlise de risco como um
instrumento de priorizao das aes que
devem ser tomadas pelas empresas para
mitigar (reduzir as chances de ocorrn-
cia) os riscos identificados durante a fase
de diagnstico fornecendo um critrio
concreto para definio do escopo de
cada ciclo de melhoria.
A prxima seo apresenta alguns
conceitos bsicos sobre riscos e como
este conceito utilizado neste domnio.
Em seguida a estratgia e a ferramenta
que compem a abordagem sero apre-
sentadas e um exemplo da sua utilizao
ser discutido.
Anlise de Risco
Risco a exposio chance de perdas
ou danos. Embora exista tambm uma
chance de alguma coisa sair melhor do
que o esperado, o risco geralmente cos-
tuma ser associado a possveis perdas ou
danos. O conceito de risco resulta da incer-
teza quanto a eventos futuros e parte de
todas as atividades de desenvolvimento.
Um processo de desenvolvimento bem
definido e institucionalizado visa reduzir
a chance de ocorrncia de ameaas (perdas
ou danos). Toda oportunidade de sucesso
sempre carrega consigo uma possibilidade
de falha, cabendo a cada empresa avaliar
a relao risco versus retorno e determinar
se estar sujeito a esta perda aceitvel,
se este evento muito grave, ou ainda
se o procedimento para a mitigao no
oferece um retorno satisfatrio.
Por mais controlada e precisa que seja a
execuo de uma atividade de desenvol-
Este fato decorre do grande nmero de
variveis que podem influenciar no resul-
tado final e da sua natureza muitas vezes
imprevisvel. A partir desse cenrio,
torna-se necessrio aprender a conviver
com riscos, minimizando suas possveis
conseqncias negativas.
As principais atividades da disciplina
de gerncia de riscos so:
Identificao corresponde identifi-
cao dos riscos inerentes a uma etapa do
desenvolvimento (fase, processo, itera-
o). Isto feito atravs do levantamento
das ameaas presentes e do impacto que
podem provocar caso se realizem.
Anlise corresponde reflexo so-

Edio 01 Engenharia de Software Magazine 11

bre os riscos identificados, a partir da
identificao do nvel de exposio de da distribuio e do impacto dos riscos.
cada projeto. tambm realizado um
estudo de classificao dos riscos no qual,
baseando-se no relacionamento entre a
exposio e conseqncia negativa do
risco e o benefcio da oportunidade, de-
termina-se quais sero eliminados, quais
sero mitigados, quais sero aceitveis e
quais sero acompanhados.
Planejamento observa e determina
como e quando os riscos sero aborda-
dos ao longo do projeto. Comumente
so elaborados planos de mitigao,
eliminao e acompanhamento de riscos
que sero utilizados como base para a
gerncia de riscos.
A eliminao total dos riscos associados a um projeto ou
iniciativa um conceito utpico.
Controle corresponde execuo e ao
acompanhamento dos planos elaborados
para o projeto. Os riscos identificados
so analisados constantemente para a
identificao do seu estado atual e atu-
alizao dos planos elaborados. Novos
riscos podem ser identificados tambm.
A gerncia de riscos utiliza como base o
conceito de exposio de risco. Para cada
ameaa ou possvel fonte de problema
que possa causar perdas ao projeto, a
exposio (Exp) definida como o pro-
duto da probabilidade da perda ocorrer
(P) e do tamanho da perda (impacto I
no projeto, artefato, ativo ou qualquer
elemento que seja o foco da anlise de
risco): Exp = P * I .
Na abordagem apresentada, o conceito
de exposio foi estendido, permitindo
uma melhor determinao do impacto
da concretizao de um risco. Para cada
ativo da organizao ou projeto avaliado
(pessoa que participa do desenvolvimen-
to ou processos utilizados) determinado
um ndice de exposio balanceado. Este
ndice, denominado PSR, determina a
exposio atravs da probabilidade da
ocorrncia do risco (P), a severidade
dessa ocorrncia para o projeto ou para
a organizao (S) e a relevncia do ativo
da organizao (pessoa ou processo) na
qualidade do produto final. Dessa forma
12 Engenharia de Software Magazine Melhorando Processos Atravs da Anlise de Risco e Conformidade
possvel obter um retrato mais preciso
foco de uma avaliao mais rigorosa e
A estratgia de diminuio de riscos
utilizada nos planos elaborados durante
a atividade de planejamento pode tentar
reduzir sensivelmente a probabilidade do
risco se realizar, fazendo com que a con-
cretizao da perda seja algo muito difcil
de ocorrer. possvel tentar reduzir o
impacto do risco, fazendo com que a con-
seqncia da materializao dele seja to
pequena que a sua ocorrncia pouco afe-
tar o resultado final do projeto. Por fim,
possvel reduzir tanto a probabilidade
quanto a severidade do risco, resultando
em um balanceamento razovel entre as
possveis perdas e a probabilidade de sua
ocorrncia no projeto.
A eliminao total dos riscos associados
a um projeto ou iniciativa um conceito
utpico. Cada ao de identificao,
acompanhamento e controle (reduo,
mitigao ou conteno de riscos) possui
um custo associado, cabendo a cada indi-
vduo ou organizao identificar o ponto
de equilbrio entre o nvel de exposio
aos riscos e o custo de reduo. Para cada
projeto ou iniciativa deve-se determinar
um ndice aceitvel de exposio aos restritos ao nvel das diretivas do modelo
riscos, que seja suficiente para as carac-
tersticas do projeto e tenha um custo que
no comprometa os resultados.
A Estratgia de Avaliao
A estratgia de avaliao que utiliza-
remos se baseia no conceito de anlise
de risco na verificao dos processos
de uma organizao e compreende os
conceitos apresentados na ISO/IEC 17799.
Esta estratgia recomenda a avaliao
de uma equipe de desenvolvimento ou
processo de software em duas etapas,
onde a primeira (etapa de Abrangncia)
representa uma verificao mais abran-
gente e menos rigorosa da implementao
dos modelos e normas de referncia, para
identificar quais so as reas crticas para
a organizao (onde est o problema). Na
etapa seguinte (etapa de Profundidade)
so definidas quais reas devem ser o
da prxima iterao do ciclo de melhoria
contnua (qual o problema e como ele
pode ser solucionado). Em cada uma
das etapas, so realizadas as fases de
Diagnstico (identificao dos riscos) e
Estabelecimento (priorizao e definio
dos planos de ao). Na etapa de Abran-
gncia o diagnstico mais abrangente e
os planos de ao so menos detalhados e,
na etapa de Profundidade, o diagnstico
mais especfico e os planos de ao so
mais detalhados.
O objetivo desta estratgia com-
plementar mtodos como SCAMPI,
MA-MPS e ISO/IEC 15504, oferecendo
propostas de solues a alguns potenciais
problemas encontrados na aplicao des-
tes mtodos. Os princpios que guiam a
estratgia so:
Mapear resultados aos objetivos do
negcio da organizao;
Minimizar o esforo de avaliao se-
gundo critrios de importncia definidos
pela prpria organizao;
Obter maior aproveitamento dos re-
sultados gerados;
Utilizar duas dimenses de anlise:
conformidade e risco.
O primeiro princpio tem como objetivo
sanar uma caracterstica identificada
na maioria dos mtodos de avaliao
de processos de desenvolvimento. De
forma geral, a aplicao destes mtodos
gera concluses ou resultados que esto
de maturidade ou norma de qualidade
utilizada. Este fato faz com que o trabalho
de convencimento da alta gerncia (geral-
mente no tcnica) acerca da importncia
dos investimentos em engenharia de
software ou qualidade seja dificultado e,
consequentemente, o projeto de melhoria
de processos fique ameaado devido
falta de comprometimento dos patrocina-
dores. O objetivo destes princpios dar
nfase s necessidades e prioridades da
empresa, ao invs de impor uma estru-
tura que pode no ser a mais adequada a
ela. O mapeamento dos resultados do n-
vel de TI para o nvel de negcios facilita
o seu entendimento, podendo orientar a
empresa a como atingir suas metas.
O segundo e terceiro princpio resul-
tado da constatao de um ponto fraco
identificado nos mtodos mais utilizados.

A grande maioria realiza inspees e
anlises rigorosas, que abrangem todo o
modelo de referncia e geram relatrios
com uma grande quantidade de informa-
es sobre diversas reas da engenharia
de software mas, na maioria dos casos,
outra grande quantidade de informaes
desperdiada. Uma avaliao indica
o estado atual da organizao e aponta
as oportunidades de melhoria na im-
plementao das diretivas do modelo
de maturidade ou norma de qualidade
utilizada como referncia. Entretanto,
devido a restries de oramento e ao
impacto que elas representam no am-
biente produtivo, apenas uma pequena
parte destas recomendaes pode ser
implementada na prxima iterao do
programa de melhoria. Aps a implemen-
tao da primeira iterao de melhoria, o
estado da organizao j no o mesmo
Figura 1. Mapeamento dos ativos em objetivos do negcio da organizao
proc esso
de quando a avaliao foi realizada, a capacidade esperada e a avaliada, qual
tornando obsoletos os dados relativos s deve receber os recursos?). A utilizao
reas de processos e as oportunidades de uma anlise de risco oferece um cri-
de melhoria que no foram abordadas. trio de desempate ou uma opo para a
A utilizao de uma estratgia em duas priorizao de investimentos.
etapas permite identificar, atravs de
uma anlise menos elaborada, as reas Ferramenta de apoio avaliao
mais relevantes e realizar uma anlise Para auxiliar a realizao da avalia-
mais elaborada apenas nestas reas. o dos processos de uma organizao
Finalmente, o quarto princpio tem utilizamos uma ferramenta de apoio
como objetivo oferecer dados de um n- execuo de avaliaes.
vel de abstrao menos granular para a A metodologia de anlise de risco
tomada de deciso. Embora a utilizao implementada pela ferramenta se baseia
da capacidade de processo e do nvel de na avaliao de caractersticas de ativos
maturidade seja o parmetro mais utili- da organizao, que podem representar
zado no direcionamento de recursos na pessoas da organizao, processos uti-
rea de desenvolvimento de software, lizados, tecnologias e caractersticas do
estes conceitos so um tanto abstratos ambiente de desenvolvimento. Cada ativo
e em muitos casos dificultam esta ativi- mapeado em componentes de negcio
dade (se vrios processos apresentam a (para o contexto de desenvolvimento de
mesma capacidade e o mesmo gap entre software foram utilizados objetivos do
Edio 01 Engenharia de Software Magazine 13
negcio ou de TI) da organizao e pos-
sui uma relevncia que est diretamente
relacionada relevncia dos objetivos aos
quais ele se relaciona. A Figura 1 ilustra
este conceito.
A cada ativo podem ser associados um
ou mais componentes, que represen-
tam caractersticas que sero avaliadas
em um projeto de avaliao que esto
relacionadas participao deste ativo,
ou seja, ao adicionar um componente a
um ativo estamos dizendo que ele um
coletor de dados que indicam o estado
de implementao de um conjunto de
boas prticas na organizao. Um pro-
jeto de avaliao pode utilizar todos os
componentes ou apenas um conjunto
que seja relevante para esta instncia de
avaliao. Cada componente possui um
checklist associado, composto por um ou
mais controles, que representam os itens
atmicos de verificao da implemen-
tao das boas prticas. Cada controle
possui uma estrutura com os seguintes
elementos:
Nome do Controle indica uma carac-
terstica (boa prtica ou requisito) que
deve estar presente no ativo para que o
controle seja considerado implementado
e seu risco associado seja eliminado.
Justificativa define os termos e concei-
tos necessrios para o entendimento do
controle e fornece uma justificativa que
explique porque aquele controle deve ser
implementado. Neste elemento so apre-
sentadas as vantagens que se obtm com
a implementao do controle e as conse-
qncias da sua no implementao.
Ameaas indicam quais elementos po-
dem se aproveitar da no implementao
do controle para se manifestar e causar
danos ao negcio da organizao.
Recomendao fornece razes e dados
para a elaborao de um plano de ao
aps a realizao da avaliao, atravs
de uma sugesto de como o controle
pode ser implementado para diminuir
a exposio da organizao aos riscos e
atingir a conformidade desejada com o
modelo ou norma de referncia.
Referncias relacionam referncias
bibliogrficas para que mais informaes
acerca do controle e da sua implementa-
o possam ser obtidas.
Probabilidade representa a probabili-
dade de uma ameaa se manifestar caso o
controle no esteja implementado na or-
ganizao. Este elemento representado
por um nmero de 1 (menor) a 5 (maior
probabilidade).
Severidade indica o grau do impacto
negativo na organizao, caso uma ou
mais ameaas se manifestem. Este ele-
mento representado por um nmero
de 1 (menor) a 5 (maior severidade).
Agrupamento indica a qual agrupa-
mento o controle pertence. Os agrupa-
mentos so comuns a todos os checklists,
permitindo verificar o estado da imple-

Controle Processo - CMMI Gerncia de Configurao Prtica 3.1 - 2 - As verses anteriores de um item de configurao devem ser passveis de recuperao.

Uma verso anterior de um item de configurao deve ser recuperada caso uma modificao no seja corretamente implementada, caso os arquivos atuais (na nova configurao
Justificativa do software) estejam corrompidos, caso seja efetuada uma juno (merge) incorretamente entre um ramo (linha temporria de desenvolvimento) e a linha principal de
desenvolvimento. Nestas situaes, pode ser apropriado restaurar uma verso anterior para que esta se torne a atual.

Este controle pode ser implementado atravs dos seguintes procedimentos:

- Disponibilizar as verses dos itens de configurao.
- Reportar os procedimentos para: (1) recuperar uma verso anterior, (2) verificar as revises de um item de configurao e (3) analisar as diferenas entre a verso anterior e a
atual. Essas informaes devem constar no plano de gerncia de configurao e nos procedimentos de controle de verses. Caso no estejam, sugere-se alter-los.
- Garantir a integridade e a disponibilidade dos repositrios de configuraes.
Recomendao Observao: A ferramenta de controle de verses deve facilitar a visualizao e recuperao das verses dos itens de configurao. Portanto, contm funcionalidades que facilitam
a implementao deste controle.

Exemplos de Artefatos Produzidos:

- Lista de verses de itens de configuraes
- Procedimentos para controle de verses

Probabilidade 4 Severidade 3

Std 1042 - IEEE Guide to Software Configuration Management, Institute of Electrical and Electronics Engineers, 1987.
ISO/IEC 12207 - Information technology - Software life cycle processes, International Organization for Standardization, 1995.
ISO/IEC 15504 - Information technology - Process Assessment, International Organization for Standardization, 2004.
Referncias
CMMI-Dev: rea de Processo: Gerncia de Configurao
Bibliografia de apoio:
H. R. Berlack, Software Configuration Management. New York: John Wiley & Sons, 1992.

Baixa manutenibilidade
Ameaas
Perda de controle de solicitaes de mudana

Agrupamento Gerncia de Configurao

Tabela 1. Exemplo de controle

14 Engenharia de Software Magazine Melhorando Processos Atravs da Anlise de Risco e Conformidade

 proc esso

mentao de caractersticas espalhadas
em vrios checklists.
A Tabela 1 apresenta um exemplo de
controle de uma prtica de gerncia de
configurao.
A avaliao consiste em responder aos
checklists associados aos ativos e sele-
cionados na configurao do projeto de
avaliao. Estes podem ser respondidos
diretamente ou atravs de questionrios
enviados via WEB, onde o contedo dos
controles pode ser interpretado para um
domnio especfico, por exemplo, para
os diversos papis de uma organizao.
A utilizao dos questionrios permite
um ganho de escala e de cobertura da
avaliao, ao mesmo tempo em que di-
minui o impacto da avaliao e aumenta
a aceitao das melhorias no processo de
desenvolvimento uma vez que todos se
sentem parte da avaliao e podem con-
tribuir com comentrios e sugestes.
Aps a coleta dos dados, gerado um
conjunto de relatrios contendo tabelas e
grficos que indicam o estado da imple-
mentao das boas prticas e os riscos
presentes na organizao e fornecem
dados para a tomada de deciso (o que e
como deve ser feito). Cada controle no
implementado ou implementado parcial-
mente, contribui com um ndice de risco
(PSR) que obtido pela multiplicao da
relevncia do ativo avaliado (R), da pro-
babilidade da concretizao das ameaas
possveis (P) e da severidade desta con-
cretizao (S) . Alm do PSR, os seguintes
indicadores so utilizados:
ndice de PSR controles (elemento)
Segurana = implementados
de um processo padro para a rea de
processo de definida em algum modelo
ou norma de referncia, como Gerncia
de Configurao e Soluo Tcnica do
CMMI, ou grupo de reas de processo,
que ser utilizado como base para a
elaborao das recomendaes de im-
plementao de controles. Esta atividade
possui tarefas de elaborao e reviso
de contedo e aderncia aos modelos ou
normas de qualidade utilizadas como
referncia. Em seguida, atividades de
gerao e reviso de arquitetura dos che-
cklists so executadas de forma iterativa
e concorrente, at que um produto com
A arquitetura do checklist consiste da identificao dos
controles que sero desenvolvidos e dos questionrios que
sero utilizados como coletores automticos de dados.
qualidade assegurada seja desenvolvido.
A arquitetura do checklist consiste da
identificao dos controles que sero
desenvolvidos e dos questionrios que
sero utilizados como coletores autom-
ticos de dados.
Tendo um conjunto revisado dos contro-
les que devem ser implementados e um
questionrio que interpreta e responde
estes controles do checklist atravs de
uma lgica bem definida para as suas
perguntas, inicia-se uma nova etapa de
implementao e reviso dos controles,
onde o contedo dos controles iden-
tificados elaborado e o questionrio
ganizao, das pessoas, dos fornecedores
ou do projeto ao qual ele pertence. Sendo
assim, chegou-se a seguinte taxonomia
para os ativos:
Processos representam fluxos de tra-
balho, reas de processo ou disciplinas da
organizao. Cada checklists associado
a este tipo de ativo possui o escopo de
uma rea de processo do modelo de
maturidade ou norma de qualidade. A
utilizao destes ativos define uma di-
menso da avaliao onde os processos
so o principal fator para o alcance dos
objetivos da organizao e, consequen-
temente, a principal fonte de evidncias
da implementao do modelo ou norma
de referncia.
Pessoa representa os atores da orga-
nizao. Os checklists associados a este
tipo de ativo verificam as diretivas da
norma relativas a um papel da organi-
zao (desenvolvedor, gerente, analista
de requisitos, etc.) que assumido pela
pessoa que referenciada pelo ativo. A
utilizao de ativos do tipo Pessoa defi-
ne uma dimenso da avaliao onde as
pessoas e os papis que elas executam
so o principal fator para o alcance dos
objetivos da organizao e, consequen-
temente, a principal fonte de evidncias

PSR (Total)
ndice de
Num.Controles Im plementados
Conformidade = Num.ControlesTotal
A partir destes ndices, pode-se gerar
um grande nmero de interpretaes,
atravs da filtragem e agrupamento de
dados das reas de processo, ativos,
ameaas, departamentos ou objetivos
de negcio.
Utilizando a Abordagem
Para utilizao desta abordagem em
uma avaliao, utilizamos um conjunto
de atividades.
A primeira atividade consiste na criao
desenvolvido refinado. Finalmente, os da implementao do modelo ou norma
checklists so homologados e adiciona- de referncia.
dos ferramenta. Ambiente representam o ambiente
Tendo um guia para a elaborao dos organizacional, caracterizado pelas
checklists, o segundo passo a identifica- acomodaes, aspectos inter-pessoais,
o dos checklists que seriam utilizados poltica motivacional e outros fatores
para a realizao das avaliaes. Como que afetam indiretamente a execuo dos
os checklists so associados aos ativos da processos. Os checklists associados a este
organizao, atravs dos componentes, tipo de ativo verificam as caractersticas
esta atividade foi realizada utilizando gerais da organizao e como ela contri-
como parmetro os tipos de ativos. bui ou no com o alcance dos objetivos
A ferramenta define quatro tipos de da organizao.
ativo para a realizao das avaliaes: Tecnologia representa a estrutura
Pessoa, Processo, Ambiente e Tec- tecnolgica da organizao, definida por
nologia. Para o domnio de processos de suas mquinas e ferramentas. Os che-
desenvolvimento, definiu-se que cada cklists associados a este tipo de ativo ve-
ativo funciona como uma dimenso de rificam caractersticas da infra-estrutura
coleta de dados sobre os processos da or- referenciada pelo ativo, como segurana

Edio 01 Engenharia de Software Magazine 15

em servidores, funcionalidades de ferra-
mentas, entre outros.
Como terceiro passo da customizao,
a estrutura para a gerao de checklists
foi elaborada. Esta atividade contou com
a definio dos agrupamentos, ameaas
e do escopo dos controles.
Como o objetivo da avaliao obter
resultados mapeados nas reas de proces-
so do modelo ou norma de qualidade de
referncia, independente de quais ativos
foram utilizados para coletar os dados, foi
definido que os agrupamentos utilizados
seriam as reas de processo.
Uma rea de processo possui carac-
tersticas especficas, que determinam
a sua implementao, e caractersticas
comuns a todas as reas, que indicam a
sua capacidade. Para facilitar a utilizao
de modelos de maturidade que utilizam
o conceito de capacidade de processos
foi definido tambm que deve existir
um agrupamento para cada nvel de
capacidade.
A Figura 2 ilustra este conceito para o
CMMI-DEV 1.2, onde um Checklist para
o ativo desenvolvedor (papel) contm os
agrupamentos Definio do Processo
Figura 2. Checklist com agrupamentos para caractersticas especficas e genricas
16 Engenharia de Software Magazine Melhorando Processos Atravs da Anlise de Risco e Conformidade
Organizacional, Desenvolvimento de
Requisitos, Foco no Processo Organiza-
cional, Garantia da Qualidade, Gerncia
de Configurao e Gerncia de Requisi-
tos que representam as caractersticas
especficas de cada rea de processo e o
agrupamento GG2 Processo Gerenciado
representa as caractersticas genricas.
Esto tambm ilustrados controles dos
agrupamentos de Gerncia de Configu-
rao e Gerncia de Requisitos. Cada
agrupamento contm um conjunto de
controles.
Com a estrutura de agrupamentos defi-
nida, os resultados das anlises de risco
e conformidade podem ser consolidados
pelos agrupamentos, resultando em rela-
trios (exemplificados no prximo tpi-
co), que indicam risco e conformidade de
cada rea de processo, e que deixam de
forma transparente quais tipos de ativo
foram utilizados.
Para o escopo dos controles, foi definida
a utilizao do item de menor granulari-
dade do modelo ou norma de referncia.
Como em muitos modelos e normas o
item de menor granularidade possui mais
de um item de verificao em seu escopo,
foi definida tambm a realizao de uma
anlise da atomicidade. Esta anlise tem
como objetivo quebrar o item em ele-
mentos de verificao atmicos, evitando
situaes de falha no preenchimento do
controle (se existem dois ou mais pontos
de verificao conectados por um ope-
rador e ou ou em um controle, como
respond-lo no caso de alguns estarem
implementados e outras no?).
Finalmente, para uniformizar as anli-
ses de risco e conformidade em processos
de desenvolvimento realizados com a
utilizao da ferramenta, foi elaborada
uma lista de ameaas.
Tendo em vista que a grande maioria
dos mtodos de avaliao de processos
de desenvolvimento (SCAMPI, MA-MPS,
ISO/IEC 15504) utiliza uma estrutura
de nveis para a classificao da imple-
mentao de uma diretiva do modelo ou
norma, utilizamos nesta soluo a mesma
abordagem. Desta forma, cada controle
pode ser classificado como Implemen-
tado, No Implementado ou Parcial-
mente Implementado. Partindo do fato
de que um controle parcialmente imple-
mentado no se encontra implementado,
foi determinado que, quando a anlise
realizada indicasse que um controle no
 proc esso

foi totalmente atendido, este deve ser
preenchido como No implementado.
Utilizando a premissa de que um controle
parcialmente implementado possui uma
probabilidade menor de causar danos do
que um controle no implementado, foi
determinado que, para cada nvel de im-
plementao atingido pelo controle, a sua
probabilidade ser diminuda em uma
unidade, at chegar ao valor mnimo 1.
Para exemplificar a abordagem, consi-
dere um controle cuja probabilidade seja
quatro. Em uma avaliao que utiliza
o modelo CMMI como referncia, um
controle classificado como parcialmente
implementado ser preenchido como No
Implementado e a sua probabilidade ser
alterada para trs. O resultado desta abor-
dagem que, ao final da anlise de risco,
os controles parcialmente implementados de desenvolvedor, portanto o peso das
contribuiro com menos risco do que os reas tcnicas do modelo ser maior que
controles do mesmo tipo classificados o peso das reas de gesto ou das reas
como no implementados. organizacionais. Alm disso, nesta etapa,
os objetivos do negcio da organizao
Utilizando a abordagem no foram identificados e mapeados nos
Para demonstrar a aplicabilidade da ativos de software.
abordagem proposta, foram realizados Abaixo so apresentados os resultados
vrios estudos de caso, nos quais o da avaliao:
processo utilizado por equipes de desen- Conforme apresentado na Tabela 3 e
volvimento de software de organizaes na Figura 3, as reas de Planejamento
distintas foi avaliado. A seguir, apre- de Projetos, Soluo Tcnica e Defini-
sentado um resumo de uma das avalia- o do Processo Organizacional tm o
es realizadas onde se realizou apenas maior ndice de Segurana indicando que
a etapa de Abrangncia. Para preservar a maior parte das prticas destas reas
a confidencialidade, as informaes esto implementadas. Ao contrrio, as
apresentadas foram descaracterizadas reas de Treinamento Organizacional,
(ver Tabela 2). Gerncia de Requisitos, Integrao
A avaliao considerou somente o perfil do Produto e Gerncia de Configura-

Empresa ABC

Objetivos: Avaliar o processo utilizado no desenvolvimento dos softwares da organizao utilizando o modelo CMMI DEV 1.2 como referncia e identificar oportunidades de melhoria nas reas de processo
de maior impacto no desenvolvimento dos softwares.

Fase de Abrangncia

Escopo Organizacional Participantes Escopo do Modelo Durao (h/dias)

Projetos de desenvolvimento de - 9 Desenvolvedores do Setor 1 reas de nveis 2 e 3 do CMMI DEV 1.2, exceto : Garantia da Qualidade, Gerencia de Fornecedores,
16/4
sistemas internos da organizao - 9 Desenvolvedores do Setor 2 Gerncia de Risco, Gerenciamento Integrado e Anlise de Decises e Resolues

Tabela 2. Resumo do objetivo e escopo da avaliao

PSR Controles PSR Controles No ndice de Conformidade ndice de Segurana

rea de Processo PSR Total
Implementados Implementados (%) (%)
Avaliao e Melhoria do Processo 64 194 256 32,16 25,00

Definio do Processo Organizacional 160 96 256 85,13 62,50

Desenvolvimento de Requisitos 304 1328 1632 19,16 18,63

Gerncia de Configurao 388 1912 2300 25,34 12,52

Gerncia de Requisitos 72 1152 1224 0,00 5,88

Integrao do Produto 148 1364 1512 15,05 9,79

Medio e Anlise 248 264 512 76,18 48,44

Monitoramento e Controle de Projetos 580 780 1360 74,05 42,65

Planejamento de Projetos 1024 200 1224 78,15 83,66

Soluo Tcnica 2140 852 2992 67,12 71,52

Treinamento Organizacional 8 400 408 0,00 1,96

Validao 108 468 576 22,25 18,75

Verificao 316 1472 1788 18,15 17,67

Total 5560 10482 16040 67,15 53,04

Tabela 3. Resultados da avaliao em abrangncia por rea de Processo

Edio 01 Engenharia de Software Magazine 17

 V is o G eral - rea P roc es s o

Planejamento de Projetos
Soluo Tcnica
Definio do Processo Organizacional
Medio e Anlise
Monitoramento e Controle de Projetos
Avaliao e Melhoria do Processo
Segurana
Validao
Conformidade
Desenvolvimento de Requisitos
Verificao
Gerncia de Configurao
Integrao do Produto
Gerncia de Requisitos
Treinamento Organizacional

0 20 40 60 80 100
%

Figura 3. Resultados da avaliao em Abrangncia Grfico de ndices de conformidade e segurana para cada rea de Processo (Ordenao decrescente
pelas reas de maior ndice de Segurana)

R is c o Abs oluto - rea P roc es s o

Gerncia de Configurao
Verificao
Integrao do Produto
Desenvolvimento de Requisitos
Gerncia de Requisitos
Soluo Tcnica
Monitoramento e Controle de Projetos
Validao
Treinamento Organizacional
Medio e Anlise
Planejamento de Projetos
Avaliao e Melhoria do Processo
Definio do Processo Organizacional

0 500 1000 1500 2000 2500

PSR

PSR Implementado PSR No Implementado

Figura 4. Resultados da avaliao em Abrangncia Grfico de PSR por rea de Processo (Ordenao decrescente pelas reas de maior PSR)

18 Engenharia de Software Magazine Melhorando Processos Atravs da Anlise de Risco e Conformidade

 proc esso

R is c o Abs oluto - S etor 1

Gerncia de Configurao
Soluo Tcnica
Integrao do Produto
Verificao
Desenvolvimento de Requisitos
Gerncia de Requisitos
Monitoramento e Controle de Projetos
Validao
Treinamento Organizacional
Medio e Anlise
Avaliao e Melhoria do Processo
Planejamento de Projetos
Definio do Processo Organizacional

0 200 400 600 800 1000 1200

PSR

PSR Implementado PSR No Implementado

Figura 5. Resultados da avaliao em Abrangncia Grfico de PSR do Setor 1 por Processo (Ordenao decrescente pelas reas de maior PSR)

R is c o Abs oluto - S etor 2

Verificao
Desenvolvimento de Requisitos
Gerncia de Configurao
Integrao do Produto
Gerncia de Requisitos
Monitoramento e Controle de Projetos
Validao
Soluo Tcnica
Treinamento Organizacional
Planejamento de Projetos
Avaliao e Melhoria do Processo
Medio e Anlise
Definio do Processo Organizacional

0 200 400 600 800 1000 1200 1400

PSR

PSR Implementado PSR No Implementado

Figura 6. Resultados da avaliao em Abrangncia Grfico de PSR do Setor 2 por Processo (Ordenao decrescente pelas reas de maior PSR)

Edio 01 Engenharia de Software Magazine 19

o tm o menor ndice de Segurana
indicando que poucas prticas destas
reas esto implementadas. As reas de
Definio do Processo Organizacional,
Medio e Anlise, Monitoramento
e Controle de Projetos e Gerncia de
Configurao tm um ndice de Confor-
midade relativamente maior que o ndice
de Segurana indicando a implementao
de prticas pouco eficientes na mitigao
dos riscos.
De acordo com a Figura 4, pode-se
verificar que as reas de Gerncia de
Configurao, Verificao, Integrao
do Produto, Desenvolvimento de Re-
quisitos e Gerncia de Requisitos tm
maior PSR No implementado indicando
maior probabilidade de manifestao dos
riscos durante sua execuo. Ao contr-
rio, as reas de Definio do Processo
Organizacional, Avaliao e Melhoria
do Processo, Planejamento de Projetos
e Medio e Anlise tm menor PSR
no implementado, indicando menor
probabilidade de manifestao dos riscos
durante sua execuo.
As reas de Soluo Tcnica, Planeja-
mento de Projetos e Monitoramento e
Controle de Projetos tm maior PSR im-
plementado, indicando a implementao
de prticas que evitaram a manifestao
de um maior nmero de riscos.
Verificando as informaes apresen-
tadas na Tabela 4 e nas Figuras 5 e 6,
conclui-se que na organizao, as reas
de Gerncia de Configurao, Verifi-
cao, Integrao do Produto, Desen-
volvimento de Requisitos e Gerncia
de Requisitos tm maior probabilidade
de manifestao dos riscos durante sua
execuo. Entretanto, quando os dois
setores so avaliados separadamente
conclui-se que:
o o
No Setor 1 as reas de Gerncia de Confi-
gurao, Soluo Tcnica, Integrao do
Produto, Verificao, Desenvolvimento
de Requisitos e Gerncia de Requisitos
tm maior probabilidade de manifestao
dos riscos durante sua execuo, ou seja,
a rea de Soluo Tcnica tem um peso
importante nos riscos das atividades do
Setor 1;
o que apresentaram um alto PSR no im-
No Setor 2, as reas de Verificao, De-
senvolvimento de Requisitos, Gerncia
de Configurao, Integrao do Produto
e Gerncia de Requisitos tm maior
probabilidade de manifestao dos riscos
durante sua execuo, ou seja, o mesmo
resultado da organizao com a inverso
de algumas posies.
Pelo apresentado na Figura 7, as ameaas
mais relevantes esto relacionadas com:
o
Produto no atender s necessidades dos
clientes - Desenvolvimento de Requisitos,
Verificao e Validao;
o
Requisitos incompletos, inconsistentes ou
incorretos - Gerncia e o Desenvolvimen-
to de Requisitos e Verificao;
Software apresentar falhas Soluo Tc-
o
nica, Integrao do Produto e Verificao;
Perder controle sobre as solicitaes de mu-
dana - Gerncia de Requisitos e Gerncia
de Configurao.
Como resultado final da avaliao,
definiu-se um plano priorizando aes
de melhoria nas reas de Gerncia de
Configurao, Desenvolvimento de
Requisitos e Gerncia de Requisitos,
plementado, combinado com um baixo
ndice de segurana. Para um melhor
detalhamento das aes de melhoria foi
sugerida tambm a realizao de uma
avaliao em Profundidade para cada
uma das trs reas mencionadas.
Em um segundo momento, foram su-
geridas aes de melhoria para as reas
de Verificao e Integrao do Produto,
devido ao alto PSR no implementado

Setor 1 Setor 2

PSR Controles PSR Controles No PSR Controles PSR Controles No

rea de Processo PSR Total PSR Total
Implementados Implementados Implementados Implementados

Avaliao e Melhoria do Processo 30 98 128 34 94 128

Definio do Processo Organizacional 82 46 128 78 50 128

Desenvolvimento de Requisitos 272 544 816 32 784 816

Gerncia de Configurao 16 1134 1150 372 778 1150

Gerncia de Requisitos 72 540 612 0 612 612

Integrao do Produto 70 686 756 78 678 756

Medio e Anlise 82 174 256 166 90 256

Monitoramento e Controle de Projetos 316 364 680 264 416 680

Planejamento de Projetos 518 94 612 506 106 612

Soluo Tcnica 796 700 1496 1244 252 1496

Treinamento Organizacional 4 200 204 4 200 204

Validao 84 204 288 24 264 288

Verificao 256 638 894 60 834 894

2598 5422 8020 2862 5158 8020
Tabela 4. Resultados da avaliao em Abrangncia por Setor e rea de Processo

20 Engenharia de Software Magazine Melhorando Processos Atravs da Anlise de Risco e Conformidade


e o estabelecimento de uma poltica
de Treinamento Organizacional, pois
apesar do PSR desta rea ser menor, o
ndice de segurana muito baixo. Da
mesma forma foi sugerida uma avaliao
em Profundidade para cada uma das trs
reas mencionadas.
Foram tambm sugeridas aes de me-
lhoria para o Setor 1 na rea de Soluo
Tcnica.
Concluso
Neste artigo apresentamos uma aborda-
gem que define um critrio concreto para
priorizao de melhorias a serem realiza-
das nos processos de desenvolvimento de
software de uma organizao. Este critrio
utiliza a anlise de risco como um instru-
mento de priorizao das aes que tm
maior eficincia na mitigao das ameaas
identificadas durante o diagnstico da
situao atual. A relevncia das ameaas
definida com base no atendimento aos
objetivos de negcio da organizao e na
conformidade com modelos e normas de
qualidade de software.
proc esso
Amea a s
Produto no atender s
necessidades dos clientes
10,06% Requisitos incompletos,
19,42% inconsistentes ou incorretos
4,54%
Software apresentar falhas
4,75%
Perder controle sobre as
solicitaes de mudana
4,92%
Elaborar produtos de baixa
manutenibilidade
7,71% 17,99% Descumprir oramento ou
prazos estimados
Baixa eficincia na execuo
dos processos
13,51% Dificuldades de melhoria na
17,10% qualidade dos projetos
Demais Ameaas
Figura 7. Resultados da avaliao em Abrangncia Ameaas
Referncias
BOEHM, B. W. Software Risk Management: Principles and Practices. IEEE Software, v. 8(1), p. 32-41, jan. 1991.
BOEHM, B. W.; DEMARCO, T. Software Risk Management. IEEE Software, v. 14(3), p. 17-19, mai./jun. 1997.
CHRISSIS, M.B.; KONRAD, M.; SHRUM, S. CMMI: Guidelines for Process Integration and Product Improvement. Boston: Addison-Wesley, 2003.
DEMARCO, T; LISTER, T. Waltzing with Bears: Managing Risks on Software Projects. New York: Dorset House Publishing, 2003.
GREMBA, J.;MYERS, C. The IDEALSM Model: A Practical Guide for Improvement. 1997. Disponvel em <http://www.sei.cmu.edu/
ideal/ideal.bridge.html>. Acesso em 18 nov.2006.
ISO/IEC. Guide 73:2002. Risk management -- Vocabulary -- Guidelines for use in standards, Reference No. ISO/IEC Guide 73:2002(E).
____. International Standard 12207. Information Technology Software Life Cycle Processes, Reference No. ISO/IEC 12207: 1995(E):
First Edition 1995.
____. International Standard 15504. Information Technology Proces Assessment, Reference No. ISO/IEC 15504:2004(E).
____. International Standard 17799. Information Technology Security Technics - Code of practice for information security
management, Reference No. ISO/IEC 17799:2005(E): Second Edition 2005.
____. Technical Report 13335 1.Information technology - Guidelines for the management of IT Security - Part 1: Concepts and
models for IT Security, Reference No. ISO/IEC TR 13335: 1996(E).
IT GOVERNANCE INSTITUTE (ITGI). Control Objectives for Information and Related Technology (COBIT). V4.0, 2005. Disponvel em
<http://www.itgi.org/>. Acesso em 25 fev 2007.
POULIN, A. Reducing Risk with Software Process Improvement. Boca Raton: Auerbach Publications, 2005.
SOFTEX.. MPS.BR Melhoria de Processo do Software Brasileiro. Guia de Avaliao. Verso 1.0, 2006a.
____. MPS.BR Melhoria de Processo do Software Brasileiro. Guia Geral. Verso 1.1, 2006b.
SOFTWARE ENGINEERING INSTITUTE (SEI). Appraisal Requirements for CMMI, Version 1.2 (ARC, V1.2). Software Engineering Institute,
Carnegie Mellon University, Pittsburgh, Pennsylvania, 2006a
____. CMMI for Development, Version 1.2. Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania,
2006b.
____. Standard CMMI Appraisal Method for Process Improvement (SCAMPI[SM]) A, Version 1.2: Method Definition Document.
Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania, 2006c
Edio 01 Engenharia de Software Magazine 21
 Agilidade ou Controle Operacional? Os dois!
Alexandre Bartie
alexandre_bartie@hotmail.com
Atua h 17 anos no gerenciamento de pro-
cessos voltados Qualidade e Engenharia de
Software. Ps-Graduado em Capacitao Ge-
rencial pela FEA-USP e em Gesto Empresarial
pelo Instituto Trevisan. Bacharel em Admi-
nistrao de Empresas pela Fundao Santo
Andr. Diretor de Inovao da ALATS (Associa-
o Latino-Americana de Teste de Software)
e Engenheiro de Software responsvel pelo
Framework X-Zone. Autor do Livro Garantia da
Qualidade de Software.
22 Engenharia de Software Magazine Agilidade ou Controle Operacional? Os dois!
Q
uando os modelos CMMI e RUP
foram popularizados, as empre-
sas convenceram-se de que, para
gerenciar a crescente complexidade do
setor de TI, seria fundamental ampliar o
nvel do controle operacional sobre todos
os projetos existentes.
Apesar de muitas empresas seguirem
risca a cartilha do CMMI, formalizan-
do seus processos, padronizando seus
artefatos e reduzindo as flutuaes de
qualidade e incertezas dos projetos,
muitas delas no obtiveram os resulta-
dos financeiros desejados. Suas receitas
financeiras e lucros operacionais foram
reduzidos em funo do aumento dos
custos e a crescente dilatao dos prazos
de entrega.
Infelizmente, as empresas e profissio-
nais deram apenas nfase ao controle
operacional, implementando cada vez inevitavelmente a um novo limite opera-
mais artefatos, controles e procedimen-
tos internos. Desta forma, os processos
tornaram-se mais pesados, provocando
uma grande lentido operacional, sinali-
zando uma perda contnua de agilidade
para seus clientes e o mercado.
O movimento gil foi o ressurgimento
de um ponto de vista que foi esquecido
pela TI, quando abraamos to fortemen-
te os processos e controles operacionais
e negligenciamos a agilidade de nossos
projetos.
O modelo gil orienta empresas, pro-
fissionais e metodologistas a pensarem
na TI como uma organizao veloz,
onde o tempo de resposta no pode ser
sacrificado. Quanto mais rpida uma
empresa, mais entregas so realizadas
em um menor espao de tempo, gerando
mais oportunidades de faturamento, o
que reverte imediatamente em maior
rentabilidade nos negcios.
Porm, a nfase na agilidade tambm
possui suas restries - ser rpido leva
cional. Somente com controles gerenciais
bem implementados, poderemos ultra-
passar estes limites sem provocarmos
um colapso nos servios da TI.
 proc esso

Desta forma, o grande desafio das
organizaes do futuro conseguir con-
ciliar agilidade e controle operacional
simultaneamente, possibilitando a rea
de TI operar com o mximo de qualidade
e produtividade.
O objetivo deste artigo justamente
apresentar um modelo que combine
agilidade e controle operacional numa
nica abordagem, viabilizando o que
chamo de Organizaes TI de Alto
Desempenho.
ncia do perodo delicado que muitas
organizaes esto passando. Nunca o
momento foi to favorvel a investimen-
tos de TI, porm o excesso de alternativas
esto gerando um alto nvel de incertezas
em nossos executivos, o que provoca uma
paralisao nestes investimentos.
Desta forma, elaborei um modelo de
gesto de TI que respeitasse as aborda-
gens em andamento, chamado aqui de
Modelo Controlado, e permitisse uma
Ressalva Importante
Antes de prosseguirmos com o artigo,
fundamental compreender que as abor-
dagens citadas esto sendo apresentadas
de forma resumida, no explorando
todos os aspectos, contextos e formatos
existentes.
O mtodo de classificao emprega-
do foi pelo critrio de prioridades que
cada abordagem possui. Modelos geis
priorizam a agilidade, enquanto que mo-

Entendendo o Momento Atual

crescente o movimento de profissio-
nais e empresas interessadas na adoo
dos chamados modelos geis, como uma
opo aos modelos controlados, liderados
mundialmente pelo CMMI e abordagens
equivalentes.
Existem inmeros debates sobre as
vantagens e desvantagens dos dois mo-
delos, onde profissionais e especialistas
buscam estabelecer critrios que definem
em quais contextos uma abordagem deve
ou no ser empregada.
Atrs da busca pelo melhor modelo,
muitos executivos encontram-se na situ-
ao delicada de decidir qual a estratgia
a ser seguida pela empresa. Muitos j
iniciaram o processo de adequao aos
padres CMMI e agora estas aes pas-
sam a ser questionadas por profissionais
que defendem as abordagens geis.
Para piorar, os executivos deparam-
se com uma TI dividida, onde equipes
trabalham juntas mais acreditam em
abordagens diferentes. Inevitavelmente,
o boicote entre as equipes ocorre de uma
forma silenciosa, alimentando mais a
rivalidade entre aqueles que defendem
seus pontos de vista.
Foi neste momento que tomei consci-
Atrs da busca pelo melhor modelo, muitos executivos
encontram-se na situao delicada de decidir qual a
estratgia a ser seguida pela empresa.
adoo gradual de novos conceitos que
poderiam dar mais velocidade TI, cha-
mado aqui de Modelo gil.
Este modelo de gesto baseia-se em
indicadores objetivos, no em conceitos
ou abordagens de trabalho. Estes indica-
dores monitoram a agilidade e o controle
operacional dos projetos, possibilitando
acompanhar o desempenho de todas suas
equipes, independente de suas caracters-
ticas e restries.
Antes de abordarmos este modelo de
gesto de TI, seria conveniente explorar-
mos um pouco mais sobre as abordagens
controladas e geis, para compreen-
dermos melhor como combinar estes
elementos nesta proposta.
Na Tabela 1 apresentado um pequeno
resumo das principais diferenas entres
as duas abordagens.
delos controlados priorizam o controle
operacional.
Porm, interessante ressaltar que abor-
dagens geis possuem seus mecanismos
de controle, da mesma forma que proces-
sos controlados podem ser to ou mais
rpidos que as abordagens geis.
O que podemos aprender com os
Modelos Controlados
O propsito inicial do CMM foi estrutu-
rar um modelo de avaliao que permitis-
se estabelecer um nvel de risco associado
ao grau de maturidade de cada organi-
zao. Seu conceito baseia-se no fato de
que as organizaes que no controlam
sua cadeia produtiva possuem maiores
chances de fracassarem na conduo de
seus projetos, pois tero menor controle
sobre os fatores que influenciam negati-
vamente a execuo dos trabalhos.

Caractersticas Modelo gil Modelo Controlado

Premissa Fundamental nfase na Agilidade nfase no Controle Operacional
Conduo dos Trabalhos Baseado em Processos Empricos Baseado em Processos Formais
Escopo da Soluo Centradas no Desenvolvimento Englobam todas as Disciplinas
Profundidade da Abordagem Definir apenas o qu deve ser feito Definir o qu e como deve ser feito
Foco dos Profissionais Atuao Local (por projeto) Atuao Global (por disciplina)
Abordagem Estratgica Atender melhor o Curto Prazo Atender melhor o Longo Prazo
Palavras Chaves Pessoas, FeedBack, Adaptao Maturidade, Estrutura, Padronizao
Modelos de Implementao XP, SCRUM, FDD, APM, Lean, Crystal e DSDM CMMI, RUP, ITIL, ISO, PMI, MPS.br
Frase que resume sua Filosofia Aproxime sua equipe do Cliente, simplifique o projeto e aumento sua produtividade No podemos melhorar o que no podemos controlar
Tabela 1. Principais diferenas entre Modelos geis e Controlados

Edio 01 Engenharia de Software Magazine 23

 A criao do modelo CMM foi gerada
a partir da necessidade do Governo dos
Estados Unidos. O objetivo foi de acelerar
seus processos de terceirizao na cons-
truo de softwares, sem que ocorresse
um descontrole em relao a prazos, cus-
tos, escopo e qualidade dos projetos.
Sendo a terceirizao uma deciso ine-
vitvel, seria necessrio estabelecer um
modelo que mitigasse os riscos de uma
m contratao, atravs de critrios obje- s demais organizaes.
tivos que comprovassem a qualificao
das empresas.
As empresas que possuem maior nvel de maturidade
organizacional sinalizam possuir maior controle operacio-
nal sobre seus projetos.
Desta forma, todos os fornecedores
deveriam ser submetidos ao processo de
avaliao CMM, de forma a mensurar
seu nvel de maturidade organizacional
e atestar suas condies mnimas para
atender determinados projetos em con-
corrncia.
As empresas que possuem maior nvel
de maturidade organizacional sinalizam
possuir maior controle operacional sobre
seus projetos e estaro em melhores
condies de oferecer seus servios que
as demais. Fornecedores bem avaliados
tero acesso a participar de um maior
nmero de projetos, aumentando suas
chances de incrementar suas receitas
operacionais. Bom para os clientes e
melhor ainda para os fornecedores que
investiram nos controles operacionais.
Este modelo demonstrou tanto sucesso
que foi adotado por vrias outras orga-
nizaes americanas, que basearam seus
processos de terceirizao de servios
nos nveis de maturidade atestados pela
avaliao CMM. Com um modelo esta-
belecido, a terceirizao foi incentivada e
intensificada em todo o mundo, tornando
extremamente popular o CMM como
modelo de avaliao.
As empresas que adotam o modelo con-
trolado buscam estabelecer uma relao
duradoura com seus clientes e fornece-
dores, objetivando sempre ampliar seus
controles operacionais e repassar este va-
lor adicional aos clientes. O projeto deixa
24 Engenharia de Software Magazine Agilidade ou Controle Operacional? Os dois!
de contemplar exclusivamente o software
que ser disponibilizado em produo,
mas incorpora todos os elementos geren-
ciais que permitam manter a evoluo do
produto ao longo do tempo.
Para as empresas que adotam o modelo
controlado, quanto mais controles opera-
cionais forem incorporados, maior ser o
valor agregado do projeto, proporcionan-
do uma vantagem competitiva em relao
com a presso de organizarem toda sua
Atualmente, o CMM foi remodelado
para o chamado CMMI. Uma viso mais
moderna e ampliada de avaliao das
organizaes de TI, de modo a incorporar
novos temas e oferecer um novo formato
de avaliao, baseado nas disciplinas.
Isto possibilita que empresas especiali-
zadas em determinados servios de TI
(testes de software, gerenciamento de
projetos, gerenciamento de requisitos,
gerenciamento de ambientes), possam
ser avaliados exclusivamente nos itens
de seu maior domnio.
Sempre bom afirmar que o CMM
um modelo de avaliao, pois estabelece
apenas os pontos de controle que devero
estar contemplados nos procedimentos de
trabalho das empresas. Cada organizao
tem a liberdade de estabelecer e modelar
seus prprios processos internos.
Portanto, apesar do CMM levar inevita-
velmente as organizaes a trabalharem
por processos, seria errado dizer que o
CMM um processo pesado ou burocr-
tico. Na verdade, sero as empresas que
determinaro seus processos internos,
podendo criar esquemas complicados,
pesados, rgidos e burocrticos, no sen-
do necessariamente culpa do CMM, mas
de sua incorreta implementao.
O que podemos aprender com os
Modelos geis
Os modelos geis fazem parte de um
movimento global de profissionais, em-
presas e instituies, chamado de Ma-
nifesto gil, que buscam estabelecer
os novos paradigmas para as empresas
fornecedoras de software, onde a entre-
ga rpida do software encomendado o
principal objetivo desta abordagem.
Os modelos geis surgem como uma
reao natural expanso do CMMI no
mercado mundial, atingindo no apenas
as grandes organizaes, mas tambm as
pequenas e mdias empresas de TI. Dessa
forma, estas passam tambm a conviver
cadeia produtiva, sob o risco de serem
simplesmente excludos do mercado.
As constantes fuses corporativas
favoreceram o surgimento das mega-
corporaes globalizadas, que necessitam
de fornecedores que consigam garantir
nveis de servios em escalas nunca antes
imaginadas. Sem possuir tantos recursos
financeiros disponveis e prevendo uma
dificuldade de adequar-se aos padres
estabelecidos pelo mercado mundial, as
pequenas e mdias empresas observam
suas oportunidades no mercado serem
gradativamente reduzidas.
Neste cenrio, a abordagem gil torna-
se uma interessante estratgia de sobrevi-
vncia das pequenas e mdias organiza-
es que no conseguem adequar-se aos
rgidos padres de excelncia estabele-
cidos pelo mercado mundial. Para isto,
necessrio convencer o mercado de que
seguir os mtodos tradicionais torna-
ro suas empresas mais lentas e caras, que
a rea de TI segue um processo evolutivo
diferente de outros setores da economia,
e que adotar padres industriais um
grande equvoco estratgico.
De certa forma, os modelos geis res-
suscitam a idia da rea de desenvolvi-
mento como o centro da organizao TI.
Na abordagem gil, tudo passa a girar
em torno dos desenvolvedores, tudo
organizado para dar poder de deciso a
estes profissionais que iro encontrar os
meios mais adequados para implementar
as mudanas no cdigo-fonte e gerar os
benefcios esperados no projeto, no me-
nor prazo e custo possvel.
As abordagens geis chamam ateno
de muitas empresas e profissionais pela
sua simplicidade de implementao, pois
suas regras so simples de serem segui-
das. O sucesso da adoo do modelo gil
est intimamente ligado ao comprometi-
mento dos profissionais, pois sua forma
de conduo dos trabalhos possui um alto
grau de informalidade.
 proc esso

A abordagem gil possui um discurso

leve, pautado na reduo drstica da
complexidade dos projetos de desen-
volvimento e de toda a estrutura da TI,
reduzindo em poucos elementos geren-
civeis e trabalhando com profissionais
com atuao multidisciplinar.
Sua filosofia refora e incentiva a atua-
o livre dos profissionais para decidirem
como ser a melhor forma de implemen-
tao, apesar de existirem poucas, mas
rgidas regras de controle sobre o projeto.
Incentiva a simplicidade do software e
uma estrutura mnima para mant-lo em
funcionamento, adicionando flexibilida-
de e eliminando complexidades ao longo
de todo o ciclo de vida do projeto.
Desta maneira, a abordagem gil torna-
se ento uma modelo vivel de atuao
no mercado mundial. Possibilitando
criar um novo nicho de oportunidades,
atraindo investidores que estaro dispos-
tos a enfrentar os riscos e as condies
impostas pelo modelo gil.
Os pontos fracos dos Modelos geis
O modelo gil possui algumas fraque-
zas que impedem sua adoo de forma
corporativa e podem comprometer sua
credibilidade e implementao no mer-
cado mundial.
Falta de uma avaliao para atestar empresas
com abordagens geis
A abordagem gil no possui um mode-
lo de avaliao que garanta ao mercado
Nos modelos geis, o valor de uma organizao medida
atravs de sua capacidade em realizar entregas rpidas a
um baixo custo operacional.
que os projetos sero efetivamente guia-
dos por esta filosofia. Isto significa que
qualquer empresa pode pleitear o ttulo
de empresa gil, sem necessariamente se-
guir esta abordagem em seus projetos.
Mesmo que no futuro exista um mo-
delo de avaliao para empresas geis, a
informalidade do modelo tornar qual-
quer avaliao altamente subjetiva, sem
quaisquer evidncias de que determina-
das aes esto realmente acontecendo
dentro da filosofia gil.
As certificaes existentes apenas ates-
tam que determinados profissionais esto
aptos a aplicar as tcnicas estabelecidas
pelos modelos geis. Porm, no existem
garantias que os mesmos as aplicam
adequadamente dentro dos projetos das
empresas, ou mesmo se esta filosofia
seguida como uma estratgia empresarial
ou apenas uma iniciativa isolada de uma
equipe dentro da empresa, acentuando
ainda mais a fragilidade deste modelo.
Foco excessivo nos prazos e custos inviabiliza o
modelo financeiro de longo prazo
Nos modelos controlados, o valor da
organizao medida pelo total de con-
troles operacionais que uma empresa
efetivamente consegue gerenciar em
seus projetos, possibilitando que esta
seja auditada e facilmente avaliada nestes
requisitos. Quanto mais controles forem
efetivamente gerenciados, maior ser o
valor da organizao no mercado.
Portanto, as empresas estaro sempre
buscando investir mais em controles
operacionais para garantir maiores opor-
tunidades de mercado trata-se de uma
estratgia organizacional sustentvel de
longo prazo.
Nos modelos geis, o valor de uma
organizao medida atravs de sua
capacidade em realizar entregas rpi-
das a um baixo custo operacional. Para
destacarem-se no mercado, as empresas
iro concorrer de forma cada vez mais
agressiva, oferecendo prazos e custos
sucessivamente mais apertados.
No mdio e longo prazo, a lucratividade
dos projetos ser gradualmente reduzida
e a presso no aumento da produtividade
das equipes ser cada vez maior. Alm
disso, os salrios devero ser reduzidos
para manter uma margem de lucro que
compense as organizaes seguirem este

Figura 1. Demonstrao de como agilidade e controle so colocados em lados opostos

Edio 01 Engenharia de Software Magazine 25

modelo. H cada novo projeto, as empre-
sas estaro trabalhando mais prximas
de seu limite operacional e financeiro,
devendo necessariamente rever sua estra-
tgia de posicionamento no mercado.
Portanto, as abordagens geis possuem
uma inconsistncia estratgica que impe-
dem que suas organizaes sejam viveis
financeiramente no longo prazo. Isto no
significa que os princpios geis no so
Para a maioria das empresas e profissionais, agilidade e
controle operacional so indicadores inversamente pro-
porcionais, estabelecendo um equivocado modelo de
causa-efeito.
bons nem interessantes, porm demons-
tram apenas que, a nfase exclusiva na
agilidade pode levar as organizaes a
uma estratgia equivocada.
O Paradigma da Incompatibilidade
dos Modelos
Para a maioria das empresas e profissio-
nais, agilidade e controle operacional so
indicadores inversamente proporcionais,
estabelecendo um equivocado modelo de
causa-efeito. Isto conduz a uma deciso
binria entre adotar um modelo ou outro,
impossibilitando aplicar de forma com-
binada estes dois elementos.
Adotando este modelo, estabelecemos
que as organizaes com maior nvel de
controle operacional, necessariamente
possuem uma limitada capacidade de
responder com agilidade as suas de-
mandas de mercado. A razo deste pen-
samento que o gerenciamento destes
controles consomem tempo e energia dos
profissionais, levando uma reduo da
produtividade (ver Figura 1).
Da mesma maneira, uma organizao
gil deveria reduzir drasticamente seus
processos e concentrar-se exclusivamente
na produo do software, obtendo uma
agilidade nunca atingida nas organiza-
es com muitos controles operacionais.
A razo deste abrupto aumento de produ-
tividade estaria ligada ao fato de que, com
o tempo disponibilizado pela ausncia
dos controles, os profissionais poderiam
dedicar-se ainda mais na construo do
software (ver Figura 1).
Porm, ser que este modelo proposto
de causa-efeito realmente consistente?
Como podemos atestar que estamos tra-
balhando com uma premissa verdadeira?
Ser que estamos condenados a escolher
entre uma ou outra abordagem ou existe
uma forma diferente de combinarmos
estes dois modelos e potencializarmos
suas vantagens?
Existe uma premissa errada na rea
de TI, onde estabelecemos que, para
tornarmos geis, precisamos abdicar dos
controles operacionais para dar maior
ateno aos elementos mais essenciais
dos projetos de software. Observando
atentamente o comportamento dos
demais setores da economia, estes dois
elementos so empregados intensamente
como estratgia em mercados altamente
competitivos.
Seja na indstria (com a produo de
carros, avies e navios), na agricultura e
pecuria (produo de soja, milho e gado)
ou na medicina (procedimentos cirrgi-
cos, exames e diagnsticos), a produti-
vidade destes setores vem aumentando
consideravelmente ao longo dos anos. Ao
mesmo tempo, estes produtos e servios
tornaram-se mais sofisticados, exigindo
complexos controles operacionais que ga-
rantam a qualidade e nveis de excelncia
cada vez maiores.
Na verdade, estas organizaes inves-
tiram pesadamente na automao de
processos industriais e administrativos,
acelerando drasticamente seu modelo de
gesto de fornecimento de servios. Para
isso, empregaram todos os modernos
recursos tecnolgicos disponveis para
aprimorar seus nveis de agilidade e
controle operacional.
Organizaes que buscaram apenas
agilidade, alcanaram rapidamente seu
limite operacional. Com o aumento do
volume de negcios e a deficincia de
seus controles gerenciais, aumentaram
a incidncia de defeitos em produo
e o nvel de retrabalho em toda cadeia
produtiva, reduzindo sua lucratividade
e participao no mercado.
Organizaes que buscaram apenas o
controle operacional mantiveram nveis
de qualidade e excelncia compatveis
com as exigncias do mercado, mas com
prazos de entregas inviveis para uma
economia cada vez mais dinmica. Foram
ento surpreendidas por organizaes
mais geis que ofereciam os mesmos con-
troles operacionais, com prazos e custos
muito mais agressivos.
Portanto, todos os setores da economia
que sobreviveram e prosperaram, con-
seguiram combinar agilidade e controle
operacional em suas operaes. Provando
que estes dois elementos formam a ver-
dadeira base de sucesso das organizaes
do futuro.
Combinando Agilidade e Controle
Operacional ao Extremo
Para as Organizaes TI de Alto De-
sempenho, combinar agilidade e con-
trole operacional fundamental para a
construo de uma empresa altamente
competitiva, que atenda as exigncias de
mercado de curto, mdio e longo prazo.
Acreditar que a rea de TI deve se-
guir um modelo diferente dos demais
setores econmicos alienar-se de um
movimento global, onde a Tecnologia
da Informao atualmente o grande
gargalo operacional de todos os setores
da economia. Ser atravs dela, que os
saltos de produtividade e qualidade sero
conquistados e superados.
O mais interessante da Abordagem
Combinada (gil e controlado) que a
pista para a construo deste modelo
foi sugerida por Kent Beck no seu livro
Extreme Programing Explained: em-
brance change (um excelente livro), po-
rm aplicada em um contexto diferente,
resultando na proposta da filosofia XP
(eXtreme Programing), umas das abor-
dagens geis citadas.
Kent Beck mapeou o que considerava ser
as melhores prticas para a construo de
um software e idealizou um modelo onde
estes controles seriam representados por
botes individuais, nos quais poderamos
regular sua intensidade de utilizao (m-
nimo e mximo). Ento jogou o seguinte
desafio O que aconteceria a uma equipe

26 Engenharia de Software Magazine Agilidade ou Controle Operacional? Os dois!

 proc esso

de desenvolvimento se girssemos todos os

botes de boas prticas ao mximo? Deste
conceito derivamos o que foi estabelecido
como modelos extremos, onde as boas
prticas de trabalho devem ser levadas ao
seu limite, gerando ento o mximo da pro-
dutividade e desempenho das equipes.
Adotando a mesma abstrao proposta
por Kent Beck, podemos visualizar um
painel onde existam dois botes indivi-
duais, representando respectivamente
a agilidade e controle operacional que
uma empresa deseja obter. Seguindo
este modelo, podemos perguntar: O que
aconteceria com a organizao se gi-
rssemos estes dois botes ao mximo?
Figura 2. Explorando ao mximo agilidade e controle operacional nos processos TI
(ver Figura 2)
Teramos uma organizao TI altamente
competitiva, capaz de oferecer produtos
e servios de TI em prazos e custos cada
vez mais reduzidos, sem comprometer Isto significa que, as organizaes de- direo e abdicarmos das demais alter-
a qualidade e a confiabilidade de suas vem implementar medidas que aumen- nativas existentes.
entregas. tem a produtividade das equipes antes de At mesmo experientes executivos
introduzir novos controles, garantindo sentem-se pressionados em modificar
Implementando o Modelo um perfeito balanceamento entre os dois suas estratgias, mesmo quando no se
Combinado indicadores. encontram plenamente convencidos dos
Com a adoo do Modelo Combinado, Neste momento, as abordagens geis resultados prometidos pelas inovaes.
estaremos alinhando a estratgia da TI a traro considerveis contribuies para Mais do que abordagens, precisamos
todos os demais setores da economia de estabelecer mecanismos de resposta mais de uma viso de longo prazo, que oriente
mercado, que entendem como necessrio flexveis, oferecendo uma oportunidade nossa organizao ao futuro, fornecendo
serem controlados e geis simultanea- de implementao gradual dos conceitos elementos gerenciais simples que guiem
mente. geis no ambiente de TI. e avaliem nossas equipes de TI.
A abordagem do Modelo Combinado Desta forma, o Modelo Combinado No importa se seguiremos
no to diferente da abordagem do requer uma maior conscincia de seus uma linha mais prxima ao CMMI ou se
modelo controlado, baseando-se em pro- profissionais, exigindo um Plano de estaremos mais aderentes ao Manifesto
cessos e suportado por robustos controles Inovao Corporativa que contemplem gil. Quebrar recordes de produtividade
operacionais estabelecidos nos moldes inovaes que conciliem aumento de e qualidade so os grandes desafios das
do CMMI. produtividade e controle operacional em organizaes de TI do futuro.
A grande mudana do Modelo Combina- todos os projetos. Portanto, independente do t-
do definir como diretriz geral que, qual- tulo que daremos aos nossos processos
quer inovao corporativa a ser planejada Concluso (gil, Adaptvel, Clssico, Controlado,
na cadeia produtiva TI, quando acarretar No futuro, novas tendncias e filoso- Formal, Extremo, Burocrtico), o que ga-
em perda de agilidade, ser antecipada- fias iro continuamente balanar nossas rante que estamos no caminho certo ser
mente compensada por uma inovao convices de como devemos conduzir nossa capacidade de sermos mais geis e
que recupere ou aprimore o patamar de nossos projetos. Sempre seremos ques- controlados ao longo do tempo - esta a
produtividade das equipes de trabalho. tionados por escolher uma determinada proposta do Modelo Combinado.

Edio 01 Engenharia de Software Magazine 27

 O processo unificado integrado ao
desenvolvimento Web
Rodrigo S. Prudente de Aquino
rodrigo@wpage.com.br
bacharel em Cincia da Computao pela
PUC-SP e MBA em Engenharia de Software
pela USP. Foi analista de sistema na Petrobras
e trabalhou como Gerente de Tecnologia Web
em uma das maiores agncias de marketing
direto do Brasil. Escritor de artigos e pales-
trante em universidades, Rodrigo S. Prudente
de Aquino autor do livro WPage - Padro-
nizando o Desenvolvimento de Web Sites
(www.wpage.com.br). Atualmente, trabalha
como Lder de Projeto no Grupo Totvs.
28 Engenharia de Software Magazine O processo unificado integrado ao desenvolvimento Web
C
om o propsito de auxiliar os for-
necedores de solues de softwa-
re que utilizam como plataforma
a internet, este artigo objetiva formalizar
idias prticas, explicando como o de-
senvolvimento de sistemas Web pode
ser integrado ao Processo Unificado.
Sero apresentados alguns artefatos para
controlar o desenvolvimento de um Web
Site, alm das vantagens e os cuidados
a tomar com a integrao de forma a
facilitar a entrega. Sero apresentados
tambm alguns pontos relacionados com
a gerncia e o plano de execuo.
Alm disso, explica-se como o Processo
Unificado pode ser configurado de acor-
do com o tempo que uma empresa possui
para desenvolver um projeto voltado para
internet.
Processo Unificado
O Processo Unificado um processo
de desenvolvimento fortemente ligado
orientao a objetos, porm, pode-se sempre abrange todo o fluxo de trabalho.
utiliz-lo em qualquer projeto mesmo
sendo ele estruturado, sem que perca
suas caractersticas bsicas. Ele utiliza
alguns princpios modernos (compo-
nentizao, revises, etc) na rea de
engenharia de software.
Algumas caractersticas bsicas do
Processo Unificado so:
Direcionado por casos de uso: O in-
cio do processo deve ser marcado pela
utilizao dos casos de uso, a fim de se
definir uma linguagem entre os usurios
e o sistema, facilitando a especificao
dos requisitos.
Centrado na arquitetura: O processo
procura modelar uma arquitetura atravs
dos aspectos estticos e dinmicos de um
projeto, que podem ser obtidos junto a
um estudo direcionado pelos casos de
uso mais significativos.
iterativo e incremental: Uma das
prticas do processo dividir grandes
projetos em mini-projetos. Cada mini-
projeto possui uma iterao, que quase
Olhando como um todo, essa iterao

resulta em um incremento para o projeto.
vlido lembrar que as iteraes so pla-
nejadas de acordo com os casos de uso.
O Processo Unificado visa tornar clara
a necessidade de atribuies de tarefas
a grupos ou indivduos envolvidos di-
retamente no desenvolvimento de um
projeto. Alm disso, deve-se definir o
quanto antes, quais as etapas (iteraes) e
os artefatos que sero envolvidos durante
o processo. Com essas caractersticas,
conclui-se que o Processo Unificado
um modelo configurvel, ou seja, deve
ser ajustado de acordo com os tipos de
projeto que se necessita desenvolver.
A Figura 1 apresenta a relao entre as
fases, iteraes e os fluxos de trabalho
dentro do Processo Unificado.
Concepo ou iniciao: Essa fase tem
como objetivo verificar a viabilidade do
projeto, bem como os riscos e um dos
fatores no menos importantes: definir
os casos de uso mais crticos obtendo
as funes chave do sistema. atravs
do tipo do projeto, dos casos de uso e
consequentemente dos requisitos, que
se realizar o ajuste de quantas iteraes
o processo ter. De acordo com os casos
de uso, pode-se definir tambm quais as
etapas exigiro maior cuidado.
Elaborao: Durante essa fase, a maio-
ria dos casos de uso so especificados e
detalhados. A arquitetura do sistema
projetada utilizando artefatos que po-
dem ser estticos ou dinmicos. Neste
instante so apresentados, o Baseline
completo do projeto, os componentes
que formaro a equipe de desenvolvi-
mento, etc. No final dessa fase os envol-
vidos devem estar aptos a planejar a fase
de construo em detalhes.
Construo: A fuso de vrios artefatos
de software ocorre neste momento, pos-
sibilitando que o sistema seja implemen-
tado quase que completamente. Tem-se
uma viso geral de como o Baseline do
projeto est sendo seguido. No final dessa
fase, o sistema deve estar totalmente pre-
parado para a transio ao usurio.
Transio: O objetivo dessa fase
garantir que todos os requisitos do pro-
jeto foram atendidos e implementados
corretamente. O produto final pode ser
liberado em uma verso beta. Existem
ainda outras atividades que, de acordo
com o projeto, podem ocorrer de manei-
ra paralela, por exemplo, a preparao
proc esso
do ambiente, a concluso do manual Anlise e Projeto: No incio desse fluxo
do usurio, identificao e correo de de trabalho, desenvolve-se uma viso
defeitos. No final dessa fase deve-se tirar arquitetural, incluindo os artefatos
uma concluso geral do projeto, obtendo significativos para o modelo de projeto.
os pontos positivos e negativos os quais O objetivo aqui compreender os casos
devem ser utilizados durante a concepo de uso mais importantes, que sero
de projetos futuros. insumos para a elaborao de alguns
artefatos, como: um diagrama de classes,
Em relao aos fluxos de trabalho, ou de estado, de iterao, de seqncia, de
disciplinas, tem-se os seguintes escla- colaborao, etc. vlido lembrar que
recimentos. no necessria a utilizao de todos os
Modelo do negcio: O objetivo princi- artefatos, mas apenas aqueles que sejam
pal desse fluxo que o fornecedor enten- relevantes a fim de que o cliente entenda
da muito bem o problema a ser resolvido, perfeitamente o que ser construdo. Com
elaborando se necessrio uma anlise de artefatos bem elaborados, a equipe de
risco e de viabilidade para o projeto como desenvolvimento ter grandes facilidades
um todo. Neste momento, existe uma em realizar a implementao. No incio
grande interao entre o fornecedor e o deste fluxo encontra-se, caso necessrio,
cliente. A fim de que possam ser gerados prottipos de funcionalidade e de inter-
os casos de uso e consequentemente face, como tambm uma descrio da
a extrao dos requisitos. Entender o arquitetura bsica do sistema. Durante
modelo de negcio do cliente pea fun- o desenvolvimento do projeto alguns
damental antes que um requisito possa artefatos podero sofrer ajustes de acordo
ser definido. com as implementaes realizadas.
Requisitos: Nesse fluxo procura-se Implementao: No incio desse flu-
extrair os requisitos do sistema a ser de- xo, os desenvolvedores podero bus-
senvolvido. A grande dificuldade nesta car componentes (funes) que foram
etapa e no desenvolvimento de software utilizados em outro sistema. Ainda
capturar requisitos de forma que os clien- na fase de concepo, pode-se ter um
tes possam entender claramente o que o prottipo de funcionalidade como um
sistema se prope a fazer. A base para isso produto final em primeira instncia. No
que o fornecedor entenda o domnio do decorrer deste fluxo, procura-se ter um
problema e consequentemente construa sistema executvel a cada iterao, alm
um bom modelo de casos de uso. A ex- da implementao baseada nos artefatos
trao dos requisitos, atravs dos casos criados no modelo de anlise e projeto.
de uso, ir compor um artefato que ser O conceito de componentizao deve ser
evoludo durante todo o projeto. sempre levado em considerao, com o
Figura 1. Overview do Processo Unificado
Edio 01 Engenharia de Software Magazine 29
intuito de que estes segmentos de cdigos
possam ser aproveitados mais tarde por
outros sistemas.
Testes: Neste fluxo, um plano de teste
deve ser elaborado, definindo e identifi-
cando qual procedimento e quais tipos
de testes sero realizados. Esse plano
poder ser alterado de acordo com a me-
lhor definio dos requisitos do sistema.
Ele tambm poder ser utilizado durante
todo o projeto, sendo modificado a cada
iterao, mostrando a situao do execu-
tvel que foi entregue ao cliente. Nas fases
No menos importante, a alterao da documenta-
o deve estar completamente condizente com o que foi
implementado.
de concepo e de elaborao tm-se os
testes de mdulos e na fase de construo
tm-se os testes de integrao. O nmero
de testes de integrao poder se repetir
de acordo com a quantidade de alteraes
nos requisitos do sistema.
Implantao: Descreve-se nesse fluxo
de trabalho, a instalao do sistema no
ambiente do cliente. Durante toda a
fase de elaborao, at o meio da fase
de construo, um simples documento
especificando algumas caractersticas do
ambiente do cliente poder ser realizado.
Este artefato pode conter, por exemplo,
especificaes tcnicas sobre a infra-
estrutura de rede e de sistemas suportada
pela empresa contratante. Alm disso,
algumas dicas de instalao podem ser
acrescentadas nesse artefato de forma a
reduzir mais tarde, o nmero de erros de
instalao e consequentemente o tempo
de testes. No final da fase de construo,
inicia-se a migrao do sistema para o
ambiente de testes do cliente. Posterior-
Figura 2. Planilha de requisitos
30 Engenharia de Software Magazine O processo unificado integrado ao desenvolvimento Web
mente, no final da fase de transio, j
se pode observar a completa migrao e
configurao do sistema no ambiente de
produo do cliente.
Gerncia de configurao e mudana:
durante esse fluxo de trabalho que
so controlados todos os artefatos do
projeto, bem como suas verses. Antes
de realizar uma mudana, deve-se fazer
uma anlise em relao ao que deve ser
modificado e saber em quais artefatos e
reas da implementao isso ir afetar. senvolver o projeto. Ele pode ser caracte-
Um bom controle de mudana crucial
para garantir o sucesso e a qualidade do
projeto. medida que o projeto entra
na fase de construo, a dificuldade no
controle de mudana e gerncia de con-
figurao aumenta. Isso ocorre porque o
projeto est maior, com mais requisitos
implementados e com maiores chances
de que uma alterao possa afetar outras
reas do sistema. Ter rastreabilidade e sa-
ber relacionar os requisitos uma tarefa
importante do engenheiro de software.
Aps uma modificao, necessita-se de
novos testes em vrias reas do sistema,
garantindo que a mudana foi implemen-
tada corretamente. No menos impor-
tante, a alterao da documentao deve
estar completamente condizente com o
que foi implementado.
Gerenciamento de projeto: Nesse fluxo
se escolhe os artefatos a serem utilizados
no desenvolvimento da aplicao, de
acordo com o tipo do projeto e o enten-
dimento do cliente. O gerente deve ter
uma viso clara do que o cliente deseja,
do que est documentado e do que est
sendo implementado. A atividade de
gerenciamento de projeto constante
durante todo o ciclo de vida do software,
elaborando reunies com RTF (Reviso
Tcnica Formal), garantindo a correta
mudana dos artefatos, alm da necessi-
dade de manter um bom relacionamento
com o cliente.
Ambiente: Esse fluxo representa o
ambiente de trabalho da empresa que de-
rizado pelo tipo de plataforma, pela rede,
pela organizao dos diretrios no qual
ficaro os artefatos e os cdigos fonte, pelo
sistema de backup etc. Pode-se perceber
na Figura 1 que no final de cada iterao,
tm-se ajustes no ambiente. Esses ajustes
podem ser do tipo: criao de diretrios, o
backup das verses do software, etc.
As iteraes, nada mais so do que mar-
cos durante a construo de um sistema
utilizando o Processo Unificado. Um
aspecto muito importante que o nmero
de iteraes deve ser definido logo no
incio de cada projeto (elas podem variar
de nmero de acordo com o tamanho do
sistema a ser desenvolvido). Uma iterao
normalmente marcada pela entrega de
uma verso executvel do sistema e uma
reunio formalizada atravs de uma RTF
(Reviso Tcnica Formal). Em geral, o re-
sultado de uma iterao um incremento
para o sistema. Entende-se tambm que
uma iterao como se fosse uma foto
tirada da aplicao num determinado
instante. um marco indicando o final
de um mini-projeto.
Artefatos especficos utilizados no
desenvolvimento de projetos Web
D urante a construo de aplicaes
web pode-se utilizar inmeros tipos de
artefatos. Sero citados a seguir, alguns
documentos que podero ser utilizados
no Processo Unificado.
 proc esso

Planilha de requisitos
Para elaborar um sistema Web, neces-
srio um levantamento dos requisitos.
Neste contexto, precisa-se de um arte-
fato para armazenar estas informaes.
Utilizaremos neste artigo uma planilha
Excel como artefato, de forma a explicar
simplificadamente a organizao dos
requisitos. A planilha Excel ter as carac-
tersticas representadas na Figura 2.
Nesta planilha temos:
Cdigo: Identifica unicamente um
requisito a fim de que se possa control-lo
atravs do projeto.
Descrio: Nesta coluna descreve-se
o requisito.
Categoria: Indica qual o tipo do
requisito (ver Tabela 1).
Prioridade: Indica o nvel de impor-
tncia que o requisito possui para o sis-
tema em geral, podendo ser baixa, mdia
ou alta.
Dificuldade: Indica o nvel de difi-
culdade para implementar este requisito,
podendo ser baixa, mdia ou alta.
Atendido: Representa o status do
requisito, indicando se o mesmo foi ou
no implementado no sistema.
Comentrios: Fornece informaes
sobre o requisito, dizendo, por exemplo,
o motivo que um determinado requisito
ainda no foi implementado (indicando
mais especificamente, quais so as difi-
culdades).
A planilha de requisitos um artefato
vivo no ciclo de vida do projeto e deve
ser incorporado rea de SCM (Software
Configured Management) do Processo
Unificado. A expresso artefato vivo
indica que a planilha est apta a sofrer
alteraes no decorrer do projeto.
Projeto Linear
Alm da planilha de requisitos, esse
um dos artefatos mais importantes para
o desenvolvimento de um sistema Web.
Nele podero ser mapeados os requisitos
do sistema com as reas ou pginas de
uma aplicao. Cada pgina receber um
cdigo, que por sua vez ser relacionado
com nenhum, um ou mais requisitos.
Atravs deste documento bus-
ca-se um maior controle do sistema,
pois se houver quaisquer modificaes
nos requisitos o fornecedor saber
quais reas devem sofrer mudana. Este
tambm um artefato vivo e deve ser
incorporado ao fluxo de trabalho de ge-
rncia de configurao e mudana (SCM
- Software Configured Management). A
Figura 3 apresenta um exemplo de como
seria uma simples representao de um
Projeto Linear, mostrando algumas reas
do site, com seus respectivos requisitos
relacionados.
Web Content
O Web Content um artefato de sof-
tware responsvel pelo armazenamento
de todo o contedo textual utilizado
em um site. No existe um documento

Requisitos Funcionais

Requisitos Estveis: So aqueles que derivam da atividade fim da organizao e so relativos diretamente ao domnio do sistema.

Requisitos Volteis: So requisitos que mudam ao longo do desenvolvimento ou aps o incio da operao. Dentro dele, existem:

Requisitos Mutveis: So requisitos que se alteram em razo das mudanas no ambiente no qual est operando.

Requisitos Emergentes: So requisitos que no podem ser completamente definidos quando o sistema est em desenvolvimento.

Requisitos Conseqentes: So requisitos baseados em premissas de como o sistema ser usado. Quando o sistema colocado em operao, ocorrem mudanas.

Requisitos No Funcionais

Requisitos de Produto: So aqueles especficos do comportamento do produto. Dentro dele, existem:

Requisitos de usabilidade

Requisitos de eficincia

Requisitos de disponibilidade

Requisitos de portabilidade

Requisitos de confiabilidade

Requisitos Organizacionais: So aqueles derivados de polticas e procedimentos organizacionais do cliente e dos desenvolvedores. Existem os seguintes tipos de requisitos organizacionais:

Requisitos de verso: definindo o produto e quais os documentos so necessrios para liberar uma verso para o usurio.

Requisitos de implementao: envolve linguagens de programao, banco de dados, etc.

Requisitos de padres: envolve os padres a serem usados.

Requisitos Externos: So aqueles derivados de fatores externos ao sistema e ao seu processo de desenvolvimento.

Requisitos de interoperabilidade: definio de como o sistema interage com outros sistemas.

Requisitos tnicos: assegurando que o sistema ser aceito pelos usurios e pelo pblico em geral.

Requisitos de legislao: devem ser seguidos para assegurar que o sistema vai operar de acordo com normas vigentes. Pode ser dividido em: requisito de privacidade e requisito de segurana.

Tabela 1. Tipos de requisitos

Edio 01 Engenharia de Software Magazine 31

padro de Web Content. Normalmente
cada empresa que desenvolve aplicaes
web possui o seu.
O Web Content formado de acordo
com os requisitos do sistema e entende-
se que o mesmo pertence ao fluxo SCM
(Software Configured Management)
do Processo Unificado. Na Figura 4
exemplifica-se como seria uma pgina
de um Web Content.
muito importante lembrar que esse
artefato formado no s de uma, mas
vrias sees, onde cada uma indica o
contedo de cada pgina do site. Com
o Web Content, o fornecedor consegue
agrupar e gerenciar melhor o contedo
de um site.
Figura 3. Projeto Linear e requisitos
Figura 5. Wireframe (pgina do FDD)
32 Engenharia de Software Magazine O processo unificado integrado ao desenvolvimento Web
FDD (Wireframes)
O FDD (Functional Design Document)
um conjunto de Wireframes onde cada
um representa uma pgina da aplicao.
Um Wireframe uma maquete da pgina
Web que se dirige somente disposio
de elementos, no esttica. Ele o
esboo de como seria uma pgina, des-
prezando cores e imagens. A vantagem
em utilizar um Wireframe como guia
para implementao, que ele trabalha
representando o fluxo da informao projeto, apesar de ter um papel muito
estabelecido anteriormente no Projeto
Linear. Ele pode ser desenvolvido pelo
arquiteto de informao.
O uso de um FDD estabelece uma forte
ligao da arquitetura da informao
com a estrutura do site, colocando a in-
formao no seu respectivo local. Alm
disso, um FDD bem organizado pode
oferecer fortes solues para os proble-
mas de usabilidade. Outra caracterstica
importante deste artefato que ele pode
informar onde encontrar o contedo para
aquela respectiva pgina dentro do Web
Content.
A desvantagem do FDD que ele no
apresenta uma soluo grfica para o
importante em conduzir a proposta de
layout a ser construda pelo designer. Em
relao ao desenvolvimento de um Web
Site, o FDD torna-se um dos artefatos
mais completos, que auxiliam muito os
programadores, pois eles criam uma re-
lao entre a pgina a ser implementada
e o contedo a ser aplicado. A Figura
5 apresenta como seria um Wireframe
dentro de um FDD - representando uma
determinada pgina de um site.
Prottipo de interface
O prottipo pode ser uma parte da apli-
cao implementada, prottipo de fun-
cionalidade, ou uma proposta de layout,
prottipo de interface, feita pelo designer
e aprovada pelo cliente. Este item fornece
algumas informaes apenas sobre o
prottipo de interface. Para chegar at o
prottipo, o designer precisa utilizar o
FDD ou pelo menos uma parte dele para
ter noes de como ser a diviso do site.
A principal funo deste artefato forne-
cer ao cliente quais sero as cores bsicas
Figura 4. Ilustrao de uma pgina do Web
Content

da aplicao, uma parte da arquitetura de
informao e como ficaro disponibiliza-
das as informaes aos usurios dentro
do site. A vantagem na utilizao deste
artefato direcionar totalmente a equipe
de anlise e projeto, bem como a equipe
de implementao.
O Processo Unificado integrado ao
desenvolvimento Web
Neste item, explica-se como configurar
o Processo Unificado de acordo com o
sistema a ser desenvolvido, obtendo uma
determinada quantidade de iteraes.
Alm disso, descreve-se o esforo gasto
para construir cada artefato Web em
razo das fases do processo.
Configurando o Processo Unificado
Antes de iniciar o desenvolvimento de
qualquer projeto utilizando o Processo
Unificado, necessrio determinar os flu-
xos de trabalho mais utilizados, o nmero
e o tempo de cada iterao dentro das
fases. Para um sistema Web, normalmente
consideram-se todos os fluxos de trabalho
do processo, ou seja, modelo de negcios,
requisitos, anlise e projeto, implementa-
o, teste e implantao. Com o objetivo
de esclarecer melhor a configurao do
Processo Unificado imagina-se, para este
artigo, o desenvolvimento de um Web Site
contendo um prazo de trs meses.
Ao ser definido o prazo de entrega,
o processo comea a ser modelado
medida que o Baseline construdo.
Considerando que o fornecedor tenha
Fases Tempo
Concepo 1 semana
Elaborao 2,5 semanas
Construo 6 semanas
Transio 2,5 semanas
Tabela 2. Diviso das fases do projeto
Artefatos
Planilha de requisitos
Projeto Linear
Web Content
FDD (Wireframes)
Prottipo de Interface
Tabela 3. Mensurao de esforo X fases
conhecimento da viso de negcio do
cliente e do sistema a ser desenvolvido
como um todo, pode-se, por exemplo,
dividir as fases do projeto conforme
apresentado na Tabela 2.
importante destacar que a Tabela 2
apenas um exemplo baseado na ilustra-
o do Processo Unificado, presente no
segundo tpico deste artigo. A quantida-
de de tempo e iteraes que um sistema
Ao ser definido o prazo de entrega, o processo comea a
ser modelado medida que o Baseline construdo.
ter ir variar muito em razo do tipo
do projeto, do nmero de profissionais
envolvidos, do prazo de entrega, das
funcionalidades, etc. O tempo de experi-
ncia da equipe de desenvolvimento um
fator importante, de forma a identificar
e combater os pontos crticos durante a
implementao da aplicao.
A Tabela 3 apresenta uma aproximao
da quantidade de esforo gasto em cada
artefato de software voltado para Web,
relacionando-os ao Processo Unificado.
Relacionando artefatos, fases do
processo e fluxos de trabalho
Descreve-se detalhadamente neste item,
o que deve ser feito em todos os fluxos de
trabalho, atravs do nmero de iteraes
definidas na configurao do processo
unificado.
Iteraes Fase Concepo - 1. Iterao casos de uso so aprovados pelo cliente.
1 A 1 iterao ocorre praticamente depois
de toda a fase de concepo do projeto,
1
tendo como referncia a Figura 1. No
2 final dessa iterao, deixa-se claro quais
os artefatos faro parte da gerncia de
1
configurao e mudana, ou seja, aqueles
Concepo Elaborao Construo Transio A arquitetura de informao descrita
30% 50% 15% 5%
20% 70% 10% 0%
15% 70% 15% 0%
10% 60% 30% 0%
100% 0% 0% 0%
Edio 01 Engenharia de Software Magazine
proc esso
artefatos que ainda sofrero algum tipo
de alterao no decorrer do desenvolvi-
mento do projeto.
Modelo de negcio: Neste fluxo, se o
fornecedor achar necessrio, pode-se re-
alizar um documento indicando a anlise
de viabilidade e de risco do projeto. Caso
esteja difcil para o fornecedor entender
o domnio do problema, deve-se elaborar
um diagrama de casos de uso do negcio,
bem como sua descrio, ficando mais
fcil chegar ao domnio da soluo. Os
casos de uso do negcio daro suporte
ao diagrama e a descrio de casos de
uso do sistema. Nesse fluxo, o Baseline
do projeto comea a ser construdo,
contemplando custos, prazos, cargos e
nmero de pessoas envolvidas. vlido
destacar que s vezes, o Baseline pode ser
modificado de acordo com as iteraes
do processo. Um cliente pr-ativo em
resolver as dvidas do fornecedor, con-
segue diminuir as chances de impactar
o desenvolvimento de algumas partes
do projeto, como tambm uma possvel
alterao no Baseline.
Requisitos: A extrao dos requisitos
deve ser feita medida que os casos de
uso do sistema so realizados e validados.
Conclui-se que a montagem da planilha
de requisitos aumenta medida que os
Mesmo sem a arquitetura de informao
do site, o prprio cliente, por exemplo,
j pode obter informaes sobre o que
deseja, em relao ao contedo que ser
apresentado em sua aplicao.
Anlise e Projeto: Este fluxo utilizar
at o momento, todos os requisitos cons-
trudos e aprovados dentro da planilha.
no Projeto Linear j pode ser montada
se baseando nos requisitos. no Projeto
Linear que sero mapeados os cdigos
de cada pgina do site, a descrio da
rea e a identificao dos requisitos. Note
que uma pgina do site poder estar
relacionada a nenhum, um ou a vrios
requisitos. Com este artefato garante-se
mais tarde a rastreabilidade. A estru-
33
turao quase que definitiva do Web
Content pode ser feita pelo fornecedor e
pelo cliente, ainda neste fluxo, no final
da 1 iterao.
Mediante a construo do Projeto Linear
e do Web Content, inicia-se a montagem
FDD. O FDD servir como guia para o
designer montar o prottipo de interface
do site. A finalizao do prottipo e a
aprovao do cliente marcam o final da
1 iterao.
Implementao: Nesse momento os
desenvolvedores podem, por exemplo,
buscar funes e componentes j desen-
volvidos em outros projetos, os quais
serviro para a realizao desta aplicao. sentado pelo crculo vermelho), o Projeto
A preparao do ambiente de desenvol-
vimento tambm pode ser feita, como a
instalao dos softwares e ferramentas
necessrias para a implementao. Neste
fluxo, d-se a construo do diagrama
de classes, bem como outros diagramas
UML que os engenheiros de software
acharem necessrios, para o entendimen-
to e validao do sistema pelo cliente. Ob-
jetivando diminuir as chances de algum
requisito ser implementado de forma
incorreta, vlido que alguns desen-
Figura 6. Overview da 1 iterao
34 Engenharia de Software Magazine O processo unificado integrado ao desenvolvimento Web
volvedores participem de reunies com
os clientes, tirando suas dvidas, como
tambm revalidando os requisitos.
Teste: Esse fluxo pode ser marcado com
o incio da construo de um artefato
chamado plano de teste. Essa construo
dever ser direcionada pelos requisitos
do sistema obtidos at o momento.
Implantao: No h. guintes artefatos sob gerncia de confi-
A Figura 6 apresenta um overview
da construo do sistema, levando-se
em considerao os artefatos utilizados
no desenvolvimento de projetos Web.
Conclui-se que o Web Content (repre-
projeto. A RTF e o prottipo de interface,
Linear (representado pelo crculo preto)
e o FDD (representado pelo crculo azul)
esto em fase de formao, por isso eles
esto tracejados. A rea com cor cinza
claro da Figura 6 representa que pou-
cos requisitos foram encontrados nesta
iterao do processo. Os crculos em
amarelo em volta do FDD e do Projeto
Linear representam que estes documen-
tos necessitam de um conhecimento
em arquitetura de informao para que
possam ser elaborados.
Aps a primeira iterao, um Wireframe
(uma parte do FDD) dever ser enviado
ao designer, que se responsabilizar
pela construo da proposta de layout.
A proposta de layout no ter o papel de
mostrar interaes e funcionalidades do
sistema ao cliente.
Ao final dessa iterao, tm-se os se-
gurao e mudana: FDD, Projeto Linear,
Web Content, Planilha de requisitos,
descrio dos casos de uso, plano de
teste, documento de Baseline e quaisquer
outros artefatos da UML que podem ser
includos mediante a necessidade do
aprovado pelo cliente, estabelecidos no
final dessa iterao, no faro parte da
gerncia de configurao e mudana,
pois so artefatos mortos, os quais no
sofrero mais modificaes.
Fase Elaborao - 2. Iterao
No contexto apresentado, a 2 iterao
abrange toda a fase de elaborao do pro-
jeto. J no existem mais esforos voltados
para o prottipo de interface. Ele servir
apenas para guiar a montagem da estru-
tura dos templates do site. Essa iterao
levar mais tempo para acontecer do que
a primeira, pois neste instante os esforos
vo se concentrando e os envolvidos no
projeto precisam entender e resolver os
problemas mais crticos que comearo
a aparecer.
Modelo de negcio: Anlises de viabi-
lidade e de riscos podem e muitas vezes
devem continuar sendo feitas. O domnio
do problema deve ser entendido comple-
tamente e uma soluo deve ser descrita
atravs dos casos de uso que estaro
80% finalizados no final desse fluxo de
trabalho. A planilha de requisitos cresce
na mesma proporo em que os casos
de uso so validados pelo fornecedor e
cliente.
Requisitos: Os requisitos continuam
sendo extrados dos casos de uso e
compondo a planilha. No final dessa
iterao tem-se 80% dos requisitos j
documentados e aprovados pelo cliente.
Os requisitos so a base para a construo
dos artefatos, como o FDD, Web Content
e o Projeto Linear. Por essa razo tem-se
grande parte da formao desses docu-
mentos ainda nesta iterao.
Anlise e Projeto: Os requisitos apro-
vados at o momento serviro como
 proc esso

base para a quase completa formao do requisitos so extrados (rea em cinza uma nova caracterstica para o projeto e
Projeto Linear, do Web Content e conse- mais escura em relao s da Figura que os gerentes julguem a necessidade
quentemente do FDD. A Figura 1 fornece 6, indicando que mais requisitos esto de construo para melhor entender o
uma idia da quantidade de esforo sendo extrados). problema.
gasto para construir cada artefato. Como No final desta iterao, os artefatos Requisitos: Os requisitos ainda conti-
explicado anteriormente, o Web Content estaro quase que totalmente concludos. nuam sendo extrados dos casos de uso
e o Projeto Linear so documentos que Eventuais ajustes podem ocorrer na Ba- e compondo a planilha. No final dessa
possuem forte ligao com o FDD, e este seline e devem ser feitos pelo gerente do iterao, tem-se em torno de 95% dos
depende muito das informaes dos dois projeto. A RTF construda avaliando e requisitos j documentados e aprovados
primeiros artefatos, a fim de que seja cor- formalizando toda a iterao, servindo de pelo cliente. Dessa forma, o FDD, o Web
retamente construdo. Alguns artefatos aprendizado e preparando os envolvidos Content e o Projeto Linear, estaro tam-
da UML podero ser desenvolvidos nessa para a prxima fase do projeto. bm, quase completamente elaborados.
fase, com o objetivo de ajudar o cliente a Anlise e Projeto: Alguns artefatos da
entender o sistema. Fase Construo - 3 e 4 Iterao UML, escolhidos para melhor representar
Implementao: Inicia-se a juno de Neste contexto, a 3 e 4 iteraes iro as caractersticas do sistema, sero fina-
todas as funes e componentes pes- compor toda a fase de construo do pro- lizados durante essas iteraes. vlido
quisados no incio do projeto, com os jeto. Mais especificamente, a 3 iterao lembrar que, exatamente nesse momento,
artefatos desenvolvidos at o momento. indica o meio da fase de construo, en- o desenvolvedor poder necessitar de
Os desenvolvedores precisam estar aptos quanto que a 4, marca o final dessa fase. algum outro artefato da UML o qual
a entender no s os artefatos como o Eventuais ajustes nos artefatos surgiro no havia escolhido anteriormente para
FDD, Web Content e o Projeto Linear, em razo da implementao. representar alguma parte do sistema.
mas tambm os possveis diagramas da Modelo de negcio: As anlises de Normalmente, essas escolhas so feitas
UML e, principalmente os requisitos ge- viabilidade e de risco diminuem e ser- devido a alguns requisitos crticos.
rados at o instante. Deve-se ter cuidado vem agora apenas para pequenas tarefas Implementao: Os programadores de-
com padres, de forma que o cdigo seja realizadas no decorrer do projeto. Dificil- vero possuir um suporte quase completo
construdo seguindo o conceito de com- mente, durante essas iteraes, tem-se de dos artefatos Web citados anteriormente.
ponentizao, para que seja facilmente reconstruir um modelo de casos de uso A maioria dos esforos do projeto so
reutilizado mais tarde. do negcio, a no ser que o cliente solicite voltados agora para implementao e
Teste: Esse fluxo pode apresentar
alteraes no plano de teste devido ao
nmero de requisitos j extrados. Em
conjunto com a fase de implementao,
so realizados testes de mdulos, com
objetivo de verificar o que est sendo
feito. importante lembrar que estes
testes no iro validar um requisito, mas
apenas verificar se ele foi implementado
corretamente.
Implantao: De forma a verificar se o
que est sendo feito em relao codifi-
cao ir funcionar do lado do cliente, no
final dessa iterao, tem-se a implantao
do que j foi codificado at o momento.
De acordo com o resultado, algumas fun-
es podero exigir um cuidado especial
e serem modificadas. Durante esse fluxo,
podero surgir alguns requisitos no
funcionais, no encontrados durante a
anlise do sistema.
A Figura 7 mostra que o objetivo agora
no mais entregar o prottipo de inter-
face e sim, finalizar os documentos para
que a equipe de desenvolvimento possa
codificar o sistema de maneira rpida e
correta. As linhas tracejadas, com menos
espaos em relao s linhas da Figura 6,
representam que os artefatos esto quase
completos. Isso ocorre medida que os Figura 7. Overview da 2 iterao

Edio 01 Engenharia de Software Magazine 35

para a gerncia das possveis mudanas
nos requisitos e consequentemente nos
artefatos. Cuidados especiais devem ser
tomados nesse momento, de forma a ga-
rantir que uma mudana no afete outra
parte do sistema.
Teste: Nesse fluxo, consegue-se enten-
der os pontos crticos de implementao
e elaborar o plano de teste quase que
totalmente. Os testes caixa preta so
muito importantes nestas iteraes, pois
eles iro verificar a conformidade do sis-
tema com as exigncias do cliente. Testes
de mdulos continuam sendo feitos e
neste instante os desenvolvedores faro
tambm os testes de integrao.
Implantao: medida que a codifica-
o finalizada, uma verso executvel apresentado neste artigo, integrando o
do sistema poder ser implantada no
ambiente do cliente. A implantao
tambm uma forma de verificar se o que
est sendo feito funcionar do lado do
cliente.
A Figura 8 mostra que os documentos
esto sendo quase finalizados (pode-se
notar pelas linhas tracejadas com menos
espaos em relao Figura 7) medida
que os requisitos ficam mais consistentes
Figura 8. Overview da 3 e 4 iterao
36 Engenharia de Software Magazine O processo unificado integrado ao desenvolvimento Web
(cor mais escura na rea que abrange os ses de viabilidade e de risco. Devem-se
requisitos). Artefatos como o FDD, Web armazenar os casos de uso do projeto
Content, Projeto Linear, descrio e dia- com boas descries representativas, a
gramas de casos de uso etc, continuam a fim de que sejam facilmente encontrados,
fazer parte da gerncia de configurao de forma a servir como modelo para
e mudana. projetos futuros.
As duas RTFs construdas nessa fase Requisitos: Os requisitos nesse fluxo
iro acrescentar muito para a experincia so mnimos. mais comum encontrar
dos desenvolvedores, ensinando-os que, alguns requisitos de engenharia (no
sempre existe a possibilidade da altera- funcionais) devido parte do sistema
o de um requisito. O gerente continua j implantada no cliente. Os artefatos
a trabalhar atentamente na gerncia de devem estar finalizados de acordo com
configurao e mudana, que serve tan- todos os requisitos funcionais e no fun-
to para o Baseline quanto para todos os cionais encontrados at o momento.
artefatos vivos do projeto. Anlise e Projeto: Nesse fluxo, tem-se
Fase Transio - 5 Iterao a finalizao do FDD, Web Content e
Esta a ltima iterao do exemplo do Projeto Linear. Os artefatos da UML
tambm sero finalizados durante essa
desenvolvimento Web com o Processo iterao.
Unificado. O final dessa iterao marca Implementao: O ideal que os de-
o trmino do projeto, bem como a cons- senvolvedores faam ajustes no sistema,
truo completa de todos os artefatos. apenas para a adaptao ao ambiente do
A gerncia de configurao e mudana, cliente. Pouqussimas alteraes nos re-
ainda continua trabalhando durante os quisitos funcionais devem ser realizadas
fluxos para deixar os artefatos condizen- nesse fluxo e consequentemente, poucas
tes com o sistema desenvolvido. modificaes no sistema.
Modelo de negcio: Dificilmente nesta Teste: Nesse fluxo, o documento de
etapa existiro tarefas que exijam anli- plano de teste ser finalizado. Testes
de sistemas e de validao podem ser
realizados tambm pelo cliente. Se ne-
cessrio, poder ocorrer a contratao de
uma empresa terceirizada para realizar
os testes funcionais e no funcionais na
aplicao.
Implantao: A verso executvel
final do sistema dever ser colocada no
ambiente de teste e posteriormente no
ambiente de produo do cliente, me-
diante aprovao do mesmo. vlido
lembrar que, o gerente ou o engenheiro
de software responsvel pelo controle
de configurao e mudana, continuar
a realizar o seu trabalho, pois no final
dessa fase, alguns artefatos podero ser
ajustados.
A Figura 9 mostra que os requisitos
esto completos (cor escura) e consequen-
temente os documentos esto finalizados
(linhas contnuas em torno do Web Con-
tent, Projeto Linear e do FDD). Outros
artefatos, como a descrio e diagramas
de casos de uso, plano de teste, planilha
de requisitos estaro completos no final
dessa iterao.
A RTF indicar os pontos fortes e fracos
do projeto, ocorridos durante essa fase.
Tem-se o backup de todas as verses do
software realizadas at o momento, bem
 proc esso

como o armazenamento dos componentes alterao de funcionalidade envolve o senvolvimento de projetos Web, podem
desenvolvidos nos seus respectivos diret- desenvolvedor desde o incio, que ter ser usados durante a construo de um
rios. Uma boa documentao importan- uma viso de como essa alterao dever sistema baseado no Processo Unificado.
te, de forma a facilitar a recuperao dos ser implementada. Com isso, consegue- Alm disso, mostrou-se um exemplo pr-
componentes para projetos futuros. se maior controle para que outras partes tico indicando como o processo pode ser
do sistema continuem se comunicando e ajustado de acordo com o tipo e tamanho
Um requisito mudou, e agora? funcionando normalmente. de um projeto. A configurao do pro-
Uma das grandes preocupaes do ge- cesso a cada projeto mostra um acumulo
rente do projeto saber exatamente o que Concluso de conhecimento armazenado durante a
fazer quando um requisito alterado pelo Neste artigo, procurou-se mostrar como entrega de cada sistema, fazendo parte
cliente. Explica-se a seguir, o comporta- artefatos especficos, utilizados no de- de uma melhoria contnua.
mento dos artefatos quando um requisito
sofre alguma modificao. A planilha de
requisitos e o modelo de casos de uso so
os primeiros artefatos que o gerente ter
de verificar e se necessrio, fazer a alte-
rao imediata. na planilha que esto
todos os requisitos do sistema, bem como
seus respectivos cdigos indicadores. O
cdigo que indica o requisito alterado
precisa ser identificado pelo gerente, que
em seguida, deve abrir o Projeto Linear
e verificar quais as reas do site usam o
requisito modificado. Dessa maneira, ele
poder obter os cdigos de vrias reas
da aplicao. Utilizando os cdigos iden-
tificadores de cada rea do site, o gerente
deve pesquisar no Web Content, a fim
de saber quais pginas do site sofrero
alterao. Perceba que no objetivo do
gerente de projeto efetuar as alteraes,
mas identificar o impacto que as solicita-
es de alterao podem causar.
Caso o projeto sofra uma mudana no
contedo, essa identificao ser feita
facilmente. Em relao a uma mudana
de funcionalidade, esta dever impactar
tambm na alterao de outros artefatos,
como o digrama de classes, diagrama
de componentes, diagrama de seq-
ncia ou qualquer outro diagrama no
qual esteja sendo usado no projeto. A Figura 9. Overview da 5 iterao

Edio 01 Engenharia de Software Magazine 37

 Arquitetura de Software
Desenvolvimento orientado para arquitetura
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 dos
livros Arquitetura de Software e Programando
com XML, ambos pela Editora Campus/Else-
vier, tem mais de 30 artigos publicados em
eventos nacionais e internacionais, colunista
para Cincia e Tecnologia pela Revista Espao
Acadmico com mais de 60 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 Uni-
versidade 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.
38 Engenharia de Software Magazine Arquitetura de Software
S
oftware, de modo genrico, uma
entidade que se encontra em quase
constante estado de mudana. As
mudanas ocorrem por necessidade de
corrigir erros existentes no software
ou de adicionar novos recursos e fun-
cionalidades. Igualmente, os sistemas
computacionais (isto , aqueles que tm
software como um de seus elementos)
tambm sofrem mudanas frequente-
mente. Essa necessidade evolutiva do
sistema de software o torna no confi-
vel e predisposto a defeitos, atraso na
entrega e com custos acima do estimado.
Concomitante com esses fatos, o cres-
cimento em tamanho e complexidade
dos sistemas de software exige que os
profissionais da rea raciocinem, proje-
tem, codifiquem e se comuniquem por
meio de componentes de software. Como
resultado, qualquer concepo ou solu-
o de sistema passa ento para o nvel
arquitetural, onde o foco recai sobre os
componentes e relacionamentos entre
eles num sistema de software.
Arquitetura de software
Quase cinco dcadas atrs software
constitua uma insignificante parte
dos sistemas existentes e seu custo de
desenvolvimento e manuteno eram
desprezveis. Para perceber isso, basta
olharmos para a histria da indstria do
software (ver seo Links). Encontramos
o uso do software numa ampla variedade
de aplicaes tais como sistemas de ma-
nufatura, software cientfico, software
embarcado, robtica e aplicaes Web,
dentre tantas. Paralelamente, observou-
se o surgimento de vrias tcnicas de
modelagem e projeto bem como de lin-
guagens de programao. Perceba que o
cenrio existente, dcadas atrs, mudou
completamente.
Antigamente, os projetos de sistemas
alocavam pequena parcela ao software.
Os componentes de hardware, por outro
lado, eram analisados e testados quase
exaustivamente, o que permitia a pro-
duo rpida de grandes quantidades de
subsistemas e implicava em raros erros de

projetos. Entretanto, a facilidade de mo-
dificar o software, comparativamente ao
hardware, tem servido como motivador
para seu uso. Alm disso, a intensificao
do uso do software numa larga variedade
de aplicaes o fez crescer em tamanho
e complexidade. Isto tornou proibitivo
analis-lo e test-lo exaustivamente, alm
de impactar no custo de manuteno.
Um reflexo dessa situao que as tc-
nicas de abstrao utilizadas at o final
da dcada de 1980 (como decomposio
modular, linguagens de programao de
alto nvel e tipos de dados abstratos) j
no so mais suficientes para lidar com
essa necessidade.
Diferentemente do uso de tcnicas que
empregam algoritmos e estruturas de
dados e das linguagens de programao
que implementam tais estruturas, o cres-
cimento dos sistemas de software deman-
da notaes para conectar componentes
(mdulos) e descrever mecanismos de
interao, alm de tcnicas para geren-
ciar configuraes e controlar verses.
A Tabela 1 apresenta o contexto da ar-
quitetura de software. Na programao
estruturada, feito uso de estruturas de
seqncia, decises e repeties como
padres de controle nos programas. J
a ocultao de informaes um recurso software
do paradigma orientado a objetos que
permite ao programador, por exemplo,
ocultar dados tornando-os seguros de
qualquer alterao acidental. Alm disso,
na programao orientada a objetos, da-
dos e funes podem ser encapsulados
numa entidade denominada objeto, o que
resulta em mais simplicidade e facilidade
na manuteno de programas. Por outro
lado, os estilos arquiteturais capturam o
padro de organizao dos componen-
tes de software num programa, caracte-
rizando a forma na qual os componentes
comunicam-se entre si.
Perceba que a categorizao, apresenta-
da na Tabela 1, teve o objetivo de capturar
uma viso geral de abordagens aplicadas
a sistemas de software. Nada impede, por
exemplo, o uso da programao estru-
turada em sistemas de grande porte ou
da nfase de um estilo arquitetural num
sistema de pequeno porte. Entretanto,
essa prtica no comum.
Note que medida que tamanho e com-
plexidade dos sistemas de software au-
mentam, o problema de projeto extrapola
as estruturas de dados e algoritmos de
computao. Ou seja, projetar a arquite-
tura (ou estrutura geral) do sistema emer-
ge como um problema novo. Questes
arquiteturais englobam organizao e
estrutura geral de controle, protocolos de
comunicao, sincronizao, alocao de
funcionalidade a componentes e seleo
de alternativas de projeto. Por exemplo,
nos sistemas Web, uma soluo que tem
sido empregada faz uso de mltiplas
camadas separando componentes clien-
te, servidores de aplicaes, servidores
Web e outras aplicaes (que possam ter
acesso a esse sistema). Essa estruturao
em camadas objetiva facilitar a alocao
da funcionalidade aos componentes. O
uso de camadas oferece suporte flexi-
bilidade e portabilidade, o que resulta em
facilidade de manuteno. Outro aspecto
a destacar da arquitetura em camadas
o uso de interfaces padres visando faci-
litar reuso e manuteno. Interfaces bem
definidas encapsulam componentes (com
funcionalidades definidas) j testados,
prtica que permite o reuso e tambm
auxilia na manuteno, j que toda e
qualquer alterao necessria estaria
confinada quele componente.
Importncia da Arquitetura de
Todos esses fatores compreendem o
projeto no nvel arquitetural e esto
diretamente relacionados com a orga-
nizao do sistema e, portanto, afetam
os atributos de qualidade (tambm
chamados de requisitos no funcionais)
como desempenho, portabilidade, con-
fiabilidade, disponibilidade, entre ou-
tros. Se fizermos uma comparao entre
Abordagem
Programao estruturada
Abstrao e modularizao
Componentes e conectores
Tabela 1. Contexto da arquitetura de software.
Categorias arquiteturais
Modelos, desenhos, planos, elevaes e
Arquitetura Clssica
Arquitetura de Software Modelos para diferentes papis, mltiplas vises
Tabela 2. Comparao de aspectos arquiteturais.
Edio 01 Engenharia de Software Magazine
proj eto
arquitetura de software (caracterizada,
por exemplo, pelo estilo em camadas) e
arquitetura clssica (relativa constru-
o de edificaes), podemos observar
que o projeto arquitetural determinante
para o sucesso do sistema.
A Tabela 2 destaca aspectos da re-
presentao de projeto que captura
elementos caractersticos da arquite-
tura enquanto que as restries esto
associadas a atributos de qualidade e,
portanto, servem como determinantes
nas decises do projeto arquitetural.
Por exemplo, embora o uso de mltiplas
camadas facilite a manuteno de um
sistema de software, tambm contribui
para degradar o desempenho do sistema.
Uma ttica tem sido reduzir o nvel de
acoplamento entre componentes para no
comprometer o desempenho do sistema.
Dessa forma, se adotarmos uma reduo
no nvel de acoplamento dos compo-
nentes, eles tero menor necessidade de
comunicao entre si, o que resulta num
melhor desempenho.
Hoje em dia, os processos de engenharia
de software requerem o projeto arquite-
tural de software. Por qu?
importante poder reconhecer as
estruturas comuns existentes de modo
que arquitetos de software (ou enge-
nheiros de software realizando o papel
de arquiteto de software conforme
Tabela 3) possam entender as relaes
existentes nos sistemas em uso e utilizar
esse conhecimento no desenvolvimento
de novos sistemas.
O entendimento das arquiteturas per-
mite aos engenheiros tomarem decises
sobre alternativas de projeto.
Foco Padres
Sistemas de pequeno porte Estruturas de controle
Encapsulamento e ocultao de
Sistemas de mdio porte
informaes
Sistemas de grande porte Estilos arquiteturais
Representaes de projeto Restries
Padro de circulao, acstica, iluminao e
perspectivas ventilao
Desempenho, confiabilidade, escalonamento e
manutenibilidade
39
 Uma especificao arquitetural
essencial para analisar e descrever
propriedades de um sistema complexo,
permitindo o engenheiro ter uma viso
geral completa do sistema.
O conhecimento de notaes para des-
crever arquiteturas permite engenheiros
comunicarem novos projetos e decises
arquiteturais tomadas a outros membros
da equipe.
Cabe destacar que, para que haja o en-
tendimento da arquitetura, faz-se neces-
srio ao engenheiro de software conhecer
os estilos arquiteturais existentes, confor-
me apresentado adiante. As propriedades
de cada arquitetura, portanto, so depen-
dentes do estilo arquitetural adotado. Por
exemplo, o uso de uma notao padro
como a UML ajuda na representao de
componentes e compartilhamento de
informaes do projeto.
Esses aspectos servem como indica-
dores de uma maturidade inicial de
engenharia de software. Outros aspectos
compreendem uso e reuso de solues
existentes no desenvolvimento de novos
sistemas. Para tanto, a prototipagem tem
sido usada em projetos de natureza ino-
vadora (bem antes da implementao ou
aceitao de um produto acontecer).
Alm disso, o aumento da complexi-
dade e quantidade de requisitos dos
sistemas dificulta cada vez mais atender
s restries de oramento e cronograma.
Atualmente, empresas tm procurado in-
corporar estratgia de reuso de software,
enfatizando o reuso centrado na arquite-
tura para obter melhores resultados no
desenvolvimento de sistemas. Note que
a arquitetura de software serve como
uma estrutura atravs da qual se tem o
entendimento dos componentes de um
sistema e de seus inter-relacionamentos.
Em outras palavras, ela define a estrutura
do sistema, de modo consistente para
Habilidades desejadas
Conhecimento do domnio e tecnologias relevantes
Conhecimento de questes tcnicas para desenvolvimento de sistemas
Conhecimento de tcnicas de levantamento de requisitos, e de mtodos de modelagem e
desenvolvimento de sistemas
Conhecimento das estratgias de negcios da empresa
Conhecimento de processos, estratgias e produtos de empresas concorrentes
Tabela 3. Habilidades e tarefas de um arquiteto de software.
40 Engenharia de Software Magazine Arquitetura de Software
implementaes, j que est diretamente
relacionada aos atributos de qualidade
como confiabilidade e desempenho. A
organizao dos componentes num sis-
tema de software impacta sobre a quali-
dade apresentada por ele. Por exemplo, a
adoo de uma arquitetura em camadas
serve para modularizar o sistema bem
como facilitar modificaes. Entretanto,
um nmero elevado de camadas (4 ou 5)
pode degradar o desempenho do sistema
se houver um elevado grau de acopla-
mento entre os componentes.
Diversos benefcios decorrem da in-
corporao da arquitetura de software
como elemento norteador do processo
de desenvolvimento de software. Cabe
destacar que a arquitetura pode:
Prover suporte ao reuso seus com-
ponentes definidos e testados podem ser
reaproveitados em novas aplicaes.
Servir de base estimao de custos
e gerncia do projeto a existncia de
uma arquitetura bem definida permite ao
gerente de projeto adequadamente alocar
tarefas de, por exemplo, implementao
de componentes e melhor estimar o tem-
po e tamanho de equipe necessria para
realizao de um projeto.
Servir de base para anlise da con-
sistncia e dependncia o arquiteto de
software pode verificar se a arquitetura
de software adotada suporta os atributos
de qualidade desejados de modo consis-
tente e avaliar o nvel de dependncia
dos atributos de qualidade em relao
arquitetura. Para tanto, ele faz a anlise
arquitetural que verifica o suporte ofere-
cido pela arquitetura a um conjunto de
atributos de qualidade (como desempe-
nho, portabilidade e confiabilidade).
Ser utilizada para determinar atribu-
tos de qualidade do sistema o arquiteto
de software faz a anlise arquitetural a
fim de determinar os atributos de quali-
dade. Trata-se de um processo iterativo.
Tarefas atribudas
Modelagem
Anlise de compromisso e de viabilidade
Prototipagem, simulao e experimentao
Anlise de tendncias tecnolgicas
Evangelizador de novos arquitetos
At uar como uma estrut ura para
atender os requisitos do sistema a ar-
quitetura ajuda a definir os requisitos
funcionais, que compreendem o con-
junto de funcionalidades do sistema de
software, e requisitos no funcionais (ou
atributos de qualidade) que determinam
as caractersticas visveis ao usurio
como desempenho e confiabilidade.
Uma questo que voc deve estar se
fazendo : Por que apenas recentemente
houve o foco na arquitetura de software?
A resposta simples: economia e reuso.
Anteriormente no havia forte nfase
na disciplina de engenharia de software,
fato este ocorreu com o amadurecimento
desta nova rea ao longo de toda a dca-
da de 1990. Tudo motivou o surgimento
de um novo profissional: o arquiteto de
software.
Habilidades do Arquiteto de
software
Perceba que o arquiteto de software
tem um papel de suma importncia
para estratgia adotada pela empresa.
Ele precisa ter profundo conhecimento
do domnio, das tecnologias existentes
e de processos de desenvolvimento de
software. Uma sntese de um conjunto
desejado de habilidades para um arqui-
teto de software e das tarefas atribudas
a ele so apresentados na Tabela 3. Note
que a prototipagem uma tarefa comum
onde o arquiteto desenvolve um protti-
po para testar uma possvel soluo. J
a simulao pode ser empregada quando
ele necessita avaliar o suporte oferecido
a determinado atributo de qualidade
como o desempenho. Por outro lado, a
experimentao pode ocorrer quando o
arquiteto precisa testar um novo compo-
nente recm implementado.
Entendo o Estilo Arquitetural
O estilo arquitetural serve para carac-
terizar a arquitetura de software de um
sistema, possibilitando a:
Identificao de componentes o
arquiteto identifica quais os principais
elementos que tem funcionalidades bem
definidas como, um componente de ca-
dastro de (informaes de) usurios e um
componente de autenticao de usurio
numa aplicao Web.
Identificao de mecanismos de inte-
rao a comunicao entre objetos por

meio da troca de mensagens constitui
uma forma atravs da qual os componen-
tes de software interagem entre si.
Identificao de propriedades o
arquiteto pode analisar as propriedades
oferecidas por cada estilo baseado na or-
ganizao dos componentes e nos meca-
nismos de interao, conforme discutido
abaixo.
O estilo arquitetural considera o sistema
por completo, permitindo o engenheiro
ou arquiteto de software determinar
como o sistema est organizado, ca-
racterizando os componentes e suas
interaes. Em outras palavras, ele
determina uma estrutura para todos
os componentes do sistema. O estilo
arquitetural compreende o vocabulrio
de componentes e conectores, alm da
topologia empregada. Mas, voc pode
estar se questionando: Por que saber o
estilo arquitetural importante?
Os sistemas de grande porte exigem
nveis de abstrao mais elevados (justa-
mente onde se tm os estilos) que servem
de apoio compreenso do projeto e
comunicao entre os participantes do
projeto. Ele determinante no entendi-
mento da organizao de um sistema de
software.
Mas, o que se ganha em saber o estilo
arquitetural? Ele oferece:
Suporte a atributos de qualidade (ou
requisitos no funcionais);
Diferenciao entre arquiteturas;
Menos esforo para entender um projeto;
Reuso de arquitetura e conhecimento
em novos projetos.
Conhecer o estilo arquitetural permite
ao engenheiro antecipar, por meio da
anlise (arquitetural), o impacto que o es-
Figura 1. Exemplo do estilo arquitetural de tubos e filtros
tilo (isto a classe de organizao do sis-
tema) ter sobre atributos de qualidade.
Adicionalmente, facilita a comunicao
do projeto, alm do reuso da arquitetura
(da soluo).
A caracterizao e existncia de estilos
arquiteturais constituem sinais de ama-
durecimento da engenharia de software,
uma vez que permite ao engenheiro or-
ganizar e expressar o conhecimento de
um projeto de modo sistemtico e til.
Note que uma forma de codificar conhe-
cimento dispor de um vocabulrio de
um conjunto de conceitos (terminologia,
propriedades, restries), estruturas
(componentes e conectores) e padres
de uso existentes. Conectores so empre-
gados na interao entre componentes
como, tubo (pipe) no estilo tubos e filtros,
e mensagens no estilo de objetos.
Exemplificando o estilo pipes
(tubos) e filtros
O estilo arquitetural de tubos e filtros
considera a existncia de uma rede
atravs da qual dados fluem de uma
extremidade outra. O fluxo de dados
se d atravs tubos e os dados sofrem
transformaes quando so processados
nos filtros.
O tubo prov uma forma unidirecional do
fluxo de dados uma vez que ele atua como
uma espcie de condutor para o fluxo de
dados entre a fonte at um destino. O exem-
plo mais comumente conhecido do estilo
tubos e filtros aquele usado no sistema
operacional Unix, isto : who | sort
A linha de comando acima executa o co-
mando who (uma nica vez) e encaminha
sua sada ao programa sort, conforme
ilustrado na Figura 1. O resultado da
execuo do programa who uma lista
Edio 01 Engenharia de Software Magazine
proj eto
de todos os usurios que se encontram
conectados (a um servidor especfico)
naquele momento, enquanto que o pro-
grama sort ordena essa lista de usurios
em ordem alfabtica (de login).
Outro exemplo compreende a arqui-
tetura bsica de um compilador como
ilustrado na Figura 2. Observe que cada
etapa do processo de compilao reali-
zada separadamente por um componente
(ou seja, um filtro).
Um compilador tem duas funes bsi-
cas: anlise e sntese. A funo de anlise
implementada por trs componentes:
analisadores lxico, sinttico e semn-
tico. J a funo de sntese compreende
os componentes de otimizao e gerao
de cdigo. Observe que essa arquitetura
oferece suporte portabilidade e reuso.
Entretanto, essa arquitetura evoluiu
com a introduo de um componente ge-
rador intermedirio de cdigo, conforme
ilustrado na Figura 3, a fim de tornar a
arquitetura do compilador mais port-
vel a vrias plataformas com o objetivo
de reduzir custos no desenvolvimento de
diferentes produtos, ou seja, compilado-
res para diferentes plataformas.
Uma nova evoluo da arquitetura de
compiladores a fim de atender a necessi-
dade de integrao (do compilador) com
outras ferramentas, tais como editor e
depurador, resultou na arquitetura mos-
trada na Figura 4.
importante salientar que a evoluo
da arquitetura de compilador foi resul-
tado, principalmente, da necessidade de
dar suporte ao requisito de portabilidade.
Nesse sentido, pode-se destacar como
vantagens:
Problema ou sistema pode ser decom-
posto de forma hierrquica;
41
Figura 2. Arquitetura bsica de um compilador (seguindo estilo arquitetural de tubos e filtros)

Figura 3. Evoluo inicial da arquitetura de um compilador.

Figura 4. Nova evoluo da arquitetura de um compilador.

42 Engenharia de Software Magazine Arquitetura de Software

 proj eto

Funo do sistema vista como com- por meio da passagem de mensagens, a interface define os eventos de entrada
posio de filtros; invocao implcita requer que compo- e sada permitidos. Conectores so
Facilidade de reuso, manuteno nentes interessados em receber ou divul- implementados atravs do binding
e extenso, que emprega abordagem gar eventos se registrem para receber ou evento-procedimento. Assim, eventos
caixa preta, onde cada componente tem enviar. Um exemplo de sistema empre- so registrados junto com eventos e os
funcionalidade e interface bem definida, gando mensagens so listas de notcias componentes interagem entre si atra-
facilitando alteraes nos mesmos; e frum que possuem componentes de vs do envio de eventos. Dessa forma,
Desempenho pode ser incrementado registro de novos usurios acoplados quando um evento recebido, o(s)
atravs do processamento paralelo de ao componente de autenticao. Perceba procedimento(s) associado(s) a este even-
filtros, j que a ativao e uso do com- que esse tipo de sistema apenas permite to (so) invocado(s). Um interessante
ponente ocorre com o fluxo de dados, que o usurio tenha acesso ao contedo exemplo deste estilo so jogos online,
permit i ndo que componentes com se este for devidamente autenticado e como discutido na seo seguinte.
funcionalidades independentes sejam registrado. Quadro negro (ou Blackboard) esse
executados de forma concorrente. (Sistemas orientados a) Eventos trata- estilo faz uso de um repositrio central
se de um estilo no qual os componentes de dados circundado por um conjunto de
Apesar das vantagens acima apontadas, podem ser objetos ou processos e a componentes (ou clulas) de informaes.
o estilo de tubos e filtros coloca nfase no
modo batch, tornando difcil seu uso em
aplicaes interativas e em situaes que
exija ordenao de filtros. Outra questo
tcnica a ser observada a possibilidade
de haver deadlock com o uso de buffers
finitos (para armazenamento temporrio
de dados). Esse estilo arquitetural tem
sido empregado em razo das vantagens
anteriormente destacadas.
Exemplos de outros estilos arquiteturais
compreendem:
Camadas a arquitetura do sistema de
software organizada num conjunto de
camadas, oferecendo maior flexibilidade
e suporte a portabilidade. A identificao
do nvel de abstrao nem sempre evi-
dente e perde-se desempenho medida
que o nmero de camadas cresce. Exem-
plo desse estilo compreende os sistemas Figura 5. Combinao de estilos.
Web de mltiplas camadas que separa
cliente, servidores de aplicao, servido-
res Web e outros clientes Web.
Objetos essa arquitetura combina
dados com funes numa nica entidade
(objeto), facilitando a decomposio do
problema, manuteno e reuso. comum
utilizar a arquitetura orientada a objetos
em sistemas de informao como siste-
mas de consulta e emprstimos online de
bibliotecas de instituies de ensino que
dispem de componentes de cadastro de
usurios e componentes de autenticao
de usurios. Note que componentes
similares existem em outros sistemas de
informaes, tais como sites de contedos
(jornais e revistas) que exigem cadastro
e autenticao de qualquer usurio antes
de disponibilizar o contedo.
Invocao implcita diferentemente do
estilo baseado em objetos, no qual um
componente invoca outro diretamente Figura 6. Jogo Connect4.

Edio 01 Engenharia de Software Magazine 43

Esses componentes contm informaes
necessrias soluo de problemas. Os
dados da soluo de problemas so man-
tidos na base de dados compartilhada
(o repositrio), o qual denominado de
quadro negro. O exemple mais comum
desse estilo um sistema especialista.
Combinao de estilos Outros
sistemas, na prtica, combinam estilos
arquiteturais resultando numa heteroge-
neidade, como ilustrado na Figura 5, que
agrega o estilo de objetos e camadas.
Exemplificando o estilo combinado
de objetos e eventos
Jogos online e de computador tm
se tornado comuns atualmente com a
popularidade da Internet. Costuma-se
categorizar os jogos em:
Baseados na vez so jogos nos quais
cada ao baseada na vez do jogador
como jogo da velha e xadrez.
Baseados em eventos so jogos onde
eventos podem ocorrer em qualquer
instante e estes ditam o ritmo do jogo.
Exemplos compreendem simuladores de
vo e corridas de carro.
Por exemplo, quando os jogos so dis-
ponibilizados na Internet, costuma-se
denomin-los de jogos online ou jogos
para Internet, possibilitando ao usurio
jogar contra a mquina (computador).
Figura 7. Arquitetura do Connect4
44 Engenharia de Software Magazine Arquitetura de Software
Um exemplo desse tipo de jogo de com-
putador o Connect4 que tem como
meta para cada jogador conectar quatro
peas da mesma cor, verticalmente, ho-
rizontalmente ou diagonalmente. Cada
jogador deve depositar uma pea na
parte superior da coluna selecionada e
esta cai at preencher a lacuna inferior da
coluna (selecionada), conforme ilustrado
na Figura 6. Note que o quadro contm 7
colunas e 6 linhas, um indicador de status
do jogo e um seletor manual (utilizado
para selecionar a coluna na qual uma
pea ser depositada).
A arquitetura de software dessa aplica-
o apresentada na Figura 7. O compo-
nente jogador computacional (que dispe
de recursos de inteligncia artificial para
simular um jogador humano) contm
uma classe Connect4State que trata a
maioria das requisies para verificar se
algum jogador venceu o jogo, e tambm
dispe de mecanismo para atualizar o es-
tado do jogo aps uma jogada do jogador
computacional.
O componente (mquina) de inferncia
contm uma classe para tratar as jogadas
feitas pelos jogadores bem como deter-
minar a melhor jogada para o jogador
computacional.
O componente de interface de usurio
contm uma classe que carrega os arqui-
vos de imagem e udio, trata as requisi-
es feitas atravs do mouse e invoca um
mtodo que checa se houve vitria, derro-
ta ou empate, alm de fazer a atualizao
da interface grfica. Um possvel estado
final desse jogo mostrado na Figura 8,
onde na terceira linha h um conjunto
de quatro peas na cor azul, indicando
que o computador completou primeiro a
conexo de quatro peas na mesma cor (a
cor do usurio humano vermelha).
A combinao estilo arquitetural orien-
tado para eventos e objetos permite a
decomposio de um sistema em termos
de objetos (componentes de inferncia,
componente de interface grfica e com-
ponente jogador computacional) que so
mais independentes alm de possibilitar
que atividades de computao e coor-
denao (de eventos) sejam realizadas
separadamente. H ainda a facilidade de
reuso e manuteno, j que novos objetos
podem ser facilmente adicionados. Essa
caracterstica, e interfaces bem definidas,
facilitam ainda a integrao.
O mecanismo de invocao no
determinstico (isto , ocorre de forma
aleatria) uma vez que considera a re-
cepo de eventos. Adicionalmente, os
componentes tm seus dados preserva-
dos de qualquer modificao acidental
j que essas informaes so encapsu-
ladas em objetos, facilitando tambm a
integrao.
 proj eto

Importncia do Reuso a arquitetura de software como premissa. Links

importante perceber de tudo o que foi
apresentado e discutido que um modelo
arquitetural oferece suporte ao reuso de
vrias formas. Por exemplo, pode se ter
arquiteturas reusveis que forneam a
organizao e o modelo de coordenao, de software) e o pilar principal dessas
permitindo seu uso em diversos siste-
mas. Alm disso, podem-se reutilizar
componentes, j testados, em mais de um
sistema. Disso tudo, o mais importante
Assim, o fator econmico tem sido e ser
o determinante da sobrevivncia da em-
presas de software. Novas estratgias de
desenvolvimento de sistemas devem ser
para o reuso e com reuso (de componentes
www.sei.cmu.edu/architecture/sat_init.html
estratgias a arquitetura de software.
H, portanto, uma necessidade premente
de formao de capital humano com tais
qualificaes.
Histria da Indstria de Software
www.softwarehistory.org
An introduction to software architecture
http://www.cs.cmu.edu/afs/cs/project/able/www/paper_abstracts/
intro_softarch.html
SEIs Software Architecture Technology Initiative
Worldwide Institute of Software Architects
www.wwisa.org/wwisamain/index.htm
The Software Architecture Portal
http://www.softwarearchitectureportal.org/

o reuso do conhecimento que tem im-

pacto direto na definio da arquitetura
de software candidata soluo de um
Caractersticas de arquitetura de software Uso prtico da arquitetura de software
problema (ou sistema).
A ampla variedade de plataformas e Como um arquiteto de software pode organizar o projeto e
Constitui um artefato reutilizvel
utilitrios, juntamente com a presso cdigo de um sistema
do mercado para reduzir o tempo de
Dispe de mecanismos de interconexo Como um arquiteto avalia e implanta arquiteturas de software em sistemas
entrega de produtos de software e elevar
a produtividade, faz com que o reuso Como um arquiteto de software atua no processo de
Oferece um vocabulrio de projeto e separa funcionalidades
seja apontado como uma das chaves de desenvolvimento de software
sucesso para empresas. Como um arquiteto avalia a qualidade do cdigo baseada
O reuso de artefatos (ou componentes) Vincula o projeto a atributos de qualidade
em mtricas de produto
possvel quando o projeto arquitetural
est incorporado e orienta o processo de Suporta o desenvolvimento baseado em componentes e
Como usar arquitetura como parmetro para reduzir custos de
desenvolvimento de software. Isto, como linha de produto (quando os requisitos so considerados
manuteno e amortizar custos de desenvolvimento
discutido, permite antever os atributos para uma famlia de sistemas)
de qualidade que o sistema suporta e
Tabela 4. Caractersticas e uso prtico da arquitetura de software
tambm administrar o cronograma de
execuo do projeto. Portanto, impac-
tando positivamente o reuso e economia
do sistema.
O quadro apresentado na Tabela 4
sumariza as principais caractersticas
da arquitetura de software e pontos im-
portantes na capacitao e reciclagem de
engenheiros e arquitetos de software.

Concluso
Embora arquitetura de software seja
um tema relevante no contexto atual para
desenvolvimento de sistemas de software
que tm seu foco no reuso e, portanto,
consideram tanto o aspecto econmico
quanto a produtividade, sua incorpora-
o nos processos de desenvolvimento de
software tem sido observada apenas em
empresas de grande porte e em poucas
de mdio porte. Entretanto, esse cenrio
comea a mudar dada a crescente necessi-
dade de integrao de sistemas a qual tem

Figura 8. Possvel estado final do jogo Connect4

Edio 01 Engenharia de Software Magazine 45

 Introduo Engenharia de Requisitos
Ana Luiza vila
analuizaavila@yahoo.com.br
bacharel em Cincias da Computao pela equipe e forma como trabalham, e, para
Universidade Salvador (UNIFACS) e Mestre
em Cincias da Computao pela PUC-Rio na
linha de Engenharia de Software.
Rodrigo Oliveira Spnola
rodrigo@sqlmagazine.com.br
Doutorando em Engenharia de Sistemas e
Computao (COPPE/UFRJ). Mestre em En-
genharia de Software (COPPE/UFRJ, 2004).
Bacharel em Cincias da Computao (UNI-
FACS, 2001). Colaborador da Kali Software
(www.kalisoftware.com), tendo ministrado
cursos na rea de Qualidade de Produtos e
Processos de Software, Requisitos e Desen-
volvimento Orientado a Objetos. Consultor
para implementao do MPS.BR. Atua como
Gerente de Projeto em projetos de consulto-
ria na COPPE/UFRJ. colaborador da Enge-
nharia de Software Magazine.
46 Engenharia de Software Magazine Introduo Engenharia de Requisitos
D
esenvolver software uma ati- desenvolvimento. Uma recente matria
vidade complexa por natureza. publicada na revista Exame relata o
Uma das razes para esta afir- crescimento do nmero de empresas que
mao que no existe uma nica soluo atingiram nveis de maturidade conside-
para cada cenrio de desenvolvimento. rando modelos como MPS.BR e CMMI.
Alm disso, lidamos o tempo todo com Este resultado um forte indicador de
pessoas, o que torna o sucesso do projeto que as empresas nacionais esto se pre-
bastante relacionado competncia da ocupando com a qualidade dos servios
que oferecem, conseguindo, dessa forma,
dificultar ainda mais, muitas vezes no uma insero maior no mercado interna-
cional de desenvolvimento de software.
fazemos uso de um processo bem defini-
do para apoiar as atividades do projeto. Neste artigo, faremos uma introduo
Entende-se por processo, neste contexto, Engenharia de Requisitos, atividade
como sendo um conjunto de atividades base para as demais tarefas associadas
bem definidas com os respectivos res- ao desenvolvimento de software.
ponsveis por execuo, ferramentas de
apoio e artefatos produzidos. Ou seja, Engenharia de Software e
define-se como a equipe dever trabalhar Requisitos
para alcanar o objetivo: desenvolver sof- Vimos na introduo que se busca cada
tware com qualidade dentro de prazos, vez mais o apoio dos fundamentos da en-
custos e requisitos definidos. genharia de software no desenvolvimen-
A boa notcia que muitas empresas to de sistemas. Entendemos engenharia
esto se movimentando no sentido de de software como sendo, de acordo com
definirem detalhadamente seus proces- o IEEE, a aplicao de uma abordagem
sos para apoiarem suas atividades de sistemtica, disciplinada e quantificvel
 requisi tos

no desenvolvimento, operao e ma-
nuteno de software. Sistemtica por
que parte do princpio de que existe um
processo de desenvolvimento definindo
as atividades que devero ser executadas.
Disciplinada por que parte do princpio
de que os processos definidos sero
seguidos. Quantificvel por que se deve
definir um conjunto de medidas a serem
extradas do processo durante o desen-
volvimento de forma que as tomadas de
deciso relacionadas ao desenvolvimento
do software (por exemplo, melhoria de
processo) sejam embasadas em dados
reais, e no em achismos. Alguns de
seus principais objetivos so:
Qualidade de software;
Produtividade no desenvolvimento,
operao e manuteno de software;
Permitir que profissionais tenham
controle sobre o desenvolvimento de
software dentro de custos, prazos e nveis
de qualidade desejados.
Entretanto, o cenrio de desenvolvimen-
to de software atual e o cenrio idealiza-
do junto engenharia de software ainda
esto distantes. Vrios fatores contribuem
para isso, podemos citar dois:
O no uso dos fundamentos da en-
genharia de software para apoiar as
atividades do desenvolvimento;
O mau uso dos fundamentos da
engenharia de software para apoiar as
atividades do desenvolvimento.
mite concluir que importante que seja
dada maior importncia s atividades
relacionadas especificao dos requi-
sitos do software.
Reforando a importncia que as ativi-
dades relacionadas a requisitos devem
possuir na indstria de software, estudo
realizado pelo Standish Group, conside-
rando 350 companhias e 8.000 projetos
de software, em 1995 revelou que (ver
Figura 1):
16,2% dos projetos so finalizados com
sucesso, ou seja, cobre todas as funcio-
nalidades em tempo e dentro do custo
previsto;
52.7% dos projetos so considerados
problemticos, ou seja, no cobre todas
as funcionalidades exigidas, custo au-
mentado e est atrasado.
31,1% dos projetos fracassam, ou seja,
o projeto cancelado durante o desenvol-
vimento.
O Standish Group ainda fez uma an-
lise sobre os fatores crticos para sucesso
dos projetos de software. O resultado
dos dez mais lembrados pode ser visto
na Tabela 2. Podemos perceber que trs
dos principais fatores esto relacionados
s atividades de requisitos: (1) Requisitos
Incompletos; (2) Falta de Envolvimento
do Usurio; (6) Mudana de Requisitos e
Especificaes.
Neste ponto, sabemos que um trabalho
mais criterioso na rea de requisitos
fundamental para o sucesso de projetos
de software. A partir da prxima seo
conheceremos a definio de requisitos e
algumas de suas definies relacionadas
antes de discutirmos mais profundamen-
te a engenharia de requisitos.
Fatores Crticos %
1. Requisitos Incompletos 13.1%
2. Falta de Envolvimento do Usurio 12.4%
3. Falta de Recursos 10,6%
4. Expectativas Irreais 9,9%
5. Falta de Apoio Executivo 9,3%
6. Mudana de Requisitos e Especificaes 8,7%
7. Falta de Planejamento 8,1%
8. Sistema no mais necessrio 7,5%
Tabela 2. Fatores crticos do sucesso.

Isso tem diversas conseqncias. Gosta-

ramos de destacar neste artigo o crescen-
te custo com manuteno dos sistemas.
Consideramos como manuteno neste
Tabela 1. Cenrio atual de desenvolvimento.
artigo como sendo qualquer retrabalho
(em nvel de requisitos, projeto, codifica-
o, teste) causado por uma definio do
domnio do problema mal elaborada nas
fases iniciais do desenvolvimento.
Neste ponto, importante analisamos
os dados da Tabela 1. Perceba que o cus-
to das atividades relacionadas anlise
de requisitos baixo. Por outro lado,
nesta fase que grande parte dos defeitos
so inseridos. Podemos perceber ainda
analisando a primeira linha que o custo
de correo destes problemas nesta fase
baixo. Continuando a anlise, percebe-
mos que estes defeitos no so tratados no
momento devido, o que pode aumentar
bastante o custo com o projeto.
Embora simples, esta anlise nos per- Figura 1. Distribuio da concluso dos projetos de software.

Edio 01 Engenharia de Software Magazine 47

Requisitos
Existem diferentes definies encontra-
das na literatura tcnica para requisitos:
Um requisito uma caracterstica
do sistema ou a descrio de algo que o
sistema capaz de realizar para atingir
os seus objetivos;
As descries das funes e restries
so os requisitos do sistema;
Um requisito uma propriedade que o
software deve exibir para resolver algum
problema no mundo real;
Uma condio ou uma capacidade que
deve ser alcanada ou estar presente em
um sistema para satisfazer um contrato,
padro, especificao ou outro documen-
to formalmente imposto...
Percebe-se que as citaes encontradas
definem o mesmo conceito sob dife-
rentes perspectivas. Podemos entender
requisitos como sendo o conjunto de
necessidades explicitadas pelo cliente que
devero ser atendidas para solucionar
um determinado problema do negcio
Figura 2. Engenharia de Requisitos.
Figura 3. Produo e Gerncia de Requisitos.
48 Engenharia de Software Magazine Introduo Engenharia de Requisitos
no qual o cliente faz parte. importante
estar atento para esta definio: embora
o requisito seja definido pelo cliente,
nem sempre o que o cliente quer o
que o negcio precisa. Cabe equipe de
consultores identificar a real necessidade
do negcio.
Neste contexto, requisitos so impor- das compras atravs de carto de crdito.
tantes para:
Estabelecer uma base de concordncia
entre o cliente e o fornecedor sobre o que
o software far;
Fornecer uma referncia para a vali-
dao do produto final;
Reduzir o custo de desenvolvimento
(como vimos anteriormente, requisitos
mal definidos causam retrabalho).
Entendida a definio de requisitos,
preciso conhecer seus tipos.
Requisitos funcionais
So requisitos diretamente ligados a
funcionalidade do software, descrevem
as funes que o software deve executar.
Alguns exemplos so:
O software deve permitir o cadastro
de clientes;
O software deve permitir a gerao de
relatrios sobre o desempenho de vendas
no semestre;
O software deve permitir o pagamento
Requisitos no funcionais
So requisitos que expressam condi-
es que o software deve atender ou
qualidades especficas que o software
deve ter. Em vez de informar o que o
sistema far, os requisitos no-funcionais
colocam restries no sistema. Alguns
exemplos so:
O software deve ser compatvel com
os browsers IE (verso 5.0 ou superior) e
Firefox (1.0 ou superior);
O software deve garantir que o tempo
de retorno das consultas no seja maior
do que 5 segundos.
Requisitos de domnio
So requisitos derivados do domnio
da aplicao e descrevem caractersticas
do sistema e qualidades que refletem o
domnio. Podem ser requisitos funcionais
novos, restries sobre requisitos exis-
tentes ou computaes especficas. Dois
exemplos de requisitos do domnio so:
O calculo da mdia final de cada aluno
dado pela frmula: (Nota1 * 2 + Nota2 *
3)/5;
Um aluno pode se matricular em
uma disciplina desde que ele tenha sido
aprovado nas disciplinas consideradas
pr-requisitos.
A partir da prxima seo apresentare-
mos os conceitos envolvidos na engenha-
ria de requisitos.
Engenharia de Requisitos
Existem diferentes definies encontra-
das na literatura tcnica para engenharia
de requisitos:
Termo usado para descrever as ati-
vidades relacionadas investigao e
definio de escopo de um sistema de
software;
Processo sistemtico de desenvol-
vimento de requisitos atravs de um
processo cooperativo de anlise onde os
resultados das observaes so codifi-
cados em uma variedade de formatos e
a acurcia das observaes constante-

mente verificada;
Processo de descobrir, analisar, docu-
mentar e verificar as funes e restries
do sistema.
Embora coerentes, estas definies
podem ser melhoradas. Perceba que elas
referem-se apenas s atividades relacio-
nadas produo de requisitos. Entre-
tanto, nada dito a respeito da gerncia
destas atividades, tambm conhecida
como gerncia de requisitos. Com isto
em mente, podemos evoluir a definio
de engenharia de requisitos para: termo
usado para descrever as atividades rela-
cionadas produo (levantamento, re-
gistro, validao e verificao) e gerncia
(controle de mudanas, gerncia de con-
figurao, rastreabilidade, gerncia de
qualidade dos requisitos) de requisitos. A
Figura 2 representa essa definio.
Desta forma, os dois conceitos base (pro-
duo e gerncia) devem ser considerados
em conjunto ao se definir estratgias de
trabalho com requisitos nas organizaes
(ver Figura 3).
Neste ponto podemos citar alguns dos
principais objetivos da engenharia de
requisitos:
estabelecer uma viso comum entre o
cliente e a equipe de projeto em relao
aos requisitos que sero atendidos pelo
projeto de software;
registrar e acompanhar requisitos ao
longo de todo o processo de desenvolvi-
mento;
documentar e controlar os requisitos
alocados para estabelecer uma baseline
para uso gerencial e da engenharia de
software;
manter planos, artefatos e atividades
de software consistentes com os requisi-
tos alocados.
Para apoiar o alcance destes objetivos,
importante que se tenha um processo
de engenharia de requisitos bem defi-
nido. Um processo de engenharia de
requisitos um conjunto estruturado de
atividades a serem seguidas para criar,
validar e manter um documento de re-
quisitos. Poucas organizaes tm um
processo de ER explicitamente definido
e padronizado. Entretanto, sugere-se que
cada organizao deva desenvolver um
processo adequado sua realidade. A Fi-
gura 4 apresenta um modelo genrico de
atividades que pode descrever a maioria
dos processos de engenharia de requisi-
tos. Perceba que ele est concentrado nas
atividades de produo dos requisitos.
Apesar do aparente fluxo entre as ativi-
dades, no existe uma fronteira explcita
elas. Na prtica existe muita sobreposio
e interao entre uma atividade e outra.
Como entradas para o processo so
consideradas:
Descries do que os stakeholders ne-
cessitam para suportar suas atividades;
Informaes a respeito do sistema que
ser substitudo ou de qualquer sistema
com o qual o sistema sendo definido ter
que interagir;
Padres vigentes na organizao a Figura 4. Processo de Engenharia de Requisitos.
respeito de prticas de desenvolvimento
de sistemas, gerncia de qualidade, etc.;
Regulamentos externos, tais como leis,
regulamentos de segurana ou sade;
Informaes gerais sobre o domnio garantia da qualidade. Conheceremos
de aplicao.
Em paralelo execuo das atividades
definidas no processo da Figura 5, est o
processo de gerncia dos requisitos, vol-
tado ao endereamento de modificaes
nos requisitos. Os aspectos relacionados
s atividades de gerncia podem ser vis-
tos na Figura 3.
A partir de agora conheceremos cada
um dos conceitos que, em conjunto, de-
finem a engenharia de requisitos.
Produo de Requisitos
A cada fase do ciclo de vida do software
produzimos um documento contendo
uma representao distinta do softwa-
re a ser construdo. Cada um desses
documentos representa o software em
um determinado nvel de abstrao.
A tendncia diminuirmos o nvel de
abstrao atravs da incluso de mais e
mais detalhes, at que, sua ltima repre-
sentao seja o cdigo fonte na linguagem
escolhida.
Um dos artefatos produzidos no incio
do processo de desenvolvimento de sof-
tware a sua especificao de requisitos.
Ele base para as demais atividades
de desenvolvimento e sua qualidade
fundamental para o sucesso do projeto.
Uma especificao de requisitos bem ela-
borada pr-requisito para um software
de qualidade, embora no seja garantia
disso. Desta forma, durante a produo
de requisitos devemos possuir, alm das
atividades essenciais de levantamento e
Edio 01 Engenharia de Software Magazine
requisi tos
especificao, atividades relacionadas
nesta seo as quatro atividades base
relacionadas com a produo de requi-
sitos.
Levantamento
Esta atividade relaciona-se obteno
dos requisitos do software. Para isto,
analistas e engenheiros de software
trabalham com clientes e usurios finais
para descobrir o problema a ser resolvido,
os servios do sistema, o desempenho ne-
cessrio, restries de hardware e outras
informaes.
Existem algumas tcnicas que apiam
as atividades de levantamento de requi-
sitos. Uma breve descrio de algumas
delas :
Entrevista: esta tcnica resume-se
em conversas realizadas com o usurio
(entrevistado) para levantar os requisitos
do sistema a ser desenvolvido. Podemos
decompor esta tcnica nas seguintes
atividades:
o Ler material de suporte;
o Estabelecer os objetivos da entre-
vista;
o Decidir quem entrevistar;
o Preparar o entrevistado;
o Decidir os tipos de questes e a sua
estrutura.
Uma entrevista pode ser estruturada de
trs diferentes formas:
o Estrutura em pirmide: iniciamos
as entrevistas com perguntas mais
especificas sobre o sistema e fecha-
49
 mos com perguntas mais genricas.
Geralmente utilizadas com usurios
mais relutantes;
o Estrutura em funil: iniciamos as en-
trevistas com perguntas mais genricas
sobre o sistema e fechamos com per-
guntas mais especificas. Geralmente
utilizadas com usurios que tem uma
relao mais afetiva com o assunto;
o Estrutura em diamante: esta es-
trutura combina as duas estruturas
anteriores e utilizadas para manter
a usurio entrevistado interessado no
assunto e para isto se utiliza de per-
guntas variadas.
Prototipao: uma verso inicial de
um sistema para experimentao. Permi-
te aos utilizadores identificar os pontos
fortes e fracos do sistema por ser algo
concreto que pode ser criticado. Temos
dois tipos de prottipos:
o Prottipos Throw-away: ajudam
o levantamento e desenvolvimento dos
requisitos e suportam os requisitos
mais difceis de perceber;
o Prottipos Evolutivos: ajudam o
desenvolvimento rpido de uma verso
inicial do sistema e suportam os requi-
sitos bem definidos e conhecidos.
Algumas das desvantagens da prototi-
pao so os custos de aprendizagem e
os custos de desenvolvimento.
JAD (Joint Application Development):
uma tcnica que permite a interao
entre pessoas que necessitam tomar
decises que afetem mltiplas reas
de uma organizao. Esta tcnica en-
Figura 5. Fases da tecnica para levantamento de requisitos JAD.
50 Engenharia de Software Magazine Introduo Engenharia de Requisitos
volve atividades de preparao para as
reunies, sesses de workshop com os
participantes, agenda para as reunies,
participantes assumindo papeis de faci-
litador / condutor e documentador alm
de facilidades visuais, como a utilizao
de flipchart, quadro negro.
Esta tcnica deve ser utilizada nos casos
onde existe a necessidade de consenso
entre diversos usurios, pois possibilita
a todos os envolvidos ter uma viso glo-
bal do sistema, ajudando a consolidar
interesses de diversos usurios quanto
ao sistema a ser desenvolvido.
O objetivo desta tcnica aumentar
o comprometimento e participao do
usurio e obter subsdios para elaborar o
documento de Especificao de Requisi-
tos para o sistema com consenso de todos
de forma a ser uma validao formal dos
requisitos do sistema.
O JAD divido quem quatro fases. A Fi-
gura 5 apresenta estas fases e os artefatos
produzidos por cada uma delas.
A atividade de levantamento de requi-
sitos no trivial. Existe um conjunto
grande e variado de fatores que a tornam
complexa, por exemplo:
Falta de conhecimento do usurio das
suas reais necessidades
o Usurio com vaga noo do que
precisa e do que um produto de sof-
tware pode oferecer.
Falta de conhecimento do desenvolve-
dor do domnio do problema
o Desenvolvedor sem conhecimento
adequado do domnio, o que leva a
decises erradas.
Domnio do processo de levantamento
de requisitos pelos desenvolvedores
o Desenvolvedor no ouve o que os
usurios tm a dizer e fora suas pr-
prias vises e interpretaes.
Comunicao inadequada entre os
desenvolvedores e usurios
o Usurios incapazes de expressar
suas necessidades apropriadamente;
o Significados diferentes a termos
comuns.
Dificuldade do usurio tomar deci-
ses
o Falta de entendimento sobre as
conseqncias das decises ou as al-
ternativas possveis.
Problemas de comportamento
o O levantamento de requisitos um
processo social;
o Conflitos e ambigidades nos pa-
pis que os usurios e desenvolvedores
desempenham.
Questes tcnicas
o Complexidade crescente dos sis-
temas atuais.
Registro
Uma vez identificados e negociados, os
requisitos devem ser documentados para
que possam servir de base para o restante
do processo de desenvolvimento.
Entre os muitos problemas que enfren-
tamos na documentao de requisitos,
certamente, administrar o grande volume
de informaes gerado pelo processo de
requisitos um dos principais.
Os requisitos so documentados em um
nvel apropriado de detalhe. Em geral
produzido um documento de especifica-
o de requisitos, de forma que todos os
stakeholders possam entend-lo.
O registro dos requisitos num documen-
to prprio facilita o controle de alteraes
de todos os envolvidos na manuteno
dos requisitos, bem como a gerao de
verses do documento e a facilidade de
acesso por todos os envolvidos.
Verificao
Esta atividade examina a especificao
do software, de forma a assegurar que
todos os requisitos foram definidos sem
ambigidades, inconsistncias ou omis-
ses, detectando e corrigindo possveis
problemas ainda durante a fase de defi-
nio dos requisitos.
Neste contexto, sabe-se que o custo da
correo de defeitos aumenta na medida
em que o processo de desenvolvimento

progride. Revises de artefatos de sof-
tware tm se mostrado uma abordagem
eficiente e de baixo custo para encontrar
defeitos logo aps terem sido introdu-
zidos, reduzindo o retrabalho e melho-
rando a qualidade dos produtos. No
em vo que modelos de maturidade de
processo de software, como o CMMI e o
MPS BR exigem a conduo de revises.
Um tipo particular de reviso de softwa-
re so as inspees. Inspees possuem legislao, mudanas no mercado, mu-
um processo de deteco de defeitos
rigoroso e bem definido. Os benefcios
de se aplicar inspees so maiores para
artefatos desenvolvidos no incio do pro-
cesso, como o documento de requisitos.
Conheceremos um pouco mais sobre
inspeo de software em um segundo
artigo a ser publicado na segunda edio
da Engenharia de Software Magazine.
Validao
A validao representa a atividade
em que obtemos o aceite do cliente sob
determinado artefato. No cenrio de
engenharia de requisitos, esta atividade
significa aprovar junto ao cliente os re-
quisitos que foram especificados. Embora
aparentemente simples, esta atividade
pode ser bastante dificultada pelo cliente
ou mesmo por um processo de validao
inadequado utilizado pela empresa.
Gerncia de Requisitos
Requisitos so por natureza volteis.
Diversos fatores contribuem para sua
instabilidade ao longo do tempo. Mudan-
as externas no ambiente (mudanas de
requisitos so volteis e, portanto sofrem
dana no posicionamento estratgico da
empresa), erros incorridos no processo de
requisitos, entre outros. Todos esses fato-
res fazem com que seja necessrio alterar
os requisitos. Tais alteraes precisam ser
conduzidas de forma ordenada para que
no se perca controle sobre o prazo e o
custo do desenvolvimento.
Denominamos a atividade de adminis-
trar os requisitos ao longo do tempo de
gerenciamento de requisitos. Os bene-
fcios desta atividade so percebidos no
mdio prazo, sendo que so necessrios
investimentos no curto prazo. Assim, a
atividade , muitas vezes, tida como um
fardo desnecessrio conduo do pro-
cesso. Contudo, sua no implementao
Edio 01 Engenharia de Software Magazine
requisi tos
faz com que as economias de curto prazo
sejam logo suplantadas pelas despesas no
longo prazo, verificadas com superao de
custo e prazo nos projetos conduzidos.
Veremos a partir de agora algumas das
atividades que devem ser consideradas
durante a gerncia dos requisitos.
Controle de Mudanas
Conforme foi citado anteriormente, os
mudanas ao logo do tempo, para condu-
zir estas mudanas recomenda-se pre-
paro e planejamento. Uma das maneiras
bastante utilizadas para organizar estas
mudanas a baseline de requisitos
que nos permite diferenciar o que era o
requisito original, o que foi introduzido
e o que foi descartado. Alm disto, inte-
ressante estabelecer um nico canal para
controle de mudanas, bem como utilizar
um sistema para este controle.
Apresentamos a seguir uma sugesto
de passos que devem ser seguidos para
um processo de controle de mudana:
Checar validade da solicitao de
mudana;
Identificar os requisitos diretamente
51
afetados com a mudana;
Identificar dependncias entre requi-
sitos para buscar os requisitos afetados
indiretamente;
Assegurar com solicitante a mudana
a ser realizada;
Estimar custos da mudana;
Obter acordo com usurio sobre o
custo da mudana.
Aps a realizao desta anlise, po- to de requisitos est a rastreabilidade.
demos aceitar ou rejeitar a mudana,
conforme os impactos e custos que ela
pode ter no sistema.
Gerncia de Configurao
Durante o ciclo de vida do desenvolvi-
mento, o software passa por uma srie de
modificaes, desde a especificao dos
requisitos at a implantao do sistema.
A gerncia de configurao de software
existe no intuito de definir critrios que
permitam realizar tais modificaes
mantendo-se a consistncia e a integri-
dade do software com as especificaes,
minimizando problemas decorrentes ao
processo de desenvolvimento, atravs
de um controle sistemtico sobre as
modificaes.
A criao de um plano de gerncia de
configurao consiste em estabelecer nor-
mas, ferramentas e templates que permi-
tam gerenciar de maneira satisfatria os
itens de configurao de um sistema, que
so definidos por Pressman como: cada
um dos elementos de informao que so
criados durante o desenvolvimento de
um produto de software, ou que para este
desenvolvimento sejam necessrios, que
so identificados de maneira nica e cuja
evoluo passvel de rastreamento. o usurio) que fundamentaram a criao
Em cada fase do processo de desenvolvi-
mento, um conjunto bem definido de itens
de configurao deve ser estabelecido. A
este conjunto dado o nome de baselines.
Estas baselines servem como marco no
processo de desenvolvimento, pois ao
final de cada fase estabelecida uma
nova baseline e, portanto, todos os itens
de configurao esto sob total controle
de seus desenvolvedores. Desta forma,
nesta baseline guardada uma foto dos
artefatos criados at aquele momento:
tornando mais fcil realizar modi-
ficaes nos artefatos de maneira con-
trolada;
52 Engenharia de Software Magazine Introduo Engenharia de Requisitos
possibilitando ter um controle siste-
mtico sobre todos os itens de configu-
rao abordados em cada fase do ciclo de
vida do software, e;
tornando possvel que sejam realiza-
das, mais facilmente, avaliaes sobre seu
grau de evoluo.
Rastreabilidade
No centro da atividade de gerenciamen-
Esta definida como a habilidade de se
acompanhar a vida de um requisito em
ambas as direes (por exemplo: partindo
de requisitos e chegando a projeto ou,
partindo de projeto e chegando a requi-
sitos) do processo de software e durante
todo o seu ciclo de vida.
A dificuldade envolvida com a ras-
treabilidade est no grande volume de
informaes gerado. As informaes do
processo de requisitos devem ser catalo-
gadas e associadas aos outros elementos
de forma que possam ser referenciadas
atravs dos diversos itens de informao
registrados. um trabalho extenso que,
sem o auxlio de ferramentas adequa-
das, muito provavelmente no poder
ser feito
Para implementar a rastreabilidade,
usualmente confeccionado em conjun-
to com a especificao de requisitos um
artefato chamado matriz de rastreabi-
lidade, que tem como objetivo mapear
os rastros dos requisitos descritos na
especificao.
Os rastros dos requisitos podem ser de
dois tipos:
Pr-rastreabilidade: os rastros (artefa-
tos: plano de negocio, atas de reunio com
nem possvel investigarmos a qualidade
do requisito.
Ps-rastreabilidade: os rastros (arte-
fatos: cdigo, documentos) que se forma-
ram a partir do requisito criado.
Gerncia de Qualidade de Requisitos
Segundo o padro IEEE 830, devemos
considerar alguns critrios de qualidade
ao trabalharmos com requisitos:
Correo: um documento de requi-
sitos considerado correto se todos os
requisitos representam algo que deve
estar presente no sistema que est sen-
do desenvolvido, ou seja, os requisitos
reais do usurio devem coincidir com
os requisitos identificados. Esta no
uma tarefa trivial e parte de seu sucesso
est associada a uma boa atividade de
validao dos requisitos.
No ambigidade: um conjunto de
requisitos no ambguo quando so-
mente pode ser interpretado por todos
os envolvidos em um projeto de uma
nica maneira.
Completude: um conjunto de requi-
sitos dito completo quando descreve
todas as demandas de interesse dos usu-
rios. Estas demandas incluem requisitos
funcionais, de desempenho, restries,
atributos e interfaces externas.
Consistncia: um conjunto de requisi-
tos dito consistente se nenhum subcon-
junto destes requisitos entra em conflito
com os demais requisitos do sistema.
Verificabilidade: um requisito
verificvel se existe uma forma efetiva,
em termos de tempo e custo, para que
pessoas ou ferramentas indiquem se um
sistema cumpre o requisito (IEEE). Em
quase todas as situaes, difcil provar
de forma conclusiva que um requisito
cumprido por um software. Entretanto,
escrever bem o requisito pode ajudar a
aumentar a confiana na avaliao.
Modificabilidade: um conjunto de re-
quisitos modificvel quando seu estilo
e estrutura tal que as alteraes podem
ser realizadas de forma simples e consis-
tente com os demais requisitos.
A gerncia, neste cenrio, responsvel
por manter uma infra-estrutura necess-
ria para atividades de verificao que tor-
dos requisitos que estamos definindo.
Concluso
A engenharia de requisitos define, sem
dvida, um dos mais importantes conjun-
tos de atividades a serem realizadas em
projetos de desenvolvimento de software.
Embora no garanta a qualidade dos
produtos gerados, um pr-requisitos
bsico para que obtenhamos sucesso no
desenvolvimento do projeto. Este artigo
apenas uma breve introdu oao
tema, que dever ser bastante explorado
em edies futuras da Engenharia de
Software Magazine.
 Introduo a Teste de Software
Arilo Cludio Dias Neto
(ariloclaudio@gmail.com)
Bacharel em Cincia da Computao for-
mado na Universidade Federal do Amazonas,
Mestre em Engenharia de Sistemas e Compu-
tao formado na COPPE/UFRJ, e atualmente
est cursando doutorado na rea de Engenha-
ria de Software da COPPE/UFRJ. Possui 5 anos
de experincia em anlise, desenvolvimento e
teste de software. editor tcnico das Revis-
tas SQL Magazine e WebMobile, gerenciadas
pelo Grupo DevMedia.
54 Engenharia de Software Magazine Introduo a Teste de Software
T
este de software o processo de desta tarefa revelar o nmero mximo
execuo de um produto para de falhas dispondo do mnimo de esforo,
determinar se ele atingiu suas es- ou seja, mostrar aos que desenvolvem se
pecificaes e funcionou corretamente no os resultados esto ou no de acordo com
ambiente para o qual foi projetado. O seu os padres estabelecidos.
objetivo revelar falhas em um produto, Ao longo deste artigo, iremos discutir
para que as causas dessas falhas sejam os principais conceitos relacionados s
identificadas e possam ser corrigidas pela atividades de teste, as principais tcnicas
equipe de desenvolvimento antes da en- e critrios de teste que podem ser utiliza-
trega final. Por conta dessa caracterstica dos para verificao ou validao de um
das atividades de teste, dizemos que sua produto, assim como exemplos prticos
natureza destrutiva, e no construti- da aplicao de cada tipo de tcnica ou
va, pois visa ao aumento da confiana de critrio de teste.
um produto atravs da exposio de seus
problemas, porm antes de sua entrega Conceitos bsicos associados
ao usurio final. a Teste de Software
O conceito de teste de software pode Antes de iniciarmos uma discusso
ser compreendido atravs de uma viso sobre teste de software precisamos es-
intuitiva ou mesmo de uma maneira clarecer alguns conceitos relacionados a
formal. Existem atualmente vrias defi- essa atividade. Inicialmente, precisamos
nies para esse conceito. De uma forma conhecer a diferena entre Defeitos, Er-
simples, testar um software significa veri- ros e Falhas. As definies que iremos
ficar atravs de uma execuo controlada usar aqui seguem a terminologia padro
se o seu comportamento corre de acordo para Engenharia de Software do IEEE
com o especificado. O objetivo principal Institute of Electrical and Electronics

Engineers (IEEE 610, 1990).
Defeito um ato inconsistente come-
tido por um indivduo ao tentar entender
uma determinada informao, resolver
um problema ou utilizar um mtodo
ou uma ferramenta. Por exemplo, uma
instruo ou comando incorreto.
Erro uma manifestao concreta
de um defeito num artefato de softwa-
re. Diferena entre o valor obtido e o
valor esperado, ou seja, qualquer estado
intermedirio incorreto ou resultado
inesperado na execuo de um programa
constitui um erro.
Falha o comportamento operacional
do software diferente do esperado pelo
usurio. Uma falha pode ter sido causada
por diversos erros e alguns erros podem
nunca causar uma falha.
A Figura 1 expressa a diferena entre
esses conceitos. Defeitos fazem parte
do universo fsico (a aplicao propria-
mente dita) e so causados por pessoas,
por exemplo, atravs do mal uso de uma
tecnologia. Defeitos podem ocasionar a
manifestao de erros em um produto, ou
seja, a construo de um software de for-
ma diferente ao que foi especificado (uni-
verso de informao). Por fim, os erros
geram falhas, que so comportamentos
inesperados em um software que afetam
diretamente o usurio final da aplicao
(universo do usurio) e pode inviabilizar
a utilizao de um software.
Dessa forma, ressaltamos que teste de
software revela simplesmente falhas em
um produto. Aps a execuo dos testes
necessria a execuo de um processo de
depurao para a identificao e correo
dos defeitos que originaram essa falha,
ou seja, Depurar no Testar!
A atividade de teste composta por
alguns elementos essenciais que auxiliam
na formalizao desta atividade. Esses
elementos so os seguintes:
Caso de Teste. descreve uma condio
particular a ser testada e composto por
valores de entrada, restries para a sua
execuo e um resultado ou compor-
tamento esperado (CRAIG e JASKIEL,
2002).
Procedimento de Teste. uma descri-
o dos passos necessrios para executar
um caso (ou um grupo de casos) de teste
(CRAIG e JASKIEL, 2002).
Critrio de Teste: serve para selecionar
e avaliar casos de teste de forma a aumen-
Verific ao, Validao e Teste
requisitos
Figura 1. Defeito x erro x falha (Uma verso similar pode ser obtida em http://www.projectcartoon.com/cartoon/611)
tar as possibilidades de provocar falhas
ou, quando isso no ocorre, estabelecer
um nvel elevado de confiana na correo
do produto (ROCHA et al., 2001). Os crit-
rios de teste podem ser utilizados como:
o Critrio de Cobertura dos Testes:
permitem a identificao de partes do
programa que devem ser executadas
para garantir a qualidade do software
e indicar quando o mesmo foi suficien-
temente testado (RAPPS e WEYUKER,
1982). Ou seja, determinar o percentual
de elementos necessrios por um crit-
rio de teste que foram executados pelo
conjunto de casos de teste.
o Critrio de Adequao de Casos
de Teste: Quando, a partir de um con-
junto de casos de teste T qualquer, ele
utilizado para verificar se T satisfaz os
requisitos de teste estabelecidos pelo
critrio. Ou seja, este critrio avalia se os
casos de teste definidos so suficientes
ou no para avaliao de um produto ou
uma funo (ROCHA et al., 2001).
o Critrio de Gerao de Casos de
Teste: quando o critrio utilizado para
gerar um conjunto de casos de teste T
adequado para um produto ou funo,
ou seja, este critrio define as regras e
diretrizes para gerao dos casos de tes-
te de um produto que esteja de acordo
com o critrio de adequao definido
anteriormente (ROCHA et al., 2001).
Definidos os elementos bsicos asso-
ciados aos testes de software, iremos a
seguir discutir a origem dos defeitos em
um software.
Defeitos no desenvolvimento
de software
No processo de desenvolvimento de
software, todos os defeitos so humanos
e, apesar do uso dos melhores mtodos
de desenvolvimento, ferramentas ou
Edio 01 Engenharia de Software Magazine
profissionais, permanecem presentes
nos produtos, o que torna a atividade de
teste fundamental durante o desenvolvi-
mento de um software. J vimos que esta
atividade corresponde ao ltimo recurso
para avaliao do produto antes da sua
entrega ao usurio final.
O tamanho do projeto a ser desenvolvi-
do e a quantidade de pessoas envolvidas
no processo so dois possveis fatores
que aumentam a complexidade dessa
tarefa, e consequentemente aumentam
a probabilidade de defeitos. Assim, a
ocorrncia de falhas inevitvel. Mas
o que significa dizer que um programa
falhou? Basicamente significa que o
funcionamento do programa no est de
acordo com o esperado pelo usurio. Por
exemplo, quando um usurio da linha
de produo efetua consultas no sistema
das quais s a gerncia deveria ter acesso.
Esse tipo de falha pode ser originado por
diversos motivos:
A especificao pode estar errada ou
incompleta;
A especificao pode conter requisitos
impossveis de serem implementados
devido a limitaes de hardware ou sof-
tware;
A base de dados pode estar organizada
de forma que no seja permitido distin-
guir os tipos de usurio;
Pode ser que haja um defeito no algo-
ritmo de controle dos usurios.
Os defeitos normalmente so introdu-
zidos na transformao de informaes
entre as diferentes fases do ciclo de de-
senvolvimento de um software. Vamos
seguir um exemplo simples de ciclo de
vida de desenvolvimento de software:
os requisitos expressos pelo cliente so
relatados textualmente em um docu-
mento de especificao de requisitos.
Esse documento ento transformado
55
em casos de uso, que por sua vez foi o
artefato de entrada para o projeto do
software e definio de sua arquite-
tura utilizando diagramas de classes
da UML. Em seguida, esses modelos
de projetos foram usados para a cons-
truo do software em uma linguagem
que no segue o paradigma orientado a
objetos. Observe que durante esse pe-
rodo uma srie de transformaes foi
realizada at chegarmos ao produto fi-
nal. Nesse meio tempo, defeitos podem
ter sido inseridos. A Figura 2 expressa
exatamente a metfora discutida nesse
pargrafo.
Essa srie de transformaes resultou
na necessidade de realizar testes em dife-
rentes nveis, visando avaliar o software
em diferentes perspectivas de acordo com
o produto gerado em cada fase do ciclo de
vida de desenvolvimento de um softwa-
re. Esse ser o foco da seo seguinte.
Figura 2. Diferentes Interpretaes ao longo do ciclo de desenvolvimento de um software
Figura 3. Modelo V descrevendo o paralelismo entre as atividades de desenvolvimento e teste de software
(CRAIG e JASKIEL, 2002)
56 Engenharia de Software Magazine Introduo a Teste de Software
Nveis de teste de software
O planejamento dos testes deve ocorrer
em diferentes nveis e em paralelo ao
desenvolvimento do software (Figura 3).
Buscando informao no Livro Qualidade
de Software Teoria e Prtica (ROCHA et
al., 2001), definimos que os principais nveis
de teste de software so:
Teste de Unidade: tambm conhecido
como testes unitrios. Tem por objetivo
explorar a menor unidade do projeto, pro-
curando provocar falhas ocasionadas por
defeitos de lgica e de implementao em
cada mdulo, separadamente. O universo
alvo desse tipo de teste so os mtodos
dos objetos ou mesmo pequenos trechos
de cdigo.
Teste de Integrao: visa provocar
falhas associadas s interfaces entre os
mdulos quando esses so integrados
para construir a estrutura do software
que foi estabelecida na fase de projeto.
Teste de Sistema: avalia o software em
busca de falhas por meio da utilizao do
mesmo, como se fosse um usurio final.
Dessa maneira, os testes so executados nos
mesmos ambientes, com as mesmas con-
dies e com os mesmos dados de entrada
que um usurio utilizaria no seu dia-a-dia
de manipulao do software. Verifica se o
produto satisfaz seus requisitos.
Teste de Aceitao: so realizados
geralmente por um restrito grupo de usu-
rios finais do sistema. Esses simulam
operaes de rotina do sistema de modo
a verificar se seu comportamento est de
acordo com o solicitado.
Teste de Regresso: Teste de regresso
no corresponde a um nvel de teste, mas
uma estratgia importante para reduo
de efeitos colaterais. Consiste em se
aplicar, a cada nova verso do software
ou a cada ciclo, todos os testes que j
foram aplicados nas verses ou ciclos
de teste anteriores do sistema. Pode ser
aplicado em qualquer nvel de teste.
Dessa forma, seguindo a Figura 3, o
planejamento e projeto dos testes devem
ocorrer de cima para baixo, ou seja:
1. Inicialmente planejado o teste de
aceitao a partir do documento de re-
quisitos;
2. Aps isso planejado o teste de sis-
tema a partir do projeto de alto nvel do
software;
3. Em seguida ocorre o planejamento
dos testes de integrao a partir o projeto
detalhado;
4. E por fim, o planejamento dos testes
a partir da codificao.
J a execuo ocorre no sentido inverso.
Conhecidos os diferentes nveis de teste,
a partir da prxima seo descreveremos
as principais tcnicas de teste de software
existentes que podemos aplicar nos dife-
rentes nveis abordados.
Tcnicas de teste de software
Atualmente existem muitas maneiras
de se testar um software. Mesmo assim,
existem as tcnicas que sempre foram
muito utilizadas em sistemas desenvol-
vidos sobre linguagens estruturadas
que ainda hoje tm grande valia para
os sistemas orientados a objeto. Apesar
de os paradigmas de desenvolvimento
serem diferentes, o objetivo principal
destas tcnicas continua a ser o mesmo:
 Verific ao, Validao e Teste

encontrar falhas no software. nadas por estruturas de condies requisitos

As tcnicas de teste so classificadas de
acordo com a origem das informaes
utilizadas para estabelecer os requisitos
de teste. Elas contemplam diferentes
perspectivas do software e impe-se a
necessidade de se estabelecer uma estra-
tgia de teste que contemple as vantagens
e os aspectos complementares dessas tc-
nicas. As tcnicas existentes so: tcnica
funcional e estrutural.
A seguir conheceremos um pouco mais
sobre cada tcnica, mas iremos enfatizar
alguns critrios especficos para a tcnica
funcional.
Tcnica Estrutural
(ou teste caixa-branca)
Tcnica de teste que avalia o com-
portamento interno do componente de
software (Figura 4). Essa tcnica trabalha
diretamente sobre o cdigo fonte do com-
ponente de software para avaliar aspec-
tos tais como: teste de condio, teste de
fluxo de dados, teste de ciclos e teste de
caminhos lgicos (PRESSMAN, 2005).
Os aspectos avaliados nesta tcnica
de teste dependero da complexidade
e da tecnologia que determinarem a
construo do componente de software,
cabendo, portanto, avaliao de outros
aspectos alm dos citados anteriormente.
O testador tem acesso ao cdigo fonte
da aplicao e pode construir cdigos
para efetuar a ligao de bibliotecas e
componentes.
Este tipo de teste desenvolvido anali-
sando-se o cdigo fonte e elaborando-se
casos de teste que cubram todas as pos-
sibilidades do componente de software.
Dessa maneira, todas as variaes origi-
so
testadas. A Listagem 1 apresenta um
cdigo fonte, extrado de (BARBOSA et
al., 2000) que descreve um programa de
exemplo que deve validar um identifica-
dor digitado como parmetro, e a Figura
5 apresenta o grafo de programa extrado
a partir desse cdigo, tambm extrado Figura 4. Tcnica de Teste Estrutural.
de (BARBOSA et al., 2000). A partir do
grafo deve ser escolhido algum critrio
baseado em algum algoritmo de busca
em grafo (exemplo: visitar todos os ns,
arcos ou caminhos) para gerao dos ca-
sos de teste estruturais para o programa
(PFLEEGER, 2004).
Um exemplo bem prtico desta tcnica
de teste o uso da ferramenta livre JUnit
para desenvolvimento de casos de teste
para avaliar classes ou mtodos desen-
volvidos na linguagem Java. A tcnica de
teste de Estrutural recomendada para
os nveis de Teste da Unidade e Teste da
Integrao, cuja responsabilidade prin-
cipal fica a cargo dos desenvolvedores
do software, que so profissionais que
conhecem bem o cdigo-fonte desenvol-
vido e dessa forma conseguem planejar
os casos de teste com maior facilidade.
Dessa forma, podemos auxiliar na redu-
o dos problemas existentes nas peque-
nas funes ou unidades que compem Figura 5. Grafo de Programa (Identifier.c)
um software. (BARBOSA et al., 2000).
Teste Funcional (ou teste caixa-preta)
Tcnica de teste em que o componente
de software a ser testado abordado
como se fosse uma caixa-preta, ou seja,
no se considera o comportamento inter-
no do mesmo (Figura 6). Dados de entrada
so fornecidos, o teste executado e o
resultado obtido comparado a um re- Figura 6. Tcnica de Teste Funcional.

Listagem 1. Cdigo fonte do programa identifier.c (BARBOSA et al., 2000)

/* 01 */ {
/* 01 */ char achar;
/* 01 */ int length, valid_id;
/* 01 */ length = 0;
/* 01 */ printf (Digite um possvel identificador\n);
/* 01 */ printf (seguido por <ENTER>: );
/* 01 */ achar = fgetc (stdin);
/* 01 */ valid_id = valid_starter (achar);
/* 01 */ if (valid_id)
/* 02 */ length = 1;
/* 03 */ achar = fgetc (stdin);
/* 04 */ while (achar != \n)
/* 05 */ {
/* 05 */ if (!(valid_follower (achar)))
/* 06 */ valid_id = 0;
/* 07 */ length++;
/* 07 */ achar = fgetc (stdin);
/* 07 */ }
/* 08 */ if (valid_id && (length >= 1) && (length < 6) )
/* 09 */ printf (Valido\n);
/* 10 */ else
/* 10 */ printf (Invalido\n);
/* 11 */ }

Edio 01 Engenharia de Software Magazine 57

sultado esperado previamente conhecido.
Haver sucesso no teste se o resultado
obtido for igual ao resultado esperado.
O componente de software a ser testado
pode ser um mtodo, uma funo interna,
um programa, um componente, um con-
junto de programas e/ou componentes ou
mesmo uma funcionalidade. A tcnica
de teste funcional aplicvel a todos os
nveis de teste (PRESSMAN, 2005).
Um conjunto de critrios de teste pode
ser aplicado aos testes funcionais. A se-
guir conheceremos alguns deles.
Particionamento em classes de
equivalncia
Esse critrio divide o domnio de entrada
de um programa em classes de equivaln-
cia, a partir das quais os casos de teste so
derivados. Ele tem por objetivo minimizar
o nmero de casos de teste, selecionando
apenas um caso de teste de cada classe,
pois em princpio todos os elementos
de uma classe devem se comportar de
maneira equivalente. Eventualmente,
pode-se tambm considerar o domnio
de sada para a definio das classes de
equivalncia (ROCHA et al., 2001).
Uma classe de equivalncia representa
um conjunto de estados vlidos e in-
vlidos para uma condio de entrada.
>80 #produtos
Valor comp ra
< =80
Figura 7. rvore de Deciso Grafo de Causa-Efeito.
Condies de Entrada
Tamanho t do identificador
Primeiro caractere c uma letra
S contm caracteres vlidos
Tabela 1. Classes de Equivalncia do programa identifier.c.
Valor da compra
Causa
#Produtos
Cobrar frete
Efeito
Frete grtis
Tabela 2. Tabela de deciso para o programa de compra pela Internet.
58 Engenharia de Software Magazine Introduo a Teste de Software
Tipicamente uma condio de entrada
pode ser um valor numrico especfico,
uma faixa de valores, um conjunto de
valores relacionados, ou uma condio
lgica. As seguintes diretrizes podem
ser aplicadas:
Se uma condio de entrada especifica
uma faixa de valores ou requer um valor es-
pecfico, uma classe de equivalncia vlida
(dentro do limite) e duas invlidas (acima
e abaixo dos limites) so definidas.
Se uma condio de entrada especifica
um membro de um conjunto ou lgica,
uma classe de equivalncia vlida e uma
invlida so definidas.
Devemos seguir tais passos para gera-
o dos testes usando este critrio:
1. Identificar classes de equivalncia (
um processo heurstico)
o condio de entrada
o vlidas e invlidas
2. Definir os casos de teste
o enumeram-se as classes de equi-
valncia
o casos de teste para as classes vlidas
o casos de teste para as classes invlidas
Em (BARBOSA et al., 2000) apresenta-
do a aplicao do critrio de particiona-
mento por equivalncia para o programa
<3
Fret e Grtis
> =3
Cob rar Frete
Classes Classes
(1) 1 t 6 (2) t > 6
(3) Sim (4) No
(5) Sim (6) No
> 60 > 60
<3 >= 3
V V
V
identifier.c. Iremos apresent-lo como
exemplo do uso deste critrio de teste. Re-
lembrando, o programa deve determinar
se um identificador vlido ou no.
Um identificador vlido deve comear
com uma letra e conter apenas letras ou
dgitos. Alm disso, deve ter no mnimo
1 caractere e no mximo 6 caracteres
de comprimento. Exemplo: abc12 (v-
lido), cont*1 (invlido), 1soma (invli-
do) e a123456 (invlido).
O primeiro passo a identificao das
classes de equivalncia. Isso est descrito
na Tabela 1.
A partir disso, conseguimos especificar
quais sero os casos de teste necessrios.
Para ser vlido, um identificador deve
atender s condies (1), (3) e (5), logo
necessrio um caso de teste vlido que
cubra todas essas condies. Alem disso,
ser necessrio um caso de teste para
cada classe invlida: (2), (4) e (6). Assim, o
conjunto mnimo composto por quatro
casos de teste, sendo uma das opes:
T0 = {(a1,Vlido), (2B3, Invlido), (Z-12,
Invlido), (A1b2C3d, Invlido)}.
Anlise do valor limite
Por razes no completamente iden-
tificadas, um grande nmero de erros
tende a ocorrer nos limites do domnio de
entrada invs de no centro. Esse critrio
de teste explora os limites dos valores de
cada classe de equivalncia para preparar
os casos de teste (Pressman, 2005).
Se uma condio de entrada especifica
uma faixa de valores limitada em a e b,
casos de teste devem ser projetados com
valores a e b e imediatamente acima e
abaixo de a e b. Exemplo: Intervalo =
{1..10}; Casos de Teste {1, 10, 0,11}.
Como exemplo, extrado de (BARBOSA
et al., 2000), iremos considerar a seguinte
situao:
"... o clculo do desconto por depen-
dente feito da seguinte forma: a entra-
da a idade do dependente que deve
estar restrita ao intervalo [0..24]. Para
<= 60 dependentes at 12 anos (inclusive) o
desconto de 15%. Entre 13 e 18 (inclu-
--
sive) o desconto de 12%. Dos 19 aos
21 (inclusive) o desconto de 5% e dos
22 aos 24 de 3%..."
Aplicando o teste de valor limite

convenc iona l sero obt idos ca-
s o s de t e st e s e me l h a nt e s a e st e:
{-1,0,12,13,18,19,21,22,24,25}.
Grafo de causa-efeito
Esse critrio de teste verifica o efeito
combinado de dados de entrada. As
causas (condies de entrada) e os efeitos
(aes) so identificados e combinados
em um grafo a partir do qual montada
uma tabela de deciso, e a partir desta,
so derivados os casos de teste e as sadas
(ROCHA et al., 2001).
Esse critrio baseado em quatro pas-
sos, que exemplificaremos utilizando o
exemplo, tambm extrado de (BARBOSA
et al., 2000):
Em um programa de compras pela
Internet, a cobrana ou no do frete
definida seguindo tal regra: Se o valor
da compra for maior que R$ 60,00 e fo-
ram comprados menos que 3 produtos,
o frete gratuito. Caso contrrio, o frete
dever ser cobrado.
1. Para cada mdulo, Causas (condies
de entrada) e efeitos (aes realizadas s
diferentes condies de entrada) so rela-
cionados, atribuindo-se um identificador
para cada um.
Causa: valor da compra > 60 e #pro-
dutos < 3
Efeito: frete grtis
2. Em seguida, um grafo de causa-
efeito (rvore de deciso) desenhado
(Figura 7).
3. Neste ponto, transforma-se o grafo
numa tabela de deciso (Tabela 2).
4. As regras da tabela de deciso so,
ento, convertidas em casos de teste.
Para a elaborao dos casos de teste,
devemos seguir todas as regras extradas
da tabela. Esse critrio deve ser combi-
nado com os dois outros j apresentados
neste artigo para a criao de casos de
teste vlidos (extrados das regras) e
invlidos (valores foras da faixa defini-
da). Os casos de teste definidos a seguir
refletem somente as regras extradas da
tabela de deciso. Fica como exerccio
pensar nos casos de teste invlidos para
este problema.
Casos de Teste (valor, qtd produtos,
Verific ao, Validao e Teste
resultado esperado) = {(61,2,frete requisitos
gr- gerenciamento e anlise de resultados.
tis); (61,3,cobrar frete); (60, qualquer Apoio ferramental para qualquer ativi-
quantidade,cobrar frete)}. dade do processo de teste importante
como mecanismo para reduo de esforo
Outras tcnicas associado tarefa em questo, seja ela
Outras tcnicas de teste podem e devem planejamento, projeto ou execuo dos
ser utilizadas de acordo com necessidades testes. Aps ter sua estratgia de teste
de negcio ou restries tecnolgicas. definida, tente buscar por ferramentas
Destacam-se as seguintes tcnicas: teste de que se encaixem na sua estratgia. Isso
desempenho, teste de usabilidade, teste de pode reduzir significantemente o esforo
carga, teste de stress, teste de confiabilida- de tal tarefa.
de e teste de recuperao. Alguns autores Alm disso, importante ressaltar que
chegam a definir uma tcnica de teste diferentes tipos de aplicaes possuem
caixa cinza, que seria um mesclado do uso diferentes tcnicas de teste a serem
das tcnicas de caixa preta e caixa branca, aplicadas, ou seja, testar uma aplicao
mas, como toda execuo de trabalho web envolve passos diferenciados em
relacionado atividade de teste utilizar comparao aos testes de um sistema
simultaneamente mais de uma tcnica embarcado. Cada tipo de aplicao possui
de teste, recomendvel que se fixem os caractersticas especificas que devem ser
conceitos primrios de cada tcnica. consideradas no momento da realizao
dos testes. O conjunto de tcnicas apre-
Concluses sentado neste artigo cobre diversas carac-
O teste de software uma das atividades tersticas comuns a muitas categorias de
mais custosas do processo de desenvol- software, mas no completo.
vimento de software, pois pode envolver Para finalizar, podemos destacar ou-
uma quantidade significativa dos recursos tros pontos importantes relacionados s
de um projeto. O rigor e o custo associado atividades de teste que podemos abordar
a esta atividade dependem principalmente em prximos artigos, tais como processo
da criticalidade da aplicao a ser desenvol- de teste de software, planejamento e con-
vida. Diferentes categorias de aplicaes trole dos testes e teste de software para
requerem uma preocupao diferenciada categorias especficas de software, como
com as atividades de teste. aplicaes web. At a prxima!
Um ponto bastante importante para
a viabilizao da aplicao de teste de Agradecimentos
software a utilizao de uma infra- Agradecemos aos professores Jos Carlos
estrutura adequada. Realizar testes Maldonado e Ellen Barbosa por terem
no consiste simplesmente na gerao gentilmente autorizado a publicao deste
e execuo de casos de teste, mas envol- material, cujos exemplos utilizados esto
vem tambm questes de planejamento, fundamentados em seus trabalhos.
Referncias
BARBOSA, E.; MALDONADO, J.C.; VINCENZI, A.M.R.; DELAMARO, M.E; SOUZA, S.R.S. e JINO, M..
Introduo ao Teste de Software. XIV Simpsio Brasileiro de Engenharia de Software, 2000.
CRAIG, R.D., JASKIEL, S. P., Systematic Software Testing, Artech House Publishers, Boston, 2002.
IEEE Standard 610-1990: IEEE Standard Glossary of Software Engineering Terminology, IEEE Press.
PFLEEGER, S. L., Engenharia de Software: Teoria e Prtica, Prentice Hall- Cap. 08, 2004.
PRESSMAN, R. S.,Software Engineering: A Practitioners Approach, McGraw-Hill, 6th ed, Nova York,
NY, 2005.
RAPPS, S., WEYUKER, E.J., Data Flow analysis techniques for test data selection, In: International
Conference on Software Engineering, p. 272-278, Tokio, Sep. 1982.
ROCHA, A. R. C., MALDONADO, J. C., WEBER, K. C. et al., Qualidade de software Teoria e prtica,
Prentice Hall, So Paulo, 2001.
Edio 01 Engenharia de Software Magazine 59
 Gesto de defeitos
Ferramentas Open Source e melhores prticas na gesto de defeitos
Cristiano Caetano
c_caetano@hotmail.com
certificado CBTS pela ALATS. Consultor de
teste de software snior com mais de 10
anos de experincia, j trabalhou na rea de
qualidade e teste de software para grandes
empresas como Zero G, DELL e HP Invent.
colunista na rea de Teste e Qualidade de
software do site linhadecodigo.com.br e au-
tor dos livros "CVS: Controle de Verses e De-
senvolvimento Colaborativo de Software" e
"Automao e Gerenciamento de Testes: Au-
mentando a Produtividade com as Principais
Solues Open Source e Gratuitas". O autor
mantm um blog sobre testes e qualidade
de software, confira no seguinte endereo:
http://spaces.msn.com/softwarequality/.
60 Engenharia de Software Magazine Gesto de Defeitos
O
principal objetivo do teste de
software medir o nvel de
qualidade de um sistema, seja a
aplicao executvel ou os artefatos utili-
zados na sua construo. A qualidade de
um sistema pode ser medida, essencial-
mente, pelo nmero de falhas encontra-
das durante a execuo dos testes.
Falha, nesse contexto, a conseqncia de
um erro, defeito ou engano. Ou seja, o des-
vio entre o que foi solicitado pelo usurio
por meio dos requisitos e o comportamento
apresentado pela aplicao executvel. Em
virtude da complexidade e tamanho de um
sistema ou para atender normas de quali-
dade ou processos de maturidade, se faz
necessrio utilizar um processo de gesto
de defeitos integrado ao ciclo de vida de
desenvolvimento e teste.
Neste contexto, entender as atividades
de um processo de gesto de defeitos
e escolher a ferramenta adequada para
automatizar a gesto do ciclo de vida
de um defeito so tarefas fundamentais,
como veremos mais adiante.
Neste artigo, voc conhecer os con-
ceitos, atividades e terminologia de um
processo de gesto de defeitos. Tambm
ser apresentado um exemplo prtico uti-
lizando o Mantis, ferramenta Open Sour-
ce para gesto de defeitos. E, por fim,
sero apresentadas outras alternativas
Open Source e comerciais caso o Mantis
no atenda as suas necessidades.
Processo de Gesto de defeitos
Um processo de gesto de defeitos tem o
objetivo de definir prticas para prevenir
os defeitos e minimizar os riscos de um
projeto. A utilizao de uma ferramenta
automatizada, alm de oferecer uma base
comum para a entrada de informaes,
tambm oferece um meio para fomentar
a integrao entre o time de desenvolvi-
mento e o time de testes. Alm disso, por
meio dos relatrios de gesto e mtricas
geradas por essas ferramentas, os gestores
do projeto podero promover a melhoria
contnua do processo estabelecido.
Genericamente, o termo Erro (Error)
 Verific ao, Validao e Teste

utilizado para indicar uma diferena rios com dados relevantes para acompa- no especificado no requisito.
entre valor computado, observado ou me- nhar o progresso dos testes e a qualidade
dido em relao ao esperado. No entanto, do sistema, assim como, a gerao de Uma vez que o defeito for encontrado,
o padro IEEE 610.12-1990 (IEEE Standard mtricas para alimentar a atividade de seja por inteno ou por acidente, o
Glossary of Software Engineering Ter- melhoria do processo. prximo passo dever ser o relato (ou
minology) distingue a terminologia da reporte) desse defeito por meio de algum
seguinte forma: Ciclo de vida de um defeito mecanismo estabelecido no processo de
Defeito (Fault): Passo, processo ou de- Como discutimos anteriormente, a gesto de defeitos.
finio de dados incorretos. Por exemplo, qualidade de um sistema pode ser me- Este mecanismo poder ser, desde uma
uma instruo incorreta no cdigo ou dida, essencialmente, pelo nmero de simples planilha, at uma ferramenta
uma falta num artefato esttico; defeitos encontrados durante a execuo automatizada. Por motivos bvios, uma
Engano (Mistake): Ao humana que dos testes. ferramenta automatizada e construda
produz um resultado incorreto, como por Podemos afirmar que os defeitos so para esse propsito ser, sem sombra de
exemplo, uma ao incorreta tomada pelo encontrados por meio da execuo formal dvida, muito mais eficiente do que uma
desenvolvedor ou analista; dos testes (testes estruturais ou funcio- simples planilha ou soluo alternativa.
Falha (Failure): Desvio entre o resul- nais), durante a utilizao do sistema em De qualquer forma, to logo o defeito
tado/comportamento apresentado pela produo ou, at mesmo, por acidente. A seja relatado, ele dever ser submetido a
aplicao em relao aos requisitos. A priori, podemos classificar os defeitos nas um ciclo de vida pr-definido pelo pro-
falha ocorre em conseqncia de um erro, seguintes categorias: cesso de gesto de defeitos. Este ciclo de
defeito ou engano gerando um compor- Faltante (Missing): O defeito ocorre em vida define os fluxos que o defeito dever
tamento incorreto da aplicao. virtude da falta parcial ou total de um percorrer at o seu fechamento.
requisito; A Figura 2 descreve genericamente um
Neste artigo, o termo defeito ser usado Errado (Wrong): O defeito ocorre ciclo de vida de um defeito aderente ao
de forma genrica, podendo representar porque o requisito foi implementado processo de gesto de defeitos apresen-
um erro, engano, defeito ou falha. Se- incorretamente; tado anteriormente. Devemos lembrar
gundo o livro, Base de Conhecimento Acrscimo (Extra): O defeito ocorre que esse um exemplo didtico, existem
do CSTE do QAI, os elementos chave em virtude de um comportamento ou fluxos alternativos e papis que no esto
de um processo de gesto de defeitos elemento que foi implementado, mas foi presentes nesta figura.
so (Figura 1):
Preveno de defeitos: Com base
nos levantamento dos riscos crticos do
projeto, devem ser promovidas aes de
preveno e planejamento de contingn-
cias para minimizar o impacto caso os
riscos tornem-se problemas;
Linha base entregvel: Estabeleci-
mento formal de linhas base (baselines)
por meio da Gerncia de Configurao
de Software. Cada linha base deve de- Figura 1. Elementos chave de um processo de gesto de defeitos.
terminar quais requisitos/artefatos sero
liberados e submetidos ao teste;
Identificao do defeito: Definio
das tcnicas necessrias para encontrar,
reportar e classificar os defeitos, assim
como, os critrios para reconhec-los;
Soluo do defeito: Definio das
atividades para a correo e posterior
notificao da resoluo do defeito. Mui-
tas destas atividades so definidas pela
Gerncia de Configurao de Software
para garantir o histrico e rastreamento
das modificaes por meio do controle
de verses;
Melhoria do processo: Anlise das m-
tricas e relatrios de gesto para entender
a causa raiz dos problemas e promover a
melhoria contnua do processo;
Relatrio de gesto: Gerao de relat- Figura 2. Ciclo de vida de um defeito genrico.

Edio 01 Engenharia de Software Magazine 61

Recomendaes para o relato evitando manifestaes de humor, Severidade X Prioridade
de defeitos emoo, etc; A classificao da severidade e priori-
Notamos que, muito embora o relato Generalizar: Procure entender o dade dos defeitos , de forma similar ao
de um defeito seja um dos passos funda- problema de forma genrica, em virtu- relato de defeitos, um ponto normalmen-
mentais do processo de gesto de defeitos, de de que este problema tambm pode te negligenciado e foco de interpretaes
normalmente ele relegado para segundo acontecer em outras situaes ou fun- incorretas. A classificao incorreta da
plano. A listagem abaixo apresenta as cionalidades. severidade e da prioridade normalmente
diretrizes que devem ser seguidas du- Reproduzir: Garanta que o defeito contribui para a ineficincia da priori-
rante o relato de um defeito com base nas seja reproduzvel e descreva os passos zao e agendamento da correo dos
recomendaes descritas no livro Base de necessrios para a sua reproduo; defeitos. O efeito colateral direto desse
conhecimento em teste de software: Evidenciar: Evidencie a existncia do problema a m utilizao dos recursos
Resumir: Descreva claramente o de- defeito encontrado por meio de arquivos em funo do enfoque na correo de
feito, mas de forma resumida; de sada, printscreens das telas, etc; defeitos menos prioritrios.
Preciso: Certifique-se que o defeito Revisar: Revise a descrio e os passos A grosso modo, podemos afirmar que
identificado realmente um desvio do para reproduzir o defeito. Lembre-se que a severidade de um defeito define o im-
comportamento esperado e no uma o relato do defeito um documento do pacto do defeito no funcionamento da
falha de entendimento; projeto, assim como um caso de uso, um aplicao. Por outro lado, a prioridade
Neutralizar: Relate apenas os fatos, plano de testes, etc. Trate-o como tal; indica a ordem de correo do defeito
(defeitos com alta prioridade so corrigi-
dos imediatamente ou num curto prazo
Severidade Descrio
de tempo). De modo geral, defeitos com
Alta Bloqueia completamente a utilizao de uma funcionalidade bsica ou da aplicao inteira alta severidade so classificados com alta
prioridade. No entanto, podem existir
Bloqueia a utilizao de uma funcionalidade. Mas, no entanto, a funcionalidade pode ser usada por meio da utilizao
Mdia diversas situaes onde no podemos
de um contorno (workaround) conhecido
aplicar essa regra. Por exemplo, a cor-
Baixa Problemas cosmticos e solicitaes de melhorias rupo dos dados de uma aplicao no
Windows 3.11 um defeito com alta se-
Tabela 1. Classificao da prioridade.
veridade mas, no entanto, deve ter baixa
Prioridade Descrio
prioridade em virtude de que 99,9% dos
usurios da aplicao utilizam verses
1 O defeito deve ser corrigido imediatamente (at um dia til). A aplicao no pode ser liberada sem a correo deste defeito mais atuais do Windows. A justificativa
para esse critrio : Por que priorizar a
altamente desejvel que o defeito seja corrigido to logo seja possvel (at cinco dias teis). A aplicao no pode ser
2 correo de um defeito que vai beneficiar
liberada sem a correo deste defeito
apenas 0,01% dos usurios?
3 Defeito de baixa prioridade. A aplicao pode ser liberada com esse defeito Para evitar a subjetividade da classifica-
o, sugere-se que os critrios para cada
Tabela 2. Classificao da severidade.
nvel de prioridade e severidade sejam
definidos na documentao do processo
de gesto de defeitos. Para fins didticos
e de entendimento, sero apresentados na
Tabela 1 e Tabela 2 exemplos de critrios
para classificar a severidade e a priorida-
de dos defeitos respectivamente.

Mantis
O Mantis uma ferramenta Open
Source automatizada escrita em PHP
cujo principal objetivo dar suporte ao
processo de gesto de defeitos. O Mantis
controla o ciclo de vida de um defeito,
desde o seu relato at o seu fechamento,
por meio de fluxos (workflows) persona-
lizveis, como pode ser observado na
Figura 3.
O endereo do site do Mantis est
disponvel na seo Links. Caso voc
tenha interesse de conhec-lo com maior
Figura 3. Pgina inicial do Mantis. profundidade, os passos para a instalao

62 Engenharia de Software Magazine Gesto de Defeitos

 Verific ao, Validao e Teste

so os seguintes: Controle de acesso e nveis de permis- o seu fechamento.

1. As pr-condies para a instalao
so (PHP 4.0.6 ou superior, MySQL 3.23.2
ou superior, Apache ou IIS).
2. Faa o download do Mantis no site
disponvel na seo Links.
3. Descompacte o arquivo zip do Mantis
na pasta www ou htdocs do servidor
WEB (Apache ou IIS).
4. Abra o seu navegador e acesse o
seguinte endereo: (http://localhost/
mantis_1.0.5/).
5. Na janela Pre-Installation Check, pre-
encha os campos username com o nome
da conta de usurio para acesso ao banco
de dados MySQL e o campo password
com a senha.
6. Deixe os valores default nos demais
campos.
7. Pressione o boto Install/Upgrade
Database.
8. Ao final do processo, abra o seu
navegador e acesse o seguinte ende-
reo: (http://localhost/mantis_1.0.5/
login_page.php).
9. Faa o primeiro login com o usurio
padro (administrator/root). Lembre-se
de mudar a senha deste usurio.
ses para os usurios;
Ciclo de vida dos defeitos (worflow)
personalizvel;
Gerador interno de relatrios e grfi-
cos (possibilidade para exportar os dados
nos formatos CSV, Excel e Word);
Mecanismo para a criao de campos
personalizveis (custom fields);
Notificaes por email automticas
ou por meio de RSS Feeds;
Integrao com ferramentas de con-
trole de verses (Subversion e CVS);
Interface Webservice (SOAP) para
integrao com outras ferramentas;
MantisWAP Suporte a dispositivos
mveis (funcionalidade paga);
A fim de dar ao leitor uma exposio
sobre as principais funcionalidades do
Mantis e como elas atendem os principais
fluxos de um ciclo de vida de um defeito,
vamos simular na prtica o relato de um
defeito e acompanhar todos os passos at
To logo um testador ou usurio encon-
tre um defeito, seja por inteno ou por
acidente, o prximo passo dever ser o
relato (ou reporte) desse defeito.
No nosso cenrio, vamos relatar um de-
feito (problema no recurso de seleo de
textos quando existe uma tabela no topo
do documento) do OpenOffice Writer
(processador de texto Open Source).
Para realizar tal tarefa, voc dever
selecionar o menu Relatar Caso do
Mantis. Uma vez que a janela de relato for
exibida, voc dever informar o resumo
do defeito, a descrio, os passos para
reproduzir e assim por diante, como pode
ser observado na Figura 4.
importante lembrar que o correto
preenchimento dos campos severidade
(gravidade) e prioridade neste passo de
extrema importncia para a priorizao e
agendamento da correo do defeito.
Assim que o defeito for relatado, o ana-
lista de teste (ou lder de desenvolvimen-

O Mantis instalado em ingls por

padro. Caso voc prefira utilizar o
Mantis com os textos traduzidos para a
lngua portuguesa, ento siga os passos
descritos abaixo:
1. Faa o login normalmente com o seu
usurio e senha.
2. Clique no menu My Account e en-
to selecione a opo Preferences.
3. No campo Language selecione a op-
o "portuguese_brazil".
4. Pressione o boto "Update Prefs".

Entre as diversas funcionalidades ofe-

recidas pelo Mantis, devemos destacar
as seguintes:
Pode ser executado em qualquer
plataforma que suportar PHP/Apache/
Mysql (Windows, Linux, Mac, Solaris,
AS400/i5, etc);
Suporta vrios bancos de dados (MyS-
QL, MS SQL, PostgreSQL);
Suporta mltiplos mecanismos de
autenticao (Interna, LDAP, HTTP Basic,
Active Directory);
Traduzido em 68 lnguas diferentes
(incluindo "portuguese_brazil");
Criao ilimitada de projetos e relatos
de defeitos; Figura 4. Relato de um defeito.

Edio 01 Engenharia de Software Magazine 63

 to) poder filtrar os defeitos cadastrados
recentemente para confirmar e reconhe-
cer se o que foi relatado realmente um
defeito ao invs de um mal entendimento
do comportamento esperado.
Se for confirmado que o relato no um
problema, ele imediatamente fechado.
Caso contrrio, o analista de teste (ou
lder de desenvolvimento) dever confir-
mar se a severidade (gravidade) e priori-
dade foram classificadas corretamente e
atribuir o defeito a um desenvolvedor,
como pode ser visto na Figura 5.
Nesta altura, tambm podero ser re-
alizadas a projeo da complexidade e
a estimativa do tempo necessrio para
finalizar a correo do defeito.
O desenvolvedor, por sua vez, receber
um e-mail automaticamente conforme
o fluxo (workflow) definido no Mantis,
como pode ser observado no exemplo
apresentado na Figura 6. De qualquer for-
ma, o desenvolvedor poder visualizar
Figura 5. Reconhecimento, priorizao e agendamento da correo de um defeito. os defeitos atribudos a ele diretamente
no Mantis por meio da pgina Minha
Viso. Nesta pgina (Figura 7), so
apresentados e consolidados todos os
defeitos, inclusive os defeitos associados
ao usurio logado no Mantis.
Assim que o desenvolvedor receber
o e-mail notificando que a correo do
defeito foi programada e atribuda a
ele, o prximo passo ser a execuo da
correo propriamente dita.
Dessa forma, to logo a correo seja
finalizada, o desenvolvedor dever re-
portar a correo do defeito por meio do
Mantis. Para tal tarefa, o desenvolvedor
dever mudar a resoluo do defeito para
Corrigido e descrever quais foram as
modificaes necessrias para corrigir o
defeito no campo Anotao, como pode
ser visto na Figura 8.
Por fim, assim que for reportada a
correo do defeito, o testador dever
Figura 6. E-mail enviado pelo Mantis ao desenvolvedor. executar o re-teste. Durante o re-teste, o

64 Engenharia de Software Magazine Gesto de Defeitos

 Verific ao, Validao e Teste

testador poder identificar que o defeito

no foi corrigido corretamente ou foi par-
cialmente corrigido. Neste caso, o defeito
dever ser reaberto e o ciclo de vida do
defeito reiniciado.
Por outro lado, o defeito dever ser
fechado caso ele tenha sido corrigido
corretamente. Para realizar tal tarefa, o
testador dever mudar o status do de-
feito para Fechado e descrever algum
comentrio sobre o fechamento no campo
Anotao, como pode ser visto na Fi-
gura 9. Dessa forma, chegamos ao final
da simulao de um ciclo de vida de um
defeito e a apresentao das principais
funcionalidades do Mantis.

Mtricas e relatrios de gesto Figura 7. Consolidao dos defeitos associados ao usurio logado.
A norma IEEE Std 829-1998 (IEEE Stan-
dard for Software Test Documentation)
define a documentao e relatrios ne-
cessrios para a execuo de um projeto
de teste de software. Dentre os relatrios
sugeridos, existe um relatrio chamado
Relatrio de Incidente de Teste. Este re-
latrio registra e consolida as ocorrncias
que precisam de algum tipo de investi-
gao. Ele normalmente utilizado para
registrar os defeitos encontrados durante
a execuo dos testes.
Ferramentas automatizadas de gesto
de defeitos, tais como o Mantis, geram di-
versos relatrios e grficos com mtricas
que podero fornecer dados para alimen-
tar o Relatrio de Incidente de Teste.
O Mantis, alm de oferecer um relat-
rio com o resumo consolidado de todos
os defeitos relatados (Figura 10), tambm
permite a visualizao de grficos com
as principais mtricas utilizadas na
gesto de defeitos (Figura 11). Na lista-
gem a seguir, so apresentadas diversas
sugestes de indicadores e mtricas de
um processo de gesto de defeitos eficaz,
afinal, voc no pode gerenciar o que
Figura 8. Reporte da correo de um defeito.
voc no pode medir:

Edio 01 Engenharia de Software Magazine 65

 Densidade dos defeitos: Indica o
nmero de defeitos por uma unidade.
normalmente utilizado para identificar
a quantidade de defeitos por cada mil
linhas de cdigo (KLOC);
Taxa de abertura dos defeitos: Utili-
zado para acompanhar o progresso da
execuo dos testes e o nvel da qualidade
do sistema em teste;
Taxa de correo dos defeitos: Utili-
zado para acompanhar e medir a capa-
cidade do time de desenvolvimento de
corrigir os defeitos encontrados;
Taxa de defeitos re-abertos: Utilizado
para acompanhar a qualidade da corre-
o dos defeitos. Pode identificar baixa
qualidade no trabalho dos desenvolve-
dores ou baixa qualidade nos relatos
dos defeitos (o que leva a uma correo
incorreta);
Figura 9. Fechamento de um defeito. Taxa de defeitos abertos agrupados
por testador: Identifica a taxa de abertura
de defeitos por testador. Deve ser anali-
sada em conjunto com outros dados, caso
contrrio, vai privilegiar testadores que
encontram dezenas de defeitos bobos em
detrimento dos testadores que encontram
poucos defeitos (porm so defeitos com-
plexos e difceis de reproduzir);
Taxa de defeitos corrigidos agrupados
por desenvolvedor: Identifica a taxa de
correo dos defeitos por desenvolvedor.
Deve ser analisada em conjunto com ou-
tros dados, caso contrrio, vai privilegiar
desenvolvedores que corrigem dezenas de
defeitos bobos em detrimento dos desen-
volvedores que corrigem poucos defeitos
(porm so defeitos de difcil resoluo);
Severidade por mdulo: Utilizado
para identificar os mdulos que contm
muitos defeitos com severidade alta.
Com base nesses dados, podemos tomar
alguma deciso para identificar a causa
raiz dos problemas e promover alguma
modificao no processo para diminuir
a quantidade de defeitos com severidade
alta no mdulo;

Figura 10. Resumo consolidado de todos os defeitos relatados.
Links
Comparao entre ferramentas de gesto de defeitos
http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems
Website do Mantis
http://www.mantisbt.org
Gauging Software Readiness With Defect Tracking
http://www.stevemcconnell.com/ieeesoftware/bp09.htm
Microsoft Solutions Framework (Zero Bug Bouce e
Bug Convergence)
http://www.microsoft.com/technet/solutionaccelerators/msf/
default.mspx

66 Engenharia de Software Magazine Gesto de Defeitos

 Verific ao, Validao e Teste

Prioridade por mdulo: Identifica

mdulos com alta taxa de defeitos com Open Source Comercial
prioridade alta. Com base nesses dados,
Bugzilla FogBugz
podemos realocar os recursos a fim de
http://www.bugzilla.org/ http://www.fogcreek.com/FogBugz/
atender a demanda. Normalmente
Scarab Jira
analisada em conjunto com a mtrica de
http://scarab.tigris.org/ http://www.atlassian.com/software/jira/
Severidade por mdulo;
BugNET yKAP
Vazamento de defeitos: Utilizada
http://www.bugnetproject.com/ http://www.ykap.com/
para medir a efetividade da abordagem
TRAC Rational ClearQuest
de testes em cada fase de teste (Unidade,
http://trac.edgewall.org/ www.ibm.com/software/awdtools/clearquest/
Integrao, Sistema e Aceitao). Dessa
Tabela 3. Ferramentas de gesto de defeitos alternativas.
forma, podemos identificar que a abor-
dagem e cobertura de testes utilizada na
fase de testes de Sistema no foram mui-
to eficientes em virtude de que muitos
defeitos vazaram e foram encontrados
durante a fase de testes de Aceitao;
Bug Convergence: Identifica o ponto
de declnio da taxa de abertura dos de-
feitos. Este o ponto onde a quantidade
de defeitos abertos tende a ser menor do
que a quantidade de defeitos corrigidos.
Dessa forma, espera-se que a partir desse
ponto a quantidade de defeitos abertos
diminua at chegar a zero;
Zero Bug Bounce: Utilizada para
acompanhar os picos e vales do grfico de
defeitos encontrados a partir do momento
do declnio da taxa de abertura dos de-
feitos (Bug Convergence). Os vales desse
grfico representam os pontos no tempo
onde no existem defeitos conhecidos
com status igual a aberto, ou seja, estes
so os melhores momentos para liberar
o sistema para a prxima fase ou para o
cliente;
Figura 11. Principais mtricas utilizadas na gesto de defeitos.
Concluso
Neste artigo foram apresentados os
conceitos e melhores prticas na gesto
de defeitos. O objetivo principal do artigo
era destacar a importncia da gesto de
defeitos como um processo de apoio ao
desenvolvimento e teste de software. Para
facilitar o entendimento do leitor, foram
demonstrados na prtica os conceitos
discutidos por meio da utilizao do
Mantis (ferramenta Open Source para
gesto de defeitos).
Se o leitor quiser se aprofundar no
assunto, so apresentadas na Tabela
3 algumas das principais ferramentas
comerciais e Open Source para a gesto
de defeitos. No foram esgotadas todas
as opes disponveis, mas j um bom
ponto de partida para auxiliar o leitor
a encontrar a soluo ideal para a sua
necessidade.

Edio 01 Engenharia de Software Magazine 67

 Introduo Inspeo de Software
Aumento da qualidade atravs de verificaes intermedirias
Marcos Kalinowski
mk@kalisoftware.com
Doutorando em Engenharia de Sistemas e
Computao (COPPE/UFRJ). Mestre em En-
genharia de Software (COPPE/UFRJ, 2004).
Bacharel em Cincias da Computao (UFRJ,
2001). Diretor executivo e instrutor da Kali
Software (www.kalisoftware.com), empresa
de consultoria e treinamento em Engenharia
de Software. Professor e pesquisador do curso
de Cincia da Computao do Centro Univer-
sitrio Metodista Bennett, ministrando disci-
plinas de Engenharia de Software. Consultor
para implementao e avaliao do MPS.BR custo do retrabalho para correo de
tendo colaborado na elaborao do guia geral
e do guia de implementao deste modelo.
Rodrigo Oliveira Spnola
rodrigo@sqlmagazine.com.br
Doutorando em Engenharia de Sistemas e
Computao (COPPE/UFRJ). Mestre em En-
genharia de Software (COPPE/UFRJ, 2004).
Bacharel em Cincias da Computao (UNI-
FACS, 2001). Colaborador da Kali Software
(www.kalisoftware.com), tendo ministrado
cursos na rea de Qualidade de Produtos e
Processos de Software, Requisitos e Desen-
volvimento Orientado a Objetos. Consultor
para implementao do MPS.BR. Atua como
Gerente de Projeto em projetos de consulto-
ria na COPPE/UFRJ. colaborador da Enge-
nharia de Software Magazine.
68 Engenharia de Software Magazine Introduo Inspeo de Software
N
a engenharia de software, assim roso e bem definido. A Figura 1 ilustra a
como em outras disciplinas de possibilidade de se realizar inspees nos
engenharia, necessrio consi- diferentes artefatos de software.
derar variveis como esforo, produtivi- De forma resumida, o processo tradicio-
dade, tempo e custo de desenvolvimento. nal de inspeo envolve o planejamento
Essas variveis so afetadas negativa- da inspeo, indivduos revisando um
mente quando artefatos defeituosos so determinado artefato, um encontro em
produzidos, devido ao retrabalho para equipe para discutir e registrar os de-
corrigir defeitos. Sabe-se, ainda, que o feitos, a passagem dos defeitos para o
autor do artefato para que possam ser
defeitos aumenta na medida em que o corrigidos e uma avaliao final sobre a
processo de desenvolvimento progride. necessidade de uma nova inspeo.
Desta forma, iniciativas devem ser reali- A importncia de inspees na reduo
zadas no sentido de encontrar e corrigir do retrabalho e na garantia da qualidade
defeitos to logo sejam introduzidos. Uma de software est bem documentada na
abordagem que tem se mostrado eficiente literatura e discutida em maiores neste
e de baixo custo para encontrar defeitos, artigo. A seo seguinte apresenta a
reduzindo o retrabalho e melhorando a definio de alguns conceitos utilizados
qualidade dos produtos a reviso dos ao longo deste trabalho. Veremos ainda
artefatos produzidos ao longo do processo neste artigo alguns benefcios de se rea-
de desenvolvimento de software. lizar inspees em artefatos produzidos
Inspeo de software um tipo parti- ao longo do processo de desenvolvimento
cular de reviso que pode ser aplicado a de software so descritos; conceitos
todos os artefatos de software e possui sobre tcnicas de leitura para deteco
um processo de deteco de defeitos rigo- de defeitos em artefatos de software;
 Verific ao, Validao e Teste

o processo de inspeo de software e
suas caractersticas, e; o estado atual da
utilizao de inspees na prtica e do
suporte ferramental existente.
Definio dos Conceitos
O termo defeito muitas vezes utilizado
de forma genrica. No entanto, importante
ter em mente que sua interpretao depen-
der do contexto em que ele for utilizado.
Defeitos encontrados atravs de revises
estaro relacionados s faltas no artefato
sendo revisado. Quando um defeito se
manifesta atravs de atividades de teste,
por sua vez, estaremos lidando com uma
falha no software. Estas definies seguem
a terminologia padro para Engenharia de
Software do IEEE (IEEE 610.12, 1990):
Erro: um defeito cometido por
um indivduo ao tentar entender uma
determinada informao, resolver um
problema ou utilizar um mtodo ou uma
ferramenta.
Defeito (ou Falta): uma manifes-
tao concreta de um erro num artefato
de software. Um erro pode resultar em
diversos defeitos.
Falha: o comportamento operacio-
nal do software diferente do esperado
pelo usurio. Uma falha pode ter sido
causada por diversas faltas e algumas
faltas podem nunca causar uma falha.
tos constituiria um tipo de defeito. Assim,
a seguinte taxonomia foi definida:
Omisso: (1) Algum requisito im-
portante relacionado funcionalidade,
ao desempenho, s restries de projeto,
ao atributo, ou interface externa no foi
includo; (2) no est definida a resposta
do software para todas as possveis si-
tuaes de entrada de dados; (3) faltam
sees na especificao de requisitos; (4)
faltam referncias de figuras, tabelas, e
diagramas; (5) falta definio de termos
e unidades de medidas.
Ambigidade: Um requisito tem
vrias interpretaes devido a diferentes
termos utilizados para uma mesma ca-
racterstica ou vrios significados de um
termo para um contexto em particular.
Inconsistncia: Dois ou mais requi-
sitos so conflitantes.
Fato Incorreto: Um requisito des-
creve um fato que no verdadeiro,
considerando as condies solicitas para
o sistema.
Informao Estranha: As informa-
es fornecidas no requisito no so
necessrias ou mesmo usadas.
Outros: Outros defeitos como a inclu-
so de um requisito numa seo errada
do documento.
importante ressaltar que estas classes
genricas de defeitos podem ser dividi-
das em classes mais especficas, depen-
dendo da necessidade. Alm disto, esta
classificao no pretende ser definitiva
e cada organizao pode acrescentar
mais tipos de defeito de acordo com suas
necessidades.
Benefcios da Aplicao de
Inspees de Software
Esforo, Produtividade, Tempo e Custo
O esforo gasto por organizaes de
software com retrabalho pode variar em
mdia entre 40% e 50% do esforo total
do desenvolvimento de um projeto. Uma
estimativa da distribuio do retrabalho
pelas atividades de desenvolvimento de
software est ilustrada na Figura 2.
Analisando a Figura 2, possvel veri-
ficar que o retrabalho tende a aumentar
na medida em que o desenvolvimento
progride. Uma das razes para isto o
aumento no esforo para corrigir defei-
tos nas atividades finais do processo de
desenvolvimento. Atravs da anlise de
63 projetos, BOEHM (1981) apresenta o
custo relativo da correo de defeitos
encontrados em cada uma das atividades
de desenvolvimento (Figura 3).

Em alguns momentos o termo discre-

pncia ser utilizado. Este termo refere-
se a um suposto defeito encontrado. No
nosso contexto, uma discrepncia poder
ser considerada um defeito de fato ou um
chamado falso positivo. Figura 1. Inspees de Software nos Diferentes Artefatos. Adaptado de (ACKERMAN et al., 1989)
Para obter uma classificao para os
defeitos encontrados nas revises (as
faltas), partimos do fato de que todos os
artefatos gerados durante o desenvolvi-
mento de software utilizam como base
o documento de requisitos ou artefatos
gerados a partir deste. Desta forma, as
classes de defeito seriam os tipos de
defeito presentes em documentos de
requisitos acrescidos dos tipos de defei-
tos introduzidos pela transformao de
artefatos ao longo do desenvolvimento
de software.
Um padro IEEE (IEEE 830, 1998), que
recomenda prticas para especificao
de requisitos de software, define atribu-
tos de qualidade que um documento de
requisitos deve possuir. Foi considerado Figura 2. Distribuio do retrabalho pelas atividades de desenvolvimento de
que a falta de qualquer um destes atribu- software. Adaptado de (WHEELER et al., 1996).

Edio 01 Engenharia de Software Magazine 69

 Assim, um dos maiores benefcios de
se utilizar inspees de software a
deteco de defeitos nas fases iniciais
do processo de desenvolvimento de
software, facilitando a correo destes
defeitos com menor esforo e custo. Desta
forma, de acordo com (JONES, 1991), o
esforo com retrabalho reduzido em
mdia para 10% a 20% do esforo total
de desenvolvimento. Esta reduo no
retrabalho pode implicar em melhorias
significativas para a produtividade de
software. De acordo com (BOEHM et
al., 2000) a maior reduo de esforo
gerada pela melhoria de (1) maturidade
de processos de software, (2) arquitetu-
ras de software e (3) gerncia de riscos
proveniente da reduo do retrabalho.
Resultados experimentais mostram como
este benefcio pode afetar as variveis
esforo, produtividade, tempo e custo,
mencionadas na seo anterior:
Esforo. O departamento de desenvol-
vimento da Ericsson em Oslo, Noruega,
calculou uma reduo bruta do esforo
total de desenvolvimento em 20% apli-
cando inspees. Alm disto, resultados
de estudos mostram que a introduo
de inspees de projeto pode reduzir o
esforo com retrabalho em 44%.
Produtividade. De acordo com (GILB
e GRAHAM, 1993), inspees aumentam
a produtividade de 30% a 50%;
Tempo. De acordo com (GILB e
GRAHAM, 1993), inspees reduzem o
tempo de desenvolvimento de 10% a 30%;
Custo. Resultados de estudos mostram
que a introduo de inspees de cdigo
pode reduzir os custos de implementao
de projetos em 39%.
Uma estimativa de (WHEELER et al.,
1996) sobre o custo de desenvolvimento
Figura 3. Custo relativo para corrigir um defeito. Adaptado de (BOEHM, 1981).
70 Engenharia de Software Magazine Introduo Inspeo de Software
quando inspees so aplicadas, quando
comparado ao desenvolvimento sem uti-
lizar inspees, se encontra na Figura 4.
Esta estimativa representa bem os benef-
cios apresentados nesta seo. possvel
observar que utilizando inspees se
obtm um aumento na produtividade,
j que projetos so concludos em menos
tempo e envolvem menos gastos.
Qualidade de Software
De acordo com Pressman (2001), quali-
dade de software a conformidade a: (1)
requisitos funcionais e no funcionais
que tm sido explicitamente declarados,
(2) padres de desenvolvimento que te-
nham sido claramente documentados e
(3) caractersticas implicitamente espera-
das de todo software a ser desenvolvido.
De forma resumida, qualidade consiste
de um conjunto de requisitos e de um
produto ou servio que esteja em confor-
midade com estes requisitos e, por esta
razo, atenda completamente s neces-
sidades dos clientes. Entre as atividades
que podem ser utilizadas para verificar a
qualidade de software se encontram:
Revises de software;
Testes;
Padres e procedimentos formais;
Controle de mudanas;
Mtricas de software;
Procedimentos para coleo e disse-
minao de informaes.
A importncia das revises na garantia
da qualidade destacada pelo modelo
CMMI, que exige a realizao de revi-
ses como uma prtica especfica do
processo de verificao. Sabe-se ainda
que inspees de software, em particular,
capturam em torno de 60% dos defeitos
de artefatos (BOEHM e BASILI, 2001) o
Figura 4. Estimativa dos gastos de desenvolvimento utilizando e no
utilizando inspees. Adaptado de (WHEELER et al., 1996).
que deixa explcita a sua contribuio
para a melhoria da qualidade.
Uma outra maneira de detectar defeitos
em artefatos atravs da aplicao de
testes. No entanto, a aplicao de testes
descobre apenas sintomas de problemas e,
desta forma, pode ocasionar um trabalho
refinado e custoso para detectar o defeito
que causou o sintoma. BOEHM e BASILI
(2001) ressaltam ainda que inspees e
testes capturam diferentes tipos de defeito
e em diferentes momentos do processo de
desenvolvimento de software.
Portanto, interessante aplicar tanto
inspees quanto testes para detectar
defeitos em artefatos de software.
Alm disto, precedendo os testes com as
inspees, defeitos podem ser removidos
nas fases iniciais do processo de desen-
volvimento e os desenvolvedores tero
uma viso mais ampla da complexidade
do sistema. Esta viso os deixa mais bem
preparados para o momento em que se
confrontam com esta complexidade e com
os defeitos que podem possivelmente
surgir durante os testes.
Outros Benefcios
A aplicao de inspees de forma bem
planejada pode trazer diversos outros
benefcios:
Aprendizado. Inspetores experientes
podem tentar detectar padres de como
os defeitos ocorrem e definir diretrizes
que ajudem na deteco destes. Alm
disto, bons padres de desenvolvimento
podem ser observados durante a inspe-
o, sendo possvel sua descrio como
melhores prticas para a organizao.
Integrao entre processos de deteco
e de preveno de defeitos. Saber onde e
quando os defeitos ocorrem pode ajudar
a estabelecer planos de contingncia que
 Verific ao, Validao e Teste

evitem a sua ocorrncia. inspeo continue no prximo dia. SAUER et al., (2000) propuseram uma
Produtos mais inteligveis. Os auto- Retrabalho. O autor corrige os defeitos reorganizao do processo tradicional
res dos diversos artefatos, sabendo que encontrados pelos inspetores e confirma- de inspeo. Essa reorganizao visa
estes sero inspecionados, passaro a dos pelo moderador. a adequao do processo tradicional a
produzir artefatos de uma forma que sua Continuao. O material corrigido inspees com reunies assncronas e
compreenso seja facilitada. A produo pelos autores repassado para o mode- equipes geograficamente distribudas.
de artefatos mais inteligveis, alm de rador, que faz uma anlise da inspeo Assim, mudanas para reduzir o custo e o
facilitar a inspeo, trar benefcios para como um todo e re-avalia a qualidade do tempo total para a realizao deste tipo de
as fases seguintes do processo de desen- artefato inspecionado. Ele tem a liberda- inspeo foram introduzidas. Este projeto
volvimento, incluindo principalmente a de de decidir se uma nova inspeo deve alternativo para inspees de software
fase de manuteno. ocorrer ou no. mantm a estrutura rgida e os aspectos
Dados defeituosos ajudam a melhorar o colaborativos do processo tradicional e
processo de software do projeto. Analisando A forma como estas atividades se re- consiste basicamente em substituir as
a causa dos defeitos encontrados possvel lacionam no processo de inspeo est atividades de preparao e de reunio do
fazer ajustes no processo para evitar a ocor- ilustrada na Figura 5. Note que a ativi- processo tradicional por trs novas ativi-
rncia de defeitos deste mesmo tipo. dade de apresentao, opcional, no est dades seqenciais: deteco de defeitos,
representada na figura. coleo de defeitos e discriminao de
O Processo de Inspeo de Software Entre as caractersticas deste processo, defeitos. Estas atividades podem ser des-
FAGAN (1976) desenvolveu o processo temos que ele pode ser aplicado a todos critas da seguinte forma:
tradicional de inspeo de software, os artefatos produzidos ao longo do Deteco de Defeitos. Cada um dos
uma forma detalhada de se realizar uma processo de desenvolvimento, permi- inspetores selecionados pelo moderador
reviso. Neste processo, existem seis tindo a utilizao de tcnicas de leitura no planejamento realizar uma atividade
atividades principais: de artefatos especficos na atividade de de deteco de defeitos. A principal tarefa
Planejamento. Um usurio, desem- preparao individual. Alm disto, ele desta atividade consiste em buscar defeitos
penhando o papel de moderador da possui uma estrutura rgida, com aspec- no documento a ser inspecionado e assim
inspeo, define o contexto da inspeo tos colaborativos, onde papis, atividades produzir uma lista de discrepncias.
(descrio da inspeo, tcnica a ser utili- e os relacionamentos entre atividades Coleo de Defeitos. O moderador
zada na deteco de defeitos, documento esto bem definidos. agrupa as listas de discrepncias dos ins-
a ser inspecionado, autor do documento, petores. Esta atividade envolve eliminar
entre outros), seleciona os inspetores e A Reorganizao do Processo discrepncias repetidas (encontradas por
distribui o material a ser inspecionado. de Inspeo mais de um inspetor), mantendo s um
Apresentao. Os autores dos artefatos Baseados em diversos estudos expe- registro para cada discrepncia.
a serem inspecionados apresentam as rimentais sobre inspees de software Discriminao de Defeitos. O modera-
caractersticas destes. Esta fase pode ser
omitida se os inspetores possuem conhe-
cimento sobre o projeto e os artefatos que
devem ser inspecionados.
Preparao. Os inspetores estudam
os artefatos individualmente, e even-
tualmente fazem anotaes sobre estes
produzindo uma lista de discrepncias.
O fornecimento de tcnicas de leitura
pode facilitar a execuo desta tarefa.
Reunio. Uma reunio em equipe
ocorre, envolvendo o moderador, os
inspetores e os autores do documento.
Discrepncias so discutidas, e classi-
ficadas como defeito ou falso positivos.
A deciso final sobre a classificao de
uma discrepncia sendo discutida
do moderador. A soluo dos defeitos
no discutida durante a reunio, que
no deve exceder duas horas, uma vez
que aps este tempo a concentrao e
a capacidade de anlise dos inspetores
costuma reduzir drasticamente. No caso
em que uma reunio precisar de mais de
duas horas, sugerido que o trabalho de Figura 5. Processo de inspeo de software, conforme definido em (adaptado de FAGAN, 1976).

Edio 01 Engenharia de Software Magazine 71

dor, o autor do documento e os inspetores
discutem as discrepncias de forma
assncrona. Durante esta discusso, al-
gumas discrepncias sero classificadas
como falso positivo e outras como defeito.
Os falso positivos sero descartados e os
defeitos sero registrados em uma lista
de defeitos, que ento ser passada para o
autor para que a correo possa ocorrer.
A forma como as atividades se rela-
cionam na reorganizao do processo
de inspeo de SAUER et al. (2000) est
ilustrada na Figura 6.
Este processo permite a utilizao de
um nmero grande de inspetores em pa-
ralelo para a deteco de defeitos e, assim,
aumentar a probabilidade de se encontrar
defeitos difceis de serem encontrados. Um
grande nmero de inspetores tem um efei-
to no custo, mas no no tempo de deteco
de defeitos e no implicar em problemas
Figura 6. Reorganizao do processo de inspeo, adaptada de (SAUER et al., 2000).
Figura 7. Distribuio do Uso de Inspeo nos Diferentes Artefatos. Adaptado de
(LAITENBERGER e DEBAUD, 2000).
72 Engenharia de Software Magazine Introduo Inspeo de Software
de coordenao, afinal discrepncias
encontradas por mais de um inspetor
so encaminhadas diretamente para a
atividade de retrabalho e as discrepncias
encontradas por apenas um inspetor no
precisam ser discutidas necessariamente
por todos os inspetores.
Estado Atual: Prtica de Revises
em Organizaes de Software e
Suporte Ferramental Existente
Ao longo dos anos, muito conhecimento
tem sido produzido na rea de inspees de
software. Incluindo variantes do processo
tradicional de inspeo, tcnicas de estima-
tiva do nmero de defeitos de documentos
e da cobertura de inspees, tcnicas de
leitura de documentos visando aumentar
o nmero de defeitos encontrados por ins-
petores, diretrizes para pontos de tomada
de deciso do processo de inspeo, dentre
outras. Parte deste conhecimento tem sido
Figura 8. Cobertura de defeitos estimada para as organizaes
participantes do survey. Adaptado de (CIOLKOWSKI et al., 2003).
avaliado em estudos experimentais e se
mostrado adequado.
No entanto, muito deste conhecimento
no tem sido utilizado na prtica por or-
ganizaes de software ao realizarem suas
inspees, e negligenciado na maioria
das propostas de apoio ferramental ao
processo de inspeo de software.
Esta seo apresenta o estado da prtica
de revises de software e o ferramental
de apoio atualmente existente.
Prtica de Revises em Organizaes
de Software
Em um artigo comparando as diversas
abordagens sobre inspees de software
encontradas na literatura, LAITENBER-
GER e DEBAUD (2000) mostraram que,
conforme representado na Figura 7, ins-
pees em cdigo so as mais comuns.
No entanto, sabe-se que os benefcios de
inspees so maiores para os artefatos
produzidos no incio do ciclo de desen-
volvimento. importante destacar aqui
que estas informaes podem no refletir
o estado atual de desenvolvimento de
software, estamos em 2008.
Um survey foi realizado em 2002 visan-
do avaliar o estado da prtica de revises
de software (CIOLKOWSKI et al., 2003).
De acordo com seus resultados, embora
muitas organizaes de software reali-
zem revises, a forma como as revises
so realizadas ainda pouco sistema-
tizada, pouco conhecimento da rea
de inspees de software utilizado e
assim o verdadeiro potencial das revises
raramente explorado. Este argumento
baseado em trs observaes sobre as
organizaes participantes do survey:
(1) Revises raramente cobrem siste-
maticamente as fases de desenvolvimento
de software. Cerca de 40% das organiza-
es responderam realizar inspees em

requisitos e 30% inspees em cdigo.
(2) Muitas vezes a atividade de deteco
de defeitos no realizada sistematica-
mente. Cerca de 60% das organizaes
responderam no conduzir uma atividade
de deteco de defeitos regularmente.
(3) Organizaes raramente utilizam
revises de software no contexto de um
programa sistemtico de avaliao e
melhoria do processo. Mais da metade
das empresas participantes do survey
respondeu no coletar dados (40%) ou co-
letar dados e no os utilizar para realizar
uma anlise (18%).
A utilizao pouco sistematizada de
revises na prtica tem sido um fator de
confuso entre os resultados esperados
e os obtidos atravs de sua aplicao. A
Figura 8 ilustra a cobertura de defeitos
estimada das revises realizadas pelas
organizaes participantes do survey.
Visando apoiar a realizao de revises
na prtica de forma mais sistemtica
foram elaboradas propostas de apoio fer-
ramental. Algumas destas propostas se
encontram descritas na sesso seguinte.
Ferramentas de Apoio ao Processo de
Inspeo
Entre as ferramentas que apiam a
coordenao e as diversas atividades
do processo de inspeo que tem sido
efetivamente avaliadas e utilizadas re-
centemente na indstria de software des-
tacamos as seguintes: GRIP (GRoupware
supported Inspection Process), IBIS (In-
ternet Based Inspection System) e ISPIS
(Infra-estrutura de Suporte ao Processo
de Inspeo de Software). Esta ltima
sendo tecnologia nacional desenvolvida
na COPPE/UFRJ, em processo de regis-
tro junto ao INPI. Uma descrio destas
ferramentas se encontra a seguir:
GRIP (Grnbacher et al., 2003). Nasceu
da iniciativa de se adaptar um sistema
COTS (Comercial Off The Shelf) de apoio
a trabalho colaborativo (GSS) (Groupware
Support System) para realizar inspees
em requisitos de software. Assim, GRIP
fornece um framework e ferramentas co-
laborativas para a realizao de inspees
assncronas com equipes geograficamente
distribudas. GRIP fornece suporte a
um processo prprio de inspeo que
envolve quatro atividades: planejamento,
inspeo individual, reunio assncrona,
e avaliao da inspeo. A ferramenta
Verific ao, Validao e Teste
no fornece apoio a tcnicas especficas
de deteco de defeitos, apenas ad-hoc.
Uma taxonomia fornecida junto com o
artefato a ser inspecionado. Os elementos
desta taxonomia representam, de forma
hierrquica, os tpicos abordados no arte-
fato a ser inspecionado. As discrepncias
dos inspetores so ento agrupadas de
acordo com os elementos da taxonomia.
Assim, uma discrepncia na descrio do
caso de uso Mantendo Usurio poderia ser
adicionada utilizando a seguinte navega-
o pela taxonomia: Requisitos Funcionais
> Casos de Uso > Mantendo Usurio >
Descrio. Os artefatos em si so lidos na
ferramenta mais conveniente ao inspetor.
Desta forma, GRIP capaz de lidar com
diferentes tipos de artefato, bastando que
uma taxonomia para o artefato seja criada
descrevendo sua estrutura. Na reunio
GRIP fornece apoio para a classificao
das discrepncias que de acordo com um
estudo experimental, mostrou reduzir o
esforo da reunio e apoiar a classificao
correta de discrepncias;
IBIS (LANUBILE et al., 2003). Utiliza
a web em conjunto com notificaes por
e-mail para apoiar inspees assncronas
com equipes geograficamente distribu-
das. IBIS visa explicitamente apoiar a
reorganizao do processo de inspeo
proposta em SAUER et al. (2000) e permi-
tir a sua realizao de forma sistematiza-
da. IBIS no limita o tipo de artefato a ser
inspecionado e na deteco de defeitos
atualmente permite apenas a utilizao
Figura 9. Apoio de IBIS ao registro de discrepncias na atividade de deteco de
defeitos (LANUBILE et al., 2003).
Edio 01 Engenharia de Software Magazine
das tcnicas ad-hoc e de checklists. Na
reunio de inspeo desta proposta as
discrepncias encontradas na deteco
de defeitos so tratadas como tpicos
de discusso, onde mensagens podem
ser acrescentadas e o moderador pode
realizar a classificao das discrepncias
como defeito ou falso positivo. IBIS no
fornece apoio aos pontos de tomada de
deciso do processo de inspeo, sendo as
atividades de planejamento e de continu-
ao do processo tratadas como simples
cadastros, sem apoio para a realizao
de suas tarefas. IBIS tem sido utilizada
em estudos experimentais recentes para
obter conhecimento na rea de inspees
de software e para avaliar aspectos da
reorganizao do processo de inspeo. A
Figura 9 ilustra o apoio de IBIS ao registro
de discrepncias na atividade de deteco
de defeitos utilizando um checklist.
ISPIS (KALINOWSKI e TRAVASSOS,
2004). Esta ferramenta tambm visa
apoiar a reorganizao do processo de
inspeo proposta em SAUER et al. (2000).
Entretanto, ISPIS foi desenvolvida utili-
zando uma metodologia experimental,
levando em considerao conhecimento a
respeito de inspees de software selecio-
nado criteriosamente, dando preferncia
a conhecimento efetivamente avaliado.
ISPIS a nica ferramenta que possibilita
o uso automatizado deste conhecimento
sem que a equipe de inspeo precise
adquiri-lo atravs de revises bibliogr-
ficas e aplic-lo manualmente. Assim, os
73
pontos de tomada de deciso do processo
so apoiados por resultados de tcnicas
de estimativa e dados quantitativos
representando a realidade da prpria
organizao. ISPIS pode ser utilizada
para coordenar e apoiar a inspeo de
qualquer tipo de artefato de software
(documentos de requisitos, de projeto,
cdigo, etc) e, opcionalmente, faz uso de
um mecanismo de integrao para se co-
municar com ferramentas de deteco de
defeitos existentes para artefatos especfi-
cos. Outra caracterstica da ferramenta
permitir reunies de inspeo tanto sn-
cronas quanto assncronas. As inspees
com reunies assncronas se adequam ao Figura 10. Telas do apoio de ISPIS ao planejamento de uma inspeo de software (KALINOWSKI et al., 2004).
contexto de desenvolvimento global de
software. Assim, ISPIS pde, por exem- Referncias
plo, ser utilizada com sucesso em inspe-
ACKERMAN, A., BUCHWALD, L., LEWSKI, F., 1989,Software Inspections: An Effective Verification Process,IEEE Software, vol. 6, no. 3, pp.31-37.
es com participantes distribudos entre
Rio de Janeiro, Nova Iorque e Londres. A KALINOWSKI, M., SPNOLA, R.O., TRAVASSOS, G.H., Infra-Estrutura Computacional para Apoio ao Processo de Inspeo de Software. No:
ferramenta tem ainda sido utilizada para Simpsio Brasileiro de Qualidade de Software, 2004, Braslia.
a realizao de projetos na indstria. Por BOEHM, B. W., BASILI, V.R., 2001,Software Defect Reduction Top 10 List., IEEE Computer 34 (1): 135-137.
representar o estado da arte a respeito de BOEHM, B.W., ABTS, C., BROWN, A.W., CHULANI, S., CLARK, B.K., HOROWITZ, E., MADACHY, R., REIFER, D., STEECE, B., 2000, Software Cost
inspees de software, ISPIS resultou em Estimation with COCOMO II, Prentice Hall.
artigos cientficos em conferncias reno- BOEHM, B.W., 1981, Software Engineering Economics, Prentice Hall.
madas. Sua aplicabilidade na indstria CIOLKOWSKI, M., LAITENBERGER, O., BIFFL, S., 2003,Software Reviews: The State of the Practice, IEEE Software 20 (6): 46-51.
permitiu ainda publicaes sob forma FAGAN, M.E., 1976,Design and Code Inspection to Reduce Errors in Program Development,IBM Systems Journal, vol. 15, no. 3, pp. 182-211.
de relatos de experincia. A Figura 10 GILB, T., GRAHAM, D., 1993,Software Inspection, Addison-Wesley.
ilustra algumas telas do apoio de ISPIS
Grnbacher, P., Halling, M., Biffl, S.,An Empirical Study on Groupware Support for Software Inspection Meetings, Proceedings of the
atividade de planejamento.
18th IEEE International Conference on Automated Software Engineering, 2003.
JONES, C., 1991,Applied Software Measurement, McGraw Hill.
Concluso
O objetivo de inspees de software Kalinowski, M., Travassos, G. H., A Computational Framework for Supporting Software Inspections, In: 19th IEEE International
melhorar a qualidade de artefatos de sof- Conference on Automated Software Engineering - ASE'04, pp. 46-55, Linz, Austria, 2004.
tware atravs de sua anlise, detectando LAITENBERGER, O., ATKINSON, C., 1999,Generalized Perspective Based Inspection to handle Object Oriented Development Artifacts,
e removendo defeitos antes que o artefato Proceedings of ICSE 99, p.494-503, Los Angeles, CA, USA.
seja passado para a prxima fase do pro- Lanubile, F., Mallardo, T., CALEFATO, F., 2003, Tool support for Geographically Dispersed Inspection Teams, Software Process
cesso de desenvolvimento de software. Improvement and Practice, 2003, 8: 217-231 (DOI: 10.1002/spip.184).
Conforme visto neste artigo, a aplicao PRESSMAN, R.S., 2001, Software Engineering: A Practitioners Approach, Fifth Edition, McGraw Hill.
de inspees entre as atividades do ciclo SAUER, C., JEFFERY, D.R., LAND, L., YETTON, P., 2000, The Effecticveness of Software Development Technical Review: A Behaviorally
de vida de software pode trazer diversos Motivated Program of Research, IEEE Transactions on Software Engineering, 26 (1): 1-14, January.
benefcios para organizaes de software.
WHEELER, D.A., BRYKEZYNSKI, B., MEESON, R.N., 1996, Software Inspections: An Industry Best Practice, IEEE Computer Society.
O processo de inspeo foi inicialmente
elaborado por FAGAN (1976). Argumen-
tos da literatura e estudos experimen-
tais, visando avaliar este processo, vm sistematizada e pouco conhecimento COPPE/UFRJ. no contexto da disserta-
indicando reunies assncronas para da rea de inspees de software uti- o de mestrado do Marcos Kalinowski
inspees de software. Tendo em vista lizado. Assim o verdadeiro potencial (um dos autores deste artigo).
as inspees com reunies assncronas das revises raramente explorado,
SAUER et al., (2000), baseados em estudos introduzindo um fator de confuso entre Reconhecimento
experimentais, apresentam uma reorga- os resultados esperados pelas revises e Aos pesquisadores Forrest Shull, Gui-
nizao com mudanas para reduzir o os obtidos na prtica. Visando enderear lherme Horta Travassos e Jeffrey Carver
custo e o tempo total da realizao deste este problema e permitir a realizao de por suas contribuies acadmicas para
tipo particular de inspeo. inspees mais sistemticas algumas a rea de inspees de software, fun-
Atualmente muitas organizaes re- propostas de apoio ferramental surgi- damentais para a elaborao da tese de
alizam revises, mas a forma como as ram. Entre estas propostas destacamos mestrado que, entre outros, rene os co-
revises so realizadas ainda pouco a infra-estrutura ISPIS, desenvolvida na nhecimentos discorridos neste artigo.

74 Engenharia de Software Magazine Introduo Inspeo de Software