Teste de Software 15

16
.Net Magazine - Quick Update
Conhecimento
faz diferena!
Capa ESM - Final .pdf
19.02.08
18:15:13
magazine
Engenharia de Software
Saiba seu significado e para que serve
00003
9 771983 127008
ISSN 1983127-7
Edio Especial
Entenda os principais conceitos sobre

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

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

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

anlise de risco e conformidade
Veja como integrar conceitos de

Modelos Tradicionais e geis
Veja como integrar o Processo

Unificado ao desenvolvimento Web
Mais de 60 mil downloads

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

Faa um up grade em sua carreira.
Em um mercado cada vez mais focado em qualidade ter conhecimentos aprofundados sobre requisitos, metodologia, anlises,
testes, entre outros, pode ser a diferena entre conquistar ou no uma boa posio profissional. Sabendo disso a DevMedia
lana para os desenvolvedores brasileiros sua primeira revista digital totalmente especializada em Engenharia de Software.
Todos os meses voc ir encontrar artigos sobre Metodologias Ageis; Metodologias tradicionais (document driven);
ALM (application lifecycle management); SOA (aplicaes orientadas a servicos); Analise de sistemas; modelagem; Mtricas;
orientao objetos; UML; testes e muito mais. Assine j!
EDITORIAL
Ano 2 - 15 Edio 2009
Impresso no Brasil
Corpo Editorial
Colaboradores
Rodrigo Oliveira Spnola
rodrigo@sqlmagazine.com.br
Marco Antnio Pereira Arajo
Eduardo Oliveira Spnola
Diagramao
Gabriela de Freitas - gabrieladefreitas@gmail.com
Capa
Romulo Araujo - romulo@devmedia.com.br
Na Web
www.devmedia.com.br/esmag
Apoio
Parceiros:
Um importante fator de sucesso de um software sua qualidade.

Existem diversas maneiras de se avaliar a qualidade de um produto,
uma dessas maneiras a realizao de atividades de testes de software por uma equipe especializada no assunto. Neste contexto, a
Engenharia de Software Magazine destaca nesta edio trs matrias muito interessantes que abordam o tema.
Testes de Software, um processo criativo: Este artigo aborda o tema
processo de testes de software mostrando uma maneira de agrupar
as atividades de testes em etapas, com objetivos bem definidos. Ele
mostra que a organizao das atividades pode ter um impacto positivo significativo na qualidade do produto gerado, e que muito mais
do que burocracia preciso criatividade para um bom desempenho
de tais atividades.
Manuteno: Desafios para os Testes numa Fbrica de Software:
Neste artigo sero apresentadas dicas e sugestes para superar os
principais desafios e entraves associados s atividades de testes na
manuteno de softwares em um ambiente de Fbrica de Software.
Plano de Teste - Um Mapa Essencial para Teste de Software:
Este artigo apresenta o plano de teste de software, destacando sua
importncia no processo de desenvolvimento de software, mostrando como elabor-lo e exemplificando os itens que devem compor o
referido documento.
Alm destas matrias, esta edio traz mais cinco artigos:
Priorizao Voltada para Resultados;
Linhas de Produtos de Software;
UML Diagrama de Seqncias;
Incorporando Restries UML;
Governana de Tecnologia de Informao.
Desejamos uma tima leitura!
Equipe Editorial Engenharia de Software Magazine
Rodrigo Oliveira Spnola
Atendimento ao Leitor
A DevMedia conta com um departamento exclusivo para o atendimento ao leitor.
Se voc tiver algum problema no recebimento do seu exemplar ou precisar de
algum esclarecimento sobre assinaturas, exemplares anteriores, endereo de
bancas de jornal, entre outros, entre em contato com:
(rodrigo@sqlmagazine.com.br)
Doutorando em Engenharia de Sistemas e Computao (COPPE/UFRJ). Mestre em
Engenharia de Software (COPPE/UFRJ, 2004). Bacharel em Cincias da Computao
(UNIFACS, 2001). Colaborador da Kali Software (www.kalisoftware.com), tendo ministrado cursos na rea de Qualidade de Produtos e Processos de Software, Requisitos e Desenvolvimento Orientado a Objetos. Consultor para implementao do MPS.
BR. Atua como Gerente de Projeto e Analista de Requisitos em projetos de consultoria
na COPPE/UFRJ. Colaborador da Engenharia de Software Magazine.
Cristiany Queiroz Atendimento ao Leitor

http://www.devmedia.com.br/mancad/
(21) 2220-5375
Kaline Dolabella
Gerente de Marketing e Atendimento
kalined@terra.com.br
(21) 2220-5375
Publicidade
Para informaes sobre veiculao de anncio na revista ou no site entre em
contato com:
Kaline Dolabella
publicidade@devmedia.com.br
Fale com o Editor!

muito importante para a equipe saber o que voc est achando da revista: que tipo de artigo
Marco Antnio Pereira Arajo

(maraujo@devmedia.com.br)
Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ - Linha de
Pesquisa em Engenharia de Software, Especialista em Mtodos Estatsticos Computacionais e
Bacharel em Matemtica com Habilitao em Informtica pela UFJF, Professor e Coordenador
do curso de Bacharelado em Sistemas de Informao do Centro de Ensino Superior de Juiz de
Fora, Professor do curso de Bacharelado em Sistemas de Informao da Faculdade Metodista Granbery, Professor e Diretor do Curso Superior de Tecnologia em Anlise e Desenvolvimento de Sistemas da Fundao Educacional D. Andr Arcoverde, Analista de Sistemas
da Prefeitura de Juiz de Fora, Colaborador da Engenharia de Software Magazine.
voc gostaria de ler, que artigo voc mais gostou e qual artigo voc menos gostou. Fique a
vontade para entrar em contato com os editores e dar a sua sugesto!
Se voc estiver interessado em publicar um artigo na revista ou no site SQL Magazine,
entre em contato com os editores, informando o ttulo e mini-resumo do tema que voc
gostaria de publicar:
Rodrigo Oliveira Spnola - Colaborador
editor@sqlmagazine.com.br
Eduardo Oliveira Spnola

(eduspinola@gmail.com)
Editor das revistas Engenharia de Software Magazine, SQL Magazine, WebMobile.
bacharel em Cincias da Computao pela Universidade Salvador (UNIFACS) onde
atualmente cursa o mestrado em Sistemas e Computao na linha de Engenharia de
Software, sendo membro do GESA (Grupo de Engenharia de Software e Aplicaes).
Caro leitor, para esta edio, temos um conjunto de 5 vdeo aulas. Estas vdeo aulas esto
disponveis para download no Portal da Engenharia de Software Magazine e certamente traro uma significativa contribuio para seu aprendizado. A lista de aulas publicadas
pode ser vista abaixo:
Tipo: Engenharia de Requisitos
Ttulo: Solues Concretas para Problemas Prticos da Engenharia de Requisitos Parte 7
Autor: Rodrigo Oliveira Spnola
Mini-Resumo: Existem diferentes maneiras de estruturar um processo com atividades relacionadas engenharia de requisitos em empresas desenvolvedoras de software. Modelos de
maturidade, como o MPS, podem servir como um arcabouo para a definio deste processo.
Alm disso, fundamental para um processo de engenharia de requisitos que ele seja capaz
de lidar com dificuldades e problemas relacionados a requisitos que possam surgir durante o
desenvolvimento de software na prtica. Uma iniciativa rumo ao levantamento destas dificuldades e problemas e de maneiras de estruturar um processo para lidar com estes problemas
ser apresentada nesta srie de vdeo aulas. Nesta stima aula, sero apresentados problemas
e sugestes de soluo associadas a atividades de verificao e validao de requisitos.
Ttulo: Solues Concretas para Problemas Prticos da Engenharia de Requisitos Parte 8
Mini-Resumo: Existem diferentes maneiras de estruturar um processo com atividades
relacionadas engenharia de requisitos em empresas desenvolvedoras de software. Modelos de maturidade, como o MPS, podem servir como um arcabouo para a definio deste
processo. Alm disso, fundamental para um processo de engenharia de requisitos que ele
seja capaz de lidar com dificuldades e problemas relacionados a requisitos que possam surgir
durante o desenvolvimento de software na prtica. Uma iniciativa rumo ao levantamento
destas dificuldades e problemas e de maneiras de estruturar um processo para lidar com estes
problemas ser apresentada nesta srie de vdeo aulas. Nesta oitava aula, sero apresentados
problemas e sugestes de soluo associadas a atividades de gerenciamento de requisitos.
Ttulo: Concretas para Problemas Prticos da Engenharia de Requisitos Parte 9
Mini-Resumo: Existem diferentes maneiras de estruturar um processo com atividades
relacionadas engenharia de requisitos em empresas desenvolvedoras de software.
Modelos de maturidade, como o MPS, podem servir como um arcabouo para a definio
deste processo. Alm disso, fundamental para um processo de engenharia de requisitos
que ele seja capaz de lidar com dificuldades e problemas relacionados a requisitos que
possam surgir durante o desenvolvimento de software na prtica. Uma iniciativa rumo ao
levantamento destas dificuldades e problemas e de maneiras de estruturar um processo
para lidar com estes problemas ser apresentada nesta srie de vdeo aulas. Nesta nona e
ltima aula desta srie, sero apresentados problemas e sugestes de soluo associadas
a atividades de gerenciamento de requisitos, ferramentas e recursos humanos associados
s atividades da engenharia de requisitos.
Tipo: Projeto
Ttulo: Introduo Matriz de Rastreabilidade Parte 1
Mini-Resumo: pode ser considerado um conceito chave ao longo do desenvolvimento
de projetos de software. Este conceito define que possvel mapear a relao entre os
diferentes elementos elaborados durante o desenvolvimento de software. Esta relao
identificada a partir das transformaes que existem em informaes ao longo do
processo de desenvolvimento e podem ser representadas atravs de rastros em
uma matriz de rastreabilidade. Nesta vdeo aula apresentaremos as definies iniciais
associadas rastreabilidade.
Tipo: Projeto
Ttulo: Introduo Matriz de Rastreabilidade Parte 2
Mini-Resumo: Rastreabilidade pode ser considerado um conceito chave ao longo do
desenvolvimento de projetos de software. Este conceito define que possvel mapear a
relao entre os diferentes elementos elaborados durante o desenvolvimento de software.
Esta relao identificada a partir das transformaes que existem em informaes ao longo
do processo de desenvolvimento e podem ser representadas atravs de rastros em uma
matriz de rastreabilidade. Nesta segunda parte, apresentaremos a importncia do conceito
de rastreabilidade e como ele pode ser aplicado atravs das matrizes de rastreabilidade.
NDICE
08 - Priorizao Voltada para Resultados
Dairton Bassi
14 - Incorporando Restries UML

Thiago Carvalho de Sousa
22 - UML Diagrama de Sequncias

Ana Cristina Melo
30 - Testes de Software, um processo criativo

Melissa Barbosa Pontes
36- Manuteno: Desafios para os Testes numa Fbrica de Software

Daniel Scaldaferri Lages
42 - Plano de Teste
Antonio Mendes da Silva Filho
48 - Linhas de Produtos de Software

Pasqueline Scaico, Alexandre Scaico e Fillipe Loureno da Cunha Lima
55 - Governana de Tecnologia de Informao

Monalessa Perini Barcellos e Alex Sandro Barreto Rodrigues
Engenharia de Software Magazine
6 SQL Magazine
Edio 05 - Engenharia de Software Magazine
Priorizao Voltada para Resultados

De que se trata o artigo?
Dairton Bassi
dbassi@gmail.com
Mestre em Engenharia de Software com

nfase em Mtodos geis pelo IME-USP.
Bacharel em Cincia da Computao pelo
IME-USP. Co-fundador da AgilCoop e criador do Encontro gil (www.encontroagil.
com.br). Especialista em implantao de
metodologias geis. Ministra cursos e palestras sobre mtodos geis. Atuou como
programador, lder de desenvolvimento e
consultor em diversas instituies do setor
pblico e privado.
riorizar significa determinar uma

ordem, que pode ser, por exemplo,
de importncia ou de precedncia. Neste processo, naturalmente alguns
elementos so favorecidos em detrimento de outros.
Na produo de software, decises
erradas na priorizao das funcionalidades ou de mdulos de um projeto
podem causar estouro de oramento,
perda de prazos, retardamento na
gerao de receita, adiamento do uso
do software, falta de foco no desenvolvimento e, em ltima instncia,
cancelamento do projeto.
Historicamente, a indstria de software no tem sido hbil em fazer priorizaes e tem sofrido dos males que essa
deficincia traz: grandes desperdcios de
tempo e de recursos que comprometem
o projeto e, em muitos casos, causam o
seu fracasso.
Uma amostra representativa da indstria de software de pases desenvolvidos foi estudada por Jim Jonhson
em 2002. Ele descobriu que 64% das
Engenharia de Software Magazine - Priorizao Voltada para Resultados
Neste artigo entenderemos os problemas causados

pela falta de priorizao nas funcionalidades durante a implementao de projetos de software e
apresentaremos tcnicas usadas em metodologias
geis para determinar as prioridades de desenvolvimento.
Para que serve?

Com bons critrios de priorizao, a equipe de desenvolvimento ter foco e poder trabalhar unida
para atingir seu objetivo. Alm disso, o produto
em desenvolvimento ter resultados palpveis
mais rapidamente. Isso permitir que ele seja
avaliado mais cedo e aprimorado.
Em que situao o tema til?

A eleio de prioridades adequadas evita inmeros
desperdcios de recursos e de tempo, tornando o projeto mais propenso ao fracasso. A escolha adequada
das funcionalidades que sero implementadas pode
ser determinante para o cumprimento do prazo e dos
custos do projeto e tambm pode antecipar a obteno de verses preliminares do software.
METODOLOGIAS GEIS
funcionalidades implementadas so raramente ou nunca

utilizadas. Este nmero revela que somente cerca de 1/3 do
que foi desenvolvido, de fato, precisava ser feito e, portanto,
dois teros dos recursos e do tempo foram mal empregados.
Ratificando os resultados de Jonhson, em 2007, o PMI Brasil
apontou resultados semelhantes na indstria brasileira. 66%
das empresas do setor de tecnologia tm problemas para cumprir o custo dos projetos e em 82% para cumprir os prazos.
Estes nmeros sinalizam srios problemas relacionados
priorizao. Se as prioridades fossem melhor elegidas, os 64%
de funcionalidades raramente usadas provavelmente no precisariam ser feitas. Com isso, haveria uma grande economia
de recursos, os projetos seriam muito mais simples e, seria
possvel concluir os 34% que tm valor muito mais rpido. Se
isso fosse feito, os problemas com custos e prazos certamente
no seriam gritantes.
H diversas maneiras de fazer a priorizao do desenvolvimento de um software. A escolha de uma delas geralmente
guiada pela filosofia da empresa ou pelas caractersticas do
projeto. Neste artigo apresentamos algumas tcnicas para
determinar as prioridades de desenvolvimento com foco no
valor de negcios trazido por cada funcionalidade. Essas
tcnicas envolvem a equipe de desenvolvimento, mas contam
principalmente com a participao de clientes e tambm de
potenciais usurios.
Quem o responsvel?
muito fcil pensar que os responsveis pela priorizao, ou

pela falta dela, so os gerentes do projeto, que significa que
eles seriam exclusivamente culpados pelos resultados que a
indstria tem apresentado. Esta seria uma anlise parcial
e incorreta da situao. Uma boa priorizao s possvel
quanto o processo de desenvolvimento reserva espao para
que ela acontea. Dado isso, fundamental que os envolvidos
na priorizao conheam o mercado no qual o software ser
inserido e, principalmente, o ponto de vista dos usurios.
Modelos de desenvolvimento com escopo e prazo grandes
e fixos so um dos principais responsveis por problemas de
priorizao. Como nestes modelos todas as funcionalidades
do escopo devem estar prontas no fim do prazo, os envolvidos
no sentem tanta necessidade de priorizar, afinal, a ordem de
implementao no relevante para atender o acordo com o
cliente. Isso faz com que a ordem de desenvolvimento seja
forte e exclusivamente influenciada pelos aspectos tcnicos
do desenvolvimento. Por exemplo, as funcionalidades podem
ser ordenadas de acordo com as tecnologias que elas requerem
em sua implementao, ou conforme o grau de dificuldade de
implementao. Em outros casos, a ordenao das funcionalidades influenciada pela indisponibilidade de alguns recursos
da equipe, como DBAs, designers, etc.
Alm dessas restries desfavorecerem o uso de priorizao
alinhadas com os interesses comerciais, o formato de contrato
que fixa prazo e escopo o preferido por ambas as partes envolvidas na produo do software: clientes e desenvolvedores. Isso
acontece porque tanto clientes como desenvolvedores querem
o contrato pelo mesmo motivo: aumentar a sua segurana.

O comprador quer listar as funcionalidades que ele deseja
para ter uma garantia de que ir receb-las. O desenvolvedor
tambm quer listar as funcionalidades para estabelecer um
limite sobre o tamanho do seu trabalho e de suas responsabilidades. O grande problema deste modelo que o comprador
ir querer incluir o mximo de funcionalidades, pois ele no
sabe precisamente quais ele ir querer ou de fato usar daqui
a alguns meses ou anos. Na dvida, se uma funcionalidade
ser ou no til, melhor inclu-la. E se algum precisar...
Com as funcionalidades e o prazo definidos, todas elas precisam ficar prontas, por isso so tratadas igualmente ou planejadas sob pontos de vista que no refletem as prioridades de
negcio do projeto, criando uma seqncia de implementao
motivada puramente por questes tcnicas. Priorizaes que
consideram somente o ponto de vista tcnico podem implicar,
depois de alguns meses, em uma grande quantidade de cdigo
comercialmente intil. Isso acontece quando funcionalidades
sem valor para os usurios so implementadas no incio do
projeto, enquanto funcionalidades importantes ficam para o
fim, correndo o risco de no serem implementadas caso o projeto atrase ou seja cancelado justamente por falta de resultados.
Quando a ordem importa
Priorizar, basicamente, significa definir uma ordem para que

as funcionalidades sejam implementadas. O estabelecimento
de critrios para orden-las beneficia o desenvolvimento de
diversas maneiras, independente do tipo de processo que se
use. A eleio destes critrios importante para determinar
uma direo para o desenvolvimento e facilitar a definio de
metas intermedirias para a equipe.
Para compor os critrios de priorizao, podem ser usados
vrios tipos de informao. Alguns exemplos so: a opinio
dos usurios, o retorno financeiro ou a dificuldade de implementao. Bons critrios de priorizao consideram mais de
uma informao, como por exemplo, o retorno financeiro e a
dificuldade de implementao. Assim, fatores cruciais para o
sucesso comercial do software (retorno financeiro) so ponderados com variveis que indicam a viabilidade de produo
(dificuldade de implementao).
Em projetos onde preciso conseguir receita para garantir
a sua continuidade, ou para justificar mais investimentos, a
ordem de implementao deve estar alinhada com os interesses comerciais. Neste caso, priorizar pelo retorno financeiro
ou valor agregado so boas opes. Com este critrio de implementao, as funcionalidades mais importantes estaro
prontas rapidamente e, mesmo sem que o produto inteiro esteja
pronto, ser possvel testar e fazer demonstraes que exibem
o potencial do software final.
A apresentao de funcionalidades que tornam o software
capaz de gerar receita muda a percepo que o cliente tem a
respeito do projeto. Seja ele um cliente externo, um investidor
ou nveis superiores da prpria empresa que faz o desenvolvimento, o projeto que era visto como uma fonte de gastos, ou
como um investimento de alto risco, passa a ser tratado como
um ativo valioso. Como conseqncia, a equipe de desenvolvimento tambm passa a ser mais valorizada.
Se a urgncia pelo produto for grande, uma priorizao
voltada para as principais funcionalidades pode criar rapidamente uma verso simplificada, ou beta, do produto.
Dessa forma, as prximas funcionalidades podem ser criadas
enquanto uma verso j gera receita. Isso coloca o projeto em
uma condio auto-sustentvel e a equipe de desenvolvimento em uma situao mais confortvel com relao cobrana
por resultados.
Desenvolvimento iterativo, priorizao iterativa
Modelos de desenvolvimento iterativos tm se mostrado

adequados ao dinamismo com que as regras e as necessidades
do mercado se comportam. Por meio de iteraes e desenvolvimento incremental possvel segmentar a produo de um
grande software e refinar as suas caractersticas desde o incio
do projeto, evitando pagar o alto preo de grandes correes
tardias.
Empresas que usam mtodos geis, como XP ou Scrum, tendem a fazer iteraes curtas com durao de algumas semanas
cada uma. Com isso, possvel rever e ajustar o planejamento,
alm de validar com freqncia o que j foi produzido. Pequenas iteraes tambm ajudam na manuteno das prioridades,
pois com revises peridicas, novas demandas podem ser
consideradas e o desenvolvimento pode se manter sensvel s
oscilaes do mercado.
Periodicidade da Priorizao
O tamanho das iteraes est relacionado com caractersticas

do projeto. Por exemplo, projetos sujeitos a muitas mudanas
devem usar iteraes curtas para evitar que as necessidades
mudem durante a iterao. Por outro lado, se houver dificuldades para conseguir feedback ou uma validao sobre o que
desenvolvido, iteraes maiores so mais adequadas, pois
permitem que haja tempo hbil para a entrega.
Tambm importante que a periodicidade com que as prioridades so revistas mantenha uma relao com o tamanho
das iteraes. O ideal que a periodicidade das prioridades
seja um mltiplo do tamanho da iterao, podendo ocorrer,
por exemplo, junto com o planejamento de cada iterao ou
a cada duas iteraes. Se a periodicidade no estiver sincronizada com as iteraes, o modelo de desenvolvimento
forar mudanas de prioridade enquanto a equipe est no
meio de uma etapa do desenvolvimento. Isso pode criar um
cenrio onde os programadores trabalham para produzir
funcionalidades que deixaram de ser importantes, o que
tornar a equipe pouco confiante e sem motivao para
concluir a iterao.
O Scrum, por exemplo, prev a criao de um backlog com
todas as funcionalidades desejadas, porm, a cada iterao,
uma nova priorizao acontece para a escolha do que ser
implementado no prximo sprint (iterao). Em XP, durante o
planejamento da release costuma-se fazer uma diviso inicial
das funcionalidades em iteraes. Isto facilita a obteno das
10
primeiras estimativas. Nas prximas priorizaes, possvel

fazer permutas entre as funcionalidades medida que novas
prioridades so identificadas. Essas mudanas acontecem no
planejamento da iterao com o consentimento de clientes e
desenvolvedores.
Para os cenrios onde no possvel ter todos os recursos (DBAs, designers, etc.) 100% do tempo, independente
da metodologia, o ideal minimizar a distoro que as
indisponibilidades causam na priorizao. Para fazer isso,
determine a ordem ideal de implementao ignorando as
indisponibilidades e depois tente ajustar o uso dos recursos
para que a priorizao real seja a mais prxima possvel da
priorizao ideal.
Tcnicas de Priorizao
As tcnicas que apresentamos a seguir so fortemente baseadas em interesses de negcios, portanto levam em considerao
o ponto de vista dos clientes e usurios. Os programadores,
apesar de estarem completamente envolvidos com a criao
do software, no devem ter a responsabilidade de determinar
as prioridades de negcio. Estas decises devem ser tomadas
por aqueles que esto envolvidos com questes financeiras e
estratgicas do projeto, como por exemplo, as tticas comerciais
e as aes de marketing.
Opinio do Cliente
Os clientes devem estar altamente envolvidos com o desenvolvimento, pois os programadores, e mesmo o gerente, na
maioria das vezes no so especialistas no domnio de negcios
do software, portanto eles no tm condies de determinar
sozinhos as prioridades do projeto.
Envolver os clientes e colocar as primeiras verses do software em contato com potenciais usurios uma forma de
coletar opinies de pessoas que podero avali-lo pensando
de que maneiras aquele programa ainda em construo pode
se tornar rapidamente mais til e poderoso.
Para coletar as opinies de potenciais usurios, uma reunio pouco formal, no estilo de demonstrao o ideal. Aps
a apresentao das funcionalidades, algumas perguntas
ajudaro a entender os principais interesses dos usurios.
Se o grupo de usurios for grande, cada um pode responder
em uma folha de papel perguntas simples como: Quais
so as prximas trs funcionalidades que voc gostaria que
esse sistema possusse? acompanhada de uma discusso
com o grupo sobre as respostas. Se os usurios j usam um
software e o novo vem para substitu-lo ou para disputar
mercado, a pergunta pode ser: Quais funcionalidades voc
usa com frequncia que este programa ainda no tem?,
e em um momento mais avanado do desenvolvimento a
pergunta seria: Que funcionalidades voc gostaria que o
sistema tivesse para tornar o seu trabalho mais fcil?. Se
os potenciais usurios no possuem qualquer soluo em
software, a pergunta pode ser: O que mais este software
precisa fazer para ser til para voc? ou O que faria voc
usar este software?.
METODOLOGIAS GEIS
Dependendo do processo de desenvolvimento usado, perguntas parecidas com estas podem ter sido feitas em uma
fase inicial do projeto, porm as suas respostas provavelmente
foram usadas para entender as necessidades, mas no para
determinar prioridades. Alm disso, as necessidades podem
ter mudado, esta uma forma de verificar se elas continuam
as mesmas.
Estas reunies de demonstrao podem acontecer periodicamente durante o desenvolvimento do produto. Mensalmente
ou sempre que as maiores prioridades apontadas na reunio
anterior tiverem sido implementadas. Se as demonstraes
acontecerem desde a primeira iterao, o software poder ser
utilizado e avaliado desde o incio, reduzindo a possibilidade
da equipe de desenvolvimento despender tempo em funcionalidades que no agregam valor ao software.
Em geral, aps algumas semanas j possvel fazer a primeira
demonstrao para clientes ou potenciais usurios, mesmo
que o software no tenha todas as funcionalidades ou mesmo
uma interface grfica profissional. Naturalmente, importante
alert-los de antemo de que esta ainda uma verso precoce
que precisa da colaborao e opinio de todos para crescer e
se tornar o produto que desejam.
Priorizao por Valor e Risco
Outra maneira de priorizar considera o valor de negcios
que a funcionalidade traz para o software, que vamos chamar
simplesmente de valor, e a dificuldade de implementao, que
inclui o risco de atraso e as incertezas a respeito da implementao, chamamos essas dificuldades de risco. Esta tcnica
simples e produz um diagrama que pode ser lido facilmente e
oferece uma viso panormica do projeto sob o ponto de vista
das duas variveis consideradas: valor e risco.
O resultado deste exerccio de priorizao ser visto em um
plano cujos eixos so o valor e o risco. Ele pode ser desenhado
em uma lousa, em um quadro branco ou em uma cartolina
sem a necessidade de definir uma escala, basta apenas determinar a direo em que o valor e o risco crescem em seus
respectivos eixos.
Para mensurar o valor e o risco de cada funcionalidade,
a participao de clientes e desenvolvedores essencial. O
cliente determina a quantidade de valor que cada funcionalidade agrega ao produto final e a equipe de desenvolvimento
dimensiona o risco de implementao. Desta forma, cada
funcionalidade pode ser representada por um ponto no plano,
conforme a Figura 1.
Neste exerccio a meta no obter estimativas para criar
cronogramas. O objetivo dimensionar comparativamente
a quantidade aproximada de valor e risco de cada funcionalidade, por isso no preciso associar nmeros para as
medidas. O importante perceber quais funcionalidades
so, de fato, valiosas e de alto risco atravs de comparaes
diretas com as demais. Ao dispor os pontos (funcionalidades) no grfico, as posies comeam a ser definidas pelas
opinies dos participantes e depois so ajustadas por comparao com os outros pontos.
Figura 1. Plano com os eixos de Valor e Risco com

