Engenharia de Software - Edição 67

Rodrigo Oliveira Spnola
rodrigo.devmedia@gmail.com
Doutor e Mestre em Engenharia de Software pela COPPE/UFRJ. Realizou seu Ps-Doutorado na
University of Maryland Baltimore County e Centro Fraunhofer nos Estados Unidos. Atualmente
Professor Titular do Programa de Ps-Graduao em Sistemas e Computao da Universidade
Salvador - UNIFACS.
Marco Antnio Pereira Arajo

maraujo@devmedia.com.br
67 Edio - 2014
Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ, Especialista em

Mtodos Estatsticos Computacionais e Bacharel em Matemtica com Habilitao em Informtica pela UFJF.
Corpo Editorial
Editor
Rodrigo Oliveira Spnola
Eduardo Oliveira Spnola

eduspinola@gmail.com
Colaboradores
Marco Antnio Pereira Arajo
Eduardo Oliveira Spnola
Nicolli Souza Rios
Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Magazine.
bacharel em Cincia da Computao pela Universidade Salvador (UNIFACS).
Consultor Tcnico
Daniella Costa
Nicolli Souza Rios

nicolli.devmedia@gmail.com
Formanda em Cincia da Computao na Universidade Salvador (UNIFACS), Gerente de Projetos da
COMMIT Empresa Jnior de Computao da UNIFACS e Estagiria de Desenvolvimento de Software
na BAHIAGS. Faz parte do grupo de pesquisa em Engenharia de Software do Programa de PsGraduao em Sistemas e Computao da UNIFACS.
Jornalista Responsvel
Kaline Dolabella - JP24185
Na Web
http://www.devmedia.com.br/revista-engenharia-de-software-magazine
Atendimento ao Leitor
A DevMedia conta com um departamento exclusivo para o atendimento ao leitor.
Se voc tiver algum problema no recebimento do seu exemplar ou precisar de algum
esclarecimento sobre assinaturas, exemplares anteriores, endereo de bancas de
jornal, entre outros, entre em contato com:
www.devmedia.com.br/central
(21) 3382-5038
Publicidade
Para informaes sobre veiculao de anncio na revista ou no site entre em
contato com:
publicidade@devmedia.com.br
Fale com o Editor!

muito importante para a equipe saber o que voc est achando da revista: que tipo de artigo voc
gostaria de ler, que artigo voc mais gostou e qual artigo voc menos gostou. Fique a 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 ES Magazine,
entre em contato com os editores, informando o ttulo e mini-resumo do tema que voc gostaria
de publicar.
Artigo no estilo Prtico
06 Softwell Maker 3: Crie seu primeiro projeto

[ Ronlio Oliveira ]
Sumrio
Contedo sobre Boas Prticas
14 Medio de Software no CMMI e MPS.BR

[ Anderson Pinheiro Balbo, Wilson Vendramel e Maria Beatriz Felgar de Toledo ]
Artigo no estilo Curso
24 Use Case Point: Estimativas de Projeto Parte 2

[ Anderson Pinheiro Balbo, Wilson Vendramel e Maria Beatriz Felgar de Toledo ]
Contedo sobre Boas Prticas, Contedo sobre Engenharia
31 Casos de Teste: Importncia da rastreabilidade entre requisitos

[ Ana Paula Gonalves Serra e Edson Saraiva de Almeida ]
Contedo sobre Boas Prticas, Contedo sobre Engenharia
38 Mtricas de Software
D
s
[ Darlan Florncio de Arruda ]
Feedback
eu
[ Arilo Claudio Dias Neto ]
Artigo no estilo Prtico
49 SMarty Check: Conhecendo a Tcnica de Inspeo de software

[ Edson A. Oliveira Junior e Diogo Cassio Pereira ]
edio
ta
43 Casos de Teste: Aprimore seus casos e procedimentos de teste
sobre e
s
Contedo sobre Engenharia, Artigo no estilo Mentoring
D seu feedback sobre esta edio!

A Engenharia de Software Magazine tem que ser
feita ao seu gosto.
Para isso, precisamos saber o que voc, leitor, acha
da revista!
56 Trabalhando com Testes Exploratrios

[ Anne Caroline Noronha ]
www.devmedia.com.br/esmag/feedback
Edio 05 - Engenharia de Software Magazine
Planejamento e Gerncia
Nesta seo voc encontra artigos voltados para o planejamento
e gerncia de seus projetos de software.
Softwell Maker 3: Crie seu primeiro projeto

Inserindo agilidade no desenvolvimento de software
Fique por dentro:
Ronlio Oliveira
ronelio.oliveira@gmail.com
Formado em Anlise e Desenvolvimento

de Sistemas, Ps Graduado em Qualidade e
Governana de TI, Certificado CBTS. Experincia de 07 anos na rea de TI. Atualmente,
coordena a Equipe de QA e a rea de Produtos da Softwell Solutions.
crise de software surgiu devido

grande demanda de software, falta de tcnicas e grande
complexidade nos problemas a serem
resolvidos. Apesar de ter surgido a quase
5 dcadas, a crise de software ainda
muito visvel no dia a dia de desenvolvedores, analistas, gerentes de projetos
e principalmente o cliente final. Projetos
com oramentos e prazos estourados,
softwares com baixa qualidade e cdigo
difcil de manter so algumas das formas
da crise se manifestar.
Diante destes problemas, o Maker
surge para quebrar paradigmas e simplificar o processo de desenvolvimento
de software. Ele uma ferramenta de
desenvolvimento web voltada para o
ambiente corporativo e a sua principal
caracterstica permitir que o desenvolvimento seja realizado sem a utilizao
de linhas de cdigo. As regras de negcio
do projeto so desenvolvidas utilizando
fluxogramas e recursos visuais que proporcionam o aumento da produtividade
e ainda agregam poderosos recursos ao
produto final.
Engenharia de Software Magazine - Softwell Maker 3: Crie seu primeiro projeto
A ideia desse artigo demonstrar a utilizao

da ferramenta de desenvolvimento Maker 3,
apresentando seus componentes e principais
funcionalidades que facilitaro o uso da ferramenta no dia a dia dos desenvolvedores Maker.
No decorrer do artigo, demonstraremos a criao de um simples projeto no banco de dados
SQL Server. Procura-se demonstrar a nova
verso do Maker 3, ferramenta de desenvolvimento RAD Web. Este artigo til tanto para
os novos desenvolvedores Maker quanto para
os desenvolvedores mais experientes que ainda
no tiveram contato com o Maker 3.
Alm disso, o Maker acompanhado

de assistente de formulrios, assistente
de consultas, assistente de relatrios,
assistente de criao de tabelas e muitos
outros recursos que auxiliam o desenvolvedor durante desenvolvimento do
projeto.
Mas essa ferramenta no s para desenvolvimento em fluxogramas, o Maker
tambm a simplificao do processo
de desenvolvimento que, muitas vezes,
se torna burocrtico e custoso nas organizaes, o que geralmente implica em
planejamento
cronogramas atrasados e com oramento alm do previsto.

Dessa forma, ganhamos agilidade ao empreg-lo no desenvolvimento de solues customizadas.
Mas em que situaes o Maker simplifica?
quando seu projeto desenvolvido facilmente portado para
a plataforma .NET;
quando seu projeto pode ser facilmente portado para a plataforma Mobile sendo Android e/ou iOS;
quando seu projeto pode ser publicado facilmente em servidores de aplicaes Java;
quando mostra boas prticas para o desenvolvedor durante
seu uso;
abstrao da documentao do projeto, que gerada
automaticamente;
quando a migrao para qualquer banco de dados feita
apenas com alguns cliques.
E tudo isso sem que nada precise ser reescrito. Desenvolver
com o Maker normalmente muito mais rpido que utilizando
abordagens mais tradicionais de desenvolvimento. Isso sem
falar na curva de aprendizagem que baixa.
A Tabela 1 apresenta um breve resumo do Maker.
Nota: Portabilidade para outros bancos
A migrao para banco de dados sem que sejam necessrios ajustes possvel quando o
desenvolvedor no utiliza funes especficas de um determinando banco de dados. Demais
particularidades como tipo de campo, entre outros, tratado automaticamente pelo Maker.
O que ?
IDE para desenvolvimento RAD de aplicaes corporativas.
Plataformas
Java, .NET e Mobile (Android e iOS)
Banco de dados
Microsoft SQL Server, PostgreSQL, IBM DB2, Oracle Database, MySQL

e Firebird.
Forma de desenvolvimento
WYSIWYG e editor de regras de negcio via fluxogramas.
Recursos Extras
Editor de CSS integrado, possibilidade de criao de seus prprios

componentes, plug-ins que do mais apoio ao desenvolvimento,
avaliao de boas prticas no fluxo e API de funes extensvel.
Tabela 1. Ficha tcnica do Maker
Como o Maker armazena os dados do projeto

Durante o desenvolvimento do projeto, o Maker armazenar
os seguintes artefatos: formulrios, fluxos, relatrios, documentao do projeto e versionamento destes objetos. Estes
so facilmente visveis no gerenciador de objetos na rea de
trabalho do Maker.
Todos os artefatos desenvolvidos pelo Maker so armazenados no banco de dados, nas tabelas com prefixo FR_, e por isso
necessrio que exista uma conexo ativa com um dos bancos
de dados suportados. Desta forma, quando h vrios desenvolvedores no mesmo projeto, os objetos desenvolvidos ficam
visveis a todos e o Maker versiona cada objeto para consultas
futuras. possvel observar neste ponto que os processos de
checkin, checkout, commit, entre outros, so abstrados pois
o controle passa a ser feito pela prpria ferramenta.
Todo formulrio Maker, quando vinculado a uma fonte de

dados, ter automaticamente o CRUD pronto, sendo que caso
seja especfico da sua regra de negcio, o CRUD poder ser
desenvolvido ignorando assim o comportamento padro.
Webrun
O Webrun o framework responsvel por obter todos os
objetos desenvolvidos no Maker e compil-los para exibir
ao usurio final ou ao desenvolvedor durante o processo de
desenvolvimento.
Como todos objetos desenvolvidos, sejam eles fluxos (regras
de negcio), formulrios ou relatrios, so armazenados no
banco de dados, estes precisam ser extrados, direcionados
(camada cliente/servidor) e compilados para uso posterior. Este
processo pode ser facilmente entendido conforme Figura 1.
O papel do Webrun est alm de compilar os objetos desenvolvidos para entregar ao usurio final. Todo o controle de persistncia de dados, gerenciamento de perfis de acesso, controle
de segurana de acesso aplicao e ainda prover Webservices
para consumo, so funcionalidades, tambm, do Webrun.
Para resumir o importante papel do Webrun, podemos compar-lo a uma JVM. Os formulrios e fluxos seriam os bytecodes e o Webrun seria a JVM responsvel por interpret-los.
API de Funes
Hoje o Maker possui aproximadamente 747 funes disponveis para o desenvolvedor. Dentre estas, temos funes disponveis para acesso a dados, chamada de DLLs, comunicao
com applets e consumo de Webservices.
Todas as funes so agrupadas por categoria para facilitar a
localizao das mesmas. Por exemplo, a categoria Banco de dados possui todas as funes relacionadas a operaes de banco
de dados como abrir consulta e executar atualizao. O nome
das funes intuitivo, por exemplo: Alterar valor do componente,
obter valor do componente, Abrir formulrio entre outras.
Alm das funes disponveis, o desenvolvedor poder
estender a API. Geralmente, o desenvolvedor estende a API
para atender algum projeto especfico visto que a API atual
atende a aproximadamente 95% dos projetos desenvolvidos.
Para estender a API o desenvolvedor dever ter conhecimento
de JavaScript para funes na camada cliente ou Java para
funes na camada servidor.
Criando seu primeiro projeto

Iremos criar agora um pequeno projeto que ser chamado de
Agenda Dev. Antes de prosseguir, certifique-se de que possui
os seguintes itens no seu ambiente:
SQL Server Express com protocolo TPC/IP ativo;
Maker 3.1;
Webrun 3.1. Instalado junto com o Maker 3.1;
API de funes 3.0.5+;
Certificado de ter todos os requisitos necessrios, s clicar
na opo Novo Projeto e preencher as informaes para conexo
com o banco de dados.
Figura 1. Processo de compilao dos objetos desenvolvidos
Figura 2. Assistente de criao do projeto

Nota: Acesso ao sistema
As credenciais para acesso ao projeto so: usurio master e senha 1. Mais usurios podero ser
criados posteriormente quando tivermos mais de um desenvolvedor trabalhando no projeto.
importante lembrar que caso o banco de dados no exista, o

mesmo ser criado e inicializado automaticamente pelo Maker.
Caso informe o banco j existente, o Maker criar as tabelas
necessrias para continuao do desenvolvimento.
No primeiro grupo denominado Conectando ao banco
de dados so preenchidas as informaes para conexo
com o banco. Caso a conexo seja realizada com sucesso,
o prximo grupo ser habilitado e ser possvel preencher
as informaes do projeto que est sendo

criado. Preencha as informaes complementares, conforme mostra a Figura 2.
A escolha do Tema livre. Como sugesto
escolha o tema Mac ou Office. Defina tambm o Skin clicando com o boto direito
na rea de trabalho do Maker.
Clique em OK para que o Maker crie o
arquivo .wfre. Este arquivo utilizado
para guardar as configuraes de conexo
do projeto.
Aps este ponto, o Maker far a importao do Tema definido e importao da API
de funes.
A rea principal do Maker composta
pelo Gerenciador de Objetos (Formulrios,
Fluxos e Relatrios), subrea para visualizao do projeto em desenvolvimento, subrea de ajuda (acesso
ao Frum, portal do suporte, entre outros), acesso aos plug-ins
e muitas outras funcionalidades. Observe a Figura 3.
A ttulo de demonstrao, o projeto criado ser simples e ter
apenas dois formulrios. Para cri-los, basta clicar com o boto
direito na aba Formulrios, no gerenciador de objetos, e seguir as
instrues do Assistente de Criao de formulrios. importante
observar que no dever selecionar a fonte de dados visto que
o projeto no possui tabelas no momento e estas sero criadas
automaticamente pelo Maker.
Organize seu formulrio conforme Figura 4. Neste formulrio
foram colocadas duas caixas de texto e um componente moldura.
planejamento
Observe a paleta de objetos na figura.

Todos os componentes e suas propriedades so acessveis atravs da orbital
de objetos.
Aps configurar, basta pressionar
CTRL + S para salvar as alteraes e
seguir o Assistente de Banco de Dados.
O Maker criar a tabela necessria para
persistncia do contato. Veja na Figura 5
o assistente de banco de dados, observe
que o Maker sugere o nome dos campos
bem como qual coluna ser o campo
chave.
Observe que embora no tenhamos
um campo para cdigo no formulrio,
o Maker sugere sua criao para que a
chave primria possa ser criada. Note
tambm que so definidos os nomes
que sero utilizados para os campos nas
tabelas (exemplo: AGE_CON_IDADE).
Alm disso, neste assistente possvel
definir informaes como o tipo de dados associado ao campo, se ele ou no
obrigatrio (em nosso exemplo, apenas
os campos cdigo e nome do contato
foram definidos como obrigatrios) e
o tamanho de caracteres aceito.
O desenvolvedor pode configurar
livremente as sugestes conforme necessidade. Aps uma breve visualizao,
efetuar alteraes se necessrio e clicar
em Executar para que o Maker crie a
tabela no banco de dados.
Feito o formulrio de contato, crie o
formulrio para armazenar os telefones
do contato. O formulrio de telefones
ter apenas um componente. Observe
a Figura 6.
Note que ao inserir o campo texto e
selecionar a opo Propriedades um
conjunto grande de definies sobre o
campo podem ser customizadas. Alguns exemplos so: nome do campo, se
somente leitura, se o campo ou no
visvel. Alm disso, podemos customizar o posicionamento do campo no
formulrio e definir respostas a eventos
que ocorram nele.
Ao final, salve o formulrio e siga as
instrues do Assistente de Banco de Dados
novamente. Para aqueles que gostam de
ter um maior controle sobre as definies
do banco de dados, possvel tambm
fazer com que a criao automtica de
tabelas seja desabilitada.
Figura 3. Tela principal do Maker
Figura 4. Formulrio Contato e seus campos
Figura 5. Assistente de banco de dados
Voltando para o formulrio de Contatos, acrescente o componente grade

e configure a propriedade Formulrio
informando o formulrio de telefones
criado anteriormente. Ao salvar, o Maker
sugerir criar a chave estrangeira na
tabela de telefones. O formulrio dever

estar conforme Figura 7.
Visualizando o formulrio criado

Antes de visualizar o formulrio no
Webrun, necessrio acrescent-lo no
menu do projeto. Esta configurao feita no formulrio

principal do projeto. Procure por Principal no gerenciador
de objetos e abra o formulrio para adicionar o formulrio
de Contatos no menu. A propriedade do componente Menu
a ser configurada denominada Estrutura do Menu. Para
adicionar o formulrio ao menu, clique com o boto direito
sobre o componente Menu e acesse a propriedade Estrutura
do Menu. Veja na Figura 8.
Na tela aberta, clique com o boto direito na opo Raiz,

selecione Novo submenu e preencha o nome do novo submenu.
Em seguida, arraste o formulrio Contatos e associe ao menu
recm criado.
Para visualizar o formulrio criado basta acessar no navegador o endereo http://localhost:8030/webrun e selecionar o
sistema desejado. Acesse o formulrio pelo Menu definido e
cadastre algumas informaes. Observe a Figura 9.
Figura 8. Definindo a estrutura do menu da aplicao
Figura 6. Formulrio Telefone com as propriedades do componente

Telefone
Figura 9. Tela de Contatos visualizada no Webrun atravs do browser
importante observar a interface amigvel da tela final.

Mais customizaes podem ser realizadas com o MasterSkin,
editor de CSS do Maker.
Figura 7. Formulrio Contatos criado
Criando o fluxo para validar idade

Nota: Menu Legado
importante lembrar de configurar a propriedade Menu Legado para No. Esta
propriedade s til para projetos criados na verso 2.7, desta forma a estrutura de menu
antiga ser mantida.
10
At aqui apresentamos como criar formulrios simples

contendo funcionalidades de cadastro e como o Maker facilita a vida do desenvolvedor gerando todo o cdigo fonte
necessrio ao projeto. Entretanto, a parte mais interessante
vem agora: possvel definir regras de negcio e deixar que a
planejamento
ferramenta gere o cdigo associado a elas. Estas regras esto

muitas vezes associadas a validaes presentes nos formulrios
da aplicao.
Note que esta possibilidade de criao automatizada de regras de negcio torna o Maker uma opo muito interessante
quando estamos em busca de uma ferramenta que nos permita
trabalhar com o ciclo de vida RAD (Rapid Application Development). Ele pressupe entregas rpidas de funcionalidades do
software ao cliente e, para isso, fundamentado no uso de
ferramentas CASE que permitam a gerao de aplicaes. O
sucesso deste ciclo de vida dependente da ferramenta de
gerao utilizada.
Para demonstrar um pouco o funcionamento do editor de
regras (fluxos) de negcios, tomaremos como base que um
contato s pode ser cadastrado caso o mesmo possua idade
maior ou igual a 10 anos. Na rea de trabalho do Maker, pressione F7 para abrir o editor de fluxos. Para compor a regras de
negcio, oferecem-se os seguintes objetos:
Processamento: principal item utilizado para montar as
expresses;
Subfluxo: para efetuar chamadas a outros fluxos;
Comentrio: para inserir um bloco de comentrio no fluxo;
Deciso: para validaes lgicas;
Fim: para finalizar o fluxo.
Figura 10. Expresso para validao da idade do contato
Para a validao ser necessrio criar uma varivel de entrada

denominada Idade. O teste da idade ser feito com o objeto
Deciso. Abra-o e localize a funo Maior ou Igual e defina os
valores, conforme Figura 10.
Observe que temos uma expresso com a funo Maior ou
Igual e como parmetros para a funo tem-se a varivel Idade
11
e uma constante 10 que ser a idade mnima permitida. Agora

utilize dois objetos Interao para informar o erro ou no ao
usurio. O fluxo final dever estar conforme Figura 11.
Observe no fluxo que basicamente tratamos o valor do parmetro idade e, a depender de seu valor, o software validar
positivamente o dado inserido ou apresentar uma mensagem
de erro para o usurio.
Figura 11. Fluxo para validao da idade
possvel observar no canto superior direito que existe uma

crtica realizada referente s boas prticas durante o desenvolvimento do fluxo, conforme a Figura 12. Essas boas prticas
avaliam questes como: objeto sem descrio, objeto isolado
sem um fluxo associado, dentre outras. Caso o fluxo definido
esteja ok, o Maker indicar que o fluxo est ok e que no h
necessidade de ajust-lo por ele no possuir inconsistncias.
Figura 13. Associando o fluxo no evento antes de inserir do formulrio

de contatos
Conhecemos nesse artigo a praticidade e ganho em produtividade proporcionado pelo Maker. possvel observar tambm
a abstrao de muitas etapas durante o desenvolvimento, visto
que a ideia do Maker manter o desenvolvedor focado nas
regras de negcio de sua aplicao trazendo ganhos reais no
prazo e facilitando a manuteno do projeto futuramente.
Links:
HotSite do Maker 3
http://maker3.softwell.com.br/
Figura 12. Fluxo com nota 0 devido falta de descrio em um dos objetos
Criado o fluxo que define a regra de negcio, o prximo passo

ser vincul-lo ao evento ou objeto do formulrio que precisa
se comportar de acordo com a regra definida.
Para isso, vincule o fluxo no evento Antes de Inserir do formulrio Contatos. Para chegar tela Definir Aes, clique com
o boto direito na rea do formulrio Contatos => Eventos =>
Antes de inserir e clique em .... Para o parmetro de entrada
do fluxo, informe que a origem ser do campo referente idade,
conforme Figura 13.
Com o formulrio salvo, basta pressionar CTRL + F5 para
recarregar a pgina e obter as alteraes feitas. Experimente
preencher valores maiores e menores que 10 na incluso de
um contato e observe as mensagens.
12
Frum
http://forum.softwell.com.br
Mais informaes sobre o editor de fluxos
http://suporte.softwell.com.br/maker/manual2_7/pt/maker_2/fluxos_e_acoes/editor_de_
fluxo_de_acoes.htm
Voc gostou deste artigo?

D seu voto em www.devmedia.com.br/esmag/feedback
Ajude-nos a manter a qualidade da revista!
planejamento
13
Medio de Software no CMMI e MPS.BR

Da arquitetura civil interao humano-computador
Fique por dentro:

Anderson Pinheiro Balbo
anderson.balbo@gmail.com
Possui graduao em Informtica com nfase

em Gesto de Negcios pela Faculdade de
Tecnologia da Zona Leste, especializao em
Engenharia de Software pelo Instituto de
Computao-UNICAMP e especializao em
Gesto de Projetos em TI pela Fundao Carlos
Alberto Vanzolini-USP. Atualmente supervisor de TI na Caixa Econmica Federal.
Wilson Vendramel
wilson.vendramel@fatec.sp.gov.br
Possui especializao em Engenharia de Software e mestrado em Cincia da Computao

pelo Instituto de Computao-UNICAMP, e
especializao em Melhoria de Processo de
Software pela Universidade Federal de Lavras.
Atuou como Especialista de Sistemas na IBM
Brasil.
Maria Beatriz Felgar de Toledo

beatriz@ic.unicamp.br
Possui graduao e mestrado em

Cincia da Computao pelo Instituto de Computao-UNICAMP e doutorado em Sistemas
Distribudos pela Universidade de Lancaster,
Inglaterra. Atualmente professora associada
na Universidade Estadual de Campinas. Tem
interesse nas reas de gesto de processos de
negcio, servios Web, Web semntica e arquiteturas orientadas a servios.
14
undado pelo Departamento de

Defesa dos Estados Unidos, o Instituto de Engenharia de Software
(SEI), da Universidade Carnegie Melon,
aliou-se a organizaes do governo e da
indstria para desenvolver, alm dos
modelos CMM, os mtodos de avaliao
e os produtos de suporte.
Posteriormente, outros modelos especficos de processo foram desenvolvidos,
com o objetivo de atender s reas de
recursos humanos, aquisio de software e engenharia de sistemas. O uso
simultneo desses modelos nas empresas causou confuso devido diferena
entre as metodologias de um modelo
para outro.
A partir da, surgiu o modelo integrado, para atender de forma nica a outras
reas, como a gesto de recursos humanos, alm de servir de guia prtico para a
melhoria de processos nas organizaes
e dos profissionais envolvidos.
Engenharia de Software Magazine - Medio de Software no CMMI e MPS.BR
Nesse artigo so tratados aspectos relevantes

acerca dos modelos MPS.BR e CMMI. Em termos
comparativos, o MPS.BR bastante parecido
com o CMMI, no somente por adotar processos semelhantes a este, mas tambm por ser
recomendado s empresas que desejam padronizar o seu processo de desenvolvimento e no
entanto no possuem recursos suficientes para
se adequar s normas do CMMI. Sero apresentados conceitos, modelos, estgios, nveis
de maturidade e capacitao, bem como suas
caractersticas e de que forma podem ser adotados nos processos de desenvolvimento.
O mtodo de avaliao oficial do SEI

para obteno de nvel de maturidade
no modelo integrado o SCAMPI (Mtodo Padro de Avaliao do CMMI
para Melhoria de Processos). O principal objetivo do SCAMPI avaliar
o atendimento s recomendaes do
CMMI e estabelecer um nvel oficial
de maturidade ou capacidade da organizao, alm do estabelecimento de
requisitos para quem exercer a funo
de lder da avaliao.
planejamento
CMMI, O Modelo de Maturidade de