funcionalidades representadas por pontos.
Depois de dispor as funcionalidades no plano, este dividido

em quadrantes. Desta forma, as funcionalidades ficaro agrupadas em quatro categorias, de acordo com suas quantidades
de valor e risco. As categorias so: alto risco e alto valor, baixo
risco e alto valor, baixo risco e baixo valor, e alto risco e baixo valor.
A seguir, uma estratgia de priorizao dos quadrantes
escolhida conforme a metodologia, o projeto e a experincia da equipe. Para projetos que precisam comprovar sua
viabilidade ou equipes experientes com mtodos geis, a
prioridade mais alta pode ir para as funcionalidades do
quadrante com valor e risco mais altos. Faz-las primeiro
interessante porque quando estas estiverem implementadas, haver uma grande quantidade de valor agregado
ao software e ao mesmo tempo, uma grande quantidade
de risco ter sido eliminada do projeto. Em seguida vem o
quadrante de alto valor e baixo risco e depois o de baixo valor
e baixo risco, conforme a Figura 2. Com esta estratgia, caso
no seja possvel produzir as primeiras funcionalidades,
que so de alta dificuldade, o projeto pode ser reavaliado
sem ter tido custos elevados, pois os impedimentos foram
identificados cedo. Tambm pode ser percebido que a implementao ser muito mais demorada do que o previsto.
Isso permite que as estimativas sejam ajustadas ainda no
incio do projeto.
Figura 2. Sequncia de implementao para equipes

experientes ou projetos com muita incerteza.
11
Equipes com pouca experincia em desenvolvimento gil

ou projetos sem grandes desafios tcnicos podem usar outra
sequncia de priorizao. Comeando pelo quadrante de alto
valor e baixo risco, para produzir funcionalidades importantes
e rapidamente chegar a uma verso do software em produo
e, em seguida, implementar as funcionalidades dos quadrantes
de alto valor e alto risco e baixo valor e baixo risco e, se necessrio,
as do quadrante de baixo valor e alto risco. A Figura 3 exibe essa
seqncia de implementao.
periodicamente, mantm o foco nas funcionalidades de maior

interesse, o que aumenta significativamente as chances de
sucesso do projeto.
Os critrios de priorizao podem ser variados, contudo,
para projetos que buscam retorno financeiro, uma boa
ttica usar este fator como um dos critrios de priorizao. Dessa forma, o desenvolvimento orientado pela
mesma varivel que tambm guia a cobrana dos resultados da equipe.
A obteno das prioridades pode ser feita a partir de tcnicas
de fcil execuo. As que vimos neste artigo visam criao
rpida de uma verso funcional do software. Por isso consideram fortemente as opinies de usurios, desenvolvedores e
especialistas no domnio de negcios da aplicao. Contudo,
as mesmas tcnicas podem ser usadas considerando outros
critrios de priorizao.
Referncias
Uma priorizao adequada das funcionalidades faz parte

da etapa de planejamento do desenvolvimento. Ela ajuda o
projeto a aproveitar melhor seus recursos e, quando revista
12
A Engenharia de Software Magazine tem que ser feita ao seu gosto.

Para isso, precisamos saber o que voc, leitor, acha da revista!
D seu voto sobre este artigo, atravs do link:
www.devmedia.com.br/esmag/feedback
Feedback
eu
sobre e
s
Concluses
D seu feedback sobre esta edio!
D
s
Muitas vezes, independente de implementao escolhida,

as funcionalidades do ltimo quadrante no chegam a ser
implementadas porque o software j atende s necessidades
dos usurios e o investimento para produzir funcionalidades
de alto risco no recompensado.
edio
ta
Figura 3. Sequncia de implementao para equipes

pouco experientes ou projetos sem desafios tcnicos
Jim Johnson. ROI, its your job. In Keynote Speech at 3rd International Conference on eXtreme
Programming and Agile Processes in Software Engineering (XP2002), May 2002.
PMI Chapters Brasileiros. Estudo de benchmarking em gerenciamento de projetos brasil.
Technical report, www.pmi.org.br, 2007.
Kent Beck. Extreme Programming Explained: Embrace Change. Addison-Wesley, 1999.
Ken Schwaber. Agile Software Development with Scrum. Microsoft Press, 2004.
Mike Cohn. Agile Estimating and Planning. Prentice Hall, 2006.
Dairton Bassi. Experincias com desenvolvimento gil. Masters thesis, Instituto de Matemtica
e Estatstica da Universidade de So Paulo - IME/USP, 2008.
METODOLOGIAS GEIS
Modstia parte, sua

melhor opo para
se destacar no mercado!
A Escola Superior da Tecnologia da
Informao oferece as melhores
opes em cursos, formaes,
graduaes e ps-graduaes para
profissionais de desenvolvimento
e programao.
P S - G R A D UA O
So programas voltados para a

formao de profissionais de elite,
com aulas 100% prticas, corpo
docente atuante no mercado,
acesso mais atualizada biblioteca
de TI do Rio, laboratrios equipados
com tecnologia de ponta, salas de
estudo e exames.
FORMAES
Engenharia de Software:
Desenvolvimento Java
G R A D UA O
Anlise e Desenvolvimento
de Sistemas
Desenvolvedor Java
Desenvolvedor Java: Sistemas
Distribudos
Gestor de TI
Desenvolvedor Web .NET 2008
MCITP Server Administrator
SQL Server 2008
Acesse nosso site e conhea todos os nossos programas: www.infnet.edu.br/esti

TURMAS
NO RIO DE
JANEIRO
www.infnet.edu.br - cursos@infnet.edu.br - Central de Atendimento: (21) 2122-8800
EDUCAO SUPERIOR ORIENTADA AO MERCADO
13
Incorporando Restries UML

Os conceitos principais por trs da linguagem OCL

Neste artigo ser apresentada uma introduo
OCL, a linguagem de restrio oficial da UML.
A
Thiago Carvalho de Sousa
thiagocsousa@gmail.com
Doutorando em Engenharia de Computao e

Sistemas Digitais (EP-USP). Mestre e Bacharel
em Cincia da Computao (IME-USP). Trabalha h mais de 8 anos com desenvolvimento de
software e j atuou como gerente de projetos,
analista de negcios e engenheiro de requisitos
na Oracle, Johnson & Johnson, Goodyear, NET/
Embratel e Grupo Claudino. Atualmente consultor da Alstom Transport e professor licenciado das disciplinas de Engenharia de Software e
Mtodos Formais do CEUT e da FAETE.
14
UML (Unified Modeling Language) uma linguagem para

especificao, documentao,
visualizao e desenvolvimento de
sistemas orientados a objetos. Sintetiza
os principais mtodos existentes, sendo
considerada uma das linguagens mais
expressivas para modelagem de sistemas e por isso de grande aceitao na
indstria. Por meio de seus diagramas
possvel representar sistemas de softwares sob diversas perspectivas de
visualizao. Facilita a comunicao de
todas as pessoas envolvidas no processo de desenvolvimento de um sistema
- gerentes, coordenadores, analistas,
desenvolvedores - por apresentar um
vocabulrio de fcil entendimento.
A primeira verso da UML foi apresentada em junho de 1996 e submetida
OMG (Object Management Group),
consrcio de empresas que define padres de modelos e linguagens. A reviso desse modelo mostrou uma grande
Engenharia de Software Magazine - Incorporando Restries UML
Para que serve?

Impor restries a alguns objetos de fundamental importncia para esclarecer, verificar e validar
modelos UML. Este artigo trata sobre como possvel fazer isso atravs da OCL.

Em que situao o tema til: Para aqueles que
no conseguem apenas com os diagramas UML
definir todos os aspectos relevantes da especificao do sistema.
deficincia na clareza e consistncia das

definies da UML. Em particular, uma
dificuldade encontrada foi que a semntica da UML poderia ser interpretada
de formas ambguas. O problema foi
minimizado com a elaborao de uma
nova verso da linguagem, a qual foi
publicada em 1997. O mais importante
incremento nesta verso foi a criao da
OCL (Object Constraint Language), que
acompanha oficialmente a evoluo da
UML at os dias atuais.
PROJETO
A linguagem OCL
A OCL (ou linguagem para especificao formal de restries,

em portugus) uma linguagem declarativa para descrever as
regras que se aplicam aos modelos UML. uma linguagem de
texto precisa que fornece afirmaes em um modelo orientado
a objeto que no possam ser expressadas pela notao diagramtica. A OCL complementa os modelos UML fornecendo
expresses que no tm nem as ambiguidades da lngua natural
(eg. o sistema deve identificar uma pessoa com um telescpio),
nem a dificuldade inerente de se usar matemtica complexa.
Com a OCL possvel testar a construo dos modelos, retirar
mtricas ao nvel de projeto e ainda especificar vrios tipos de
restries, que podero refletir regras de negcio, atravs de
pr/ps condies e invariantes.
Como a OCL uma linguagem formal, semelhante a uma linguagem de programao, torna-se, tambm, possvel a criao
de geradores de cdigo tendo como entrada os modelos e as especificaes/restries nessa linguagem e como sada programas
fontes em linguagens de programao ou triggers para bancos
de dados. Inclusive, atualmente a OCL vem se tornando um
componente fundamental no novo padro MDA-QVT (QueryView-Tranformation) para transformao de modelos da OMG.
A OCL pode ser utilizada para:
Especificar invariantes em classes e tipos do modelos de classes.
Especificar tipos invariantes para esteretipos.
Descrever pr e ps-condies em operaes.
Como uma linguagem de navegao entre associaes.
Como uma linguagem de consulta.
Para especificar o alvo das mensagens e aes.
Para especificar regras de derivaes para atributos.
Especificar restries sobre operaes.
A estrutura da OCL est intimamente ligada a outros modelos
da UML, sendo bastante usada com o Diagrama de Classes
atravs de uso de notas nos diagramas. composta por expresses escritas em forma de afirmaes. uma linguagem
que possui tipos de dados pr-definidos, assim como algumas
palavras reservadas. Nas prximas sees falaremos sobre a
sintaxe de cada uma dessas caractersticas principais.
Expresses OCL
Toda expresso OCL declarativa no sentido de que expressa

o qu a restrio representa no sistema e no como essa restrio implementada. A avaliao de uma expresso quase
sempre resulta em um valor booleano e nunca muda o estado
do sistema no modelo.
As expresses OCL so utilizadas para definir condies
invariantes nas classes representadas em um modelo e tambm so utilizadas para especificar as pr e ps-condies em
operaes aplicadas a classes deste modelo.
Expresses OCL tambm podem ser utilizadas para fazer
consultas a um modelo de classes da UML. Essas consultas
podem ser teis para validar modelos de classes na fase de
projeto. Nesse caso, a avaliao dessa expresso no devolve
um valor booleano, e sim valores de um tipo especfico da OCL.
Tipos de Expresses
As expresses OCL podem ser de trs tipos:
Expresses que representam condies invariantes em
classes de objetos;
Expresses que representam pr-condies de operaes
aplicveis a uma classe de objetos;
Expresses que indicam as ps-condies de operaes
aplicveis a uma classe de objetos;
Contexto de uma Expresso
As expresses OCL requerem que as restries estejam ligadas a um contexto de um modelo. O contexto de uma expresso
pode ser uma classe de objetos ou pode ser uma operao
aplicvel a um objeto.
Para representar um contexto em OCL utilizamos a seguinte
palavra reservada:
context
<contexto>
Invariantes
Invariantes so condies que os objetos modelados devem
respeitar durante toda sua existncia no sistema. Em OCL,
para indicar que uma expresso uma invariante, utilizamos
a palavra reservada inv: aps a declarao do contexto. Uma
expresso tpica em OCL e que representa uma condio invariante tem o seguinte formato:
context <contexto>

inv: <expresso>
Pr-condies
Pr-condies so declaraes que refletem o estado no
qual deve se encontrar o sistema para que as operaes sobre
os objetos possam ser executadas. Em OCL, quando queremos expressar uma condio na forma de pr-condio,
utilizamos a palavra reservada pre: aps a declarao do
contexto. O contexto deve possuir explicitamente a indicao sobre qual operao a pr-condio ocorre. A expresso
tpica em OCL usada para representar uma pr-condio
tem a seguinte estrutura:
context <contexto>

pre: <expresso>
Ps-condies
Ps-condies so declaraes que apresentam o estado do
sistema aps a execuo de uma determinada operao de um
objeto. Em OCL, para declararmos uma expresso na forma
de ps-condio utilizamos a palavra reservada post: aps a
declarao do contexto. O contexto deve possuir explicitamente
a indicao sobre qual operao a ps-condio ocorre. Para as
ps-condies temos a seguinte expresso tpica:
context <contexto>

post: <expressao>
15
Palavras Reservadas
Algumas palavras que desempenham funes especiais no
contexto da expresso foram criadas para estruturar melhor
certas restries em OCL.
Self
Numa expresso em OCL, a palavra reservada self usada
para referenciar explicitamente uma instncia do contexto.
@Pre
Numa expresso em OCL, a palavra reservada @pre acompanha um atributo ou associao, indicando o seu valor antes
do inicio da operao.
Result
Numa expresso em OCL, a palavra reservada result indica
o resultado gerado por uma operao.
Let ... in
Algumas vezes uma pequena parte da expresso utilizada
mais de uma vez. As palavras reservadas let...in permitem a
definio de uma varivel (que contm a pequena parte da
expresso) a qual pode ser usada na restrio a ser expressada.
If Then. Else..... End If
Para uma restrio que envolve condies, foram criadas as
palavras reservadas if...then...else...end if.
Tipos de Dados
Uma das caractersticas da OCL ser uma linguagem tipada.
Toda informao manipulada, nas expresses construdas em
OCL, pertence a um dos seguintes grupos de variveis:
Tipos Bsicos: Real, Integer, String e Boolean;
Colees: Set (elementos nicos e no ordenados), Bag
(elementos duplicados e no ordenados), Sequence (uma bag
ordenada), e OrderedSet (um set ordenado);
Tipos dos modelos UML: todas as classes, atributos, interfaces, associaes, consultas e enumeraes introduzidas por
um diagrama de classes.
Operaes sobre Tipos Bsicos
Real: +, -, *, /, >=, <=, >, <, abs(), floor(), round (), max(r:Real),
min(r: Real)
Integer: +, -, *, /, >=, <=, >, <, abs(), div(i: Integer), mod (i:Integer),
max(r:Integer), min(r: Integer)
String: size(), concat(s: String), subString(lower: Integer,
upper: Integer), toInteger(), toReal()
Boolean: or(b:Boolean), xor(b:Boolean), and(b:Boolean),
implies(b: Boolean)
Operaes sobre Colees
Para realizar uma operao sobre uma coleo utilizamos a
seguinte sintaxe bsica:
[tipo de dado] -> [operao]
16
As principais operaes so:

size(): Integer encontra o tamanho da coleo;
isEmpty(), notEmpty(): Boolean - verifica se a coleo
vazia ou no;
first(): Object encontra o primeiro elemento da coleo;
last(): Object encontra o ultimo elemento da coleo;
sum (): Integer/Real - soma os elementos da coleo;
count(object): Integer numero de ocorrncias de um objeto;
includes (object): Boolean verifica se um objeto est numa
coleo;
excludes (object): Boolean verifica se um objeto no de
uma coleo;
includesAll (collection): Boolean verifica a incluso de
uma coleo em uma outra;
excludesAll (collection): Boolean verifica a excluso de
uma coleo em uma outra;
including (object): Collection adiciona um elemento a
coleo;
excluding (object): Collection exclui um elemento da
coleo;
union (collection): Collection une duas colees;
asSet(): Collection - transforma uma bag em um set, eliminando os duplicados;
select (condition):Collection restringe a coleo os objetos
sob uma certa condio;
reject (condition): Collection - exclui da coleo os objetos
sob uma certa condio;
forall (condition): Boolean verifica se todos os objetos
satisfazem uma certa condio;
exists (condition): Boolean verifica se pelo menos um
objeto satisfaz uma certa condio
collect (condition): Collection - cria uma coleo derivada
de outra, mas que tambm contm outros elementos.
Exemplo de Uso 1
A OCL se encaixa perfeitamente na metodologia de desenho

por contrato (design by contract). Essa metodologia foi desenvolvida em meados da dcada de 80 por Bertrand Meyer
e tem crescido muito nos ltimos anos, tendo entre seus
principais adeptos Craig Larman. O desenho por contrato
(DbC) um mtodo de implementao que visa a construo
de sistemas orientados a objetos mais confiveis, na medida
em que prov mecanismos para deteco de violaes da
sua especificao, em especial violaes de invariantes. A
principal idia do DbC que entre as classes e seus clientes
seja estabelecido explicitamente um contrato. Nele, o cliente
deve garantir certas condies antes de invocar os mtodos da
classe (pr-condies), que por sua vez deve garantir algumas
propriedades aps ter sido executado (ps-condies). Veremos a seguir como a utilizao da OCL como ferramenta
para a especificao de restries do sistema, usando dois
exemplos para elucidar a teoria apresentada.
O primeiro exemplo um clssico proposto por Jos Warmer
baseado na empresa fictcia Royal e Loyal (R&L). A R&L
gerencia programas de fidelidade para empresas parceiras
PROJETO
Figura 1. Diagrama de Classes.
que oferecem vrios tipos de bnus (eg. milhas areas). A

classe principal a LoyaltyProgram. Um sistema que tem
apenas um programa de fidelidade possuir um nico objeto dessa classe. A empresa que oferece a seus clientes um
programa de fidelidade chamada ProgramPartner. Mais
de uma empresa pode participar de um mesmo programa.
Nesse caso, os clientes que entram no programa fidelidade
podem lucrar com servios prestados por qualquer das
empresas participantes.
Todos os clientes entram no programa atravs do preenchimento de um formulrio e obtm um carto de fidelidade.
Os objetos da classe Customer representam as pessoas que
entraram no programa. O carto de fidelidade representado
pela classe CustomerCard e pode ser do tipo ouro ou prata,
dependendo dos gastos do cliente. A maioria dos programas
permite que os clientes acumulem pontos de bnus. Cada
parceiro decide quando e quantos pontos de bnus so atribudos a uma determinada aquisio (Service). Os pontos
podem ser usados para comprar servios especficos de
um dos parceiros do programa. Para contabilizar os pontos
de bnus que so salvos pelo cliente, cada membro associado a uma LoyaltyAccount. H dois tipos de transaes:
uma para obter pontos (Earning) e outra para resgat-los
(Burning). Para administrar os diferentes nveis de servios,
a classe ServiceLevel foi introduzida ao modelo. Um nvel de
servio definido pelo programa de fidelidade e usado por
cada membro (Membership). Vejamos a seguir o diagrama
de classes (Figura 1) desse sistema e mais detalhes sobre a

especificao de requisitos (Quadro 1).
.
R11: Todo cliente deve ter no mnimo 21 anos
R12: A data valid from do carto de fidelidade deve ser anterior a data valid to
R13: Um carto fidelidade s pode ser emitido para um membro
R14: A quantidade de nveis de servios exatamente dois
R15: O nome impresso no carto de fidelidade deve ser precedido pelo ttulo ao qual o cliente
deseja ser chamado
R16: O numero de cartes vlidos para cada cliente deve ser igual ao numero de programas que
ele participa
R17: Quando um programa no possui acrscimo e nem resgate de pontos, no existe necessidade
dos clientes terem uma conta
R18: O numero de clientes de um parceiro a soma dos participantes de um ou mais programas
daquele parceiro
R19: O primeiro nvel de servio o prata
R20: O mximo de pontos que pode ser resgatado em cada parceiro de 10000
R21: O ttulo do cliente Mr. se for homem, caso contrario Ms.
R22: O nvel de servio atual deve ser um servio oferecido pelo programa de fidelidade
R23: O conjunto de transaes em uma conta deve ter pelo menos uma transao com mais de
500 pontos
R24: A existncia de pontos em conta implica que pelo menos uma transao foi realizada.
R25. O numero de pontos resgatados em uma aquisio nunca deve exceder o numero de pontos
ganhos por esse servio.
.
Quadro 1. Especificao de Requisitos
17
A partir desses requisitos e visualizando o diagrama de

classes, podemos criar as seguintes expresses OCL:
context Customer

inv: age( ) >= 21
(R11)
- - age( ) um mtodo da classe Customer e pode ser

usada em uma
- - expresso OCL como consulta.
context CustomerCard

inv: validFrom.isBefore(ValidTo)
(R12)
- - isBefore ( ) um mtodo da classe Date

e validFrom e validTo so
- - atributos de CustomerCard do tipo Date.
context Membership
inv: card.customer = customer

(R13)
context LoyaltyProgram
inv: serviceLevel->size() = 2

(R14)
- - a pr-definida operao size da OCL

devolve o tamanho da coleo de
- - nveis de servios.
context CustomerCard
inv: printedName = customer.title.

concat(customer.name)

(R15)
- - title do tipo String e pode ser

concatenado (concat) com o nome do
- - cliente, que tambm do tipo String,
para formar o nome a ser

- - impresso no carto.
context Customer

inv: program->size() = cards->select
(valid = true) ->size()
(R16)
(R17)

inv: partners.deliveredServices>forAll(pointsEarned = 0 and pointsBurned = 0)
implies membership.loyaltyAccount->isEmpty()

- - se um parceiro oferece um programa onde

todos (forAll) os servios
- - no oferecem acrscimo ( pointsEarned = 0)
e nem resgate de pontos
- - (pointsBurned = 0), ento a coleo de contas
(loyaltyAccount) de um - - cliente deve ser
vazia (isEmpty).
context ProgramPartner
(R18)
inv: numberofCustomers = loyaltyProgram.

customer->asSet->size()

- - a pr-definida operao asSet da OCL
transforma uma bag em um
- - set, eliminando os clientes repetidos.
- as transaes de resgate (Burning) devem

somar (sum) no mximo
- - 10000 pontos
context Customer
(R21)
inv: title = (if isMale = true then Mr.

else Ms. endif)
context Membership
(R22)

inv: program.serviceLevel-> includes (actualLevel)
context LoyaltyAccount
(R23)

inv: transaction->collect(points) -> exists
(p:Integer | p > 500)
context LoyaltyAccount
(R24)
inv: points> 0 implies transaction->exists (points> 0)

context ProgramPartner
(R25)
inv: self.services.transaction->select(Burning)

-> collect(points) ->sum() <= self.services.
transaction->select(Earning)->collect(points) ->sum()
Note que o requisito R18: O numero de clientes de um parceiro a soma dos participantes de um ou mais programas daquele parceiro permite uma interpretao ambgua, pois pode
ser tanto a quantidade total de participaes nos programas
ou a quantidade de pessoas distintas. Com a OCL possvel
esclarecer requisitos ambguos (no caso, o analista preferiu
optar pela segunda opo) e coloc-los em uma notao matemtica precisa, sem margem para varias interpretaes, mas
de fcil entendimento. Nesse exemplo usamos a OCL apenas
para relatar os invariantes do sistema, mas poderamos us-la
tambm para delimitar as pr-condies e as ps-condies.
Faremos isso a seguir.
Exemplo de Uso 2
O segundo exemplo baseado em um fictcio sistema bancrio. Os clientes (Customer) possuem uma conta (Account), que
pode ser do tipo corrente (current) ou poupana (deposit). Toda
conta do tipo corrente possui um limite de cheque especial
(odLimit). Os clientes podem sacar, depositar (em cheque (check) ou dinheiro (cash)) e solicitar emprstimos (Credit) usando
bens (Security) como garantia. Vejamos a seguir o diagrama
de classes (Figura 2) desse sistema e mais detalhes sobre a
especificao de requisitos (Quadro 2).
A partir desses requisitos e visualizando o diagrama de
classes, podemos criar as seguintes expresses OCL:
context Customer
inv: age >= 18
(R1)
context Account
inv: self.balance >= -self.odLimit
(R2)
- o saldo sempre deve ser maior que o

cheque especial negativamente.
(R19)

inv serviceLevel.name ->first() = Silver
- - o modelo define que a associao entre

LoyaltyProgram e ServiceLeve
- - ordenada, sendo silver o primeiro elemento.
context Account
inv: self.holder.getAge() < 25 implies

odLimit = 0
(R3)
(R20)

inv: partners.deliveredServices.transaction->
select(Burning)-> collect (points)->sum( )<= 10000
context Account

inv: self.accountType = #deposit implies
self.odLimit = 0
(R4)
18
self.
PROJETO
Figura 2. Diagrama de Classes do cenrio 2

- - se a conta do tipo poupana (deposit),

ento no existe cheque - - especial.
context Account::deposit (amount: Integer,

depositType: DepositType)

pre: amount > 0 and accessor = holder
(R26)
post:

(depositType = #cash implies balance =

balance@pre + amount) or (R27)
(depositType = #check implies uncleared =

uncleared@pre + amount)

- - se o depsito for em dinheiro (cash),

ento o saldo
- - automaticamente incrementado. Se o
depsito for em cheque (check),
- - ento o
saldo dos depsitos bloqueados incrementado.
context Account::clear (amount: Integer)

pre: self.uncleared >= amount (Requisito Novo)

post:
(uncleared = unclered@pre amount) and (R28)

(balance = balance@pre + amount)

- quando um depsito liberado, o saldo
dos depsitos bloqueados
- - decrementado e o valor acrescentado ao
saldo real (balance).
context Account::withdraw (amount: Integer)
pre: amount > 0 and accessor = holder

balance-amout>= -odLimit

post: balance = balance@pre amount
context Account::balanceEnquiry(): Integer

pre: accessor = holder

post: result = balance
and
(R32)
(R33)
(R57)
.
R1: Todo cliente deve ser maior de idade
R2: O limite de cheque especial nunca pode ser excedido
R3: Clientes menores de 25 anos no possuem cheque especial
R4: Contas do tipo Poupana no possuem cheque especial
.
R26: Depsitos nulos e no realizados pelo titular so invlidos
R27: Se o depsito for em dinheiro, o saldo deve ser incrementado. Se o depsito for em cheque, o
valor ficar bloqueado em uma conta de saldos bloqueados at o cheque ser compensado.
R28: Quando um cheque compensado, o seu valor incorporado ao saldo e a conta de saldos
bloqueados atualizada.
.
R32: No so permitidos saques nulos, que excedam o limite de cheque especial e no realizados
pelo titular da conta.
R33: O saldo deve ser atualizado aps um saque.
.
R57: O saldo e o saldo total somente podem ser vistos pelo titular da conta.
R58: O saldo total calculado pela soma do saldo com o limite do cheque especial
.
R62: Um cliente s pode pedir um emprstimo se possuir conta do tipo corrente e com cheque
especial de pelo menos 10000
R63: Um cliente s pode pedir um emprstimo se a soma de todos os seus emprstimos no
exceder em 50% do seu salrio
R64: Um cliente s pode pedir um emprstimo se a soma dos valores de todos os bens for pelo
menos 20% maior que o valor dos emprstimos
R65: Depois de pagar a mensalidade de todos os emprstimos, o saldo da conta deve ser positivo
R66: O emprstimo mnimo de 10000 e o mximo de 1000000
R67: Os bens dados como garantia devem ser obrigatoriamente do cliente
.
R74: Ser possvel consultar quais os clientes com saldo total maior que 100000.
.
Quadro 2. Especificao de Requisitos
19
- - o cliente possuir conta do tipo corrente

(current), seu cheque
- - especial ser maior ou igual a 1000
(odLimit >= 10000), a soma dos
- - pagamentos mensais (monthlyRatio) ser
menor que a metade de seu
- - salario (income) e o valor do bens
penhorados (incluindo o atual,
- - security.value) ser maior que 20% do
valor do emprstimos
- - (incluindo o atual, sum) pr-condio

para realizar um novo
- - emprstimo.

context Customer
(R65)
inv: heldAccount.balance - credits.

monthlyRate->sum() >= 0
context Credit
(R66)

inv: amount >= 10000 and amount <=1000000
context Security

inv: securities.owner->forAll(owner | owner =
customer)
(R67)
context Customer

inv: self.heldAccount->select(balanceEnquiry()
> 100000)
(R74)
20
A evoluo da engenharia de software pode ser comparada

da engenharia civil. Com o passar do tempo, esta precisou
se basear em clculos estruturais formais a fim de garantir a
qualidade dos imveis construdos. O que se percebe que
essa evoluo natural para um formalismo mais apurado est
tambm ocorrendo na engenharia de software para alguns problemas especficos, uma vez que as exigncias de confiabilidade
e segurana de um software tm aumentado nos ltimos anos.
Nesse contexto, apresentamos no artigo as noes bsicas da
OCL, a linguagem oficial de restries da UML, que vem se
destacando a cada dia, sendo a grande aposta da OMG como
pea fundamental da arquitetura MDA-QVT.
Links
OMG OCL Specification Site
http://www.omg.org/docs/formal/06-05-01.pdf
Artigo Introduction to OCL, de Jos Warmer e Anneke Kleppe
http://www.klasse.nl/ocl/ocl-introduction.html
Applying Design by Contract, de Bertrand Meyer
http://www.cs.ucl.ac.uk/students/A.Masalskis/files/contract.pdf
Artigo Introduction to OCL in Together, de Dan Massey
http://conferences.codegear.com/article/32200

Feedback
eu
sobre e
s
Mais uma vez podemos ver que a OCL transforma os requisitos (descritos em linguagem natural ambgua, como o requisito
R32) em notao matemtica precisa e de fcil entendimento.
Alm disso, durante essa transformao, o analista pode
lembrar de pontos importantes esquecidos no documento de
especificao, como verificar se a conta de saldos bloqueados
Concluso
D
s
context Customer::getMortgage(sum: double, security: Security)

pre:

self.accountType = #current and odLimit >= 10000 and

(sum + self.credits.monthlyRatio -> sum() <=
self.income * 0.5) and

(security.value + self.securities.value->sum()
>= 1.2 * self.credits.amount -> sum() + sum)

(R62) (R63) (R64)
possui um valor maior ou igual ao que vai ser desbloqueado.

A vantagem da OCL se completa quando se usa ferramentas
automatizadas (eg. Together) para gerar cdigos fontes (eg.
uma consulta SQL a partir do requisito R74) e testar se todas
as possveis entradas/sadas das operaes atendem as pr e
ps-condies.
edio
ta
context Account::availableFunds(): Integer

pre: accessor = holder
(R57)
post: result = balance + odLimit

(R58)

- - o saldo total a soma do saldo real com
o limite do cheque especial.
quic k update
Edio 65 - .Net Magazine
17
UML Diagrama de Sequncias

Descobrindo como modelar um diagrama de sequncias
Ana Cristina Melo

informatica@anacristinamelo.com.br
especialista em Anlise de Sistemas e professora de graduao e ps-graduao da

Universidade Estcio de S. Atua em anlise
e programao h 21 anos, sendo os ltimos
11 anos no servio pblico. Autora do livro
Desenvolvendo aplicaes com UML - do
conceitual implementao, na segunda
edio, e Exercitando modelagem em UML.
Palestrante em alguns eventos, entre eles,
Congresso Fenasoft, OD e Sepai.
22
UML, na sua verso atual, nos

oferece treze diagramas que
tratam de aspectos diferentes
de todas as fases de desenvolvimento de
um sistema. Todos tm suas utilidades,
mas, na prtica, sabemos que possvel
desenvolver a maioria dos sistemas
orientados a objetos utilizando apenas
trs deles. Desses, j apresentei aqui os
Casos de Uso e o Diagrama de Classes.
E hoje, trabalhando em como modelar
um Diagrama de Sequncias, podemos
dizer que vocs tero o conhecimento
bsico para desenvolver cerca de 70%
dos sistemas orientados a objeto.
Veremos o que significa esse diagrama e como o mesmo se integra com os
outros modelos.
O Diagrama de Sequncias um
Diagrama de Interao
O Diagrama de Sequncias o principal

dos quatro diagramas de interao. Os
outros so: Diagrama de Comunicao, Diagrama de Viso Geral e Diagrama Temporal.
Um diagrama de interao tem por
responsabilidade mostrar a interao
entre os objetos de um sistema por meio
Engenharia de Software Magazine - UML Diagrama de Sequncias

Este artigo tem por objetivo apresentar as regras
para se modelar um diagrama de sequncia, partindo da integrao com os casos de uso e modelo
de classes.
Para que serve?

Fornecer aos desenvolvedores ou estudantes da
rea de sistemas uma linha de entendimento
com o intuito de orient-los a modelar seus diagramas de sequncia.

Para quem ainda no modelou diagramas de interao, ou para quem tem experincia e quer revisar
a sintaxe permitida nesse tipo de diagrama.
de uma viso dinmica. Essa interao

entre objetos representada por meio
de mensagens. Ao se identificar as
mensagens, estamos identificando os
servios oferecidos pelas classes. E, por
sua vez, identificar os servios significa
que estamos descobrindo quais os mtodos necessrios a cada classe. Por isso,
normalmente s chegamos a uma verso
final do modelo de classes depois que
passamos pelo diagrama de sequncias,
PROJETO
pois s com ele conseguimos enxergar claramente todos os

mtodos que sero necessrios para atender aos casos de uso.
Apesar de todos os diagramas terem um objetivo final comum, cada um atende a uma caracterstica particular.
O Diagrama de Sequncias enfatiza a troca de mensagens
dentro de uma linha de tempo sequencial.
O Diagrama de Comunicao enfatiza o relacionamento
estrutural entre os objetos, sem se preocupar com o tempo
determinado para cada interao.
O Diagrama de Viso Geral uma variao do diagrama de
atividades que mostra de uma forma geral o fluxo de controle dentro de um sistema ou processo de negcios. Cada n ou atividade
dentro do diagrama pode representar outro diagrama de interao.
O Diagrama Temporal mostra a mudana de estado de um
objeto numa passagem de tempo, em resposta a eventos externos. Este ltimo mais utilizado quando o objetivo principal
do diagrama a determinao do tempo exato, o que indicado
para sistemas de tempo real.
Integrando os modelos
O Diagrama de Sequncias no surge do nada e sim de uma

modelagem feita a partir dos casos de uso, com o auxlio
das classes j identificadas num modelo de classes. No caso
de uso, estabelecemos a ordem das funcionalidades, sem
nos preocuparmos com a implementao. Ao modelarmos
o diagrama de sequncias, representaremos por mensagens
cada item descrito nos cenrios principal e alternativos. Essas mensagens podem ser expressas do ator para o sistema,
ou da interface para os objetos.
Para exemplificar essa modelagem, tomaremos por base um
pequeno estudo de caso que se refere a um sistema de votao interna de uma empresa. Para isso, apresentaremos nas
Figuras 1 e 2 os diagramas de casos de uso e a verso inicial
do diagrama de classes, respectivamente. Nas Listagens 1, 2,
3, 4 e 5 apresentaremos os cenrios dos principais casos de
uso, para que vocs possam compreender como chegamos
ao modelo de classes e como o pequeno sistema funciona.
Listagem 1. UC Manter Eleio
Figura 1. Diagrama de casos de uso para o sistema

gestor de votao interna de uma empresa
Figura 2. Diagrama de classes (verso inicial) para o

sistema gestor de votao interna de uma empresa
Descrio: Este caso de uso tem por objetivo manter o cadastro

de eleies, permitindo a incluso, alterao, excluso ou
consulta de eleies.
Atores: Coordenadoria de Eleies
Cenrio principal:
1. O sistema prepara uma lista de eleies cadastradas, exibindo
para cada uma: objetivo, data da eleio, status da apurao.
1.1. O usurio pode pesquisar uma eleio, informando os
seguintes critrios:
- objetivo
ou
- perodo inicial e final em que ocorreu a eleio
2. O sistema habilita as seguintes opes para o usurio:
2.1. Incluso de eleio
2.2. Alterao de eleio
2.2.1. Para alterao, o usurio deve pr-selecionar a eleio
2.3. Excluso de eleio
2.3.1. Para excluso, o usurio deve pr-selecionar a eleio
3. Para a opo de Incluso ou Alterao:
3.1. O usurio informa/edita:
3.1.1. objetivo da eleio
3.1.2. data da eleio
4. Para a opo de Excluso:
4.1. O sistema exibe os dados do item 3.1 desabilitados para edio.
4.2. O usurio confirma a excluso da eleio.
5. O usurio confirma a operao.
5.1. O sistema atualiza o cadastro de eleies.

Cenrios alternativos:
Pesquisa de eleio
1.a. A pesquisa de eleio deve desconsiderar caixa alta e
baixa, acentuao e realizar a localizao dos trechos em
qualquer ordem que os mesmos apaream no cadastro.
1.b. A pesquisa de perodo deve ser feita considerando os
perodos inicial e final, inclusive; podendo ser informado
apenas um dos perodos.
Permisso de Alterao da eleio
2.a. Se j houver data que indique o incio da votao, a
eleio no poder ser alterada. Exibir mensagem de erro e
retornar ao passo 1.
Permisso de Excluso da eleio
2.b. Se j houver data que indique o incio da votao, a
eleio no poder ser excluda. Exibir mensagem de erro e
Validao da data de eleio
3.a. Se o usurio informar uma data de eleio que no seja
futura, exibir mensagem de erro e retornar ao passo 3.
3.a. Se o usurio informar uma data de eleio futura que j
esteja cadastrada para outra eleio, exibir mensagem de erro
informando a qual eleio a data j est cadastrada e retornar
ao passo 3.
23
Listagem 2. UC Manter Candidatos
Listagem 5. UC Votar
Descrio: Este caso de uso tem por objetivo manter o cadastro

de candidatos, permitindo a incluso, alterao, excluso ou
consulta de candidatos.
Atores: Coordenadoria de Eleies
Pr-condio: existir cadastro prvio de eleies.
Cenrio principal:
1. O sistema prepara uma lista de eleies cadastradas, que
ainda no tenham ocorrido a votao (incio de votao em
branco), exibindo para cada uma: objetivo, data da eleio,
lista de candidatos cadastrados. Para cada candidato
cadastrado, exibir: nmero e nome.
2. O usurio seleciona uma eleio.
3. O sistema habilita as seguintes opes para o usurio:
3.1. Incluso de candidato
3.2. Alterao de candidato
3.2.1.Para alterao, o usurio deve pr-selecionar
tambm o candidato.
3.3. Excluso de candidato
3.3.1. Para excluso, o usurio deve pr-selecionar
tambm o candidato.
4. Para a opo de Incluso ou Alterao:
4.1. O usurio informa/edita:
4.1.1. nmero do candidato
4.1.2. nome do candidato
4.1.3. foto do candidato
5. Para a opo de Excluso:
5.1. O sistema exibe os dados do item 4.1 desabilitados para edio.
5.2. O usurio confirma a excluso da eleio.
6. O usurio confirma a operao.
6.1 O sistema atualiza o cadastro de candidatos.

Validao do nmero do candidato
4.a. Se o usurio informar um nmero de candidato j cadastrado
na eleio escolhida, exibir mensagem de erro informando a que
candidato est associado e retornar ao passo 4.
Descrio: Este caso de uso tem por objetivo permitir que o

eleitor registre o seu voto.
Atores: Eleitor
Pr-condio: a urna estar liberada para votao. Receber a
identificao da eleio e do eleitor habilitado para votao.
Cenrio principal:
1. O sistema busca e exibe todos os candidatos associados
eleio identificada.
1.1. Para cada candidato, o sistema exibe: nmero do
candidato, nome do candidato e foto do candidato.
2. O sistema habilita as opes Nulo e Branco.
3. O usurio seleciona um dos candidatos ou uma das opes
Nulo ou Branco.
4. O usurio confirma a votao.
5. O sistema atualiza o cadastro de votao.
5.1. O sistema registra que o eleitor identificado j efetuou
seu voto, sem associ-lo ao voto.
5.2. O sistema computa 1 voto para o candidato selecionado ou
para as opes Nulo ou Branco.
5.3. O sistema libera a urna.

Permisso de correo da votao
4.a. O usurio pode solicitar a correo do seu voto, no
momento de confirmar a votao. Nesse caso, o sistema deve
Listagem 3. UC Iniciar Votao

Descrio: Este caso de uso tem por objetivo dar incio
votao de uma eleio.
Atores: Mesrio
Pr-condio: existir uma eleio cuja data igual data
vigente e que ainda no tenha tido a votao iniciada.
Cenrio principal:
1. O sistema busca a eleio cuja data igual data vigente.
2. O usurio confirma o incio da votao.
2.1. O sistema atualiza o cadastro de eleies, registrando a
data e hora atual no campo incio da votao.

No se aplica
Listagem 4. UC Habilitar Eleitor

Descrio: Este caso de uso tem por objetivo validar o eleitor e
liberar a urna para votao.
Atores: Mesrio
Pr-condio: existir uma eleio cuja data igual data
vigente e cujo incio da votao j tenha sido preenchido.
Cenrio principal:
1. O usurio informa a matrcula do eleitor.
1.1. O sistema busca o eleitor, exibindo o seu nome.
2. O usurio libera a urna para votao.

Validao da matrcula do eleitor
1.a. Se o usurio informar um nmero de matrcula que no
exista no cadastro, exibir mensagem de erro e retornar ao passo 1.
1.b. Se o eleitor j tiver votado na eleio corrente, exibir
mensagem de erro e retornar ao passo 1.
Permisso para liberar a urna
2.a. Se o eleitor anterior ainda no tiver finalizado a
votao, exibir mensagem de erro e retornar ao passo 1.
24
Modelando o primeiro Diagrama de Sequncias
Ao se modelar um diagrama de sequncias, em geral elaboramos ao menos um diagrama para cada caso de uso. Comearemos com o UC Habilitar Eleitor, por ser o mais simples
para nossa primeira explicao.
Primeiro desenhamos o mesmo ator do caso de uso (Mesrio), no canto superior esquerdo. No topo desenhamos, em
seguida, um objeto para representar a interface do sistema
e um objeto para cada classe envolvida nesse caso de uso.
Nesse caso, as classes Eleicao e Eleitor. A partir de cada objeto,
incluindo o ator, desenharemos uma linha tracejada que a
linha de vida desse objeto.
A linha de vida indica o tempo de vida desse objeto. Sendo
colocada desde o incio do diagrama como se esse objeto
fosse criado desde o incio da rotina. Terminando no final do
diagrama, indica que o objeto destrudo quando a rotina
encerrada. A maioria dos diagramas de sequncias desenhada dessa maneira. Contudo, se for necessrio representar que
um objeto criado ou destrudo durante a execuo da rotina
possvel faz-lo. Veremos num tpico mais frente. Veja a
representao grfica desse primeiro diagrama na Figura 3.
Figura 3. Primeira parte do desenho do

Diagrama de Sequncias do UC Habilitar Eleitor
PROJETO
Os objetos se diferenciam das classes por se apresentarem sublinhados. E podem ser desenhados com trs notaes diferentes:
nome do objeto : nome da classe
ou
: nome da classe
ou
nome do objeto
A primeira notao traz primeiro um nome aleatrio de objeto
que ser til se precisarmos usar esse objeto como parmetro
de um mtodo.
A segunda notao indica um objeto annimo, ou seja,
desconhecemos o nome do objeto por ele ser irrelevante, mas
conhecemos a classe da qual ele instanciado.
A terceira notao a menos indicada, pois desconhecemos o
nome da classe. Nesse caso o nome do objeto deve ser claro o suficiente para que o leitor identifique de qual classe ele foi instanciado.
A partir da estrutura inicial, j podemos desenhar as mensagens, que partem sempre de uma origem para o objeto destino
que contm o servio que se est querendo chamar.
Assim comearamos pelo item 1 do caso de uso. Contudo, como
temos uma pr-condio, essa pr-condio pode representar
apenas um parmetro que a rotina receba ao ser iniciada, ou uma
verificao que precisa ser verdadeira, para que a rotina tenha
incio. Como, nesse caso, representa uma verificao, a primeira
mensagem de nosso diagrama de sequncias ser essa checagem.
A pr-condio determina que exista uma eleio cuja data
igual data vigente e cujo incio da votao j tenha sido
preenchido. Isso significa que precisamos de um mtodo na
classe Eleicao que possa retornar se existe ou no uma eleio
com a data atual. E depois, se existir, basta verificar se o atributo inicioVotacao est preenchido. Essa ltima verificao reside
no processamento que se inicia com a mensagem que parte da
interface. Se essa verificao for OK, a rotina ter incio.
O retngulo que surge a partir de uma mensagem disparada
chamado de caixa de ativao. Ele dura o tempo de processamento
daquela mensagem, tanto no objeto origem quanto no objeto destino.
O mtodo criado na classe Eleicao o buscaEleicao, passando
como parmetro a dataAtual, que ser usada para comparao
com as datas cadastradas das eleies.
Com a primeira verificao concluda, o ator est liberado para
iniciar a interao com o sistema. Olhando o caso de uso, vemos
no item 1 que o usurio informa a matrcula do eleitor. Essa representao vista no diagrama de sequncias com a mensagem
partindo do ator (com o contedo matriculaEleitor) para o objeto
interface. A partir dessa mensagem, no caso de uso, tem-se a ao
do sistema buscando esse eleitor e exibindo seus dados, caso
encontre. A busca do eleitor requer um novo mtodo, nesse caso,
o mtodo buscaEleitor na classe Eleitor. Como argumento, esse
mtodo receber a informao passada pelo ator, a matriculaEleitor.
Porm, repare que o cenrio principal que faz a busca do eleitor

(item 1) tem dois cenrios alternativos associados. O primeiro trata
a resposta falsa na busca do eleitor, o que j se resolve na mensagem
de retorno. O segundo cenrio alternativo verifica se esse eleitor j
votou. Essa informao ser obtida questionando-se classe Eleio
a existncia de um relacionamento da eleio com eleitor, que s
criada quando da votao pelo eleitor. Assim, temos no mesmo
processamento iniciado com a mensagem do ator, uma nova
mensagem sendo disparada (sem que tenha havido interrupo do
processamento) em direo classe Eleicao, chamando pelo mtodo
verificaVotacao. Como argumento passado o prprio objeto Eleitor,
chamado objEleitor, que, nesse momento, estar preenchido com o
eleitor identificado na mensagem anterior.
Com todas as validaes efetuadas, o controle repassado
novamente ao usurio, para decidir o momento de liberar a
urna para votao item 2 do caso de uso. Porm, da mesma
forma que ocorreu com o item anterior, esse item do cenrio
principal tem atrelado a ele um item do cenrio alternativo.
Ento, logo depois da interface receber a mensagem do ator, ela,
que representa o sistema, deve verificar se possvel liberar a
urna. Para isso, preciso questionar classe Eleicao se a urna
est liberada. Isso feito pela chamada do mtodo urnaLiberada.
Aqui, fazemos uso do retorno status para colocar uma condio
na mensagem que liberar a urna para o prximo eleitor.
Repare que, por conveno, s colocamos mensagem de retorno para o ator, no final do diagrama, indicando que a rotina
foi concluda com sucesso.
Analisando-se esse diagrama, percebemos que identificamos
quatro mtodos da classe Eleicao (buscaEleicao(), verificaVotacao(),
urnaLiberada() e liberarUrna()) e um mtodo da classe Eleitor
(buscaEleitor()) (ver Figura 4).
Figura 4. Diagrama de Sequncias finalizado do UC Habilitar Eleitor
25
Modelando Diagrama de Sequncias usando a

nomenclatura da UML 2.0
Se podemos considerar um local no qual houve boas alteraes na verso 2.0 da UML, esse local o Diagrama de
Sequncias. A fim de obtermos maior legibilidade na separao das funcionalidades, de forma a permitir agrupamentos,
condies relacionadas a um grupo de mensagens e no s a
uma mensagem, trechos opcionais, etc., a UML disponibilizou
os operadores e as ocorrncias de interao.
Vejamos na prtica como isso funciona modelando o Diagrama de Sequncias do UC Manter Candidatos.
Comeamos desenhando o ator Coordenadoria de Eleies.
Em seguida, o objeto da interface e os objetos para as classes
Eleicao e Candidato.
Analisando o caso de uso, vemos que a primeira providncia a tomar garantir a pr-condio. Ento, traaremos uma
mensagem da interface (que representa o sistema) para a classe
Eleicao, a fim de obter com o mtodo existeEleicaoCadastrada() a
garantia de que a pr-condio ser cumprida.
Com a resposta positiva, o sistema continua com o controle,
pois dever trazer a lista de eleies cadastradas, que ainda
no tenham ocorrido a votao. Nesse caso, criaremos o
mtodo buscaEleicoesNaoRealizadas() da classe Eleicao. Repare
que o retorno dessa lista no traz apenas dados da eleio,
mas dados do candidato tambm. Isso significa dizer que o
mtodo buscaEleicoesNaoRealizadas() deve ser responsvel por
obter, para cada eleio encontrada, os candidatos que j se
encontram cadastrados. Essa dependncia na busca tpica
do relacionamento de agregao por composio que existe
entre as classes Eleicao e Candidato.
Ento, dentro do processamento do mtodo buscaEleicoesNaoRealizadas() feita uma chamada ao objeto Candidato,
chamando o mtodo buscaCandidato() que far uma busca
simples dos atributos desse objeto. S que esse mtodo no ser
chamado uma nica vez, e, sim, tantas vezes quantas forem a
quantidade de candidatos cadastrados. Por isso, aparece sobre
a mensagem o smbolo * para indicar iterao (repetio) e
a condio, colocada entre colchetes, para indicar a condio
de parada.
Veja que s depois que essa busca feita, o controle entregue, pela primeira vez ao ator. Ento ele faz a seleo de uma
das eleies exibidas. Veja que todo esse processo de exibio
fica dentro da caixa de ativao, ou seja, no relevante mostrar
no Diagrama de Seqncias, pois o detalhamento desse tipo
de procedimento j est no caso de uso.
A partir da seleo da eleio, o controle volta ao sistema que
habilita as opes. Isso tambm no representado explicitamente no diagrama de sequncias, ficando subentendido na
caixa de processamento. A quebra da caixa de ativao indica
que o controle volta para o usurio, para que o use no tempo
desejado. Na nova interveno do ator, h a passagem de uma
mensagem com a seleo da sua opo.
Repare que, a partir desse ponto, temos blocos diferentes
de processamento. Temos um bloco reservado incluso e
alterao, e outro excluso. Os blocos so controlados pelo
26
operador alt. Em cada bloco interno, coloca-se uma condio

que indica que esse bloco s ser executado se a condio
for verdadeira. Assim, o primeiro bloco s ser executado se
a opo selecionada pelo usurio tiver sido a incluso ou a
alterao. No segundo bloco, somente se a opo selecionada
tiver sido a excluso.
Vemos que todas as mensagens que ficam dentro de um
bloco so pertinentes s e somente s a esse bloco. Ento, s
haver passagem da mensagem com o nmero, nome e foto do
candidato, se o processamento estiver na incluso ou na alterao. Uma vez informados esses dados, o diagrama representa
o cenrio alternativo que verifica se esse nmero duplicado
ou no. Assim surge a mensagem com chamada do mtodo
buscaCandidato da classe Candidato. Se nenhum candidato for
encontrado com aquele nmero, o sistema estar habilitado
para continuar o processo de edio, chamando ento o
mtodo gravaCandidato da classe Eleicao, pois somente essa
classe pode se responsabilizar pela gravao do candidato,
visto que a classe Eleicao a classe todo no relacionamento
de agregao por composio.
No segundo bloco, h a mensagem de confirmao do ator. A
partir do recebimento dessa mensagem, o sistema pode passar
a mensagem excluiCandidato para a classe Eleicao para que ela
se responsabilize pela chamada do mtodo excluiCandidato() da
classe Candidato. Veja como ficou esse diagrama na Figura 5.
Outros recursos do Diagrama de Sequncias
Vejamos os outros recursos que o Diagrama de Sequncias

nos oferece para se atingir o melhor que for possvel na modelagem que representar um caso de uso.
Vimos que, por padro, criamos os objetos no incio do diagrama e sua destruio feita ao trmino do mesmo, quando
a rotina se encerra. Mas se precisarmos criar um objeto no
meio do diagrama, devemos colocar uma mensagem de criao chegando ao centro do objeto, e depois podemos incluir
as outras mensagens que executaro os demais mtodos. Veja
a estrutura na Figura 6.
Da mesma forma, para excluir um objeto durante a execuo
do diagrama, devemos colocar uma mensagem de destruio
chegando ao final da linha de vida, onde colocado um X,
para indicar esse fim precoce. Veja a estrutura na Figura 7.
Outra necessidade que pode surgir durante a modelagem
a chamada de um mtodo dentro da prpria classe. Suponha
que uma mensagem que chega no objeto Disciplina chame o
mtodo busca. Porm, ao encontrar a disciplina, temos que
fazer a busca de todos os objetos que estejam ligados a essa
instncia. E se um desses objetos for a prpria disciplina, que
esteja como um atributo de pr-requisito, teremos que fazer
uma nova busca, ao mesmo objeto. Essa chamada recursiva
denominada auto-chamada e representada por uma caixa de
ativao sobreposta caixa anterior. Veja exemplo na Figura 8.
Para finalizarmos, vamos conhecer os outros operadores
existentes e seus objetivos. bom lembrar que esses operadores so colocados na aba de identificao do frame com o qual
estamos trabalhando.
PROJETO
Figura 6. Sintaxe para criao do objeto