Capacitao do SEI
A engenharia de sistemas recebe do modelo
integrado as recomendaes para a aquisio
adequada de sistemas, de modo que atenda
s necessidades do cliente; o CMMI prev os
passos necessrios para que os engenheiros
de sistema desenvolvam esse sistema de forma
organizada no ciclo de vida do projeto.
Com o intuito de medir a maturidade de produo de software, a engenharia de software Figura 1. Modelo de Maturidade de Capacitao do SEI
a atividade voltada ao desenvolvimento de software com boa qualidade, em prazos e custos
razoveis e previsveis. O CMMI fornece as recomendaes
pessoas chave, ou seja, profissionais convocados em situaes
para o desenvolvimento e a aquisio adequada do software
de emergncia para solucionar dificuldades.
de outros fornecedores, aliando o produto ao sistema em
A dependncia da organizao da competncia das pessoas
desenvolvimento.
pode ser considerado um problema que, embora no impea
O Desenvolvimento Integrado do Produto e do Processo
o perfeito desenvolvimento do produto com qualidade, torna
conta com a participao dos stakeholders na composio do
a organizao vulnervel. Tal fato se deve rotatividade dos
processo de software e do produto resultante, para anlise
profissionais na organizao; caso haja troca de pessoal, a
macro do sistema, estudando a melhor maneira de atenderem
qualidade na produo de software pode diminuir.
aos requisitos do cliente.
Alm dos problemas de ordem gerencial predominarem
Devido s diferentes estratgias aplicadas pelas empresas no
sobre os de ordem tcnica, no existem, portanto, mecanismos
desenvolvimento de software, o CMM elaborou a abordagem
organizacionais para garantir que os procedimentos sejam
de desenvolvimento por estgios de maturidade, atualmente
adotados de forma consistente.
utilizada pelo CMMI. Contudo, a principal diferena deste
para aquele que o CMMI suporta a abordagem contnua
Nvel Gerenciado
de desenvolvimento, integrando apenas as reas de processo
Nesse nvel, o projeto passa a contar com procedimentos
utilizadas na empresa.
formais e requisitos gerenciados. Esse nvel possui as reas
reas de processos podem ser entendidas como um conjunto
de processo descritas na Tabela 1.
de objetivos e prticas relacionadas em uma rea que, quando
executadas coletivamente, satisfaz um grupo de metas imSigla Descrio
portantes, responsveis pelas melhorias significativas nessa
RM
Requirements Management (Gerenciamento de Requisitos)
rea. As reas de processo (Process Area - PA) compem,
PP
Project Planning (Planejamento do Projeto)
alm de prticas genricas e especficas, os objetivos genriPMC Project Monitoring and Control (Monitoramento e Controle do Projeto)
cos e especficos definidos. Portanto, cada rea de processo
SAM Supplier Agreement Management (Gerenciamento de Acordos com Fornecedores)
abrange atividades especficas, integradas ou no, conforme
a representao do modelo adotado pela empresa em questo:
MA
Measurement and Analysis (Medio e Anlise)
por estgio ou contnua.
PPQA Process and Product Quality Assurance (Garantia da Qualidade do Processo e do Produto)
Representao por Estgio

A representao por estgios prope a melhoria de capacidade da organizao atravs da evoluo dos nveis de maturidade. Cada nvel de maturidade abrange um conjunto de reas
de processo que devem ser contemplados para que o nvel
pretendido seja atingido. Por exemplo, para que obter o nvel 3
de maturidade, todas as PA relacionadas ao nvel 1, nvel 2 e
nvel 3 devem ser contempladas. Os cinco nveis de maturidade
de capacitao do SEI so os apresentados na Figura 1.
Nvel Inicial
No nvel inicial de Maturidade, os processos so caticos e
no h um gerenciamento eficaz do projeto. H problemas com
o cronograma e custo, alm da falta de padres no cumprimento de requisitos, e a organizao dependem frequentemente de
CM
Configuration Management (Gerenciamento de Configuraes)
Tabela 1. reas de Processo do Nvel Gerenciado
No nvel 2, equivalente ao nvel repetvel do CMM, no existe

um modelo de processo formal, e a organizao capaz de
repetir com xito projetos do mesmo tipo. Para tanto, necessria a motivao da equipe por parte dos gerentes, a fim
de aumentar a probabilidade de sucesso no desenvolvimento
do produto.
Os mtodos de gerenciamento de software so documentados, e h o acompanhamento e a orientao no projeto. Alm
disso, as no conformidades nos requisitos so identificadas
com certa antecedncia, possibilitando a implantao de aes
corretivas, como a alocao de mais pessoas no projeto, por
exemplo.
15
Nvel Definido
No nvel definido, os processos so bem caracterizados e
compreendidos. Isso se deve ao fato de existir uma preocupao maior com a padronizao do processo em toda a organizao, e a customizao deste para cada projeto. A existncia
de um processo definido possibilita maior consistncia nos
produtos desenvolvidos pela organizao. Processos padronizados geram produtos facilmente identificados, alm de
apresentarem caractersticas em comum de um produto para
outro e contriburem significativamente para a melhoria da
produtividade e qualidade.
A organizao nesse nvel tambm capaz de gerar uma
infraestrutura de processos que permite a adaptao a diversos
tipos de mudanas. Observe na Tabela 2 as reas de processo
desse nvel.
Sigla
Descrio
OPP
Organizational Process Performance (Desempenho do Processo Organizacional)
QPM
Quantitative Project Management (Gerncia Quantitativa do Projeto)
Tabela 3. reas de Processo do Nvel Quantitativamente Gerenciado
Nvel em Otimizao
Nesse nvel, a organizao est empenhada na melhoria contnua dos processos, planejando e gerenciando suas mudanas
de forma a no causar impacto na qualidade do produto final. A
melhoria nesse caso parte essencial dos procedimentos adotados
na organizao, e as inovaes esto previstas juntamente com a
implantao de novas tecnologias. Os efeitos dessa implantao
so medidos e avaliaes constantes so realizadas.
O planejamento das melhorias essencial para que a organizao mantenha o nvel otimizado do CMMI, e as tarefas
associadas a essas melhorias sejam desempenhadas por todos
os envolvidos no projeto, e no apenas pelos profissionais de
alto nvel hierrquico. Observe na Tabela 4 as reas de processo desse nvel.
Sigla
Descrio
RD
Requirements Development (Desenvolvimento de Requisitos)
TS
Technical Solution (Solues Tcnicas)
PI
Product Integration (Integrao de Produtos)
VER
Verification (Verificao)
VAL
Validation (Validao)
OID
Organizational Innovation and Deployment (Inovao e Implantao na Organizao)
OPF
Organizational Process Focus (Foco no Processo Organizacional)
CAR
Causal Analysis and Resolution (Anlise e Resoluo de Causas)
OPD
Organizational Process Definition (Definio do Processo Organizacional)
OT
Organizational Training (Treinamento Organizacional)
IPM
Integrated Project Management (Gerenciamento Integrado do Projeto)
Representao Contnua
RM
Risk Management (Gerenciamento de Riscos)
DAR
Decision Analysis and Resolution (Anlises de Decises e Resolues)
A representao contnua composta por seis nveis de capacitao, onde as reas de processo so reunidas em grupos
anlogos. Por exemplo, somente pertencero ao grupo de gerncia de projeto as reas de processo que tratam de projeto, da
mesma forma ocorre com gerncia de processos, engenharia e
suporte. Observe na Tabela 5 como esto organizadas as reas
de processo nesta representao.
O grupo de gerncia de processos contm atividades para
definir, planejar, implantar, implementar, monitorar, controlar,
avaliar, medir e melhorar os processos da organizao. As
PA referentes gerncia de projeto suportam as atividades
de planejamento, monitorao e controle do projeto. O grupo
de engenharia trata de atividades pertinentes a engenharias
como a de sistema e a de software. O suporte contm reas de
processo para assistncia ao desenvolvimento e manuteno
de produtos.
Assim como na representao por estgio, a representao
contnua classificada em nveis, totalizando seis nesse caso.
A principal diferena entre as duas que a ltima baseia-se
na capacidade dos processos, enquanto a representao por
estgio mede a maturidade da organizao como um todo.
Tabela 2. reas de Processo do Nvel Definido
Apesar de o nvel definido ser constitudo por onze reas

de processo, para ele necessrio contemplar tambm as sete
reas de processo aplicadas ao nvel gerenciado.
Nvel Quantitativamente Gerenciado

A organizao que alcana o nvel quantitativamente
gerenciado de processo tem um programa formal de coleta
de dados quantitativos, onde as mtricas de processo e
produto so referncias para as atividades de melhoria de
processo.
Uma base de dados histrica mantida com os dados das
medies de qualidade, e com isso decises futuras podem
ser tomadas baseadas em informaes consistentes de projetos anteriores. A principal diferena entre o nvel 3 e 4
que o primeiro se restringe a fornecer escalas qualitativas
do processo, enquanto o nvel 4 permite o controle quantitativo atravs de mtodos estatsticos e outras tcnicas
quantitativas.
O domnio quantitativo dos processos fundamental para
prever o seu desempenho, e com isso, atingir o estado de
melhoria contnua. Observe na Tabela 3 as reas de processo
desse nvel.
16
Sigla
Descrio
Tabela 4. reas de Processo do Nvel em Otimizao
Nvel Incompleto
Este o nvel zero, momento em que a empresa no utiliza qualquer processo de melhoria. comum empresas que
iniciam as suas atividades pertencerem a esse nvel, at o
momento em que utilizam as recomendaes do CMMI.
planejamento
Entretanto, preciso atentar ao fato de que mesmo a utilizao

de algum processo no significa a passagem para o nvel realizado, pois antes de tudo os objetivos especficos dessa rea
de processo devem ser satisfeitos.
Categoria
rea de processo associada

Process Focus (Foco no Processo)
Gerncia
De
Processos
Process Definition (Definio de Processos)

Organizational Training (Treinamento)
Organizational Process Performance (Desempenho de Processo)
Organizational Innovation and Deployment (Inovao e Implantao)
Project Planning (Planejamento de Projeto)
Project Monitoring and Control (Controle e Monitoramento de Projeto)
Supplier Agreement Management (Gerncia de Acordos com Fornecedores)
Gerncia
De
Projeto
Integrated Project Management (Gerncia de Projeto Integrada)

Risk Management (Gerncia de Riscos)
Integrated Teaming (Integrao da Equipe)
Integrated Supplier (Integrao de Fornecedores)
Quantitative Project Management (Integrao de Equipe)
Requirements Management (Gerncia de Requisitos)
Requirements Development (Desenvolvimento de Requisitos)
Engenharia
Technical Solution (Soluo Tcnica)

Product Integration (Integrao de Produto)
Verification (Verificao)
Validation (Validao)
Configuration Management (Gerncia de Configurao)
Process and Product Quality Assurance (Garantia de Qualidade de Produto e
Processo)
Suporte
Measurement and Analysis (Medio e Anlise)

Decision Analysis and Resolution (Anlises de Decises e Resolues)
Organization Environment for Integration (Ambiente Organizacional para
Integrao)
Causal Analysis and Resolution (Resoluo e Anlise de Causas)
Tabela 5. reas de Processo na representao contnua
Nvel Realizado
A organizao que pertence a esse nvel no tem apenas uma
rea de processo atendida, mas tambm todos os objetivos
especficos dessa rea satisfeitos. A realizao de todas as
atividades pertinentes a essa rea pode ser comprovada pelo
correto funcionamento do processo, questionando se ele efetua
a entrada, o processamento e a sada (por sada entende-se
a concluso do produto ou servio pretendido) conforme as
recomendaes do CMMI.
Nvel Gerenciado
Nesse nvel, alm do correto funcionamento de uma rea
de processo, verificado se essa rea planejada e executada
atravs de polticas determinadas. Os profissionais envolvidos
so habilitados e a organizao possui os recursos necessrios
para monitorar, controlar e revisar a rea de processo e seu
produto gerado. Alm disso, aes corretivas so tomadas,
requisitos e objetivos so estabelecidos, e os produtos so
revisados contra os requisitos descritos.
Nvel Definido
O processo, para pertencer ao nvel definido, deve atender s
recomendaes do nvel realizado e gerenciado. Os padres
passam a vigorar com maior frequncia nesse nvel, fazendo
parte da rotina da organizao. No nvel definido, os processos
so determinados de maneira mais rigorosa do que no nvel
gerenciado, pois neste ainda pode haver distino em processos utilizados entre dois ou mais projetos desenvolvidos.
Os processos tratam da entrada, processamento e sada; entretanto, no processamento deve haver as medidas e verificaes
recomendadas para a sua execuo.
Nvel Gerenciado Quantitativamente

No nvel gerenciado quantitativamente os processos so
administrados atravs de tcnicas quantitativas, como as estatsticas. Isso significa que os processos envolvidos na obteno
do produto ou servio so analisados, os dados referentes so
extrados e utilizados como base para decises futuras. Tambm podem compor o histrico do projeto, de modo a evitar
que falhas cometidas anteriormente se repitam.
A diferena fundamental entre o nvel definido e o nvel
gerenciado quantitativamente que neste os processos so
previstos com maior rigor, e estimativas so realizadas antes
mesmo que ele seja executado.
Nvel Otimizado
O nvel otimizado engloba as reas de processo que alcanaram o nvel quatro e os anteriores da representao contnua.
Assim como no nvel cinco da representao por estgio, essa
representao pressupe que o nvel otimizado cumpre todos
os requisitos de qualidade conforme o CMMI.
O processo otimizado deve cumprir com os objetivos de
negcio da organizao e atender s inovaes tecnolgicas
que influenciam na qualidade da rea de processo, causam
impacto e geram custos para a organizao. Embora o nvel
gerenciado quantitativamente seja previsvel, as suas variaes de desempenho podem gerar falhas durante o processo,
e a funo do nvel otimizado implementar mudanas que
estabilizem essas variaes.
rea de Processo de Medio e Anlise

O propsito da rea de processo de medio e anlise no
CMMI dar suporte deciso e ao gerenciamento de informaes atravs do desenvolvimento da capacidade de medies.
17
As mtricas de processo so essenciais sua melhoria e a

medio tem um papel essencial na melhoria de processos
de pessoal.
Para a anlise dessa PA, considera-se a sua aplicao a partir
do nvel gerenciado de maturidade da representao por estgio, e o seu papel como rea de processo de medida e anlise
no grupo de suporte da representao contnua.
Medio e Anlise no Nvel Gerenciado

No nvel gerenciado, existem fases de controle de custo e cronograma nos produtos intermedirios, e a cada trmino de fase
so obtidos dados para anlise e tomada de aes corretivas
no caso de falhas que prejudiquem o resultado final.
Conforme a Figura 2, verifica-se atravs do sinal de interrogao que h dificuldades em localizar os pontos internos do
processo, o que no impede que o prazo (representado pelo
relgio cinza) e o custo sejam determinados ao fim de cada
etapa do processo.
rea de Processo
Planejamento do Projeto
Monitoramento e Controle do Projeto
Gerenciamento de Configurao
Desenvolvimento de Requisitos
Gerenciamento de Requisitos
Definio do Processo Organizacional
Gerenciamento Quantitativo do Projeto
Relacionamento com a rea de Processo de Medio

e Anlise
Estimativa de atributos do projeto e outras necessidades
de informaes de planejamento.
Monitoramento das necessidades de informaes de
planejamento.
Gerenciamento de produtos de trabalho de medies.
Atendimento dos requisitos de clientes e necessidades
de informaes relacionadas.
Manuteno da rastreabilidade dos requisitos e
necessidades de informaes relacionadas.
Estabelecimento do repositrio de medies da
organizao.
Entendimento das variaes e uso apropriado de
tcnicas de anlises estatsticas.
Tabela 6. Relacionamento entre Medio e Anlise e as outras PAs
As atividades exercidas pela medio e anlise devem atender

de forma adequada a uma quantidade determinada de metas
especficas e genricas para que o processo em questo seja
realizado com sucesso. Ao todo so duas metas especficas,
cada uma composta por quatro prticas especficas, e uma
meta genrica, composta por dez prticas genricas.
As prticas especficas podem ser consideradas como atividades necessrias para atingir um objetivo especfico, e as
prticas genricas como atividades que asseguram a efetividade e repetio dos processos associados s PAs.
Alinhar as Atividades de Medio e Anlise

Figura 2. Entrada (E) e sada (S) do processo no nvel gerenciado
Nesse nvel os compromissos so, portanto, compreendidos e

gerenciados. [3] estabelece os seguintes requisitos para a rea
de medio e anlise:
Alinhar os objetivos de medio e anlise com as informaes
que se deseja obter e as necessidades identificadas;
Especificar o mtodo para coleta de dados e medidas,
as tcnicas de anlise e os mecanismos utilizados para
comunicao;
Gerenciar os dados obtidos, implementando a coleta, armazenagem, anlise e relatrio dos dados obtidos;
Adaptar os dados para dar suporte s decises e possibilitar
a tomada de aes corretivas.
Alm dos objetivos especficos, a medio e anlise tambm
tratam de metas genricas e especficas. As metas genricas
possuem caractersticas comuns a serem alcanadas, entre
algumas reas de processo. As metas especficas referem-se a
caractersticas nicas dessa rea e descrevem o que deve ser
implementado para o seu desempenho correto.
O processo de medio e anlise mantm relacionamento
com sete reas de processo (em alguns casos recebe a forma
abreviada PA - Process Area) de diferentes nveis de maturidade (ver Tabela 6).
18
Essa meta especfica tem por objetivo especificar as anlises fundamentais que sero feitas, antes de colocar em
prtica os detalhes da especificao de medies, coleta e
armazenamento de dados.
A prtica especfica Estabelecer Objetivos de Medies
documenta o propsito das medies e anlises, e especifica
as aes a serem tomadas suportadas pelos dados obtidos.
Esse propsito pode ser a necessidade de gerenciamento,
por exemplo.
O refinamento dos objetivos de medies em medidas
precisas e quantificveis realizado pela prtica especfica
Especificar Medidas. Essas medidas podem ser bsicas,
quando obtidas por medio direta, ou derivadas, se provm
de outros dados, podendo combinar duas ou mais medidas
bsicas.
Um exemplo de medida bsica a quantidade de horas
homem (tambm chamado de esforo), ou a quantidade de
pginas codificadas; exemplos de medidas derivadas so os
ndices de desempenho do cronograma, ou o resultado da diviso ou outra operao matemtica entre duas medidas.
A prtica especfica Especificar Procedimentos de Coleta
e Armazenamento de Dados responsvel por garantir que
os dados corretos so coletados de modo adequado, possibilitando o seu uso futuro, alm de contribuir para esclarecer
as necessidades de informaes e objetivos das medies.
Definir como ser feita a anlise e comunicao dos dados
planejamento
tarefa da prtica especfica Especificar os Procedimentos de

Anlises, pois esta possibilita que os dados sejam coletados,
e as anlises apropriadas sejam executadas e comunicadas
a fim de atender s necessidades e objetivos de informaes
referentes a ela.
Fornecer Resultados de Medies

A meta especfica Fornecer Resultados de Medies permite
que os dados estejam disponveis para a tomada de deciso.
As evidncias objetivas geradas pelas medies podem
contribuir com atividades importantes da organizao,
como monitorar o desempenho e cumprir obrigaes
contratuais.
A coleta dos dados de medio bsica e derivada que devem
ser verificadas quanto a sua integridade realizada pela
prtica especfica Coletar Dados de Medies. Esses dados,
uma vez coletados, so analisados seguindo as recomendaes da prtica especfica - Analisar os Dados das Medies.
Nesse ponto, h um planejamento do que ser analisado, e
os resultados so revisados com os stakeholders envolvidos
nessa atividade especfica, tambm denominados stakeholders relevantes.
Aps a coleta e anlise dos dados, recomendvel armazenar as informaes geradas pelas medies, de forma
que possam ser usadas para anlises futuras, e definir o
diagnstico dos resultados obtidos no processo; esse papel
desempenhado pela prtica especfica Armazenar os Dados
e Resultados.
Com os resultados do processo de medio e anlises em
mos, o prximo passo comunic-los aos stakeholders relevantes, para assegurar que as aes de correo de falhas
sejam tomadas a fim de evitar repeties de insucessos no
projeto; a essa atividade est associada a prtica especfica
Comunicar Resultados.
caso todas as prticas genricas descritas na Tabela 7 sejam

atendidas com xito.
Medio e Anlise na Categoria de Suporte

A PA de medio e anlise possui todas as caractersticas
apresentadas no nvel gerenciado da representao por estgio. Contudo, pode-se ter uma meta genrica a mais para
a representao contnua dessa rea de processo. Essa a
meta genrica Atingir Objetivos Especficos, responsvel
por suportar a realizao de objetivos especficos de uma
determinada PA nas atividades de entrada, processamento,
e sada dos produtos finais.
A prtica especfica referenciada por essa meta denominada Desempenhar as Prticas Base, e seu objetivo gerar
os produtos de trabalho requeridos e entregar os servios
relacionados ao desenvolvimento do produto.
Medio e Anlise no MPS.BR

O programa para Melhoria de Processo do Software Brasileiro foi criado por pesquisadores brasileiros, com foco na melhoria dos processos que envolvem o desenvolvimento de software em organizaes brasileiras. O MPS.BR coordenado pela
Associao para Promoo da Excelncia do Software Brasileiro (SOFTEX) e apoiado pelo Ministrio da Cincia e Tecnologia, pela Financiadora de Estudos e Projetos, pelo Banco
Interamericano de Desenvolvimento, e por Universidades.
Institucionalizar um Processo Gerenciado

Diferente das metas anteriores, a meta Institucionalizar
um Processo Gerenciado genrica, pois suas atividades
tambm podem estar associadas a outras reas de processo.
[3] classifica as dez prticas que compem essa meta como
genricas, e as agrupa conforme a funo de cada uma aplicada no processo: compromisso, habilitao, implementao
e verificao da implementao.
Os compromissos esto relacionados criao de polticas e
garantia de patrocnios. As habilitaes asseguram que tanto
o projeto quanto a organizao tenham a disposio os recursos de que precisam. A implementao est relacionada ao
gerenciamento do desempenho do processo, gerenciamento
da integridade dos seus produtos de trabalho, e envolvimento
dos stakeholders relevantes. A verificao da implementao
realizada pela gerncia de mais alto nvel e avalia a conformidade de padres, procedimentos e processos.
As prticas genricas so utilizadas tanto na representao
por estgio como na contnua. A sua importncia se deve,
sobretudo, possibilidade de melhoria do nvel gerenciado,
19
Caractersticas
Comuns
Compromisso
Habilitao
Implementao
Verificao da
Implementao
Prticas Genricas
Descrio
Estabelecer uma Poltica Organizacional
Documenta e coloca em prtica uma poltica organizacional para o planejamento e execuo do processo.
Planejar o Processo
Planeja a execuo do processo.
Fornecer Recursos
Fornece recursos necessrios para executar o processo de medies e anlises, desenvolver produtos de trabalho e servios
associados.
Atribuir Responsabilidades
Atribui responsabilidades para executar o processo, desenvolver produtos de trabalho e servios do processo de medies e anlises.
Treinar as Pessoas
Providencia o treinamento necessrio para as atividades associadas medio e anlise.
Gerenciar Configuraes
Gerencia configuraes e verses de produtos de trabalho (como ferramentas de anlises de dados).
Identificar e Envolver os Stakeholders Relevantes
Identifica os stakeholders para compromissos, aprovaes, comunicao e acompanhamento.
Monitorar e Controlar o Processo
Acompanha o planejamento do processo e adota aes corretivas.
Avaliar Objetivamente a Aderncia
Analisa a aderncia contra os procedimentos e padres, e trata as no conformidades.
Revisar o Status com o Nvel Mais Alto de Gerncia Revisa a situao atual e os resultados da medio e anlise com os nveis gerenciais superiores, e adota aes corretivas.
Tabela 7. Prticas genricas do Nvel Repetvel
As suas recomendaes so adequadas s micro, pequenas

e mdias empresas de software brasileiras, interessadas
na melhoria de processos, mas que dispem de poucos
recursos para a adaptao s normas internacionais, como
o CMMI.
O Guia Geral do MPS.BR descreve de forma detalhada o Modelo de Referncia (MR-MPS), fornece uma viso geral sobre
os demais guias e as definies comuns para o entendimento
dos componentes desse modelo, de acordo com [4]. O Guia de
Aquisio do MPS.BR fornece as recomendaes para compra
de software e servios aplicveis ao seu desenvolvimento.
O Guia de Avaliao detalha o processo e o Mtodo de Avaliao do programa, e esto em conformidade com a ISO/IEC
15504-2:2003.
O programa ainda conta com as Instituies Implementadoras e Avaliadoras para assegurar que o processo seja
corretamente adaptado e verificado quanto ao atendimento s
recomendaes de qualidade. Cabe ao Frum de Credenciamento e Controle (composto por representantes da Indstria,
Academia e Governo) garantir que essas instituies sejam
adequadamente credenciadas e em acordo com os limites ticos
e de qualidade necessrios, alm de monitorar os resultados
obtidos pelo programa.
A Equipe Tcnica do Modelo responsvel por definir e aprimorar o MR-MPS, o Mtodo de Avalio (MA-MPS), e demais
Guias especficos, alm de aplicar provas, cursos, workshops
e treinamentos anuais do programa.
20
Embora o foco do MPS.BR seja as empresas brasileiras, ele

utiliza bases de trs normas internacionais: CMMI, ISO 15504
e ISO 12207 (ver Figura 3).
Figura 3. Construo do MPS.BR
O Modelo de Referncia composto por sete nveis de maturidade, que estabelecem as condies para a evoluo dos
processos, iniciando pelo tipo A (Em Otimizao) at o tipo G
(Parcialmente Gerenciado), evoluindo medida que itens do
processo determinados pelo MPS.BR so atendidos.
Cada processo do nvel de maturidade deve atender a um
conjunto de atributos exigveis para o seu refinamento e determinao da sua capacidade, e estes atributos so descritos
pelo Guia Geral do MPS.BR (ver Tabela 8).
Com exceo dos nveis de maturidade F (Gerenciado) e
G (Parcialmente Gerenciado), todos os demais requerem os atributos de processo 3.1 e 3.2. O atributo 3.1 requer um processo
planejamento
21
definido e padronizado, assim como o atributo 3.2 requer que