durante a sequncia de mensagens
Figura 7. Sintaxe para destruio do objeto

durante a sequncia de mensagens
Figura 5. Diagrama de Sequncias finalizado do UC Manter Candidatos
Operador ref: permite referenciar como ocorrncia de interao uma outra interao que representa uma poro comum. O
uso do operador ref permite que trechos de um diagrama de sequncia sejam isolados em pequenos frames e chamados apenas pelo
nome, evitando a duplicidade de modelagem. No s a modelagem
evitada, como a manuteno simplificada em um nico lugar.
Veja exemplo nas Figuras 9 e 10 com o uso desse operador ref.
Para entender esse exemplo, imagine um sistema de controle
acadmico, no qual na maioria das funes necessrio que
se faa uma busca do aluno, por meio de sua matrcula.
No nosso exemplo, esse trecho de busca (Figura 9) representado
apenas por uma mensagem da interface para a classe aluno, com
a chamada do mtodo busca, e depois a mensagem de retorno.
Mas esse trecho poderia ser mais complexo, com chamadas a
mais de uma classe, a mais de um mtodo. Imagine esse trecho
sendo repetido em vrios diagramas de seqncia! Alm do
Figura 8. Exemplo de auto-chamada
esforo em se reproduzir um mesmo trecho, em caso de manuteno, teramos que procurar todos os diagramas para alterao.
No momento em que extramos esse trecho de interao que se
repete em vrios lugares, e o colocamos num nico lugar, ganhamos reaproveitamento de modelo e agilidade de manuteno.
Aps o trecho ser separado, basta que faamos a sua chamada
no diagrama de seqncias que precisar utiliz-lo, por meio
da ocorrncia de interao, com o operador ref. Em vez de se
desenhar o trecho, desenha-se apenas um frame, colocando
ao centro o nome da ocorrncia de interao (Figura 10).
Tambm possvel adicionarmos parmetros de entrada e
sada a essas ocorrncias de interao. O default o parmetro
de entrada, em que nada preciso acrescentar. Para o parmetro de sada, acrescenta-se a palavra-chave out. Veja exemplo:
sd BuscarAlunoMaiorMedia (objDisciplina, out media):
objAluno
27
Figura 9. Exemplo de interao que ser referenciada
No exemplo acima, a ocorrncia de interao recebe dois

parmetros: objDisciplina e media. O parmetro objDisciplina apenas de entrada. O parmetro media deve retornar
preenchido, pois um parmetro de sada. O retorno da
funo ser o objAluno que indicar quem o aluno que
tem a maior mdia. Assim, conseguimos que o retorno do
Diagrama de Sequncias ter dois valores de retorno: o
objeto que representa o aluno com maior mdia e a prpria
mdia desse aluno.
Operador opt: permite definir um trecho da interao como
opcional. Similar ao que acontece com o operador alt,
colocado no topo, ao centro, uma condio que indicar se
o bloco ser executado ou no.
Suponha que temos um diagrama de sequncias que recebe
o valor vendido de um produto, para atualizar o estoque.
Logo depois de chamar o mtodo que faz a atualizao do
estoque, o sistema deve checar se o estoque do produto atingiu o valor mnimo. Se atingiu, deve emitir um pedido de
compra, enviar um alerta para o gerente da rea e um outro
para o setor de compras. Imagine que so vrias mensagens
que dependem da resposta do teste:
[estoque.valorAtual <= estoque.valorMinimo]
Figura 10. Diagrama de sequncias com uma ocorrncia

de interao para o trecho Busca Aluno
Nesse caso, indicamos um intervalo mnimo e mximo para

repetio com uma condio de parada. Se no houver a condio de parada, que opcional, o bloco ser repetido tantas
vezes quanto for o intervalo entre o valor mnimo e o mximo.
Veja exemplo:
loop 1, 3 [senha not OK]
O exemplo indica que o trecho marcado com o operador

loop ser executado no mnimo, uma, no mximo, trs vezes.
Contudo, o trecho s ser executado enquanto a senha no
estiver OK. Ento, se aps a primeira vez, a senha estiver OK,
o trecho abandonado, continuando o processamento logo
aps o fim do frame do operador loop. Se aps a terceira vez,
a senha continuar invlida, mesmo assim o trecho ser abandonado, pois se atingiu o limite mximo de trs tentativas.
Concluso
Neste artigo foi apresentado o uso do diagrama de sequencia.

Percebemos que integrando corretamente os casos de uso,
diagrama de classes e o diagrama de sequncias, temos um
modelo completo para implementao da maioria dos sistemas
orientados a objetos.
Referncias
28

D
s
Feedback
eu
edio
ta
Operador loop: permite a repetio de um trecho da interao.
MELO, Ana Cristina. Desenvolvendo aplicaes com UML 2.0: do conceitual implementao.
Rio de Janeiro: Brasport, 2004.
sobre e
s
Na verso antiga da UML, teramos que repetir a condio

em todas as mensagens, para que no houvesse dvida de
que todas elas eram dependentes da mesma condio.
Na verso nova, basta envolvermos todas essas mensagens num frame e identific-lo com o operador opt. Como
condio de guarda colocamos o teste citado acima. Isso
significa que o trecho indicado pelo frame s ser executado
se o valor atual do estoque estiver menor ou igual ao valor
mnimo de estoque.
PROJETO
29
Testes de Software, um processo criativo
Melissa Barbosa Pontes

melissa.pontes@cesar.org.br
Mestre em Engenharia de Software do Cesar.EDU. Certificada em testes de software

pelo ISTBQ (International Software Testing
Qualification Board), atualmente trabalha
como engenheira de testes no CESAR (Centro
de Estudos e Sistemas Avanados do Recife),
onde desempenha atividades de definio
de processos, liderana e consultoria. integrante do GrIT (Grupo Independente de
Testes do Cesar) atravs do qual realiza pesquisas e treinamentos em testes na organizao. Possui artigos e trabalhos publicados
em eventos internacionais. membro integrante da comisso de organizao de EBTS
- Encontro Brasileiro de Testes de Software,
que j se encontra na quarta edio.
30
m importante fator de sucesso

de um software sua qualidade.
Existem diversas maneiras de
se avaliar a qualidade de um produto,
uma dessas maneiras a realizao de
atividades de testes de software por
uma equipe especializada no assunto.
O principal objetivo dessas atividades
descobrir se o produto est de acordo com
as exigncias do cliente. A introduo
dessas atividades em uma organizao
deve ser feita de maneira estruturada, de
forma que lhe permita uma boa definio
de quais atividades devem ocorrer em um
projeto, em que sequncia e por quem
estas devem ser realizadas.
O Processo de Testes de Software
As atividades de testes de software so

diversificadas, e so mais bem desempenhadas se estiverem organizadas em um
processo. Koomen, em seu livro chamado
Test Process Improvement: A step-bystep guide to structured testing, estima
que entre 25% e 50% dos custos e esforos
de um projeto so gastos com testes. Da
a importncia de investimentos em definio e melhoria de um bom processo de
testes de software para uma organizao.
Engenharia de Software Magazine - Testes de Software, um processo criativo

Este artigo aborda o tema processo de testes de
software mostrando uma maneira de agrupar
as atividades de testes em etapas, com objetivos
bem definidos. Ele mostra que a organizao das
atividades pode ter um impacto positivo significativo na qualidade do produto gerado, e que
muito mais do que burocracia preciso criatividade para um bom desempenho de tais atividades.
Para que serve?

Uma maneira de se avaliar a qualidade de um produto atravs da realizao de atividades de testes.
Porm, se essas atividades forem realizadas de maneira ad-hoc, ou seja, sem um planejamento nem
estruturao, pode no ficar to evidente a dimenso da contribuio que os testes podem trazer para
a qualidade de um produto. Por isso, fundamental
a definio e utilizao de um processo para guiar a
equipe de testes na conduo de suas atividades.

Uma vez entendida a importncia da realizao de
testes em um projeto, prudente que estas comecem
de maneira mais estruturada possvel. A viso geral
de um processo de testes fornecida por este artigo d
uma idia de como implantar as atividades de testes
em uma organizao com um mnimo de organizao.
VALIDAO, VERIFIC AO & TESTE
Essas atividades devem iniciar o quanto antes em um projeto

de desenvolvimento, se possvel no primeiro dia do projeto.
Dessa maneira, defeitos podem ser identificados o quanto
antes no produto, minimizando os custos da sua correo.
Isso nos leva a concluir que no uma prtica vantajosa tratar
testes como uma nica atividade de execuo, e deix-las para
o final do projeto. Isso poder gerar uma corrida por correes
de defeitos, e estudos mostram que quanto mais modificado
um cdigo, maior a propenso desse cdigo ao aparecimento
de mais defeitos. Esta constatao pode ser evidenciada pelo
trabalho de Naggapan, publicado no artigo Use of relative code
churn measures to predict system defect density, no ano de 2005.
De maneira simplificada, o processo de testes pode ser ilustrado como na Figura 1.
Figura 1. Processo de testes
Na maioria dos casos, as fases do processo acontecem em

sequncia, como apresentado na figura, e nada impede de voltarmos para uma fase anterior para melhorar suas atividades.
Trata-se de um processo com atividades e papis bem definidos, e necessria muita criatividade em quase todas as
etapas. A equipe deve estar segura de que elaborou diversos
cenrios diferentes para avaliar a aplicao. Tambm deve ter a
certeza de que os executores de teste souberam discernir entre
um produto de qualidade e um produto que ainda no est
pronto para ir ao mercado, e utilizaram sua percepo sobre o
produto para influenciar decises tomadas pela alta gerncia.
Vrias atividades do processo podem ser realizadas de forma
automtica, mas isso no o foco deste artigo.
A seguir, falaremos um pouco sobre cada atividade, dando
uma viso geral.
Planejamento de Testes
Objetivo Principal: Elaborar uma estratgia de testes para

o projeto e definir como esta ser implementada. Tudo isso
deve ser documentado no Plano de Testes, artefato principal
desta etapa.
Planejar comea com um bom entendimento de contexto.
Antes de dar inicio s atividades de testes propriamente ditas,
a equipe deve entender o objetivo do projeto em questo, e
somente a partir da, definir o objetivo dos testes, que pode ser:
identificar novos defeitos, checar se novas implementaes no
quebraram algo que funcionava antes, homologar a aplicao
junto ao cliente, etc.
Entender o objetivo do projeto significa estar alinhado com
as necessidades do cliente, alm de entender quais riscos este
projeto apresenta e levant-los com antecedncia.
Comear o planejamento com a definio do escopo fundamental. Para saber como testar, necessrio saber o que ser
testado. E tambm importante saber o que no ser testado, e

o porqu. A partir da que a equipe consegue definir melhor
o tempo que levar para realizar as atividades, quantas pessoas
devem ser envolvidas e se ser ou no necessria a utilizao
de ferramentas, por exemplo.
A estratgia a alma do planejamento de testes, mas o planejamento envolve muito mais do que elaborar a estratgia. Nesse
momento deve ser identificado de que maneira os testes vo
ser organizados, quem vai escrev-los, quem vai execut-los,
e em que momento a equipe poder parar de testar.
Devem ser definidos quais os nveis de testes que vo ser
realizados no projeto. Uma boa definio de nveis de teste
pode ser encontrada no artigo Introduo a Teste de Software,
publicado na primeira edio desta revista, por Arilo DiasNeto. Para cada nvel de teste, deve-se definir quantos ciclos
de teste sero executados. Um ciclo um conjunto de testes
pronto para execuo.
Tambm faz parte da estratgia o nvel de cobertura dos
testes. Dentro do escopo definido, a equipe deve decidir se
vai exercitar todo o cdigo, ou se uma porcentagem dele j
suficiente. Esse critrio de cobertura do cdigo, ou dos
requisitos, somado aos defeitos encontrados, ajudam a
definir o critrio de parada dos testes. Como a equipe sabe
se testou o suficiente? A resposta para essa pergunta deve
estar no plano de testes.
Deve-se buscar toda a informao que for possvel em relao
ao projeto. Ento, documentao de requisitos e casos de uso,
caso existam, ajuda muito, mas nem sempre so suficientes.
E por que no so suficientes? Porque podem estar errados,
ambguos ou mal escritos. Se esses documentos estiverem mal
escritos podem at atrapalhar o time de testes.
Se envolver em reunies de planejamento do projeto ajuda
a identificar o que mais importante no produto e que reas
representam riscos para a gerncia e para a equipe de desenvolvimento. Ainda, saber quando o software deve ser lanado
no mercado, qual o seu pblico alvo, qual a estratgia de
marketing e qual a mensagem que a organizao quer passar
para o pblico com o produto desenvolvido.
Se os usurios esperam um produto fcil de usar, os testes
devem identificar se tudo est em conformidade com esse
aspecto. Caso o produto tenha que dar respostas rpidas ao
usurio, muda completamente o tipo de teste que verifica essa
caracterstica, porque nesse caso, o desempenho da aplicao
deve ser analisado. E a, a partir do que se espera do produto,
vai se modelando a estratgia de testes, que consiste em identificar que tipos de testes vo ser realizados para cada rea da
aplicao, em qual momento, e com qual intensidade.
Todo o conhecimento adquirido em relao ao projeto vai
compor o que na prtica chamamos de orculo. No livro
Software Testing Foundations, Spillner explica que orculo
um mecanismo de obteno dos resultados esperados.
atravs do orculo, dentre outras coisas, que a equipe de
testes vai conseguir identificar com mais segurana se j
realizou testes suficientes para poder emitir uma opinio
sobre a qualidade do produto.
31
Assim como em todas as atividades de um projeto, as atividades de testes tambm podem ser impactadas por problemas que
chegam a inviabilizar sua realizao. Por isso, importante que
a equipe identifique riscos para minimizar o impacto desses
incidentes no projeto.
Exemplos do que podem atrapalhar as atividades de testes
so: atraso na entrega do cdigo, pela equipe de desenvolvimento, falta de ferramentas e ambiente adequado, imaturidade
da equipe de testes, e muito mais. Tudo deve ser registrado
no plano de testes e algum direcionamento deve ser dado a
esses problemas.
objetivo do teste pode ser alcanado. Alm disso, o teste pode

ter uma pr-condio, que indica o que necessrio para a
sua realizao.
Mais informaes podem estar presentes em um caso de teste,
mas no momento, ficaremos com um exemplo bem simples,
somente para dar a idia do que se trata. A Figura 2 traz um
exemplo de como se escreve um caso de teste para um requisito
de login de uma aplicao.
Especificao de casos de teste
Objetivo: Produzir uma sute de testes, ou seja, um conjunto

de casos de teste.
Essa fase tambm conhecida como fase de projeto de testes.
Este projeto pode ser de execuo manual, semi-automtica ou
automtica. Caso seja manual, os casos de testes sero escritos
e podem ser armazenados em planilha excel, documento do
Word, ou ferramenta de gerenciamento de casos de teste. Caso
seja semi-automtica ou automtica, sero gerados scripts
aps a escrita manual, e sero desenvolvidos em linguagem
de programao. Neste artigo, daremos foco aos casos de
testes manuais.
De onde vm os casos de teste? Eles podem ser elaborados a
partir de diversas fontes, inclusive da imaginao de quem os
est escrevendo. Geralmente os casos de teste so escritos com
base nas documentaes do projeto, e tm o objetivo de checar
se o software funciona corretamente e principalmente se est
de acordo com o que foi especificado pelo cliente.
Que documentaes de projeto podem dar origem a casos
de teste? Na maioria das vezes so os requisitos e casos de uso
especificados, mas nada impede, e at aconselhvel, que toda
a documentao existente seja analisada. Isso ajuda no entendimento do objetivo do projeto e da sua criticidade para o cliente.
Ento, o projetista de testes, ou desenhista, como chamada
a pessoa que escreve os casos de teste, depois de entender o
objetivo dos seus testes, a chamada misso de testes, deve
imaginar os cenrios atravs dos quais tentar encontrar os
defeitos na aplicao.
Consultando o plano de testes, o projetista identifica para
quais funcionalidades da aplicao ele deve escrever testes
em dado momento. Na seo de escopo dos testes do plano
devem estar definidos, atravs de um trabalho realizado na
fase anterior do processo, quais so os requisitos a ser testados e que tipos de testes (funcionalidade, carga, desempenho)
podem ser aplicados a aqueles requisitos. O trabalho agora
dizer como testar.
Sero elaborados os roteiros que vo ajudar os executores de
testes a analisar o produto.
Com o que se parece um caso de teste?
Um caso de teste simples deve conter: um objetivo, que os
testadores devem tentar alcanar; um passo a passo, mais
conhecido como procedimento de teste, atravs dos quais o
32
Figura 2. Exemplo de Caso de Teste
Quanto mais casos de testes, melhor!

Muita criatividade, alm da documentao disponvel,
necessria para se escrever bons e diversificados cenrios de
testes. preciso imaginar o que outras pessoas no pensaram. Explorar mentalmente as diversas maneiras de utilizar
a aplicao, tentando fazer com que a mesma levante todas as
excees, provocar para que ela d mensagens de erro, imaginar de que maneira as funcionalidades poderiam apresentar
um comportamento inesperado. Geralmente a forma como o
sistema no deve funcionar no est especificado.
Um projeto de testes escrito sem criatividade fica muito parecido com os requisitos e casos de uso. O mais indicado ter
quantos casos de testes forem possveis para cada requisito
da aplicao.
Podemos ento deduzir que quanto mais cenrios forem
elaborados, mais bem testada estar a aplicao. Cuidado
com essa afirmao, pois a gerao de muitos cenrios, sem
um direcionamento correto, pode trazer alguns problemas
para a equipe:
1. Exploso de casos de teste. O projetista pode escrever
tantos cenrios que o time no ser capaz de execut-los
no tempo que dispe;
2. Casos de testes repetidos. Pode ocorrer que alguns testes,
aparentemente diferentes, exercitam o mesmo trecho de
cdigo do software, no agregando nenhuma informao
nova para a equipe, e consumindo tempo de escrita,
execuo e anlise de seu resultado;
3. Dificuldade de manuteno da sute de testes. Gerenciar
uma grande quantidade de casos de teste pode ser tornar
uma tarefa exaustiva e desmotivadora. Alm de propiciar

o aparecimento de erros humanos.
Como ento minimizar o impacto das dificuldades mencionadas acima?
1. Definir prioridades. Projetar o que mais crtico e mais
importante primeiro. Alm de classificar os casos de
testes por nveis de prioridade. Casos de testes muito
importantes podem receber uma identificao, o que vai
fazer com que as pessoas sempre olhem para eles na hora
de compor um ciclo de execuo de testes;
2. Escolher os melhores cenrios. De que maneira? Existem
vrias tcnicas na literatura que ajudam os projetistas a
identificar bons cenrios para encontrar defeitos, e ainda
ajudam a no repetir casos de teste. O artigo Introduo a
Teste de Software, de Arilo Dias-Neto, j mencionado anteriormente, traz uma breve explicao sobre essas tcnicas;
3. Elaborar uma matriz de rastreabilidade, que uma correspondncia entre os requisitos da aplicao e os casos
de teste. Dessa maneira, cada vez que um requisito for
modificado ou removido, fica mais fcil saber quais casos
de testes so impactados pela mudana, facilitando a
manuteno da sute de testes.
Alm da escolha do cenrio, deve-se ter muito cuidado na
escrita do caso de teste. Embora escrever um caso de testes parea uma atividade simples, existem algumas armadilhas que
devem ser evitadas porque podem causar problemas no futuro.
Comeando pelo objetivo do caso de testes:
1. Este deve ser simples e direto, contendo uma nica finalidade. Isso vai evitar que o testador se confunda em
relao ao que deve fazer. Tambm vai evitar que um
caso de teste tenha metade de seu objetivo passando,
e metade dele falhando, o que provocaria confuso no
momento de decidir se esse teste passou ou falhou;
2. Deve ter base nos requisitos, mas foco no usurio final. O
que isso quer dizer? Que os requisitos no so perfeitos
e o testador tem que por suas impresses, como pessoa,
para avaliar se tudo est indo bem;
3. So mais importantes do que o procedimento. Porque o
procedimento de testes escrito por um projetista, nem
sempre a nica maneira de se atingir o objetivo. s vezes
d para chegar ao mesmo lugar por diversos caminhos.
O que dizer sobre procedimentos de testes?
1. No devem divergir do objetivo do caso de teste. Supondo que o objetivo do caso de teste seja alcanado, e
somente um passo do seu procedimento, divergente do
objetivo, esteja falhando, vai ser trabalhoso para quem
vai analisar mtricas de testes contabilizarem testes que
esto passando ou falhando;
2. Devem ter a menor quantidade de passos possvel. Um
caso de testes com muitos passos pode ser um indicativo de que o seu escopo est muito grande, indo alm
do objetivo principal, ou que o objetivo no est claro;
3. Se possvel, devem ter seu passo a passo escrito em

alto nvel. Em vez de escrever Clique no boto OK,
pode ser melhor escrever Confirme a operao. Isso
vai evitar muito retrabalho caso itens da tela sejam
redefinidos, por exemplo. A no ser que a situao seja
um teste especifico de rtulos da tela.
Se os casos de teste no forem simples e fceis de gerenciar,
fica difcil medir o progresso do projeto em relao quantidade de testes passando.
Execuo de testes
Objetivo: Executar os casos de testes especificados na fase

anterior com o objetivo de encontrar defeitos na aplicao.
A primeira coisa a fazer ento quando o projeto est na
fase de execuo de testes preparar o cenrio para que tudo
acontea como planejado nas fases anteriores. O plano de testes
deve ser analisado para entender como ser o ambiente dessa
execuo. E este ambiente deve ser preparado para os testes,
caso contrrio, essa atividade pode at chegar a ser suspensa,
ou mesmo cancelada.
Em seguida, os ciclos de testes devem ser criados. Um ciclo
de teste uma maneira de definir o escopo da execuo em
determinado momento. Em um ciclo devem entrar somente os
casos de testes que sero executados. Como organizar ento
um ciclo de execuo de testes? Pelo contexto. Responder algumas perguntas pode ajudar, tais como: quais funcionalidades
foram recentemente implementadas? Caso se deseje testar
coisas novas; reas antigas do sistema ainda continuam funcionando corretamente? Caso o time esteja querendo analisar
o impacto da integrao de novas funcionalidades no restante
da aplicao. Esses so alguns exemplos de como escolher os
testes para um ciclo.
Definido o ciclo, que deve estar de acordo com o contexto
e com o plano de testes, chega o momento de comear a execuo propriamente dita. Por onde comear ento? Uma dica
organizar testes que tenham configuraes semelhantes
como pr-requisito para execuo, e atribu-los para a mesma
pessoa da equipe. Com essa prtica, a equipe ganha tempo
configurando o ambiente apenas uma vez, e executando todos
os testes de uma vez.
Em geral, os executores de testes devem pegar os roteiros
definidos pelos projetistas e segui-los com o foco no seu objetivo. Caso a aplicao se comporte de maneira diferente do
que o caso de teste especifica, pode ser que realmente haja um
defeito no software, e esse caso de teste ento deve falhar. Da
mesma maneira, caso a aplicao se comporte de forma da
mesma maneira que o caso de teste especifica, este teste deve
passar. Um terceiro estado tambm pode ser atribudo como
resultado de um caso de teste. Este pode ser bloqueado, se por
algum motivo se encontrar impedido de ser executado. Os
defeitos encontrados devem ser registrados para futura anlise.
Quase sempre, da maneira descrita acima que as execues
de teste acontecem, mas isso no uma regra. Um caso de teste
divergente do comportamento da aplicao pode no significar
33
que um defeito de software foi encontrado, mas sim que um

defeito no caso de teste existe. A equipe deve estar atenta a
esse tipo de situao para melhorar o produto e o processo.
Realizar testes com roteiro e ainda usar a criatividade. Isso
possvel?
Em geral, testadores se baseiam nos casos de teste, e seguem
o seu roteiro para testar a aplicao em questo. Mas, para a
obteno de um melhor resultado com a execuo de testes,
recomendado que o roteiro sirva somente como um cenrio
bsico. Seguir o roteiro sem limitar-se a eles uma prtica que
agrega muito valor ao projeto, pois permite ao time contar com
a criatividade dos executores de testes tambm. Executores
devem sentir-se livres para testar sua imaginao no projeto
e relatar tudo o que puderem observar.
O que se pode observar com essa prtica que muito mais
defeitos so encontrados com um s caso de teste.
Pode haver defeitos sem casos de teste associados?
Em um projeto onde todos contribuem com sua imaginao,
isso geralmente acontece. Isso comprova que nem sempre os
projetistas de testes conseguem pensar em todas as situaes
possveis de uso da aplicao. Esses novos cenrios encontrados pelos executores de teste devem ajudar na definio de
novos testes a serem includos na sute para serem realizados
nas prximas verses do cdigo.
Anlise de Resultados
Objetivo: Avaliar os resultados da execuo dos testes e analisar se tudo est de acordo com o que se esperava do produto.
Uma vez que o ciclo de teste foi realizado e os defeitos encontrados foram registrados, um relatrio de defeitos deve ser
construdo para relatar tudo o que aconteceu. Devem constar
nesse relatrio quais foram os casos de teste que entraram no
ciclo, qual o resultado de cada um, quais defeitos foram abertos
e a que caso de teste eles esto relacionados, qual a verso do
software analisada, quem foram os testadores envolvidos nessa
execuo. Outras informaes tambm podem ser definidas
pela equipe do projeto.
Neste momento deve-se analisar se o produto est de acordo
com o critrio de aceitao definido no incio do projeto, mas
no podemos concluir muito sobre a qualidade do produto
baseando apenas nos resultados dos casos de teste. A equipe
deve se basear em todo o processo utilizado em testes para
chegar a uma concluso mais confivel. Um processo de qualidade d mais confiana a equipe de testes na hora de opinar
sobre o estado da aplicao.
A fase de anlise deve ser um trabalho completo, analisando
o produto e o processo. E o resultado dessa anlise deve dar
subsdios que ajudem em vrias decises, tais como:
1. Decidir se o produto est pronto para ser lanado no
mercado, ainda que possua alguns defeitos;
2. Corrigir defeitos crticos antes de liberar o produto;
3. Executar mais testes, inclusive elaborando novos cenrios;
4. Melhorar a escrita e / ou cobertura dos casos de teste.
34
Muitos testes falharam. O software est ruim?

Pode no ser esta a questo. Os casos de teste podem estar
desatualizados, ou mal escritos, e isso pode causar problemas
de entendimento na hora da execuo. Em times pequenos,
geralmente os casos de teste so escritos por uma pessoa s,
que em fases iniciais do projeto pode ter se baseado em requisitos ainda imaturos.
O conhecimento de como a aplicao funciona verdadeiramente fica mais evidente quando o testador est vendo o produto, o que pode gerar alteraes nos casos de teste ou mesmo
nos requisitos do projeto. Essa questo deve ser avaliada com
cautela antes de tirar concluses sobre o produto.
Melhoria de um Processo de Testes
Por mais simples que seja um processo de testes, ele pode

ser melhorado. Porm, Rex Black, em seu livro Advanced
Software Testing, ressalta um ponto muito importante.
Embora existam algumas frentes para a melhoria de processos de software, tais como: CMM (Capability Maturity
Model), CMMi (Capability Maturity Model Integration)
e SPICE (Software Process Improvement and Capability
dEtermination), deve ficar claro que a busca por qualidade nesses modelos no se d atravs de testes como o
principal caminho.
Devido esta lacuna que os modelos mencionados acima
deixam, alguns modelos foram propostos para melhoria de
processos de testes especificamente. Alguns deles so:
Critical Testing Process (CTP);
Systematic Test and Evaluation Process (STEP);
Test Maturity Model (TMM);
Test Process Improvement (TPI).
No entraremos em detalhes em relao aos modelos acima,
deixando este assunto para ser abordado em um trabalho
futuro.
Concluses
Apesar de termos um processo que permite a organizao

e sequenciamento das atividades de teste de software, muito importante investir na capacitao das pessoas que vo
desempenh-las. A literatura est repleta de tcnicas e prticas para a realizao de testes, mas preciso conhecimento
do assunto para escolher o que melhor utilizar, levando em
considerao o contexto.
A certeza de uma boa estratgia de testes um bom ponto de
partida, seguida de um projeto de testes com boa cobertura dos
requisitos da aplicao e definio de bons cenrios.
Embora o objetivo das atividades de testes seja encontrar
defeitos no produto, no significa que a fase mais importante
do processo inteiro seja a execuo dos testes. Todas as fases
do processo tm grande importncia em um projeto.
Diversas iniciativas existem na literatura com a finalidade de
propor melhorias em processos de teste, isso deve ser analisado
para que as organizaes possam realizar testes de maneira
cada vez melhor.
Agradecimento
Referncias
Gostaria de agradecer Marcelle Frazo D. C. de Arajo e

Mariana Pinto Xavier pela leitura e contribuies pertinentes
fornecidas para a melhoria deste artigo.
Foundations of Software Testing: ISTQB Certification -Dorothy Graham, Erik van

Veenendaal,Isabel Evans, Rex Black (2007)
The Art of software Testing. Glenford J. Myers (1979)
sobre e
s

Feedback
eu
edio
ta
D
s
Test Process Improvement: A step-by-step guide to structured testing. Tim Koomen, M. Pol
(1999).
Use of relative code churn measures to predict system defect density. Nachiappan Naggapan,
Tomas Ball (2005).
Software Testing Foundations: A Study Guide for the Certified Tester Exam. Andreas Spillner,
Tilo Linz, Hans Schaefer. (2007).
Introduo a Testes de Software. Arilo Dias-Neto. (2008). Artigo publicado na edio 1 da
revista Engenharia de Software.
35
Manuteno: Desafios para os Testes numa

Fbrica de Software
Dificuldades e sugestes para ganhar produtividade e qualidade nas
atividades de testes em uma fbrica de software
Neste artigo veremos dicas e sugestes para superar os principais desafios e entraves associados
s atividades de testes na manuteno de softwares em um ambiente de Fbrica de Software.
S
Daniel Scaldaferri Lages
dlages@gmail.com
Possui MBA em Gerncia de Projetos pela

Fundao Getlio Vargas, ps-graduado
em Gerncia de T.I. pela Universidade FUMEC e Bacharel em Cincia da Computao
pela UFMG. Atualmente Coordenador da
equipe de Quality Assurance da CPM Braxis,
filial BH. Sua experincia profissional inclui
o cargo de Analista de Testes no Synergia
(ncleo de engenharia de software do Departamento de Cincia da Computao da
UFMG), Gerente da fbrica de software na
Unitech (hoje CPM Braxis) e docncia no curso de graduao de Sistemas de Informao
na PUC-MG. Possui a certificao ITIL para
gerenciamento de servios de T.I. certificado em testes de software pela ISTQB e em
qualidade de software pela IBM.
36
e uma pesquisa fosse realizada

com os desenvolvedores e testadores de uma Fbrica de Software
sobre a preferncia entre participar de
novos projetos (aqueles iniciados do
zero), ou projetos de manuteno, seria
possvel arriscar que a grande maioria
ficaria com a primeira opo. Apesar da
atividade de manuteno de um software ser uma tarefa to desafiadora quanto
a criao de um novo, para muitos, participar de um projeto desde o incio
uma tarefa mais motivante e prazerosa.
Muitas vezes mais simples, pois quem
participa desde o incio do projeto tem
mais tempo para assimil-lo, obtendo
um grau satisfatrio de domnio das suas
regras e arquitetura, diferentemente de
um sistema a ser mantido.
O maior pesadelo para as fbricas de
software so os sistemas que surgem de
maneira no planejada. Eles nascem da
seguinte forma: um funcionrio de uma
empresa cliente que possui conhecimentos em informtica ou em alguma
linguagem de programao, com o intuito de automatizar um processo para
Para que serve?

As dicas e as sugestes apresentadas servem para
tornar as atividades de testes de software mais
produtivas dentro do processo de manuteno de
software, visto que esperado que uma Fbrica
de Software realize o servio com qualidade no
menor tempo possvel.

Empresas e profissionais que prestam servios de
manuteno em diversos sistemas, assim como
as empresas clientes, que tenham interesse em
melhorar o processo de desenvolvimento e de
testes de software, obtendo resultados em mdio e longo prazo.
agilizar seu trabalho ou do seu chefe,

cria um sisteminha. Uma planilha do
excel com macros, ou uma simples pgina web, o que seja. Esse sisteminha
apresentado para o chefe, que o aprova e
solicita novas funcionalidades ao longo
Engenharia de Software Magazine - Manuteno: Desafios para os Testes numa Fbrica de Software
do tempo. Chega um determinado momento que o sisteminha torna-se um sistemo, com informaes importantes
sobre aquela rea de negcio. Ento decide-se que o servidor,
normalmente localizado debaixo da mesa do funcionrio, deve
ser passado para a rea de TI da empresa, que imediatamente
repassa para a fbrica. Sem documentao, sem padronizao,
sem boas prticas de programao etc. O Frankstein est ali,
pronto para ser entendido e mantido.
A viso sobre a manuteno de software no algo positivo.
Esse olhar negativo dos envolvidos possui vrios motivos
comumente vividos pelas Fbricas de Software que oferecem
esse tipo de servio. A manuteno exige a anlise, na maioria
da vezes, de cdigos mal escritos, sem comentrios, despadronizados, ou seja, com baixa manutenibilidade. Mas isso que a
torna uma tarefa desafiadora! Em um curto espao de tempo
(pois geralmente o prazo para manuteno bem mais curto
em relao ao desenvolvimento de novos sistemas, devido
urgncia), a capacidade analtica e investigativa deve entrar em
ao com rapidez e qualidade para satisfazer as necessidades
do cliente. Isso serve tanto para desenvolvedores quanto para
testadores. Mesmo quando o cdigo possui uma boa qualidade,
no bem visto, pois foi criado por outras pessoas, que possuem diferentes formas de pensar e codificar. natural do ser
humano querer fazer do seu jeito, da maneira como aprendeu
e sente maior confiana.
Este artigo, baseado na experincia do autor, relata brevemente as principais dificuldades encontradas na manuteno de um software na perspectiva dos testes, levando em
considerao a qualidade e agilidade a que uma Fbrica de
Software se propre. Para cada problema so sugeridas aes
para minimizar essas dificuldades.
Fbrica de Software
Para que seja possvel entender os problemas relacionados
aos testes de software em manutenes, deve-se conhecer o
ambiente onde os testes sero realizados. Segundo [HERBSLEB], as Fbricas de Software so definidas como organizaes
que fornecem servios de desenvolvimento de sistemas com
qualidade, a baixo custo e de forma rpida. Utilizando um
processo de desenvolvimento de software bem definido e com
apoio de tecnologias de mercado, alm de reconhecer e lidar
com oportunidades de melhoria do seu processo.
Atravs do conceito de [HERBSLEB], fica clara a imensa
expectativa dos clientes quanto ao retorno na contratao de
uma Fbrica de Software, principalmente quanto agilidade e
qualidade dos servios. Desta forma, para satisfazer o cliente,
o processo de manuteno deve ser certeiro, e estar preparado
para enfrentar sistemas Frankstein.
As Fbricas de Software no desenvolvem apenas novos
sistemas. Muitas delas, pelo contrrio, realizam manutenes
como sua atividade principal. Alteram sistemas desenvolvidos
por elas mesmas, mas tambm sistemas legados. O primeiro
grupo apresenta certas vantagens para fbrica em relao ao
segundo, pois como ela desenvolveu, teoricamente possui o conhecimento de todo o sistema. Conhecimento este presente na
forma de documentaes ou de capital intelectual da empresa.

Sistema legado, conforme [WARD e BENNET] pode ser definido como aquele que executa tarefas teis para a organizao,
mas que foi desenvolvido utilizando-se tcnicas atualmente
consideradas obsoletas. Segundo [SERRA], o sistema legado
nos passa a impresso de serem antigos e ultrapassados, de no
possuir especificao, modelagem de soluo, documentao
de regras de negcio, alm do cdigo ser despadronizado.
A manuteno de sistemas legados uma atividade altamente
desempenhada pelas Fbricas de Software. Muitas delas so
responsveis por manter uma quantidade enorme de sistemas,
de diversas tecnologias e diferentes domnios de aplicao.
Devido expectativa e cobrana sobre os resultados de uma
Fbrica de Software, juntamente com os problemas enfrentados
na manuteno desses sistemas de baixa manutenibilidade,
torna-se um desafio oferecer um servio de qualidade.
Manuteno do Software
A vida de um software no termina aps a sua implantao.
Ele ainda viver durante muito tempo. Ser utilizado por anos,
e com certeza, ter muitas atualizaes, gerando novas verses
do sistema. De acordo com [IEEE], a manuteno caracterizada pela modificao do software j entregue ao cliente, ou
seja, a manuteno qualquer alterao no software aps sua
entrada em produo.
Conforme [SPILLNER, LINZ e SCHAEFER], o propsito da
manuteno de software diferente da manuteno de produtos industrializados, pois a manuteno realizada no feita
para reparar danos causados pelo tempo de uso do software.
Defeitos no so introduzidos pelo tempo e nem pela carga
de utilizao. Os defeitos encontrados j existiam, antes do
software entrar em produo. Por algum motivo, no foram
detectados em fases anteriores. Mas a manuteno no se
caracteriza apenas por correes. De acordo com [LIENTZ],
existem trs tipos principais de manutenes em softwares,
Adaptativas, Corretivas e Evolutivas (Perfectivas):
Adaptativas: so alteraes que visam adaptar o software a
uma nova realidade ou novo ambiente externo, normalmente
imposto. Um exemplo claro seriam mudanas de leis ou regras,
definidas pelo governo e/ou rgos reguladores;
Corretivas: como o prprio nome diz, servem para eliminar
as falhas encontradas em produo. bastante comum, principalmente quando o processo de desenvolvimento no se
preocupou de maneira adequada com a qualidade do software;
Evolutivas: so alteraes que visam agregar novas funcionalidades e melhorias para os usurios que as solicitaram. No
se deve confundir esse tipo de manuteno com as entregas
programadas de um processo de desenvolvimento interativo.
A integrao com outros sistemas tambm considerada um
tipo de evoluo.
As migraes para novas tecnologias, sejam de hardware ou
software, podem causar dvidas quanto classificao do tipo
de manuteno. Se a tecnologia foi imposta, a manuteno
classificada como adaptativa. Se a tecnologia uma soluo de
37
melhoria do sistema, classificada como evolutiva. [PAULA

FILHO] ainda cita mais um tipo de manuteno, a chamada
preventiva. Esta procura localizar os defeitos antes que se
manifestem em operao. Entretanto, raramente praticada.
A proporo do esforo de manuteno, segundo [LIENTZ], aps
estudos com 487 organizaes da rea, de 20% para corretivas,
25% adaptativas, 50% evolutivas e apenas 5% para preventivas.
A seguir sero apresentadas situaes que dificultam os testes
aps as manutenes nos softwares terem sido realizadas.
Frequncia das Manutenes

Este um problema que ocorre principalmente em Fbricas
de Software de grande porte, que possuem vrios clientes, e
que so responsveis por vrios sistemas distintos, implementados em diversas tecnologias. normal que alguns sistemas
sejam mais alterados que outros. Essa diferena impacta no
desenvolvimento e nos testes do sistema.
O problema da frequncia de manutenes realizadas pode
ser percebida claramente quando se compara a qualidade do
servio de manuteno entre sistemas com alta e baixa frequncias de alteraes. Quando a frequncia alta, normalmente
a equipe responsvel pelo sistema maior e mais capacitada.
A Fbrica de Software identifica e se prepara para atend-lo da
melhor forma, logicamente. Com uma equipe grande, maior o
nmero de responsveis pelo sucesso e, o que mais importante, o conhecimento melhor disseminado. Dessa forma, os
testes de software so mais fceis, pois existe um conhecimento
e um suporte (dos desenvolvedores aos testadores) adequado
sobre o sistema. A prtica e o conhecimento sobre o sistema
se tornam sempre recentes.
Mas quando a frequncia baixa, ou muito baixa, torna-se
um grande problema, indo contra as caractersticas do servio
prestado em sistemas com alta frequncia de manuteno.
Como por exemplo, o conhecimento deixa a desejar, pois como
no existe a prtica, ele se perde ao longo do tempo. Tambm
no existe um guru do sistema. O profissional que est
disponvel naquele momento que ser o responsvel pelo
servio de manuteno, mesmo que no domine a tecnologia
do sistema. Os testes so difceis, pois no se tem conhecimento
amplo do sistema, tornado-os pouco efetivos.
Esse problema agravado pelo fator rotatividade dentro
de uma empresa. A mesma pesquisa realizada por [LIENTZ],
citada anteriormente, diz que quanto mais antigo o sistema,
maior o esforo que deve ser empregado em sua manuteno.
A fbrica, tambm, torna-se mais sujeita a perder o conhecimento em torno deste sistema, devido rotatividade dos
profissionais. Isto , como a frequncia de manuteo baixa,
o profissional que realizou a ltima manuteno no sistema
pode j no estar mais na equipe. Consequentemente, caso
aes para reter o conhecimento no tenham sido tomadas,
este conhecimento tambm no estar mais na empresa.
Uma das solues, que no trar resultados imediatos, mas a
mdio e longo prazo, e manter o conhecimento dentro da empresa a elaborao e o reuso dos casos de testes. Tendo como
premissa que uma fbrica preza pela qualidade dos servios,
38
especifica os casos de testes referentes alterao realizada

como parte integrante do seu processo, a preocupao recai
sobre uma forma fcil de reusar os casos de testes.
O reuso dos casos de testes tornam a execuo dos testes mais
geis, pois evitam a elaborao dos casos de testes novamente,
e j traz consigo o conhecimento daquela funcionalidade do
sistema. Mas para conseguir esse reuso, os testadores devem
armazen-los de forma adequada, para que a busca seja fcil
quando forem solicitados os testes de um sistema com baixa
frequncia de manuteno. Outro ponto de ateno sempre
atualizar os casos de testes, pois, se desatualizados, podem
atrapalhar, ao invs de ajudar.
O ideal utilizar alguma ferramenta que possa servir como
um repositrio centralizado de casos de testes. A utilizao de
planilhas no indicada, pois com o tempo, elas se espalham
dentro do sistema de arquivos da fbrica, alm de proporcionar possibilidade de redundncias. A ferramenta Testlink,
apresentada na edio nmero 3 desta revista Ferramentas
open source e melhores prticas na gesto de testes pode ser
utilizada para realizar o papel deste repositrio.
Ao longo do tempo, os casos de testes tornam-se uma especificao do sistema para os testadores, uma vez que uma especificao de testes possui um conjunto de entradas, condies
de execuo e um critrio de sucesso/falha, segundo [PEZZ
e YOUNG]. Com essas informaes, os testadores conseguem
claramente entender o sistema e os testes a serem realizados.
A situao ideal seria que a fbrica realizasse um trabalho
completo de especificao de casos de testes, para quando
uma alterao fosse realizada em um sistemaa com baixa
frequncia de manuteno, os testes se tornassem uma tarefa
mais gil. Mas as fbricas, devido ao cenrio apresentado
que exige agilidade e qualidade a baixo custo, no acham a
idia compensadora, uma vez que no possuem garantia de
que o sistema, ao menos, sofrer alguma outra manuteno.
Logicamente, para os sistemas com alta frequncia, essa ao
um investimento com retorno garantido.
Efeitos colaterais das Manutenes

Quando se altera o software, seja para correo, evoluo
ou adaptao, existe a possibilidade de se introduzir novos
defeitos ou reintroduzir erros que ocorriam anteriormente no
mesmo. o chamado efeito colateral. O ideal seria que todos
os mdulos ligados parte alterada ou o sistema todo fossem
retestados. Mas devido aos curtos prazos, principalmente
em manutenes corretivas emergenciais, quase nunca isso
possvel. Segundo [SPILLNER, LINZ e SCHAEFER], a falha
causada atravs do efeito colateral pode aparecer em qualquer
ponto do software, podendo ficar fora da cobertura dos testes
daquela manuteno.
Isto um desafio para os testadores, pois eles precisam garantir o correto funcionamento do sistema como um todo. Uma
forma de prevenir este efeito seria a realizao dos testes de
regresso, que conforme [SPILLNER, LINZ e SCHAEFER], so
realizados para garantir que os novos defeitos introduzidos ou
desmascarados sejam encontrados e removidos.
Para atender aos curtos prazos, os testes de regresso devem

ser automatizados. Realiz-los manualmente no seria vivel.
Entretanto, conforme [FEWSTER], automatizar uma tarefa
complexa e custosa, que exige grande esforo. Mas, uma vez
automatizado, o teste de regresso torna-se muito mais econmico, correspondendo apenas a uma frao do tempo gasto
caso fosse realizado manualmente. Uma sugesto para diluir o
alto custo da automao dos testes de regresso, seria a automao de partes do sistema a cada nova demanda de manuteno,
alcanando a situao ideal no mdio ou longo prazo.
De acordo com [PEZZ e YOUNG], a automao particularmente importante para obter um nvel razovel de garantia em
um ciclo de desenvolvimento muito rpido, como por exemplo,
o ciclo das manutenes corretivas. Uma vez atingido esse
cenrio ideal, os testes sero rpidos e eficazes, mitigando os
riscos das falhas causadas pelo efeito colateral.
Escopo dos Testes na Manuteno

Quando um software desenvolvido do zero, ou seja, quando
ele totalmente novo, as atividades de testes tornam-se tarefas
mais claras e objetivas. Muitas vezes mais rpidas de serem
concludas em comparao s mesmas atividades em um sistema
que est passando por uma grande manuteno, seja ela do tipo
adaptativa ou evolutiva, principalmente. Esta clareza e objetividade dos testes diz respeito ao seu escopo. Isto ocorre pelo
simples fato de que se o sistema novo, tudo tem que ser testado.
O mesmo no acontece para as manutenes de software. O
escopo dos testes restrito s funcionalidades que foram alteradas. Mas ao mesmo tempo, a fbrica deve garantir que tudo
que funcionava antes continua funcionando aps a manuteno. A identificao do escopo dos testes no uma tarefa to
simples. Perguntas, como por exemplo, se a falha encontrada
est ou no dentro do escopo daquele servio de manuteno
so frequentes. comum nos testes de manutenes encontrar
falhas em outras partes do sistema que no tenham sido alteradas. Por mais que o testador focalize no escopo da demanda,
ele se depara com falhas no sistema, por exemplo, no caminho
para alcanar a funcionalidade a ser testada. Logicamente, o
bom testador no deixar de registr-la.
Outras perguntas tambm so realizadas. Se a falha estiver
fora do escopo, quem foi o responsvel por introduzir o defeito?
A fbrica atual ou a anterior? Sendo a anterior responsvel,
logicamente, a fbrica da vez no concordar com o nus da
correo da falha, e ir solicitar nova solicitao de manuteno
para essa correo, pois ir querer receber por isso, uma vez
que este o seu negcio. Como os sistemas legados so antigos,
podem ser mantidos por vrias fbricas distintas ao longo do
tempo e esse tipo de situao inevitvel de acontecer.
Sendo a fbrica atual a responsvel, outra pergunta surge:
O defeito est ou no dentro do perodo de garantia dos
prvios servios? Se estiver dentro do prazo, a correo ser
efetuada. Caso contrrio, qual ser a estratgia? Agregar
valor ao servio de manuteno e agradar o cliente corrigindo a falha, ou considerar uma oportunidade para uma
nova demanda de manuteno?
No momento da execuo dos testes, essas dvidas surgem

frequentemente entre testadores e desenvolvedores. Mas
independentemene dessas questes, os testadores devero
registrar as falhas encontradas. O que deve ser pensado na
maneira de organizar e classificar esses tipos de falhas para
auxiliar os desenvolvedores e gerentes de projetos a priorizarem as atividades de correo. possvel ocorrer os seguintes
tipos de falhas:
Falhas dentro do escopo da demanda;
Falhas fora do escopo da demanda, de responsabilidade da
fbrica, fora da garantia;
Falhas fora do escopo da demanda, de responsabilidade da
fbrica, dentro da garantia;
Falhas fora do escopo da demanda, de responsabiliade de
alguma fbrica anterior.
No momento dos testes possvel classificar se a falha est
dentro ou fora do escopo da demanda, pois o testador tem
idia do que foi alterado e do que dever ser testado, pois ele
segue um plano de testes e uma especificao de requisitos.
Mas algumas vezes surgem dvidas sobre tal classificao,
pois em alguns casos, em se tratando de manuteno, a fronteira do que est dentro ou fora do escopo tnue. Quanto
responsabilidade da introduo do defeito e garantia do
servio, melhor que os lderes e gestores do servio decidam.
No responsabilidade tcnica dos analistas de testes, e sim
uma deciso gerencial e contratual.
Atravs das ferramentas de Gesto de Incidentes, como o Mantis
e o Bugzilla, possvel registrar se a falha encontrada est ou no
dentro do escopo daquele servio. Essas ferramentas so customizveis, permitindo a criao de campos. Dessa forma, caso o
testador no saiba identificar se a falha est no escopo ou no,
pode-se registrar escopo a ser verificado, por exemplo. Sendo
assim, possvel ajudar os desenvolvedores a priorizar a correo.
Uma forma da fbrica se resguardar quanto s questes da
cobertura da garantia e da origem das falhas atravs da utilizao de um processo de controle de verso. Existem algumas
boas ferramentas gratuitas que podem ser adotadas, e que
satisfazem s necessidades, como exemplos, CVS e Subversion.
A informao histrica mantida nestes tipos de aplicativos
til para rastrear falhas ao longo de verses, segundo [PEZZ
e YOUNG]. Eles proporcionam um controle apurado das
alteraes, indicando os autores, as datas e os motivos das
manutenes realizadas.
comum existirem manutenes onde o escopo a migrao da tecnologia do sistema, como por exemplo, a liguagem
de programao. Quando o sistema implementado na nova
tecnologia testado e encontram-se falhas bsicas, essas
devem ser registradas. No se deve considerar que, como a
falha j ocorria no sistema antigo, ela no problema. Este
nivelamento por baixo de qualidade em relao omisso
de falhas encontradas por no serem de responsabilidade da
fbrica atual, no pode acontecer. O mnimo que deve ser feito
registr-las como falhas fora do escopo ou at mesmo como
sugestes de melhorias.
39
Ambientes de Testes
A quantidade de sistemas e a diversificao das tecnologias utilizadas tambm um desafio para as fbricas se a questo do ambiente
de testes no for muito bem planejada. Essa diversidade, aliada
frequncia de manuteno, pode tornar-se um gargalo no momento
da execuo dos testes. Manter o ambiente de um sistema com baixa
frequncia de manuteno um desperdcio de infra-estrutura.
caro manter um servidor preparado com um ambiente que ser
pouco utilizado. Ao mesmo tempo, montar um ambiente para os
testes no uma tarefa rpida que pode ser deixada para o ltimo
momento. Planejar a preparao do ambiente antes do momento
da execuo dos testes um fator importante para evitar atrasos.
Solicitar o dump da base de dados para o cliente um procedimento comum. Mas, comum tambm, pode ser a demora do
retorno a essa solicitao. Algumas vezes o cliente no atende
ao pedido, pois os dados so considerados confidenciais. Existem boas ferramentas para gerao da massa de dados com o
custo acessvel. Com esse tipo de ferramenta possvel ganhar
agilidade na gerao da massa de dados, evitando solicitaes
aos clientes. Apesar disso, a massa de dados reais extradas
do ambiente de produo bem mais rica e, portanto, mais
benfica aos testes. Os scripts de gerao da massa de dados podem ser armazenados e reutilizados, ganhando produtividade.
Esses artefatos, logicamente, devem fazer parte da baseline dos
artefatos, juntamente com os planos e casos de testes, e devem
ser administrados atravs de ferramentas de controle de verso.
Falta de Documentao
A falta de documentao um problema que afeta no s as
atividades de testes, mas todas as demais tarefas de desenvolvimento, como exemplo, a implementao. A ferramenta Rational
Requisite Pro bastante interessante no caso de manutenes.
Ela funciona como um repositrio de requisitos e casos de uso.
Ao longo das manutenes, esses itens sofrem alteraes. Atravs da ferramenta, a tarefa de encontrar e realizar as alteraes
torna-se bem produtiva. Com a utilizao do SoDA, ferramenta
responsvel por extrair os dados do Requisite Pro, os documentos so gerados seguindo um template padro, que pode
ser customizvel, agregando qualidade s documentaes.
De forma semelhante ao uso do Testlink para casos de testes, no
mdio e longo prazo, o sistema sem documentao, aps o povoamento do Requisito Pro com seus casos de uso, possuir informaes
suficientes para atender o cliente com agilidade. Para as atividades
de testes a utilizao dessa ferramenta tambm muito bem vinda,
visto que as informaes do Requisite Pro que servem de base para
a elaborao dos casos de testes estaro padronizadas. Alm disso,
fica simples rastrear casos de testes para os casos de usos e requisitos.
conseguir cumprir o prazo de entrega. O tempo ganho ignorando as atividades de testes pode se reverter em grandes problemas aps a alterao realizada entrar em produo, tornando o
custo da manuteno bem maior, conforme [SPILLNER, LINZ e
SCHAEFER]. Este um princpio bsico dos testes de software.
A centralizao e o reuso dos artefatos so as palavras-chaves
para ganhar agilidade nas atividades de testes dentro da manuteno de um sistema, assim como manter o conhecimento
dentro da Fbrica de Software. Foram apresentados exemplos
de ferramentas, como o Teslink e o Requisito Pro, capazes de
centralizar e suportar o reuso dos artefatos de testes e de especificao, respectivamente, tornando a manuteno mais gil.
Este artigo apresentou algumas questes que dificultam as atividades da equipe de testes, principalmente em relao execuo
dos testes. As dicas e solues propostas esto longe de resolverem
os problemas em um curto espao de tempo, mas so aes que iro
trazer, no mdio e longo prazo, agilidade aos servios. Aps este
tempo, a fbrica estar bem mais preparada, alcanando a capacidade necessria para atender s expectativas dos seus clientes.
Links
Testlink: www.teamst.org/
Mantis: www.mantisbt.org/
Bugzilla: www.bugzilla.org/
CVS: www.nongnu.org/cvs/
Subversion: subversion.tigris.org/
Requisite Pro: www-01.ibm.com/software/awdtools/reqpro/
SoDA: www-01.ibm.com/software/awdtools/soda/index.html
Referencias
FEWSTER, Mark, Common Mistakes in Test Automation. Grove Consultants, Llandeilo UK, 2001.
HERBSLEB, J. D., Grinter, R. E. (1999). Splitting the Organization and Integrating the Code:
Conways Law Revisited. In: Proceedings of ICSE. Los Angeles: IEEECSP, 1999. p. 8595.
IEEE (1998) Std 1219 IEEE Standard for Software Maintenance Institute of Electrical and
Eletronic Engineers, New York, NY, USA.
LIENTZ, B.P; Swanson, E.B. (1980) Software Maintenance Management, Reading, MA,
Addison Wesley.
PAULA FILHO, Wilson de Pdua. Engenharia de Software: fundamentos, mtodos e padres. 2a
ed. Rio de Janeiro: LTC - Livros Tcnicos Cientficos. 2003.
PEZZ, Mauro; YOUNG, Michal, Teste e Anlise de Software. Edio Traduzida. Porto Alegre:
Bookman 2008.
SERRA, Ana Paula Gonalves. Reengenharia de Software Uma viso Geral. Engenharia de
Software Magazine, Nmero 11, 2009.
SPILLNER, Andreas; LINZ, Tilo; SCHAEFER, Hans; Software Testing Foundations A Study Guide
for the Certified Tester Exam. Rio de Janeiro: Fundao Getlio Vargas, 2006.
WARD, M.P; BENNETT, K.H. Formal Methods for Legacy Systems. Journal of Software
Maintenance: Research and Practice, v.7 n.3, 1995