os processos estejam implementados.
gerncia de configurao e aquisio, a adequao do processo de medio. A finalidade desse processo, caracterizado
como de apoio, a de orientar a coleta e anlise dos dados
Processo de Medio no Nvel Gerenciado
referentes aos produtos e processos envolvidos no projeto,
A organizao que deseja obter o nvel F de maturidade,
incluindo o prprio projeto, que daro suporte tomada
correspondente ao nvel gerenciado, deve conter, alm da
de decises.
Os atributos de processo associados
medio so 1.1, 2.1 e 2.2. No
Atributos de Processo
Nvel
Sigla
Processos
primeiro,
o processo executado e
1.1
2.1
2.2
3.1
3.2
verificado a extenso com a qual
IIO
Implantao de Inovaes na organizao
o processo atinge o seu propsiA

ACR
Anlise de Causas e Resoluo
to. No atributo 2.1 o processo

DEP
Desempenho do Processo Organizacional
gerenciado, com poltica organiB

zacional estabelecida e mantida,
GQP
Gerncia Quantitativa do Projeto
execuo do processo planejada e

ADR
Anlise de Deciso e Resoluo
C
monitorada, e os recursos para sua
GRI
Gerncia de Riscos
execuo so identificados e disDRE

Desenvolvimento de Requisitos
ponibilizados. O Guia Geral tamSTE

Soluo Tcnica
bm determina para o atributo 2.1

que haja competncia dos execuITP
Integrao do Produto
tores do processo, alm do gerenD

ISP
Instalao do Produto
ciamento de comunicao entre

LIP
Liberao do Produto
as partes envolvidas no projeto, e

VER
Verificao
a reviso do processo com o nvel

VAL
Validao
hierrquico adequado de gerncia

TRE
Treinamento
que possibilite o tratamento de

problemas.
AMP Avaliao e Melhoria do Processo Organizacional
E
Para o atributo 2.2, os produtos
DFP
Definio do Processo Organizacional
de trabalho do processo tambm

APG
Adaptao do Processo para Gerncia de Projeto
so gerenciados. O resultado espeMED Medio
rado corresponde documentao,

GCO
Gerncia de Configurao
reviso e controle dentro da gernF

AQU
cia de configurao. Os seguintes
Aquisio
resu ltados so espec f icos do

GQA
Garantia da Qualidade
processo de medio:
GRE
Gerncia de Requisitos
G
As necessidades de informao e
GPR
Gerncia de Projeto
objetivos da organizao estabeleTabela 8. Nveis de maturidade do MR-MPS

cem as medies requeridas;
As medies pertinentes ao proN
Macroatividade
cesso so documentadas, prioriza1
Selecionar Instituio Avaliadora (IA)
das, revisadas e atualizadas;
2
Estabelecer contrato (entre o patrocinador da avaliao na unidade organizacional avaliada e a IA)
As atividades de coleta e armazenamento so definidas, envolvendo
3
Contactar a SOFTEX
mtodos e ferramentas;
4
Estabelecer Contrato (entre o patrocinador da avaliao na unidade organizacional avaliada e a SOFTEX)
As atividades de anlise so
5
Planejar avaliao
definidas, envolvendo mtodos e
6
Preparar a avaliao
ferramentas;
7
Conduzir avaliao inicial
So realizadas coletas e anlises
dos dados requeridos;
8
Completar preparao para a avaliao
realizado o armazenamento
9
Conduzir avaliao
dos dados e dos resultados;
10 Avaliar a execuo do processo de avaliao
As informaes geradas daro
11 Relatar resultados
suporte s decises e suportaro a
12 Registrar resultados
comunicao aos interessados.
Tabela 9. Macroatividades do MA-MPS
22
planejamento
Processo de Avaliao
Links:
O processo de avaliao do MPS.BR, em conformidade com

a Norma ISO/IEC 15504-2:2003, tem a finalidade de verificar
a maturidade caracterizada pelos processos executados na
organizao. Ao solicitar uma Instituio Avaliadora (IA) autorizada pela SOFTEX, estabelecido o contrato, e esta passa a
ter cincia do interesse da organizao, apresentando a equipe
que representa a IA.
Para o nvel Gerenciado, no qual consta o processo de Medio, essa equipe formada por um avaliador lder, um ou mais
avaliadores adjuntos e um ou mais representantes da unidade
organizacional, contanto que o somatrio dos integrantes no
seja inferior a quatro ou superior a cinco pessoas. A avaliao
pela qual passa a organizao contm os procedimentos citados
na Tabela 9, referentes s macroatividades desempenhadas
para obteno do grau de maturidade.
Em termos comparativos, o MPS.BR bastante parecido
com o CMMI, no somente por adotar processos semelhantes
a este, mas tambm por ser recomendado s empresas que
desejam padronizar o seu processo de desenvolvimento e no
entanto no possuem recursos suficientes para se adequar
s normas do CMMI.
[1] CORTS, M.L.; CHIOSSI, T.C.S. Modelos de Qualidade de Software: adendo

ao captulo 5. So Paulo: UNICAMP - Universidade de Campinas, 2005.

[2] CMU/SEI-2002-TR-028, ESC-TR-2002-028. Capability Maturity Model

Integration (CMMISM), Verso 1.1, CMMISM for Software Engineering (CMMISW, V1.1), Continuous Representation. Pittsburg, PA: Software Engineering
Institute, Carnegie Mellon University, 2002.
http://www.sei.cmu.edu/publications/ documents/02.reports/02tr028.html
[3] CMU/SEI-2002-TR-029, ESC-TR-2002-029. Capability Maturity Model Integration (CMMISM), Verso 1.1, CMMISM for Software Engineering (CMMI-SW,
V1.1), Staged Representation. Pittsburg, PA: Software Engineering Institute,
Carnegie Mellon University, 2002.
http://www.sei.cmu.edu/publications/documents/ 02.reports/02tr028.html
[4] KOSCIANSKI, A.; SOARES, M.S. Qualidade de software: aprenda as metodologias e tcnicas mais modernas para o desenvolvimento de software. 2.
ed. So Paulo: Novatec Editora, 2007.
[5] PIMENTEL, F.F. Uma Perspectiva de Mapeamento do CMMI ao MPS.Br.
Recife: Universidade Federal de Pernambuco, 2006.
http://www.cin.ufpe.br/~tg/ 2006-1/ffp.pdf
[6] ROCHA, A.R.C.; MALDONADO, J.C.; WEBER, K.C. Qualidade de Software:
Teoria e Prtica. So Paulo: Pearson Education do Brasil/Makron Books
Ltda, 2001.
[7] SOFTEX. MPS.BR - Melhoria de Processo do Software Brasileiro: Guia
Geral. Verso 1.1, 2006a.
http://www.softex.br/portal/mpsbr/_guias/default. asp
23
Use Case Point: Estimativas de Projeto

Parte 2
Fique por dentro:
Anderson Pinheiro Balbo
anderson.balbo@gmail.com
Possui graduao em Informtica com nfase

em Gesto de Negcios pela Faculdade de
Tecnologia da Zona Leste, especializao em
Engenharia de Software pelo Instituto de
Computao-UNICAMP e especializao em
Gesto de Projetos em TI pela Fundao Carlos
Alberto Vanzolini-USP. Atualmente supervisor de TI na Caixa Econmica Federal.
Wilson Vendramel
wilson.vendramel@fatec.sp.gov.br
Possui especializao em Engenharia de Software e mestrado em Cincia da Computao

pelo Instituto de Computao-UNICAMP, e
especializao em Melhoria de Processo de
Software pela Universidade Federal de Lavras.
Atuou como Especialista de Sistemas na IBM
Brasil.
Maria Beatriz Felgar de Toledo

beatriz@ic.unicamp.br
Possui graduao e mestrado em

Cincia da Computao pelo Instituto de Computao-UNICAMP e doutorado em Sistemas
Distribudos pela Universidade de Lancaster,
Inglaterra. Atualmente professora associada
na Universidade Estadual de Campinas. Tem
interesse nas reas de gesto de processos de
negcio, servios Web, Web semntica e arquiteturas orientadas a servios.
24
Este artigo faz parte de

um curso
tcnica de pontos por caso de

uso (UCP) surgiu como uma
adaptao para os pontos de
funo. Contudo, no houve grande
repercusso do mtodo nessa poca.
As empresas que utilizam os casos de
uso como forma de traduzir os requisitos
do cliente conseguem definir as aes
que o sistema deve realizar no incio
do projeto, assim como no decorrer do
desenvolvimento do sistema. O UCP permite que as estimativas sejam realizadas
durante o levantamento de requisitos,
e nas fases de anlise e implementao
do projeto.
Estimativas geradas no incio do projeto permitem ao gestor o levantamento
de dados imediatos para calcular o custo
do produto. O CoCoMo dependente
Engenharia de Software Magazine - Use Case Point: Estimativas de Projeto Parte 2
Estimativas de projeto so um grande desafio

para gerentes de projetos de software, pois
afetam a anlise de viabilidade, elaborao de
propostas, o planejamento e acompanhamento
dos projetos. Esse artigo mostra um processo de
estimativas de projetos de software, utilizando
a tcnica de Pontos por Caso de Uso, que pode
facilitar a estimativa do tamanho funcional do
projeto.
da tecnologia aplicada, pois gera as

mtricas a partir de linhas de cdigo.
A Anlise de Pontos de Funo permite a
medio independente da linguagem de
programao utilizada, contudo deve ter
as funcionalidades do sistema definidas
para que os clculos sejam implementados. O UCP, por outro lado, contabiliza
as realizaes dos componentes no diagrama de caso de uso.
Outro ponto importante a ser esclarecido que os casos de uso so de simples
entendimento pelo usurio, tornando,
portanto, as suas mtricas facilmente
evidenciadas e justificadas. Os clientes
e os usurios finais tm interesse nesse
planejamento
tipo de modelagem, pois ela representa

toda a funcionalidade do sistema e descreve como ele ser usado; sua participao
durante a modelagem fundamental,
uma vez que um analista de sistema ser
um agente que transcrever aquilo que
entender sobre a realidade exposta pelos
clientes/usurios e suas necessidades, em
especificaes tcnicas que devem retratar
tal realidade.
Dessa forma, as estimativas tambm
podero ser entendidas pelo cliente, que
estar capacitado a negociar com o seu
fornecedor o custo em razo da complexidade do produto.
Situaes em que h modificaes na
especificao so previstas para essa
medio, pois os requisitos, desde que
previamente acordados entre fornecedor
e cliente, so passveis de adaptao. Figura 1. Exemplo de modelagem do contexto de um sistema
Existem quatro razes principais no
projeto que levam os requisitos a serem
Composto por nomes e contedos grficos, o diagrama de
readaptados:
caso de uso foi criado por Ivar Jacobson, ao desenvolver um
Mudanas funcionais nos requisitos que no foram especisistema para a Ericsson, e sua abstrao est em obter os
ficadas nos casos de uso: as necessidades do cliente/usurio
requisitos do cliente sem se preocupar com a implementao
evoluem, refletindo no sistema em desenvolvimento. Essas
do sistema.
modificaes devem, antes de tudo, estar documentadas nos
Alm disso, os diagramas de caso de uso proporcionam
casos de uso, impedindo que haja desvios das mtricas com
suporte para visualizao dos servios externos ao ambiente,
o projeto;
tambm chamada de modelagem da viso esttica do caso de
A evoluo dos requisitos no funcionais tambm deve apauso do sistema.
recer na diagramao dos casos de uso, evitando que elementos
Essa modelagem consiste em desenhar um retngulo, que
importantes do desempenho do sistema deixem de constar
representa o sistema em questo. Fora desse retngulo estaro
para as estimativas;
os atores, e internamente ao retngulo esto os casos de uso.
Os sistemas so suscetveis a mudanas corretivas, caso
Os atores interagem com os casos de uso do sistema por meio
apresentem alguma alterao com o que foi especificado nos
de relacionamentos, assim como os atores e os casos de uso
requisitos, desse modo os defeitos localizados devem estar
interagem entre si (ver Figura 1).
documentados no diagrama de casos de uso;
Algumas alteraes no so solicitadas pelo cliente, contudo
Atores
o gerente de projetos pode solicitar sua equipe alteraes
Um ator refere-se a um grupo coerente de papis desempequanto ao produto em desenvolvimento, a fim de evitar futuros
nhados pelos usurios ao interagir com os casos de uso do
problemas de incompatibilidade do software ou mesmo para
sistema. O ator pode ser um ser humano, departamento ou
adequ-lo s exigncias do mercado.
mquina, representado graficamente por um stickman. Por
exemplo, um funcionrio de um banco pode assumir o papel
Um dos problemas a ser enfrentado pelo Use Case Point
de gerente, e caso possua algum tipo de conta nesse banco,
a ateno ao nvel de detalhamento do diagrama de casos de
tambm desempenha o papel de cliente.
uso. Quanto mais casos de uso, atores e relacionamentos a esPercebe-se que o papel do ator alterado pelo modo como ele
pecificao tiver, mais precisa ser a medio, principalmente
interage com o sistema. O gerente realiza abertura de contas,
se o diagrama respeitar a quantidade certa ou pelo menos
lanamento de metas de vendas para a sua equipe, enquanto
aproximada de aes requeridas para o sistema.
que, no papel de cliente, movimenta sua conta, realiza depsitos e saques, entre outros.
Modelagem de Casos de Uso
O ator externo ao sistema, e apesar de oper-lo, no faz
Os diagramas de casos de uso so um dos principais diaparte dele. Apenas troca informaes e fornece funcionalidagramas utilizados na Linguagem de Modelagem Unificada
de ao sistema. Da mesma forma, um ator no pode ser uma
- UML. Sua importncia est em entender e documentar o
instncia. O ator no pode retratar um usurio em particular,
comportamento de um elemento.
e sim o papel representado por este.
25
Por exemplo, se a usuria Maria abrir conta em um banco,

e logo em seguida realizar um depsito de $ 2500,00, h duas
atividades realizadas por um cliente do banco. Convm associa-las ao papel de cliente do banco, pois assim como a Maria,
o Joo tambm pode realizar a abertura de conta e o depsito,
dispensando a repetio de representao dessas atividades.
Os atores, embora realizem atividades em comum, tambm
podem executar tarefas distintas e que sejam importantes para
o entendimento do sistema. No exemplo do banco, considerando que a Maria cliente pessoa fsica, a empresa Fictcia S/A
pode exercer o papel de cliente pessoa jurdica.
Ambos realizam abertura de conta e depsitos, contudo h
atividades especficas para a Maria, como o emprstimo consignativo em folha de pagamento, enquanto a empresa Fictcia
S/A pode receber consultoria para investimento de aes na
Bolsa de Valores.
A modelagem dos casos de uso prev esse tipo de situao, em
que atores especficos so desmembrados de um ator genrico.
Os relacionamentos de generalizao so usados para retratar
o comportamento comum entre os atores. A generalizao
representada por uma seta que parte do ator mais especfico
e aponta para o mais genrico, conforme a Figura 2.
A descrio dos casos de uso pode ser dada de forma contnua, numerada e particionada, conforme a necessidade de
entendimento e narrativa. No formato de descrio contnua,
o texto decorre em frases sequenciais, de acordo com a ordem
em que as aes so executadas. Na descrio numerada, cada
ao numerada em ordem crescente, representada por uma
frase. Na descrio particionada, as aes so separadas em
duas colunas; em uma das colunas so descritas todas as interaes do ator, e na outra coluna, as reaes do sistema.
Os casos de uso tambm contam com colaboraes, que so
sociedades de classes cuja finalidade implementar os casos
de uso. A Figura 3 mostra como uma colaborao contribui
para a realizao do caso de uso. O foco da arquitetura de um
sistema consiste em encontrar o conjunto mnimo de colaboraes bem estruturadas para cada caso de uso.
Figura 3. Casos de uso e colaboraes
Figura 2. Herana entre atores
Os atores tambm so classificados em primrios e secundrios. Os atores primrios so aqueles que do incio ao caso de
uso, enquanto os demais atores apenas participam dos casos
de uso j existentes.
Casos de Uso
Um caso de uso a descrio do que um sistema deve fazer,
sem especificar como ser feito. Por essa definio, entendese que qualquer usurio que interaja como ator nos casos de
uso no precisa saber como o sistema mantm os casos de
uso em processo de execuo das tarefas, apenas deve saber a
responsabilidade de cada caso de uso.
Um caso de uso a especificao de uma sequncia de interaes entre um sistema e os agentes que utilizam esse sistema.
Essas interaes permitem que o agente (ator) tenha apenas a
viso externa do sistema, ao invs do comportamento interno
dos casos de uso.
26
Entre os casos de uso pode haver os relacionamentos de incluso, extenso e generalizao. A incluso refere-se a rotinas
obrigatrias durante a execuo de um caso de uso, gerando
outro caso de uso. Por exemplo, o pagamento de uma compra a
prazo realizado pelo ator Consumidor ir gerar no sistema da
loja vendedora a necessidade de validar os seus dados pessoais
para cadastro; ou seja, uma ao secundria foi acionada por
uma ao primria.
No caso do relacionamento de extenso, a ao de um caso
de uso pode gerar casos de uso opcionais, ou estendidos. Adotando o exemplo anterior, se o Consumidor fizer o pagamento
vista, ele ter 10% de desconto nas compras.
Diferente do relacionamento de incluso, a modificao do
caso de uso estendido no altera o extensor. Isso significa que,
mesmo que no haja o desconto de 10% no valor das compras,
o pagamento ser efetuado. Por outro lado, no relacionamento
de incluso o caso de uso principal alterado conforme o caso
de uso includo executado. Considerando o exemplo anterior,
se o caso de uso validar dados pessoais no for executado, a
compra no poder ser efetuada.
No relacionamento de generalizao todas as sequncias de
comportamento do caso de uso genrico so vlidas para o caso
de uso especfico. O Consumidor que efetua a compra a prazo
tem as opes de pagamento com cheque, carto de crdito ou
boleto bancrio. Cada forma de pagamento representada atravs de um caso de uso, pois todas as trs aes foram geradas
a partir da ao pagamento a prazo (ver Figura 4).
planejamento
Assim como nos atores, o relacionamento

de generalizao entre casos de uso representado graficamente por uma seta que parte
do caso de uso mais especfico para o caso de
uso mais genrico.
No diagrama de casos de uso, vlido
classific-los do ponto de vista dos atores,
em primrios e secundrios. Os casos de uso
primrios identificam os objetivos dos atores,
e representam os processos automatizados
pelo software. Os casos de uso secundrios
contribuem para o correto funcionamento
do sistema, embora no tragam benefcios
diretos, e normalmente esto relacionados a
alguma atividade de manuteno.
Os casos de uso relacionados manuteno
tambm recebem o nome de secundrios,
pois apenas so estruturados quando os
processos j foram definidos e o escopo do
sistema foi delineado.
Comear a identificao pelos casos de
uso secundrios uma indicao de que o
modelador est pensando em como o sistema Figura 4. Relacionamento entre casos de uso
deve ser construdo. O ponto-chave considerar que um sistema de software no existe para cadastrar
Bezerra [1] enumera os fluxos do cenrio de cada caso
informaes, nem tampouco para gerenciar os seus usurios.
de uso, acrescentando os atores, precondies, e as regras
O objetivo principal de um sistema produzir algo de valor
de negcio. As precondies so os requisitos essenciais a
para o ambiente no qual ele est implantado.
partir do qual um determinado caso de uso ser executado.
A comunicao entre os casos de uso e os atores ocorre atravs
As regras de negcio so todas as condies necessrias para
da associao, representada na Figura 4 por um segmento de
que o sistema funcione conforme desejado pelo cliente.
reta apontando para o ator Consumidor e para o caso de uso
A falha de alguma regra de negcio geralmente est assoRealizar Pagamento.
ciada a um fluxo de exceo.
Essa associao permite que o ator se comunique com um
Supondo que o Ator Aluno interaja com o Sistema de
ou mais casos de uso atravs do sistema para enviar e receber
Controle Acadmico para Realizar Inscrio, e o Sistema de
informaes; no exemplo, o Consumidor acessou o Sistema
Faturamento necessite acessar o mesmo caso de uso para
de Pagamento para ativar o caso de uso Realizar Pagamento,
manter o controle dos alunos inscritos, pode-se construir o
mas poderia ativar qualquer outro que estivesse disponvel e
cenrio com o nmero de fluxos correspondentes apresenfosse de sua convenincia, como Efetuar Compra ou Realizar
tado na Tabela 1.
Troca de Produto.
Percebe-se que para a realizao adequada do cenrio
apresentado na Tabela 1, necessrio atender a trs regras
Cenrios
de negcios, descritas separadamente na Tabela 2.
Um cenrio a uma sequncia de aes que descreve como os
casos de uso podem ser realizados. A criao do cenrio permite
Estimativas do Use Case Point
que os casos de uso sejam analisados em seu contexto, atravs de
A tcnica Use Case Point fornece as estimativas de esforo
fluxos de eventos necessrios para a sua realizao. Esses fluxos
requerido para o desenvolvimento do sistema. Entretanto,
so denominados de principal, alternativos, e de exceo.
seu diferencial est em fornecer tais informaes desde o
O fluxo principal descreve o que normalmente acontece na
incio do projeto, logo aps a extrao de requisitos e morealizao dos casos de uso. O alternativo trata do que acontece
delagem dos casos de uso.
quando o ator escolhe caminhos alternativos para atingir o seu
A contagem dos atores e casos de uso considera a comobjetivo. O fluxo de exceo refere-se a aes inesperadas na
plexidade desses elementos e adiciona seus resultados
interao entre o ator e o caso de uso.
a fatores tcnicos e ambientais para ajuste dos clculos.
Tonsig [4] utiliza o mtodo de roteiro textual para descrever o
A contagem dos casos de uso e dos atores depende do siscaso de uso, atravs de dilogos e narrao, que devem fornecer
tema em questo, pois se este tiver um tamanho grande,
os dados necessrios para o modelador extrair as atividades e
recomenda-se que seja decomposto em componentes, para
os envolvidos no cenrio.
facilitar a contagem.
27
Contagem dos Pesos dos Atores

A contagem no ajustada dos pesos dos atores (Unadjusted
Actor Weights UAWs) um dos critrios para obter as estimativas dos casos de uso. So contados os atores envolvidos
no sistema (ou componente do sistema) em anlise, e a seguir
so classificados conforme a sua interao no sistema.
Realizar Inscrio
Sumrio: Aluno usa o sistema para realizar inscrio em disciplinas.
Ator Primrio: Aluno
Atores Secundrios: Sistema de Faturamento
Precondies: O Aluno est identificado pelo sistema.
Fluxo Principal
1. O Aluno solicita a realizao de inscrio.
2. O sistema apresenta as disciplinas disponveis para o semestre corrente e para as quais o aluno
tem pr-requisitos.
3. O Aluno seleciona as disciplinas desejadas e as submete para inscrio.
4. Para cada disciplina selecionada, o sistema aloca o aluno em uma turma que apresente uma
oferta para tal disciplina.
5. O sistema informa as turmas nas quais o Aluno foi alocado. Para cada alocao, o sistema informa
o professor, os horrios e os respectivos locais das aulas de cada disciplina.
6. O Aluno confere as informaes fornecidas.
7. O sistema envia os dados sobre a inscrio do aluno para o Sistema de Faturamento e o caso de
uso termina.
Fluxo Alternativo: Incluso em lista de espera
a) Se no h oferta disponvel para alguma disciplina selecionada pelo aluno, o sistema reporta o
fato e fornece a possibilidade de inserir o aluno em uma lista de espera.
b) Se o aluno aceitar, o sistema insere na lista de espera e apresenta a posio na qual o aluno foi
inserido na lista. O caso de uso retorna ao passo 4 do fluxo principal.
c) Se o Aluno no aceitar, o caso de uso prossegue a partir do passo 4 do fluxo principal.
Fluxo de Exceo: Violao de RN01
a) Se o Aluno atingiu a quantidade mxima de inscries (RN01), o sistema informa ao aluno a
quantidade de disciplinas que ele pode selecionar, e o caso de uso retorna ao passo 2 do fluxo
principal.
Cada ator possui uma complexidade especfica, podendo ser

simples, mdia ou complexa, de acordo com o tipo de comunicao que realiza com o sistema.
Os atores simples so os sistemas externos que interagem
diretamente com outros sistemas atravs de interfaces. Essa
interao ocorre por meio de protocolos que determinam o
acesso por programao s funcionalidades do sistema em
questo (application programming interface - API). Os protocolos definem padres como o formato e a ordem das mensagens
enviadas e recebidas.
Os atores de complexidade mdia podem ser classificados
como os hardwares que controlam o sistema, e os temporizadores, que so sistemas programados para executar uma ao
em tempo pr-determinado.
Esses sistemas interagem atravs do protocolo de controle
de transmisso / protocolo de internet, tambm chamado
de Transmission Control Protocol / Internet Protocol (TCP
/ IP). Sua finalidade a transferncia de dados de comunicao entre redes locais ou redes externas s empresas. Esse
protocolo foi criado para interligar diferentes redes e computadores locais e remotos, suportando sistemas e aplicativos
diferentes entre si.
Os protocolos que representam as transferncias de arquivos
entre sistemas (File Transfer Protocol - FTP) tambm so referncias para contagem dos atores de complexidade mdia.
J os atores complexos so definidos como sendo usurios
que interagem com o sistema por interface grfica, como as
utilizadas em aplicaes web ou cliente-servidor.
Uma vez que se trata de seres humanos, esses tipos de atores so os mais difceis de controlar, alm de serem os mais
imprevisveis.
Por definio, deve-se multiplicar o peso de cada tipo de ator
pela quantidade associada. Supondo que haja quatro atores
simples, cinco de complexidade mdia e dois complexos, ser
feito o seguinte clculo para obter o peso total de atores no
ajustado:
Ps-condies: O aluno foi inscrito em uma das turmas de cada uma das disciplinas desejadas, ou
foi adicionado a uma ou mais listas de espera.
UAW = 1 x quantidade (ator simples) + 2 x quantidade (ator

mdio) + 3 x quantidade (ator complexo)
UAW = 4 x 1 + 5 x 2 + 2 x 3 = 4 + 10 + 6 = 20
Regras de Negcio: RN01, RN02, RN03.
Contagem dos Pesos dos Casos de Uso
Tabela 1. Cenrio para o caso de uso Realizar Inscrio
Quantidade mxima de inscries por semestre letivo (RN01)