Feedback
eu
edio
ta
40
sobre e
s
Seguir um processo de testes em pequenas manutenes pode

parecer, a princpio, uma tarefa burocrtica e anti produtiva,
principalmente em razo das dificuldades encontradas somadas
forte expectativa de retorno de uma fbrica de software em
relao aos prazos e qualidade. No aconselhvel que as
organizaes abram mo dos testes dessas manutenes para
D
s
Concluso
41
Plano de Teste
Um MapaEssencial para Teste de Software
U
Antonio Mendes da Silva Filho
antoniom.silvafilho@gmail.com
Professor e consultor em rea de tecnologia

da informao e comunicao com mais
de 20 anos de experincia profissional,
autor do livros Arquitetura de Software e
Programando com XML, ambos pela Editora
Campus/Elsevier, possui diversos artigos
publicados em eventos nacionais e internacionais, colunista para Cincia e Tecnologia
pela Revista Espao Acadmico com mais de
90 artigos publicados, tendo feitos palestras
em eventos nacionais e exterior. Foi Professor
Visitante da University of Texas at Dallas e da
University of Ottawa. Formado em Engenharia Eltrica pela Universidade de Pernambuco,
com Mestrado em Engenharia Eltrica pela
Universidade Federal da Paraba (Campina
Grande), Mestrado em Engenharia da Computao pela University of Waterloo e Doutor
em Cincia da Computao pela Univesidade
Federal de Pernambuco.
42
ma atividade essencial no desenvolvimento de todo e qualquer projeto o planejamento.

Um plano tem o papel semelhante ao
de um mapa. Sem um mapa, um plano
ou qualquer outra fonte de informao
similar, voc no conhecer seus objetivos, nem aonde quer chegar e jamais
ter a certeza de ter alcanado sua meta.
Perceba que entender o propsito do planejamento de suma importncia a fim
de monitorar a execuo de atividades,
sendo tambm importante conhecer o
papel dos riscos no planejamento, bem
como diferenciar estratgias de planos.
Planejamento engloba trs atividades
principais:
1. Definir um cronograma de atividades:
estabelecer as atividades que devem
ser realizadas, as etapas a serem seguidas e a ordem cronolgica de execuo;
2. Fazer alocao de recursos: definir
quem realiza as atividades e quais ferramentas/recursos a serem utilizados;
3. Definir marcos de projeto estabelecer
os marcos, ou milestones, a serem
alcanados com objetivo de se fazer o
acompanhamento.
Engenharia de Software Magazine - Plano de Teste

Apresenta o plano de teste de software, destacando sua importncia no processo de desenvolvimento de software, mostrando como elabor-lo
e exemplificando os itens que devem compor o
referido documento.
Para que serve?

Orientar o gerente de projeto e/ou lder da equipe de
teste na elaborao de um plano de teste para um
sistema de software.

Trata-se de uma prtica regular na engenharia de software e ajuda na elaborao de um
plano de teste, na definio dos itens que
devem compor esse plano e justifica sua necessidade num processo de desenvolvimento
de software.
Perceba que o planejamento acompanhado da atividade de monitorao

ou superviso que visa avaliar se o
progresso que tem sido alcanado est
em conformidade com o que foi estabelecido no plano ou, em outras palavras,
responder a questo: quo bem estamos
indo no projeto?
VALIDAO, VERIFIC AO E TESTE
Agora, dentro do contexto do desenvolvimento de software,

voc necessitar de vrios documentos como, por exemplo, plano
de projeto, documento de requisitos e plano de teste. Neste artigo, o foco recai sobre o ltimo, isto , plano de teste. Trata-se de
um documento ou mapa no qual se definem escopo e objetivos,
alm de requisitos, estratgias e recursos a serem empregados
nas atividades de testes de software. Nesse sentido, o artigo
apresenta os itens que devem fazer parte de um documento de
plano de teste, exemplificando e discutindo esses itens.
Teste de Software
Teste de software uma das atividades do processo de desenvolvimento de sistema de software que visa executar um programa
de modo sistemtico com o objetivo de encontrar falhas. Perceba
que isto requer verificao e validao de software. Nesse sentido,
definir quando as atividades de verificao e validao iniciam
e terminam, como os atributos de qualidade sero avaliados e
como os releases do software sero controlados, so questes
que devem ser acompanhadas ao longo do processo de software.
Vale ressaltar que teste no deve ser a ltima atividade do
processo de desenvolvimento de software. Ela ocorre durante
todo o processo, como exemplificado na viso geral do processo
RUP (Rational Unified Process) mostrado na Figura 1.
Figura 1. Viso geral do RUP.
E, alm de encontrar falhas, testes objetivam aumentar a

confiabilidade de um sistema de software, isto , aumentar
a probabilidade de que um sistema continuar funcionando
sem falhas durante um perodo de tempo.
Embora seja desejvel testar um sistema por completo, devese ter em mente que a atividade de teste assegura apenas
encontrar falhas se ela(s) existirem, mas no asseguram sua
ausncia. Portanto, as atividades devem ser disciplinadas a fim
de identificar a maioria dos erros existentes. Note que realizar
os testes de software implica em responder s questes:
1. Quais atributos da qualidade devero ser testados?
2. Quem realizar os testes?
3. Quais recursos sero utilizados?
4. Quais as dependncias entre os atributos de qualidade?
5. Quais as dependncias entre as atividades de desenvolvimento?
6. Como o processo e a qualidade do sistema de software sero
acompanhados?
Na seo seguinte, um exemplo do conjunto de sees de um

plano de teste apresentado com o objetivo de ilustrar como
as informaes pertinentes ao teste de software poderiam ser
tratadas e documentas. No h, portanto, o objetivo de ser
completo, pois cada sistema possui suas peculiaridades que
devem ser consideradas caso a caso.
Plano de Teste
O plano de teste um dos documentos produzidos na conduo de um projeto. Ele funciona como:
Um integrador entre diversas atividades de testes no projeto;
Mecanismo de comunicao para os stakeholders (i.e. a equipe
de testes e outros interessados);
Guia para execuo e controle das atividades de testes.
O plano de teste, que pode ser elaborado pelo gerente de
projeto ou gerente de testes, visa planejar as atividades a serem
realizadas, definir os mtodos a serem empregados, planejar
a capacidade necessria, estabelecer mtricas e formas de
acompanhamento do processo. Nesse sentido, deve conter:
Introduo com identificao do projeto (definies, abreviaes,
referncias), definio de escopo e objetivos;
Conjunto de requisitos a serem testados;
Tipos de testes a serem realizados e ferramentas utilizadas;
Recursos utilizados nos testes;
Cronograma de atividades (e definio de marcos de projeto).
Em outras palavras, um plano de teste deve definir:
1. Os itens a serem testados: o escopo e objetivos do plano
devem ser estabelecidos no incio do projeto.
2. Atividades e recursos a serem empregados: as estratgias
de testes e recursos utilizados devem ser definidos, bem como toda
e qualquer restrio imposta sobre as atividades e/ou recursos.
3. Os tipos de testes a serem realizados e ferramentas empregadas:
os tipos de testes e a ordem cronolgica de sua ocorrncia
so estabelecidos no plano.
4. Critrios para avaliar os resultados obtidos: mtricas devem
ser definidas para acompanhar os resultados alcanados.
Perceba que o planejamento necessrio a fim de antecipar
o que pode ocorrer e, portanto, provisionar os recursos necessrios nos momentos adequados. Isto significa coordenar
o processo de teste de modo a perseguir a meta de qualidade
do produto (sistema de software).
Exemplificando o Plano de Teste

O plano de teste contm um conjunto de informaes que
permite ao gerente de projeto no apenas coordenar as atividades de testes de um projeto, mas tambm monitorar seu
progresso e verificar se o executado est em conformidade
com o planejado. A Tabela 1 apresenta uma relao dos itens
consideradas imprescindveis em um plano de teste. A relao
de itens no pressupe a inteno de ser completo, mas de
apontar os itens considerados como obrigatrios num plano
de teste de uma instituio.
43
Itens de um
Plano de Teste
Contedo
1. Introduo
Contm uma identificao do projeto, descrio dos objetivos do

documento, o pblico ao qual ele se destina e escopo do projeto a
ser desenvolvido. Pode adicionalmente conter termos e abreviaes
usadas, alm de informar como o plano deve evoluir.
2. Requisitos a
serem testados
Esta seo descreve em linhas gerais o conjunto de requisitos a serem

testados no projeto a ser desenvolvido, comunicando o que deve
ser verificado. Exemplos de requisitos a serem testados so: Esta
desempenho, segurana, interface de usurio, controle de acesso,
funcionalidades.
3. Estratgias e
ferramentas de
teste
Apresenta um conjunto de tipos de testes a serem realizados,

respectivas tcnicas empregadas e critrio de finalizao de teste. Alm
disso, listado o conjunto de ferramentas utilizadas.
4. Equipe e infraestrutura
Contm descrio da equipe e da infra-estrutura utilizada para

o desenvolvimento das atividades de testes, incluindo: pessoal,
equipamentos, software de apoio, materiais, dentre outros. Isto visa
garantir uma estrutura adequada para a execuo das atividades de
testes previstas no plano.
1. Introduo
Este documento apresenta o planejamento das atividades de testes do sistema Exemplo o
qual ser utilizado como base para as atividades de acompanhamento, reviso, verificao e
validao do projeto, desde seu incio at sua concluso, a fim de garantir a anlise comparativa
do resultado real versus planejado. Desta forma, aes corretivas e preventivas podero ser
tomadas, sempre que resultados reais desviarem significativamente do planejado.
1.1 Termos e acrnimos
Esta seo explica o conceito de um subconjunto de termos importantes que sero mencionados
no decorrer deste documento. Estes termos so descritos na Tabela 2, estando apresentados
por ordem alfabtica.
Termo
5. Cronograma de
atividades
Contm uma descrio de marcos importantes (milestones) das

atividades (incluindo as datas de incio e fim da atividade). Apenas
marcos relevantes devem ser listados, ou seja, aqueles que contribuiro
nas atividades de testes. Por exemplo: projeto de testes, execuo de
testes ou avaliao de testes.
Descrio
Artefato
Tudo que produzido e documentado em uma atividade de qualquer fluxo

do projeto. Por exemplo: documento de requisitos, diagrama de casos de usos
e glossrio.
Milestone
Ponto de checagem; marco que indica a concluso de uma fase ou etapa.
NA
No Aplicvel
Representante da empresa cliente ou contratada responsvel pelo

Patrocinador sucesso do projeto em instncia superior, garantindo o cumprimento de
responsabilidades estabelecidas.
Reviso
Apresentao de produtos de software para os interessados visando

comentrio e aprovao dos mesmos.
SQA
Software Quality Assurance, profissional ou grupo responsvel por garantir a

qualidade do produto de software e processo de desenvolvimento.
Tabela 2 Termos e acrnimos do projeto.

6. Documentao
complementar
Apresenta-se uma relao dos documentos pertinentes ao projeto.
Tabela 1 Relao de itens de um plano de Teste.
O contedo exato das sees que compem um plano de teste,

geralmente, difere de instituio para instituio. Entretanto,
os itens acima apontados existem nas sees do documento. A
subsees, destacados nos quadros a seguir (enumerados de
1 a 6), ilustram o contedo que compe um plano de teste. O
Quadro 1 destaca a seo 1 do plano de teste.
O Quadro 2 representa a seo 2 do documento e apresenta
um conjunto de requisitos a serem testados.
Perceba que os objetivos do projeto so peculiares a cada um.
Alm disso, os critrios de aceitao final do projeto resultado
de acordo entre as parte envolvidas (i.e. empresa desenvolvedora e
cliente). O Quadro 3 caracteriza a seo dos requisitos do sistema,
que apresenta uma viso geral do projeto trazendo objetivos, participantes e mecanismos de evoluo do plano de teste e aceitao.
A motivao da seo anterior caracterizar os principais
testes a serem aplicados s funcionalidades do sistema e possveis ferramentas a serem usadas. A seo representada no
Quadro 4 apresenta a equipe de teste com respectivas funes
e infra-estrutura utilizada.
Neste ponto, pode-se definir o cronograma (ver Quadro 5).
Perceba que o cronograma apresentado na seo 5 destaca
apenas as principais atividades, caracterizando os principais
marcos do projeto. No h, contudo, a inteno aqui em ser
completo, mas a de ressaltar como as informaes podem ser
apresentadas no plano de teste.
44
Note que a Tabela 2 identifica um subconjunto de termos que pode caracterizar um projeto.
Todo e qualquer termo, conveno adotada ou abreviaes deveriam ser apresentadas nessa
tabela a fim de comunicar s partes envolvidas e interessadas (i.e. os stakeholders) o seu
significado. Isto visa prover as denominaes corretas empregadas no documento.
1.2 Objetivos
Esta seo contm o conjunto de objetivos que orientam as atividades de testes do sistema a ser
desenvolvido. Esse documento do Plano de Testes do sistema Exemplo possui os seguintes objetivos:
Levantar as informaes de projeto pertinentes e os componentes de software a serem testados.
Definir o conjunto de requisitos a serem testados (alto nvel).
Definir e detalhar as estratgias de teste a serem utilizadas.
Definir os recursos necessrios e obter uma estimativa dos esforos das atividades de teste.
Identificar os artefatos resultantes das atividades de testes.
1.3 Sistema Exemplo
Este documento especifica o plano de teste de um sistema que deve prover notcias e contedo
online, denominado de Sistema Exemplo, a ser desenvolvido para a Empresa XYZ. Seu propsito
prover notcias sobre os mais variados contedos, permitindo acesso integral apenas a usurios
leitores cadastrados no sistema.
(Nota que o propsito desse sistema, usado aqui apenas com fins ilustrativos, similar ao de um
sistema como o de portais de jornais e revistas e outros provedores de contedo que permitem o
acesso ao contedo apenas a clientes devidamente cadastrados no sistema).
1.4 Escopo
Este projeto aborda um sistema Exemplo de informao online, com foco em prover contedo
online. Este sistema Exemplo necessitar fazer testes unitrios, de integrao e de sistema. Os
Quadro 1. Introduo
testes unitrios e de integrao visam tratar a qualidade funcional, a interface grfica e controle
de acesso. Por outro lado, os testes de sistema trataro as questes de desempenho.
Para a execuo dos testes sero utilizadas mquinas o mais idnticas possvel, em termos de
hardware, quelas que sero implantadas no cliente (provedor de contedo online, como um
portal de notcias), a fim de garantir a previsibilidade de desempenho e compatibilidade.
Outros testes como os testes de stress, de volume e de falha/recuperao no sero realizados
por se considerar que o ambiente de implantao do sistema nao est sujeito a esse tipo de
ocorrncia, as quais podem ser facilmente previstas e tratadas pelo cliente.
3. Estratgias e ferramentas de teste

Esta seo apresenta um conjunto de tipos de testes a serem realizados onde, para cada tipo de teste
adotado, definem-se as tcnicas utilizadas, o critrio de finalizao de teste e outras suposies ou
consideraes especificas para o teste. Adicionalmente, informa-se o conjunto de ferramentas empregadas.
1.5 Documentao do projeto

Esta seo contm informaes sobre o conjunto de documentos disponveis e respectiva situao de
reviso, os quais so importantes no plano de teste. O quadro abaixo ilustra uma situao exemplo.
Teste funcional (ver Tabela 3)
Documento
Especificao de Requisitos
Sim
Disponvel
No
Sim
No
Plano de Projeto
Sim
No
Sim
No
Modelo de Anlise
Sim
No
Sim
No
Modelo de Projeto
Sim
No
Sim No
Documento de Arquitetura
Sim No
Sim No
Prottipo
Sim No
Sim No
Objetivo do Teste:
Assegurar a funcionalidade adequada do

teste, incluindo navegao, entrada de dados,
processamento e recuperao.
Tcnica:
Executar cada caso de uso e fluxo de caso de uso,

usando dados vlidos e invlidos a fim de verificar:
Se os resultados esperados ocorrem quando dados
vlidos so usados
Se mensagens de erro ou aviso apropriadas so
exibidas quando dados invlidos so usados.
Se cada regra de negcio est sendo aplicada de
maneira apropriada
Revisado
Manual do Usurio
Sim No
Sim No
Lista de Riscos
Sim
Sim
No
Estratgias
As estratgias compreendem um conjunto de testes empregados com o objetivo de verificar
aspectos especficos do sistema em desenvolvimento (abaixo, apresenta-se um extrato de
possveis testes que podem ser adotados).
No
Continuao Quadro 1. Introduo

Critrio de Finalizao:
2. Requisitos a serem testados
Esta seo apresenta um conjunto de requisitos funcionais e no funcionais que foram
identificados durante o levantamento de requisitos e para os quais os testes abaixo so
considerados como necessrios (representam um extrato do que ser testado).
Teste da Interface do Usurio
a) Navegue atravs de todas as funcionalidades, verificando que cada tela de interface grfica
pode ser rapidamente entendida e facilmente utilizada.
b) Verifique que se a ajuda online est funcionando adequadamente.
Teste Funcional
a) Verifique se as informaes teis obtidas pelo subsistema responsvel so automaticamente
e periodicamente atualizadas.
b) Verifique se qualquer usurio pode acessar as notcias e outras informaes disponveis no portal.
Teste de Desempenho
a) Verifique o tempo de resposta da rede interna e do servidor em relao aos terminais.
b) Verifique o tempo de consulta/atualizao do subsistema de notcias e outras informaes.
c) Verifique se o tempo de resposta para operaes que envolvam dados multimdia (imagens,
vdeos, etc.) no ultrapassam 15 segundos.
Teste do Banco de Dados
a) Verifique se as informaes de contedos, notcias, categorias e demais informaes podem
ser inseridos, atualizados e consultados pelo administrador de sistema.
b) Verifique se as informaes teis obtidas pelo subsistema responsvel podem ser atualizadas
e que as mesmas podem ser apresentadas.
c) Verifique se as informaes do portal de notcias possam ser consultadas pelos usurios.
d) Verifique se as informaes teis disponveis no portal possam ser consultadas.
(Note que um sistema possui diversos requisitos que podem ser verificados atravs de outros tipos de
testes como teste de carga, teste de instalao, teste de volume, teste de stress, teste de configurao.
Por exemplo, num teste de segurana e de controle de acesso, voc pode verificar se usurios no
cadastrados podem acessar informaes restritas aos cadastrados. Adicionalmente, voc pode checar
se, alm do administrador, ningum mais pode inserir, atualizar ou remover dados do sistema).
Quadro 2. Requisitos a serem testados
Consideraes Especiais:
Tabela 3. Teste Funcional
Todos os testes planejados foram executados.

Todos os defeitos identificados foram tratados.
Nenhuma
Teste de interface de usurio (ver Tabela 4)

Verificar se a navegao atravs das funcionalidades testadas
refletem as funes e os requisitos do negcio apropriadamente,
incluindo janela-a-janela, campo-a-campo, e o uso de mtodos
de acesso (movimentos do mouse, teclas aceleradoras)
Objetivo do Teste:
Tcnica:
Critrio de Finalizao:
Consideraes Especiais:
Checar se os objetos e caractersticas da janela, tais como menus,

tamanho, posio, estado e foco conformam-se aos padres.
Criar ou modificar os testes para cada janela a fim de verificar a
navegao e os estados de objeto adequados para cada janela e
objetos da aplicao.
verificado que cada janela permanece consistente com a
verso de comparao ou dentro de padres aceitveis de
usabilidade.
Todas as propriedades para objetos devem ser acessadas.
Tabela 4. Teste de interface

Ferramentas
Um conjunto de ferramentas empregadas em atividades deste projeto compreende (ver Tabela 5):
Atividade
Ferramenta
Gerenciamento de Teste
Rational RequisitePro
Projeto de Teste
Rational Rose
Gerenciamento de Projeto
Microsoft Project
Ferramentas do SGBD
MySQL Control Center
Tabela 5. Ferramentas
Quadro 3. Estratgias e ferramentas de teste
45
4. Equipe e infra-estrutura
Esta seo apresenta a equipe de testes, identificando-se os papis e responsabilidades. Alm disso,
a infra-estrutura existente listada.
6. Documentao complementar
Esta seo apresenta documentao de apoio, referenciando um conjunto de outros documentos
que complementam e suportam as informaes contidas no plano de teste.
Equipe de teste
A Tabela 6 descreve um conjunto de papis e respectivas responsabilidades na equipe de teste.
1. Documento de Requisitos do Sistema Exemplo, Verso 00.01 22/05/2009.

2. Ata de Reunio Levantamento de Requisitos do Mdulo A do Sistema Exemplo, 12/05/2009.
3. Ata de Reunio Levantamento de Requisitos do Mdulo B do Sistema Exemplo, 13/05/2009.
4. Ata de Reunio Levantamento de Requisitos do Mdulo C do Sistema Exemplo, 14/05/2009.
5. Ata de Reunio Validao de Requisitos do Sistema Exemplo, 15/05/2009.
6. Plano de Projeto do Sistema Exemplo.
Papel
Gerente do Projeto
Responsabilidades
Fornece orientao tcnica
Adquire recursos necessrios
Elabora relatrios de gerenciamento
Identifica, prioriza, e implementa os casos de teste

Gera o plano de teste
Projetista de teste
Cria o modelo de teste
Avalia o esforo de teste
Executa os testes
Testador
Registra os resultados
Documenta as solicitaes de mudana
Implementa e faz os testes unitrios das classes e
pacotes de teste
Implementador de testes
Cria as classes e pacotes de teste implementados no
modelo de teste
Identifica e define as operaes, atributos, e
Projetista
associaes das classes de teste
Identifica e define as classes e pacotes de teste
Tabela 6 - Papis e responsabilidades da equipe de projeto.
Infra-estrutura
Abaixo, listado o conjunto de recursos disponveis para este projeto.
Servidor de Banco de Dados - MySQL DataBase Server
Repositrio de Testes - 4 PCs de Desenvolvimento de Teste
Quadro 4. Equipe e infra-estrutura
5. Cronograma
O cronograma da Tabela 7 contempla as atividades de testes, marcos, e respectivas datas de
incio e trmino. Este quadro no ilustra qualquer dependncia entre as atividades. Caso exista,
isso pode ser apresentado atravs de um diagrama de Gantt usando Microsoft Project.
Milestone
Data de Incio
Data de Trmino
Planejar Teste
03/06/09
05/06/09
Projetar Teste
08/06/09
10/06/09
Implementar Teste
12/06/09
17/06/09
Executar Teste
17/06/09
20/06/09
Avaliar Teste
22/06/09
23/06/09
Tabela 7. Cronograma
Quadro 6. Documentao complementar
O conjunto de sees apresentados acima servem para ilustrar

pontos importantes num plano de teste. No houve aqui a inteno de ser completo, mas de informar quais itens deveriam
compor o plano de teste, bem como a de ilustrar o contedo
que pode ser encontrado nesse documento.
Concluso
Um projeto compreende um conjunto de atividades interrelacionadas com datas de incio e fim, alm de metas especficas. Dentre essas atividades, uma essencial a de teste
cujo objetivo encontrar sistematicamente falhas. Para tanto,
faz-se necessrio elaborar um plano de teste que servir como
um guia das atividades de teste que compreende o projeto,
implementao, execuo e avaliao de testes.
Trata-se de um documento que o gerente de projeto usa com objetivo de coordenar as atividades de teste. Voc deve entender que
a visibilidade do processo (de desenvolvimento e, especificamente,
de teste) essencial. Tal visibilidade permite monitorar a qualidade
obtida em cada etapa e programar cada atividade a ser executada.
Esse processo de acompanhamento contnuo das atividades de
teste de fundamental importncia para obteno dos resultados
em termos de qualidade, custo e tempo. Portanto, sem esse mapa,
torna-se muito difcil realizar com sucesso as atividades de teste.
Links
Introduo ao Teste (baseado no RUP)
http://www.wthreex.com/rup/portugues/index.htm
Teste de software na Wikipedia
http://pt.wikipedia.org/wiki/Teste_de_software
Processo de teste de software (Datasus)
http://pts.datasus.gov.br
Risk and Requirements -based Testing artigo de James Bach, IEEE Computer
http://www.satisfice.com/articles/requirements_based_testing.pdf
Software Testing Brain
http://www.testingbrain.com/
Software Errors Cost U.S. Economy $59.5 Billion Annually
http://www.nist.gov/public_affairs/releases/n02-10.htm

Feedback
eu
edio
ta
46
sobre e
s
Perceba, por exemplo, que a atividade de projeto, implementao e execuo de teste poderia ser decomposta em subsistemas, caso voc estiver tratando de um sistema de mdio a
grande porte.
A seo apresentada no Quadro 6 trata de informaes que
so detalhadas em outros documentos.
D
s
Quadro 5. Cronograma
AMIGO
Existem coisas
que no
conseguimos
ficar sem!
...s pra lembrar,

sua assinatura pode
estar acabando!
Renove J!
www.devmedia.com.br/renovacao
Para mais informaes:
www.devmedia.com.br/central
47
Linhas de Produtos de Software

Introduo, conceitos e desafios para sua adoo
Pasqueline Scaico
pasqueline@ccae.ufpb.br
Professora da Universidade Federal da Paraba (UFPB) Litoral Norte, pesquisadora

na rea de Linhas de Produtos de Software.
Possui mais de nove anos de experincia
com Engenharia de Software. Membro do
grupo de pesquisa Computao Aplicada
(Applied). Atualmente, coordena um projeto do CNPq que visa a elaborao de um
mtodo para identificao de famlias de
produtos chamado YANA.
Alexandre Scaico
alexandre@ccae.ufpb.br
Doutor em Engenharia Eltrica e Professor da

Universidade Federal da Paraba (UFPB) Litoral Norte. Pesquisador na rea de Interface
com o Usurio e Linhas de Produtos de Software. J publicou mais de vinte trabalhos,
alguns deles em peridicos de referncia na
rea de Computao, como o Lecture Notes on
Computer Science (LNCS) e o IEEE- Transaction
of Society for Computer Simulation.
Fillipe Loureno da Cunha Lima

fillipe.lourenco@gmail.com
Graduando em Licenciatura em Cincia da

Computao pela Universidade Federal da
Paraba (UFPB) Litoral Norte. Premiado
no XI Encontro de Iniciao a Docncia realizado pela PRG/UFPB em 2008. Trabalha no
projeto YANA.
48
o seria legal se para desenvolver uma aplicao de software precisssemos apenas

escolher artefatos para que no final
tivssemos a aplicao funcionando?
Um dos temas em maior evidncia nos
ltimos anos a Engenharia de Linhas
de Produtos de Software (LPS), um
paradigma para o desenvolvimento
de aplicaes, que traz como bandeira uma filosofia audaciosa para
o conceito amplo de reuso. Aqui so
apresentados conceitos introdutrios
sobre este assunto e mencionados os
desafios existentes nesse complexo
universo. Neste artigo ser tratado
com mais nfase a anlise de domnio
orientada a features.
A origem das Linhas de produtos
O conceito tradicional das linhas de

produtos foi criado na indstria automobilstica para substituir o modelo de
fabricao existente na poca no qual
um produto era inteiramente produzido por uma nica pessoa ou por um
pequeno grupo delas. As linhas de
produo introduziram o conceito de
Engenharia de Software Magazine - Linhas de Produtos de Software

Linhas de Produtos de Software um novo paradigma da Engenharia de Software voltado
extrema utilizao do reuso para a construo de
famlias de produtos. A nfase do artigo dada
aos conceitos iniciais da abordagem e a anlise de
domnio de caractersticas, uma das etapas principais para o estabelecimento das plataformas de
produo.
Para que serve?

As Linhas de Produtos permitem que se estabelea a
infra-estrutura necessria para que uma famlia de
produtos, aplicaes que fornecem servios parecidos, contudo, diferenciados, seja constituda para a
construo rpida das aplicaes.

Para empresas que atuam em um segmento especfico de mercado e, dentro dele, querem oferecer
produtos mais diferenciados de acordo com o perfil
de consumidores que possuem.
modularizao, j que o trabalho poderia

ser feito em pedaos, e possibilitava
que os produtos fossem desenvolvidos
em um tempo menor devido ao paralelismo das tarefas.
DESENVOLVIMENTO
Este modelo de fabricao permitiu que mais clientes fossem atendidos, mas teve que ser adaptado para permitir a
diferenciao dos produtos, j que at ento, todos os carros
tinham a mesma aparncia e serviam a um determinado
propsito. Era preciso adequar o modelo de fabricao para
que fosse possvel oferecer produtos diferenciados com a
mesma rapidez de produo. O conceito de customizao
em massa (Figura 1) representou a possibilidade de atender
a produo de bens em larga escala com base em perfis de
consumidores. As fbricas passaram a projetar automveis
levando em considerao os segmentos de clientes e suas
necessidades, o que ocasionou verses diferentes de um
mesmo modelo de carro. Surge, ento, a idia das famlias
de produtos.
Figura 1. Customizao em massa
Para atingir esse grau de customizao, plataformas de

produo foram estabelecidas e passaram a ser usadas como
moldes para aqueles componentes que eram comuns maioria dos produtos: chassis, motor e cmbio. Os componentes
que eram diferentes, a exemplo da carroceria e itens de conforto, eram responsveis por permitir as variaes dentro
da famlia de produtos. Logo, a maneira como o reuso das
peas foi utilizado permitiu que se produzissem diversos
modelos de automveis.
Os primeiros conceitos de Linhas de Produto de Software
(LPS) surgiram da observao dos processos industriais
na dcada de 70, contudo, apenas nos anos 90 foram
completamente introduzidos atravs das contribuies
do projeto FODA (Feature-Oriented Domain Analysis) e
das pesquisas realizadas pelo SEI (Software Engineering
Institute) no desenvolvimento de aplicaes para o governo. Uma LPS segue os mesmos princpios das linhas
encontradas na indstria, sendo que constit uem um
conjunto de aplicaes de software relacionadas entre si
que oferecem funcionalidades parecidas e que satisfazem
as diferentes necessidades de um determinado segmento
ou misso de mercado.
Conceitos bsicos
Normalmente os termos famlia de produtos e linha de

produtos so citados quando se fala deste tema. Basicamente,
as linhas de produtos se referem ao paradigma de desenvolvimento, enquanto as famlias de produtos representam o
conjunto de sistemas, os quais so muito parecidos, mas que
possuem caractersticas diferenciadas que atendem especificamente a um grupo de clientes de um setor do mercado, contudo,
muitos autores as usam indistintamente. Estas caractersticas
que diferem so chamadas de pontos de variao ou de variabilidades. So elas que ditam a versatilidade e (em muitas
vezes, a complexidade) de uma linha de produtos.
Para entender a idia por traz das linhas de produtos, imagine
um software de segurana de ambientes. Dependendo do tipo de
local, a aplicao dever oferecer diferentes possibilidades para
atender as necessidades dos usurios. Todo sistema de segurana possui um mecanismo de travamento de portas e de alarme
para o caso de intruso. Contudo, outro servio que pode ser
oferecido opcionalmente o desligamento automtico de luzes,
que eventualmente ficaram acesas no fechamento das portas.
Perceba que as caractersticas presentes apenas em algumas
verses deste tipo de sistema so as chamadas variabilidades.
Numa abordagem de desenvolvimento convencional muito
provvel que todos estes servios sejam especificados e projetados em funo de uma nica aplicao que atender da
mesma maneira (ou com certos ajustes) os diversos perfis de
usurios. Em LPS, o paradigma para a concepo da soluo
outro de forma que, a partir de um estudo sistmico de todas
as caractersticas (comuns e variveis) do domnio em questo
ser montada uma plataforma de artefatos reutilizveis que ao
serem combinados, permitiro o desenvolvimento de vrias
instncias diferentes do sistema, dedicadas, cada uma, a um
grupo de clientes. Estes artefatos tambm so chamados de
ativos. Nas prximas sees so apresentados mais detalhes
sobre estes conceitos.
Muitos benefcios so decorrentes do uso de linhas de produtos. Podem ser citados como exemplo a diminuio do time-tomarket, j que com o alto grau de reusabilidade dos artefatos a
implementao decorre da juno de componentes; a reduo
dos custos; a melhoria na qualidade final do produto, j que a
conduta de realizar os testes se torna mais rigorosa para que
seja possvel garantir a manuteno e evoluo da plataforma
de artefatos; a reduo dos riscos j que, em geral, a empresa
se apega um domnio de problema cuja a tendncia a de
que com o tempo seja mais explorado e conhecido; e por fim,
o posicionamento da empresa no mercado j que atuar com
estratgias e abordagens mais refinadas e aprimoradas.
Contudo, quando se pensa em adotar o desenvolvimento
de aplicaes sob esta perspectiva, necessrio tomar cincia
das mudanas que precisam ocorrer na organizao. H de
ser considerado:
Os investimentos iniciais para a adoo decorrentes da
preparao de competncias, dos treinamentos, da contratao de especialistas na rea de negcios e da aquisio de
infra-estrutura de desenvolvimento, entre outros;
49
A necessidade de que os processos internos e organizacionais

tenham um certo grau de maturidade para que seja possvel
identificar, controlar e continu-los sem um gasto considervel de tempo;
As mudanas organizacionais, j que os produtos dentro de
uma famlia no podem mais ser vistos como independentes e, por isso, a equipe precisa ser reorganizada. Um time
responsvel pelo estabelecimento da linha de produo deve
trabalhar em sintonia com a equipe desenvolvedora;
Um novo esforo deve ser despendido para a elaborao da
plataforma que comea com a padronizao de processos,
fluxos de trabalho, tecnologia e artefatos utilizados;
Como ser elaborada a plataforma da linha de produo, de
maneira que uma estratgia conveniente seja estipulada para
descobrir as caractersticas comuns da grande maioria dos
produtos e depois as suas especificidades;
A flexibilidade que os componentes devem ter para que
possam ser adequados a diferentes sistemas para permitir o
reuso: importante que seja possvel mapear os pontos em
que os produtos diferem para que se determinem as variabilidades. Produtos que compartilham a mesma plataforma
e apresentam caractersticas semelhantes pertencem a uma
mesma famlia de produtos.
Portanto, o uso por convenincia de reuso no caracteriza a
utilizao de linhas de produtos. Este o caso do uso de APIs,
de frameworks ou de componentes. Como ser observado
adiante, comeando pelo ciclo de vida, grandes mudanas
acontecem para o uso desta abordagem.
Ciclo de vida das linhas de produtos
Normalmente, quando se fala em reuso o primeiro artefato a se pensar o cdigo. O aprimoramento de padres
arquiteturais, dos padres de projeto e a construo de
frameworks refletem esta preocupao. Em linhas de
produtos, a dimenso que o reuso toma muito maior
porque se procura maximizar o reuso em todos os artefatos
do ciclo de desenvolvimento, de forma que seja possvel
escolher pedaos de artefatos mais gerais para compor um
produto da linha.
Assim, as etapas do ciclo de vida tradicional no so
suficientes para este contexto. Ao contrrio da abordagem
tradicional em que se espera especificar requisitos de
software, em LPS os esforos iniciais esto voltados para
identificar as caractersticas dos produtos na linha, ou seja,
para o entendimento do domnio do problema no qual a
linha de produtos estar inserida. Este processo chamado
de Engenharia de Domnio. Como todos os artefatos sero
reaproveitados ao longo dos projetos, um alto grau de
flexibilidade precisa existir para que um mesmo artefato
possa carregar informaes teis para outros artefatos e
que seja de serventia para os mltiplos produtos da linha.
Na Engenharia de Domnio o desenvolvimento se d
para o reuso. Os artefatos que vo sendo criados deixam
explcita a questo da variabilidade nos mesmos. Um
50
exemplo que o documento de requisitos pode conter uma

descrio explcita de que alguns requisitos se aplicam
apenas a um subconjunto de produtos, ou so opcionais a
outros. Veja um exemplo na Tabela 1, onde em uma famlia
de produtos para bibliotecas, o documento de requisitos
poderia ser descrito como se segue. A caracterstica comum
na famlia de sistemas para bibliotecas o emprstimo.
Apenas alguns desses sistemas permitem a reserva dos
exemplares, que pode ser feita com o pagamento de uma
taxa de reserva ou no.
Requisitos
OBRIGATRIOS
OBR 1 Emprstimo de livros
OPCIONAIS
OPC 1 Reservas
ALTERNATIVAS
OPC 1 ALT 1 Reserva com pagamento de taxa
OPC 1 ALT 2 Reserva sem pagamento de taxa
Tabela 1. Trecho de especificao de requisitos em um LPS
Observando a Figura 2 fica claro que quando se usa linhas de produtos no se tem a especificao de um sistema,
e sim, a especificao de todas as caractersticas daquele
domnio e para um conjunto de sistemas. Os artefatos da
Engenharia de Domnio so especificados genericamente
e contemplam as caractersticas do universo que est
sendo explorado. A prxima seo deste artigo trata mais
detalhadamente das atividades necessrias para a representao de domnio.
Figura 2. Engenharia de Domnio
Depois de representadas as caractersticas, a criao dos

produtos tem incio, os quais tero artefatos mais especficos. Esta etapa do ciclo chama-se Engenharia de Aplicao
e tem como finalidade tirar proveito das variabilidades na
linha, combinando as variaes extradas pela Engenharia
de Domnio, para que produtos diferenciados sejam construdos. neste processo que acontece o desenvolvimento
com o reuso. A infra-estrutura da linha oferece a maioria
das funcionalidades para o produto seja construdo. Alm
disso, os demais artefatos so simplesmente instanciados a
partir da base e encaixados uns com os outros para formar
a nova aplicao (Figura 3).
Figura 3. Engenharia de Aplicao
DESENVOLVIMENTO
A idia que o documento de requisitos, a arquitetura, as

classes de software e os testes que devero ser utilizados, por
exemplo, sejam simplesmente escolhidos da plataforma de
artefatos especificadas pela Engenharia de Domnio.
Anlise de Domnio Orientada a Features
Muitos mtodos de anlise do domnio existentes so extenses
ou derivaes do modelo proposto pelo FODA que indicou pioneiramente a importncia da investigao sistmica do ambiente no
qual estaro inseridas aplicaes, para a identificao das variveis
importantes no domnio em estudo. Uma feature uma caracterstica-chave distintiva de um produto, visvel pelo usurio e que
relevante para os stakeholders. Cada produto da linha definido a
partir de uma seleo delas. So essas combinaes que diferem
uns produtos dos outros na linha. Em geral, a anlise do domnio
uma atividade investigativa que visa delimitar o escopo da linha
de produtos atravs da identificao e representao das features.
As caractersticas variveis podem estar associadas ao tempo
ou ao espao. O primeiro caso acontece quando h mais de
uma verso de um mesmo artefato em diferentes momentos (
comum que a evoluo tecnolgica cause este tipo de estado).
Quando h diferentes verses que podem ser usados em um
dado momento temos a presena da variabilidade no espao. As
features podem ser identificadas e classificadas em termos dos
servios que podem ser oferecidos, das tecnologias empregadas, do tipo de rede utilizado, do nvel de segurana requerido,
do tipo de interface, das tcnicas de implementao aplicveis,
do hardware que ser utilizado e do ambiente operacional onde
o sistema ser implantado, por exemplo.
Depois de identificadas, as features so representadas em um
modelo hierrquico para que as relaes e dependncias sejam
mais facilmente evidenciadas. Tais modelos so muito teis
no levantamento de informaes com os stakeholders. Ainda
no h uma linguagem padro, como a UML (Unified Modeling
Language), para modelar features. A definio de alternncia ou
exclusividade de uma feature em um modelo o grande fator
variante entre uma notao e outra. A primeira notao foi
proposta pelo projeto FODA e mostrada na Figura 4.
Figura 5. Notao Czarnecki-Eisenecker
Outra notao, a Extended Czarnecki-Eisenecker, como

o nome j prope, estende da Czarnecki-Eisenecker. Sua
principal caracterstica a ausncia dos indicadores de
obrigatria e opcional em seus nodos de sub-features, em
contrapartida utiliza-se a cardinalidade para representar
tais relacionamentos (Figura 6).
Figura 6. Notao Extended Czarnecki-Eisenecker
A notao FeatuRESB (Figura 7) segue todo padro da Original FODA, sua divergncia est na representao de subfeatures onde classifica como pontos de variao dinmico
ou esttico e obrigatrio. Esta representao, porm j est
superada pela notao Gurp-Bosch-Svahnberg (Figura 8).
Figura 4. Notao Original FODA
A primeira derivao da Original FODA a notao Czarnecki-Eisenecker a qual alm de definir features obrigatrias
e opcionais, alternativas e alternativas exclusivas, representa
sub-features alternativas e opcionais. Em todos os nodos possui
a indicao de obrigatria e opcional, seja em uma feature ou
em uma sub-feature. Na Figura 5 temos essa representao.
Figura 7. Notao FeatuRESB
Diferentemente da FeatuRESB, a notao Gurp-BoschSvahnberg volta a apresentar as sub-features como alternativa

e alternativa exclusiva. Ela adiciona a questo dinmica
51
sub-fetures que possam ser adicionadas aps atingir um certo

estado de utilizao do software ou uma ao que venha a
adicionar uma funcionalidade ao produto depois de concludo.
Figura 8. Notao Gurp-Bosch-Svahnberg
Como apresentado, embora possuam representaes diferentes, as notaes apresentadas so bastante parecidas quanto
as suas caractersticas grficas, pois todas derivam da notao
FODA. Para exemplificar, um modelo de feature simplificado,
que representa uma famlia de celulares, apresentado na
Figura 9. A notao utilizada a de Czarnecki-Eisenecker.
Percebe-se que h caractersticas comuns e especficas para
diferentes celulares. Fazendo uma breve leitura, note que os
crculos preenchidos indicam que todos os celulares da linha
tero uma porta para entrada e sada de dados do sistema (1).
obrigatrio escolher uma forma de interatividade que, de
acordo com (2), pode ser por teclado, por uma tela sensvel
ao toque ou ambos. Todos os celulares tero um sistema operacional que nico, como indicado em (3), que pode ser um
sistema especfico, suportar o Windows CE ou Linux ME, mas
nunca mais de um ao mesmo tempo. Nem todos os celulares
tm suporte a carto de memria (4). Pode-se observar que
diferentes combinaes das features demonstradas ocasionam
verses diferentes de um celular da mesma marca. Dessa forma
estando bem representado o domnio garante-se o reuso e uma
produo em paralelo de forma eficaz.
Figura 9. Exemplo de modelo de features para uma linha de produo de celular
A utilizao de apoio ferramental para a criao dos modelos

muito importante. A ferramentas XFeature e Gears servem a
este propsito. Alguns plug-ins para o IDE (Integrated Development Environment) Eclipse tambm podem ser utilizados
como alternativa. o caso do FeaturePlugin, fmp e o fmp2rsm
e o pure::variant.
Aspectos econmicos
Um dos primeiros aspectos que precisa ser considerado na

adoo a maturidade da empresa em relao aos negcios.
Enquanto as tcnicas da Engenharia de Software voltadas
para a melhoria de custos e qualidade possuem uma frgil
conexo com as questes diretamente relacionadas ao negcio,
52
as Linhas de Produtos influenciam naturalmente esta perspectiva. Quando se estabelece uma plataforma de produtos, a
primeira coisa que se deve perceber se existe um segmento de
mercado a ser atacado, o que muitas vezes no est aflorado. O
alinhamento das plataformas de produo com as estratgias
de negcio podem conduzir a uma presena de mercado muito forte. Optar por implantar uma linha requer uma anlise
organizacional que responda a questes importantes para
justificar o investimento necessrio adoo.
Em primeiro lugar, quais so as estratgias que a empresa usa
para determinar como novos produtos sero criados? Diferentes abordagens existem e se baseiam em modelos orientados ao
cliente (sob demanda), orientados ao fornecedor (de prateleira),
orientados a tecnologia ou orientados a mercado (quando a
empresa aposta na inovao e sempre busca as oportunidades
para novos projetos). Dependendo do modelo que a empresa
utiliza, o processo de adoo das linhas poder ter um custo
muito elevado. Este o caso de contratos orientados ao cliente,
que sugere que a organizao no est atenta ao mercado em
potencial, j que adota uma postura mais passiva diante dele
esperando que os clientes iniciem os novos projetos.
Qual a estratgia de mercado que a empresa utiliza para
ser reconhecida no mercado? Existem trs principais tipos de
estratgias: liderana de preo (definem o preo mais baixo
chegando a ficar prximo aos custos de produo), a diferenciao (oferecem servios ou funcionalidades diferenciadas dos
concorrentes) e o foco (especialista em um nicho de mercado).
Como o ciclo de vida da linha de produtos no mercado? Para
sistemas individuais os estgios so representados pela introduo do produto no mercado, crescimento (novos requisitos
ainda so adicionados), maturidade (pice do seu desempenho
face aos clientes), saturao (o produto comea a no atender
algumas demandas) e degenerao (abandono). Numa linha de
produtos preciso levar em conta o conjunto de produtos. Duas
perspectivas so importantes: a variao e o tempo. Na primeira,
onde existem variaes de produtos na linha, pode ocorrer um
processo conhecido como canibalizao onde os sistemas competem entre si. Na variao do tempo, que geralmente ocorre
quando as variaes surgem em decorrncia da mudana da
tecnologia, pode resultar na renovao dos produtos da linha.
Uma linha de produtos capaz de dar suporte s estratgias de
mercado da empresa (liderana de preo ou inovao, por exemplo)
porque considera o reuso como a base do processo de desenvolvimento, com isso possvel atingir resultados que favoream a
reduo dos custos do desenvolvimento, o aumento da qualidade,
a reduo do time-to-market, dos esforos com manuteno e da
melhoria nas estimativas. Aps avaliar se os aspectos relacionados
ao negcio esto afinados com a filosofia da Engenharia de Linhas
o processo de adoo pode passar para a prxima etapa.
Concluso
Apesar de trazer muitos benefcios, a filosofia de Linhas de

Produtos impe muitos desafios. Em primeiro lugar porque
as empresas de software precisam mudar a maneira de como
elas enxergam os clientes, a sua postura de mercado e como
DESENVOLVIMENTO
queiram usar a abordagem de LPS. Para isso, um mtodo

para identificao de famlias de produtos, chamado YANA,
avaliar a organizao e indicar se existem potenciais
famlias a serem derivadas em funo das aplicaes que a
empresa j desenvolve.
Links
Site sobre Linhas de Produtos de Software - Software Engineering Institute (SEI)
http://www.sei.cmu.edu/productlines/index.html
Monografia Comparao Entre Ferramentas para Linha de Produtos de Software, escrita
Rogrio Aguiar de Lima Jnior
http://dsc.upe.br/~tcc/20081/RogeriomonografiaFinal.pdf
Livro Generative Programming: Methods, Tools, and Applications. Addison-Wesley escrito
por Krysztof Czarnecki e Ulrich Eisenecker.
http://www.pdf-search-engine.com/generative-programming-methods-tools-andapplications--pdf.html

Feedback
eu
edio
ta
D
s
Relatrio tcnico Feature-oriented domain analysis (FODA) feasibility study, escrito por Kyo
C.Kang, Sholom G. Cohen, James A. Hess, William A. Novak, Spencer Peterson.http://wwwiti.
cs.uni-magdeburg.de/iti_db/lehre/epmd/2008/bib/foda.pdf
Artigo Integrating Feature Modeling with the RSEB escrito por Giss, M. L. Favaro, J. dAlessandro
http://www.favaro.net/john/home/publications/rseb.pdf
Artigo Exploring the Commonality in Feature Modeling Notations escrito por Miloslav Sipka.
http://www2.fiit.stuba.sk/iit-src/2005/22-sipka.pdf
Artigo Managing Variability in Software Product Linesescrito por Tommi Myllymki
http://practise2.cs.tut.fi/pub/papers/VarMgnFinal.pdf
sobre e
s
elas gerenciam o seu portflio de produtos j que iro mudar

o foco para uma viso de negcios mais ampla. Atualmente,
muitas empresas ainda concentram uma parcela considervel
de tempo, esforo e investimento na aquisio e aprendizado
de tecnologias, deixando em segundo plano as estratgias para
captao de novos projetos.
O paradigma de LPS oferece a oportunidade para que estas
empresas reestruturem seus processos internos. Mas, o fato
que elas no conhecem esta abordagem. Alm disso, considerando que ela inerentemente complexa pela riqueza de
informaes que contm e que grande parte do conhecimento
ainda est concentrado no meio acadmico, quase impossvel
considerar a implantao de LPS sem o auxlio de especialistas.
Os custos relacionados aos investimentos necessrios para
adotar a estratgia, o tempo que durar a implantao e os
efeitos decorrentes com o rompimento das prticas e condutas
do modelo tradicional de desenvolvimento so fatores desmotivadores para a adoo.
Alm disso, pouco consenso existe para o uso de terminologia e para a definio de padres na rea o que causa entrave
nas discusses. Um grande desafio ainda a ser vencido est
relacionado modelagem da variabilidade das features. Apesar
da modelagem de domnio ser bastante til para documentar
em que as instncias dos produtos em uma linha diferem,
necessrio propagar a variabilidade ao longo dos artefatos
tradicionais no ciclo desenvolvimento. A variabilidade precisa
ser representada em diferentes nveis de abstrao, para que
os usurios possam visualizar caractersticas especficas para
alguns sistemas e finalmente, em mais baixo nvel a equipe de
desenvolvimento possa perceber os pontos de variao nos
artefatos do projeto. Contudo, ainda no h uma abordagem
unificada para este tipo de especificao.
Atualmente na UFPB, Campus Litoral Norte, est sendo
desenvolvido um projeto que auxiliar as organizaes que
53
54
ENGENHARIA DE SOFT WARE
Governana de Tecnologia de Informao

Uma Viso Integrada Engenharia de Software
Monalessa Perini Barcellos

monalessa@inf.ufes.br
Doutoranda em Engenharia de Sistemas

e Computao (COPPE/UFRJ), Mestre em
Engenharia de Sistemas e Computao (COPPE/UFRJ), Bacharel em Cincia da Computao (UFES). Professora do Departamento
de Informtica, rea Engenharia de Software, da Universidade Federal do Esprito Santo
(UFES). Atuante desde 1999 em projetos,
consultorias, treinamentos e pesquisas da
rea de Engenharia de Software.
Alex Sandro Barreto Rodrigues

asbrodrigues@yahoo.com.br
profissional da rea de Governana de TI,

Master Business Administrator em Gerncia
de Projetos (FGV), Foundation Certificate in
IT Service Management - ITIL, Professor da
graduao e ps-graduao das Unidades
de Negcio e de Sistemas da FAESA (Vitria
- ES), Professor de ps-graduao da UCL
(Faculdade do Centro Leste) (Vitria - ES),
Criador e Coordenador do LIG (ITSMF) do
Esprito Santo. Atuante desde 1997 em projetos, consultorias e treinamentos relacionados a Tecnologia da Informao.
os dias de hoje, quase impossvel pensar em uma organizao que no faa uso
da Tecnologia da Informao. Se h
alguns anos a Tecnologia da Informao
era privilgio das grandes empresas e
centros de pesquisa, hoje ela pode ser
considerada uma necessidade comum a
praticamente todos os tipos de organizaes, desde a vendinha do Seu Joaquim
at as grandes empresas multinacionais.
No incio de sua utilizao nas organizaes, a Tecnologia da Informao teve
sua aplicao focada principalmente no
apoio realizao de processos operacionais. Com o passar do tempo e com
as evolues tecnolgicas que ocorreram
em ritmo acelerado, a Tecnologia da Informao passou a apoiar processos de
todos os nveis e reas das organizaes.
Mas, o que levou as organizaes
a destinarem grande parte de seus
oramentos para investimentos em
Tecnologia da Informao? Modismo?
Definitivamente no.
Este artigo apresenta os principais conceitos e