Descrio
Em um semestre letivo, um aluno no pode se inscrever em uma quantidade de

disciplinas cuja soma de crditos ultrapasse 20.
Descrio
Uma oferta de disciplinas no pode ter mais de 40 alunos inscritos.
Descrio
Um aluno no pode se inscrever em uma disciplina para a qual no possua os prrequisitos necessrios.
Quantidade de alunos possveis (RN02)

Pr-requisitos para uma disciplina (RN03)
Tabela 2. Regras de negcio para o caso de uso Realizar Inscrio
28
A principal funo dos casos de uso realizar as aes do

sistema ao qual pertencem, atravs de transaes (cenrios) do
fluxo principal e alternativo. O clculo do peso total dos casos
de uso no ajustados (Unadjusted Use Case Weights - UUCWs)
efetuado atravs da contagem das transaes que estes realizam para obter a complexidade dos casos de uso.
A contagem ideal se faz atravs da decomposio do sistema
em componentes, permitindo a contagem de casos de uso
em menor quantidade por componente. Cada caso de uso
avaliado; se realizar trs transaes ou menos, considerado
simples, e atribudo o valor cinco ao seu peso; de quatro a
sete transaes, ser dado o peso dez; para um nmero de
transaes acima de sete, seu peso ser de valor quinze.
planejamento
Esses valores, assim como na contagem dos atores, so multiplicados pela quantidade de elementos localizados em cada
nvel de complexidade, e o resultado o peso total dos casos
de uso no ajustados:
UUCW = 5 x quantidade (caso de uso simples) + 10 x quantidade (caso de uso mdio) + 15 x quantidade (caso de uso
complexo).
Fatores Tcnicos
Assim como na anlise de pontos de funo, os casos de uso
no dependem da tecnologia aplicada para serem definidos.
Entretanto, para realizar uma estimativa coerente com as condies tcnicas da empresa, importante considerar uma srie
de requisitos funcionais relevantes que certamente interferem
no custo e no tempo de durao do projeto.
Existem treze questes relativas complexidade tcnica do
projeto e da equipe que o integra, e cada fator deve ser pontuado com valores de zero a cinco, ou seja, quanto mais relevante
for o fator para o projeto, maior ser a sua pontuao. Fatores
com pontuao zero so considerados irrelevantes, enquanto
os de valor cinco so fundamentais (observar Tabela 3).
Fator (F i)
Descrio dos fatores tcnicos
Peso (P i)
F1
Sistema distribudo
F2
Tempo de resposta
mesma regra adotada pelos fatores tcnicos, e da mesma forma, deve ser avaliada por um especialista ou lder de projetos
(ver Tabela 4).
Fator (F i)
Descrio dos fatores ambientais
Peso (P i)
F1
Familiaridade com o processo de desenvolvimento de software
1,5
F2
Experincia na aplicao
0,5
F3
Experincia em Orientao a Objetos
F4
Capacidade do analista
0,5
F5
Motivao
F6
Estabilidade dos requisitos
F7
Empregados em tempo parcial
-1
F8
Dificuldade com linguagem de programao
-1
Tabela 4. Fatores ambientais para a equipe para o ajuste do UUCP
A participao dos fatores ambientais na determinao dos

Pontos por Caso de Uso capaz de estimar o quanto eficiente
o projeto, e recebe valores semelhantes aos aplicados no TCF,
como segue:
8
E
F = 1,4 + (0,03 Fi x Pi )
i =1
, onde EF o valor total da complexidade
ambiental.
F3
Eficincia
Clculo dos Pontos por Caso de Uso
F4
Complexidade do processamento
F5
Cdigo deve ser reutilizado
F6
Facilidade de instalao
0,5
F7
Facilidade de uso
0,5
F8
Portabilidade
Aps a identificao dos fatores tcnicos e ambientais, resta

multiplic-los pelos Pontos por Caso de Uso no ajustados,
que a soma do peso total de atores no ajustados e do peso
total dos casos de uso no ajustados, tornando dessa forma as
estimativas mais precisas e adequadas realidade do projeto.
O resultado dessa multiplicao so os Pontos por Caso de Uso
ajustados, conforme a equao abaixo:
UCP = (UAW + UUCW) x TCF x EF
F9
Facilidade de alteraes
F 10
Uso concorrente
F 11
Recursos de segurana
F 12
Permite acesso por terceiros
F 13
Necessidade de treinamento
Tabela 3. Fatores tcnicos considerados para o ajuste do UUCP
A pontuao aplicada a cada questo deve ser multiplicada

pelo peso desta, e o somatrio dos resultados o Fator de
Complexidade Tcnica, (Technical Complexity Factor - TCF),
que utilizado na seguinte frmula:
1
3
TCF = 0,0
6 + (0,01 Fi x Pi )
i=1
, onde TCF o valor total da complexidade
tcnica.
Fatores Ambientais
Os fatores ambientais, ou Environmental Factor (EF), so
compostos por 8 questes referentes a requisitos no funcionais, sendo em sua maioria voltados experincia da equipe
envolvida no projeto. A pontuao (de zero a cinco) segue a
A contagem dos casos de uso tambm pode variar entre

as estimativas. Na hiptese de uma transao dos casos de
uso conter diversas transaes, aquela transao pode ser
referenciada como um novo caso de uso, de modo a facilitar a
contagem e evitar desvios de valor para ajuste.
Clculo de Produtividade
O ndice de produtividade determina o esforo necessrio
para o desenvolvimento do sistema, estipulado pelo nmero
de pessoas alocadas no projeto para gerar o produto final.
Carroll [5] adota o valor padro de homem-horas para o
clculo de produtividade, onde um ponto de caso de uso corresponde a vinte homem-horas. Desse modo, supondo que o
valor encontrado no clculo do UCP seja 70, calcula-se o valor
ajustado de homem-horas (HH) da seguinte forma:
Total Homem-Horas = UCP x 20 = 1400 HH
Karner [6] constata que, uma vez que o projeto conta com
um nmero determinado de pessoas, e obtido o valor do UCP,
29
tambm possvel definir a quantidade de horas necessrias

para cada ponto por caso de uso. A Tabela 5 fornece os valores extrados do Projeto A, cujo objetivo calcular o tempo
despendido para desenvolver cada UCP.
Projeto A
Nmero de Atores: 5 atores (valor mdio)
Nmero de Casos de Uso: 10 casos de uso (valor mdio)
UUCP = 110
Fatores de Complexidade Tcnica:
Todos os fatores tm o valor padro 3.
TCF = 1
Fatores Ambientais:
Familiaridade com o mtodo = 1.
Motivao = 5.
Requisitos estveis = 4.
O restante dos fatores tm o valor padro 3.
EF = 0,975
Links:
[1] BEZERRA, E. Princpios de Anlise e Projeto de Sistemas com UML. Rio de
Janeiro: Elsevier, 2002.
[2] CARROLL, E.R. Estimating Software Based on Use Case Point. In: Conference on Object Oriented Programming Systems Languages and Applications,
20., San Diego, 2005. Practitioner report. Nova Iorque: ACM Press, 2005.
p.257-265.
[3] ROCHA, A.R.C.; MALDONADO, J.C.; WEBER, K.C. Qualidade de Software:
Teoria e Prtica. So Paulo: Pearson Education do Brasil/Makron Books
Ltda, 2001.
[4] TONSIG, S.L. Engenharia de Software: anlise e projeto de sistemas. So
Paulo: Futura, 2003.
[5] CARROLL, E.R. Estimating Software Based on Use Case Point. In: CONFERENCE ON OBJECT ORIENTED PROGRAMMING SYSTEMS LANGUAGES AND
APPLICATIONS, 20., San Diego, 2005. Practitioner report. Nova Iorque: ACM
Press, 2005. p.257-265.
[6] KARNER, G. Resource Estimation for Objectory Projects. Kista: Objective
Systems SF AB, 1993.
UCP = UUCP X TCF X EF = 107,25

Recursos utilizados:
Homem-Horas para completar o projeto: 2150 h.
Recursos Mdios (Mean Resources - MR) para o projeto A = 2150 / 107,25 20 h

Tabela 5. Estimativa de Recursos Mdios por UCP
30
Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros
Casos de Teste: Importncia da

rastreabilidade entre requisitos
Ana Paula Gonalves Serra
prof.anapaula@usjt.br
Doutora e Mestre em Engenharia de Computao e Sistemas Digitais pela Escola

Politcnica da Universidade de So Paulo.
Bacharel em Cincia da Computao pela
Universidade So Judas Tadeu. Professora
na rea de Engenharia de Software da
Universidade So Judas Tadeu nos cursos
de Ps-Graduao e Graduao. Professora de Engenharia de Software da FATEC
Ipiranga no curso de Graduao. Membro do Projeto INOVA Paula Souza como
Agente Local de Inovao.
Edson Saraiva de Almeida

prof.ealmeida@usjt.br
Mestre em Engenharia de Computao

pelo IPT/USP, Licenciado em Matemtica
pela Universidade Catlica de Santos,
Certificado pelo SOFTEX no MPS.BR, em
teste pelo ISTQB e pelo Scrum.org como
Professional Scrum Master. Com 20 anos de
experincia em consultoria na avaliao da
qualidade de projetos de desenvolvimento
de software tendo atuado por 5 anos na
Scopus Tecnologia como Coordenador de
Controle da Qualidade, por 6 anos na ASR
como Consultor em Qualidade de Software,
por 2 anos na Fidelity Information Services
como Coordenador de Controle da Qualidade de Software e por 5 anos no Unibanco
em auditoria de sistemas.
Fique por dentro:

A rastreabilidade dos requisitos de software
uma atividade da gerncia de requisitos e est
associada qualidade do desenvolvimento de
software. Uma deciso importante que deve ser
definida no incio do projeto est relacionada ao
nvel de rastreabilidade que ser mantido para
atender os objetivos do software. O planejamento
da rastreabilidade deve adotar uma abordagem
que permita facilitar o processo de desenvolvimento de software e no restringi-lo.
Uma das grandes dificuldades no desenvolvimento de software a gerncia de requisitos, pois
necessrio manter o acompanhamento dos requisitos individuais e manter a ligao dos requisitos
dependentes, pois a alterao de um requisito
este pode ser definido como uma

atividade que tem por objetivo
verificar se o software produzido
est de acordo com sua especificao e
se satisfaz as expectativas do cliente.
Teste de software parte integrante
do processo de Validao e Verificao
(V&V) da Engenharia de Software. Sendo
que, verificao refere-se ao conjunto
de tarefas que garantem que o software
pode afetar outros requisitos, regras de negcio

relevantes e arquitetura do sistema. Consequentemente, os casos de testes so comprometidos e
a entrega do software pode no atender a expectativa do cliente, alm de conter erros de validao e verificao.
Este artigo apresenta ao leitor um modelo que
permite manter a rastreabilidade entre requisitos e casos de teste. O propsito deste modelo
estabelecer mecanismos de rastreabilidade para
garantir que os requisitos sejam atendidos pelo
sistema e permitir avaliar o impacto de alteraes
nos requisitos que podem implicar em modificaes nos artefatos de projeto, no cdigo e de maneira particular nos casos de teste.
implementa corretamente uma funo

especfica, e validao refere-se ao
conjunto de tarefas que asseguram que
o software foi criado e pode ser rastreado segundo os requisitos do cliente.
A definio de V&V abrange muitas
atividades de garantia da qualidade de
software [4].
Das atividades de verificao e validao, a atividade de teste considerada
31
um elemento crtico para garantia da qualidade. Um problema

na atividade de teste de software esta relacionado a como
determinar se um programa P foi suficientemente testado e
pode ser liberado para os usurios com razovel confiana de
que funcionar de modo aceitvel. O significado de aceitvel
varia para uma aplicao especfica em funo da criticidade
das funes, consequncias antecipadas de um mau funcionamento e da frequncia de uso esperada. Apesar dos esforos
na utilizao de modelos de melhoria de processos em organizaes de desenvolvimento de software, os padres para
determinar a adequao da atividade de teste so praticamente
inexistentes. Um conjunto de problemas no processo de teste
que devem ser evitados so:
Cronogramas agressivos deixando a equipe de teste impossibilitada de completar os testes planejados devido falta de
recursos, equipe no qualificada e falta de tempo;
Falta de rastreabilidade de casos de teste entre diferentes
verses do sistema, dificultando o reuso e repetio dos testes
aps modificaes nos requisitos;
Testes manuais, pois h um grande esforo da equipe de testes a cada incio de uma nova atividade de teste, consequentemente quando o software sofre manuteno e a documentao
no atualizada;
Ambiente de teste diferente do ambiente de produo;
Ausncia de critrios para seleo dos casos de teste, definio da sua completude e estabelecimento de um ponto de
parada.
Este artigo aborda a rastreabilidade de requisitos, enfatizando
aspectos relacionados s informaes de rastreabilidade entre
requisitos e casos de teste. Nosso principal propsito apresentar ao leitor algunsaspectos que envolvem a rastreabilidade
visando conscientiz-lo da importncia do rastreamento no
processo de desenvolvimento de software.
Estratgia de Teste de Software

Uma estratgia para teste de software pode ser realizada
numa srie de quatro passos executados sequencialmente,
conforme apresentado na Figura 1 e explicado a seguir:
(i) Inicialmente o foco do teste cada componente individual, garantindo que estas funes operam adequadamente.
O teste de unidade focaliza o esforo de verificao na menor
unidade de projeto do software, componente ou mdulo de
software.
(ii) Em seguida, os componentes devem ser integrados (teste de
integrao) para formarem um pacote completo de software.
(iii) Depois que o software passou pelo processo de teste de
unidade e integrao testes de validao so conduzidos.
Os requisitos estabelecidos com parte da anlise de requisitos do
software so validados contra a implementao do sistema.
(iv) Finalmente o software deve ser combinado com outros
elementos do sistema e testado como um todo. Testes de
sistema verificam se todos os elementos esto integrados de
maneira adequada e se todas as funcionalidades do sistema
so atendidas [5].
32
Figura 1. Estratgia de teste [5]
A aplicao de uma estratgia de teste uma aliada na garantia de qualidade, mas somente ter sucesso se os testadores
de software realizarem as seguintes atividades [5]:
Especificarem o software de maneira quantificvel, muito
antes de comearem os testes: alm de encontrar erros, uma
boa estratgia de teste tambm avalia outras caractersticas
de qualidade, como: portabilidade, manuteno, confiabilidade, usabilidade, entre outros. O objetivo de mensurar
esses requisitos que no ocorra ambiguidade nos resultados dos testes;
Definirem explicitamente os objetivos do teste: Os objetivos especficos dos testes devero ser definidos em termos
mensurveis no plano de testes. Por exemplo: eficincia e
abrangncia do teste, tempo mdio de falhas e custo para
corrigir defeitos;
Desenvolverem um plano de teste que enfatizem o teste
do ciclo rpido: recomenda-se que existam ciclos rpidos,
em torno de 2% do trabalho de projeto de incrementos de
funcionalidades. O retorno gerado por esses testes de ciclo
rpido pode ser usado para controlar os nveis e qualidade e
as correspondentes estratgias de teste;
Criarem software robusto que sejam projetados para testar o
prprio software: Criao de software que diagnostique certas
classes de erros, alm de testes automatizados;
Utilizarem revises tcnicas eficazes com filtro antes do teste:
As revises tcnicas podem ser to eficazes como testes para
descobrir erros, pois podem antecipar erros, reduzir o trabalho
e produzir software de alta qualidade;
Executarem revises tcnicas para avaliar a estratgia
de teste e os prprios casos de testes: As revises tcnicas
podem descobrir inconsistncias, omisses e erros na abordagem de testes;
Desenvolverem abordagem de melhoria contnua para o
processo de teste: A estratgia de teste dever ser medida,
para que haja um controle estatstico de processo para o teste
de software.
Engenharia de Software Magazine - Casos de Teste: Importncia da rastreabilidade entre requisitos
en gen haria
No cenrio atual de desenvolvimento de software, alm

da estratgia de testes, h a necessidade de automatizar os
testes, pois, quando desenvolvidos de forma adequada, sero
facilmente executados.
Para agregar valor ao negcio e atender a presso por
prazos em projetos de desenvolvimento de software necessrio estabelecer um processo de automao de teste de
software robusto [1]. A Programao eXtrema, em particular,
recomenda explicitamente testes automatizados para ajudar na garantia da qualidade dos sistemas de software [4].
Em sistemas complexos o volume de scripts de teste pode
crescer muito e importante nestes casos uma estratgia de
organizao dos scripts.
Modelo de rastreabilidade
Os requisitos de um sistema de software esto sempre mudando. Durante o processo de desenvolvimento de software
o entendimento dos envolvidos sobre o problema que est
sendo solucionado muda constantemente. Esses requisitos
devem evoluir para refletir essas novas vises do problema. O
gerenciamento de requisitos um processo para compreender
e controlar as mudanas dos requisitos de sistema. Existem vrios relacionamentos entre os requisitos e o projeto do sistema.
Quando as mudanas so propostas, deve-se estabelecer meios
para rastrear seu impacto em outros requisitos e no projeto do
sistema, a chamada hierarquia de rastreabilidade.
A rastreabilidade a propriedade de uma especificao de
requisitos que reflete a facilidade de encontrar os requisitos
relacionados. Os elementos do projeto envolvidos em rastreabilidade so chamados de itens de rastreabilidade. Os itens
tpicos de rastreabilidade incluem diferentes tipos de requisitos - funcionais e no funcionais, elementos de modelo de
projeto e de anlise, artefatos de testes (conjuntos de testes,
casos de teste, etc.), material de treinamento e documentao
de suporte a usurio final.
Em qualquer processo de desenvolvimento de software existe
algum mecanismo de rastreabilidade implcito. Geralmente a
rastreabilidade estabelecida pelas relaes formais entre os
artefatos do processo. Um exemplo deste tipo de rastreabilidade implcita a conveno de nomenclatura, ou seja, a classe
no modelo de projeto chamada Cliente implementada pela
classe no modelo de implementao chamada Cliente.
Trs tipos de informaes de rastreabilidade podem ser
mantidos:
1. Informaes de rastreabilidade da origem: elos de rastreamento (link) ligam requisitos aos envolvidos que propuseram
os requisitos e a necessidade desses requisitos. Quando uma
mudana proposta pode-se utilizar essas informaes para
encontrar e consultar os envolvidos sobre a mudana.
2. Informaes de rastreabilidade de requisitos: elos de rastreamento (link) ligam os requisitos dependentes dentro do documento de requisitos. Permite avaliar quantos requisitos sero
afetados pela mudana proposta e a extenso das mudanas.
3. Informaes de rastreabilidade de projeto: elos de rastreamento (link) ligam os requisitos aos mdulos de projeto, nos
quais esses requisitos so implementados. Permite avaliar o

impacto das mudanas de requisitos no projeto e na implementao do sistema.
As informaes de rastreabilidade so frequentemente
representadas por meio de matrizes de rastreabilidade que
relacionam os requisitos aos envolvidos, a outros requisitos ou
mdulos do projeto. Para a criao de tabelas de rastreabilidade
para auxiliar o processo de gesto de requisito necessrio
identificar os requisitos. A Figura 2 apresenta uma tabela
de rastreabilidade genrica, onde as linhas representam os
requisitos e as colunas os atributos de requisitos que podem
ser aspectos especficos do sistema ou do ambiente, inclusive
casos de teste associados ao requisito.
Figura 2 . Tabela de rastreabilidade genrica
Cada tabela de rastreabilidade relaciona os requisitos identificados a um ou mais aspectos do sistema ou de seu ambiente.
Entre as muitas tabelas de rastreamento possveis esto as
seguintes:
Tabela de rastreabilidade de caracterstica: mostra como
os requisitos se relacionam a caractersticas importantes do
sistema/produto.
Tabela de rastreabilidade de fontes: identifica a fonte de
cada requisito.
Tabela de rastreabilidade de dependncia: indica como os
requisitos esto relacionados uns aos outros.
Tabela de rastreabilidade de subsistemas: caracteriza os
requisitos pelo subsistema que ele governa.
Tabela de rastreabilidade de interface: mostra como os requisitos se relacionam com as interfaces internas e externas
do sistema.
A estratgia de rastreabilidade apresentada na Figura 3
relaciona os requisitos de usurio (Requisitos do Produto Req A), os requisitos de sistema (Requisitos detalhados
(Casos de Uso) - Req B), com artefatos de projeto, casos de teste
e documentos de usurio.
O Rational Unified Process (RUP) um processo de engenharia de software que oferece uma abordagem baseada em
disciplinas para atribuir tarefas e responsabilidades dentro
de uma organizao de desenvolvimento. Sua meta garantir
a produo de software de alta qualidade que atenda s necessidades dos usurios dentro de um cronograma e de um
oramento previsveis.
33
O RUP considera entre as melhores prticas de desenvolvimento de software o gerenciamento de requisitos (enfoque na
rastreabilidade de requisitos em todo o processo de desenvolvimento de software, conforme apresentado na Figura 4). Essas
melhores prticas devem ser apoiadas por ferramentas para
automatizar o processo de engenharia de software.
A finalidade de estabelecer rastreabilidade ajudar a:
Compreender a origem dos requisitos;
Gerenciar o escopo do projeto;
Gerenciar mudanas nos requisitos;
Avaliar o impacto no projeto da mudana em um
requisito;
Avaliar o impacto da falha de um teste nos requisitos (isto ,
se o teste falhar, talvez o requisito no seja atendido);
Verificar se todos os requisitos do sistema so atendidos
pela implementao;
Verificar se o aplicativo faz apenas o que era esperado que
ele fizesse.
De acordo com os artefatos do RUP, as informaes fornecidas
sobre os requisitos como Regras de Negcios e Solicitaes dos
Figura 3. Estatgia de rastreabilidade de requisitos
Figura 4. Hierarquia de rastreabilidade
34
Principais Envolvidos, so convertidas em um conjunto de

necessidades chave dos envolvidos/usurios e caractersticas
do sistema, conforme especificado no documento de Viso.
O modelo de caso de uso, por sua vez, descreve como essas
caractersticas so convertidas na funcionalidade do sistema.
Os detalhes de como o sistema interage com o mundo externo
so capturados nos casos de uso, com outros requisitos importantes (como requisitos no funcionais, restries de design,
etc.) na especificao suplementar. A rastreabilidade tambm
permite acompanhar como essas especificaes detalhadas
so traduzidas em um projeto, como elas so testadas e como
elas so documentadas para o usurio. No caso de sistemas
complexos, os casos de uso e as especificaes suplementares
podem ser reunidos para definir uma especificao de requisitos de software (ou SRS Software Requirements Specification)
para uma caracterstica particular ou outros agrupamentos
de subsistemas.
O modelo de caso de uso e a especificao suplementar so
artefatos de entrada continuamente para o modelo de design,
conjunto de testes (onde sero especificados os casos de teste)
e documentao adicional.
Um conceito-chave para ajudar a gerenciar mudanas nos requisitos o vnculo
de rastreabilidade suspeito. Quando
um requisito (ou outro item de rastreabilidade) muda em qualquer extremidade
do vnculo de rastreabilidade, todos os
vnculos associados quele requisito so
marcados como suspeitos. Isso uma
marca para que seja realizada uma anlise
de mudana que determina se os itens
associados precisaro mudar tambm.
Esse conceito tambm ajuda a analisar o
impacto de mudanas potenciais.
A rastreabilidade pode ajudar a responder ao seguinte conjunto de questes:
Necessidades dos usurios que no
foram vinculadas a caractersticas do
produto;
Status dos testes em todos os casos de
uso na interao #n;
Requisitos suplementares vinculados a
testes que possuem status no testado;
Resultados de testes que falharam, em
ordem de importncia;
Caractersticas programadas para este
lanamento, quais necessidades de usurios elas satisfazem e o status delas.
Uma considerao, que o RUP pode
ser utilizado para todos os tipos de
projeto de software, de simples a complexo. Recentemente, um nmero cada
vez maior de modelos geis, como
eXtreme Programming (XP), SCRUM,
en gen haria
Feature-Driven Development (FDD) e a metodologia Crystal

Clear, tm obtido reconhecimento como modelos eficazes
para a criao de sistemas menores e que podem ser compatveis com o RUP, pois o RUP um framework de processo
configurvel.
O conceito de rastreabilidade de requisitos pode ser aplicado
em qualquer modelo gil. Por exemplo, no XP podem-se definir
requisitos com histrias, escritas em cartes representando
os requisitos funcionais. Os requisitos no funcionais podem
ser mapeados em restries, e os casos de testes podem ser
representados pelos testes de aceitao, testes unitrios, dados
do teste e resultado do teste.
Ratreabilidade entre requisitos e casos de teste

O software deve ser testado para garantir que se comporta
de acordo com os requisitos estabelecidos e que ir funcionar
como esperado em seu ambiente pretendido. O teste deve ser
eficaz para encontrar defeitos, mas tambm deve ser eficiente
e rpido de executar a um baixo custo.
A automao da execuo do teste de software pode reduzir
significativamente o esforo necessrio de teste, ou aumentar
significativamente as condies a serem testadas em um tempo
limitado. Alguns estudos mostram economia na ordem de 80%
do esforo de teste manual com a utilizao de teste automatizado. Algumas organizaes no obtiveram uma economia
financeira ou de esforo diretamente com a automao do
processo, mas isto, tem permitido produzir software de melhor
qualidade mais rapidamente do que seria possvel por meio
de testes manuais isoladamente.
Implementar uma soluo para automao de testes de software, mesmo com a disponibilidade de excelentes ferramentas
de teste uma tarefa no trivial, no evidente, com alta chance
de insucesso e frustrao. A elaborao de scripts deve ser
precedida por uma anlise da automao que determine qual
a melhor abordagem a ser seguida de maneira a maximizar o
retorno da atividade de teste. A falta de um planejamento adequado pode resultar em uma taxa elevada de manuteno dos
scripts de teste, baixa cobertura, tempo de desenvolvimento
de scripts excessivo, com pouca flexibilidade e produtividade, limitando os benefcios que poderiam ser obtidos com o
processo de automao.
Uma estratgia de automao de teste pode estabelecer uma
abordagem de teste em trs nveis diferentes, como mostrado
na Figura 5 pirmide de automao de teste. Na base da
pirmide de teste esto os testes de unidade e componente.
No desenvolvimento gil o maior esforo de teste direcionado para esta camada. O meio da pirmide inclui os testes
automatizados da frente de negcios escritos para oferecer
suporte equipe. Na camada do topo so mantidos os testes
que manipulam e operam a camada de apresentao tradicionalmente os testes de maior custo para escrever.
Uma dificuldade na estratgia de automao de teste frequentemente est relacionada a como organizar os scripts de
teste. necessrio planejar esta organizao, pois na medida
em que os scripts de teste aumentam, pode se tornar muito
complicado localizar um caso de teste. Considerando uma