padres relacionados Governana de TI e oferece
uma viso para integrar a Engenharia de Software
a esse contexto.
Para que serve?

Fornecer conhecimento essencial sobre Governana
de TI e o posicionamento da Engenharia de Software
nesse contexto para organizaes, pesquisadores,
estudantes e profissionais de software.

Organizaes que realizam ou desejam realizar Governana de TI e desejam integrar suas prticas de
Engenharia de Software a essa abordagem. Pesquisadores, estudantes e profissionais de TI que buscam
entendimento sobre Governana de TI, bem como
sua relao com Engenharia de Software.
A utilizao da Tecnologia de Informao de maneira adequada mostrou-se

como um acelerador do desempenho
organizacional, o que, entre outros,
contribuiu fortemente para o aumento
da competitividade das organizaes.
Percebeu-se, ento, que quanto melhor a
Tecnologia de Informao fosse aplicada
55
e gerida, melhores seriam os resultados obtidos. Em outras

palavras, enxergou-se na Tecnologia de Informao uma aliada
fundamental para as organizaes alcanarem seus objetivos
de negcio.
Apesar dessa percepo, ainda muito comum organizaes
investirem milhes em tecnologia e no obterem o retorno
esperado. Ainda so comuns projetos de Tecnologia da Informao que estouram os prazos e custos e que no atendem
aos requisitos de qualidade desejados. Ainda so comuns os
servios de Tecnologia da Informao prestados de forma
insatisfatria.
Considerando esse cenrio e a dependncia cada vez maior
dos negcios em relao Tecnologia da Informao, torna-se
necessria sua gesto de forma alinhada aos objetivos estratgicos das organizaes. Nesse sentido, surge a Governana de
Tecnologia da Informao, que trata basicamente do alinhamento das aes relacionadas Tecnologia da Informao com
os objetivos do negcio, a fim de que a utilizao da Tecnologia
da Informao seja capaz de agregar valor ao negcio como
um todo.
E onde entra a Engenharia de Software? Para responder a
essa questo basta lembrar que desenvolver e manter software
so atividades relacionadas Tecnologia da Informao e, no
contexto da estrutura organizacional, normalmente a rea de
desenvolvimento de sistemas de uma organizao parte da
rea de Tecnologia de Informao. Ou seja, uma vez que o
desenvolvimento e a manuteno de sistemas fazem parte da
Tecnologia da Informao em uma organizao, estes tambm
so considerados na Governana de Tecnologia da Informao.
Para entender melhor a Governana de Tecnologia da Informao e o posicionamento das prticas de Engenharia de
Software nesse contexto, nas sees seguintes so apresentados
alguns conceitos e padres relacionados ao tema para, ento,
ser possvel localizar a Engenharia de Software no mbito da
Governana de Tecnologia de Informao.
As Organizaes e a Tecnologia de Informao
Organizaes so compostas por diferentes nveis e reas funcionais. Apesar de existirem diversas nomenclaturas propostas
por diferentes autores, comumente diz-se que as organizaes
so estruturadas em trs nveis (nvel estratgico, nvel gerencial
ou ttico e nvel operacional) e que esses nveis so atravessados
pelas reas funcionais da organizao (como vendas e marketing, recursos humanos, produo e finanas, por exemplo).
estrutura formada pelos nveis e reas funcionais d-se o nome
de Arquitetura Organizacional, conforme mostra a Figura 1.
No nvel operacional encontram-se os processos cuja execuo garante o funcionamento dirio da organizao. Em um
banco, por exemplo, depsitos e transferncias so processos
do nvel operacional.
No nvel gerencial (tambm chamado nvel ttico) encontramse os processos relacionados monitorao, controle, tomada
de decises e procedimentos administrativos. No exemplo do
banco, a monitorao e controle do alcance das metas dirias
so processos do nvel gerencial.
56
Figura 1. Arquitetura Organizacional.
No nvel estratgico esto os processos que consideram

uma viso mais ampla da organizao, incluindo seu
posicionamento em relao ao mercado. A anlise de viabilidade para abertura de uma nova agncia bancria ou
lanamento de um novo produto exemplo de um processo
do nvel estratgico.
Em cada nvel, tambm esto as pessoas responsveis pela
execuo dos processos: funcionrios em geral, gerentes, diretores e executivos.
O funcionamento e a integrao entre os processos e as
pessoas que compem a Arquitetura Organizacional podem
ser descritas, macroscopicamente, da seguinte forma: no
nvel estratgico definido o Planejamento Estratgico da
organizao, onde constam os objetivos de negcio, estabelecidos com foco na competitividade organizacional e que
devem ser alcanados em perodos de tempo determinados
(longo, mdio e curto prazo). Para esses objetivos so definidos Planos de Ao, que so executados (em sua maior
parte) no nvel operacional, sendo monitorados e controlados
pelo nvel gerencial.
A palavra-chave que guia os processos do nvel estratgico
competitividade. A questo bsica o que deve ser feito para
que a organizao seja sempre interessante para o mercado.
Por outro lado, a palavra-chave que guia os processos do nvel
gerencial sobrevivncia. A questo bsica passa a ser o que
deve ser feito para que a organizao atinja as metas estabelecidas e, assim, continue funcionando. Por fim, a palavra-chave
que guia os processos do nvel operacional funcionamento,
uma vez que o nvel operacional a gua que move o moinho,
ou seja, faz a organizao funcionar.
A utilizao da Tecnologia da Informao em uma organizao deve ser realizada a fim de apoiar a execuo dos processos
da Arquitetura Organizacional. Ao integrar a Tecnologia da
Informao Arquitetura Organizacional, os processos da
organizao ficam sobre a estrutura de Tecnologia da Informao e quanto melhor apoiados forem os processos, maiores
so as oportunidades de competitividade para a organizao.
A Figura 2 apresenta uma evoluo da Figura 1, evidenciando
a relao entre a Arquitetura Organizacional e a estrutura de
Tecnologia da Informao.
Engenharia de Software Magazine - Governana de Tecnologia de Informao
deve atuar para garantir que a Tecnologia da Informao da

organizao seja capaz de sustentar e estender seus objetivos
estratgicos, atravs do gerenciamento de servios e produtos
de TI de forma dinmica e competitiva. Para isso, a Governana
de TI possui cinco focos principais:
Alinhamento Estratgico: busca integrar TI e negcios.
Agregao de Valor: busca alcanar benefcios com custos
otimizados.
Gerenciamento de Recursos: busca otimizar os investimentos
em recursos de TI, bem como a utilizao desses recursos.
Gerenciamento de Riscos: busca incorporar TI anlise e
resposta aos riscos, bem como conformidade de processos.
Mensurao de Desempenho: busca avaliar e divulgar o
desempenho dos aspectos tratados pela TI.
Figura 2. Arquitetura Organizacional e estrutura de TI.
Conforme ilustrado na Figura 2, a estrutura de Tecnologia

da Informao refere-se estrutura de hardware, software,
armazenamento de dados e redes de comunicao que apiam
tecnologicamente os processos das organizaes. Sendo assim,
aplicativos de integrao de processos e/ou tomada de deciso,
bem como, sistemas operacionais, servios de redes e correio
eletrnico so partes integrantes da TI.
Vale destacar que a Governana de TI considera alm da estrutura de TI que foi descrita, os recursos humanos envolvidos
em seu desenvolvimento e operao.
Governana de TI
Apesar de seu destaque associado Tecnologia de Informao

ser relativamente recente, o termo governana no novo para
a Administrao. A palavra governana significa ato ou efeito
de governar. Governar, por sua vez, significa administrar,
dirigir. No contexto da Administrao, pode-se dizer, ento,
que de certa forma, a governana tem estado presente desde
o final do sculo XIX, quando o foco era a gesto da produo
(tratada principalmente por Taylor, Ford e Fayol), mantendo sua
presena durante as evolues da gesto, que culminaram no
controle da qualidade e produtividade de produtos e processos.
No contexto da Tecnologia da Informao, o termo governana pode ser considerado novo, mas, como tudo o que
relacionado tecnologia, vem evoluindo e ganhando espao
rapidamente.
A Governana de TI faz parte da Governana Corporativa,
que surgiu nos Estados Unidos e na Inglaterra no final dos anos
90 e est relacionada forma como as empresas so dirigidas
e controladas. A Governana Corporativa um conjunto de
prticas de relacionamento entre acionistas, cotistas, conselho
de administrao, diretoria e conselho fiscal, que tem a finalidade de otimizar o desempenho da organizao e facilitar
o acesso ao capital.
A Governana de TI um conjunto de prticas que visam
utilizao e gesto da Tecnologia da Informao alinhada aos
objetivos estratgicos e de responsabilidade da alta administrao (incluindo diretores e executivos de negcio e de TI), que
A utilizao da Governana de TI tem sido impulsionada por

diversos fatores. Como j comentado neste artigo, a intensa
competio mercadolgica tem exigido que as organizaes
realizem grandes investimentos em TI, o que tem tornado o
sucesso dos negcios cada vez mais dependente do sucesso da
aplicao da Tecnologia da Informao. Consequentemente,
as organizaes tm buscado melhorar a gesto dos recursos
destinados TI, sendo necessrias prticas que assegurem que
tanto os gestores quanto a estrutura de Tecnologia da Informao estejam adequados para agregar valor para a organizao
e que o capital destinado para a TI no ser investido em aes
de baixo valor estratgico.
Se por um lado, as prprias organizaes tm percebido a
necessidade de melhorar a gesto da Tecnologia da Informao,
por outro, leis e regulamentaes dos negcios tm imposto
essa necessidade de melhoria. Empresas com aes na bolsa
de valores norte-americana, por exemplo, so obrigadas a
atender aos requisitos do Ato Sarbanes-Oxley. Bancos, por
sua vez, precisam atender aos requisitos de gesto de riscos
operacionais e de crditos previsto no Acordo da Basilia II.
Uma maneira interessante de notar a importncia e a responsabilidade da Governana de TI relembrar alguns escndalos
que ocorreram em empresas norte-americanas.
Em 2001, organizaes como a Enron, a Tyco International e a
WorldCom foram denunciadas por fraudes contbeis e fiscais,
pois divulgaram lucros fictcios em seus relatrios financeiros, a fim de tornarem-se mais atraentes aos investidores de
capitais, omitindo sua real situao financeira. A Enron, na
poca supostamente 7 colocada no ranking da economia
americana, faliu em dezembro de 2001 e a WorldCom demitiu
cerca de 20.000 funcionrios. Ambas, aps vrios processos
e investigaes, tiveram seus principais executivos presos e
responsabilizados pelas fraudes.
Essa onda de escndalos trouxe tona questes como
transparncia, tica nos negcios e conflitos de interesses que
geraram desconfiana e instabilidade entre os investidores
do mercado de capitais. Como resposta onda de fraudes, em
Julho de 2002, os senadores Paul Sarbanes e Michael Oxley
formularam o Ato Sarbanes-Oxley que responsabiliza os
executivos por estabelecer, avaliar e monitorar os controles
57
internos relacionados aos relatrios financeiros da organizao.

O objetivo principal do ato proteger os investidores do mercado de capitais americano de fraudes contbeis e financeiras,
bem como responsabilizar os envolvidos com uma srie de
penalidades.
Mas, o que isso tem a ver com Governana de TI?
Em sntese, o Ato Sarbanes-Oxley prev controles internos
sobre os relatrios financeiros das empresas. Os relatrios
produzidos devem ser atestados pelos principais executivos
da organizao. E, normalmente, de onde vm esses relatrios?
Esses relatrios so resultado de vrias transaes que dependem de operaes de TI, como sistemas de informao, acessos
autorizados a redes de dados, armazenamento e recuperao
de informaes, entre outros. Ou seja, a figura do gestor de
TI ou executivo de TI passa a ter uma conotao equivalente
aos demais executivos da organizao, uma vez que somente
uma gesto transparente e alinhada aos objetivos de negcio
da organizao pode ser capaz de justificar os investimentos
em TI e atestar a qualidade dos produtos desenvolvidos e
servios prestados.
Estrutura da Governana de TI
Tradicionalmente, a estrutura da Governana de TI representada por uma figura que se assemelha a uma casa, conforme
mostra a Figura 3.
Conforme mencionado, no telhado definido o que deve ser feito

para que seja possvel obter uma gesto de TI alinhada aos objetivos
estratgicos. Nos pilares, por sua vez, o que transformado em
como, ou seja, as diretrizes fornecidas pela Governana de TI so
incorporadas aos processos definidos em cada pilar.
Na base da casa, as operaes de TI fornecem a fundao para
que os processos definidos nos pilares possam ser corretamente realizados, produzindo resultados aderentes aos princpios
da Governana de TI.
Apesar da estrutura de Governana de TI incluir vrios componentes, nem sempre necessrio que uma organizao implemente
todos. O que define o que deve ou no ser incluso na Governana
de TI em uma organizao so suas necessidades, objetivos e
recursos. Alm disso, uma organizao pode, tambm, optar por
uma abordagem gradativa, trabalhando inicialmente nos pilares
mais crticos e, aos poucos, inserindo os demais pilares.
Modelos, Normas e Melhores Prticas
Para apoiar a implementao da Governana de TI nas organizaes, h no mercado, um conjunto de modelos, normas,
prticas e frameworks que podem ser adotados, em conjunto
ou no, para atender s demandas da Governana de TI. Esses
modelos, normas, prticas e frameworks so recomendados,
pois foram elaborados por rgos especficos com grande
conhecimento em suas respectivas reas. Salvo algumas
excees, no faz sentido, por exemplo, reinventar a roda do
gerenciamento de projetos, uma vez, que existe um guia de
conhecimento mantido pelo PMI (Project Management Institute) bastante utilizado e aceito pelo mercado.
Na Figura 4 os principais modelos, normas, prticas e frameworks so relacionados aos componentes da estrutura de
Governana de TI que melhor apiam. Em seguida apresentada uma breve descrio de cada um.
Figura 3. Estrutura da Governana de TI.
O telhado de uma casa, como se sabe, deve cobrir toda sua estrutura. Analogamente, no telhado da estrutura da Governana
de TI encontram-se processos, prticas e diretrizes especficos
da Governana de TI, ou seja, que definem o que deve ser feito
para que a gesto de TI da organizao seja alinhada aos seus
objetivos estratgicos.
Sob o telhado esto os pilares da Tecnologia da Informao da
organizao, ou seja, todos os conjuntos de processos que esto
relacionados TI e so responsveis por sustent-la na organizao.
58
Figura 4. Frameworks de apoio Governana de TI.
COBIT (Control Objectives for Information and Related Technology)

considerado o modelo mais abrangente de Governana de
TI. O Information Technology Governance Institute (ITGI)
atualmente o responsvel pelo COBIT. composto por 34
processos que esto organizados em quatro domnios que

espelham os agrupamentos de TI usuais em uma organizao:
Planejamento e Organizao; Aquisio e Implementao;
Entrega e Suporte; e, Monitorao e Avaliao. As interaes
entre esses grupos de processos definem um ciclo de vida que
contribui para o alinhamento da TI aos objetivos estratgicos
da organizao. COBIT foca o sucesso da entrega de produtos
e servios de TI, a partir da perspectiva das necessidades do
negcio, com um foco mais acentuado no controle que na
execuo. Ou seja, preocupa-se mais com o que deve ser feito
que como deve ser feito.
ITIL (Information Technology Infrastructure Library)
Descreve um conjunto de melhores prticas para gesto
dos servios de TI. Foi criada no final dos anos 80 pela CCTA
(Central Computing and Telecommunications Agency) para o
governo britnico e recebeu esse nome devido quantidade
de livros gerados para descrever as melhores prticas. Atualmente, a ITIL est em sua terceira verso e apresenta um
framework para gerenciar o ciclo de vida dos servios de TI.
Inclui livros com melhores prticas para: definio e execuo
da estratgia de servios, projeto e desenvolvimento de servios, transio de servios, operao de servios e melhoria
contnua dos servios.
ISO/IEC 20000 Information Technology Service Management
A norma ISO/IEC 20000, formulada a partir da BS 15000
(British Standards Instituitions Standard for IT Service Management), foi publicada em 2005 para responder s necessidades
de entendimento comum sobre gerenciamento de servios de
TI. Caracteriza o gerenciamento de servios de TI baseando-se
nas melhores prticas reunidas na ITIL e promovendo a adoo
de um processo integrado para a prestao e o gerenciamento
eficaz dos servios de TI que respondem aos requisitos do negcio e dos seus clientes. A norma est dividida em duas partes.
A Parte 1 contm as especificaes para o gerenciamento de
servios de TI e fornece os requisitos que devem ser cumpridos
para obteno da certificao ISO 20000. relevante para os
responsveis pela preparao, implementao ou gerenciamento continuado dos servios de TI em uma organizao. A
Parte 2 apresenta o cdigo de prtica e fornece orientao para
auditores internos, bem como assistncia aos prestadores de
servios que planejam melhorias.
CMMI (Capability Maturity Model Integration)
Criado pelo SEI (Software Engineering Institute) com o objetivo de ser um modelo integrado de prticas para apoiar a
Engenharia de Software. O CMMI apia a Governana de TI
uma vez que guia a melhoria dos processos e habilidades organizacionais que cobrem o ciclo de vida de produtos e servios.
Srie ISO/IEC 27000 - Information Security Management
Systems
A ISO/IEC 27001 trata do estabelecimento, implantao,
operao, monitorao, reviso, manuteno e melhoria de
um Sistema de Gesto da Segurana da Informao. Pode ser

usada na avaliao da conformidade de um Sistema de Gesto
da Segurana da Informao por partes interessadas internas
e externas. A ISO/IEC 27002 estabelece os princpios gerais
para iniciar, manter e melhorar a gesto da segurana da
informao em uma organizao, provendo, diretrizes sobre
as metas geralmente aceitas nesse mbito. Pode ser utilizada
como um guia para elaborar os procedimentos de segurana
da informao e prticas eficientes de gesto de segurana em
uma organizao.
PMBoK (Project Management Body of Knowledge)
um documento que contm o conhecimento considerado
relevante ao gerenciamento de projetos. mantido pelo PMI
(Project Management Institute), uma organizao no governamental que trata das prticas do gerenciamento de projetos.
O PMBoK define um conjunto de processos necessrios ao
gerenciamento de projetos, relacionando-os a nove reas de
conhecimento (escopo, tempo, custos, recursos humanos,
qualidade, riscos, comunicaes, aquisio e integrao) e
organizando-os em grupos de processos (iniciao, planejamento, execuo, controle e encerramento) que compem o
ciclo da gerncia de projetos.
BSC (Balanced Scorecard)
um mecanismo que auxilia as organizaes no alinhamento
de suas aes em relao a seus objetivos estratgicos. Est organizado considerando quatro perspectivas do negcio: perspectiva
financeira, perspectiva de processos internos, perspectiva de
aprendizado e crescimento e perspectiva do cliente. A relao
entre os objetivos do negcio e as perspectivas demonstrada
por meio de mapas estratgicos, que representam a criao de
valor em uma organizao. O BSC pode ser utilizado para apoiar
as organizaes no Planejamento Estratgico da TI, uma vez que
permite desdobrar os objetivos estratgicos de TI em iniciativas
que contribuam para os objetivos estratgicos da organizao.
Essas iniciativas podem ser realizadas em projetos que podem ser
acompanhados, medidos e verificados at que sejam concludos.
Srie ISO 9000:2000 - Sistema de Gesto da Qualidade
uma srie de normas que utiliza princpios da gesto da qualidade total e tem como principal objetivo a gerao de produtos
e/ou servios em conformidade com requisitos estabelecidos. O
ciclo PDCA (Plan, Do, Check, Act) usado na ISO 9000:2000 para
tratar a melhoria contnua do Sistema de Gesto da Qualidade.
Pode ser utilizada em conjunto com outras prticas para garantir
a qualidade na entrega dos produtos/servios. Vale ressaltar que
o ciclo PDCA presente na ISO 9000:2000 tambm utilizado em
outras normas como, por exemplo, na ISO/IEC 20000 onde o foco
a melhoria contnua dos servios de TI.
A Engenharia de Software na Governana de TI
Conhecidos os principais conceitos e a estrutura da Governana de TI, a relao entre Engenharia de Software e Governana de TI torna-se bastante clara. No?
59
A Governana de TI foi inicialmente impulsionada pela

necessidade das organizaes atenderem requisitos definidos
em legislaes especficas de seus segmentos. Percebidos os
benefcios gerais alcanados, a Governana de TI passou a ser
atraente para organizaes em geral e vem conquistando cada
vez mais seu espao.
Na Governana de TI, os tradicionais gerentes de TI tm
novas responsabilidades e uma nova viso organizacional
deles exigida, a fim de que se transformem em gestores de TI.
Ao contrrio do que se imagina, gestores de TI, gerentes de
projetos e engenheiros de software no so concorrentes na
rea de TI. Na verdade, esto todos no mesmo barco e, se querem chegar ao destino que representa o sucesso da organizao
como um todo, precisam remar de maneira sincronizada e na
mesma direo.
Referncias

D
s
FERNANDES, A. A., ABREU, V. F., 2008, Implantando a Governana de TI: da Estratgia Gesto
dos Processos e Servios, 2. Edio, Brasport, Rio de Janeiro.
LAUDON, K. C., LAUDON, J. P., 2004, Sistemas de Informao Gerenciais Administrando a
Empresa Digital, 2. Edio, Pearson - Prentice Hall, So Paulo.
MAGALHES, I. L.; PINHEIRO, W. B., 2007, Gerenciamento de Servios de TI na Prtica: Uma
Abordagem com Base na ITIL, Novatec, So Paulo.
Feedback
eu
edio
ta
60
Concluso
sobre e
s
Analisando-se a Figura 3, possvel perceber que prticas de

Engenharia de Software podem ser encontradas pelo menos
nos pilares Desenvolvimento de Aplicaes, Gerenciamento
de Projetos e Sistema de Qualidade. Mas, exatamente onde?
Em Desenvolvimento de Aplicaes so construdos os sistemas de informao necessrios organizao. Para desenvolver software devem ser utilizadas prticas de Engenharia
de Software. Alm disso, comum que o desenvolvimento
de sistemas seja realizado por meio de projetos, e projetos
devem ser gerenciados (no pilar Gerenciamento de Projetos
da estrutura de Governana de TI). Para gerenciar projetos de
desenvolvimento e/ou manuteno de software, as prticas de
Engenharia de Software concernentes gerncia dos projetos
precisam ser realizadas. Por fim, os softwares produzidos e os
processos que os produzem precisam atender aos requisitos
de qualidade de produto e processo de software estabelecidos,
o que tambm envolve prticas da Engenharia de Software,
como prticas de garantia da qualidade, por exemplo, que na
estrutura de Governana de TI esto presentes no pilar Sistema
de Qualidade.
Como argumentado no incio deste artigo, o desenvolvimento e a manuteno de software so atividades relacionadas
Tecnologia da Informao. E, uma vez que no contexto da
estrutura de Governana de TI, elas encontram-se sob os princpios dessa forma de gesto, importante que suas prticas
sejam condizentes com as demais prticas relacionadas a TI,
guiadas pela Governana de TI. Em outras palavras, falar em
Governana de TI envolve falar em Engenharia de Software.
Planejar adequadamente a Governana de TI em uma organizao exige que os aspectos relacionados Engenharia de
Software tambm sejam considerados e corretamente estruturados na estratgia de Governana de TI definida. Para isso,
necessrio que os papis, responsabilidades, entradas, sadas
e interaes sejam claramente estabelecidos ao longo de toda
a estrutura de Governana de TI adotada.
61
62

Teste de Software 15

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Teste de Software 15

Hochgeladen von

Copyright:

Verfügbare Formate

16

.Net Magazine - Quick Update

Capa ESM - Final .pdf

Entenda os principais conceitos sobre

Conhea os principais conceitos envolvidos

Entenda o conceito de Arquitetura de Software e

Melhore seus processos atravs da

Veja como integrar conceitos de

Veja como integrar o Processo

Mais de 60 mil downloads

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

Ano 2 - 15 Edio 2009

Um importante fator de sucesso de um software sua qualidade.

Rodrigo Oliveira Spnola

Cristiany Queiroz Atendimento ao Leitor

Fale com o Editor!

Marco Antnio Pereira Arajo

Eduardo Oliveira Spnola

14 - Incorporando Restries UML

22 - UML Diagrama de Sequncias

30 - Testes de Software, um processo criativo

36- Manuteno: Desafios para os Testes numa Fbrica de Software

48 - Linhas de Produtos de Software

55 - Governana de Tecnologia de Informao

Engenharia de Software Magazine

Edio 05 - Engenharia de Software Magazine

Priorizao Voltada para Resultados

Mestre em Engenharia de Software com

riorizar significa determinar uma

Engenharia de Software Magazine - Priorizao Voltada para Resultados

Neste artigo entenderemos os problemas causados

Para que serve?

Em que situao o tema til?

funcionalidades implementadas so raramente ou nunca

muito fcil pensar que os responsveis pela priorizao, ou

o contrato pelo mesmo motivo: aumentar a sua segurana.

Quando a ordem importa

Priorizar, basicamente, significa definir uma ordem para que

Edio 15 - Engenharia de Software Magazine

Desenvolvimento iterativo, priorizao iterativa

Modelos de desenvolvimento iterativos tm se mostrado

O tamanho das iteraes est relacionado com caractersticas

primeiras estimativas. Nas prximas priorizaes, possvel

Engenharia de Software Magazine - Priorizao Voltada para Resultados

Figura 1. Plano com os eixos de Valor e Risco com

Depois de dispor as funcionalidades no plano, este dividido

Figura 2. Sequncia de implementao para equipes

Edio 15 - Engenharia de Software Magazine

Equipes com pouca experincia em desenvolvimento gil

periodicamente, mantm o foco nas funcionalidades de maior

Uma priorizao adequada das funcionalidades faz parte

A Engenharia de Software Magazine tem que ser feita ao seu gosto.

Engenharia de Software Magazine - Priorizao Voltada para Resultados

D seu feedback sobre esta edio!

Muitas vezes, independente de implementao escolhida,

Figura 3. Sequncia de implementao para equipes

Modstia parte, sua

So programas voltados para a

Acesse nosso site e conhea todos os nossos programas: www.infnet.edu.br/esti

EDUCAO SUPERIOR ORIENTADA AO MERCADO

Edio 15 - Engenharia de Software Magazine

Incorporando Restries UML

De que se trata o artigo?

Doutorando em Engenharia de Computao e