tecnologia orientada a objeto a unidade bsica da organizao
do cdigo de teste o mtodo de teste. Decidir o que colocar e
onde o foco central desta organizao. Existem quatro possibilidades de organizao, sendo que no existe uma soluo
tima deve-se analisar e decidir a melhor estratgia:
1. Uma classe de teste para toda aplicao: o nmero de casos de
teste pode crescer e ser necessrio dividir em mais classes de teste reduzindo o nmero de mtodos de teste por classe de teste;
2. Uma classe de teste por classe testada;
3. Uma classe de teste por funcionalidade;
4. Uma classe de teste por pr-condies: um grupo de testes
que requerem as mesmas pr-condies (Por exemplo: sistemas
de processamento de carto de crdito tipicamente utilizam
esta estratgia, o esforo de setup da aplicao para iniciar a bateria de teste, justifica o compartilhamento das pr-condies
independentemente das funes a serem testadas).
Figura 5. Pirmide de automao de teste
Outro aspecto importante est relacionado conveno de

nomes. Os nomes estabelecidos para uma classe de teste ou
um mtodo de teste podem ajudar a encontrar e compreender
um caso de teste. A estratgia de organizao dos scripts de
teste associada a uma conveno de nomes adequada permite
estabelecer os elos de rastreabilidade de acordo com as necessidades de cada projeto. No exemplo da Figura 6, a estratgia
de um script de teste por caso de uso foi estabelecida e uma
conveno de nomes permite identificar o caso de uso e o script
de teste correspondente.
Uma matriz de rastreabilidade apresentada na Tabela 1 pode
ser elaborada mantendo informaes de rastreabilidade entre
requisitos e casos de teste.
Cada script de teste mantm os casos de teste de acordo com
as condies de teste estabelecidas para validar o comportamento do sistema. A rastreabilidade mantida por seo de
caso de uso (fluxo bsico e alternativo), conforme apresentado
na Figura 7.
35
Figura 6. Modelo de rastreabilidade entre requisitos e casos de teste automatizado
Figura 7. Casos de teste associados a casos de uso

Req
Script de Teste
Casos de teste (mtodos de teste)
UC05
UC05LiberacaoDeAcesso.java
CT01UC05FBLiberacaoDeAcesso_com_sucesso ( )
UC05
UC05LiberacaoDeAcesso.java
CT02UC05A1LiberacaoDeAcesso_senha_invalida ( )
...
...
...
Tabela 1. Matriz de Rastreabilidade
Desta forma, de acordo com o critrio de aceitao estabelecido, pode-se avaliar se o resultado da execuo dos testes est
aderente aos objetivos de qualidade planejados.
A estratgia pode ser adaptada de acordo com as necessidades do projeto. O modelo pode ser aplicado para os testes de
unidade, integrao ou de sistema.
36
A existncia dos mecanismos de rastreabilidade permite

identificar as origens de cada funcionalidade de um sistema.
Estes mecanismos podem ser usados em procedimentos de
verificao e validao para garantir que o sistema foi adequadamente testado e que atende s necessidades dos usurios.
Mecanismos de rastreabilidade entre requisitos e casos de
testes permitem, entre outras coisas, visualizar a quantidade
de casos de teste alocada a um requisito e se algum requisito
ainda no possui casos de testes associados. Alguns pontos
que devem ser considerados na aplicao de um modelo de
rastreabilidade podem envolver:
1. A captura e uso dos elos (links) de rastreabilidade devem ser
adaptados s necessidades especficas de cada projeto;
2. Definir no incio do projeto um modelo de rastreabilidade,
considerando a aplicao a ser desenvolvida, os objetos e artefatos que sero alvo de registro da rastreabilidade;
3. Identificar ferramentas que apoiaro o processo de
rastreabilidade;
4. Conscientizar a equipe da importncia do processo de
rastreabilidade;
5. Estabelecer os momentos de registro e controle da
rastreabilidade;
6. Avaliar um mecanismo de extrao de elos (agilidade na
recuperao);
7. Analisar criticamente com a equipe, aps a liberao
do software a efetividade do modelo de rastreabilidade
adotado.
en gen haria
A rastreabilidade de requisitos tem sido identificada na literatura como fator de qualidade do processo de desenvolvimento
de software, apesar disto, ainda existe um desconhecimento
sobre os benefcios da utilizao de modelos de rastreabilidade
em organizaes de desenvolvimento de software. A efetiva
aplicao da rastreabilidade no processo de desenvolvimento
de software depende da definio de um modelo de rastreabilidade. Neste artigo abordamos a rastreabilidade de requisitos
considerando aspectos de rastreabilidade entre requisitos e
casos de teste.
O planejamento da rastreabilidade deve adotar uma abordagem que permita facilitar o processo de desenvolvimento
de software e no restringi-lo. A existncia dos mecanismos
de rastreabilidade permite identificar as origens de cada
funcionalidade de um sistema. Estes mecanismos podem ser
usados em procedimentos de verificao e validao para garantir que o sistema foi adequadamente testado e que atende
s necessidades dos usurios. Mecanismos de rastreabilidade
entre requisitos e casos de testes permite, entre outras coisas,

visualizar a quantidade de casos de teste alocada a um requisito e se algum requisito ainda no possui casos de teste
associados.
Links:
[1] CRISPIN, Lisa; GREGORY, Janet. Agile testing: A practical guide for testers
and agile teams. Pearson Education, 2009.
[2] FEWSTER, Mark; GRAHAM, Dorothy. Software test automation: effective
use of test execution tools. ACM Press/Addison-Wesley Publishing Co.,
1999.
[3] MESZAROS, Gerard. xUnit test patterns: Refactoring test code. Pearson
Education, 2007.
[4] BECK, Kent; ANDRES, Cynthia. Extreme programming explained: embrace
change. Addison-Wesley Professional, 2004.
[4] RUP. Rational Unified Process, 2001.
[5] SAYO, Miriam; DO PRADO LEITE, Julio Cesar Sampaio. Rastreabilidade de

requisitos. RITA, v. 13, n. 1, p. 57-86, 2006.
[6] SPENCE, Ian; PROBASCO, Leslee. Traceability strategies for managing

requirements with use cases. White Paper, Rational Software Corporation,
1998.
37
Engenharia
Mtricas de Software
Problema ou Soluo?
Fique por dentro:
Darlan Florncio de Arruda

dfa@ecomp.poli.br www.darlanarruda.com
Bacharel em Sistemas de Informao

pela Universidade de Pernambuco (UPE).
Tem experincia na rea de Cincia da
Computao, com nfase em Mtricas,
Gesto, Testes e Qualidade de Software.
Atualmente aluno do programa de
mestrado acadmico em Engenharia de
Computao da Escola Politcnica da
Universidade de Pernambuco (POLI/UPE)
e Engenheiro de Testes de Software do
C.E.S.A.R.
38
tricas de Software um assunto que vem sendo estudado h

anos e mesmo assim, ainda
hoje desperta interesses de pesquisadores. Talvez pelo fato de ainda no ter
atingido sua maturidade. Sabe-se que
realizar estimativas e prover mtricas
de software eficientes tem se tornado
um grande desafio na rea de TI e que
essa incapacidade da indstria em estimar software com preciso resulta em
problemas oramentais e atrasos nas
entregas. Diante disso, esse artigo tem
como objetivo investigar e apresentar
possveis causas que contribuem para o
uso ineficiente de mtricas de software.
Mtricas de softwares possibilitam
realizar uma das atividades mais fundamentais do processo de gerenciamento
de projetos - o planejamento. Servem
como suporte medio em diversas
tipos de atividades e aplicaes como,
por exemplo: utilizao de mtricas
no contexto organizacional de gesto
do conhecimento, no apoio a sistemas
Engenharia de Software Magazine - Mtricas de Software
Nesse artigo so tratados aspectos relevantes

acerca da aplicao e utilizao de mtricas de
software, visando identificar e explanar fatores
que contribuem para que atividades de medio
e estimativas sejam realizadas de forma ineficiente pela indstria de TI. Esse artigo til em
situaes onde as atividades de medio e estimativas de software so realizadas de forma
ineficiente, pois apresenta dados e informaes
importantes que so identificados como contribuintes para o uso ineficiente de mtricas em
projetos de software, dando uma viso ampla
acerca do assunto, ajudando profissionais de TI
a identificar tais fatores em suas organizaes e
com isso minimizar os problemas encontrados
na realizao desse tipo de atividade.
baseados em computao em nuvem,

no suporte a medio de complexidade
do software, medio de esforo de trabalho, mtricas no contexto de custos em
manuteno corretiva de software, como
suporte a mensurao de qualidade
em aplicaes de negcios, inspeo de
software e mtricas no contexto de qualidade e testes de Software.
en gen haria
Mtricas de software medem diferentes aspectos da complexidade do software e, portanto, desempenham um papel
importante na anlise e melhoria da qualidade do software.
Tais aspectos abrangem rea de qualidade, estimativa, custos,
processos e assim por diante. Uma outra definio para mtrica
de software a referencia como sendo a medida - geralmente
usando classificaes numricas - para quantificar algumas
caractersticas ou atributos de uma entidade de software.
Medies tpicas incluem a qualidade dos cdigos de fonte, o
processo de desenvolvimento e as aplicaes realizadas.
Alm dessas, pode-se afirmar tambm que mtricas de software a contnua aplicao de tcnicas baseadas na medio
para o processo de desenvolvimento de software e para os
seus produtos fornecendo informao de gesto relevante e,
a utilizao dessas tcnicas visa melhorar o processo e os seus
produtos [4]. As mtricas de software so agrupadas em dois
tipos, as mtricas de produto e as mtricas de processos.
Mtricas de Produto, tambm conhecidas como as mtricas de
qualidade, so usadas para medir as propriedades do software
e ajudam a melhorar a qualidade dos diferentes componentes
e existentes do sistema. Pode-se destacar como exemplos de
mtricas de produto: esforo, tamanho, volume, complexidade,
contagem de pontos de funo, contagem de Tokens, mtricas de
funcionalidades, desempenho, usabilidade, custo e tamanho
e mtricas de estilo.
J as mtricas de processo so conhecidos como mtricas de
gesto e so utilizadas para medir as propriedades do processo que usado para se obter o software. Mtricas de processo
incluem as mtricas de custo e esforos, mtricas de progresso
e mtricas de reutilizao. Mtricas de processo ajudam na
previso do tamanho do sistema final e a determinar se um
projeto em execuo se encontra de acordo com o cronograma. Como mtricas de processos, podemos citar: mtricas de
reusabilidade, mtricas de produtividade, mdia de ponto de
estria por desenvolvedor por dia/ms, mtricas de recursos,
dentre outros.
Comparar e avaliar as capacidades e produtividade das pessoas envolvidas no desenvolvimento de software, elaborao
das especificaes de qualidade de software, verificao do
cumprimento de requisitos de sistemas de software e especificaes, so algumas das caractersticas que a aplicao de
mtricas proporcionam e que so consideradas vantagens para
quem as usam. Alm disso, pode-se citar tambm a tomada de
decises sobre outra diviso do mdulo complexo que deve
ser feito ou no e obteno de uma ideia sobre a complexidade
do software
Ao mesmo tempo em que as mtricas de software proporcionam diversas vantagens que ajudam no auxlio de algumas
atividades dentro do processo de desenvolvimento do produto de software elas tambm apresentam certas limitaes
em relao ao seu uso. A maioria dessas desvantagens esto
vinculadas ao uso incorreto por parte dos profissionais de TI.
No processo de utilizao de mtricas de software, deve-se
garantir algumas propriedades para que as mesmas sejam
utilizadas da maneira mais eficiente possvel.
As mtricas devem ser facilmente entendidas, calculadas e

testadas, devem gerar uma sugesto de melhoria nas estratgias, bem como de grande importncia que a mtrica seja
obtida o mais cedo possvel no processo de desenvolvimento
do software.
A utilizao de mtricas de software muito importante
dentro da engenharia de software, especialmente na gerncia
de projetos. Ela geralmente analisada por gerentes de projetos de software e coletada pelos engenheiros e/ou analistas
de software.
Mtrica: Problema ou Soluo?

Mtrica de software um assunto estudado h mais de 30
anos. No entanto, mal conseguiu se estabelecer sua amplitude
na engenharia de software. A principal razo para isto que
a maioria das atividades associadas ao uso de mtricas de
software no tm apresentado o requisito mais importante: fornecer informaes para apoiar a tomada de deciso gerencial
quantitativa durante o ciclo de vida do software [3].
Quando se pensa em produtos de software, o grande desafio
das empresas estimar custos, esforo e prazo para criao
de mtricas que realmente representem a realidade. Estimar
software uma atividade complexa, cujos resultados devem
ser constantemente atualizados levando em considerao
quantitativos reais de todo o ciclo de vida do desenvolvimento. Realizar estimativas e prover mtricas de software tm se
tornado um grande desafio na rea de TI.
A incapacidade da indstria em estimar software com preciso
resulta em falhas oramentais e atrasos nas entregas que resultam em desconfiana e insatisfao por parte do contratante.
Essa incapacidade em prover estimativas precisas com relao
a custo, esforo e tempo constantemente citada em relatrios
como o trabalho intitulado Catlogo de Fatores que Influenciam
a Produtividade no Desenvolvimento de Software, por meio de
estudos de casos de projetos que falharam e publicaes
cientficas como Practical Software Project Estimation: A Toolkit
for Estimating Software Development Effort & Duration, dentre
outros. Em estudo realizado no Brasil em 2009 pelo Ministrio
da Cincia e Tecnologia do Governo Brasileiro, observou-se
que 22,7% das empresas, de um total de 264 analisadas, no
utilizam nenhuma mtrica para estimar o tamanho de produto
de software.
Diante disso, questionamentos como: Por que isso acontece?
Por to difcil estimar e prover mtricas de forma eficiente? Quais os
fatores que contribuem para o uso ineficiente de mtricas em projetos
de Software? Utilizar mtricas em projetos de software uma soluo
ou um problema? Ser que o fato da empresa no utilizar mtricas
de software est relacionado a histricos de mal uso? - se mostram
importantes e relevantes tanto para academia, quanto para a
indstria, diante da necessidade de entender esses porqus
e buscar uma soluo que diminua esse gap da engenharia
de software.
Na prxima seo, so apresentados fatores e aspectos que so
e podem ser considerados contribuintes para o uso ineficiente
de mtricas em projetos de software, por empresas de TI.
39
Fatores Contribuintes para o uso Ineficiente de

Mtricas de Software
Como j explicado em sees anteriores, o uso de mtricas de software por parte da indstria de TI tem levantado
questionamentos acerca da qualidade de sua aplicao no
que diz respeito a eficincia na realizao de atividades de
estimativas e medio. Sendo assim, nessa seo mostra-se
que existem vrios fatores que so e que podem ser considerados contribuintes para histricos de medio e estimativas
mal sucedidas em projetos de software.
Percebe-se que mtricas de software possuem certas limitaes. Percebe-se que algumas delas contribuem para o uso
ineficiente de mtricas de software. Pode-se afirmar que as
mtricas de software no so aplicadas de forma eficiente
por que so difceis de aplicar, considerado um trabalho
dispendioso e que utiliza em sua maioria dados histricos
e empricos, que so difceis de verificar e que muitas vezes as empresas no os possuem. Isso resulta na falta de
informaes sobre projetos anteriores completados, o que
dificulta na estimativa de novos projetos, principalmente
se esse novo projeto no possuir similaridade com projetos
j executados.
sabido tambm que uma vasta gama de mtricas de
software, visando vrios nveis de abstrao e atributos
de qualidade, tm sido propostas pela comunidade de
pesquisa [1]. Muitas destas mtricas de avaliao consiste
em verificar as propriedades matemticas, investigando o
comportamento da mtrica para um certo nmero de sistemas ou comparando o seu valor contra outras mtricas
quantificando atributos de qualidade relacionados. E isso
pode ser um problema quando se pensa em ter mtricas
eficientes e reais. Dessa forma, uma anlise estrutural das
mtricas seria uma soluo.
Porm, infelizmente, uma anlise estrutural da utilidade
de mtricas num ambiente de avaliao do mundo real frequentemente ausente, sendo que essa avaliao importante
para compreender as situaes em que uma mtrica pode
ser aplicada para identificar reas de possveis melhorias,
para explorar problemas gerais detectadas pelos indicadores
e definir estratgias de soluo geralmente aplicveis. Dessa
forma, pode-se inferir que a falta de uma anlise estrutural da mtrica pode contribuir para a gerao de mtricas
ineficientes ou irreais.
Acredita-se que alm das possveis causas apresentadas at
o momento, a incapacidade de produzir requisitos precisos
(essa impreciso muitas vezes se d pelo motivo de haver muitas
requisies de mudanas de requisitos ao longo do processo de
desenvolvimento do software, o que acarreta na constante falta de
atualizao das mtricas j definidas) e a falta de experincia
em projetos similares, alm da constante evoluo da TI,
podem contribuir para o uso ineficiente quando se pensa
na gerao de mtricas de software.
Alm desses, pode-se apontar a falta de experincia e de conhecimento do profissional em relao a atividades de estimativas e medio e que de fato contribui significativamente para
40
aumento dessa lacuna da engenharia de software. A Tabela 1

mostra, na viso do autor, os atributos e/ou limitaes que
contribuem para a prtica ineficiente em relao a gerao
e uso de mtricas de software e que foram classificados em
organizacional/ambiente e tcnico.
Organizacional/Ambiente
Tcnico
Falta de Experincia do Profissional
Requisitos Imprecisos
Falta de Experincia em Projetos Similares
Falta de Anlise Estrutural da Mtrica
Falta de Conhecimento
Utiliza dados histricos que muitas vezes nem

existem na organizao/projeto.
Evoluo da TI
So Difceis de Aplicar e de Verificar
Tabela 1. Atributos Contribuintes para o Uso Ineficiente de Mtricas de

Software
Com o intuito de avaliar o quo importantes so esses

dados identificados como fatores de contribuio para o
uso ineficiente de mtricas por meio da percepo dos profissionais de TI que lidam com atividades de estimativas
e medio, buscou-se realizar um estudo de campo com
algumas empresas de TI localizadas no Porto Digital em
Recife/PE. O Porto Digital, definido como um Arranjo
Produtivo de Tecnologia da Informao e Comunicao
e Economia Criativa, que est situado no Recife, capital
de Pernambuco, no nordeste brasileiro e que surgiu do
resultado do ambiente de inovao que se consolidou em
Pernambuco, regio atrativa para inovao, instituies,
empresas, universidades e governos fomentaram mudanas
econmicas e sociais.
Sendo assim, um questionamento foi laado: Em sua
opinio, quais os motivos para o uso ineficiente de mtricas
de software pela indstria de TI?. Os dados apresentados
a seguir so dados da pesquisa em formato parcial. At
o momento 20 empresas de TI participaram da pesquisa
respondendo ao questionrio e por meio dessas respostas
ser possvel identificarmos se existe coerncia em relao
aos fatores apontados pela literatura.
As Figuras 1 e 2 apresentam os dados estatsticos obtidos
com a pesquisa de campo. Como pode-se perceber, foram
elencadas como opes de respostas essa pergunta muitos
dos fatores identificados na literatura como contribuintes
para uso ineficiente de mtricas de software. O intuito deste,
foi verificar o quo frequente esses itens so representados
em atividades profissionais de estimativa e medio mal
sucedidas. Nessa questo o respondente pode escolher mais
de uma alternativa como resposta.
Cerca de 13 respondentes, o que representa 23% do total de
respostas, apontaram que os requisitos irreais e/ou imprecisos a principal causa para o uso ineficiente de mtricas. Em
seguida, cerca de 18%, o que representa dez respostas apontam a falta de informao como sendo fator impulsionador do
mal uso de mtricas em projeto de software. A inexperincia
do profissional que trabalha com a elaborao e aplicao de
mtricas apontada por 16% dos respondentes. Esse nmero
en gen haria
representa cerca de nove respostas. J 11% das respostas recebidas, cerca de seis respondentes, apontam a fator relacionado
a falta de histrico de mtricas de projetos j finalizados.
9% dos respondentes confirmam que muitas vezes a interpretao incorreta de dados contribui para esse gap relacionado
da engenharia software. Entretanto, cerca de 7% de participantes indica que o fator tempo importante e contribui
de forma negativa na criao de mtricas. O fato de ser uma
atividade considerada difcil de aplicar e a inexperincia em
projetos similares foram apontados por 5% cada uma, como
sendo fatores motivadores para esse problema em relao ao
uso de mtricas. Por fim, cerca de 2% apontaram a questo
da falta de uma anlise estrutural do cdigo e falta de comprometimento da gerncia como sendo atributos importantes
para o uso ineficiente de mtricas de
software. 2% dos respondentes apontaram a opo Outros, porm no
especificaram quais seriam esses
outros motivos.
Pode-se afirmar que a ocorrncia de requisitos imprecisos ou

irreais, a inexperincia do profissional e a falta de informao
so fatores-chave para essa lacuna na engenharia de software.
Tambm percebe-se que no so fatores complicados de serem
resolvidos. Para isso, uma boa metodologia de elicitao e
comunicao de requisitos deve ser seguida, alm de investimentos em capacitao dos profissionais que devem lidar
diretamente com estimativas e medio.
Mtricas de software proporcionam diversas vantagens para
quem as usa, entretanto deve-se ressaltar que mesmo possibilitando diversas vantagens, essa abordagem oferece algumas
limitaes.
Atravs de uma anlise realizada, foi possvel inferir que muitas dessas limitaes podem ser fatores que contribuem para
Reflexo
Ser que podemos responder ao
questionamento central de artigo
baseado nos dados apresentados at
o momento? Mtricas de Software
podem ser consideradas um problema ou uma soluo para quem
as usam?
De acordo com os dados obtidos
na literatura e confirmados com o
estudo de campo realizado na indstria de TI, percebe-se que mtricas
de software uma soluo vivel e
organizada de se ter em um projeto,
pois ajuda na avaliao da capacidade produtiva dos envolvidos no
projeto, na elaborao de especificaes de qualidade de software,
validao e verificao de requisitos,
tomada de deciso e em uma das
atividades mais importantes dentro
do gerenciamento de projetos - o
planejamento.
Entretanto, sabe-se que as atividades de medio e estimativas
no so realizadas corretamente
pela indstria de TI e isso contribui
para que a aplicao de mtricas de
software deixem de ser soluo para
passar a ser um problema, pois estimativas mal sucedidas contribuem
para atrasos no cronograma, o que
culminam em excessos oramentais
e que no final termina em estresse e
insatisfao por parte do cliente.
Figura 1. Porcentagem de Respostas
Figura 2. Nmero de Respostas por Item
41
que estimativas e mtricas sejam feitas de forma ineficiente.

Algumas caractersticas que foram identificadas compreendem
a falta de uma anlise estrutural da mtrica, a dificuldade de
aplicao, o fato de ser um trabalho dispendioso e usam dados
histricos e empricos e que nem sempre esto disponveis
dentro da organizao e/ou projeto, alm da falta de conhecimento e experincia do usurio e requisitos inconsistentes e/
ou imprecisos. Essas limitaes podem sim, contribuir para
a incapacidade da indstria de TI em fazer um bom uso de
mtricas de software.
Foi possvel identificar que muitos dos fatores identificados
na literatura foram apontados por profissionais de TI que esto
ligados diretamente a atividades de engenharia de software e
que fatores como requisitos imprecisos ou irreais, a inexperincia do profissional e a falta de informao so fatores-chave
para essa lacuna na engenharia de software.

Links:
[1] BOUWERS, Eric; DEURSEN, Arie Van; VISSER, Joost. Evaluating Usefulness
of Software Metrics - an Industrial Experience Report -.Software Engineering
Research Group, Department of Software Technology, Faculty of Electrical
Engineering, Mathematics and Computer Science, Delft University of
Technology, 2013.
[2] CURTIS, Bill; SAPPIDI, Jay; SUBRAMANYAM, Jitendra. Measuring the Structural Quality of Business Applications. 2011 Agile Conference, 2011b.
[3] FENTON, Norman E; NEIL, Martin. Software Metrics: A roadmap. ICSE
00Proceedings of the Conference on The Future of Software Engineering,
2000.
[4] GOODMAN, Paul. Practical Implementation of Software Metrics, McGraw
Hill, London, 1993.
[5] JOHARI, Kalpana; KAUR, Arvinder. Effect of software evolution on software metrics: An open source case study. ACM SIGSOFT Software Engineering
Notes, 2011.
[6] MOLKKEN, Kjetil; JRGENSEN, Magne; A Review of Surveys on Software
Effort Estimation. Proceedings of the 2003 International Symposium on
Empirical Software Engineering, ISESE 03, IEEE Computer Society, pp.223230, 2003..
[7] SINGH, Gurdev; SINGH, Dilbag; SINGH, Vkram. A Study of Software Metrics.
IJCEM International Journal of Computational Engineering & Management,
Vol. 11, January 2011.
[8] SINGH, Ram; BHAGAT, Avinash; KUMAR, Navdeep. Generalization of
Software Metrics on Software as a Service (SaaS). International Conference
on Computing Sciences, 2012.
42
Engenharia
Casos de Teste: Aprimore seus casos e

procedimentos de teste
Conhea algumas boas prticas e torne seus testes mais eficazes
Cenrio:
Este artigo do
tipo mentoring
saiba mais: www.devmedia.com.br/
mentoring-saibamais
Q
Arilo Claudio Dias Neto
arilo@icomp.ufam.edu.br
Mestre e Doutor em Engenharia de Sistemas e Computao pela Universidade

Federal do Rio de Janeiro (COPPE/UFRJ).
Possui 10 anos de experincia na rea
de Engenharia de Software. Atualmente
professor do Instituto de Computao
da Universidade Federal do Amazonas
(IComp/UFAM). Lidera o Grupo de Pesquisa
em Experimentao e Teste de Software
(ExperTS) da UFAM. Possui o certificado
de Implementador do Modelo MR-MPS.
Possui a certificao internacional ISTQB
Certified Tester.
ualquer profissional da rea

de teste de software possivelmente conhece e/ou j precisou
especificar casos e/ou procedimentos
de teste.
Segundo Craig e Jaskiel (2002), estes
artefatos do processo de teste de software podem ser definidos da seguinte
forma:
Caso de Teste: descreve uma condio
particular a ser testada e composto por
valores de entrada, restries para a sua
execuo e um resultado ou comportamento esperado.
Procedimento de Teste: uma descrio
dos passos necessrios para executar um
caso (ou um grupo de casos) de teste.
Casos de teste so elementos essenciais para o

sucesso das atividades de teste em um projeto
de software. So eles que definem as entradas a
serem informadas pelo testador (manualmente
ou com apoio ferramental) e os resultados
esperados a partir desta ao. Assim, eles nos
permitem medir o quanto o software est sendo testado. J um procedimento de teste define
os passos/sequncia necessrios para executar
os casos. Estes visam apoiar na customizao do
esforo de teste em um projeto. Neste artigo,
sero discutidas estratgias para melhor especificao de casos e procedimentos de teste em
projetos de software. Para isso, ser utilizado
um exemplo simples e comum de ser encontrado em sistemas de informao, um formulrio
de cadastro de venda de produtos online com
diversas regras de negcio para validao dos
dados preenchidos, e realizaremos a especificao dos casos e procedimentos de teste de forma a torn-la mais completa e objetiva, apoiando assim testes manuais e automticos.
Aqueles com um pouco mais de experincia profissional devem perceber que

uma das dificuldades enfrentadas na
atividade de teste a especificao dos
43
casos e procedimentos de testes, no apenas pela dificuldade

natural exigida pela tarefa, mas pelas variaes de formato
de descrio destes artefatos em diferentes locais. Apesar de
existir um padro internacional para a especificao de casos
e procedimentos de teste publicado no padro IEEE-Std-829
(roteiro de documentos para a atividade de teste em geral, no
apenas casos e procedimentos de teste, cuja verso mais atual
foi publicado em 2008), este padro em geral serve apenas como
um roteiro e normalmente customizado pelas empresas, em
certas ocasies de forma correta, porm em outras, de forma
indevida.
Na verdade, o padro IEEE-Std-829 foi proposto exatamente
com o intuito de servir como base para que empresas de software pudessem definir o seu roteiro de documentos para as
atividades de teste de software. Cada organizao possui suas
especificidades e isso precisa ser refletido no roteiro utilizado
para documentar suas atividades de teste. Assim, se um determinado formato funciona adequadamente para a empresa X,
por que ele contm o conjunto de informaes necessrias para
que os demais membros da equipe de teste desempenhem de
forma satisfatria suas atividades. Contudo, no h garantia
de que mesmo este formato funcionando adequadamente em
uma empresa, ele possa ser utilizado de forma satisfatria
por outra com caractersticas ou perfil diferentes. Maiores
ou menores nveis de detalhamento na descrio podem ser
necessrios.
Apesar de no existir um padro universal ou um consenso
entre empresas de software no que diz respeito especificao,
um conjunto de boas prticas tem sido estabelecido ao longo
dos anos e que, se consideradas, podem contribuir positivamente para que a especificao dos casos e procedimento de
teste seja realizada de forma mais satisfatria. Neste contexto,
satisfatria significaria poder ser utilizada por outros membros
da equipe de teste (analistas de teste ou testadores, por exemplo) sem a necessidade de novas intervenes na especificao
para que ela possa ser melhor compreendida.
Neste artigo, partiremos de um caso de uso simples para
realizar a especificao de casos e procedimentos de teste
para um formulrio de compra online de produtos. Ao final,
teremos uma especificao bem definida e que ir considerar
vrias das prticas que tm sido adotadas por equipes de teste
de software.
Cenrio utilizado
Para ilustrar o uso de boas prticas na descrio de casos e
procedimentos de teste, partiremos do caso de uso Comprar
Produto, apresentado na Tabela 1. Ele est especificado de
acordo com o formato de descrio de casos de uso apresentado
no artigo Especificando casos de uso eficazes publicado na
edio 66 da ES Magazine.
A partir deste caso de uso, testes funcionais podem ser realizados. O processo para construo de testes funcionais a partir
de casos de uso j foi explorado no artigo Automatizando a
gerao e execuo de testes a partir de casos de uso publicado na edio 80 da SQL Magazine.
44
Objetivo:
Atores:
Condio de
Entrada
Permitir que produtos sejam comprados do sistema.

Funcionrio
O ator seleciona a opo Comprar Produto
1. O sistema apresenta o formulrio de compra [RN1]

2. O sistema apresenta ao final as opes Comprar e Cancelar
3. O ator informa os dados da compra e seleciona a opo Comprar [A1]
4. O sistema valida a compra [A2][RN2][RN3]
5. O sistema confirma a compra, debitando a quantidade do produto do
Fluxo Principal: estoque
6. O sistema apresenta ao final o valor total da compra e mensagem de compra
realizada com sucesso, alm das opes Nova Compra e Finalizar
7. O ator seleciona a opo Finalizar [A3]
8. O sistema retorna para a tela inicial
9. O caso de uso encerrado
[A1] O ator seleciona a opo Cancelar
1. O sistema retorna para a tela inicial
2. O caso de uso encerrado
Fluxo
[A2] Compra invlida
Alternativo: 1. O sistema exibe mensagem com os erros cometidos
2. O sistema retorna ao passo 2 do fluxo principal
[A2] O ator seleciona a opo Nova Compra
1. O sistema retorna ao passo 1 do fluxo principal
[RN1] So exibidos os campos Cdigo do Produto e Quantidade, ambos
obrigatrios.
Regras de
[RN2] A compra s pode ser confirmada se existir quantidade suficiente do
negcio:
produto escolhido no estoque do sistema.
[RN3] A quantidade a ser comprada deve ser maior que 0 e menor que 5.
Tabela 1. Caso de uso Comprar Produto
Boas prticas aplicadas especificaes de casos e

procedimentos de teste
Para chegarmos ao conjunto de boas prticas relacionadas
especificao de casos e procedimentos de teste, foram analisadas situaes comuns cometidas por profissionais da rea de
teste de software. Algumas destas situaes dificultam, mas
no inviabilizam, o projeto e execuo dos testes. Outras so
impeditivas e no permitem que os testes sejam executados
sem qualquer interveno por parte do analista de teste/testador ao profissional responsvel por tal especificao, o que
prejudica o andamento e sucesso dos testes em um projeto
de software.
Nesta seo sero compartilhadas algumas dicas e boas prticas sobre como especificar casos e procedimentos de teste.
PRTICA 1: Separao de casos e procedimentos de teste
comum em empresas de software o hbito de integrar casos
e procedimentos de teste em um nico artefato (muitas vezes
chamados ainda de casos de teste). Estes artefatos possuem
objetivos distintos. Um caso de teste descreve uma condio
a ser testada, formado por uma entrada, aes ou eventos a
serem realizados e uma resposta ou comportamento esperados.
Este visa determinar se uma funcionalidade de um software
est funcionando corretamente e deve ser o mais simples
Engenharia de Software Magazine - Casos de Teste: Aprimore seus casos e procedimentos de teste
planejamento
e fcil de ser entendido. J um procedimento de teste seria

simplesmente a ordenao de um grupo de casos de teste a
serem executados. Assim, a separao fsica destes artefatos
pode resultar em algumas vantagens para uma empresa de
software, tais como:
Melhor organizao da sua sute de teste (conjunto de artefatos de teste de um projeto de software).
Possibilidade maior de reutilizao de artefatos de teste em
projetos futuros, visto que os artefatos podem, individualmente, serem aproveitados com mais facilidade sem precisar
de adaptaes.
Maior facilidade para implantar estratgias de automao de
testes, pois os scripts a serem implementados, que caracterizam
os procedimentos de teste, podem ser reaproveitados para
diferentes casos de teste, reduzindo o esforo da sua criao.
Facilidade para gesto dos testes, permitindo a distribuio de
esforos entre membros da equipe de teste e separao de responsabilidades, sem criar uma dependncia direta entre as tarefas.
A partir desta deciso de separar casos e procedimentos de
teste, j podemos pensar em quais seriam os testes para nosso
estudo de caso (compra de produto online). Aplicando o critrio de particionamento por classes de equivalncia, podemos
identificar os seguintes casos de teste:
Testes de situao de falha:
- CT1: Cdigo do produto e quantidade no preenchidos.
- CT2: Cdigo do produto preenchido, mas inexistente.
- CT3: Quantidade a ser vendida fora do limite 1-4.
- CT4: Quantidade a ser vendida no limite, mas superior
quantidade do produto em estoque.
Testes de situao de sucesso:
- CT5: Cdigo do produto existente e quantidade a ser vendida entre 1-4 e inferior ou igual quantidade em estoque.
Como procedimento, assumindo que a interface do software

permite testar sequncias de teste de situao de falha sem finalizar o cenrio de uso (isso pode ser observado na descrio dos
passos do caso de uso da Tabela 1), apenas um procedimento
de teste seria necessrio, ordenando a execuo dos testes da
seguinte forma: primeiramente executa-se os testes de situao
de falha (ex: CT1, CT2, CT3 e CT4) para em seguida executar o
caso de teste de situao de sucesso (CT5).
O padro IEEE-Std-829 descreve um roteiro para os artefatos
caso de teste e procedimento de teste. Os itens que compem
cada roteiro esto apresentados nas Tabelas 2 e 3.
Esta estrutura de caso e procedimento de teste resulta em
outras boas prticas a serem implementadas durante a especificao dos testes, conforme descrito a seguir.
PRTICA 2: Definio dos requisitos para execuo dos
casos/procedimentos de teste
Em geral, casos e procedimentos de teste devem ser executados dentro de um contexto mais amplo de utilizao de um
software. Este cenrio resulta na necessidade de se definir os
requisitos necessrios para que estes sejam executados, e eles
so diferentes para cada artefato.
Os requisitos de um caso de teste se referem ao que se precisa
como ambiente de teste para a sua execuo individual, incluindo tipo de hardware ou software especfico ou alguma configurao do sistema para atender ao objetivo do caso de teste. No
caso do sistema de compra de produtos, os casos de teste listados
na seo anterior podem ter requisitos de hardware e software
em comum (ex: SO Windows), porm cada caso de teste possui
requisitos individuais, conforme listado a seguir:
CT1: nenhum requisito individual.
CT2: o cdigo do produto informado NO pode existir na
base de produtos.
Item
Descrio
ID do Caso de Teste
Identificador que caracteriza unicamente o caso de teste.
Descrio
Descrio a respeito do que o caso de teste est avaliando.
Item a ser testado
Indicao do item (funcionalidade, unidade, mdulo, componente) do sistema a ser testado pelo caso de teste.
Caractersticas a serem testadas

Entradas
Resultados e Comportamentos
esperados
Indicao dos atributos de qualidade do sistema que sero avaliados pelo caso de teste (ex: funcionalidade, desempenho, segurana, portabilidade, dentre outros).
Entradas requeridas para a execuo do caso de teste, incluindo no apenas elementos de interface, mas entradas providas internamente pelo sistema. Devem ser
especificados a varivel, seu tipo e valor a ser usado na execuo do caso de teste.
Sadas esperadas aps a execuo do caso de teste, incluindo resultados de interface ou internos do sistema (ex: mensagens ou atualizao de valores) e
comportamentos (ex: tempos de resposta, estado atual do sistema).
Necessidades do Ambiente de teste Especificar as necessidades de hardware, software, configurao do sistema ou outras relevantes para a execuo do caso de teste.
Tabela 2. Roteiro de Caso de Teste segundo o padro IEEE-Std-829 (2008)
Item
ID do Procedimento de Teste
Objetivo
Descrio
Identificador que caracteriza unicamente o procedimento de teste.
Descrever o objetivo deste procedimento de teste em relao aos casos de teste que so executados por ele.
Requisitos
Identificar qualquer requisito especial que necessrio para a execuo deste procedimento de teste. Isso pode incluir procedimentos pr-requisitos, requisitos de
habilidade/perfil necessrio para o responsvel pela sua execuo e requisitos especiais do ambiente.
Passos
Descrever, de forma ordenada, os passos a serem seguidos durante a execuo dos testes, indicando em cada passo qual o caso de teste associado, quando pertinente.
Tabela 3. Roteiro de Procedimento de Teste segundo o padro IEEE-Std-829 (2008)
45
CT3: deve ser configurado um produto com qualquer quantidade em estoque.

CT4: deve ser configurado um produto com quantidade
disponvel em estoque inferior a 4.
CT5: deve ser configurado um outro produto com quantidade
disponvel em estoque superior a 4.
Em geral esta configurao deve ser preparada pela equipe de desenvolvimento em uma base especfica para as atividades de teste
do software, que fora inicialmente zerada, evitando assim dados
com problemas de integridade afetando o resultado dos testes.
Os requisitos de um procedimento de teste se referem ao que
se precisa no software, em geral como condio, para realizar
a execuo do procedimento de teste. No caso do sistema de
compra de produtos, dois requisitos podem ser definidos para a
execuo do procedimento de teste, conforme listado a seguir:
O usurio precisa estar autenticado no sistema.
O usurio deve estar na funcionalidade Comprar Produtos
para que os testes sejam iniciados.
Esta definio dos requisitos e condies importante para
que os procedimentos de teste possam ser executados em sequncia, sem resultar em esforo adicional para os testadores.
Assim, por exemplo, os testadores poderiam iniciar a execuo
dos procedimentos pelo caso de uso de autenticao de usurio
no sistema, e uma vez aprovado, em sequncia passariam para
os testes da compra de produtos, sem precisar refazer todos
os passos desde a sua autenticao no sistema.
PRTICA 3: Instanciao e definio de valores a serem
atribudos s entradas dos casos de teste
46
Uma limitao comum observada nos casos de teste se refere

ao valor a ser fornecido nas entradas do sistema. comum analistas de teste no informarem instncias de valores em seus
casos de testes, preenchendo apenas com descries ambguas
sobre possveis valores a serem usados nos testes. Abaixo so
apresentados dois cenrios, um de forma inadequada e outro
de forma adequada para especificao dos valores de entrada
para o caso de teste CT5 do sistema de compra de produtos.
Forma inadequada:
- Cdigo do produto = qualquer cdigo existente na base
do sistema.
- Quantidade = menor que cinco e inferior quantidade
atual do produto.
Forma adequada. Primeiramente preciso retornar aos
requisitos definidos pelo caso de teste. Neste caso, definiu-se
como requisito do caso de teste um cdigo de produto vlido
PR003, que custa R$ 5,00 e que possui dez itens em estoque:
- Cdigo do produto = PR003 do tipo String.
- Quantidade = 3.
PRTICA 4: Definio de resultados e comportamentos
esperados para os casos de teste
De forma similar ao que ocorre na definio das entradas, a
definio dos resultados e comportamentos esperados aps a
execuo de um caso de teste em geral possui limitaes no
que se refere, principalmente, completude dos resultados/
comportamentos esperados. comum analistas de teste informarem apenas resultados/comportamentos aparentes na
interface grfica do software, sem levar em resultados/comportamentos internos que devem ser atingidos aps a execuo
do caso de teste. Abaixo so apresentados dois cenrios, um
planejamento
Item
Descrio
ID do Caso de Teste
CT01
Descriao
Testa valores no preenchidos nos campos
Item a ser testado
Caso de Uso Comprar Produto
Funcionalidade
Entradas
Resultados e Comportamentos esperados
Necessidades do Ambiente de teste
Cdigo do Produto: (vazio)

Quantidade: (vazio)
Mensagem na tela: Compra Invlida
Cdigo de Produto Invlido;
Quantidade Invlida
Hardware: PC com SO Windows 7
Software: Browser Firefox
Item
Descrio
ID do Caso de Teste
CT02
Item a ser testado
Descrio
Testa cdigo de produto inexiste
Funcionalidade
Entradas
Cdigo do Produto:PR7872
Quantidade: 3
Cdigo de Produto Inexistente;
Banco de Dados: no deve existir um produto com cdigo PR7872.
Item
Descrio
ID do Caso de Teste
CT03
Descrio
Testa a quantidade invlida
Item a ser testado
Funcionalidade
Entradas
Cdigo do Produto: PR003

Quantidade: 6
Quantidade Invlida
Banco de Dados: deve existir um produto com cdigo PR003.
Item
Descrio
ID do Caso de Teste
CT04
Descrio
Testa a quantidade alm do disponvel em estoque
Item a ser testado
Funcionalidade
Entradas

Quantidade: 3
Quantidade Invlida
Banco de Dados: deve existir um produto com cdigo PR002 com 2 itens em estoque.
Tabela 4. Casos de Teste para o caso de uso Comprar de Produtos
47
Item
Descrio
ID do Caso de Teste
CT05
Descrio
Testa uma compra vlida
Item a ser testado
Funcionalidade
Entradas

Quantidade: 3
Mensagem na tela: Compra Realizada com Sucesso
Mensagem na tela: Valor total = R$ 15,00
Nova quantidade do produto em estoque = 7
Banco de Dados: deve existir um produto com cdigo PR003 que vale R$ 5,00 e com 10 itens em estoque.
Continuao: Tabela 4. Casos de Teste para o caso de uso Comprar de Produtos

Item
Descrio
ID do Procedimento de Teste
PT01
Objetivo
Realizar testes funcionais no caso de uso Comprar Produto
Requisitos
Estar autenticado no sistema.

Estar acessando a funcionalidade Comprar Produtos.
Passos
Tabela 5. Procedimento de Teste para o caso de uso Comprar Produto
de forma incompleta e outro de forma mais completa para

especificao dos resultados/comportamentos esperados para
o caso de teste CT5 do sistema de compra de produtos a partir
da entrada informada na seo anterior.
Forma incompleta:
- Resultado esperado: mensagem na tela de Compra realizada com sucesso.
Forma completa, considerando o teste com o cenrio do CT5
descrito anteriormente (Cdigo PR003 e quantidade 3):
- Resultado esperado 1: mensagem na tela de Compra
realizada com sucesso.
- Resultado esperado 2: valor total da compra = R$ 15,00
(3 x R$ 5,00).
- Resultado esperado 3: nova quantidade em estoque do
produto = 7 (10 3).
Exemplo de casos e procedimentos de teste

A partir das boas prticas descritas anteriormente, podemos chegar aos casos e procedimentos de teste descritos nas
Tabelas 4 e 5 para o sistema de compra de produtos.
A descrio de casos e procedimento de teste uma atividade
que resulta em um grande impacto nas atividades de teste em
geral. Este fato torna esta tarefa muito importante. Assim, ela
deve ser planejada com antecedncia e deve ser feita de forma
bem organizada. O profissional que ser o responsvel por esta
especificao deve sempre lembrar que esta atividade no
feita para ele/ela, mas sim para toda uma equipe, incluindo
48
outros testadores e desenvolvedores, que podero ser afetados

por este trabalho.
Assim, devida importncia deve ser dada a esta atividade.
Casos e Procedimentos de Teste devem ser entendveis por
todos os profissionais que os utilizam, sem ambiguidade e
com facilidade para manuteno destes artefatos. Este artigo
apresentou um conjunto de boas prticas que podem aprimorar
a qualidade da descrio de casos e procedimentos de teste.
importante estar atento ao fato de que estas prticas podem
ou no ser adequadas s necessidades de sua organizao.
Alm disso, esta forma de descrio de casos e procedimentos
de teste no requer o uso de alguma ferramenta especfica. Em
geral, as ferramentas que apoiam a modelagem de casos/procedimentos de teste permitem uma adaptao das informaes
necessrias, facilitando assim o uso de tais boas prticas. Elas
podem ser aplicadas desde ferramentas mais sofisticadas de
apoio a testes at editores de texto ou planilhas eletrnicas.
importante lembrar tambm que o conjunto apresentado
no e nem pretende ser uma lista final de boas prticas. Outras certamente existem e quase sempre so provenientes da
experincia de analistas nos projetos que participa.
Links:
1. CRAIG, R.D., JASKIEL, S. P., Systematic Software Testing, Artech House
Publishers, Boston, 2002.
2. IEEE Standard 829-2008: Standard for Software and System Test Documentation (Revision of IEEE Std 829-1998).

Desenvolvimento
Nesta seo voc encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software
SMarty Check: Conhecendo a Tcnica de

Inspeo de software
Fique por dentro:
L
Edson A. Oliveira Junior
edson@din.uem.br
Professor de Engenharia de Software na

Universidade Estadual de Maring (UEM).
Doutor em Cincia da Computao pelo
Instituto de Cincias Matemticas e de
Computao (ICMC) da Universidade de
So Paulo (USP). Principais temas de pesquisa: linha de processo de software, linha
de produto de software, arquitetura de software e avaliao, mtricas, engenharia de
software experimental, modelos e metamodelos UML. Possui as certificaes Java:
SCJA, SCJP, SCJD, SCWCD e SCBCD.
Diogo Cassio Pereira

diogopereiramga@gmail.com
Graduando em Informtica pela Universidade Estadual de Maring.
inha de Produtos de Software

(LPS) compreende um conjunto
de produtos que juntos se destinam a um segmento de mercado especfico ou uma misso particular. A ideia de
LPS explorar as caractersticas comuns
que os produtos similares possuem, para
agilizar as suas construes.
Entretanto, o conceito de LPS relativamente novo e pode ser considerado
uma das mais promissoras abordagens
de reuso de software que foi amplamente
adotada pela indstria. O aumento pelo
interesse em LPS se deve principalmente
ao fato de as organizaes perceberem
que podem se beneficiar muito mais com
um reuso de software mais planejado e
direcionado a um domnio especfico,
ao invs de continuar reusando componentes de software individuais de forma
oportunista, acidental e adaptando-os a
inmeras situaes.
Atualmente, grande parte das organizaes utiliza uma quantidade enorme
Neste artigo ser apresentado um estudo sobre

tcnicas de inspeo de software e do que se
trata a abordagem SMarty. Tambm ser apresentada a tcnica SMartyCheck, demonstrando
sua aplicao com exemplos em linhas de produto de software baseadas em UML. Esse tema
til para gerentes de qualidade de software,
pesquisadores da rea e estudantes e engenheiros interessados em melhorar a qualidade
do produto e do processo de software alinhados tcnica linha de produto de software.
de informaes e depende de aplicaes

de software para desenvolver seus trabalhos diante de um mercado competitivo
que exige da empresa a informao para
conduzir seus negcios. Para isso, as empresas devem possuir sistemas de informao adequados s mudanas impostas
pelo mercado. O uso dessas informaes
uma atividade de grande importncia,
pois somente com um software desenvolvido a partir das necessidades reais
de uma empresa, pode-se garantir que
as organizaes no sero prejudicadas
pela falta de informaes.
49
Para acompanhar essas exigncias, primordial que os

sistemas em processo de desenvolvimento utilizem tcnicas
para inspecionar o produto que est sendo desenvolvido. Para
isso, importante gerar uma boa documentao ao longo do
ciclo de vida do sistema. Faz-se necessrio avaliar o produto
do software, se os artefatos especificados esto de acordo com
as necessidades e expectativas do usurio e da organizao e
em conformidade com os produtos finais.
Inspeo de software uma forma de reviso eficiente e
frequentemente utilizada pela indstria. A literatura aponta
que a comunidade de LPS vem buscando aplicar os conceitos j
estabelecidos de inspeo de software em modelos de variabilidade. A abordagem SMarty vem sendo amplamente utilizada
para gerenciar variabilidades em projetos de LPS baseadas em
UML. Assim, uma tcnica de inspeo de software que toma
como base SMarty se torna uma ferramenta poderosa na busca
por defeitos em artefatos que contem variabilidade em LPS
como, por exemplo, em modelos de casos de uso.
Inspeo de Software
A inspeo uma tcnica que contribui para garantir a qualidade do produto de software. Todas as etapas do processo de
desenvolvimento de software so suscetveis incorporao de
defeitos, que podem ser detectados previamente pela inspeo
e posteriormente removidos.
importante destacar que quanto mais cedo esses defeitos
forem removidos, menor ser o custo de desenvolvimento e
manuteno do produto. Experincias tm comprovado que a
inspeo, quando realizada no incio do desenvolvimento do
software, leva deteco de 60% a 90% dos defeitos potenciais
em um projeto de software.
Para isso, o processo de Garantia da Qualidade utiliza-se de
atividades de verificao, validao com o intuito de encontrar
defeitos em todas as etapas do desenvolvimento. Essas atividades so muito importantes, pois cuidam de analisar diversos
pontos do processo de desenvolvimento, impedindo que
um defeito se propague para as fases posteriores do projeto.
A Figura 1 mostra que a inspeo de software pode ser aplicada
em diferentes artefatos.
Os conceitos fundamentais de algumas das principais tcnicas de inspeo so:

Verificao e Validao: tcnicas de verificao e validao
so aplicadas aos artefatos de software durante e depois de seu
desenvolvimento para garantir que ele atende sua especificao e fornece as funcionalidades esperadas pelos clientes.
Essas atividades ocorrem durante todo o ciclo de vida do software comeando com revises de requisitos e continuando ao
longo das revises de projeto e das inspees de cdigo at o
teste do produto;
Anlise dinmica: uma tcnica de verificao e validao
muito usada, que consiste em exercitar o programa usando
dados reais processados pelo programa e verificar se as sadas obtidas esto de acordo com as sadas esperadas. Uma
tcnica esttica muito utilizada so os testes de software que
so essenciais para a descoberta de defeitos e a garantia de
qualidade e confiabilidade que s podem ser obtidas com a
execuo do programa;
Anlise esttica: so tcnicas usadas para garantir a qualidade do software que no necessitas de uma verso executvel
do programa. Por esse motivo podem ser utilizadas em todas
as fases do desenvolvimento do software, podendo verificar
tanto o produto quanto o processo de software. Porm, essa
tcnica oferece garantia somente a correspondncia entre um
programa e sua especificao (verificao). Essa tcnica no
demonstra que o software til operacionalmente e no pode
testar propriedades emergentes do software como desempenho
e confiabilidade.
Dentre as tcnicas de verificao, revises so tcnicas amplamente difundidas e que podem ser usadas tanto na anlise
esttica quanto dinmica. Revises fazem parte do conjunto
de atividades de garantia de qualidade de software. Essas
atividades constituem um padro sistemtico e planejado de
aes que so exigidas para garantir a qualidade do software
e que devem ser aplicadas ao longo de todo o processo de
engenharia de software.
Nesse contexto, a reviso de software um filtro para o processo de engenharia de software, pois revises so aplicadas
Figura 1. Inspees de Software em Diferentes Artefatos
50
Engenharia de Software Magazine - SMarty Check: Conhecendo a Tcnica de Inspeo de software
en gen haria
em vrios pontos durante o ciclo de vida do desenvolvimento

de software eliminando defeitos em cada fase antes de passar
para a fase seguinte.
Dentre as tcnicas de reviso, podemos citar: walkthrough,
peer-review, inspeo, tcnicas de leitura de artefato de software, tcnicas de leitura Ad-Hoc, tcnicas de leitura checklist e
tcnicas de leitura baseada em perspectiva.
Atualmente, as tcnicas de inspeo mais adotadas so as
tcnicas de leitura, que contribuem para o aumento da compreenso sobre algum artefato de software. Tal compreenso
deve ser suficiente a ponto de permitir que os inspetores identifiquem tanto as informaes importantes para a execuo de
uma determinada tarefa, como a relao dessas informaes
com o problema de que se est tratando.
Uma dessas tcnicas de leitura bastante utilizada checklist
(lista de verificao), que baseada em uma srie de perguntas (frequentemente questes de sim/no) sobre assuntos do
documento a ser inspecionado. As questes so elaboradas de
acordo com o tipo de documento de software que se pretende
inspecionar. Outras das principais tcnicas de leitura existentes
so: Ad-hoc, Cenrio (LBCe), Stepwise Abstraction (SA), Anlise
de Pontos de Funo (APF), Perspectiva (LBPe) e N-fold.
O checklist uma lista de verificao apresentada como uma
lista de perguntas que devem ser respondidas de forma assertiva por meio de uma nica verificao, um check. fundamental
que cada questo seja clara e autoexplicativa.
Executar um checklist pode ser um fator chave para dar aceite
ou no no recebimento de um projeto. Para isso, fundamental
que um checklist seja bem realista, baseado no histrico ou na
experincia, como segue:
Checklist Baseado no Histrico: elaborado por meio de um
levantamento dos tipos de defeitos registrados nas ltimas
iteraes, ou projetos. Devero estar presentes no checklist os
itens que apresentam o maior nmero de defeitos;
Checklist Baseado na Experincia: elaborado por meio da
experincia do profissional responsvel pela execuo das
tarefas. Devero ser levados em conta os critrios de risco e
propriedade do projeto.
A abordagem SMarty
A abordagem Stereotype-based Management of Variability (SMarty) apoiada por um perfil UML, o SMartyProfile e um processo
sistemtico para o gerenciamento de variabilidades, o SMartyProcess. Os principais conceitos envolvidos no gerenciamento
de variabilidades em LPS adotados por SMarty so:
Variabilidade, que permite distinguir os diversos membros
de uma linha de produto. No SMartyProfile esse conceito representado pelo esteretipo <<variability>> que uma extenso
da metaclasse Comment;
Ponto de Variao, que indica um local especfico de um
artefato onde ocorre a variao. No SMartyProfile esse conceito
representado pelo esteretipo <<variationPoint>>;
Variante, que um artefato que sofre a variao. No
SMartyProfile esse conceito representado pelo esteretipo
<<variant>>;
Restrio entre Variantes, que define os relacionamentos

entre duas ou mais variantes para que seja possvel resolver
um ponto de variao ou uma variabilidade.
O SMartyProfile contm um conjunto de esteretipos e metaatributos para representar variabilidade em modelos UML
de LPS. Basicamente, o SMartyProfile usa a notao UML e
o seu mecanismo de profiling para fornecer uma extenso do
metamodelo padro da UML e permitir a representao grfica
dos conceitos de variabilidade. Atualmente, o SMartyProfile
possui suporte a modelos de casos de uso, classes, atividades,
componentes e sequncia.
Os esteretipos que compem o SMartyProfile so:
<<variability>> que representa o conceito de variabilidade
em LPS e uma extenso da metaclasse Comment. Isso significa que esse esse esteretipo pode ser aplicado somente em
notas UML;
<<variationPoint>> que representa o conceito Ponto de Variao e uma extenso das metaclasses UML Actor, UseCase,
Interface e Class. Isso significa que esse esteretipo pode ser
aplicado somente a atores, casos de uso, interfaces e classes;
<<variant>> que representa o conceito Variante e uma extenso abstrata das meta-classes UML Actor, UseCase, Interface
e Class. Por ser abstrato, esse esteretipo no pode ser aplicado
em nenhum elemento UML, porm, suas especializaes no
abstratas podem ser aplicadas em atores, casos de uso, interfaces e classes;
<<mandatory>> que representa variantes obrigatrias que
devem ser parte de todos os produtos derivados de uma linha
de produto;
<<optional>> que representa variantes que podem ser
selecionadas para resolver um ponto de variao ou uma
variabilidade;
<<alternative_OR>> que representa variantes em que diferentes combinaes podem resolver pontos de variaes ou
variabilidades;
<<alternative_XOR>> que representa variantes em que apenas uma delas pode ser selecionada para resolver um ponto
de variao ou uma variabilidade;
<<mutex>> representa o conceito de restrio de variante
em linhas de produto e uma relao mutuamente exclusiva
entre duas variantes. Isso significa que quando uma variante
selecionada outra variante no pode ser selecionada para
um mesmo produto;
<<requires>> representa o conceito em que a seleo de variante requer a seleo de outra para um mesmo produto;
<<variable>> que indica que um determinado elemento
composto por outros elementos que possuem algum tipo de
variabilidade como, por exemplo, um componente que formado por classes que possuem variabilidade.
A tcnica SMartyCheck
A princpio, SMartyCheck concentra-se em modelos SMarty
de casos de uso, por serem os modelos mais abstratos de uma
LPS baseada em UML. SMartyCheck aplicada para cada
51
modelo de casos de uso dos produtos especficos gerados a

partir de uma LPS. Assim, possvel identificar defeitos que
tm como consequncia a especificao de produtos especficos
inconsistentes de uma LPS. Exemplos de aplicao da tcnica
sero apresentados a seguir.
O aumento pelo interesse em LPS na indstria e a efetividade de muitas tcnicas de inspeo justificam a proposta
desta tcnica. Checklist a forma inicial escolhida por ser uma
maneira simples de inspecionar software, alm de intuitiva
e de fcil compreenso. J a relao da tcnica proposta com
SMarty tem como objetivo tirar proveito das diversas vantagens j conhecidas de tal abordagem, como a modelagem clara
e objetiva de variabilidades, alm de ser baseada na notao
padro UML.
A tcnica SMartyCheck composta de um checklist que foi
criado de acordo com os principais defeitos comuns cometidos na modelagem de casos de uso de acordo com SMarty.
O checklist formado de questes assertivas que guiam o usurio em como identificar defeitos em casos de uso.
SMartyCheck aplicado a Produtos Especficos da LPS

AGM
A LPS AGM possui um conjunto completo de documentos e
modelos UML, bem como um conjunto de classes testadas e
cdigo fonte para trs jogos diferentes, sendo eles: Pong, Bowling
e Brickles. Apesar de no ser uma LPS comercial, a AGM tem
sido usada para ilustrar os conceitos de LPS.
Os artefatos essenciais da AGM so: o modelo de caractersticas, o modelo de classes, a arquitetura lgica de componentes
e o modelo de casos de uso. Esse ltimo o mais importante
para analisarmos neste artigo, pois nele que aplicada
SMartyCheck.
A Figura 2 apresenta o modelo de casos de uso da AGM
segundo SMarty. Esse o modelo usado para a gerao dos
produtos especficos da AGM para o exemplo em questo. Tal
modelo est correto de acordo com as diretrizes do SMarty.
Considere para este exemplo os produtos gerados e apresentados nas Figuras 3, 4 e 5.
Checklist para a Aplicao do SMartyCheck

A tcnica SMartyCheck considera dois tipos de defeitos:
Redundncia: o modelo de casos de uso de um produto
especfico apresenta redundncia quando gera casos de usos
com a mesma especificao;
Inconsistncia: o modelo de casos de uso de um produto
especfico apresenta inconsistncia quando informaes no
correspondem com o modelo de caso de uso da LPS.
A Tabela 1 apresenta os itens do checklist da tcnica SMartyCheck de acordo com os tipos de defeitos.
Tipo de
Defeito
Item do Checklist
Redundncia
R.1 Existem dois ou mais casos de uso que representam exatamente a mesma
especificao?
I.1 Existe algum caso de uso na LPS com <<mandatory>> que no esteja
presente no produto especfico?
Figura 2. Modelo de Variabilidade para Casos de Uso da AGM de acordo

com SMarty
I.2 Existe algum caso de uso na LPS com <<variationPoint>> cujo nmero
de variantes presentes no produto especfico maior que o definido em
maxSelection da variabilidade associada?
I.3 Existe algum caso de uso na LPS com <<variationPoint>> cujo nmero
de variantes presentes no produto especfico menor que o definido em
minSelection da variabilidade associada?
I.4 Existe algum caso de uso no produto especfico que no foi definido no
modelo de casos de uso da LPS?
I.5 Existe algum caso de uso na LPS que exige a seleo de outro
(<<requires>>) e esse outro no est presente no produto especfico?
Inconsistncia I.6 Existe algum caso de uso na LPS que exige a no seleo de outro
(<<mutex>>) e esse outro est presente no produto especfico?
I.7 Existe alguma variabilidade (<<variability>>) presente no produto
especfico cujo meta-atributo bindingTime seja DESIGN_TIME (tempo de
projeto)?
Tabela 1. Checklist da Tcnica SMartyCheck
52
Figura 3. AGM 1 Primeiro Produto
en gen haria
Tipo de
Defeito
Redundncia
Inconsistncia
Item do Checklist
Defeitos Encontrados
R.1 Existem dois ou mais casos de uso que representam exatamente a mesma especificao?
[ X ] No
[ ] Sim
I.1 Existe algum caso de uso estereotipado como <<mandatory>> no modelo de casos uso da LPS que no esteja no produto
O caso de uso Exit Game no est presente no
especfico?
produto.
[ ] No
[ X ] Sim
I.2 Existe algum caso de uso com <<variationPoint>> cujo nmero de variantes no produto especfico maior que o definido em
maxSelection da variabilidade associada?
[ X ] No
[ ] Sim
I.3 Existe algum caso de uso com <<variationPoint>> cujo nmero de variantes no produto especfico menor que o definido
em minSelection da variabilidade associada?
[ X ] No
[ ] Sim
I.4 Existe algum caso de uso no produto especfico que no foi definido no modelo de casos de uso da LPS?
[ X ] No
[ ] Sim
I.5 Existe algum caso de uso que exige a seleo de outro (<<requires>>) e esse outro no est presente no produto especfico?
[ X ] No
[ ] Sim
I.6 Existe algum caso de uso que exige a no seleo de outro (<<mutex>>) e esse outro est presente no produto especfico?
[ X ] No
[ ] Sim
I.7 Existe alguma variabilidade (<<variability>>) presente no modelo de caso de uso do produto especfico cujo meta-atributo
bindingTime seja DESIGN_TIME?
[ X ] No
[ ] Sim
Tabela 2. SMartyCheck Aplicada ao Produto AGM 1
O primeiro produto gerado AGM 1 (Figura 3), possui o

jogo Bowling com as seguintes funcionalidades: instalar o jogo,
salvar o jogo, desinstalar o jogo e selecionar o jogo.
Aplicando SMartyCheck no modelo de casos de uso de AGM 1
so encontrados defeitos conforme a Tabela 2
Na Figura 4 o segundo produto especfico AGM 2 apresenta os casos de uso obrigatrios, Install Game, Save Game,
Exit Game, Uninstall Game e Play Selected Game, e permite ao
usurio verificar a melhor pontuao com o caso de uso Check
Previous Best Score.
Figura 5. AGM 3 Terceiro Produto Gerado
Figura 4. AGM 2 Segundo Produto

so encontrados defeitos, conforme a Tabela 3.
O terceiro produto especfico na Figura 5 AGM 3 permite
salvar e a visualizar a melhor pontuao. Esse produto permite
ter dois jogos, Pong e Brickles.

so encontrados defeitos conforme a Tabela 4.
A reviso dos artefatos produzidos ao longo do processo
de desenvolvimento de software essencial para diminuir o
retrabalho e melhorar a qualidade dos produtos. A inspeo
de software um tipo particular de reviso que pode ser
aplicada a todos os artefatos de software e possui um processo
rigoroso e bem definido de deteco de defeitos. A literatura
existente apresenta vrias tcnicas de inspeo para os mais
diversos domnios. Porm, o uso dessas tcnicas atualmente
53
Tipo de Defeito
Redundncia
Inconsistncia
Item do Checklist
[ X ] No
[ ] Sim
I.1 Existe algum caso de uso estereotipado como <<mandatory>> no modelo de casos uso da LPS que no esteja no
produto especfico?
[ X ] No
[ ] Sim
I.2 Existe algum caso de uso com <<variationPoint>> cujo nmero de variantes no produto especfico maior que o
definido em maxSelection da variabilidade associada?
[ X ] No
[ ] Sim
I.3 Existe algum caso de uso com <<variationPoint>> cujo nmero de variantes no produto especfico menor que o
definido em minSelection da variabilidade associada?
[ ] No
[ X ] Sim
[ X ] No
[ ] Sim
I.5 Existe algum caso de uso que exige a seleo de outro (<<requires>>) e esse outro no est presente no produto
especfico?
[ ] No
[ X ] Sim
I.6 Existe algum caso de uso que exige a no seleo de outro (<<mutex>>) e esse outro est presente no produto
especfico?
[ X ] No
[ ] Sim
I.7 Existe alguma variabilidade (<<variability>>) presente no modelo de caso de uso do produto especfico cujo metaatributo bindingTime seja DESIGN_TIME?
[ X ] No
[ ] Sim
O caso de uso Play Selected Game possui zero variantes,

sendo que deveria possuir pelo menos uma.
O caso de uso Check Previous Best Score exige a seleo do

caso de uso Save Score, que no est presente em AGM 2.

Tipo de Defeito
Redundncia
Item do Checklist
[ X ] No
[ ] Sim
I.1 Existe algum caso de uso estereotipado como <<mandatory>> no modelo de casos uso da LPS que no esteja no produto
especfico?
[ ] No
[ X ] Sim
I.2 Existe algum caso de uso com <<variationPoint>> cujo nmero de variantes no produto especfico maior que o definido
em maxSelection da variabilidade associada?
[ X ] No
[ ] Sim
I.3 Existe algum caso de uso com <<variationPoint>> cujo nmero de variantes no produto especfico menor que o
definido em minSelection da variabilidade associada?
[ X ] No
[ ] Sim
[ X ] No
[ ] Sim
Inconsistncia
I.5 Existe algum caso de uso que exige a seleo de outro (<<requires>>) e esse outro no est presente no produto
especfico?
[ X ] No
[ ] Sim
I.6 Existe algum caso de uso que exige a no seleo de outro (<<mutex>>) e esse outro est presente no produto
especfico?
[ X ] No
[ ] Sim
I.7 Existe alguma variabilidade (<<variability>>) presente no modelo de caso de uso do produto especfico cujo metaatributo bindingTime seja DESIGN_TIME?
[ X ] No
[ ] Sim
54
O caso de uso Install Game no est presente

no produto.
en gen haria
restrito quando da sua aplicao a modelos de variabilidade

de LPS, conforme visto na realizao da reviso sistemtica
apresentada neste artigo.
Este artigo apresentou uma tcnica de inspeo baseada em
checklist para modelos UML de LPS com base na abordagem
SMarty para gerenciamento de variabilidades em LPS, chamada SMartyCheck. Tal tcnica est direcionada, a princpio, a
modelos SMarty de casos de uso, por serem os modelos mais
abstratos de uma LPS. Essa tcnica aplicada para cada modelo
de casos de uso dos produtos especficos gerados a partir de
uma LPS em busca de defeitos a partir de um checklist, por
ser uma maneira simples de inspecionar software, alm de
intuitiva e de fcil compreenso.
O checklist da tcnica SMartyCheck foi criado de acordo com
os principais defeitos comuns encontrados na modelagem de
casos de uso de acordo com SMarty. O checklist considera dois
tipos de defeitos: redundncia e inconsistncia.
Para ilustrar o uso da tcnica na deteco de defeitos, SMartyCheck foi aplicada a LPS AGM. Para aplicar a tcnica foi
necessrio o modelo de variabilidade para casos de uso da LPS
em questo. Assim, foram criados trs produtos especficos
da LPS AGM e aplicada a cada um desses produtos a tcnica
SMartyCheck, buscando possveis defeitos.

Dentre os defeitos encontrados, destacam-se a ausncia de

um ou mais casos de uso obrigatrios, o nmero de variantes
no produto que pode ser diferente do especificado nas variabilidades da LPS e existir no produto casos de uso que no
foram especificados no modelo da LPS.
Links e Referncias:
CUNHA, R.; CONTE, T. U.; ALMEIDA, E. S.; MALDONADO, J. C. A Set of Inspection
Techniques on Software Product Line Models. In: International Conference on
Software Engineering and Knowledge Engineering, 2012. p. 657-662.
FIORI, D. R.; GIMENES, I. M. S.; MALDONADO, J.; OLIVEIRA JUNIOR, E. A. Variability Management in Software Product Line Activity Diagrams. In: International Conference on Distributed Multimedia Systems, 2012. p. 89-94.
OLIVEIRA JUNIOR, E. A.; I. M. S.;MALDONADO, J. C.; MASIERO, P. C.; BARROCA,
L. Systematic Evaluation of Software Product Line Architectures. Journal of
Universal Computer Science, v. 19, p. 25-52, 2013.
OLIVEIRA JUNIOR, E. A. Variabilidade em Linha de Produto de Software: Como
identificar, delimitar e representar variabilidade nos principais modelos UML
de uma linha de produto de software. Engenharia de Software Magazine,
v. 33, p. 71-80, 2011.
OLIVEIRA JUNIOR, E. A.; GIMENES, I. M. S.; MALDONADO, J. C. Systematic
Management of Variability in UML-based Software Product Lines. Journal
of Universal Computer Science, v. 16, p. 2374-2393, 2010.
ROCHA, A. R. C.; MALDONADO, J. C.; WEBER, K. C. Qualidade de Software Teoria e Prtica. So Paulo: Prentice Hall, 2001.
SEI. A Framework for Software Product Line Practice. Online, 2012a.
http://www.sei.cmu.edu/productlines/frame_report/index.html
SHULL, F.J. Developing Techniques for Using Software Documents: A Series of
Empirical Studies. Ph.D. Thesis. University of Maryland, EUA, 1998.
55
Desenvolvimento
Nesta seo voc encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software
Trabalhando com Testes Exploratrios

Ganhando agilidade nas atividades de teste
Fique por dentro:
P
Anne Caroline Noronha
annepnoronha@gmail.com
Ps-graduada em Engenharia de Software

pela Fundaao Centro de Anlise Pesquisa
e Inovao Tecnolgica FUCAPI e formada em Tecnologia em Desenvolvimento de
Software pelo o Centro Universitrio do
Norte UNINORTE. Possui certificao Certified Tester Foundation Level (ISTQB/CTFL)
na rea de Teste de Software.Trabalha no
cargo de Desenvolvedora de Teste no time
de Validao de Produto no Instituto Nokia
de Tecnologia (INdT) na plataforma mobile
e atua ministrando treinamentos na rea
de Teste de Software.
56
ara desenvolver softwares com

qualidade importante que ocorra um planejamento na elaborao
e execuo dos testes durante todo o projeto, sempre levando em considerao
os riscos, custos e o tempo a ser gasto
para estas atividades. Tais requisitos
colaboram para que o ciclo de testes
seja realizado de forma correta com o
objetivo de cobrir a maior rea possvel
do software.
Aliado a isso e com o intuito de ajudar
a realizar a validao do produto, ser
enfatizado no primeiro momento deste
artigo a abordagem de testes exploratrios, a qual muito utilizada durante o
processo de teste. Isso porque os profissionais desta rea sempre investigam
situaes ou caminhos que esto fora do
escopo dos testes que seguem roteiros
pr-estabelecidos. Alm disso, testes exploratrios so uma excelente alternativa
para ganharmos agilidade na realizao
das atividades de teste.
Engenharia de Software Magazine - Trabalhando com Testes Exploratrios
Este artigo descreve a importncia e planejamento da abordagem de testes exploratrios

durante o processo de teste de software. No
decorrer do artigo explicado toda a organizao e planejamento dos testes exploratrios. Este artigo discutir pontos relevantes
sobre esta abordagem durante o projeto com
o intuito de fazer com que profissionais da
rea de qualidade estejam preparados para
executar os testes exploratrios em plataformas. Isso para se atingir um maior nvel de
cobertura na execuo dos testes agregando
qualidade ao software desenvolvido.
Os testes exploratrios so sempre

associados ideia de testes aleatrios
ou desorganizados, cujos resultados
podem acontecer esporadicamente e sem
nenhuma estrutura lgica a respeito do
defeito encontrado. Isto acontece devido
a falta de entendimento da gesto, estrutura e tcnicas deste tipo de teste pelos
profissionais, o que contribui para a no
disseminao deste tipo de abordagem
durante a execuo de um projeto.
Durante o processo de teste de software, os testes exploratrios, se bem
desen volvimento
estruturados e executados, so de extrema importncia para

o projeto, uma vez que contribuem significativamente nos
resultados alcanados. Com este princpio, alm da execuo
dos testes exploratrios em funcionalidades nos aplicativos,
mostraremos no decorrer deste artigo a vinculao desta
abordagem nas plataformas em que so desenvolvidos os
aplicativos, sempre buscando enriquecer, estruturar e aguar o pensamento lgico do testador para o mapeamento de
caminhos de testes ou investigao de defeitos difceis de
serem encontrados.
Testes Exploratrios
Para o melhor entendimento das tcnicas e resultados que
sero abordados nos prximos tpicos, faz-se necessrio o
conhecimento conceitual da abordagem e definio sobre
testes exploratrios.
Esta abordagem, por no ser orientada por script, muitas
vezes confundida com testes ad hoc, o qual comumente
definido como uma abordagem informal e improvisada, onde
no h nenhum planejamento das atividades exercidas.
Segundo James Bach, o teste exploratrio um processo onde
realizada a anlise e a elaborao do projeto, juntamente com
a execuo dos testes. Esta abordagem de teste no baseada
em testes orientados por scripts ou testes com roteiros. Na
verdade, nesse tipo teste o testador elabora seus casos de testes
no decorrer da execuo dos mesmos, ou seja, improvisa os
testes com o objetivo de buscar erros.
Com isso vemos que os testes exploratrios ultrapassam a
ideia de um simples teste ad hoc, pois so baseados em estruturas de aprendizagem contnua e possuem um planejamento
com tcnicas e mtodos para gerenciar esta abordagem durante
a sua execuo, o que gera o entendimento completo das atividades e defeitos gerados durante o processo de teste.
Um testador exploratrio qualificado pode explorar funcionalidades do aplicativo sem restries, podendo diversificar
seus testes de acordo com a resposta de sua execuo. Com base
nisto, podemos vislumbrar que os testes exploratrios no so
somente testes realizados sem nenhum propsito.
Esse tipo de teste exige uma abordagem sofisticada e pensativa no intuito de alcanar resultados e variaes de testes
que j foram implementados, uma vez que combina aprendizagem contnua com o estudo de heursticas e tcnicas que
contribuem para o sucesso na elaborao e execuo dos testes
exploratrios.
Importncia dos testes exploratrios

Em um projeto de software, alm da execuo de testes
baseados em scripts, o testador realiza testes exploratrios
durante todo o processo de testes. Os testes exploratrios, se
bem aplicados durante o projeto, tornam-se de grande importncia para o resultado final do projeto.
O testador poder aplicar os testes exploratrios quando o
projeto no contempla os requisitos, quando existe a necessidade de fornecer um feedback rpido sobre o produto e quando
o tempo curto para os testes. Ainda, quando h o intuito
de adquirir conhecimento sobre o produto a ser entregue,

para encontrar e investigar defeitos semelhantes ou novos,
para realizar cenrios de testes que no so convencionais ou
diversificar os testes j elaborados.
Com base nos objetivos apresentados acima para a execuo
dos testes exploratrios, podemos observar que durante um
projeto de software importante a execuo desta abordagem para incrementar e aperfeioar a percepo detalhada
do projeto a ser validado. Alm dos pontos citados, o testador
deve explorar e forar o software a expor sua capacidade para
assegurar que o mesmo execute suas funes conforme foi
projetado.
Como executar um bom Teste Exploratrio?

Durante os projetos visvel a falta da tempo para a execuo dos testes, por isso importante o testador analisar e
gerenciar suas abordagens e tcnicas para que o processo de
testes seja satisfatrio. Com isso, o profissional que busca um
bom resultado aps a observao das funcionalidades do
aplicativo deve seguir alguns critrios essenciais para que a
execuo dos testes exploratrios siga um nvel de criticidade
e validao dos erros que possam ser encontrados. necessrio um pensamento crtico, a interpretao dos resultados
e a comparao de funcionalidades ou sistemas similares
para produzir um resultado mais abrangente de informaes
encontradas durante a sesso destes testes.
Para alcanar os pontos levantados acima, uma boa explorao requer uma investigao contnua do produto, pois o testador deve responder s mudanas que podero ocorrer durante
o projeto e sempre manter o feedback com sua equipe.
Durante a utilizao desta abordagem o testador poder
encontrar alguns fatores que so favorveis ou desfavorveis
para os resultados alcanados. Abaixo so listados alguns
destes fatores:
Fatores Positivos:
Percepo aguada do testador: Na execuo dos testes
exploratrios deve-se ter um nvel de concentrao e alta
percepo para a anlise dos pequenos detalhes que a plataforma e as funes do aplicativo possam oferecer.
Criticidade do testador: Na execuo ou planejamento
dos testes o testador deve questionar os vrios cenrios que
um usurio possa executar, por mais que sejam cenrios
remotos de acontecer no uso do aplicativo ou plataforma.
Deve-se planejar um tempo para associar e organizar alguns
caminhos de excees com nvel de criticidade maior antes
mesmo de comear a execuo dos testes exploratrios.
Testadores exploratrios crticos so aqueles profissionais
capazes de analisar e explicar a lgica dos testes realizados,
o que de suma importncia para relatar o status de uma
sesso de testes exploratrios de forma clara, ou com o
propsito de esclarecer um defeito.
Experincia com tipos de testes: Os resultados dos testes
exploratrios sero mais precisos caso o testador tenha uma experincia em testes e domine tcnicas dos testes exploratrios
para a produo de ideias durante a execuo dos testes.
57
Domnio tcnico com o aplicativo: O domnio das funcionalidades existentes no aplicativo muito importante para
detectar a lgica correta de um determinado erro encontrado. Caso o testador no tenha esse tipo de experincia,
o mesmo pode realizar uma sesso de testes exploratrios
com casos de testes sobre a aplicao no intuito de adquirir
tal conhecimento.
Fatores Negativos:
Pouco tempo para anlise: No contexto de execuo dos
testes exploratrios, quase sempre no se reserva tempo
hbil para o planejamento e execuo dos testes, sejam
eles para ser aplicados na plataforma ou aplicativos.
Inexperincia do profissional: Para esta abordagem
de teste o profissional de teste que no tenha experincia, seja com aplicao, seja com plataforma, ter certa
dificuldade em estruturar testes exploratrios mais
detalhados.
Explorao limitada: Apesar de ter planejamento, alguns testes exploratrios ficam limitados, seja por causa
de erro na plataforma, seja pela inexperincia do testador
com o aplicativo ou outro fator externo. Assim, alguns
erros encontrados no so mais reproduzidos com a mesma lgica, sendo necessrio explorar um novo caminho
no qual o mesmo erro possa acontecer.
Estes fatores devem ser levantados previamente para a
abordagem ser utilizada com sucesso. Alm destes pontos,
deve-se observar as ferramentas e servios disponveis, o
status de outras partes do projeto para a mesma entrega
e os resultados de testes anteriormente executados, pois
tais percepes colaboram para o avano ou regresso dos
cenrios de testes que devem ser explorados.
Processo a ser aplicado para os Testes Exploratrios

Durante a utilizao desta abordagem importante
entender como podemos executar um planejamento e levantamento de critrios que sero utilizados durante todo
o processo de teste. Para isto devemos estudar e manter o
entendimento de algumas tcnicas para a gesto e avaliao
dos testes exploratrios que iro ser criados.
A abordagem dos testes exploratrios no pode ser medida
em relao ao seu planejamento ou a sua execuo, mesmo
porque cada projeto tem sua particularidade de atividades. Mas para termos um parmetro dos graus que o teste
exploratrio pode ter durante um projeto, James Bach, um
dos precursores desta abordagem, apresenta um dos vrios
graus que podemos encontrar durante a execuo dos testes
(ver Figura 1).
Ressalte-se que durante um projeto podemos intercalar entre os graus de testes exploratrios acima citados. De forma
sucinta, abaixo ser explicado cada grau apresentado:
Free exploration : Este grau demonstra o teste exploratrio
livre, onde o testador no se guia por nenhum planejamento
prvio, podendo comear e terminar do ponto de explorao
que ele quiser no aplicativo ou plataforma;
58
Roles: Este grau demonstra o testador assumindo a explorao guiada por papis. Os testes so executados no
aplicativo com o testador assumindo uma funo de um
usurio especfico como, por exemplo, um perfil de gerente.
Neste grau o testador exploratrio guia a sua execuo com
um ponto de vista para os testes, focando os resultados na
estrutura do papel definido;
Tasks: O grau dos testes exploratrios guiado por uma
tarefa especfica, estreitando ainda mais a viso dos testes que
sero executados. Dentro deste grau o testador poder assumir
um papel de usurio e realizar uma tarefa que o aplicativo oferece, buscando o maior detalhamento desta funcionalidade;
Sporadically Specified / Loosely Specified / Fully Sprecified: Nos trs graus restantes o testador j estrutura, podendo ser usada pouca ou total especificao com o intuito
de realizar seus testes exploratrios de forma orientada e
obter o melhor desempenho das funcionalidades a serem
validadas.
Figura 1. Graus que podem ser encontrados durante a execuo de testes
Para a execuo dos testes exploratrios seguir um processo,

pode-se seguir os passos apresentados na Figura 2:
Criao de uma hiptese: Visualizar um modelo mental que
represente o correto funcionamento da funcionalidade ou rea
do aplicativo a ser validado;
Planejar Cenrios: Planejar para comprovar a hiptese;
Aplicar os testes / Observar os Resultados: Nesta etapa o
testador executa os testes de acordo com os critrios definidos
nos passos anteriores e observa os resultados obtidos;
Avaliar os Resultados: Avaliao dos resultados diante da
hiptese levantada no primeiro passo;
Comprovar a hiptese: Comprovar se a hiptese foi validada
ou no e, caso o testador no obtenha o resultado esperado,
iniciar o ciclo novamente.
Alm deste processo, que pode ser utilizado para focar os
resultados a serem alcanados durante o processo de testes
em aplicativos, tem-se tambm que o analista de testes deve
considerar os cinco elementos apresentados na Figura 3:
Explorao do Produto: Este elemento tem por objetivo
observar as funes, os processamentos, as reas que so instveis e a interligao entre as funcionalidades do aplicativo
ou plataforma a ser validada. Neste primeiro momento o autor
afirma tambm que com esta prvia avaliao do produto
possvel estimar o esforo para a realizao da tarefa;
desen volvimento
Design de Teste: Com base na avaliao do produto possvel determinar o que ser testado;
Execuo dos Testes: Execuo dos testes observando o
comportamento do produto durante este processo, para que
o testador tenha informaes que o ajudem na compreenso
de como funciona o produto;
Resultados de Reviso: Todos os resultados devem ser
avaliados de forma que atendam a hiptese criada. Todo o
resultado necessita de revises constantes para que o testador
sempre esteja preparado para explicar como foi realizado os
testes e explicar se o produto atende ou no ao resultado obtido, podendo ser necessrio, posteriormente, reproduzir os
testes novamente;
Heurstica: So diretrizes ou regras que ajudam a decidir
o que fazer, como por exemplo o que e como deve ser testado
o aplicativo ou plataforma.
Figura 2. Processo para realizao de testes exploratrios
Como relatado nas duas vises de processos ou elementos

essenciais para os testes exploratrios, verifica-se que ambos
guiam-se com uma lgica inicial de entendimento do produto
como um todo, e tendo como principal validao de uma funcionalidade, ou parte do produto, o resultado que ser gerado.
Este resultado na abordagem de testes exploratrios de suma
importncia, pois este tipo de abordagem orientada atravs
de resultados que comprovem se determinada hiptese est
ou no em conformidade com o que foi planejado.
Desta forma, os testes exploratrios no mais so elaborados
e executados sem nenhuma misso a ser cumprida. As duas
vises mostram modelos de processos que so utilizados na
estruturao dos testes com o intuito de melhorar e guiar o
testador a alcanar maior cobertura dos testes com sucesso.
Gesto dos Testes Exploratrios - SBTM

A abordagem dos testes exploratrios, pode ser visualizada
como uma prtica onde podemos vislumbrar todos os tipos de
caminhos e aplicar vrias tcnicas durante sua execuo. Por
isso, torna-se para os testadores uma abordagem ampla que
alguns profissionais da qualidade ainda tm dificuldade em
realizar seu gerenciamento.
Dentre os mtodos que so utilizados para a gesto dos testes
exploratrios, o enfoque principal est no SBTM (Gerenciamento de Testes Baseados em Sesses). Esta gesto guiada
por sesses tem por objetivo conduzir melhor a execuo e os
resultados que sero coletados durante a execuo dos testes
exploratrios. Uma sesso um trabalho contnuo de reviso
e esforo de testes associado a uma misso em busca do que
ser testado ou quais problemas so procurados. Todos estes
resultados so mensurados em um perodo de tempo pr-determinado, que no contenha interrupes, sendo apresentado
o resultado no final.
Alm destas diretrizes, esta abordagem baseia-se nos pontos
fortes que a contemplam, como flexibilidade e velocidade das
atividades exercidas. Durante as sesses o testador registra
informaes que so relevantes, reaes do sistema, dados
utilizados e condies ou ideias que podem surgir no momento
da execuo.
Para entendermos melhor a estruturao do gerenciamento
de testes baseado em sesses, ao analisarmos este tipo de
gesto devemos observar os seguintes elementos: misso,
sesso e resultados.
Misso - SBTM
Figura 3. Anlise dos testes exploratrios
Para os testes exploratrios, a misso precisa ser objetiva,

descrevendo somente o que dever ser testado e no como
realizar a sua execuo. Em uma equipe que contempla esta
gesto, importante sempre realizar a priorizao das atividades dos testes e, assim, definir as misses para cada sesso
a ser criada, analisando a projeo de cada uma para que no
sejam muito especificas ou muito genricas.
As misses podem ser criadas a partir de reunies entre a
equipe durante o projeto, nos requisitos que so repassados
para o testador, nos defeitos encontrados, nas observaes
59
registradas durante as sesses, nas comparaes entre softwares, entre outros. A utilizao destes artefatos aperfeioa
as misses j criadas e tambm ajuda na idealizao de novas
misses durante o projeto.
Sesso - SBTM
A sesso compreende o perodo de tempo sem interrupes com durao entre uma ou duas horas. Esta sesso tem
como foco o cumprimento do objetivo da misso, garantindo,
assim, o sucesso dos resultados gerados durante os testes
exploratrios.
Esse autor separa esta sesso em trs tipos de tarefas: Setup
da Sesso, Modelagem /Execuo dos testes e Investigao /
Reportar Defeitos.
Setup da Sesso: consta na configurao do ambiente que
o testador ir executar, incluindo tarefas como equipamentos,
localizao de materiais, ler manuais ou escrever um relatrio
da sesso;
Modelagem / Execuo dos Testes: o testador analisa o objeto de testes em busca de informaes relevantes ou defeitos
relevantes;
Reportar Defeitos: Relatar os possveis erros que sero encontrados durante a execuo ou comportamentos
inesperados.
Resultados - SBTM
Durante o gerenciamento baseado em sesses, aps a avaliao e execuo das sesses, os testes so constitudos de
um conjunto de notas escritas que podem ser revisadas por
um gerente para o planejamento de posteriores sesses. Este
relatrio, alm de conter mtricas, deve possuir as seguintes
sees: descrio da misso, nome do testador, data e hora da
sesso, as mtricas, arquivo de dados, questes e os defeitos
encontrados.
As mtricas mostram s partes interessadas uma estatstica
do esforo de testes. Tais dados se relacionam a essas trs
seguintes tarefas:
Test Execution and Design (T): Tempo gasto para a elaborao, planejamento e execuo dos testes exploratrios;
Bug Investigation and Reporting (B): Tempo gasto para
encontrar e registrar os defeitos;
Setup (S): Percentual em tempo gasto para a preparao do
ambiente de testes ou atividades realizadas em paralelo.
Aps a realizao da sesso e mtricas, o testador apresenta
os resultados para os gerentes, lder de testes ou interessados
no produto, em uma reunio para mostrar as atividades executadas juntamente com os problemas encontrados durante
a sesso. Esta prestao de contas pode possuir o seguinte
formato:
Past (Passado): O que aconteceu durante a sesso?
Results (Resultados): Quais resultados foram atingidos
durante a sesso?
Obstacles (Obstculos): Quais obstculos atrapalharam a
explorao?
60
Outlook (Perspectiva): O que ainda falta fazer?

Feelings (Sentimentos): Como o testador se sente (em relao
ao teste ou qualidade)?
Com esta gesto possvel trabalhar a ateno do testador
para funcionalidades ou reproduo de erros difceis, permitindo o controle das suas atividades exploratrias com o consequente aumento na confiabilidade dos resultados alcanados.
Isto resulta em uma melhor explorao durante o processo de
testes, gerando qualidade no planejamento e execuo dos
testes exploratrios durante o projeto.
Testes Exploratrios em Plataformas

Uma vez conceituados todos os aspectos relevantes dos testes
exploratrios, a partir de agora iremos analisar esta abordagem
com foco em plataformas, onde so desenvolvidos o aplicativos.
A anlise proposta enfatiza pontos de extrema importncia a
serem explorados, complementado o aprendizado contnuo do
testador durante a validao do produto.
Quando se pensa em testes exploratrios, a ideia geral de
que se deve explorar as funcionalidades de uma determinado
aplicativo para ter um melhor entendimento e achar possveis
defeitos. Se o testador pensar somente desta forma, o planejamento dos testes no conseguir contemplar o quantitativo
de defeitos crticos a serem identificados, e sua viso sobre
os testes que sero elaborados e executados durante o projeto permanecer somente voltada para o entendimento do
aplicativo.
Com o intuito de ajudar o testador no melhor entendimento
dos testes em plataforma, esta seo mostrar aspectos essenciais para analisar os testes exploratrios sobre o ponto de
vista das funcionalidades e comportamentos exercidos pela
plataforma.Com isto, o foco do testador deve compreender a
anlise de todo o ambiente, levando em considerao a plataforma utilizada, juntamente com as funcionalidades propostas
pelo aplicativo a ser validado.
A importncia dos testes exploratrios nas plataformas
serve para o testador dominar o ambiente em que ir ser
desenvolvido o aplicativo, para que posteriormente se realize
cenrios de testes que tenham uma complexidade e nvel de
cobertura maior.
Durante o processo destes testes, foram observados alguns
pontos relevantes para o melhor entendimento do testador
no momento em que se aplica a abordagem de testes exploratrios como auxlio na execuo dos cenrios de testes. Com
isto, alguns pontos podem ser levantados e estudados pelo
testador quando for executar ou planejar esta abordagem de
testes em plataforma:
Comportamento da Plataforma: necessrio que o testador
tenha como objetivo o estudo e conhecimento de comportamentos padro que a plataforma exerce em todos os seus
componentes ou aplicaes nativas. Com base em um breve
estudo desta questo, o testador j poder iniciar as possveis
interligaes que podem influenciar no aplicativo desenvolvido e que posteriormente ter que ser validada.
desen volvimento
Alguns pontos podem ser observados durante a execuo

dos testes em relao ao comportamento da plataforma, tais
como a vulnerabilidade, funcionalidades padro e os pontos
fortes que a plataforma apresenta.
Componentes da Plataforma: Associado ao comportamento
da plataforma encontra-se a realizao dos testes exploratrios
para conhecer os tipos de componentes que a mesma oferece
em todo o seu contexto. Isto ajuda a entender como os componentes so mostrados e quais comportamentos so executados,
podendo ser analisado tambm o tempo de resposta que cada
componente exerce sobre determinado tipo de teste.
Alguns componentes podero ser reutilizados ou at mesmo
serem similares no aplicativo que ser testado, por isso este
passo torna-se importante para analisar a estrutura do aplicativo na fase de execuo dos testes.
Com estas informaes sobre a plataforma, o trabalho de
planejamento e execuo das atividades de teste ser mais
completo, visto que os cenrios de testes criados podem ter
uma amplitude de caminhos de teste que sero analisados e
mensurados no decorrer do projeto. Dentre estes caminhos
ser mais fcil para o testador diferenciar os erros entre a
plataforma e o aplicativo, e verificar posteriormente se o erro
encontrado na aplicao no consequncia de um erro de
plataforma.
Testes exploratrios em Aplicativos

A colaborao dos testes exploratrios anteriormente executados na plataforma de grande importncia para a avaliao
dos testes nos aplicativos. Aps a execuo dos testes exploratrios nos itens da plataforma, o testador dever avaliar
alguns pontos gerais do aplicativo com o intuito de aprender
sobre as funcionalidades e, tambm, realizar as associaes
com a plataforma.
Para a execuo dos testes em aplicativos, o testador exploratrio utiliza como principal ponto de partida os cenrios que sero
executados no decorrer da explorao. O testador sempre busca
entradas alternativas em busca de novas sadas inesperadas, mas
o objetivo final sempre completar o cenrio final planejado,
com a diferena de que o testador exploratrio poder percorrer
novos fluxos que podero ocasionar algum defeito.
Com base nisto, alguns pontos essenciais em aplicativos que
devem ser explorados utilizando esta abordagem so:
Anlise Especfica das Funcionalidades do Aplicativo:
- Funcionalidades Macros e Derivadas: Para um testador
exploratrio necessrio o entendimento das funcionalidades de todo o aplicativo a ser validado. A lgica utilizada
para compreender o aplicativo em sua totalidade focada
em aprender primeiro sobre o propsito e as principais
funes que sero implementadas. Com esta primeira explorao o testador j compreende as possveis ligaes entre
algumas funes do aplicativo com o intuito de mapear as
derivaes das funes macro;
- Componentes do Aplicativo: Os componentes do aplicativo
tornam-se to mais importantes quanto as funcionalidades
do mesmo. Isto porque alguns defeitos encontrados durante

a explorao so sobre o componente utilizado. O testador
enriquece a utilizao da abordagem exploratria caso
domine os componentes implementados em todo o aplicativo, pois sua viso no momento da execuo dos testes ir
englobar os pontos fortes e fracos entre as funcionalidades
e os componentes. Esta anlise ajuda a identificar as vulnerabilidades existentes nos componentes utilizados no
aplicativo, os quais so derivados da plataforma.
Anlise do Ponto de Vista do Usurio:
- Viso Estrutural do Usurio com o aplicativo: A anlise
que o testador deve focar nesta fase da explorao deve ser
nas principais funcionalidades que o usurio ir utilizar,
alm de observar a usabilidade durante toda a execuo dos
testes. Nesta observao o testador realiza a execuo dos
testes com o perfil de Usurio para que sejam observados
os detalhes de interface e a estrutura de usabilidade que o
aplicativa ir proporcionar a um usurio.
- Comportamentos relevantes do usurio: Este ponto serve como complemento para a execuo dos testes no item
anterior, visto que o testador exploratrio ir explorar os
comportamentos padronizados de um usurio e, em cima
destas informaes, estruturar cenrios de excees ou com
funes que trabalhem de forma correta.
A Figura 4 resume a lgica utilizada neste estudo sobre testes
exploratrios utilizando duas vertentes: Plataforma e Aplicativos. Durante este estudo foi observado que esta abordagem,
alm de ser til na explorao focada somente na Plataforma
ou no aplicativo, tambm foi de extrema importncia ao ser
aplicada na integrao entre as duas vertentes.
Figura 4. Integrao entre plataforma e aplicativo
A figura mostra como foi realizado os testes exploratrios

entre a plataforma e o aplicativo. Aps a anlise individual de
cada etapa, foi realizado a integrao entre os itens j explorados. Foram encontrados dois pontos significativos a serem
incorporados e analisados durante a integrao:
61
Verificao entre os componentes: No teste exploratrio

realizado para a integrao, o foco dos testes no aplicativo
leva em considerao todas as funoes dos componentes que
a plataforma oferece, por isso o modo como se comporta os
componentes dos aplicativo avaliado em cima de como a
plataforma interage com seus aplicativos nativos. Com isto
avaliado possvel o testador verificar um defeito no aplicativo
e avaliar se este comportamento errado realmente um erro
do aplicativo ou se o componente da plataforma est com
problemas, assim podendo influenciar no comportamento dos
componentes de outros aplicativos.
Verificao entre o comportamento das funcionalidades:
A explorao geral entre o comportamento da plataforma e do
aplicativo ajuda o testador a avaliar os pontos fortes e fracos
que a plataforma oferece para planejar alguns de seus testes
exploratrios no aplicativo. Este teste exploratrio de integrao abrange todas as funcionalidades do aplicativo, sendo
certo que o testador, com a sua experincia, poder analisar
os pontos crticos que podero ocorrer entre a plataforma e as
funes do aplicativo.
Esta abordagem requer uma avaliao minuciosa das funcionalidades dos aplicativos e plataforma, pois, como foi relatado,
os testadores tm um ganho muito alto na qualidade do planejamento dos testes exploratrios durante a execuo destes,
desde que se absorvam os benefcios de testar um aplicativo
empregando previamente esta abordagem na anlise da plataforma. Esta anlise deixa o profissional de teste com maior
domnio e raciocnio lgico dos problemas encontrados.
Ao utilizar os testes exploratrios com nfase nestas trs

etapas (explorao da plataforma, explorao do aplicativo
e explorao com integrao entre plataforma e aplicativo),
observa-se melhores resultados na execuo dos testes, alm de
ampliar o conhecimento do testador na absoro de possveis
falhas tcnicas que iro impactar na aplicao, conhecimento
do comportamento e componentes entre a plataforma e aplicativo, explorar cenrios difceis de serem executados e diversificar os testes durante o seu planejamento e execuo.
Como vimos no decorrer do artigo, a lgica dos testes exploratrios vai alm do que uma simples execuo, tornando-se uma
abordagem essencial na rea de teste de software. Isso porque,
se conduzida de forma correta, far com que os resultados a
serem alcanados durante o projeto sejam relevantes para a
qualidade e robustez do software.
BLACK, Rex. MITCHELL, Jamie. Advanced Software Testing, Rocky Nook,

vol. 3, 2011.
62
Links e Referncias:
BACH, James. Exploratory Testing Explained
http://www.satisfice.com/articles/et-article.pdf
KANER, Cem. Learning Styles and Exploratory Testing
http://www.kaner.com/pdfs/ExploratoryTestingandLearningStyles(Final).pdf
LYNDSAY, James. Adventures in Session-Based Testing
http://www.workroom-productions.com/papers/AiSBTv1.2.pdf
ACRISPIN, Lisa. GREGORY, Janet. Agile Testing A Practical Guide for Testers
and Agile Teams, 1st ed, Addison-Wesley, 2009.
COPELAND,Lee. Practitioners Guide to Software Test Design, Artech

House,2004.
WHITTAKER, James A. Exploratory Software Testing - Tips, Tricks, Tours an
Techniques to guide Test Design, Addison-Wesley ,2009.

desen volvimento
63
64

Engenharia de Software - Edição 67

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Engenharia de Software - Edição 67

Uploaded by

Copyright:

Available Formats

Rodrigo Oliveira Spnola

Marco Antnio Pereira Arajo

Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ, Especialista em

Eduardo Oliveira Spnola

Nicolli Souza Rios

Fale com o Editor!

Artigo no estilo Prtico

06 Softwell Maker 3: Crie seu primeiro projeto

Contedo sobre Boas Prticas

14 Medio de Software no CMMI e MPS.BR

Artigo no estilo Curso

24 Use Case Point: Estimativas de Projeto Parte 2

Contedo sobre Boas Prticas, Contedo sobre Engenharia

31 Casos de Teste: Importncia da rastreabilidade entre requisitos

Contedo sobre Boas Prticas, Contedo sobre Engenharia

[ Darlan Florncio de Arruda ]

[ Arilo Claudio Dias Neto ]

Artigo no estilo Prtico

49 SMarty Check: Conhecendo a Tcnica de Inspeo de software

43 Casos de Teste: Aprimore seus casos e procedimentos de teste

Contedo sobre Engenharia, Artigo no estilo Mentoring

D seu feedback sobre esta edio!

56 Trabalhando com Testes Exploratrios

Edio 05 - Engenharia de Software Magazine

Softwell Maker 3: Crie seu primeiro projeto

Fique por dentro:

Formado em Anlise e Desenvolvimento

crise de software surgiu devido

Engenharia de Software Magazine - Softwell Maker 3: Crie seu primeiro projeto

A ideia desse artigo demonstrar a utilizao

Alm disso, o Maker acompanhado

cronogramas atrasados e com oramento alm do previsto.

IDE para desenvolvimento RAD de aplicaes corporativas.

Java, .NET e Mobile (Android e iOS)

Microsoft SQL Server, PostgreSQL, IBM DB2, Oracle Database, MySQL

WYSIWYG e editor de regras de negcio via fluxogramas.

Editor de CSS integrado, possibilidade de criao de seus prprios

Tabela 1. Ficha tcnica do Maker

Como o Maker armazena os dados do projeto

Todo formulrio Maker, quando vinculado a uma fonte de

Criando seu primeiro projeto

Edio 67 - Engenharia de Software Magazine

Figura 1. Processo de compilao dos objetos desenvolvidos

Figura 2. Assistente de criao do projeto

importante lembrar que caso o banco de dados no exista, o

as informaes do projeto que est sendo

Engenharia de Software Magazine - Softwell Maker 3: Crie seu primeiro projeto

Observe a paleta de objetos na figura.

Figura 3. Tela principal do Maker

Figura 4. Formulrio Contato e seus campos

Figura 5. Assistente de banco de dados

Voltando para o formulrio de Contatos, acrescente o componente grade

tabela de telefones. O formulrio dever

Visualizando o formulrio criado

Edio 67 - Engenharia de Software Magazine

menu do projeto. Esta configurao feita no formulrio

Na tela aberta, clique com o boto direito na opo Raiz,

Figura 8. Definindo a estrutura do menu da aplicao

Figura 6. Formulrio Telefone com as propriedades do componente

Figura 9. Tela de Contatos visualizada no Webrun atravs do browser

importante observar a interface amigvel da tela final.

Criando o fluxo para validar idade

At aqui apresentamos como criar formulrios simples

Engenharia de Software Magazine - Softwell Maker 3: Crie seu primeiro projeto