Ebook - Engenharia, Qualidade e Teste de

ENGENHARIA,
QUALIDADE E
TESTE DE SOFTWARE
Jailson Costa dos Santos
gente criando o futuro
Capa_Engenharia de Software_A5.indd 1,3 25/09/19 12:38

LIVRO 1
ENGENHARIA
DE SOFTWARE
LIVRO 2
QUALIDADE
DE SOFTWARE
LIVRO 3
TESTE
DE SOFTWARE
eBook Completo para Impressao - Fundamentos da Educacao - Aberto.indd 1 20/11/2019 17:26:50

ENGENHARIA
DE SOFTWARE
(LIVRO 1)
Presidente do Conselho de Administração Janguiê Diniz
Diretor-presidente Jânyo Diniz
Diretoria Executiva de Ensino Adriano Azevedo
Diretoria Executiva de Serviços Corporativos Joaldo Diniz
Diretoria de Ensino a Distância Enzo Moreira
Autoria Jailson Costa dos Santos
Projeto Gráfico e Capa DP Content
DADOS DO FORNECEDOR
Análise de Qualidade, Edição de Texto, Design Instrucional,
Edição de Arte, Diagramação, Design Gráfico e Revisão.
© Ser Educacional 2019
Rua Treze de Maio, nº 254, Santo Amaro
Recife-PE – CEP 50100-160
*Todos os gráficos, tabelas e esquemas são creditados à autoria, salvo quando indicada a referência.
Informamos que é de inteira responsabilidade da autoria a emissão de conceitos.
Nenhuma parte desta publicação poderá ser reproduzida por qualquer meio
ou forma sem autorização.
A violação dos direitos autorais é crime estabelecido pela Lei n.º 9.610/98 e punido pelo
artigo 184 do Código Penal.
Imagens de ícones/capa: © Shutterstock
Engenharia de Software - Unidade_1_A5.indd 2 25/09/19 12:49

Boxes
ASSISTA
Indicação de filmes, vídeos ou similares que trazem informações comple-
mentares ou aprofundadas sobre o conteúdo estudado.
CITANDO
Dados essenciais e pertinentes sobre a vida de uma determinada pessoa
relevante para o estudo do conteúdo abordado.
CONTEXTUALIZANDO
Dados que retratam onde e quando aconteceu determinado fato;
demonstra-se a situação histórica do assunto.
CURIOSIDADE
Informação que revela algo desconhecido e interessante sobre o assunto
tratado.
DICA
Um detalhe específico da informação, um breve conselho, um alerta, uma
informação privilegiada sobre o conteúdo trabalhado.
EXEMPLIFICANDO
Informação que retrata de forma objetiva determinado assunto.
EXPLICANDO
Explicação, elucidação sobre uma palavra ou expressão específica da
área de conhecimento trabalhada.

Sumário
Unidade 1 - Aspectos introdutórios da engenharia de software

Objetivos da unidade............................................................................................................ 14
A crise do software............................................................................................................... 15
A crise de software e a Idade Média......................................................................... 17
Causas da crise de software........................................................................................ 18
Introdução à engenharia do software............................................................................... 19

Software: conceitos e características....................................................................... 20
Conceitos introdutórios sobre engenharia de software.......................................... 21
Estudo da diversidade na engenharia de software ................................................ 24
A relação da internet com a engenharia de software . .......................................... 26
Mitos e desafios do desenvolvimento de software........................................................ 27

Mito de gerenciamento................................................................................................. 28
Mito do cliente................................................................................................................ 29
Mito do profissional....................................................................................................... 30
Fundamentos dos processos de desenvolvimento do software................................... 30

Dificuldades encontradas nos processos de desenvolvimento de software...... 31
Definição de projeto x definição de processo ......................................................... 31
Processo de software........................................................................................................... 33
Análise dos modelos de processos de software . ................................................... 35
O Modelo em Cascata................................................................................................... 36
Desenvolvimento incremental..................................................................................... 40
Engenharia de software orientada a reúso............................................................... 42

Atividades do processo de software................................................................................. 45
Especificação de software........................................................................................... 45
Projeto e implementação de software....................................................................... 47
Validação de software.................................................................................................. 49
Evolução do software.................................................................................................... 50
Sintetizando............................................................................................................................ 52
Referências bibliográficas.................................................................................................. 53
ENGENHARIA DE SOFTWARE 5

Sumário
Unidade 2 - Modelos de software e métodos ágeis

Modelos de processos clássicos de software................................................................ 56

Modelo cascata................................................................................................................ 57
Modelo evolucionário...................................................................................................... 59
Prototipação...................................................................................................................... 59
Modelo espiral.................................................................................................................. 62
Técnicas de quarta geração.......................................................................................... 63
Combinando paradigmas................................................................................................ 65
Baseado em reúso........................................................................................................... 67
Incremental....................................................................................................................... 70
RAD..................................................................................................................................... 71
Formal................................................................................................................................. 73
Modelos de processos contemporâneos de software................................................... 75

Extreme Programming..................................................................................................... 75
Lean Software Development.......................................................................................... 78
DevOps............................................................................................................................... 79
Métodos ágeis de desenvolvimento.................................................................................. 80

Métodos ágeis.................................................................................................................. 81
Desenvolvimento ágil e dirigido a planos..................................................................... 83
Gerenciamento ágil de projetos..................................................................................... 84
Escalamento de métodos................................................................................................ 86
Sintetizando............................................................................................................................ 87

Sumário
Unidade 3 - Garantia da qualidade

A garantia da qualidade de software................................................................................ 91

Fatores da qualidade de software................................................................................. 95
Como garantir a qualidade de software....................................................................... 98
Atividades SQA................................................................................................................. 99
Normas de qualidade aplicadas no desenvolvimento do software.......................... 101

ISO 9001............................................................................................................................ 102
ISO 12207.......................................................................................................................... 103
ISO 15504.......................................................................................................................... 104
Modelo de maturidade da captação para software (CMM)................................... 105
PSP e TSP........................................................................................................................ 107
MPS.BR (melhoria de processo de software brasileiro)......................................... 108
Métricas de qualidade de software................................................................................ 109

Análise de componentes de software........................................................................ 112
Indicadores de qualidade de software....................................................................... 114
A ciência de software de Halstead............................................................................. 116
Métrica de complexidade de McCabe....................................................................... 118
Medições ambíguas....................................................................................................... 119
Sintetizando.......................................................................................................................... 121
Referências bibliográficas................................................................................................ 122

Sumário
Unidade 4 - Modelagem de sistemas

Objetivos da unidade.......................................................................................................... 124
Modelagem de sistemas.................................................................................................... 125

Modelos de contexto..................................................................................................... 127
Modelos de interação.................................................................................................... 131
Modelos estruturais....................................................................................................... 133
Modelos comportamentais........................................................................................... 134
Tipos de modelo de software............................................................................................ 136

Modelo codificar e consertar....................................................................................... 136
Modelo V.......................................................................................................................... 137
Praxis................................................................................................................................ 139
O processo unificado aberto (OpenUP)........................................................................... 141

RUP................................................................................................................................... 142
AUP................................................................................................................................... 145
OpenUP............................................................................................................................ 148
Swebok................................................................................................................................. 150
Categorias do conhecimento da engenharia de software...................................... 150
Áreas do conhecimento................................................................................................ 151
Aspectos do Swebok..................................................................................................... 152
Sintetizando.......................................................................................................................... 153

Apresentação
Esta disciplina pretende abordar os conceitos fundamentais da en-

genharia de software e ensinar, de maneira clara e coesa, a história, a
evolução, as novidades e os desafios dessa relevante matéria dentro do
desenvolvimento de software. Mostraremos a importância de desenvolver
softwares priorizando qualidade, rapidez, eficácia e eficiência, também
considerando prazo e orçamento do produto final de modo gerenciável.
A engenharia de software pode ser, inicialmente, compreendida como
um conjunto de etapas acrescidas de métodos, ferramentas e procedimen-
tos com a finalidade de produzir e entregar um software de acordo com as
solicitações e necessidades do cliente, destacando qualidade, prazo, custos
e aplicabilidade. O ciclo de vida básico de qualquer software deve passar
por algumas fases, citadas a seguir: engenharia de sistemas, análise dos
requisitos, constituição de um projeto, codificação, testes de qualidade e
sustentação (manutenção).
Neste conteúdo, além disso, quer-se abordar as principais característi-
cas da engenharia de software e a crise enfrentada no final do século pas-
sado por essa área – crise esta que tem reflexos até os dias atuais. Serão
tratados os mitos, desafios e paradigmas do desenvolvimento de software.
Vale ressaltar que a engenharia de software tem se expandido muito nos
últimos anos, e seus conceitos têm sido aplicados em diversas áreas dentro
das organizações e empresas, afim de estreitar o relacionamento com os
clientes e entregar produtos mais personalizados e coerentes com as ne-
cessidades de seus consumidores.
Por fim, vamos explanar como os estudos de engenharia de software
resultaram no desenvolvimento de alguns modelos, levando em considera-
ção suas características e seus comportamentos de modo abstrato. A utili-
zação desses modelos de software tem impactado de maneira muito positi-
va a engenharia de software, uma vez que tem apresentado soluções de um
jeito mais rápido e eficiente, visando a entregar um software – seja como

produto, seja como serviço – mais personalizável e que esteja de acordo
com as necessidades de seus clientes, não deixando de lado a preocupação
com possíveis alterações, correções e futuras implementações para ter um
software de longa vida e com crescimento escalável.

O autor
O Professor Jailson Costa dos Santos

é especialista em Engenharia de Soft-
ware pela Universidade Braz Cubas
(UBC) (2018). É especialista em Gover-
nança em Tecnologia da Informação
pela Universidade Nove de Julho (Uni-
nove) (2018). É especialista em Docên-
cia do Ensino Superior pela Universida-
de Paulista (Unip) (2017). É graduado
em Análise e Desenvolvimento de Sis-
temas pela Universidade Mogi das Cru-
zes (UMC) (2015). Ministra disciplinas
de desenvolvimento de software, algo-
ritmos e lógica de programação, enge-
nharia de software, programação web
e mobile para os cursos de Engenharia
da Computação, Sistemas da Informa-
ção e Tecnólogo em Análise e Desen-
Dedico este trabalho a Deus, pelo volvimento de Sistemas.
dom da vida e pela oportunidade de
aprendizagem; aos meus pais, à minha Currículo Lattes:
esposa, à minha irmã e à minha sobrinha,
http://lattes.cnpq.br/1518555946125894
que sempre me incentivaram com seus
carinhos e afagos; aos meus alunos que
me conduziram a este aprendizado e
foram incentivadores deste novo desafio.

UNIDADE
1 ASPECTOS
INTRODUTÓRIOS DA
ENGENHARIA DE
SOFTWARE

Objetivos da unidade
Discorrer sobre a crise dos softwares;
Apresentar os aspectos introdutórios da engenharia de software e suas

características;
Abordar os mitos e desafios existentes no desenvolvimento dos

softwares;
Observar os fundamentos dos processos de desenvolvimento de

software verificando seu processo e suas atividades.
Tópicos de estudo
A crise do software Fundamentos dos processos de
A crise de software e a Idade Média desenvolvimento do software
Causas da crise de software Dificuldades encontradas nos processos
de desenvolvimento de software
Introdução à engenharia do software Definição de projeto x definição de
Software: conceitos e características processo
Conceitos introdutórios sobre enge-
nharia de software Processo de software
Estudo da diversidade na engenharia Análise dos modelos de processos de
de software software
A relação da internet com a engenha- O Modelo em Cascata
ria de software Desenvolvimento incremental
Engenharia de software orientada a
Mitos e desafios do desenvolvimento de reúso
software
Mito de gerenciamento Atividades do processo de software
Mito do cliente Especificação de software
Mito do profissional Projeto e implementação de software
Validação de software
Evolução do software

A crise do software
A expressão “crise do software” não é recente dentro dos estudos relaciona-
dos à engenharia de software. A utilização dela se deu, primeiramente, a partir
da década de 1970, quando a engenharia de software era pouco desenvolvida.
Nesse momento, existiam limitações expressas na criação de softwares, em
face da grande procura por eles. Era visível o grau de complexidade dos pro-
blemas observados, ao mesmo tempo que inexistiam métodos criados para o
desenvolvimento de sistemas que possibilitassem o funcionamento adequado
ou mesmo que fossem validados.
No entanto, você pode estar se perguntando: o que é um software? Quais
são as suas características? Como evoluiu para os dias atuais? Essas questões
serão respondidas de modo a auxiliar o entendimento da crise do software. Em
uma definição simplificada, pode-se
definir “software” como um produto
projetado e desenvolvido por profis-
sionais ligados à área de engenharia
do software, que abrange:
• Programas: quando executados,
determinam a função e o resultado
que se deseja obter;
• Documentos: apresentam a operação e a utilização dos programas;
• Estrutura dos dados: permitem aos programas a possibilidade de mani-
pulação correta da informação.
Quanto às características de um software, é perceptível que eles são cria-
dos e planejados com o intuito de serem aplicados de maneiras distintas para
cada cliente. No entanto, mesmo que seja utilizado por uma série de clientes,
sua implantação e seu suporte serão diferentes de cliente para cliente. O soft-
ware pode se tornar obsoleto conforme a sua deterioração.
Uma outra característica está relacionada ao fato de que os softwares po-
dem ser montados a partir de componentes já disponíveis, reduzindo o tempo
dispendido para a produção e a quantidade de problemas, já que tais compo-
nentes já foram previamente testados. Nesse contexto, o uso de frameworks é
um auxiliador na criação da parte visual.

A evolução do software está em um processo de crescimento desde a
sua criação. A produção deles é recente, se comparada a profissões mais
tradicionais. As primeiras informações que temos a respeito da utilização
de softwares surgiram entre os anos 1950 e 1965, período em que a evolu-
ção contínua do hardware permitiu que a produção de software se popu-
larizasse. Enquanto o hardware era considerado como uma ferramenta de
propósito geral, o software sempre foi apresentado com um caráter mais
específico em suas aplicações, mas não havia documentação ou registro de-
les no período mencionado.
A partir de 1965, surgiram novas linguagens de programação. Associado a
isso, observou-se a aplicação dos primeiros sistemas multiusuários, as técnicas
interativas e os sistemas em tempo real. Nessa época – que durou até meados
de 1975 –, o crescimento dos sistemas baseados em computadores ocorreu
ao mesmo tempo em que a manutenção deles se tornou impossível. Conse-
quentemente, o software passou a ser obsoleto.
CURIOSIDADE
A primeira geração de sistemas de banco de dados surgiu em meados
dos anos 1970. Paralelo a isso, surgiram pequenas empresas de desen-
volvimento de software chamadas de Software Houses. Elas tinham o
objetivo de aumentar a produtividade e criaram as chamadas bibliotecas
de softwares.
Agora ficou mais claro entender o contexto em que estava inserido o termo
“crise de software”. É perceptível que o uso dele ficou mais frequente a partir
do final da década de 1960. O estudioso Edsger Dijkstra é referência no assunto
através da sua apresentação realizada na Association for Computing Machinery Tu-
ring Award, no ano de 1972. O trabalho levou o título de The Humble Programmer.
A partir do momento em que o desenvolvimento de software passou a se
expandir por meio da utilização das chamadas “linguagens estruturadas e mo-
dulares”, vimos um processo de sucessivas falhas cometidas pela indústria de
software no que se refere, primeiramente, à demonstração dos resultados –
que não ocorria dentro dos prazos estabelecidos. Consequentemente, os va-
lores dos orçamentos eram ultrapassados e o nível de qualidade do produto
trazia dúvidas e insatisfação.

Hoje em dia, é um consenso afirmar que a crise de software teve relação di-
reta com o modelo de trabalho em equipe que era praticado à época. Além dos
problemas relacionados ao não funcionamento do sistema da maneira deseja-
da, existiam dúvidas de como criar e manter um nível crescente no número de
softwares, além de haver uma preocupação em atender possíveis demandas
no futuro. Isso pode ser atribuído à baixa compreensão dos desenvolvedores,
à aplicação de métodos e técnicas de nível baixo aplicados no processo e no
produto, e ao estabelecimento de poucos parâmetros de qualidade.
Desse modo, é importante ressaltar que esses fatores estabeleceram res-
postas e métodos que, ao longo do tempo, foram melhorados e registrados,
originando a chamada área de engenharia de software. A procura por requi-
sitos como eficiência e competência trouxe uma gama de oportunidades, de-
safios e ameaças que nortearam as tecnologias e indicaram novos caminhos
para as pesquisas.
A crise de software e a Idade Média

As origens da crise de software podem ser compreendidas através da
comparação com a experiência de outras indústrias. Antes da Revolução In-
dustrial, por exemplo, existia uma individualização na produção de sapatos
ou de qualquer outro manufaturado.
Da extração da matéria-prima à en-
trega ao consumidor final, cada par
de sapatos era produzido de maneira
única para cada cliente.
Fazendo uma analogia do processo
produtivo anterior à Revolução Indus-
trial com o processo em que a indústria
de softwares passou a ter, notam-se
alguns pontos semelhantes. Primei-
ramente, como já vem sendo exposto
e discutido, os métodos de criação e
desenvolvimento de softwares ainda
passam por um processo de matura-

ção e estabelecimento devido a uma série de técnicas que estão surgindo nos
últimos tempos. Outro ponto a ser avaliado é o de que a criação de um novo
software normalmente acarreta no descarte de ideias e materiais utilizados
na produção anterior. Logo, é fato que a tendência, em situações assim, é de
uma entrega de produto (software) com problemas de documentação, além da
não disseminação do conhecimento pela organização, já que a maior parte das
ideias e dos procedimentos utilizados fica com os desenvolvedores, ou seja, o
cenário é muito parecido com o do sapateiro, citado no exemplo.
Causas da crise de software

O processo de criação de um software é complexo e, fora isso, a área de en-
genharia de software passa por um processo de maturação na formação de pro-
fissionais. Essas situações explicam de imediato as causas da crise do software.
Existe uma imprecisão na estipulação de prazos e no custo final do produto,
além da falta de tempo hábil para a captura de dados relevantes para serem
utilizados no processo de desenvolvimento de software. Aqui, você pode estar
se perguntando: se o prazo e o custo são indefinidos e não existe uma coleta de
dados realizada dentro de um tempo relativamente suficiente, que resultados
serão alcançados?
Bem, como a extração de dados históricos tem sido realizada
através de parâmetros de baixo nível, a consequência disso é obter
resultados ruins. Logo, fica evidente que a produtivida-
de apresentada pelos profissionais da área de enge-
nharia de software é insuficiente em relação aos
serviços demandados, pois os projetos de criação
e desenvolvimento de software apresentam resul-
tados muito aquém do que é exigido pelo cliente.
CURIOSIDADE
A manifestação da crise ocorre de diversas maneiras, entre as quais se
pode destacar o fato de haver projetos mal elaborados que normalmente
tornam-se pouco gerenciáveis ou que ultrapassam o limite orçamentário e
de prazo. Em um contexto como esse, o software criado é de baixa quali-
dade, não atingindo os requisitos mínimos para sua execução.

Como já observado, há muito tempo essa crise foi diagnosticada nos pro-
cessos de desenvolvimento de software, mas ela persiste até os dias atuais.
Nesse caso, como solucioná-la? Uma alternativa interessante está na aquisição
de um nível mais elevado de métodos e ferramentas, além de investimentos
em treinamento em um grau maior daquele que é oferecido atualmente. A cria-
ção de software precisa mudar de paradigma, abordando como o software é
desenvolvido atualmente e como poderia ter sido desenvolvido.
Introdução à engenharia do software

Na década de 40, o mundo começou a se fami-
liarizar com o primeiro computador eletrônico da
história, o ENIAC, lançado pela empresa IBM. Ainda
nessa década, A TV foi introduzida aos lares e ao co-
tidiano das pessoas. Nessa época, iniciou-se também um
processo de evolução nos sistemas computadorizados,
em que o desenvolvimento de hardware foi a principal
atividade de captação de esforços e custos, devido às difi-
culdades e limitações presentes naquele período.
Com o passar dos anos, a tecnologia de hardware foi superada e, no início
dos anos 50, o desenvolvimentodos sistemas operacionais tornou-se a grande
preocupação dentro das organizações empresariais. Passaram, então, a apa-
recer os feitos iniciais desses sistemas em paralelo às realizações das lingua-
gens de programação, além dos compiladores. O que você precisa compreen-
der é que o objetivo do desenvolvimento desses sistemas era fazer com que
o usuário se atentasse mais à resolução de questões relacionadas aos proble-
mas computacionais e menos ao funcionamento interno (hardware).
Na década seguinte, surgem sistemas operacionais baseados em multipro-
gramação, ou seja, os sistemas computacionais passam a atuar com um maior
grau de eficiência. Devido a isso, há a necessidade de desenvolver um número
maior de sistemas de software, que passaram a substituir os programas de
menor capacidade utilizados naquele momento.
A transição dos pequenos sistemas de softwares para os mais abundantes
ocasionou um enorme problema devido à não adaptação às técnicas de desen-

volvimento já existentes por parte dos programas menores, o que ocasionou a
“crise de software”. Perceba bem que engenharia de software surgiu dentro
desse mesmo contexto.
CURIOSIDADE
O custo de desenvolvimento de um software não segue a tendência da
queda de preço dos equipamentos. Tal custo está cada vez mais incorpo-
rado ao custo global de um sistema informatizado. Isso é explicado pelo
fato de a tecnologia de desenvolvimento de software demandar de uma
extensa carga de trabalho.
Ao longo deste capítulo, veremos os conceitos relacionados ao desenvolvi-

mento de software por meio da engenharia de software no que diz respeito a
técnicas, metodologias e métodos.
Software: conceitos e características

Até o momento, foi exposto todo período de
evolução do desenvolvimento de software ao
longo das décadas. Porém, o que é de fato um
software? Segundo o entendimento trazido
por Sommerville (2011, p. 4), softwares “são pro-
gramas de computador e documentação associa-
da. Produtos de software podem ser desenvolvidos para
um cliente específico ou para o mercado em geral. São
estruturas de dados que possibilitam que informações
sejam manipuladas de maneira adequada com o intuito de
resolver problemas e a documentação necessária para uma
melhor compreensão do seu uso”.
CURIOSIDADE
Dentro de um contexto que envolve o conceito de engenharia de softwa-
re, o termo “software” tem a conotação de produto e, desse modo, ele
pode ser comercializado. Enquanto os programas propriamente ditos são
restritos ao próprio autor, os softwares são direcionados comercialmente
a pessoas diferentes dos seus programadores.

Ao utilizarem um produto de software, os usuários dispõem de informações
ou experiências que variam de pessoa para pessoa. Você já deve imaginar que
um software, enquanto produto, deve ser desenvolvido com atenção especial
à sua interface e trazer uma documentação robusta em informações que possi-
bilitem a plena utilização dos recursos disponíveis. Ressaltando que o produto
software deve passar, antes da sua disponibilização, por uma série de testes
para que quaisquer erros de execução sejam corrigidos.
Agora ficou mais clara a diferença básica entre um programa e um software
desenvolvido na resolução de problemas. É visível que sempre haverá um es-
forço maior de tempo e de custos em relação à criação de um software. Outro
ponto importante a ser ressaltado está relacionado ao fato de o programa ser
um pouco mais tolerante a erros de execução, já que o próprio usuário tem a
capacidade de identificar e corrigir essas falhas.
Softwares apresentam particularidades. De imediato, você tem que enten-
der e fixar a ideia de que um software é um produto de características lógicas
e não físicas, ou seja, trata-se de um elemento intangível. Sendo assim, vale
explicar que:
• O software é fruto de um trabalho do ramo da Engenharia, mas não é um
produto manufaturado;
• Esse produto não estará sujeito ao desgaste do tempo como os produ-
tos físicos. Isso implica afirmar que o mesmo não sofre alterações ou falhas
no futuro;
• Os softwares são feitos sob medida para atender a uma necessidade espe-
cífica do cliente sem a utilização de componentes preexistentes.
Conceitos introdutórios sobre engenharia de software

Até aqui, conseguimos visualizar o processo evolutivo do desenvolvimento do
software e o seu conceito apresentado de forma mais abrangente. Agora, veremos
a importância da engenharia de software no processo de aplicação dos softwares
criados. O que é engenharia de software? Segundo o entendimento de Sommer-
ville (2011, p. 5), consiste em “uma disciplina de engenharia cujo foco está em todos
os aspectos da produção de software, desde os estágios iniciais da especificação
do sistema até sua manutenção, quando o sistema já está sendo usado”.

Se buscarmos entender o conceito prático de Engenharia, veremos que
essa área se baseia em resultados que prezam pela qualidade, respeitando
dois aspectos primordiais: prazo e orçamento. Em contrapartida, indivíduos
que desenvolvem programas para atender a necessidades pessoais, geralmen-
te, utilizam um tempo vasto para criar e desenvolvê-los. Dentro da área da
engenharia de software, os profissionais adotam uma abordagem organizada
e sistemática para executarem o trabalho, visando à eficiência na criação de
softwares de qualidade mais elevada.
Percebem que produzir um programa está ligado à ideia de conforto ao
usuário do sistema, enquanto a criação de um software requer um nível de
cobrança mais rigoroso? Entretanto, desenvolver um software, como já men-
cionado, é mais atrativo. Logo, a engenharia de software é uma área relevante
basicamente por dois aspectos:
1. A exigência da aquisição de softwares de nível cada vez mais avançado
impõe a criação de sistemas que atuem de maneira confiável, econômica e de
maneira rápida.
2. Em uma análise de longo prazo, o uso de técnicas da engenharia de soft-
ware direcionadas aos sistemas de software acaba sendo mais vantajoso do
que simplesmente desenvolver programas.
A Engenharia exige a seleção de técnicas que melhor atendam a uma sé-
rie de situações. Portanto, uma abordagem com um aspecto mais criativo
e menor nível de formalidade pode se mostrar eficiente, a depender da cir-
cunstância. O desenvolvimento de sistemas web, por exemplo, é oriundo do
desenvolvimento menos formal que solicita uma junção de habilidades de
software e de projeto.
CURIOSIDADE
Segundo Sommerville (2011, p. 6), existe uma relação entre engenha-
ria de software, ciência da computação e engenharia de sistemas.
Enquanto a ciência da computação trata de métodos que alicerçam
os sistemas de software e os computacionais e a engenharia de
sistemas direciona seus esforços no desenvolvimento e na evolução
de sistemas complexos em que o software tem o papel principal, a
engenharia de software trata de questões práticas relacionadas à
criação de softwares.

Os softwares são distintos entre si.
Logo, não existe um método único apli-
cável a todos. Porém, segundo o en-
tendimento de Sommerville (2011, p. 6),
alguns aspectos influenciam os diferentes
modelos de software:
• Heterogeneidade: Há uma exigência cada
vez maior para que os sistemas atuem de maneira
distribuída por meio de redes que abranjam distin-
tos modelos de computadores e dispositivos móveis.
É corriqueira a integração de um software recente com
sistemas mais antigos, desenvolvidos nas chamadas linguagens de progra-
mação distintas. O desenvolvimento de técnicas para criar um software de
confiança que seja maleável de tal forma que consiga lidar com o aspecto
da heterogeneidade;
• Mudança de negócio: Existe uma clara onda de mudança relacionada ao
desenvolvimento de novas tecnologias nos países considerados emergentes.
A alteração de um software por outro mais moderno deve ocorrer de maneira
mais rápida. Algumas técnicas utilizáveis na engenharia de software deman-
dam um tempo maior, dificultando a entrega de novos sistemas. O desafio é
evoluir para a redução do tempo exigido pelo software para oferecer retorno
aos seus clientes;
• Segurança e confiança: Quantas vezes você já hesitou em acessar uma
página da web ou programa de computador? De fato, nos dias atuais, a utiliza-
ção de softwares faz parte do nosso cotidiano. O diferencial para a aquisição
de um produto como esse está na segurança e na confiabilidade que o mesmo
transmite. Em uma era em que a informação é compartilhada de maneira glo-
balizada, em uma velocidade recorde, é preciso ter a confiança de que usuários
maliciosos não terão acesso ao software, mantendo a informação protegida.
CURIOSIDADE
A ideia de segurança e confiança é exemplificada pelo uso dos sistemas
remotos, já que eles são acessados por meio de uma página da web ou de
uma interface de web services.

Estudo da diversidade na engenharia de software
Diante dos conceitos até aqui abordados, você compreende que a área da
engenharia de software trata do estudo sistematizado da criação de um soft-
ware e tudo o que diz respeito ao seu desenvolvimento: análise de custos, es-
tabelecimento de prazos e – o principal – a confiança transmitida pelo produto.
Toda essa avaliação busca exatamente atender às demandas dos produtos e
dos clientes de software.
É bem verdade que a maneira como esse estudo sistematizado vai ser im-
plantado nas empresas não é padronizada, ou seja, haverá variações de acordo
com o modelo empresarial, tipo de software e quais profissionais estão inseri-
dos no processo de desenvolvimento. Devido à constante evolução existente
nessa área, não existem métodos que supram as necessidades dos sistemas
disponíveis para todas as organizações.
Pense em um empreendedor ou um gestor necessitando de um serviço

de engenharia de software que atenda a um determinado setor de sua orga-
nização. As técnicas disponíveis no mercado não atendem, com totalidade, a
sua demanda pelo serviço. O que fazer? Alguns critérios deverão ser adotados
quanto ao tipo de aplicação que precisa ser desenvolvida. Algumas dessas apli-
cações podem ser citadas – como exemplo, as aplicações stand-alone, que são

executadas em um computador local, apresentam toda a funcionalidade e dis-
pensam conexão com rede. Programas CAD ou um software de manipulação
de fotografias também exemplificam esse tipo de aplicação.
Outro exemplo interessante são os sistemas de controles embutidos. Eles
controlam os dispositivos de hardware e, possivelmente, apresentam como o
tipo de sistema de maior quantidade. Softwares de celulares que conseguem
realizar a função de um controle, ou até mesmo os softwares presentes nos
aparelhos micro-ondas que funcionam como auxílio no cozimento do alimento,
são alguns dos exemplos de funcionalidade desses sistemas.
É preciso deixar muito claro que sempre utilizaremos métodos distintos de
engenharia de software a cada tipo de sistema que venha a ser requisitado,
devido às características diversas que um software pode apresentar. Apesar da
diversidade, alguns fundamentos da engenharia de software podem ser apli-
cados a qualquer tipo de sistema, independentemente de sua característica.
Uma organização precisa elaborar e executar um processo de desenvolvi-
mento de software de maneira clara, compreensível e gerenciada, definindo
o que será produzido e quando o processo será finalizado. De imediato, você
pode se perguntar: e se os softwares apresentarem características diferentes?
Basicamente, processos diferentes serão aplicados a tipos diferentes de soft-
wares, mas o princípio básico da produção – o que produzir, para quem produ-
zir e como produzir – deve estar no planejamento inicial do desenvolvimento
de um software.
Outro ponto a ser exposto está relacionado aos sistemas, que devem de-
monstrar resultados e ser confiáveis. Empresas que desenvolvem softwares
instáveis, com falhas e indisponibilidade no momento em que são solicitados,
estão fadadas ao insucesso.
O que um software deve realizar? Essa pergunta é o elo entre o cliente-u-
suário, que deseja obter soluções pela aquisição de um produto de software,
e como os desenvolvedores conseguem gerenciar a expectativa criada pelos
clientes, oferecendo um produto no prazo e no orçamento estabelecidos. Por
fim, mas não menos importante, trata-se do reaproveitamento dos recursos
já existentes, ou seja, sempre que possível, as organizações devem reutilizar
um software já desenvolvido. Isso traz vantagens principalmente nos quesitos
tempo, conhecimento e custos, e pode ser um diferencial para a empresa.

A relação da internet com a engenharia de software
Você lembra do seu primeiro contato com a internet? Se você nasceu nos
anos 2000, certamente esse contato ocorreu mais cedo em sua vida, se compa-
rarmos com as gerações anteriores. Hoje afirmamos sem qualquer constrangi-
mento que o desenvolvimento da internet provocou mudanças profundas na
vida das pessoas dessa época.
No início, a internet funcionava como um banco de armazenamento de in-
formações que eram acessadas de modo universal e que provocavam poucas
interferências nos sistemas de software. Isso significa que tais sistemas eram
executados nos computadores locais, ou seja, eram acessados dentro da em-
presa apenas. Isso muda a partir da década de 2000, quando a evolução da
internet acontece e mais recursos são acrescentados aos navegadores.
CURIOSIDADE
A adição de recursos aos navegadores significou o desenvolvimento de
sistemas web, que passaram a ser acessados de um navegador e não de
uma interface de usuário específica. Novos produtos de software passaram
a ser desenvolvidos a partir disso e ofereceram serviços inovadores que
eram visualizados por meio da internet.
A evolução no software corporativo e organizacional, similar ao que

houve com os produtos de software, ocorreu graças à criação de nave-
gadores web, que dispunham de capacidade para executar programas de
menor escala e fazer algum modelo de processamento local. Em vez de o
software ser escrito para então ser instalado nos computadores dos usuá-
rios clientes, ele passou a ser implantado diretamente no servidor web.
Consequentemente, ficou mais barato atualizar o software. Alguns negó-
cios passaram a realizar a interação web diretamente com os sistemas de
software da organização.
Percebe que, hoje, com os avanços da tecnologia, as informações são com-
partilhadas em escala globalizada? O software, amplamente tratado como um
produto, hoje é visto também como um serviço. Diante disso, a ideia de exe-
cutar um software dentro de computadores locais é descartada e um novo
conceito passa a ser inserido: as nuvens computacionais.

EXPLICANDO
Segundo o entendimento de Sommerville (2011, p. 8 e 9), o conceito de
nuvem computacional trata de um grupo numérico de sistemas compu-
tacionais que se interligam e são compartilhados entre vários usuários.
Nesse novo modelo, os usuários não necessitam adquirir o software,
mas pagam à medida que os utilizam. Uma segunda possibilidade é
o acesso gratuito, geralmente em troca de propagandas exibidas em
suas telas.
Como é possível perceber, houve uma clara mudança na organização do

software corporativo graças ao surgimento da internet. Se antes dela as aplica-
ções corporativas ocorriam, em sua imensa maioria, de maneira isolada, agora
existe uma grande distribuição de softwares em escala global. Logicamente,
essa mudança na organização do software provocou alterações na forma como
os sistemas web são planejados. Primeiramente, observa-se que a construção
de um sistema web está baseada na reutilização de um software preexisten-
te. Outro aspecto é que especificar todos os requisitos a serem utilizados de
maneira antecipada é algo defasado na atualidade, ou seja, os sistemas web
precisam ser desenvolvidos e disponibilizados de forma incremental.
Mitos e desafios do desenvolvimento de software

Até aqui, fomos capazes de discutir conceitos básicos
de software e vimos como a área de engenharia de
software conseguiu se desenvolver ao longo dos anos.
Entretanto, como já mencionado, não existe ainda um
conjunto de técnicas e métodos padronizados utilizados no
desenvolvimento de software, apesar de haver alguns crité-
rios no momento da criação dos mesmos.
Outro ponto a ser discutido está relacionado à falta de expe-
riência profissional no gerenciamento de projetos ligados à criação de softwa-
re, além das resistências ao uso de técnicas novas na produção deles. Contudo,
podemos considerar essas afirmativas mitos? Quais são os desafios na produ-
ção e no desenvolvimento de softwares? Essas questões serão respondidas
nas próximas seções.

Mito de gerenciamento
Imagine uma empresa que disponha de um conjunto de manuais. Neles,
estão contidos alguns procedimentos e padrões que auxiliam no desenvolvi-
mento de um software. Em condições assim, é possível afirmar que a equipe
da área responsável vai realizar o desenvolvimento de maneira satisfatória.
Verificou-se que a tal da equipe utiliza métodos modernos de desenvolvimento
de software, já que os seus computadores são de última geração. Agora, pense
na possibilidade de o desenvolvimento do software estar em atraso, e que au-
mentar o número de integrantes na equipe pode solucionar o problema.
Diante da situação hipotética acima, podemos realizar algumas considera-

ções relevantes. Primeiro, é importante ressaltar que os conhecimentos inseri-
dos nos manuais devem ser efetivamente aplicados, desde que estejam alinha-
dos às práticas de desenvolvimento de softwares atuais, prevendo situações
que poderão surgir durante todo o processo. Segundo, quanto à relação das
técnicas de desenvolvimento de software com o uso de computadores moder-
nos, não há nenhuma garantia de que haverá um software desenvolvido com
qualidade, pois são as ferramentas de automatização do desenvolvimento de
software que possibilitam isso. Terceiro, no que diz respeito ao aumento de
integrantes na equipe para sanar atrasos, pode-se afirmar que é preciso que os
profissionais envolvidos no projeto em andamento ofereçam um treinamento
para os novos integrantes. O resultado disso será o atraso na entrega do pro-
duto e possíveis aumentos nos custos do projeto.

Mito do cliente
Em uma situação hipotética, um desenvolvedor deseja mais detalhes do
cliente para o software que irá criar, mas o cliente apenas fornece a descrição
geral dos requisitos. Outro aspecto a ser observado está relacionado aos requi-
sitos do projeto, que são alterados com certa frequência. No entanto, isso não é
tratado como um problema, já que o software tem por característica ser flexível
e suportável a mudanças.
Não detalhar o projeto, na sua concepção, é considerado uma das principais

razões para o fracasso. Definir desempenho, funções, critérios de validação,
dentre outros, são quesitos essenciais para o êxito de um determinado projeto
de software. Quanto à flexibilidade do software, não se pode desconsiderar o
fato de que cada alteração que surge nos requisitos do projeto gera um aumen-
to nos custos e, consequentemente, no cronograma de entrega. Portanto, é
preciso ter cuidado no momento de avaliar até onde é viável realizar alterações
no escopo do projeto.

Mito do profissional
Suponha agora um projeto de software já desenvolvido. Após a edição
realizada e a disponibilização ao cliente, o trabalho foi considerado como en-
cerrado. Existe também uma segunda hipótese: o software não está em fun-
cionamento ainda, o que impossibilita a análise da qualidade. A outra tese a
ser analisada é que a entrega do produto ao final do projeto significa que o
programa está em funcionamento.
Desmistificando essas afirmativas, pode-se afirmar outra coisa: a manu-
tenção do software, que ocorre após a entrega ao cliente, representa a etapa
de maior esforço por parte dos desenvolvedores. Quanto à qualidade, é con-
sensual que ela deva fazer parte de todas as etapas do desenvolvimento, e
que haja revisão ao fim de cada uma dessas etapas. Em relação ao programa,
trata-se de um dos componentes do software em que um bom projeto está
condicionado a um conjunto de importantes documentos.
Fundamentos dos processos de desenvolvimento do

software
É perceptível que um projeto é constituído por uma série de processos for-
mados por um conjunto de atividades que são realizadas de maneira sincroni-
zada ou organizada. Caracteriza-se por se tratar da elaboração de um produto
ou serviço. Associando esse conceito à produção de um software, percebe-se,
que este normalmente é intangível, apresentando um conjunto de variações e
incertezas, o que o torna complexo, dificultando o seu desenvolvimento e con-
sequentemente a sua qualidade.
Diante desse cenário, tonou-se importante a inclusão de temas relacionados
à Engenharia no desenvolvimento de software, pois ela permite a um gestor, o
fortalecimento de práticas para adquirir um produto de software que atenda aos
requisitos de qualidade. Essa área vai englobar três componentes considerados
fundamentais: as técnicas, as ferramentas e o procedimento.
Nas subseções a seguir, trataremos das dificuldades encontradas nos pro-
cessos de desenvolvimento de software e os conceitos fundamentais dos seus
processos e projetos de elaboração.

Dificuldades encontradas nos processos de
desenvolvimento de software
Os processos de desenvolvimento, quando executados de modo correto,
tendem a receber uma relevância maior dentro das organizações empresariais
à medida que estas elevam o seu patamar. Se observarmos bem o cenário em-
presarial dos dias atuais, veremos que o controle dos projetos corre sérios ris-
cos devido à falta de organização na aplicação dos procedimentos.
Logicamente, no início das atividades de qualquer empresa, os projetos são
considerados mais simples e exigem pouco esforço por parte das equipes, mas
a tendência natural é que esses projetos passem a demandar uma maior capa-
cidade de gestão. Portanto, no decorrer deste tópico, serão expostos conceitos
que tratam do processo de desenvolvimento de software, o ciclo de vida tradi-
cional dele, dentre outros assuntos.
Ao longo dos capítulos estudados, você pôde entender que o desenvolvi-
mento de um software não ocorre de maneira isolada, pelo contrário, ele é o
resultado de um conjunto de processos que envolve diversas ações. Quando
esse processo requer planejamento e moderação no uso dos recursos, ele tra-
rá segurança ao desenvolvimento.
EXPLICANDO
Baseado no agrupamento de conceitos disponibilizados pela literatura,
Maitino Neto (2016, p. 20) define processo como “a sequência de passos
que visam a produção e manutenção de um software e que se inter-rela-
cionam com recursos (humanos e materiais), com padrões, com entradas
e saídas e com a própria estrutura da organização”
Definição de projeto x definição de processo

É comum que haja dúvida no uso de termos e confusão entre os conceitos
de projetos e processos. Projeto, segundo o entendimento do Guia do conhe-
cimento em gerenciamento de projetos, tem um caráter temporário em que as
atividades realizadas visam a criar algum produto ou serviço para atender a
um determinado fim. Já um processo define as normas e regras de como será
a execução de um projeto. Normalmente, um processo é adotado pela ideia de

aperfeiçoamento por parte dos colaboradores à medida
que o projeto é desenvolvido.
Segundo Wazlawick (2013) citado por Maitino Neto
(2016, p. 21), podem ser observadas algumas vantagens
ao se definir a ação de desenvolvimento de software como
um processo. Ele trata, primeiramente, da diminuição no
tempo de treinamento, pois a definição e documentação dos
procedimentos e funções auxiliam na inserção de um novo mem-
bro à equipe de trabalho. Outro ponto se refere à uniformização da produção
dos artefatos, pois a condição de prever o processo condiciona a equipe a atuar
de maneira mais padronizada. Para o autor, as experiências eram transforma-
das em valor, pois a utilização do procedimento de uma forma mais sistemática
leva a um aperfeiçoamento ao longo do tempo.
No que se referem às divisões existentes na estrutura, algumas podem ser
analisadas – como as fases, que são adotadas em uma das etapas do proces-
so e consistem em um conjunto de tarefas afins, com metas bem definidas.
Se considerarmos o Modelo em Cascata de desenvolvimento, por exemplo, as
fases são bem estabelecidas. A segunda divisão se refere às atividades, ou ta-
refas, que são um projeto pequeno visando a incitar mudanças nos artefatos
do processo. Normalmente, as atividades demonstram possuir desde entradas
até recursos bem definidos.
Diante de regras processuais, a empresa pode estabelecer que seja ado-

tado um documento que exponha a atividade. É por meio dele que a equipe
conhece a tarefa, os seus responsáveis, os objetivos e tudo o que a distingue

por completo. É importante lembrar que um processo representa um conjunto
com características disciplinares e de articulação das tarefas, que possui a fun-
ção de sistematizar o desenvolvimento de software.
Esse modelo de processo é genérico, ou seja, é estabelecido e implemen-
tado pela empresa, o que representa a sua filosofia de trabalho. Entretanto,
certos modelos de processos, os ditos prescritivos, apresentam descrições da
forma como as atividades são executadas.
Processo de software
Até aqui, você já pôde perceber o quanto a engenharia de software evoluiu
ao longo dos anos. Agora, veremos como ocorre o processo de desenvolvimen-
to de um software. Para Sommerville (2011, p. 18), um processo de software
consiste em “um conjunto de atividades relacionadas que levam à produção de
um produto de software”.
Esse conjunto de atividades, ao qual Sommerville se refere, pode viabilizar o
desenvolvimento de software partindo do zero por meio de uma linguagem de
programação padrão – que pode ser o Java ou C, por exemplo. Porém, quando se
tratar de aplicações direcionadas a negócios, a forma de desenvolvimento é dife-
rente, pois os novos softwares de negócios são criados por extensão e manipu-
lação de sistemas já desenvolvidos. Outra maneira de criar esse tipo de software
é por meio da chamada integração de prateleira e configuração, ou através dos
componentes do sistema.
Nós já vimos que os softwares, por regra, não são padronizados. Portanto,
os processos de desenvolvimento também apresentam aplicações diversifi-
cadas. Mas existem basicamente quatro tarefas, ou atividades, consideradas
fundamentais na área de engenharia de software, que todo processo de desen-
volvimento deve incluir. São elas:
CURIOSIDADE
As atividades que compõem o processo de software, do ponto de vista prático,
são classificadas como complexas, pois elas também incluem algumas tarefas
secundárias, como a validação de requisitos ou até mesmo um projeto de ar-
quitetura. Paralelo a isso, são aplicadas as atividades que auxiliam o processo,
como o gerenciamento de configuração de software e a documentação.

• Especificação de software: Determina que devem ser definidas as funcio-
nalidades do software e as limitações do seu funcionamento;
• Projeto e implementação de software: Indica que o desenvolvimento de
um software tem o objetivo de atender às especificações;
• Validação de software: Para garantir que as demandas do cliente serão
atendidas, é necessário validar o software;
• Evolução de software: As necessidades e mudanças fazem com que o
software evolua.
Discutidos os processos e as atividades que são desenvolvidas neles, temos
que mencionar as descrições de um processo de software. Essas descrições po-
dem incluir os produtos, que são obtidos por meio das atividades do processo;
papéis, que tratam das atribuições dos profissionais envolvidos no processo; e
as pré e pós-condições, que são análises realizadas antes e depois da aplicação
de uma atividade do processo ou da criação de determinado produto.
Como podemos observar, a implantação de um processo de software não
é simples. Envolve, além das características já mencionadas, muita criativida-
de e capacidade intelectual. Sendo assim, é necessário que as pessoas tomem
decisões e façam avaliações constantes. Devido à constante evolução na área
de engenharia de software, não é possível definir que processo é considerado
o ideal para uma determinada organização empresarial, até porque, a maio-
ria das empresas é responsável pelo próprio processo de criação de software.
O importante é entender que esses processos têm evoluído com o intuito de
extrair o que há de melhor das pessoas dentro das empresas e dos aspectos
específicos do sistema.
É preciso fazer uma ressalva: a ideia de não haver o processo ideal para o
desenvolvimento de software não impede que as organizações busquem me-
lhorá-lo. Ainda é comum que as empresas usem processos com métodos ul-
trapassados, o que impedem que elas usufruam de técnicas mais recentes da
engenharia de software.
DICA
Nas empresas onde a diversidade nos processos de software é limitada, o
ideal é padronizá-los. Isso gera uma comunicação mais clara, uma redução
significativa do período de treinamento, além de tornar o processo automa-
tizado mais econômico.

Análise dos modelos de processos de software
Todo processo de software pode ser representa-
do de maneira simplificada por um modelo. Este
apresentará um aspecto particular do processo
em si, ou seja, sempre fornecerá informações sucin-
tas do mesmo. Dentro do ramo da engenharia de soft-
ware, existe uma série de modelos gerais de processos
que são formulados partindo de uma perspectiva rela-
cionada à sua arquitetura. Como você pode notar, é possí-
vel ter acesso ao framework do processo, mas as tarefas mais
privativas não são disponibilizadas.
É importante frisar que esses modelos generalistas, ou genéricos, não po-
dem ser entendidos como definições determinantes dos processos de soft-
ware. Devemos imaginá-los como amostras utilizadas para tratar das mais
variadas definições relacionadas ao desenvolvimento de software. Na verda-
de, eles podem ser vistos como frameworks de processos, que estão sujeitos
a uma ampliação ou até mesmo uma adaptação, no intuito de gerarem pro-
cessos mais exclusivos dentro da área de engenharia de software.
Para que você se familiarize com o tema, apresento os modelos conside-
rados mais relevantes, que serão detalhados mais adiante. De imediato, fala-
remos sobre o Modelo em Cascata, que abrange tarefas básicas do processo,
que são, segundo a conceituação de Sommerville (2011, p. 19), a especifica-
ção, o desenvolvimento, a validação e a evolução. Para o autor, cada uma
dessas atividades representa uma etapa distinta.
O segundo modelo é o chamado de Desenvolvimento Incremental, que
trata da relação existente entre as atividades de especifi cação, desenvol-
vimento e validação. Você vai verifi car que o sistema é criado como uma
série de versões e que cada versão implantada acrescenta funcionalidade à
anterior. O terceiro modelo é referente à engenharia de software orientada
a reúso – trata dos componentes reusáveis na elaboração de um novo soft-
ware. Basicamente, o processo de desenvolvimento do sistema vai realizar
a junção desses componentes em um sistema pronto, descantando a ideia
de iniciá-lo do zero.

Depois de definidos os modelos, você pode estar se perguntando: eles
atuam isoladamente? A resposta é: nem sempre. Não existe exclusividade
neles; muitas vezes atuarão em conjunto, principalmente quando houver o
desenvolvimento de sistemas em uma escala maior.
O Modelo em Cascata
É possível relacionar o desenvolvimento de um software com os con-
ceitos da engenharia de sistemas? Não só é possível, como Royce (1970)
citado por Sommerville (2011, p. 20) indica como a publicação do primei-
ro modelo do processo de desenvolvimento de software se originou dos
processos mais generalistas da engenharia de sistemas. Caracterizado
pelo encadeamento existente entre as etapas do processo, esse modelo
é classificado como Modelo em Cascata, ou simplesmente “Ciclo de vida
de software”. O processo dele é orientado a planos, ou seja, inicialmente,
é preciso realizar planejamento e programação de todas as atividades do
processo antes de realizá-las.
O Modelo em Cascata é subdividido em estágios que abordam tarefas fun-
damentais para o seu desenvolvimento. São eles:
• Análise e definição de requisitos: Nesta etapa, as metas, as limitações e
os serviços disponibilizados são instituídos através de consulta aos usuários.
Posteriormente, eles são estabelecidos em detalhes e atuam como uma espe-
cificação do sistema;
• Projeto de sistema e software: É por meio da arquitetura geral do sistema
que o processo de projeto de sistemas consegue inserir atributos, seja para sis-
temas hardware como software;
• Implementação e teste unitário: Estágio em que o projeto do software é
produzido em paralelo com uma série de programas ou as chamadas unidades
de programa. Quanto ao teste unitário, é definido como a constatação de que
cada unidade está respeitando a sua especificação definida;
• Integração e teste de sistema: Momento da integração e teste entre
unidades do programa ou programas como um sistema completo. O objetivo
é garantir que os atributos tenham sido atendidos. É somente após esse pro-
cesso que o sistema de software é disponibilizado ao cliente.

• Operação e manutenção: É considerada a fase mais extensa do ciclo de
vida. A manutenção trata do reparo de falhas que não foram observadas ao
longo dos estágios iniciais do modelo. Espera-se, nesta fase, uma evolução da
implementação das unidades do sistema e um aumento da disponibilidade de
serviços.
DIAGRAMA 1. MODELO EM CASCATA
Definição de
requisitos
Projeto
de sistema
e software
Implementação
e teste unitário
Integração e
teste de sistema
Operação e
manutenção
Fonte: SOMMERVILLE, 2011, p. 20. (Adaptado).
DICA
O resultado alcançado em cada estágio representa a aprovação dos docu-
mentos. Cada estágio alcançado é a continuação de outros, portanto, não
pode ser iniciada uma fase sem a conclusão da anterior. Por conta das
informações passadas entre as etapas, cada estágio funciona na prática
como uma espécie de feedback do estágio anterior, o que pode levar a
alterações nos documentos produzidos em cada fase.

Como você pode reparar, existe uma
complexidade no processo de criação
de um software, não só por questões
técnicas, mas também por envolver
custos. Podem ocorrer situações em que
a aprovação de documentos e os custos
relacionados à produção do software tornem as
iterações extremamente custosas e gerem um
retrabalho extenso.
Em situações como essas, o que pode ser
feito? Normalmente, depois de algumas itera-
ções, recomenda-se “congelar”, ou seja, interrom-
per áreas do desenvolvimento e partir para outros estágios em seguida.
De imediato, será adiada, programada ou simplesmente ignorada a reso-
lução dos possíveis problemas. É claro que ações como esta, ainda mais se
forem realizadas de maneira abrupta, normalmente resultam em sistemas
estruturalmente falhos.
Um ponto interessante a ser exposto é o fato de o Modelo em Cascata
apresentar um nível elevado de consistência, quando relacionado a outros
modelos de processos de Engenharia. Outra característica se deve ao fato de
a documentação desse modelo ser confeccionada em cada etapa do ciclo. A
vantagem disso é a possibilidade do processo se tornar visível e os gestores
ou gerentes conseguirem acompanhar a evolução graças ao plano de desen-
volvimento. Em contrapartida, não há flexibilidade na divisão do projeto, nas
diferentes etapas. Observa-se que os acordos são firmados na etapa inicial do
processo, dificultando possíveis alterações de atributos dos clientes.
DICA
Quando os requisitos são bem definidos e apresentam baixa possibilidade
de alterações bruscas no momento do desenvolvimento do sistema, o
Modelo em Cascata pode ser utilizado. Entretanto, esse modelo expõe o
tipo de processo empregado em outros projetos de engenharia, conforme
aborda Sommerville (2011, p. 21). Processos de softwares que utilizam o
Modelo em Cascata ainda são frequentemente utilizados, uma vez que é
fácil empregar modelos de gerenciamento que são comuns a todo projeto.

Quanto à análise das variações do Modelo em Cascata, é importante dis-
cutir sobre o conceito de desenvolvimento formal de um sistema. Caso você
não tenha nenhum conhecimento prévio na área de engenharia de software, é
nesse instante que é desenvolvido um modelo matemático extraído de uma es-
pecificação do sistema. Após a extração, o modelo passa por um procedimento
de aprimoramento por meio de manipulações matemáticas que mantêm a sua
essência em código executável. Modelos assim servem como argumentos para
justificar a consistência de um programa desenvolvido.
Vale salientar que os processos formais de desenvolvimento são, em parti-
cular, adaptados para a produção de sistemas com exigentes requisitos de pro-
teção, confiança e segurança. A criação de fatos relacionados à segurança ou à
proteção é simplificada por uma abordagem mais formalizada, apresentando
aos clientes a ideia de que o sistema de fato preenche as condições necessárias
de segurança e proteção. Já os processos referenciados em mudanças formais
são comumente empregados, exclusivamente, na elaboração de sistemas con-
siderados críticos, relacionados à segurança ou à proteção.

Desenvolvimento incremental
Trata-se de um modelo de processo de software que deseja, inicialmente,
uma implementação e, em seguida, exibi-la aos comentários dos usuários e
prosseguir através do desenvolvimento de diversas versões, até o momento
em que um sistema considerado propício seja de fato concebido. Uma ressalva:
não há separação entre as atividades de especificação, desenvolvimento e va-
lidação, em que as mesmas se mantêm intercaladas entre si. É perceptível um
breve feedback entre todas as atividades.
DIAGRAMA 2. MODTELO DE DESENVOLVIMENTO INCREMENTAL
Versão
Especificação
inicial
Descrição Versões
do esboço Desenvolvimento
intermediárias
Versão
Validação
final
Observando os dois modelos de processo de software até agora estuda-

dos, ficam algumas dúvidas: qual deles é o melhor modelo para ser aplicado?
Cascata ou Desenvolvimento Incremental? Sabendo que o Desenvolvimento
Incremental de software é considerado um elemento essencial das chamadas

abordagens ágeis, o mesmo é analisado como superior ao Modelo em Cascata
no que se refere à imensa maioria dos sistemas de negócios, pessoais e de
e-commerce, por exemplo.
Fazendo uma analogia com a nossa vida pessoal, o Desenvolvimento
Incremental consegue, mesmo que simploriamente, demonstrar como so-
lucionamos problemas cotidianos. Dificilmente conseguimos organizar a
resolução de um problema de maneira completa e antecipadamente. Isso
envolve um direcionamento gradativo em direção a uma solução; além dis-
so, cada vez que é cometido algum erro, recuamos. Ao trazermos essa ideia
para o desenvolvimento de um software de maneira incremental, fica
mais barato e menos complexo realizar alterações de software no período
do seu desenvolvimento.
CURIOSIDADE
Uma versão do sistema, ou até mesmo um incremento, incorpora alguma
funcionalidade essencial para o cliente. Normalmente, os incrementos iniciais
incluem o que é mais importante na sua funcionalidade. Nessa condição, o
cliente consegue analisar o sistema na sua fase inicial de desenvolvimento e se
verifica se o que está sendo oferecido é, de fato, o que foi solicitado. Havendo
disparidade, apenas o incremento que se encontra em desenvolvimento será
alterado. Provavelmente, uma nova funcionalidade será estabelecida para
incrementos posteriores.
Existem outras vantagens que são consideradas importantes, quando com-

paramos o modelo de desenvolvimento incremental com o Modelo em Casca-
ta. São elas:
1. O modelo incremental apresenta um custo menor de acomodação às altera-
ções nos requisitos do cliente, além de apresentar uma quantidade menor de avalia-
ções e documentação a ser refeita.
2. A relação cliente e desenvolvedores é mais estreita, uma vez que é mais
simples obter um retorno dos clientes sobre a qualidade do produto, por exem-
plo. Os clientes têm plena condição de criar comentários ou sugestões relacio-
nadas ao desempenho do software e verificar o grau de implementação.
3. A entrega e implementação célere de um software necessário ao cliente
pode ser realizada independente se a funcionalidade total não for incluída. É

permitido aos clientes o uso e a possibilidade de
ganhos através do software inicial de maneira
antecipada em relação ao processo em cascata.
Mesmo com a observação de uma série de
vantagens no uso do Modelo de Desenvolvimento
Incremental, essa abordagem apresenta basicamente
dois problemas, se analisarmos a sua aplicação sob o
aspecto do gerenciamento. São eles:
1. Não existe visibilidade no processo, ou seja, são
necessárias entregas periódicas para que os gestores con-
sigam avaliar a evolução dos processos. Existe uma relação inversa entre o
desenvolvimento do sistema com a rapidez e a produção de documentos, em
que, quanto maior for o primeiro, menos economicamente viável é a produção
do segundo;
2. A degradação da estrutura do sistema por conta do acréscimo de novos
incrementos, ou seja, as mudanças constantes podem comprometer a sua es-
trutura, dificultando futuras alterações no software.
Cabe aqui mais um questionamento: qual seria o comportamento do Mo-
delo de Desenvolvimento Incremental diante de um sistema mais complexo?
Bem, analisando os problemas do modelo, é possível verificar que eles são, em
particular, bastante críticos, quando se trata de sistemas de alto grau de com-
plexidade e é possível visualizar a ação de diversas equipes desenvolvendo
diferentes partes do sistema.
Engenharia de software orientada a reúso

Temos falado muito, ao longo da unidade, sobre o fato de que um há uma
dificuldade de reaproveitar características de um software na formulação de
um novo. Entretanto, esse quadro começou a mudar e passamos a observar
que a maioria dos projetos de software estão apresentando algum reúso de
software. Muitas vezes isso ocorre de modo informal. Imagine um grupo de
pessoas envolvido em um determinado projeto. Geralmente, eles conhecem
códigos ou projetos similares ao que está sendo exigido. O próximo passo será
buscar, alterar e incorporar esses elementos aos sistemas.

CURIOSIDADE
O reúso informal tem as suas práticas conhecidas, seja qual for o processo de
desenvolvimento utilizado. No século XXI, os processos de desenvolvimento
de software focados no reúso passaram a ser amplamente utilizados. As suas
abordagens necessitam de uma extensa base de componentes reusáveis de
software, além de um framework de integração para compor os mesmos.
O estágio de particularização de requisitos iniciais e o estágio de validação

são comparáveis, se os relacionarmos a outros processos de software. Porém,
quando nos referimos aos estágios considerados intermediários e direcioná-
-los a um processo orientado ao reúso, podemos verificar a diferença. Quanto
a esses estágios, podemos defini-los como:
1. Análise de componentes: Definida a especificação de requisitos, é rea-
lizada uma pesquisa por componentes, com o objetivo de implementar essa
particularização. Geralmente, não existe uma correspondência exata e os com-
ponentes que podem ser utilizados só disponibilizam alguma funcionalidade
quando necessário;
2. Modificação de requisitos: Observa-se que, durante esta fase, os atri-
butos são avaliados utilizando as informações sobre os elementos que foram
encontrados. Posteriormente, eles serão alterados para refletir os componen-
tes que se encontram à disposição. Havendo situação em que as alterações são
impraticáveis, a tarefa de análise dos elementos pode ser reinserida na busca
por saídas alternativas;
3. Projeto do sistema com reúso: Observa-se que nesta etapa os desen-
volvedores projetam o framework do sistema ou algum componente será reuti-
lizado. A ideia dos projetistas é selecionar os elementos que serão reusados e,
posteriormente, organizar os frameworks para serem reusados. É importante
lembrar que pode haver a necessidade de usar alguns softwares, caso os ele-
mentos reusáveis não se encontrem à disposição;
4. Desenvolvimento e integração: Pode haver situações em
que os softwares não são adquiridos externamente. Em
situações como essa, os softwares serão desenvolvidos
pela própria organização, na qual os elementos e os
sistemas (COTS) passam pelo processo de integração
para a geração de um novo sistema.

DIAGRAMA 3. APLICAÇÃO DA ENGENHARIA DE SOFTWARE ORIENTADA A REÚSO
Projeto de
Especificações Análise de Alterações nos
sistema com
e requisitos componentes requisitos
reúso
Desenvolvimento Validação de
e integração sistema
Fonte: SOMMERVILL, 2011, p. 23. (Adaptado).
Quanto aos tipos de componentes de software utilizados nos processos orien-

tados a reúso, podemos destacar primeiramente os web services, que são desen-
volvidos com base nos padrões de serviço e se encontram disponíveis para invo-
cação remota; as coleções de objetos que são geradas com o objetivo de serem
integrados com um framework de elementos; e os sistemas de software (stand-alo-
ne) que são manipulados para serem utilizados em ambiente específico.
É importante deixar claro que a engenharia de software orientada a reúso
deseja diminuir de maneira significativa a quantidade de software que são de-
senvolvidos e, consequentemente, restringir custos e riscos. A tendência natu-
ral dessas ações é promover uma entrega mais rápida do software ao cliente
final. Porém, não é possível abrir mão dos atributos do sistema, ou seja, que o
mesmo esteja funcionando em perfeitas condições. O não atendimento des-
ses requisitos pode gerar um sistema que consegue solucionar as demandas
dos usuários de maneira plena. Lembrando, também, que a evolução do soft-
ware provoca uma perda de controle, já que as versões mais atualizadas dos
elementos reutilizáveis não se encontram sob a supervisão das empresas que
estão utilizando os softwares.

Atividades do processo de software
Para que os processos de software sejam bem-sucedidos, é necessário o
auxílio das atividades utilizadas. Essas atividades, que atuam na área técnica,
de colaboração e gerência, são dispostas de forma sequencial e intercaladas
aos chamados softwares reais. Eles têm o objetivo de cuidar desde a especifi-
cação até o teste de um sistema de software.
Você pode imaginar que os de-
senvolvedores de software utilizam
uma série de métodos e técnicas para
realizar o seu trabalho. Essas técnicas
são aplicadas, especificamente, para
auxiliarem, por exemplo, na manipu-
lação de diversos modelos de docu-
mentos, ao mesmo tempo que geram
um extenso conjunto de informações
abrangentes provenientes de gran-
des projetos.
Quanto à visualização das ativida-
des básicas do processo (especifica-
ção, desenvolvimento, validação e evolução), é preciso entender que elas são
estabelecidas de maneiras distintas a depender do processo de desenvolvi-
mento aplicado. Em um Modelo de Desenvolvimento Incremental, a organi-
zação das atividades ocorre de forma intercalada, enquanto no Modelo em
Cascata elas estão dispostas em sequências. A forma como as atividades serão
realizadas está diretamente relacionada ao tipo de estrutura empresarial en-
volvida, às pessoas inseridas na atividade e ao tipo de software escolhido.
Especificação de software
Também conhecida como engenharia de requisitos, trata-se, segundo
Sommerville (2011, p. 24), de “um processo de entendimento e definição dos
serviços solicitados do sistema e reconhecimento de limitações relativas à
operação e ao desenvolvimento do sistema”. Podemos considerar que a es-

pecificação de software representa uma etapa bastante crítica do processo de
software, já que as falhas encontradas neste estágio já não conseguem evitar
problemas encontrados na implementação do sistema e no projeto.
EXPLICANDO
Produzir um documento de requisitos acertados que detalhe um sistema que
atenda aos atributos dos stakeholders é o principal objetivo do processo de
engenharia de requisitos.
O processo de engenharia de requisitos envolve quatro atividades princi-

pais. São elas:
• Estudo de viabilidade: A atividade consiste na criação de uma estima-
tiva que busque alternativas de satisfação das necessidades do cliente por
meio das recentes tecnologias de software e hardware. É preciso que você
compreenda que um estudo de viabilidade analisa as possibilidades de im-
plantação de um sistema partindo do ponto de vista do negócio. Entenda as
limitações no orçamento como possibilidades;
• Elicitação e análise de requisitos: Considere como um processo de de-
rivação dos atributos do sistema. Isso vai ocorrer por meio da avaliação dos
sistemas já existentes, e envolve uma série de etapas que vão desde a discus-
são com clientes e compradores considerados importantes até a verificação
de tarefas a serem executadas. O desenvolvimento de alguns modelos de sis-
temas pode ocorrer nesta etapa, auxiliando a compreensão do sistema que
será detalhado;
• Especificação de requisitos: Após a realização da análise de um do-
cumento que estabeleça um conjunto de atributos, o objetivo seguinte é
realizar a tradução das informações obtidas. Os requisitos inseridos em um
documento são classificados como requisitos do usuário, que na prática são
declarações de caráter abstrato dos atributos do sistema direcionados para
o usuário e ao cliente final. Já o requisito de sistema está relacionado a uma
exposição mais detalhada da funcionalidade apresentada;
• A validação de requisitos: Consiste na atividade de verificar se os re-
quisitos atendem às especificações solicitadas. É nesta fase que as falhas no
documento começam a ser expostas para, em seguida, serem corrigidas.

Portanto, você deve entender que as tarefas desempenhadas no pro-
cesso de requisitos não se restringem a uma sequência, apenas. Ela segue
durante a definição e especificação, enquanto novos requisitos surgem ao
longo do processo.
Projeto e implementação de software

Toda vez que você escutar ou fizer a leitura de assuntos relacionados à en-
genharia de software que trate de processo de conversão de uma determinada
especificação do sistema em um sistema executável, estaremos nos referindo
ao estágio (etapa) de implementação do desenvolvimento de software. Nesta
etapa, a programação de software e os processos de projeto estão completa-
mente inseridos. Entretanto, caso se empregue uma abordagem incremental
para o desenvolvimento, poderemos visualizar uma espécie de refinamento da
especificação do software.
Quando nos referimos a um projeto de software, é preciso ter em mente
que ele envolve uma série de descrições relacionadas a estruturas de dados
utilizados pelo sistema, modelos, algoritmos e até interfaces que se alocarão
entre os elementos do sistema. Logicamente, nenhum projetista chegará de
maneira imediata ao projeto final, pois se trata de um trabalho de desenvolvi-
mento iterativo.
A imensa maioria dos softwares que estão disponibilizados no mercado
mantém um nível de interação com outros sistemas de software, formando
a chamada plataforma de software. Mas o que de fato significa a plataforma
de software? É o ambiente, ou seja, o local onde o software será executado.
Consequentemente é necessário obter informações sobre essas plataformas,
pois elas são fundamentais para começar o desenvolvimento do processo do
projeto, já que cabe aos projetistas escolher a maneira mais adequada de inte-
grá-las ao ambiente de software.
Existe uma variada quantidade de tipos de sistemas que podem ser desen-
volvidos. Sendo assim, há também uma diversidade de atividades no processo
de projeto. Algumas dessas atividades podem compor o processo de projeto
de sistemas de informação. Estamos nos referindo, inicialmente, ao projeto de
arquitetura, no qual pode haver a identificação da estrutura geral do sistema,

seus elementos mais relevantes, as relações estabelecidas e ocorre a sua dis-
tribuição. Em seguida, vem o projeto de interface. Nele, é preciso definir quais
interfaces serão alocadas entre os componentes do sistema. Não pode haver
equívoco nessa alocação, onde a precisão da interface permite que um compo-
nente possa ser utilizado de forma que os demais não necessitem visualizar de
que maneira ele é implementado.
DIAGRAMA 4. MODELO GERAL DO PROCESSO DO PROJETO
Entradas de Atividades de
projeto projeto
Descrição de
dados
Projeto de
arquitetura
Informação de Especificações
plataforma e requisitos
Projeto de Projeto de
banco de dados componentes
Projeto de
Arquitetura Especificação de interface
do sistema componentes
Saídas de
projeto
Especificação de Especificação de
banco de dados interface
Mais adiante, surge o projeto de componente. Nessa atividade, é preciso

primeiro estabelecer cada componente do sistema e em seguida planejar o
seu funcionamento. Esse projeto pode ser uma declaração da funcionalidade
na qual se deseja implementar ou até mesmo uma lista de mudanças às quais

o componente reutilizável irá se submeter. Por fim, vem o projeto de banco
de dados, no qual as estruturas de dados do sistema são planejadas. Todo o
trabalho será executado baseado em um banco de dados a ser reutilizado, ou
simplesmente a partir da produção de um novo banco de dados.
Validação de software
Quando um software consegue se adaptar às suas especificações e, simul-
taneamente, atende às particularidades do cliente do sistema, ele passa por
um processo de verificação conhecido como validação do software. A princi-
pal técnica de validação empregada é o Teste de Programa, em que a execução
do sistema ocorre através de dados de testes simulados. Inspeções e revisões
são exemplos de processos de verificação da qual a validação pode se utilizar a
cada etapa do processo de software, podendo ocorrer desde o estabelecimen-
to dos atributos dos usuários até a criação do programa.
CURIOSIDADE
Em um procedimento de teste, os sistemas devem passar, no mínimo, por três
etapas. Primeiro, os componentes do sistema deverão ser testados. Depois, o
sistema integrado passa pelo mesmo processo. E, por fim, o sistema, propria-
mente dito, é testado, contendo os dados do cliente.
No que se refere aos estágios do processo, podemos defini-los como:

• Testes de desenvolvimento: Modelo de teste no qual os elementos que
compõem o sistema são testados pelos próprios profissionais que as criaram.
Os componentes são testados separadamente um dos outros e de maneira
totalmente independente;
• Testes de sistema: Observa-se que, neste tipo de teste, os componentes
do sistema são integrados para gerar um sistema completo. Tem o objetivo
de verificar possíveis falhas provenientes de interações inesperadas ocorridas
entre os elementos do sistema e problemas de interface do componente. Ocu-
pa-se em demonstrar que o sistema atende a seus requisitos, sejam funcionais
ou não funcionais;
• Testes de aceitação: Considerada a fase final dos testes, antes que o sis-
tema passe a ser utilizado operacionalmente, o teste de aceitação utiliza dados

disponibilizados pelo cliente. Esse teste pode apresentar falhas e omissões na
definição dos requisitos do sistema.
DIAGRAMA 5. ESTÁGIOS DE TESTES
Teste de Teste de Teste de

componente sistema aceitação
Evolução do software
É cada vez mais comum a adoção de softwares
dentro das organizações empresariais em detri-
mento do uso do hardware ao longo dos anos. Mas,
qual seria o grande diferencial do software? Ao longo
dos tópicos, você pode constatar as inúmeras vantagens
de se adotar um software dentro das empresas e como
a engenharia de software tem se desenvolvido de manei-
ra extensa. Entretanto, uma característica explica toda essa
ascensão: a flexibilidade.
Sem dúvida, a flexibilidade, característica dos sistemas de software, é con-
siderada um dos principais motivos pelos quais os softwares são incorpora-
dos, em grande escala, aos maiores e mais complexos sistemas. Produzir um
hardware se torna muito caro na medida em que se deseja realizar alterações
no projeto inicial. Porém, as transformações podem ser feitas no software, a
qualquer tempo, independentemente do desenvolvimento do sistema, devido
ao baixo custo.

DIAGRAMA 6. EVOLUÇÃO DO SISTEMA
Definir requisitos Avaliar sistemas Propor mudanças Modificar

de sistema existentes de sistema sistemas
Sistemas Novo
existentes sistema
É preciso deixar claro que, do ponto de vista histórico, sempre existiu uma
espécie de separação conceitual sobre o que é processo de desenvolvimento e
o que é evolução do software (manutenção). Desenvolver ou criar algo é sem-
pre mais interessante do que consertar, você concorda? Na área de engenharia
de software não é diferente. As pessoas normalmente associam o termo de-
senvolvimento de software à etapa de criatividade na produção de um sistema,
partindo do seu conceito inicial até um sistema funcional. Já a ideia de manu-
tenção, mesmo com custos mais elevados, é vista como enfadonha ou maçante
por ser menos desafiadora que o desenvolvimento de software.
Entretanto, a separação entre esses conceitos é irrelevante, considerando
que os sistemas de software são, na sua maioria, novos, os conceitos de desen-
volvimento e a manutenção são vistos como processos contínuos, ou seja, ao
invés de separá-los, é mais concreto imaginar a engenharia de software como
algo único.

Sintetizando
A tecnologia de hardware foi superada a partir da década de 1950, quando a
criação de sistemas operacionais passou a ser a principal necessidade das em-
presas. Na década seguinte, aparecem sistemas operacionais com um maior
grau de eficiência e, consequentemente, provocou a necessidade do desenvol-
vimento de softwares em grande escala, substituindo os programas de menor
capacidade, que eram mais utilizados naquele instante. A transição desses pe-
quenos sistemas de softwares para os mais abundantes gerou a chamada crise
de software.
Ficou claro que não existe ainda um conjunto de ferramentas padronizado,
utilizado no desenvolvimento de software, mesmo havendo critérios para a
produção deles. Isso provoca falta de experiência profissional na gestão de
projetos ligados à criação de software, além das resistências ao uso de técnicas
novas na produção deles.
Dentro da área de engenharia de software, existem dúvidas quanto aos
conceitos de projetos e processos. O primeiro se refere a atividades que vi-
sam a criar algum produto ou serviço para atender a um determinado fim, le-
vando-se em consideração prazo, custo e qualidade. Já o segundo determina
as normas de execução de um projeto visando à padronização de determina-
das atividades com realimentação de informações em que houve falhas, afim
de melhorar os processos.
Também vimos as atividades fundamentais na área de engenharia de soft-
ware e que todo processo de desenvolvimento deve incluir a especificação de
software, o projeto e a implementação de software, a validação de software
e a evolução de software. Já as atividades essenciais do processo são apre-
sentadas de formas diferentes a depender do processo de desenvolvimento
aplicado. Em um Modelo de Desenvolvimento Incremental, por exemplo, a or-
ganização das atividades é intercalada, enquanto no Modelo em Cascata as
atividades ocorrem em sequência.

Referências bibliográficas
MAITINO NETO, R. Engenharia de software. Londrina: Editora e Distribuidora Edu-
cacional S. A., 2016.
SOMMERVILLE, I. Engenharia de software. Trad. Ivan Bosnic e Kalinka G. de O.
Gonçalves. 9. ed. São Paulo: Pearson Prentice Hall, 2011.

UNIDADE
2 MODELOS DE
SOFTWARE E
MÉTODOS ÁGEIS

Descrever a aplicação do modelo de processos e seus impactos nas
organizações empresariais;
Abordar os modelos contemporâneos de criação de software e suas

aplicações;
Apresentar as conceituações sobre métodos ágeis e suas implicações em

pequenas e grandes empresas.
Tópicos de estudo
Modelos de processos clássicos Métodos ágeis de desenvolvi-
de software mento
Modelo cascata Métodos ágeis
Modelo evolucionário Desenvolvimento ágil e dirigi-
Prototipação do a planos
Modelo espiral Gerenciamento ágil de pro-
Técnicas de quarta geração jetos
Combinando paradigmas Escalamento de métodos
Baseado em reúso
Incremental
RAD
Formal
Modelos de processos contem-

porâneos de software
Extreme Programming
Lean Software Development
DevOps

Modelos de processos clássicos de software
Bem, iniciamos o segundo capítulo e já conseguimos compreender os pri-
meiros conceitos referentes à engenharia de software e seus paradigmas. Os
problemas relacionados ao desenvolvimento de software não apresentam so-
luções imediatas – isso requer a identificação de suas causas, além da desmis-
tificação de algumas teses defendidas sobre o uso dos softwares. Lembre-se
que essas soluções precisam oferecer auxílio prático no desenvolvimento de
software, melhorando sua qualidade e possibilitando que suas práticas este-
jam em parâmetro com o desenvolvimento do hardware.
Você pode estar se perguntando por que não há uma solução mais abran-
gente em relação aos problemas de desenvolvimento de software. Primeiro, é
preciso compreender que não existe um método específico que traga essas so-
luções. Porém, a combinação de métodos que alcancem todas as fases do de-
senvolvimento do software nos condicionará a uma área que a estudará com
maior profundidade: a engenharia de software.
CITANDO
Segundo Pressman (1995, p. 30), a combinação de métodos associados
a um conjunto de ferramentas que os automatizem, a adoção de blo-
cos de construção mais poderosos na implementação do software, o
uso de técnicas melhores que garantam a qualidade do software e a
introdução de uma mentalidade que envolva coordenação, controle e
administração são os pilares necessários para o desenvolvimento da
A engenharia de software se baseia nos princípios da engenharia tradi-

cional. Seu principal objetivo é disponibilizar um software de baixo custo
que ofereça confiabilidade e eficiência quando for testado. Vale lembrar
que a engenharia de software abrange um conjunto formado por três com-
ponentes considerados fundamentais:
• Métodos – na prática, indica como desenvolver um software. Suas ati-
vidades envolvem planejamento e estimativa de projetos, além da ava-
liação de requisitos, passando por codificações, teste e manutenção;
• Ferramentas – oferecem apoio, seja de forma automatizada ou não;

• Procedimentos – são meios de ligação entre os métodos e as ferra-
mentas no desenvolvimento racional do software. Nesta etapa, são de-
finidas as sequências de aplicação dos métodos.
CURIOSIDADE
Uma informação gerada por ferramentas integradas possibilita que uma
utilize as informações de outra. Com isso, é criado um sistema de apoio
e desenvolvimento de software denominado Computeer-Aider Software
Engineering (Case).
Portanto, este conjunto de etapas (métodos, ferramentas e procedimen-

tos) forma o que chamamos de “paradigmas da engenharia de software”.
Mas, diante de diversas demandas, qual o melhor paradigma que pode ser
aplicado? Não é uma questão simples, pois envolve a adoção de uma série
de critérios do projeto, métodos que serão aplicados, produtos que serão
entregues etc.
Veremos, agora, de maneira mais detalhada, os principais paradigmas
(modelos) utilizados na engenharia de software e as aplicações práticas den-
tro das organizações.
Modelo cascata
Segundo Pressman (1995, p. 32), o modelo cascata (ciclo de vida clássico)
se origina de uma abordagem sistemática, sequencial ao desenvolvimento do
software. Inicia-se a um nível sistêmico, progredindo ao decorrer das fases
posteriores. Como já mencionado neste curso, o modelo cascata aborda algu-
mas atividades que formam o ciclo de vida clássico.
Vamos relembrar as etapas. Continuando com Pressman,
No que se refere à análise e engenharia de sistemas, é neces-
sário considerar o fato de que um software compõe um siste-
ma mais abrangente, portanto o seu efetivo trabalho se inicia
através da determinação de requisitos dos componentes dos
sistemas e continua com a atribuição de determinada subdivisão
destes requisitos ao software (Ibidem, p. 33).

Já a análise de requisitos de software se refere
à compreensão de que todo analista de software
deve ter domínio da informação, assim como os atri-
butos exigidos para entender a origem dos programas
a serem desenvolvidos. Já o projeto de software é um pro-
cedimento de diversas etapas, que se baseia na estrutura
de dados, nos detalhes procedimentais, na arquitetura de
software e na caracterização de interface (Ibidem).
A codificação trata da forma como o projeto será traduzido
e, a depender do detalhamento do projeto executado, a codificação se dará
mecanicamente. A etapa de testes do programa ocorre posteriormente à codi-
ficação, onde se espera que todas as instruções, sob o aspecto lógico interno,
sejam testadas. Nesta fase, os aspectos lógicos externos também devem ser
testados, a fim de, entre outras coisas, descobrir possíveis erros.
Por fim, é a manutenção que, prevendo possíveis mudanças que o software
sofrerá após a entrega ao cliente final, reaplicará as etapas precedentes do
modelo cascata. É preciso entender que as mudanças ocorrem devido à desco-
berta dos erros no software ou uma exigência do cliente referente à adição de
funcionalidade e desempenho.
Além disso, por ser o mais antigo dentro da engenharia de software, o mo-
delo cascata também é o mais utilizado. Entretanto, existe uma corrente de es-
pecialistas da área que criticam este modelo. O primeiro questionamento está
relacionado ao fato de que o fluxo sequencial proposto tem baixa aplicabilidade
quando se trata de projetos reais. Outro aspecto se refere ao cliente ter certa
dificuldade em declarar suas exigências de maneira explícita. O modelo cascata
não consegue absorver o grau de incerteza presente no início dos projetos. Daí
surge o conflito entre o que o cliente deseja e o que o modelo pode oferecer.
Vale deixar claro a você, leitor, que mesmo com esses problemas o modelo
cascata ocupa uma posição de suma importância dentro da área de engenha-
ria de software, já que consegue estabelecer um determinado padrão em que
podem ser inseridas as etapas que vão desde os métodos para análise até a
manutenção. Mesmo com as fragilidades que possa apresentar, o modelo cas-
cata é, sem dúvida, mais aplicável do que uma abordagem meramente casual
ao desenvolvimento de software.

Modelo evolucionário
Deparamo-nos quase diariamente com produtos e serviços que passam
por mudanças evolutivas com o tempo. Máquinas de datilografia foram
substituídas por computadores, que por sua vez apresentam confi gurações
cada vez mais avançadas, em tamanhos físicos cada vez menores (celulares,
iPads, tablets, entre outros). Nesse contexto, como todo sistema que apre-
senta certo nível de complexidade, o software também evoluiu à medida
que os anos passam.
Seja um estagiário ou um profissional experiente, é possível notar algumas
situações corriqueiras dentro do mercado. Por exemplo, os requisitos obser-
vados em negócios ou produtos estão propensos a se alterar constantemente,
à medida que o desenvolvimento avança. Consequentemente, o produto final
entregue passa por etapas extremamente complexas, nas quais os prazos são
reduzidos por exigência do mercado.
É inviável, dentro de um cenário como este, apresentar um produto de soft-
ware abrangente. Sendo assim, é possível criar uma versão reduzida do softwa-
re como forma alternativa para lidar com as pressões existentes em um negó-
cio ou enfrentar a competitividade. É nesse cenário, onde os requisitos básicos
de um produto ou sistema são bem definidos, mas que os detalhes referentes
a extensões do produto ou sistema necessitam de ajustes, que os modelos
evolucionários podem ser inseridos.
CURIOSIDADE
Devido a sua iteratividade, os modelos evolucionários se caracterizam pelo fato
de possibilitar ao profissional da área de engenharia de software criar versões
cada vez mais abrangentes em relação ao software. Eles conseguem identificar
a origem iterativa de boa parte dos projetos da área, e uma de suas atribuições
é suportar as possíveis modificações a que o software está suscetível.
Prototipação
Chamo você, caro leitor, a pensar na seguinte hipótese: um determinado
cliente conseguiu estabelecer uma série de objetivos gerais para o software
que deseja adquirir, entretanto, não foi possível definir, de maneira detalhada,

quais os requisitos de entrada, processamento e saída. Por outro lado, pode
haver na cabeça do desenvolvedor uma dúvida sobre o grau de eficiência do
algoritmo a ser usado ou como o sistema operacional consegue se adaptar.
Diante disso, recomenda-se o uso de uma abordagem de prototipação à enge-
nharia de software. Mas qual é a definição de “prototipação”?
Segundo a definição de Pressman (1995, p. 35), prototipação é “um pro-
cesso que capacita o desenvolvedor a criar um modelo de software que será
implementado”. Basicamente, este modelo está disposto de três formas:
• Um protótipo, que estará disposto em um modelo referenciado em PC ou
em papel, e irá apresentar a interação homem-máquina de maneira que per-
mita ao usuário entender como ocorrerá a interação;
• O protótipo de trabalho deve conseguir implementar subconjuntos da
função solicitada do software requerido;
• A observação de um programa que já existe utilizado para executar total
ou parcialmente a função solicitada, porém, possui atributos que serão ajusta-
dos à medida que o desenvolvimento do software se amplia.
Para você compreender esse conceito com maior clareza, observe a Fig. 1 a
seguir, referente à sequência de eventos para o modelo de prototipação:
Figura 1. Prototipação. Fonte: PRESSMAN, 1995, p. 36.

Observando a imagem, é possível tecer algumas considerações. De imedia-
to, verifica-se que a prototipação começa com a coleta e o refinamento de re-
quisitos. Isso significa que clientes e desenvolvedores de software estabelecem
as metas gerais para o uso do software, sinalizam as exigências, ao mesmo
tempo que projetam em quais áreas é obrigatória a definição adicional.
Posteriormente, ocorre o chamado “projeto rápido”, que tem como objetivo
representar as características de softwares que estarão facilmente visíveis ao
usuário, ou seja, aquilo que se refere às abordagens de entrada e formatos de
saída (PRESSMAN, 1995, p. 36). Tal projeto possibilita a elaboração de um pro-
tótipo que será analisado pelo cliente e utilizado para o filtro de requisitos que
possibilitarão a criação do software, em sua etapa final.
EXEMPLIFICANDO
Quando é realizada a “sintonia fina” do protótipo visando a, simultanea-
mente, atender as demandas do cliente e condicionar o desenvolvedor a
um entendimento mais abrangente das ações que precisam ser tomadas,
temos aqui um processo de iteração bem definido.
Partindo de um ponto de vista considerado ideal, podemos afirmar que um

protótipo funciona como método para reconhecer atributos de software; ou
seja, caso venha a ser elaborado um protótipo de trabalho, é possível que o de-
senvolvedor utilize partes de programas já construídos ou aplique técnicas que
viabilizem, de maneira rápida, os programas de trabalho.
Como você pode notar, o protótipo pode servir como uma espécie de “primeiro
sistema”. Entretanto, este modelo pode apresentar, assim como o modelo cascata,
uma série de problemas, das mais variadas motivações. Quando um cliente, por
exemplo, acredita ter visualizado uma determinada versão de trabalho do softwa-
re, mas não sabe que na ânsia de colocar o produto em funcionamento foi descon-
siderado, pelos desenvolvedores, aspectos como qualidade e manutenção.
Em situações assim, o produto precisa ser descartado para ser reconstruído.
Como alguns clientes não entendem que é um procedimento sacrificante em
relação a tempo e custo, porém natural em um processo de prototipação, geral-
mente eles exigem o melhoramento do sistema em vez do descarte de produto,
e acabam sendo atendidos pela gerência de desenvolvimento de software.

Outro problema são as concessões realizadas para que o protótipo seja
disponibilizado com maios rapidez. Em situações como essa, pode ser ado-
tada uma linguagem de programação inadequada ou algum algoritmo inefi -
ciente. Porém, o problema não é apenas esse: o desenvolvedor pode acabar
acostumando-se com essas opções e deixar de buscar soluções corretas para
adequar o software.
Dito isso, a que conclusão se pode chegar? Bem, a prototipação está entre
os modelos de maior relevância dentro da engenharia de software. É impor-
tante deixar claro que a relação cliente-desenvolvedor deve estar alinhada, e
as regras e determinações precisam ser acordadas entre as partes, para que o
protótipo seja desenvolvido e auxilie na definição dos requisitos.
Modelo espiral
Numa conceituação básica, o modelo espiral abrange os requisitos mais re-
levantes do modelo cascata e da prototipação e, entre eles, introduz-se a análi-
se de riscos, com o intuito de complementar o entendimento.
As quatro tarefas mais importantes desenvolvidas pelo modelo espiral po-
dem ser visualizadas na Fig. 2 a seguir:
Planejamento Análise dos riscos

Coleta inicial dos requisitos e Análise dos riscos baseada
planejamento do projeto nos requisitos iniciais
Análise dos riscos baseada na

reação do cliente
Planejamento baseado nos

comentários do cliente
Decisão de prosseguir/
não prosseguir
Avaliação do cliente
Na direção de um sistema
concluído
Protótipo de software
inicial
Protótipo no nível
seguinte
Avaliação do cliente Sistema construído

Engenharia
pela engenharia
Figura 2. O modelo espiral. Fonte: PRESSMAN, 1995, p. 39.

O primeiro quadrante refere-se ao planejamento e, como próprio nome su-
gere, busca estabelecer objetivos, limitações e sugestões. Em seguida, trata-se
da análise de riscos, na qual se busca avaliar as possibilidades e o processo de
sinalização e resolução dos riscos. O terceiro quadrante demonstra a engenha-
ria, que fala da geração do produto em um nível posterior. Por fim, a avaliação
do cliente, que vai buscar a avaliação dos resultados da engenharia.
Considerações relevantes podem ser feitas baseando-se na imagem e nos
conceitos abordados nela. Um cliente, por exemplo, pode realizar suas análises
dentro do quadrante de avaliação do cliente e sugerir alterações. Após esta
avaliação, é possível implantar ações relacionadas ao planejamento e à análise
de riscos, verificando se o projeto deve ou não prosseguir.
CURIOSIDADE
Considerada como a abordagem mais realística para gerar um sistema e
desenvolver um software em larga escala, o modelo espiral, ao utilizar a seu
conceito “evolucionário”, consegue promover uma interação entre desen-
volvedor e cliente, a fim de que ambos consigam compreender e dirimir os
riscos em cada fase evolucionária.
O modelo espiral requer um relevante nível de experiência quando se re-

ferir a uma análise de riscos. Um risco não descoberto ou mal avaliado gera
consequências danosas. Mas é preciso levar em consideração que se trata de
um modelo relativamente recente, se compararmos ao modelo cascata ou ao
prototipação. Ainda vai levar algum tempo para este modelo ter sua eficácia
plenamente reconhecida dentro das organizações.
Técnicas de quarta geração

Também conhecidas como 4GT, estas técnicas conseguem reunir um conjun-
to extenso de métodos de software que permitem ao desenvolvedor especificar
alguma característica do software em um nível mais elevado (PRESSMAN, 1995,
p. 41). Consequentemente, estes métodos criam automaticamente o código-fon-
te, baseados nas especificações determinadas pelo desenvolvedor. A lógica do
funcionamento é simples: se a especificação do software em uma máquina ocor-
rer num grau elevado, o programa será construído mais rapidamente.

CURIOSIDADE
O modelo 4GT especifica o software direcionado a uma máquina, nivelado
a uma linguagem natural. É possível também usar uma notação que trate de
uma função significativa.
O ambiente onde ocorre a criação de um software que utiliza

as técnicas de quarta geração emprega algumas ferramentas,
como a interação e definição de tela, manipulação de dados,
entre outras, lembrando que suas aplicações ocorrem de
maneira muito específica.
O modelo 4GT tem início com a coleta de requisitos.
Esta seria a etapa em que o cliente descreve os requisi-
tos, porém a possibilidade de ambiguidade do usuário
a torna inviável. O que fazer em situações como esta?
Quando envolver pequenas aplicações, é possível sair da
etapa de coleta de requisitos e se direcionar diretamente para a fase de imple-
mentação, por meio da “linguagem de quarta geração” (4GL). Entretanto, quan-
do envolver aplicações que necessitem de um esforço mais elevado, recomen-
da-se elaborar uma estratégia de projeto para o sistema, independentemente
da utilização da 4GL. É notório que sua aplicação sem o desenvolvimento de um
projeto trará os mesmos problemas visualizados quando o software é produzido
com abordagens convencionais.

DIAGRAMA 1. TÉCNICAS DE QUARTA GERAÇÃO (4GT)
Obtenção dos
requisitos
Estratégia do
projeto
Implmentação
usando 4GL
Testes
Fonte: PRESSMAN, 1995, p. 42.
A implementação do 4GL permite que o profissional que irá desenvolver

o software apresente os resultados desejados de maneira que se gere, de
forma automática, o código para produzi-los. Esta implementação pode se
transformar em produto à medida que o desenvolvedor conseguir realizar
testes mais criteriosos, produzir uma documentação signifi cativa e desen-
volver as demais atividades da transição, exigidas nos outros modelos de
Combinando paradigmas
Até agora, você visualizou que as abordagens relacionadas à engenharia
de software foram descritas como alternativas e não são complementares.
Em diversas situações, é possível combinar modelos de forma que a po-
tencialidade de cada uma seja obtida em um único projeto – quando, por
exemplo, o modelo espiral se combina ao de prototipação, assim como o
modelo cascata pode ser implementado ao evolucionário. O Diagrama 2

demonstra que os modelos podem ser combinados e direcionados ao de-
senvolvimento do software.
DIAGRAMA 2. COMBINANDO PARADIGMAS
Obtenção preliminar dos requisitos
Análise 4GT (técnicas de Modelo

Prototipação
de requisitos quarta geração) espiral
Projeto
4GT (técnicas de
quarta geração)
Codificação Prototipação:
enésima iteração
Modelo espiral:
enésima iteração
4GT (técnicas de
quarta geração)
Realização
de testes
Sistema operacional
Manutenção
Fonte: PRESSMAN, 1995, p. 42.
Observa-se que toda atividade começa estabelecendo objetivos, limitações

e alternativas. A partir daí, qualquer caminho pode ser percorrido. As fases do
modelo cascata (ciclo de vida), por exemplo, podem ser seguidas, desde que haja
especificações no sistema determinado no início do processo. Havendo incer-
tezas nos requisitos, utiliza-se um protótipo para defini-los de forma completa.
É importante frisar que, na escolha dos modelos para a engenharia de soft-
ware, não é necessário estabelecer dogmas. A origem da aplicação deve esta-

belecer qual abordagem será implantada. Na combinação das abordagens, o
conjunto total pode ser mais extenso do que a soma das partes.
Baseado em reúso
A engenharia de software possui estratégias no desenvolvimento dos seus
processos. Uma delas é criar um software baseado em reúso, onde seu desen-
volvimento tem como referência softwares já existentes. Como este tema já foi
apresentado, sabe-se que o conceito do reúso de software, apesar de ser algo
aplicado há mais de quatro décadas, só ganhou relevância a partir dos anos
2000, quando os novos sistemas de negócios adotaram essa prática como nor-
ma dentro das organizações.
É importante citar que toda esta transformação dos softwares tradicionais
para aqueles baseados em reúso surgiu com o intuito de atender algumas exi-
gências que o mercado impôs. Custos de produção mais reduzidos, manuten-
ção do software, além da exigência de entregas de software mais rápidas e
com qualidade fizeram o software adquirir status de ativo valioso dentro das
empresas. Sendo assim, o reúso consegue elevar o retorno sobre os investi-
mentos em software (SOMMERVILLE, 2011, p. 296).
A oferta de softwares reusáveis tem se elevado significativamente. Há uma
grande base de código reusável, disponibilizado a custos reduzidos, a qual se
denomina “movimento open source”, podendo ocorrer através de aplicações
inteiras ou bibliotecas de programas.
CURIOSIDADE
Empresas de grande porte constantemente disponibilizam uma diversida-
de de elementos reusáveis para clientes. O web service, por exemplo, é
um tipo de padrão que facilita a criação de serviços gerais e sua reutiliza-
ção numa diversidade de aplicações.
Reutilizar ao máximo os softwares existentes é, como já foi discutido, o princi-

pal objetivo da engenharia de software. Pode haver uma variedade de unidades
de software com tamanhos diversos. Vamos ver alguns exemplos:
• Reúso de sistema de aplicação: ocorre quando um determinado sistema
é reusado na íntegra, ou seja, na sua totalidade, em outros sistemas. Pode

ocorrer também através da configuração da aplicação para diversos clien-
tes. Famílias de aplicações combinadas a uma arquitetura comum podem ser
uma alternativa, desde que direcionadas aos clientes especiais;
• Reúso de componentes: acontece quando estes componentes, alterando
o seu tamanho, independentemente de serem subsistemas ou objetos úni-
cos, podem ser reusados. Imagine, por exemplo, um sistema de reconhe-
cimento de padrões criados como parte de um sistema de processamento
de textos. Eles podem ser reutilizados em um sistema de gerenciamento de
banco de dados (Ibidem, p. 297);
• Reúso de objetos e funções: define que os elementos que compõem um
software e implementam uma única função podem ser reusados. Baseiam-se
nas chamadas bibliotecas padrão, e algumas são disponíveis gratuitamente.
Você pode estar se questionando: será que todo software pode ser efeti-
vamente reutilizado? É preciso entender que tanto os sistemas de software
quanto os componentes existentes são passíveis de reutilização, porém, um
detalhe importante precisa ser discutido. Muitas vezes a origem específica
desses sistemas ou componentes torna o seu custo elevado à medida que
se deseja alterá-lo para uma situação nova. A partir daí, é possível inserir um
conceito complementar do reúso, conhecido como “reúso de conceito”. Em
vez de reutilizar um componente de software, é possível reaproveitar a ideia,
a forma ou até mesmo algum algoritmo. Sommerville (Ibidem, p. 297) afirma
que este conceito pode ser inserido, por exemplo, como padrões de projetos
ou geradores de programas.
CURIOSIDADE
O reúso de software tem como diferencial apresentar custos globais de
desenvolvimento em níveis reduzidos. Isso implica dizer que um número
cada vez menor dos elementos que compõem um software necessita ser
especificado, implementado e validado.
Você deve observar que a redução de custos globais é apenas uma das
vantagens do reúso de software. Exemplificando, podemos citar que a con-
fiança em um software reusado é elevada se comparada à introdução de um
software novo, pois eles já passaram pelos experimentos e testes em sis-

temas que estão em funcionamento.
Entretanto, é preciso que possíveis
falhas de projeto sejam corrigidas à
medida que são encontradas.
Geralmente, é possível visualizar
o custo de um software que já foi
desenvolvido. Isso é extremamente
importante para o gerenciamento de
projeto, pois diminui a possibilidade
de erros na previsão dos custos im-
putados. Outra vantagem observada
são os padrões, que podem ser im-
plementados como um conjunto de
componentes reusáveis (Ibidem, p.
298). Um bom exemplo do uso des-
tes padrões são as interfaces de usuário padrão, que trazem benefícios
como o aumento da confiança. Vale lembrar também que a rapidez na en-
trega de um software é mais relevante do que os custos gerais observados.
Nessas condições, o reúso de um software promoverá uma produção do
sistema mais rápida e consequentemente reduzirá o tempo de desenvolvi-
mento e validação.
Entretanto, é preciso lembrar que existem custos e problemas associa-
dos ao reúso de software. Tais custos estão relacionados a compreender se
um determinado componente pode ser efetivamente reutilizado. Na práti-
ca, isso pode indicar que possíveis reduções nos custos de desenvolvimen-
to através do reúso podem trazer resultados menores do que o esperado.
A indisponibilidade do código-fonte, seja de um sistema, seja de ele-
mentos que compõem softwares reusáveis, pode aumentar os custos de
manutenção, pois as mudanças no sistema podem deixar seus componen-
tes incompatíveis. Outra desvantagem é o fato de algumas ferramentas de
software não conseguirem dar suporte ao desenvolvimento com reúso.
Portanto, é preciso adequar o desenvolvimento de software ao reúso,
passando pelas etapas de refinação de requisitos do sistema que serão
alterados para disponibilizar o software que será reutilizado.

Incremental
Dentro da área de engenharia de software, é possível verificar que al-
guns projetos estabelecem requisitos iniciais razoavelmente bem definidos.
Pode ser necessária a disponibilização rápida de certo conjunto funcional
direcionado aos usuários. Após essa disponibilização, é possível expandir
e melhorar as funcionalidades, para serem inseridas nas versões de soft-
ware seguintes. São nesses tipos de caso que se torna viável a inserção
de um modelo que desenvolva softwares de maneira incremental, que se
caracteriza, entre outros aspectos, pelo fato de combinar componentes de
processos lineares e paralelos.
COMUNICAÇÃO
PLANEJAMENTO
INCREMENTO Nº N
MODELAGEM (ANÁLISE, PROJETO)
FUNCIONALIDADE E RECURSOS DO SOFTWARE
CONSTRUÇÃO (CODIFICAÇÃO, TESTES)
EMPREGO (ENTREGA, REALIMENTAÇÃO

OU FEEDBACK)
INCREMENTO Nº 2 ENTREGA DO
ENÉSIMO
INCREMENTO
INCREMENTO Nº 1
ENTREGA DO 2º INCREMENTO
ENTREGA DO 1º INCREMENTO
CRONOGRAMA DO PROJETO
Figura 3. Modelo incremental. Fonte: DEVMEDIA, 2010.
Analisando a Fig. 3, é possível verificar que este modelo, assim como no

modelo cascata, aplica sequências lineares de forma escalonada ao longo
do tempo, gerando um incremento dos softwares finalizados para o cliente.

EXEMPLIFICANDO
Imagine um processo incremental num software de e-mail. Inicialmente, ele
tem a função básica de enviar e ler e-mails. Aplicando um segundo incremento,
este software passa a ter funções de gestão de e-mails recebidos e revisão
ortográfica, por exemplo. Outro incremento pode ser controle de spam e assim
por diante, de maneira sucessiva.
De maneira geral, é possível notar

que a inserção do primeiro incremen-
to de um produto de software traz sua
parte essencial, em que os requisitos
básicos deverão ser atendidos para via-
bilizar o funcionamento do software.
Ao fim do incremento inicial, o cliente
realizará uma avaliação do incremento
e em seguida um resultado (feedback).
Esses resultados servem de base
para que o próximo incremento seja
planejado realizando possíveis alterações, caso seja necessário. A cada incre-
mento é realizado o mesmo procedimento, até a finalização do produto. O mo-
delo de processo incremental entrega um produto operacional a cada incre-
mento sem erros e pronto para o usuário utilizar. As partes que compõem os
softwares são classificadas como operacionais e funcionam de maneira inde-
pendente. À medida que os incrementos são inseridos, o número de pessoas
envolvidas no desenvolvimento do software aumenta. Também é possível gerir
alguns riscos por meio de um planejamento baseado nos incrementos.
RAD
É possível definir o conceito de Rapid Application Development (RAD) como
um tipo de modelo incremental que ressalta um ciclo de desenvolvimento
curto. Atua como uma adequação rápida do modelo cascata. Essa rapidez é
alcançada graças à abordagem de desenvolvimento baseada em componen-
tes. Entretanto, o RAD precisa de uma boa compreensão dos requisitos e uma
limitação dos objetivos do projeto para garantir seu êxito.

DIAGRAMA 3. MODELO RAD
EQUIPE N
MODELAGEM
CONSTRUÇÃO
IMPLANTAÇÃO
EQUIPE 2
INCREMENTO 1
MODELAGEM
COMUNICAÇÃO
CONSTRUÇÃO
PLANEJAMENTO
EQUIPE 1
MODELAGEM
CONSTRUÇÃO
MODELAGEM: NEGÓCIOS, DADOS E PROCESSOS.
CONSTRUÇÃO: REÚSO DE COMPONENTES, GERAÇÃO AUTOMÁTICA DE CÓDIGOS E TESTES.
Fonte: DEVMEDIA, 2010.
O Diagrama 3 ilustra o modelo RAD. Suas etapas estão divididas em:

• Comunicação: compreende os problemas do negócio, além das caracterís-
ticas de informação acomodadas pelo software;
• Planejamento: auxilia as diversas equipes de software a executar ativida-
des em conjunto baseando-se nas diferentes funções do sistema;
• Modelagem: abrange negócios, dados e processos, e determinam as repre-
sentações de projeto, as quais servem como referência para elaborar o RAD;
• Construção: destaca componentes de software preexistentes. Esta fase
também se destaca pela aplicação da geração automática de código;
• Implantação: determina a referência para iterações subsequentes, caso
haja necessidade.
É importante ressaltar que o RAD apresenta algumas desvantagens. Quando
envolver projetos de grande porte, passíveis de alterações, o RAD precisa au-
mentar recursos humanos para adequar as equipes, o que aumenta os custos
finais do projeto. A relação entre desenvolvedores e clientes deve apresentar
comprometimento na execução das atividades, pois, sem isso, o projeto estará
sujeito ao fracasso.

Outro ponto a ser observado é em relação ao sistema. A não modulari-
zação adequada do sistema pode provocar uma construção problemática
de componentes e, com ajuste na interface dos elementos do sistema, pode
ser que o RAD não funcione. Havendo riscos técnicos elevados, o RAD não
é adequado
Formal
Podemos conceituar modelos formais como técnicas usadas na criação de
sistemas computacionais, em que se prioriza sua coesão. Estes métodos são
produzidos com princípios matemáticos que garantem sua precisão na habili-
dade de expressar ideias ligadas ao projeto de software. Sua função é ajudar
em todas as fases do desenvolvimento de software, além de moldar o desen-
volvimento de sistemas de hardware. Nas subseções a seguir, veremos em de-
talhes as fases em que se aplicam os métodos formais.
CURIOSIDADE
Métodos formais também dispõem de notações conhecidas como lingua-
gens ou notações formais. Elas se baseiam em vários segmentos matemáti-
cos, dos mais simples aos mais complexos.
Especificação formal
Identifica os requisitos funcionais e não funcionais; aqueles definem o que
o software deve fazer, e estes estabelecem como o software vai executar suas
rotinas e procedimentos para realizar suas funções. Existe uma grande dificul-
dade na etapa de elicitação de requisitos, pois esses requisitos não refletem
de maneira clara o que o cliente realmente espera do sistema. Uma opção é a
especificação formal.
EXEMPLIFICANDO
A especificação formal formaliza os requisitos descobertos empregando algum
método formal, gerando uma modelagem com o uso de elementos que variam
conforme o modelo formal aplicado. Esta etapa é composta de uma descrição
textual dos requisitos que serão revisados pelo cliente, possibilitando a intera-
ção entre eles.

A especificação formal também analisa a consistência das informações, não
bastando apenas criar modelos para os requisitos, mas também avaliar os fa-
tores (interfaces com o ambiente, nível de integridade do software) que levam
ao relacionamento entre eles.
Refinamento
Aqui, realiza-se o projeto de software. O refinamento trata da arquitetura
do sistema com os mais variados elementos, observando-se a interface e o
relacionamento entre eles.
Esta etapa incide na concepção e manutenção de um modelo, verifican-
do seu desempenho e expressando os métodos para cumprir as finalidades
explicitadas para o sistema. Vale lembrar que algumas ferramentas empre-
gadas pelos métodos formais apresentam interface gráfica, o que permi-
te o refinamento com componentes
gráficos, permitindo a simulação de
tarefas do sistema para analisar seu
comportamento.
Síntese
Trata-se da fase que gera a base
estrutural do código, partindo da eta-
pa de refinação. Pode servir como re-
ferência para implementar o sistema,
em que algumas ferramentas já dispo-
nibilizam auxílio, gerando códigos de
linguagem C ou Java.
Prova e prototipagem
A etapa da prova foi adotada para
avaliar se o sistema desenvolvido foi
idealizado atendendo a todos os re-
quisitos, sejam eles funcionais ou não
funcionais elicitados. Já a fase de pro-
totipagem consiste na elaboração de
um protótipo funcional do sistema
para atestar a capacidade de atender
as demandas do cliente.

EXEMPLIFICANDO
A fase de prova ocorre de duas formas: através da prova de teorema auto-
matizada, que é a utilização da descrição do sistema, empregando inferên-
cias lógicas analisando o nível de correção do sistema, e a verificação de
modelo, que usa o método criado na etapa de refinamento.
A fase da prototipagem surge após a fase de prova, realizando testes em
protótipos, sendo possível analisar as demandas do cliente relacionadas
ao sistema. Portanto, a estrutura formal do código gerado pelo método
formal da etapa de síntese pode ser considerada uma boa opção.
Modelos de processos contemporâneos de software

Abordando os modelos de software, já sabemos que este representa uma
perspectiva particular de um processo, trazendo informações simplificadas
sobre ele. Nas seções a seguir, abordaremos conceitos contemporâneos so-
bre alguns processos, destacando o Extreme Programming, Lean Software
Development e o DevOps.
Extreme Programming
Considerado um dos métodos ágeis mais conhecidos, o Extreme Program-
ming (XP) incentiva boas práticas, a exemplo do desenvolvimento interativo.
É preciso imaginar que este método apresenta seus requisitos em forma de
cenário, conhecidos como “estórias do usuário” (SOMMERVILLE, 2011, p. 44). A
implementação destes cenários ocorre de maneira direta a uma série de ativi-
dades, em que os programadores desenvolverão testes para cada uma delas,
na fase anterior à escritura do código. Espera-se que os testes sejam devida-
mente executados no instante em que o novo código seja integrado ao siste-
ma. Ao verificar esse procedimento descrito, você consegue entender que o
método XP aborda práticas que demonstram os princípios fundamentais dos
métodos ágeis.
Começa-se pelo desenvolvimento incremental, formado pelos releases do
sistema. Seus requisitos são fundamentados em estórias de clientes ou nos
cenários, que são os pilares na decisão da funcionalidade que será inclusa no
incremento do sistema. Outro ponto refere-se à participação do cliente, que

participa com a equipe de desenvolvimento por meio de um representante,
que tem a missão de estabelecer os testes de aceitação dos sistemas que
serão utilizados.
Vale ressaltar que as pessoas envolvidas com este modelo são mantidas
por meio de um processo de desenvolvimento sustentável que se caracteriza
por não requerer excessivas horas de trabalho (Ibidem, p. 44). As transforma-
ções podem ocorrer através do desenvolvimento test-first ou da refatoração,
que impede a degeneração do código, entre outras ações. Por fim, é importan-
te citar que a criação de projetos simples evita a antecipação desnecessária de
mudanças no sistema e garantem a manutenção da simplicidade e a refatora-
ção que eleva a qualidade do código criado.
Como você pode perceber, no processo XP, os clientes estão diretamente
envolvidos na priorização e especificação de requisitos, ou seja, estão inte-
grados às equipes de desenvolvimento, debatendo possíveis cenários com os
demais componentes. A partir desta discussão, será desenvolvido o chamado
“cartão de estórias”, que vai tratar das necessidades do cliente. Posteriormen-
te, ainda segundo Sommerville (Ibidem, p. 45), a equipe de desenvolvimento
buscará implementar esse cenário em um release futuro do software. É impor-
tante que você, caro leitor, consiga visualizar como se dá o fluxo de ações para
aplicar um método XP.
Voltando à criação de cartões de estória, é possível afirmar que estes são
considerados as mais importantes entradas para desenvolver o método XP.
Após sua criação, a equipe responsável irá dividi-los em tarefas, estabelecen-
do quais são as técnicas necessárias para cumprir estas tarefas. Lembre-se
que nesta fase o cliente estará envolvido na definição dos requisitos. Ele vai
priorizar também quais estórias serão implementadas, selecionando as que
auxiliem na criação de negócios.
Como pode haver mudanças nos requisitos estabelecidos, estórias não im-
plementadas podem ser descartadas. No caso de uma alteração em sistemas
já entregues ao cliente, novos cartões serão criados, cabendo ao cliente deci-
dir se serão prioritárias na nova funcionalidade. Para criar a versão atual de
um software através do desenvolvimento do sistema, o programador precisa
realizar os testes automatizados, tanto os já existentes quanto os que serão
utilizados para a funcionalidade mais nova.

CURIOSIDADE
XP tem relação estreita com o desenvolvimento incremental. Segundo
Sommerville (Ibidem, p. 46), as versões mais recentes do software podem ser
produzidas várias vezes durante o dia, enquanto os releases são disponibi-
lizados aos clientes, em um período quinzenal. Lembrando que os prazos de
releases jamais deixarão de ser cumpridos. Situações onde o desenvolvimen-
to apresente problemas é preciso consultar o cliente e a funcionalidade é
removida do release planejado.
A engenharia de software se baseia na ideia de que os projetos são o caminho

para a mudança. Ou seja, você, enquanto desenvolvedor, deve se antecipar a pos-
síveis transformações ocorridas no software e projetá-lo com o intuito de facilitar
a implementação destas mudanças.
Você concorda ou não com esta teoria? Baseando-se no XP, muitas vezes a
mudança representa, na prática, uma extrema perda de tempo e recursos. É re-
corrente transformações previstas em um software simplesmente não acontece-
rem ou solicitações feitas serem complemente distintas das planejadas. Com isso,
conclui-se que uma abordagem XP considera mudanças que de fato acontecerão,
porém, a reorganização do software só ocorre quando estas transformações real-
mente acontecerem.
DIAGRAMA 4. CICLO DE UM RELEASE EM XP
SELECIONAR ESTÓRIAS DO DIVIDIR ESTÓRIAS

PLANEJAR RELEASE
USUÁRIO PARA ESTE RELEASE EM TAREFAS
DESENVOLVER/INTEGRAR/
AVALIAR SISTEMA LIBERAR SOFTWARE
TESTAR SOFTWARE
Fonte: SOMMERVILLE, 2011, p. 44.

A estrutura de um software normalmente é degradada pelo desenvolvimento
incremental, o que torna a implementação de mudanças nos softwares uma ati-
vidade extremamente complexa. Se por um lado o desenvolvimento prossegue
solucionando os problemas que vão surgindo, o resultado normalmente encon-
trado traz algumas incongruências, como a duplicação do código, a reutilização
dos softwares de maneira equivocada, além da degradação da estrutura global
do código quando ele é inserido no sistema. O modelo XP trata desta questão, in-
dicando a refatoração constante do software, cabendo à equipe responsável pela
programação buscar melhorias. Portanto, o software deve ser fácil de entender e
suscetível a mudanças, à medida que novas estórias são implementadas.
Lean Software Development

Ao tratarmos sobre a aplicação do software por meio do Lean Software
Development, precisamos saber em que contexto este conceito está inseri-
do. O Lean é uma metodologia desenvolvida pela Toyota, de forma pioneira,
com o objetivo de nortear os procedimentos referentes à linha de montagem,
baseando-se em três fatores primordiais: eliminar desperdícios, elevar a velo-
cidade dos processos e primar pela qualidade de excelência. Estes princípios
foram introduzidos ao universo de
software através do Lean.
Voltando às práticas desenvolvidas
na Toyota, a implementação do Lean
possibilitou à empresa reduzir esto-
ques ao mesmo tempo que aumentou
a utilização de trabalhadores multi-
funcionais, e a produção passou a es-
tar de acordo com a demanda. Esse processo ficou conhecido mundialmente
como Toyota Production System (TPS).
Já que o lema principal do Lean é eliminar excessos e estar sempre aberto a
mudanças, este conceito é amplamente difundido nas organizações através da
adoção de técnicas, métodos e ferramentas das suas capacidades específicas.
A partir da década de 1980, as técnicas Lean vêm sendo adotadas pelas
empresas, principalmente na América do Norte e Europa.

Na engenharia de software, é comum questionar se o Lean é uma metodo-
logia nova ou um método ágil. Especialistas como Jeff Sutherland, criador do
método Scrum, afirmam que os métodos ágeis são aplicações de Lean dire-
cionadas para software, lembrando que este consegue trazer resultados mais
expressivos do que os métodos ágeis.
Quanto ao desenvolvimento de produtos, duas linhas de pensamento po-
dem ser adotadas: a determinística, que consiste em conceituar como deve ser
o produto e, a partir daí, executar conforme planejado; e a segunda linha, o
pensamento empírico, que forma um produto com nível mais elevado, realizan-
do entregas frequentes por meio de iterações, possibilitando que adequações
sejam feitas visando à evolução do produto.
DevOps
Na sua definição básica, DevOps é um termo que descreve uma série de téc-
nicas utilizadas para integrar equipes evoluídas de desenvolvimento de softwa-
re, de operações e de apoio. Refere-se também aos processos automatizados
direcionados à produção mais veloz e estável dos serviços e aplicações. Este
conceito sugere a introdução de pensamentos novos sobre a valorização do
trabalho e das atividades diversificadas.
A cultura DevOps se baseia nos seguintes pilares:
• Integração contínua: transferência mútua de experiência e conhecimen-
to entre as áreas de desenvolvimento, operações e apoio;
• Implantação contínua: liberação rápida e contínua das versões atualiza-
das de serviço ou software;
• Feedback contínuo: feedback das equipes inseridas nas etapas do ciclo
de vida do software ou serviço.
CURIOSIDADE
Desenvolvimento e operações são áreas distintas e apresentam motivações
diferentes. O setor de desenvolvimento está mais alinhado com as metodo-
logias ágeis, enquanto as operações utilizam minimamente as transforma-
ções no ambiente de produção.
Para que esses objetivos sejam alcançados, o DevOps sugere algumas ações:

• Apoiar pensamentos que facilitem a integração das pessoas;
• Criar um ambiente onde a execução de um projeto seja o objetivo comum;
• Aplicar serviços que desenvolvam o negócio.
Essas e outras ações são de suma importância para que o DevOps consiga inse-
rir suas práticas de maneira efetiva.
Métodos ágeis de desenvolvimento

Você já parou para observar como as relações comerciais ocorrem nos dias
atuais? De um lado, o mercado consumidor extremamente exigente em relação
aos produtos e serviços disponibilizados; do outro, as empresas que operam
em um ambiente suscetível às mudanças rápidas de oportunidades, novos
mercados ou até mesmo a concorrência.
Neste cenário, os softwares, que já são utilizados por boa parte dos ne-
gócios empresariais, são desenvolvidos para aproveitar as oportunidades que
estão surgindo e enfrentar a competitividade no meio organizacional. Dito isto,
você já consegue visualizar que o desenvolvimento e a entrega de software,
quando feitas de forma rápida ao consumidor final, são um diferencial para
a empresa fornecedora. De fato, às vezes, a qualidade fica em segundo plano
para que um software seja implantado.
As constantes mudanças a que as empresas estão sujeitas impedem a cria-
ção de um conjunto de requisitos de software com maior estabilidade. É preci-
so ter em mente que os requisitos iniciais estão sujeitos a alterações, pois ainda
existe certa dificuldade, por parte do cliente, em crer como um sistema pode
interferir futuramente nas práticas do trabalho, sua interação com outros sis-
temas e quais operações do usuário devem ser automatizadas (Ibidem, p. 32).
Somente após a entrega do software é que os requisitos começam a ficar mais
compreensíveis aos usuários.
CURIOSIDADE
Existe certa insistência dentro dos processos de desenvolvimento de softwa-
re quando se deseja especificar os requisitos de maneira completa. Projetar,
desenvolver e testar o sistema não ocorre rapidamente, o que se torna uma
desvantagem quando se trata de ambientes que exigem mudanças mais
dinâmicas, como a área de negócios, por exemplo.

Já é reconhecida pela engenharia de software a necessidade de criar soft-
wares mais dinâmicos, aliados a processos capazes de se adaptar às transfor-
mações constantes dos requisitos. Na década de 1980, o desenvolvimento in-
cremental foi introduzido pela IBM. No mesmo período, as 4GLs passaram a
fomentar a ideia das entregas de software mais rápidas. Entretanto, apenas ao
final da década de 1990 esta ideia passou a ganhar maior relevância, através da
criação de abordagens ágeis.
EXEMPLIFICANDO
A metodologia de desenvolvimento de sistemas dinâmicos (dynamic Systems
Development Method – DSDM) é um exemplo de desenvolvimento da noção das
abordagens ágeis que decolaram no final dos anos 1990.
É essencial entender que o desenvolvimento rápido de software tem o obje-

tivo de desenvolver softwares úteis ao mercado e que sejam produzidos envol-
vendo um conjunto de incrementos que incluem uma nova funcionalidade do
sistema (Ibidem, p. 39). Estes processos apresentam procedimentos de especi-
ficação e implementação intercalados. Outra característica se deve ao fato de o
sistema ser desenvolvido numa série de versões, onde os usuários finais envol-
vem-se na especificação e verificação de cada versão, sugerindo mudanças no
software e implementando novos requisitos nas versões seguintes do sistema.
Enfim, é possível definir que os métodos ágeis são técnicas de desenvol-
vimento formadas por pequenos incrementos. Geralmente, as versões mais
atuais do sistema são apresentadas num espaço curto de tempo (de duas a três
semanas), e o feedback sobre a evolução dos requisitos é rápido por parte do
cliente, já que ele é inserido no processo de desenvolvimento e a comunicação
normalmente é informal, o que reduz a necessidade de documentação. Abor-
daremos com mais detalhes os métodos ágeis na seção seguinte.
Métodos ágeis
Como você imagina a implementação de um software na década de 1980?
Havia uma visão geral, no final da década de 1980 para o início de 1990, de que
um planejamento mais conservador e a utilização de técnicas de análise basea-

das em ferramentas CASE, entre outros atributos, eram o suficiente para obter
um software de qualidade (Ibidem, p. 39).
As equipes que desenvolviam softwares nesta época geralmente ofereciam
seus serviços para empresas diferentes, geograficamente dispersas e desenvol-
vendo softwares que demandavam períodos extensos. Porém, é visível que, num
ambiente de mudanças constantes, uma abordagem complexa como esta, onde
os sistemas desenvolvidos até então demandavam um longo período para serem
criados e havia muito retrabalho devido a essas mudanças, impulsionou, a partir de
1990, a introdução dos “métodos ágeis”.
Conceitualmente, métodos ágeis são uma abordagem que envolve a especifica-
ção, o desenvolvimento e a entrega do software (Ibidem, p. 40). Vale ressaltar que
a entrega do produto deve ser rápida, pois os clientes, ao receberem o software,
podem sugerir mudanças posteriores no sistema.
Quanto aos princípios dos métodos ágeis, podemos tratar de imediato o envol-
vimento dos clientes, pois eles devem estar plenamente envolvidos no processo de
desenvolvimento, priorizando novos requisitos e analisando suas iterações. Outro
ponto é sobre a entrega incremental, onde o software é criado com o cliente, dei-
xando especificados os requisitos que serão incluídos. Mas os requisitos mudam,
portanto, é necessário planejar o sistema para que estas transformações sejam
acomodadas. Por fim, o foco no desenvolvimento do software deve ser simples
para evitar dificuldades no manuseio do sistema.
Métodos ágeis são fundamentados nas pessoas, ou seja, nas habilidades da
equipe, e as qualidades individuais são exploradas e valorizadas. Por isso, têm
sido utilizados pelas empresas, devido aos fundamentos já citados (foco em
simplicidade, pessoas integradas, adequações a mudanças de requisitos, entre
outros). Entretanto, problemas podem surgir se, por exemplo, este método for
direcionado para tratar de sistemas maiores, pois o sucesso da aplicação deste
método está relacionado ao fato de formar equipes coesas e pequenas para a
execução do trabalho.
Outra situação é a possibilidade de os princípios básicos, na prática, não serem
efetivamente aplicados. Imagine, por exemplo, um cliente que pouco se envolve
com as equipes de desenvolvimento, membros da equipe que não se entrosam,
ou até mesmo a dificuldade em priorizar mudanças: todas essas situações podem
dificultar a aplicação dos métodos ágeis dentro de uma organização.

Sem dúvida, é necessário entender as limitações do método e buscar me-
lhoramentos para as versões seguintes. Dito isto, existe um empenho por par-
te da engenharia de software referente à manutenção e ao melhoramento dos
sistemas de software já desenvolvidos. Para que fique mais claro, vamos enten-
der estes conceitos com a documentação formal.
A princípio, a documentação formal tem o objetivo de descrever o sistema, permi-
tindo que seu entendimento se torne mais fácil, para que as alterações sejam feitas.
Mas o que acontece na prática? A documentação formal normalmente é desatuali-
zada, não refletindo muitas vezes o código do programa. Com isso, os especialistas
acreditam ser uma perda de tempo a elaboração desta documentação e defendem a
produção de códigos bem estruturados e de alta qualidade (Ibidem, p. 42). Por outro
lado, há quem afirme que a manutenção dos sistemas precisa da formalização de um
documento-chave, no qual ficam estabelecidas as diretrizes do sistema.
DICA
O envolvimento dos clientes após a entrega do software e a continuação
dos membros em uma equipe de desenvolvimento são os principais pro-
blemas apresentados pelo uso dos métodos ágeis na fase de manutenção.
Bem, é importante frisar que esses métodos apresentam vantagens e des-

vantagens em sua utilização. Por conta disto, alguns críticos como DeMarco e
Boehm (2002), citados por Sommerville (Ibidem, p. 42), propõem uma aborda-
gem híbrida, em que os métodos adotem técnicas de desenvolvimento e dirigi-
do a planos, que trataremos a seguir.
Desenvolvimento ágil e dirigido a planos

Na concepção das abordagens ágeis de desenvolvimento de software, as ati-
vidades consideradas centrais no processo são o projeto e a implementação. Já
a abordagem dirigida a planos identifica etapas diferentes do processo de soft-
ware, no qual as saídas estão relacionadas a cada etapa. Estas saídas são a re-
ferência para o planejamento da atividade do processo seguinte (Ibidem, p. 42).
Vale ressaltar que em uma abordagem dirigida a planos são realizadas ite-
rações das atividades com os documentos formais, que objetivam definir a co-
municação entre as fases do processo.

Gerenciamento ágil de projetos
Entregar o software dentro do prazo e manter o orçamento planeja-
do são as principais responsabilidades dos gerentes de projeto da área.
Cabe a estes profissionais super visionar a atuação dos engenheiros e
avaliar a evolução do software.
Sabe-se que o gerenciamento de projetos se baseia em uma aborda-
gem dirigida a planos. Os gerentes produzem um plano direcionado ao
projeto, apresentando o que e quando será entregue, e quais profissio-
nais farão as entregas. Ter um olhar definido sobre o que será desen-
volvido e sobre os processos que serão aplicados é um diferencial para
o gerente, que utiliza uma abordagem baseada em planos. Você deve se
recordar de que esta abordagem não terá um desempenho satisfatório
no uso dos métodos ágeis, pois o desenvolvimento ocorre de forma in-
cremental, em que possíveis alterações nos requisitos do software acon-
tecem com frequência.
CITANDO
Segundo Sommerville (Ibidem, p. 50), o desenvolvimento ágil deve ser
gerenciado de forma que o tempo e os recursos disponibilizados para
a equipe sejam utilizados de maneira eficiente. Para isso, é necessá-
rio que o gerenciamento de projeto realize uma abordagem direcio-
nada para o desenvolvimento incremental e para os pontos fortes dos
métodos ágeis.
Nesse contexto, é possível falar sobre uma abordagem em específi co: a

abordagem Scrum. Considerado um método ágil geral, o gerenciamento do
desenvolvimento iterativo é o seu foco. Apresenta-se em três fases:
• Planejamento geral: define os objetivos gerais do projeto, além da
arquitetura do software;
• Ciclos de sprint: é onde se avalia, seleciona, desenvolve e se revisa um
incremento do sistema, em ciclos;
• Encerramento do projeto: completa a documentação exigida e anali-
sa o que se aprendeu.

DIAGRAMA 5. O PROCESSO SCRUM
AVALIAR SELECIONAR
PLANEJAMENTO GERAL
E PROJETO DE ENCERRAMENTO
ARQUITETURA DO PROJETO
REVISAR DESENVOLVER
CICLO SPRINT
Na fase central do Scrum, temos o ciclo de sprint, o qual representa uma

parte do planejamento no qual se avalia o trabalho, escolhe os recursos e im-
plementa o software.
No sprint, o planejamento se inicia através do backlog do produto, que é o
roteiro de trabalho a ser elaborado no projeto. Outra característica importante
é a seleção de recursos que serão desenvolvidos durante o sprint. Essa ativida-
de envolve a participação da equipe do projeto junto com o cliente.
Quando o cliente se organiza para desenvolver o software, algumas reu-
niões são feitas para avaliar os progressos atingidos ou modificar prioridades.
Nesta fase, isola-se a equipe em relação ao cliente e à organização, canalizando
as formas de comunicação através do Scrum Master, que tem a função de não
permitir que as distrações externas afetem a equipe de desenvolvimento.
Como você pode perceber, o Scrum defende a ideia de que a equipe, de
maneira geral, tem condições de tomar decisões, ao ponto de haver questio-
namentos sobre o uso do termo “gerente de projeto”. Todos os membros con-
seguem compartilhar informações, verificar progressos e novamente planejar,
caso seja necessário. Entretanto, vale salientar que o desenvolvimento de soft-
ware, nos moldes atuais, envolve cada vez mais equipes situadas em localida-
des variadas, o que tem possibilitado a criação do Scrum para ambientes de
desenvolvimento distribuído (Ibidem, p. 51).

Escalamento de métodos
Como já foi demonstrado, os métodos ágeis, por conta das suas caraterísticas,
foram criados para serem utilizados por equipes de menor porte, que tivessem a
possibilidade de atuar juntas através de uma comunicação informal. Analisando os
sistemas de maior porte, o entendimento e as necessidades são as mesmas, ou seja,
um software que seja entregue rapidamente e adaptado às demandas do cliente.
Existe um movimento grande para que haja um escalamento dos méto-
dos ágeis, objetivando inseri-lo em sistemas de maior porte. Antes, é preci-
so compreender que alguns pontos do desenvolvimento de sistemas grandes
apresentam diferenças importantes em comparação aos sistemas pequenos.
Citando um exemplo, os sistemas de grande porte são desenvolvidos em sepa-
rado, e as equipes trabalham em diversos lugares e fusos horários diferentes.
Situações como esta impossibilitam a visão completa do projeto.
Então, como aplicar os métodos ágeis em grandes sistemas? Sommerville
(Ibidem, p. 52) aborda três sugestões que precisam ser introduzidas:
• Não focar apenas o código do sistema. É preciso fazer sua documentação
e criar um projeto mais avançado;
• Aumentar os mecanismos de comunicação e usá-los. Isso facilita a intera-
ção entre as equipes, mesmo à distância;
• Manter releases, no quais as novas ferramentas de gerenciamento podem ser
introduzidas para auxiliar o desenvolvimento do software com equipes múltiplas.
Porém, mesmo com estas sugestões, ainda é complexa a introdução dos
métodos ágeis nas grandes empresas. Existe a falta de experiência de alguns
gerentes de projeto em relação ao uso dos métodos ágeis e a resistência deles
em aceitar novas abordagens, já que oferecem determinados riscos.
Você pode imaginar também que uma grande corporação adota procedimen-
tos e padrões de qualidade geralmente burocráticos e formais. Os métodos ágeis
são dinâmicos, prezam pela rapidez na elaboração e entrega do software, o que
pode se tornar incompatível com preceitos antigos.
Outro ponto que dificulta a introdução dos métodos ágeis nas grandes em-
presas é a resistência cultural, principalmente quando as organizações são tra-
dicionais na área de engenharia de software. Portanto, cabe à empresa estar
propensa a mudanças de cultura organizacional, muitas vezes até de gerencia-
mento, para que os sistemas ágeis sejam implantados com êxito.

Sintetizando
Visualizaram-se os principais modelos adotados na área da engenharia de
software e suas aplicações práticas dentro das empresas. O modelo cascata,
por exemplo, vem de uma abordagem sistemática, sequencial ao desenvolvi-
mento do software. Os modelos evolucionários possibilitam ao profissional da
área de engenharia de software criar versões cada vez mais abrangentes em
relação ao software. A criação de um software em reúso baseia seu processo
de desenvolvimento através de softwares já existentes.
Os modelos incrementais podem ser empregados diante de um cenário
onde pode ser necessária a disponibilização rápida de certo conjunto funcio-
nal direcionado aos usuários. Após essa disponibilização, é possível expandir
e melhorar as funcionalidades, para serem inseridas nas versões de software
seguintes. O modelo RAD atua como adequação rápida do modelo em cascata,
e os modelos formais são técnicas usadas na criação de sistemas computacio-
nais, em que se prioriza sua coesão.
Quanto aos métodos contemporâneos, o XP incentiva boas práticas, a
exemplo do desenvolvimento interativo, já o Lean Software Development eli-
mina os desperdícios para atingir resultados melhores, e o DevOps descreve
uma série de técnicas para integrar equipes evoluídas de desenvolvimento de
software, de operações e de apoio.
Os métodos ágeis envolvem a especificação, o desenvolvimento e a entrega
do software (Ibidem, p. 40). É importante ressaltar que a entrega do produto
aos clientes deve ser rápida, pois, ao receberem o software, podem sugerir
mudanças posteriores.
Bons estudos e até a próxima!

4LINUX. O que é DevOps. [s.l.]: 4Linux, 2016. Disponível em: <https://www.4linux.
com.br/o-que-e-devops>. Acesso em: 28 mar. 2019.
DEVEMEDIA. Learn Software Development – Java Magazine 81. [s.l.]: Devmedia,
2010. Disponível em: <https://www.devmedia.com.br/lean-software-development-
-java-magazine-81/17442>. Acesso em: 28 mar. 2019.
PRESSMAN, R. S. Engenharia de software. Trad. José Carlos Barbosa dos Santos.
São Paulo: Pearson Education, 1995.
SOMMERVILLE, I. Engenharia de software. Trad. Ivan Bosnic e Kalinka Gonçalves.
9. ed. São Paulo: Pearson Prentice Hall, 2011.

UNIDADE
3 GARANTIA DA
QUALIDADE

Descrever aspectos relacionados à garantia da qualidade do software e seus
fatores;
Abordar as principais normas aplicáveis no desenvolvimento de software;
Apresentar as métricas utilizadas para definir o nível de qualidade do software.

implicações em pequenas e grandes empresas.
Tópicos de estudo
A garantia da qualidade de Métricas de qualidade de
software software
Fatores da qualidade de Análise de componentes de
software software
Como garantir a qualidade Indicadores de qualidade de
de software software
Atividades SQA A ciência de software de
Halstead
Normas de qualidade aplicadas Métrica de complexidade de
no desenvolvimento do software McCabe
ISO 9001 Medições ambíguas
ISO 12207
ISO 15504
Modelo de maturidade da
captação para software (CMM)
PSP e TSP
MPS.BR (melhoria de processo
de software brasileiro

A garantia da qualidade de software
Como já visualizamos, os métodos, procedimentos e ferramentas emprega-
dos devem produzir um software de alta qualidade. Mas o que é alta qualidade
para a engenharia de software?
Segundo o conceito de Philip Crosby (1979) citado por Pressman (1995, p.
723), o grande problema do gerenciamento da qualidade do software não está
relacionado ao que as pessoas sabem sobre o tema, e sim ao que elas acham
que sabem sobre qualidade. Muitos estudiosos e especialistas da área podem
levar você, caro leitor, a ter a ideia de que a garantia da qualidade, por exemplo,
passa a ganhar relevância depois da geração do código, o que não é verdade.
Aprofundando um pouco mais o gerenciamento de qualidade de software
aplicado em sistemas, verifica-se que seu conceito se baseia em três aspectos
importantes. De imediato, observa-se o nível organizacional, onde o gerencia-
mento de qualidade define um framework de processos organizacionais e de
padrões que possibilitam o desenvolvimento de softwares de níveis elevados
(SOMMERVILLE, 2011, p. 454). Cabe à equipe responsável definir os processos
e padrões de desenvolvimento de softwares que serão empregados, a docu-
mentação relacionada, assim como os requisitos de sistema, projeto e código.
O segundo ponto é o estágio do projeto, onde o gerenciamento de qua-
lidade implementa procedimentos especiais, verifi cando se os processos
esboçados foram de fato cumpridos. Não se pode deixar de garantir que as
saídas de projeto estejam alinhadas com os padrões aplicáveis ao projeto
(SOMMERVILLE, 2011, p. 454).
A terceira preocupação do ge-
renciamento de qualidade também
está no nível do projeto e se refere
ao plano de qualidade, que definirá
os objetivos direcionados ao projeto,
assim como os processos e padrões
que serão aplicados.
É importante que você comece a
se familiarizar com os termos “garan-
tia de qualidade” e “controle de qua-

lidade”, pois ambos são amplamente empregados
nas organizações empresariais de maneira geral.
Segundo Sommerville (2011, p. 455), a garantia de
qualidade (QA, do inglês quality assurance) consiste
no estabelecimento de processos e padrões que os irão
levar a produtos de níveis elevados, além da introdu-
ção de técnicas de qualidade no momento da geração do
produto. Por sua vez, o QA aplica estes processos de quali-
dade objetivando descartar os produtos que não atenderem
aos requisitos de qualidade solicitados.
Adaptando a definição para a área da tecnologia, temos o conceito do
SQA (software quality assurance), ou garantia da qualidade do software,
aplicado durante todo o processo de engenharia de software, abrangendo,
segundo Pressman (1995, p. 724):
• Ferramentas e técnicas relacionadas à análise, projeto, codificação e testes;
• Reavaliações de caráter técnico empregadas ao longo das etapas de
engenharia de software;
• Diversas fases através da implementação de uma estratégia de testes;
• Práticas de controle de documentação de software e das transforma-
ções às quais estão sujeitas;
• Ações que visam manter a adequação aos modelos padronizados de
desenvolvimento de software;
• Técnicas de mensuração e divulgação.
Uma informação importante é o fato de as equipes SQA serem respon-
sáveis pela gestão do processo de teste de release em boa parte das empre-
sas. O que isso quer dizer? Que os testes de software são gerenciados antes
da liberação para os clientes. Cabe também à equipe avaliar se os testes de
sistema cobrem atributos e mantêm registros adaptados ao processo de
teste (SOMMERVILLE, 2011, p. 455).
Existe uma dúvida constante para estudantes de engenharia de softwa-
re sobre o fato de haver uma interação entre a equipe responsável pelo ge-
renciamento de qualidade e do processo de desenvolvimento de software.
Importante entender que a equipe responsável pelo gerenciamento deve
realizar uma análise separada da equipe que cuida do desenvolvimento.

DIAGRAMA 1. GERENCIAMENTO E DESENVOLVIMENTO DE SOFTWARE
Processo de
desenvolvimento D1 D2 D3 D4 D5
de software
Processo de
gerenciamento
de qualidade
Padrões Plano Relatórios de revisão

e procedimentos de qualidade de qualidade
A função do gerenciamento de qualidade é legitimar os entregáveis de pro-

jeto para garantir consistência, padrões e objetivos estabelecidos pelas empre-
sas. A equipe responsável pelo QA deve agir de maneira autônoma em rela-
ção à equipe de desenvolvimento. A intenção é possibilitar uma primeira visão
mais direta do software e permitir tratar da sua qualidade sem ser influenciado
por situações causadas pela equipe de desenvolvimento.
DICA
Importante frisar que a equipe responsável pelo gerenciamento de quali-
dade não deve ter relação com outras equipes específicas de desenvolvi-
mento, porém ela é responsável por todo o aspecto organizacional. É um
setor que precisa de autonomia e se reportar sempre aos responsáveis
e ao gerente de projeto, pois ele precisa garantir o cronograma e o orça-
mento de projeto, definidos anteriormente.
A qualidade do produto está em risco caso haja problemas em relação ao cum-

primento do cronograma, por exemplo. Havendo independência da equipe de
gerenciamento, é possível que a empresa não estabeleça metas básicas, curtos
orçamentos e possibilidades de alterações de cronogramas. Em pequenas organi-
zações esse cenário é diferente, onde o gerenciamento de qualidade está intima-
mente ligado à equipe responsável pelo desenvolvimento e qualidade do software.
Podemos conceituar planejamento de qualidade, segundo Sommerville, como
“um processo de desenvolvimento de um plano de qualidade direcionado a um

projeto” (2011, p. 455). É importante definir a qualidade que se deseja obter em um
software e relatar como serão as avaliações. Em outras palavras, temos a definição
de um software de qualidade elevada e sua importância para determinados siste-
mas. Vale ressaltar que a ausência desta definição reflete no desenvolvimento do
trabalho dos engenheiros de software, pois provoca neles uma série de dúvidas e
suposições sobre a definição dos requisitos que caracterizam um software.
Neste contexto, é relevante introduzir o conceito de planejamento formal, parte
integrante nos processos que se baseiam em planos, lembrando que, quando se
refere a métodos ágeis, a abordagem é menos formalizada quando direcionamos
para o gerenciamento de qualidade de software.
Segundo o entendimento de Humphrey (1989) citado por Sommerville (2011, p.
456), o plano de qualidade segue uma estrutura preliminar composta por:
• Introdução do produto: aponta qual será o produto em si, seu mercado e as
expectativas de qualidade;
• Planos do produto: consistem nas datas críticas de release para o produto,
aliados a planos de repasse e prestação de serviços;
• Descrições do processo: onde o gerenciamento e desenvolvimento do pro-
duto devem utilizar os processos de desenvolvimento e serviços de padrões;
• Metas de qualidade: é preciso estabelecer metas de planos e qualidade
para os produtos onde os atributos críticos de qualidade são identificados
e justificados;
• Riscos e gerenciamento de riscos: tratam da possibilidade de lidar com ris-
cos mais graves que interferem na qualidade do software.
Há uma crença de que a qualidade do software está relacionada aos processos
prescritivos, que têm como referência os padrões estabelecidos pela organização,
além de procedimentos de qualidade
que atestam se os padrões serão de
fato seguidos pela equipe responsável
pelo desenvolvimento do software. A
justificativa é que os padrões adotem
práticas viáveis de engenharia de soft-
ware. Logicamente, seguir estes pa-
drões vai ocasionar uma produção de
softwares de alta qualidade.

Como você pode perceber, os processos e padrões são de suma importân-
cia, porém cabe aos gerentes de qualidade desenvolver o que chamamos de
“cultura de qualidade”, onde os responsáveis pela criação do software estejam
imbuídos em atingir uma qualidade de software elevada. Equipes precisam ser
incentivadas a se responsabilizar pelo nível de qualidade do trabalho, além de
criar novas metodologias.
Vale informar que o gerenciamento formal de qualidade é relevante espe-
cialmente para as equipes que criam sistemas de nível mais elevado, os quais
podem levar alguns anos para se desenvolver. Para isso, a documentação de
qualidade é importante, pois trata-se de um registro em cada seção do projeto
e auxilia na verificação das atividades realizadas para que não sejam esquecidas
ou que possibilitem conceituações erradas sobre outros grupos.
A abordagem informal se adapta melhor a sistemas de menor porte, po-
rém a cultura de qualidade deve ser estabelecida pelos gerentes de qualidade
para garantir que os membros da equipe tenham uma conceituação positiva
da qualidade do software (SOMMERVILLE, 2011, p. 456).
As definições apresentadas até aqui destacam três aspectos importantes.
Primeiramente sobre a mensuração da qualidade, que passa pela coesão dos
requisitos, ou seja, não pode apresentar desconformidade. Outro ponto se re-
fere à engenharia de software, que é norteada por um conjunto de critérios
estabelecidos por padrões especificados. Por fim, deve-se tratar do software
que apresenta uma série de requisitos classificados como implícitos, ou seja, os
que normalmente não são expressos. Um software que deixa de cumprir estes
requisitos pode interferir na confiabilidade da qualidade do produto.
É notório que a qualidade do software é resultado de uma junção de fatores
que podem variar à medida que as aplicações distintas são implementadas e os
clientes solicitam o produto. Você verá com mais detalhes estes fatores e como
colocá-los em prática.
Fatores da qualidade de software

De maneira conceitual, é possível categorizar que os fatores que infl uen-
ciam a qualidade do software podem ser mensurados diretamente ou in-
diretamente.

Como em ambas as situações a mensuração (medição) precisa ser feita, é
necessário que o software seja comparado a um dado para definir uma indica-
ção de qualidade (PRESSMAN, 1995, p. 725). Diante disso, McCall e seus colegas,
citados por Pressman (1995, p. 726), promoveram uma divisão categórica que
apresentasse a utilidade dos fatores que interferem na qualidade do software.
É visível, após esta divisão, que o software foi submetido, e que três aspectos
importantes são observados: operação, revisão e transição do produto – con-
forme o Diagrama 2:
DIAGRAMA 2. FATORES DE QUALIDADE DE SOFTWARE DE MCCALL
Manutenção Portabilidade
Flexibilidade Reutilização
Testabilidade Interoperabilidade
Revisão do Transição do
Produto Produto
Operação do Produto
Corretude Confiabilidade Usabilidade Integridade Eficiência
Observe que os fatores apresentam algumas descrições sob a ótica da ope-

ração do produto. Segundo McCall (1977) citado por Pressman (1995, p. 726), a
corretude ocorre quando um programa consegue atender suas especificações e
cumprir as metas dos clientes. A confiabilidade se verifica quando um programa
consegue realizar sua função cumprindo os requisitos de precisão exigidos. Já a
eficiência trata da variedade de recursos de códigos e computação necessários
para a execução das funções de um programa. A integridade, que analisa o acesso

ao software, seja por pessoas autorizadas ou não, pode ser mais limitado. Por fim,
temos a usabilidade, que verifica o empenho direcionado à operação, preparação
à entrada e interpretação à saída de um programa (PRESSMAN, 1995, p. 727).
DICA
Para que você consiga entender as descrições dos fatores sob o ângulo
da operação do produto de software, pergunte-se: ele faz o que eu dese-
jo? (corretude); é necessário o tempo todo? (confiabilidade); funcionará
bem no hardware? (eficiência); atende aos requisitos de segurança?
(integridade); foi criado para atender os usuários? (usabilidade).
Quando analisamos estes fatores do ponto de vista da revisão, outros aspec-

tos são observados:
• Manutenibilidade: avalia o empenho disponibilizado para encontrar e sa-
nar falhas em um programa;
• Flexibilidade: verifica o esforço para alterar um programa operacional;
• Capacidade de teste: analisa a capacidade de teste de um programa para
possibilitar que ele cumpra sua função.
Por fim, é possível interpretar os fatores sob o olhar da transição do produ-
to com os seguintes aspectos:
• Portabilidade: verifica a capacidade de transferência de um programa de
hardware para software e vice-versa;
• Reusabilidade: ocorre quando um programa, ou parte dele, pode ser reu-
tilizado em outras aplicações que apresentem um conjunto de funções exe-
cutadas por ele;
• Interoperabilidade: condição em que um sistema se acopla (compõe uma
interface) com outro sistema.
É preciso compreender que estes fatores de qualidade abordados por Mc-
Call (1977 apud PRESSMAN, 1995, p. 729) estão inseridos num rol de listas indi-
cadas para a qualidade do software, denominadas “listas de conferência”. Impor-
tante mencionar também outro conjunto de fatores de qualidade de softwares
desenvolvidos pela Hewlett-Packhard (1987) citados por Pressman (1995, p. 729),
denominado Furps (inglês para funcionalidade, usabilidade, confiabilidade, de-
sempenho e suportabilidade). Este novo conjunto refuta a teoria de McCall e
seus colegas (1977) e passa a estabelecer características aos novos fatores. A

funcionalidade, por exemplo, é medida com uma avaliação dos atributos e pos-
sibilidades do programa, as características gerais das funções disponibilizadas,
além da confiabilidade (segurança) do sistema global.
A usabilidade é analisada levando em conta os chamados “fatores huma-
nos”. Já a confiabilidade avalia a intensidade e o nível dos erros apresentados,
os resultados de saída, a média de tempo entre um erro e outro, a competên-
cia em corrigir falhas, além da capacidade de previsibilidade apresentada pelo
programa. O desempenho, por sua vez, é obtido por meio de análise de velo-
cidade impressa no processamento, o tempo necessário para as respostas, a
utilização de recursos e a eficiência observada.
Por fim, e não menos importante, a suportabilidade, que une três aspectos
importantes na qualidade do software: a extensibilidade (que trata da possibi-
lidade de ampliação do programa), adaptabilidade e a capacidade do serviço,
gerando o que chamamos de manutenibilidade (PRESSMAN, 1995, p. 729). Pa-
ralelos a isso, podemos incluir outros aspectos, como a capacidade de teste, a
simplicidade na instalação de um determinado sistema, entre outros.
Vale ressaltar que estes Furps podem definir métricas de qualidade à medi-
da que a área de engenharia de software avança. Trataremos desse assunto com
mais detalhes nos tópicos seguintes.
Como garantir a qualidade de software

Um negócio que gerencia produtos utilizados por outros produtos se fun-
damenta na garantia de qualidade. Fazendo um breve contexto histórico, a ga-
rantia de qualidade era relacionada ao trabalho dos artesãos, em um período
anterior ao século XX. Segundo Pressman (1995, p. 733), os laboratórios Bell,
em 1916, foram os primeiros a desenvolver uma função mais formalizada de
garantia e controle de qualidade, e foi desenvolvida pela área de manufatura.
Quando associamos este histórico ao desenvolvimento de softwares,
percebemos que há relação com o histórico da manufatura de hardware.
Entre as décadas de 50 e 60, o programador era o responsável por verifi car
a qualidade. Somente a partir da década de 70 que os padrões de garantia
de qualidade foram inseridos no desenvolvimento de software, onde houve
uma grande disseminação deste produto no ambiente comercial.

Conceituado por Pressman (1995, p. 733) como um “padrão sistemático e
planejado de ações”, o SQA traz uma série de profissionais que participam da
sua execução (equipes de venda, engenheiros de software, entre outros).
CURIOSIDADE
O SQA deve ser desenvolvido tomando como base a visão do cliente, verifi-
cando atribuições e padrões preestabelecidos.
Atividades SQA
Até aqui você já começou a aprofun-
dar os conceitos iniciais sobre a quali-
dade de software. A SQA abrange uma
série de tarefas relacionadas a impor-
tantes atividades. Segundo a aborda-
gem de Pressman (1995, p. 734), garantia
de qualidade se relaciona à aplicação de méto-
dos técnicos, revisão técnica, introdução de
testes de software, definição de padrões,
controle de mudanças, mensuração e repa-
ração de registro de reportagens.
É visível que a qualidade do software é intro-
duzida em um sistema ou produto sem qualquer
tipo de imposição após o fato. Sendo assim, o SQA
começa reunindo um conjunto de técnicas e ferramentas que auxi-
liem o profissional responsável a adquirir uma especificação de qualidade alta,
além do projetista, que terá condições de criar um projeto de mesmo nível.
À medida que um protótipo ou projeto forem criados, ambos deverão ser
analisados em relação à qualidade. Dito isto, é importante mencionar que a
tarefa que leva em consideração a análise da qualidade é a revisão técnica
formal ( formal technical review). Esta revisão ocorre quando a equipe técnica
se reúne objetivando possíveis falhas na qualidade. Em diversas situações,
as revisões se mostram tão efetivas quanto os testes implementares para
visualizar problemas na qualidade.

DICA
Os profissionais de engenharia de software (desenvolvedores) normal-
mente utilizam a atividade-teste como uma espécie de “rede de seguran-
ça”, detectando-se, nesta fase, os erros na sua maioria, o que aliviaria a
necessidade de implantar as demais tarefas SQA.
Quando tratamos das atividades que testam os softwares, verificamos que

se juntam variadas etapas com uma sequência de métodos de exemplos de tes-
tes que auxiliam na descoberta de eventuais falhas.
No que se refere ao nível dos procedimentos e padrões formais, é preci-
so informar que ambos são implantados num grau que apresenta variações, a
depender da organização empresarial. Às vezes, o cliente é o responsável por
definir quais padrões serão estabelecidos. Havendo padrões escritos (formais),
uma atividade SQA será responsável por garantir seu seguimento.
É importante entender que os desenvolvedores de software precisam con-
siderar a análise de cumprimento de padrões como uma das etapas da revisão
técnica formal. Outro ponto é a verificação de atendimento e padrões de ma-
neira independente, pois havendo exigências, o SQA pode então se autoauditar.
Consideradas como algo que pode prejudicar a qualidade de software,
as mudanças, num primeiro momento, podem introduzir falhas ou gerar
efeitos que as aumentem. Paralelo a isto, temos o controle de mudanças,
que tem a função de, entre vários aspectos, avaliar o que leva um software
a ser alterado e controlar os efeitos desta mudança. Importante frisar que o
controle de mudanças ocorre na criação do software e, em seguida, na fase
referente à manutenção.
A medição (mensuração) são as ferramentas utilizadas pelo SQA para
acompanhar a qualidade do software e analisar os efeitos das alterações
na metodologia e nos procedimentos referentes à qualidade do software.
Ao final, abordaremos a anotação e manutenção de registro, que tratam
dos procedimentos referentes à captura e divulgação de informações, vi-
sando garantir a qualidade do software. Devido à necessidade constante
de conhecimento, isso faz com que resultados e revisões ou auditorias
façam parte do registro histórico de um projeto para que seja difundido na
equipe de desenvolvimento.

Normas de qualidade aplicadas no desenvolvimento do
software
Como já foi exposto, qualidade é
um dos assuntos mais debatidos na
engenharia de software. Desde a dé-
cada de 70, existe uma imensa preo-
cupação em produzir softwares que
tragam requisitos de qualidade mais
elevada. Entretanto, foi somente a
partir dos anos 1990 que este tema
ganhou relevância maior.
Existe hoje uma imensa produ-
ção de softwares para atender uma
demanda cada vez mais exigente,
porém não existe ainda uma padro-
nização na criação de um softwa-
re, ou os fabricantes muitas vezes
atendem a solicitações iniciais do
cliente, não disponibilizando com-
ponentes evolutivos, o que interfe-
re de maneira significativa na quali-
dade do software.
Diante de um cenário como este, desenvolver um software passou a ser
algo extremamente lucrativo na engenharia de software, ao mesmo tempo
que muitas empresas passaram a investir no desenvolvimento de sistemas
que se diferenciam em termos de qualidade. Neste contexto, foram ado-
tados modelos em que a qualidade apresentava reconhecimento interna-
cional, o que possibilitaria a certificação destes sistemas e aumentaria a
confiança dos clientes junto às empresas fornecedoras de software. Alguns
modelos criados asseguram a qualidade do produto com a normatização
dos processos utilizados ao longo da criação do software. Verificaremos
nos tópicos seguintes as normas de padronização estabelecidas para de-
senvolver softwares.

ISO 9001
É uma norma que estabelece os requisitos que possibilitam a execução de um
sistema de gestão de qualidade. Tem como principal objetivo auxiliar as organizações
empresariais no sentido de elevar a sua eficiência e o nível de satisfação do cliente.
Ela traz uma série de benefícios para a empresa ou negócio a ser implan-
tado. É possível analisar o cenário geral ao qual a empresa está inserida para
estabelecer o nível de influência que ele causa nos consumidores. Isso permite
que objetivos sejam traçados e novas oportunidades de negócio sejam aprovei-
tadas. Outra vantagem do uso da norma ISO 9001 é atender aos atributos legais
e regulamentares, além da possibilidade de expandir mercados.
Em relação à estrutura, sabe-se que essa norma é formada por uma quan-
tidade diversificada de seções que envolvem requisitos que atendem desde a
introdução e escopo da norma até a melhoria do sistema como um todo.
CURIOSIDADE
Empresas não são obrigadas a possuir a certificação ISO 9001:2016 (sua
edição mais atual), porém ela garante ao mercado consumidor que serviços
e produtos, inclusive softwares, estejam alinhados com as exigências do
cliente. A certificação pode ser obtida em algum órgão responsável (ABNT,
por exemplo) para você se credenciar e atender aos requisitos mínimos.
Importante lembrar que outras normas relacionadas à ISO 9001 também

auxiliam no desenvolvimento de sistemas de qualidade e visam garantir a sa-
tisfação do cliente. São elas:
• ABNT NBR ISO 9000 – Apresenta conceitos referentes aos princípios da
gestão de qualidade, além de oferecer informações relevantes de como as-
segurar que estes terão reflexo nas tarefas executadas pela organização
empresarial. Esta norma complementa o entendimento da ISO 9001, pois
contém as mesmas definições básicas e auxilia no desenvolvimento de um
sistema que apresenta uma gestão eficaz de qualidade;
• ABNT NBR ISO 9004 – Trata das orientações que possibilitam o atingimen-
to de êxito com o sistema de gestão de qualidade;
• ABNT NBR ISO 19011 – Orienta a realização de auditorias internas e ex-
ternas da norma ISO 9001. Essas auditorias asseguram que o sistema de

gestão de qualidade consiga cumprir suas metas. Esta norma consegue
também preparar o sistema para passar por uma auditoria externa, caso a
empresa deseje obter uma certificação na modalidade independente.
ISO 12207
Também conhecida como modelo de referência, esta norma
é padronizada internacionalmente. Tem como objetivo mais
importante disponibilizar uma estrutura ímpar para possi-
bilitar aos agentes envolvidos (fornecedor,
técnicos, clientes, desenvolvedores, dentre
outros) que usem uma linguagem comum.
Esta linguagem deve ser determinada
através de processos bem definidos.
Quanto à estrutura em que a norma se
encontra, sabe-se que foi arquitetada para
ser adaptável às demandas dos usuários. Sendo
assim, é visível que a ISO 12207 está baseada na modularidade e responsabi-
lidade. Segundo os conceitos abordados por Sant’Anna e Lahoz (2008, p. 2), a
modularidade está relacionada aos processos com acoplamento mínimo e coe-
são em nível máximo. Já a responsabilidade define um responsável para atuar
em cada processo, o que possibilita a implantação desta norma em projetos
que envolvem as pessoas habilitadas.
A norma ISO 12207 concentra as tarefas que podem ser realizadas ao lon-
go do ciclo de vida nos chamados processos primários, classificados como:
• Fundamentais: quando esse processo ocorre através do contrato
entre fornecedor e adquirente do software, além do desenvolvimento,
procedimento operacional e manutenção de produtos de software du-
rante o ciclo de desenvolvimento;
• Suporte: auxílio e contribuição que o processo possibilita para a qua-
lidade e o êxito do projeto de software;
• Organizacionais: utilizados por uma empresa para definir e aplicar
uma estrutura formada pelos processos que envolvem tanto o ciclo de
vida quanto as pessoas inseridas em seu desenvolvimento.

DICA
É importante mencionar que os processos são divididos em uma série
de atividades, e cada atividade representa um conjunto de tarefas. Cada
processo deve ser executado de maneira autônoma, ou seja, os processos
de suporte e organizacionais, por exemplo, são independentes entre si.
ISO 15504
Trata-se de um modelo de referência criado a partir de um framework para
analisar processos da área de engenharia de software, organizando negócios
e projetos. Ela também pode classificar e organizar as práticas em dimensões
denominadas em categorias de processos e níveis de capacidade.
Entenda que as categorias de processo estão relacionadas a procedimentos
mais específicos, como a engenharia e projetos, por exemplo. Já a capacidade de
organização está ligada aos níveis estabelecidos visando a sua melhoria contínua.
A ISO 15504 serve de referência
para o processo de análise, atuando
como um grupo-padrão de processos
essenciais que norteiam a engenharia
de software. Isto resulta em uma ava-
liação do perfil da instituição por meio
de uma matriz, onde processos estão
dispostos em linhas e os níveis de capa-
citação são demonstrados em colunas.
Esta norma apresenta um conjunto
composto por documentos que ofere-
cem desde a verificação de processo
até sua melhoria. Recursos como o
modelo integrado de maturidade em
capacitação para software (em inglês, capability maturity model integration –
CMMI) também se baseiam em normas como a ISO 15504. Tais modelos têm
como objetivo agregar os diferentes CMMs disponíveis, além de assegurar a
compatibilidade com a norma estabelecida por meio de uma ótica contínua de
modelo, formada por áreas de processos genéricos e essenciais.

Modelo de maturidade da captação para software
(CMM)
Diante de um ambiente onde o número de empresas que atuam no
ramo de desenvolvimento de software cresce ao passar dos anos, é possí-
vel verificar possíveis problemas na realização dos projetos. Prazos e orça-
mentos não cumpridos, insatisfação de clientes e produtos com falhas são
alguns exemplos. A que podemos atribuí-los? Bem, é quase um consenso
na engenharia de software que o desenvolvimento ocorre de forma pouco
padronizada, quase no improviso, descartando uma base mais sólida de
conhecimento que sirva de base para o trabalho.
É importante ressaltar que, nestas circunstâncias, o método CMM ob-
jetiva direcionar a empresa, implementando e melhorando de forma con-
tínua o processo de software. Isso ocorre por meio de um modelo que
abrange duas representações, divididas em estágios, dando preferência,
seguindo uma linha de raciocínio, a ações que serão realizadas.
DICA
É preciso analisar que, quanto maior o nível, consequentemente maior o grau
de maturidade das empresas. Isso vai gerar um número maior do produto final
e a possibilidade de estabelecer previsões para cronogramas e orçamentos.
O método CMM tem como meta ser referência para a evolução de pro-
cessos na empresa. Visa também ajudar no desenvolvimento da habilidade
dos profissionais de engenharia de software em gerir o desenvolvimento,
que cuida da compra e reparação de produtos ou serviços relacionados ao
software. Lembre-se também que o CMM possibilita o acompanhamen-
to ideal do desenvolvimento direcionado aos componentes do grupo. Em
projetos de grande porte, que envolvem um contingente imenso de pes-
soas e equipes, é relevante o uso do CMM. É notório que, com a ausência
destes modelos de maturidade, o controle do projeto fica comprometido.
Após essas etapas, o CMM indica um percurso baseado na evolução,
sendo indicado para uma empresa que almeja aperfeiçoar os processos
empregados para criar produtos e serviços. Esses processos também po-

dem ser colhidos através de análises feitas em empresas, entendendo-se
o funcionamento completo da organização classificada como de pequeno
porte, ou até mesmo representando um grupo de menor expressão.
O grau de maturidade atingido por uma organização é alcançado à me-
dida que os processos implantados atingem certa capacidade, o que significa
afirmar a existência de ferramentas que assegurem a frequência de resultados
satisfatórios no futuro, no que se refere ao nível de qualidade, prazos e custos.
A partir daí, é possível entender que, para estabelecer, implantar certo modelo
numa empresa, é preciso atingir determinadas fases de maneira consecutiva,
trazendo a ideia de maturidade alcançada pela organização empresarial. A al-
ternativa ocorre de forma contínua, onde é medida a possibilidade de realizar
procedimentos individualizados.
DIAGRAMA 3. CAPACIDADE E MATURIDADE ORGANIZACIONAL
ORGANIZAÇÃO
ÁREA DE PROCESSO 1 ÁREA DE PROCESSO 2
Processo 1 Nível 2 Processo 1 Nível 3

Capacidade 2

Capacidade 3

ÁREA DE PROCESSO N
Processo n Nível 3 Processo n Nível 3
Processo 1 Nível 4
Processo 2 Nível 5
Capacidade 4
Processo 3 Nível 4
Processo n Nível 4
Fonte: VASCONCELOS; MORAIS, 2009. (Adaptado).

EXPLICANDO
O CMM aborda fases de maturidade. De imediato, a organização im-
plementa sistemas tendo como referência as experiências do setor de
recursos humanos. Na última fase se percebe a aplicação de um processo
flexível e com aspecto organizado, além de um planejamento em constan-
te aprimoramento e eficiência.
É notório que uma organização empresarial alcança um grau de maturidade ele-

vado por meio de metas atingidas e entendidas a cada setor que compõe o proces-
so, as chamadas PAs (process areas). Elas têm um comportamento estático e atuam
como um conjunto de técnicas e métodos que demonstram o grau de maturidade.
PSP e TSP
Estes modelos objetivam inserir pessoas e equipes de de-
senvolvimento de software. Estruturam-se através de medi-
das do processo e são aplicados por meio de treinamentos.
Os processos de desenvolvimento conse-
guem alcançar níveis elevados de maturi-
dade por meio destes modelos quando
aplicados conjuntamente; isto facilita
de maneira significativa a aquisição
de um modelo de maturidade direcio-
nado para as empresas.
No que se refere ao modelo PSP, sa-
be-se que ele está indicado para o desen-
volvedor de software. Por sua vez, os desenvolvedores geram suas pró-
prias atividades no momento em que adquirem conhecimento ao redigir
programas. Paralelo a isto, exige-se uma mudança de comportamento no
intuito de melhorar os processos. Quando isso não ocorre, as equipes e a
organização empresarial, de maneira geral, terão dificuldades para inserir
esse melhoramento.
Quando se observa os níveis de maturidade disponibilizados pelo PSP, ob-
serva-se que ele segue a mesma linha de desenvolvimento do modelo orga-
nizacional. Na primeira fase, é preciso que os desenvolvedores estejam habili-

tados a realizar uma mensuração básica do trabalho. Na fase seguinte, esses
profissionais precisam elaborar um projeto dos trabalhos técnicos, enfatizando
o gerenciamento do tempo utilizado para concluir as tarefas.
No terceiro nível, a elevação da qualidade pessoal é instigada através de pro-
cessos de verificação do trabalho, feito de forma a antever falhas.
EXPLICANDO
O processo cíclico pessoal é considerado pelo PSP através do nível mais
elevado, ampliando a sua ótica para discutir projetos de maior extensão.
Para isto, é necessário dividir este projeto em projetos menores, que
possam ser abordados a nível pessoal, dando um aspecto incremental ao
desenvolvimento de grandes projetos.
Outro aspecto a ser analisado é o ambiente de trabalho. Se o espaço de tra-

balho não encoraja os desenvolvedores, vai ser muito difícil visualizar qualquer
atitude de melhoria de processos. Diante deste cenário, o TSP se insere como
modelo de maturidade direcionado para as equipes de trabalho, objetivando
habilitar às equipes o autogerenciamento. Neste caso, é perceptível a divisão
das responsabilidades gerenciais e de apoio.
O desenvolvimento deve ocorrer através de ciclos incrementais, visando
minimizar os riscos de cada um destes ciclos. Para que isso aconteça, é preci-
so estabelecer estratégias de planejamento antes da execução de desenvolvi-
mento. Portanto, podemos considerar que a estrutura organizacional da equi-
pe responsável pelo desenvolvimento é um fator importante para o êxito na
aplicação de uma estratégia dentro das empresas.
MPS.BR (melhoria de processo de software brasileiro)

Visando melhorar os processos de software, o MPS.BR foi criado em
2003, tentando retratar o perfil das organizações empresariais brasileiras.
Além de determinar um modelo de processos de software, serve como fer-
ramenta de análise e modelo de negócio para auxiliar as empresas brasi-
leiras que atuam no desenvolvimento de software. O MPS.BR se baseia nas
normas internacionais ISO 12207, 15504-2 e no CMM.

DIAGRAMA 4. ESTRUTURA DO MODELO MPS.BR
Modelo MPS
ISO/IEC 12207 CMMI-DEV ISO/IEC 15504
Modelo de referência (MR-MPS) Método de avaliação (MA-MPS) Modelo de negócio (MN-MPS)
Guia geral Guia de implementação Guia de aquisição Guia de avaliação Documentos do programa
Fonte: VASCONCELOS; MORAIS, 2009. (Adaptado).
Observando o Diagrama 4, é possível visualizar que o modelo de referência

(MR-MPS) possui três guias. Primeiramente o guia geral, que determina todas
as fases de alcance da maturidade, processos e requisitos de processo. Os es-
tágios de maturidade irão estabelecer o nível de evolução dos processos, atin-
gindo determinados níveis de desenvolvimento. Já o guia de aquisição detalha
as chamadas boas práticas para obtenção do software e serviços correspon-
dentes, os quais selecionam o fornecedor, aceitam o cliente, monitoram con-
tratos, entre outros. Por fim, temos a guia de implementação, que aponta ma-
neiras de programar cada uma das fases detalhadas na guia geral. Ela também
pode auxiliar uma empresa que obtém aquisições de software a implementar
um modelo MPS.
Métricas de qualidade de software

Você verificou a apresentação de uma série de fatores quantitativos utiliza-
dos para mensurar a qualidade de um software. Segundo o conceito de Som-
merville, as métricas são “medidas de previsão utilizadas para mensurar atribu-
tos internos de um sistema de software” (2011, p. 468). Quando observamos o
volume de um sistema medido através de linhas de código, ou a quantidade de

métodos ligados a cada classe de objeto, podemos defini-los como exemplos de
métricas de produto.
Existe um empenho por parte dos profissionais da área em desenvolver
medições exatas de qualidade do software. Entretanto, a natureza subjetiva da
atividade causa certa frustação. Segundo Cavano e McCall (1978) citados por
Pressman (1995, p. 753), a determinação da qualidade é um fator fundamental
no cotidiano das pessoas. Eventos esportivos ou concursos, por exemplo, ge-
ralmente têm a qualidade julgada de forma mais direta e fundamental. Normal-
mente, uma pessoa (objeto) é comparada a outra pessoa, com conceitos defini-
dos a priori e em igualdade de condições, porém, julgamentos desta natureza
tendem a ser muito subjetivos; para adquirir valores absolutos, especialistas
deverão ser consultados.
DICA
Os aspectos de um software, como o tamanho e a complexidade ciclomática,
podem ser mensurados com certa facilidade, porém não é possível estabelecer
uma relação consistente e esclarecedora com os requisitos de qualidade,
como a capacidade de compreensão e a manutenibilidade.
Você já consegue compreender que a subjetividade e a especialização são

elementos utilizados para estabelecer a qualidade do software. Com isso, é ne-
cessário definir, de maneira mais precisa, os indicadores ideais de qualidade de
software, assim como uma forma de gerar medições quantitativas de qualida-
de de software que visem uma análise objetiva, levando em consideração que
o conhecimento não é absoluto e que as medições podem apresentar certo
nível de imperfeição (PRESSMAN, 1995, p. 754).
As métricas de produto podem ser analisadas basicamente através de
duas classes:
• Métricas dinâmicas: extraídas através de medições realizadas a partir de
um programa em andamento. Essas métricas podem ocorrer no momento
de um teste de sistema ou depois de ele estar em uso;
• Métricas estáticas: obtidas através de medições realizadas de represen-
tações provenientes do sistema. Um projeto, a documentação ou um pro-
grama são exemplos dessa métrica.

Segundo Sommerville (2011, p. 468-469), um exemplo de métrica dinâmica
é a quantidade de relatórios de bugs ou o tempo necessário para encerrar uma
computação. No que se refere às métricas estáticas, é possível mencionar o
tamanho de código e o comprimento médio de identificadores utilizados.
As métricas apresentadas estão ligadas a requisitos de qualidade distintos. Métri-
cas dinâmicas, por exemplo, auxiliam a análise do grau de confiabilidade e eficiência
do programa. Já as métricas estáticas verificam o nível de complexidade, compreen-
são e manutenção de um sistema. Isso nos leva à compreensão de que as métricas
dinâmicas têm relação direta com as qualidades de um software, pois o tempo ne-
cessário para exercer as funções particulares e iniciar o sistema é considerado de fácil
mensuração. Sua função é verificar a eficiência do sistema, ao mesmo tempo que a
quantidade e os tipos de erro são registrados, definindo seu nível de confiabilidade.
No que se refere às métricas estáticas, pode-se verificar uma ligação indi-
reta com os requisitos de qualidade. É preciso entender que diversas métricas
foram formuladas e muitos testes foram realizados na tentativa de derivar e
validar a relação entre tais métricas e os requisitos de qualidade, como a manu-
tenibilidade e a complexidade do sistema. Os testes não apresentaram resul-
tados conclusivos, mas o tamanho do programa e a complexidade de contro-
le são os meios mais confiáveis para prever aspectos ligados à compreensão,
complexidade e manutenção de sistema (SOMMERVILLE, 2011, p. 469).
CURIOSIDADE
Uma terceira categoria de métricas pode ser discutida: as métricas orienta-
das a objetos (OO), ou suíte CK. Teorizadas por Chidamber e Kemerer (1994),
citados por Sommerville (2011, p. 469), servem de base informacional para
projetos de linguagem de modelagem unificada (em inglês, unified modeling
language – UML), criando-se os diagramas UML. Apesar da sua utilidade,
ainda não há provas suficientes para entender como estas métricas orienta-
das a objetos se relacionam com as qualidades externas de software.
Verificaremos nas seções seguintes aspectos sobre as análises de componen-

tes de software, os exemplos de indicadores de qualidade aplicados, além das
teorias de Halstead e McCable no que se refere à ciência de software e complexi-
dade das métricas. Importante frisar que, segundo Pressman (1995, p. 754), as
métricas representam, na verdade, medidas indiretas, pois o que realmente

se mensura é a manifestação da qualidade e não a qualidade em si. Portan-
to, a relação exata entre qualidade de software e variável mensurada gera o
chamado “fator complicador”.
Análise de componentes de software

Como você já deve ter percebido, um processo de medição tem relação com
a análise da qualidade de software. Uma diversidade de métricas pode ser utili-
zada, o que possibilita que cada elemento do sistema seja avaliado de maneira
separada. A comparação com componentes distintos e a coleta de dados pro-
venientes de projetos anteriores influenciam na determinação dos valores atri-
buídos às métricas. Medições que não atendem às normas estabelecidas (medi-
ções anômalas) indicam problemas relacionados à qualidade dos componentes.
A medição de componente pode ser dividida em fases, conforme se visualiza
no Diagrama 5:
DIAGRAMA 5. PROCESSO DE MEDIÇÃO DE PRODUTO
Escolher medições a Identificar medições

serem efetuadas anômalas
Selecionar componentes Analisar componentes

a serem avaliados anômalos
Medir características
de componentes
Fonte: SOMMERVILLE, 2011. (Adaptado).

Escolher medições a serem efetuadas – Refere-se às questões que
precisam ser formuladas para serem respondidas pelas métricas, e estas
necessitam ser definidas com exatidão. Lembre-se que métricas irrelevan-
tes não necessitam ser coletadas.
Selecionar componentes a serem avaliados – Uma informação im-
portante sobre a medição do produto se refere ao fato de muitas vezes
não haver a necessidade de analisar os valores de métricas referentes a
todos os elementos de um sistema de software, pois o uso de um conjunto
representativo de elementos para a mensuração já possibilita a análise
geral da qualidade do sistema. Centrar as atividades nos elementos prin-
cipais do sistema também é uma alternativa interessante no momento de
estabelecer a qualidade.
Medir características de componentes – Os componentes são medi-
dos depois de selecionados, enquanto as métricas associadas e os valores
são computados. Essa relação ocorre por meio da representação do com-
ponente utilizando um método de coleta de dados de maneira automati-
zada. Pode ser um método escrito ou através de um recurso de métodos
aplicados a projetos em execução.
Identificar medições anômalas – Após a conclusão das métricas dos ele-
mentos, deve ocorrer a comparação entre estes componentes e as medições
realizadas anteriormente, normalmente arquivadas nos bancos de dados das
métricas. Uma dica importante é buscar valores anormais, em níveis altos ou
baixos, direcionados para cada métrica, já que estes sugerem a existência de
problemas com o elemento que apresenta tais valores.
Analisar componentes anômalos – É sempre impor-
tante identificar se os componentes apresentam valores
anômalos para a medida escolhida e verificar
se esses valores comprometem a qualida-
de do componente. Também é necessá-
rio desmistificar a ideia de que um va-
lor anômalo de métrica representa um
componente de qualidade ruim, pois às
vezes existem outros motivos que geram
um alto valor para este elemento.

DICA
É preciso manter os dados extraídos como insumo para empresas e registros
referentes a todos os projetos, considerando a hipótese de que alguns dados
não tenham sido empregados em certo projeto. Quando se obtém um banco de
dados de medições extenso, é possível conferir a qualidade no software entre
os projetos, além de validar as relações entre os requisitos de componentes no
ambiente internos e os atributos de qualidade.
Indicadores de qualidade de software

Segundo Pressman (1995, p.
754), o comando de sistemas da For-
ça Aérea Americana criou uma se-
quência de indicadores da qualida-
de do software, tomando como base
as características de projeto de um
programa de computador que po-
dia ser mensurável. Através de con-
ceitos semelhantes implementados
por outras bases militares, a Força
Aérea Americana utiliza informações extraídas dos dados e dos projetos
arquiteturais para criar o índice de qualidade da estrutura de projeto (em
inglês, design structure quality index – DSQI). A este índice são atribuídos
valores que variam entre 0 e 1, onde os valores seguintes deverão ser ob-
servados para computar o DSQI.
Os indicadores de qualidade de software são estabelecidos variando
por meio de nomenclaturas “S”, que estabelecem parâmetros entre os nú-
meros S1 e S7. De acordo com a conceituação de Pressman (1995, p. 754),
os valores observados para computar o DSQI podem ser assim descritos:
• S1 – Significa, na arquitetura do programa, o número total de módulos;
• S2 – Trata do número de módulos, onde a sua funcionalidade correta
está relacionada à origem da entrada de dados. A outra função está
ligada à produção de dados utilizados em locais distintos;
• S3 – Relaciona-se ao número de módulos, onde o desenvolvimento da
função precisa da realização do processo anterior;

• S4 – Trata da quantidade de elementos que compõem o banco de da-
dos. Pode-se incluir objetos de dados e requisitos que criam objetos
neste tipo de nomenclatura;
• S5 – É o número de elementos que compõem o banco de dados únicos;
• S6 – Representa o número de segmentos dentro do banco de dados;
• S7 – Número de módulos que apresentam uma única entrada e saída.
Após a determinação destes valores, é possível inserir valores interme-
diários (D) para serem computados. São eles:
• Estrutura de programa (D1): havendo a utilização de um método dis-
tinto no desenvolvimento de um projeto arquitetural, o valor de D1 será
igual a 1. Caso contrário, o valor de D1 = 0.
• Interdependência modular (D2): é obtida através da fórmula matemática:
D2 = 1 - (S2/S1)
Onde S2 e S1 são os valores determinados para módulos, itens e seg-
mentos definidos anteriormente.
Seguindo a mesma linha de raciocínio, é possível definir os outros valo-
res intermediários através das fórmulas matemáticas, expressas a seguir:
• Módulos não dependentes de
processamento anterior: D3 = 1 –
(S3/S1);
• Tamanho do banco de dados =
D4 = 1 – (S5/S4);
• Compartimentalização do ban-
co de dados = D5 = 1 – (S6/S4);
• Característica da entrada/ saída
modular = D6 = 1 – (S7/S1).
Estabelecendo os valores inter-
mediários, o DSQI será computado
da seguinte forma:
DSQI = ∑wiDi, onde i é a variação
entre 1 e 6, o wi refere-se ao peso
relativo, onde os valores intermediá-
rios demonstram sua importância, e
∑wi aborda o somatório destes pe-

sos relativos. Segundo Pressman (1995, p. 756), caso os valores atribuídos
a Di apresentem o mesmo peso, o valor de wi será 0,167.
O valor do DSQI nos projetos finais pode ser estabelecido e comparado
com projetos em desenvolvimento. O DSQI, caso apresente valores infe-
riores à média, acarretará na indicação de um trabalho contendo projetos
adicionais e uma revisão. De maneira similar, alterações relevantes em um
projeto já existente causarão efeitos sobre DSQI.
Outra questão importante se refere à introdução ao índice de maturi-
dade de software (em inglês, software maturity index – SMI), que apresenta
uma referência de estabilidade de um software. Vale mencionar que esta
estabilidade se baseia em alterações surgidas a cada versão apresentada
do produto.
Segundo Pressman (1995, p. 756), esse índice de maturidade pode ser
expresso através da seguinte fórmula:
SMI = [MT – (Fa + Fc + Fd)]
MT
Onde:
MT = Quantidade de módulos da versão atual;
Fc = Quantidade de módulos alterados na versão atualizada;
Fa = Número de módulos adicionados na versão atual;
Fd = Número de módulos da versão anterior excluído da liberação atual.
A estabilização do produto se relaciona à aproximação do SMI a um de-
terminado valor = 1. Este índice pode ser utilizado como métrica que possi-
bilita o planejamento das tarefas de reparação do software. A produção de
um software se relaciona com o SMI. Sendo assim, os modelos empíricos
podem ser desenvolvidos visando o empenho na manutenção.
A ciência de software de Halstead

A ciência de software traz algumas teorias que auxiliam no entendimento
sobre softwares de maneira geral. Uma destas teorias é a ciência de software
de Halstead (1977), citado por Pressman (1995, p. 767). Consiste em medidas
compostas de complexidade de software, sendo uma das mais conhecidas e

estudadas na engenharia de software. Aqui são estabelecidas as leis analíticas
referentes ao software do computador.
É graças à ciência de software que as leis quantitativas são designadas ao
desenvolvimento do software no computador. Neste contexto, a teoria de
Halstead defende a ideia de que o cérebro humano adota uma série de normas
mais rígidas do que de fato tem consciência.
Importante mencionar que a ciência de software utiliza uma série de me-
didas primitivas derivadas após a geração do código ou estimadas após a
finalização do projeto. São elas:
• n1 = quantidade de operadores diferentes que surgem em um programa;
• n2 = quantidade de operandos distintos que surgem em um programa;
• N1 = número total de ocorrências realizado pelos operadores;
• N2 = número total de ocorrências com os operandos.
EXPLICANDO
Estas expressões também são utilizadas para definir, segundo Pressman
(1995, p. 757), o volume mínimo potencial, o volume real, o nível de progra-
ma, o nível de linguagem, empenho e tempo do desenvolvimento e, por fim,
a quantidade planejada de erros do software.
As medidas primitivas empregadas por Halstead visam desenvolver expres-

sões que atendam ao comprimento global do programa, e o comprimento N,
definido por ele, pode ser formulado e calculado da seguinte forma:
N = n1log2n1 + n2log2n2
Enquanto o volume do programa é apresentado como:
V = Nlog 2 (n1 + n2)
O volume varia de acordo com a linguagem de programação, e irá represen-
tar o volume de informação solicitado para especificar um programa do ponto
de vista teórico, havendo volume em nível mínimo direcionado a um algoritmo
em particular. É possível também definir um índice volumétrico, como a relação
entre o volume do programa real com o volume que apresenta a forma mais
compacta de um programa. O índice volumétrico é menor que 1 e pode ser
expresso através da fórmula:
L = (2/m) x (n2 /N2)

A proposta de Halstead consiste em dizer que cada linguagem pode ser ca-
tegorizada variando de acordo com a linguagem estabelecida. Ele elaborou a
tese de que o nível de linguagem se mantém constante para certa modalidade.
Verifica-se que o trabalho de Halstead se mostra aberto a uma análise
experimental. Diante disto, uma extensão de pesquisa realizada investigou a
ciência de software e os resultados encontrados apresentaram certa concor-
dância entre o que foi previsto e o que de fato foi experimentado.
Métrica de complexidade de McCabe

Trata-se de uma medida de complexidade de software desenvolvida por Tho-
mas McCabe, que se baseia em uma representação do fluxo do controle de um
programa (PRESSMAN, 1995, p. 760).
DIAGRAMA 6. COMPLEXIDADE DO GRÁFICO DE FLUXO DE CONTROLE
Fonte: PRESSMAN, 1995, p. 761. (Adaptado).
Observando o Diagrama 6, é possível visualizar o fluxo de controle. As letras

envolvidas no círculo representam uma tarefa de processamento e a represen-
tação do fluxo e controle ocorre através das setas de ligação. Verificando G, ob-
serva-se a atividade de processamento a. No que se refere à atividade de pro-

cessamento b será acompanhada por e, onde as duas poderão ser executadas.
Segundo a definição de McCabe, uma medida de complexidade de software
está referenciada na chamada complexidade ciclomática. A métrica de McCa-
be apresenta uma medida quantitativa, demonstrando o nível de complexidade
para realizar testes e apontar a confiabilidade final.
Medições ambíguas
A coleta de dados quantitativos, além do processo de software, requer o
entendimento do profissional que manipula e analisa estes elementos. Infeliz-
mente, é comum interpretá-la de maneira errada e fazer inferências incorretas
(SOMMERVILLE, 2011, p. 471). É preciso que você não apenas visualize os dados,
mas também considere o contexto em que são adquiridos. Isto abre margem
para ambiguidades no momento de compreender as medições do software.
Imagine, por exemplo, um gerente de desenvolvimento que decide alterar
um software se baseando nas solicitações do cliente, mas não interpreta cor-
retamente quais itens precisam ser modificados e cria pressuposições apenas
para satisfazê-lo e reduzir custos. Ao final, percebe que as solicitações dos
clientes aumentam e não consegue entender como isto ocorreu, ficando im-
possibilitado de analisar os efeitos das mudanças realizadas. Como solucionar
o problema?
Este tipo de problema só é compreendido se você entender as razões pe-
las quais os clientes solicitam mudanças. Quando, por exemplo, o software
não funciona corretamente e não realiza as funções que os clientes desejam,
eles solicitam alterações para que o software funcione. Uma segunda situação
pode ocorrer quando o software apresenta uma qualidade elevada e é ampla-
mente utilizado. Neste caso, as solicitações ocorrem devido à criatividade dos
usuários que sugerem mudanças possíveis.
Dito isto, a solução encontrada é elevar o nível de participação do cliente
para diminuir a quantidade de solicitações de alterações em que os clientes
apresentavam descontentamento. A eficiência percebida por conta das altera-
ções torna o software mais adaptável e usável, porém as mudanças podem não
funcionar e, por conta disto, os clientes podem demandar um sistema alterna-
tivo. As solicitações de mudanças se reduzem porque o produto também re-

duziu o seu mercado por conta da concorrência. Isso resulta automaticamente
numa quantidade menor de usuários.
É preciso compreender que mudanças no processo podem atrair clientes no-
vos que queiram se envolver no desenvolvimento do produto, gerando mais so-
licitações de mudança. Tratar estas solicitações de forma mais efetiva eleva esta
tendência se as organizações se mostrarem mais abertas a sugestões dos clien-
tes, os quais, por sua vez, acreditam que as solicitações enviadas serão impor-
tantes para as empresas e incorporadas aos próximos softwares desenvolvidos.
Não é suficiente apenas saber a quantidade de solicitações de mudan-
ças. Saber quem solicitou, qual a metodologia de uso e o motivo da soli-
citação é importante, além das informações sobre fatores externos, como
mudanças ocorridas no mercado. Estas informações possibilitam saber se as
alterações de processo foram suficientes para elevar a qualidade do software
(SOMMERVILLE, 2011, p. 472).
Você entende que as dificuldades de entendimento das consequências pro-
vocadas pelas mudanças e a teoria científica disponibilizada para tratar desse
problema podem diminuir os fatores que influenciam as métricas realizadas,
porém não há separações ou isolamentos dos produtos e processos em rela-
ção a sua atmosfera negocial.
Existe uma constante mudança no ambiente dos negócios, o que torna in-
viável proibir alterações nas práticas de trabalho. Uma dica importante é evitar
que dados quantitativos que tratam sobre tarefas humanas não possam se
basear no valor de face. Diversas vezes os motivos pelos quais um valor men-
surado se altera são subjetivos, por isso devem ser analisados detalhadamente
antes de se chegar a conclusões errôneas.

Sintetizando
O gerenciamento de qualidade de software visa garantir que ele apresente
um número reduzido de falhas e consiga se adaptar aos padrões exigidos. É
importante definir quais os padrões estabelecidos e visualizar se foram atendi-
dos. Também é necessário documentar uma série de procedimentos de garan-
tia de qualidade, inseridos em manuais nas organizações. Estes procedimentos
se baseiam em métodos sugeridos pela norma ISO 9001.
A mensuração de um software pode extrair dados quantitativos relaciona-
dos a ele e a seu processo. É possível empregar os valores das métricas de soft-
ware extraídos para realizar inferências relacionadas à qualidade do produto
e do processo.
Conclui-se que as métricas de qualidade de produto são úteis para enfatizar
elementos anômalos que apresentam problemas relacionados à qualidade, de-
vendo ser avaliados com mais detalhes posteriormente.

LAHOZ, C.; SANT’ANNA, N. Os padrões ISO/IEC 12207 e 15504 e a modelagem
de processos da qualidade de software. São Paulo: INPE, 2003. Disponível em:
<http://mtc-m16c.sid.inpe.br/col/lac.inpe.br/worcap/2003/10.20.14.01/doc/Lahoz-
Workcap_versaofinal.pdf>. Acesso em: 14 maio 2019.
PRESSMAN, R. S. Engenharia de software. Tradução de José Carlos Barbosa dos
Santos. São Paulo: Pearson Education, 1995.
SOMMERVILLE, I. Engenharia de software. Tradução de Ivan Bosnic e Kalinka Gon-
çalves. 9. ed. São Paulo: Pearson Prentice Hall, 2011.
TONINI, A. C.; CARVALHO, M. M.; SPINOLA, M. M. Contribuição dos modelos de qua-
lidade e maturidade na melhoria dos processos de software. Production, v. 18, n.
2, São Paulo, 2008. Disponível em: <http://www.scielo.br/scielo.php?script=sci_art-
text&pid=S0103-65132008000200006>. Acesso em: 14 maio 2019.
VASCONCELOS, A. M. L.; MORAIS, L. Modelos de maturidade para processos
de software: CMMI e MPS.BR. Recife: UFPE, 2009. Disponível em: <http://www.
cin.ufpe.br/~processos/TAES3/Livro/00-LIVRO/08-CMMI_MPSBR_v6_CORRIGIDO.
pdf>. Acesso em: 14 maio 2019.

UNIDADE
4 MODELAGEM DE
SISTEMAS

Descrever os aspectos relacionados à modelagem de sistemas e aos tipos
de modelos de software;
Entender o processo unificado aberto (OpenUP) e suas características;
Apresentar a conceituação sobre Swebok e seus aspectos.
Tópicos de estudo
Modelagem de sistemas Swebok
Modelos de contexto Categorias do conhecimento da enge-
Modelos de interação nharia de software
Modelos estruturais Áreas de conhecimento
Modelos comportamentais Aspectos do Swebok
Tipos de modelo de software

Modelo codificar e consertar
Modelo V
Praxis
O processo unificado aberto (OpenUP)

RUP
AUP
OpenUP

Modelagem de sistemas
Já discutimos pontos importantes relacionados ao software, desde seu de-
senvolvimento até a verificação da qualidade. Neste capítulo, abordaremos as-
pectos destacando a modelagem dos sistemas e outros processos relacionados
ao desenvolvimento do software. De imediato, detalharemos a modelagem de
sistemas desenvolvidos como um dos requisitos nos processos de engenharia
de requisitos e de projeto de sistema.
Segundo Sommerville (2011, p. 82), a modelagem de sistemas consiste num
desenvolvimento baseado no modelo de abstração. Vale salientar que cada mo-
delo abrange uma perspectiva ou ótica distinta do sistema. Normalmente, esta
modelagem se apresenta de duas formas para representar o sistema: a primeira
é através de alguma notação gráfica (linguagem de modelagem unificada – UML);
a segunda ocorre por meio de modelos formais, que utilizam ferramentas mate-
máticas e apresentam-se como especificação do sistema.
CURIOSIDADE
Os modelos possuem uma série de funcionalidades aplicadas durante
o seu desenvolvimento. Durante o processo de engenharia de requi-
sitos, eles auxiliam na coleta de atributos do sistema. Ao longo do
projeto, os modelos detalham o sistema e o tornam acessível para os
engenheiros. Por fim, ao término, viabilizam a operação do sistema e
documentam sua estrutura.
É possível desenvolver modelos de sistemas, tanto dos que já existem quanto

dos que serão implementados. Os modelos de sistemas existentes são emprega-
dos ao longo da engenharia de requisitos com o objetivo de esclarecer as funções
do sistema que já existem, possibilitar o debate dos seus pontos fortes e fracos e
implementar os requisitos ao novo sistema. Quando se refere ao modelo de um
sistema novo, sabe-se que também são empregados durante a engenharia de
requisitos visando a apresentar os requisitos sugeridos para outros stakeholders
do sistema. Eles são utilizados para debater sugestões de projeto e documentar
o sistema para a implementação. É importante dizer que, num processo de en-
genharia direcionado a modelos, existe a possibilidade de criar uma aplicação de
maneira parcial ou completa, por meio de um modelo de sistema.

Uma característica comum a um modelo de sistema é a falta de detalhes,
ou seja, ele não pode ser uma alternativa, e sim uma abstração do sistema
como um todo. Você pode estar pensando que um modelo deve trazer todas
as informações do sistema, porém uma amostra dele é suficiente para sinte-
tizar e escolher os requisitos mais importantes. Imagine um escritor sendo
entrevistado para apresentar o seu livro em programa de TV. Logicamente,
ele vai expor os pontos principais para um entendimento superficial sobre o
tema que ele aborda. A mesma analogia serve para diferenciar a funciona-
lidade de um modelo e o sistema propriamente executado.
DICA
É possível criar diferentes modelos que representem o sistema através
de perspectivas distintas. Pode ser por meio de uma perspectiva externa,
na qual você define o modelo do contexto; interação, em que é possível
ajustar as interações entre um sistema e seu ambiente; estrutural, em que
você modela a ordenação de um sistema ou a estrutura dos dados pro-
cessados por ele; por fim, a comportamental, em que é possível adaptar o
comportamento multifuncional do sistema e sua reação quando submetido
a outros eventos.
A linguagem de modelagem padrão orientada a objetos provém de dia-

gramas estabelecidos em UML. Por sua vez, a UML dispõe de uma diversida-
de de diagramas que possibilitam a criação de modelos de sistemas varia-
dos. Porém, segundo o entendimento de Erickson e Siau (2007), citados por
Sommerville (2011, p. 83), somente cinco tipos de diagrama sintetizam o que
há de mais importante para formular um sistema. São eles:
• Diagrama de atividades: apresenta as tarefas referentes ao processa-
mento de dados;
• Diagrama de casos de uso: apresenta as interações entre um sistema
e seu ambiente;
• Diagrama de sequência: expõe as relações entre os componentes do
sistema;
• Diagrama de classes: mostra os tipos de objeto no sistema e suas in-
ter-relações;
• Diagrama de estado: demonstra como o sistema reage a eventos in-
ternos e externos.

Vale ressaltar que uma notação gráfica pode ser flexível à medida que os
modelos de sistemas são desenvolvidos. A pretensão de como o modelo vai ser
empregado é a atividade que requer um nível mais elevado de detalhamento
e rigidez. Geralmente, os modelos gráficos são divididos em três maneiras: fa-
cilitando o debate entre o sistema existente e o sugerido; documentando um
sistema em execução; e descrevendo, de maneira detalhada, um sistema.
Especificando cada uma dessas formas, você poderá verificar algumas ca-
racterísticas importantes. De imediato, a principal meta do modelo é promo-
ver uma importante discussão entre os profissionais da área de engenharia
de software que atuam na criação de um sistema. Esses modelos podem se
apresentar de maneira incompleta, utilizando uma notação de modelagem de
maneira informal, classificada normalmente como modelagem ágil.
Quanto ao fato de os modelos serem utilizados como documentação, saiba
que eles não necessitam estar formulados de maneira completa, já que é pos-
sível desenvolver modelos com o intuito de suprir alguns setores do sistema.
Porém, é imprescindível a assertividade na utilização dos modelos, nos quais
a notação deve ser usada de maneira correta, apresentando uma descrição
exata do sistema (SOMMERVILLE, 2011, p. 83).
Por fim, os novos modelos precisam estar dispostos de maneira inte-
gral e assertiva, já que são empregados como referência para criar o cha-
mado código-fonte do sistema. Ressalte-se que, quando você desenvolver
esse tipo de modelo, precisa redobrar a sua atenção para não confundir,
por exemplo, símbolos semelhantes que apresentam signifi cados distintos,
como setas de ponta e blocos.
Modelos de contexto
No início de qualquer fase, é preciso definir até onde o sistema pode expan-
dir. Trata-se de uma atividade que envolve a presença de stakeholders do siste-
ma com o objetivo de estabelecer qual funcionalidade o sistema deve incluir e
o que será oferecido pelo seu ambiente.
Cabe a quem desenvolve os modelos decidir se o auxílio para os processos,
que envolvem negócios, será realizado de maneira automatizada ou manual,
baseado em sistemas diferentes. No que se refere à funcionalidade, é preciso

observar as sobreposições que podem surgir em relação aos sistemas sendo
executados e definir como e onde a nova funcionalidade será aplicada. Atente-
-se ao fato de que isto deve ser estabelecido no início do processo como manei-
ra de estabelecer um limite de custos, e defina o tempo preciso para identificar
e entender os atributos e o projeto do sistema.
CURIOSIDADE
É importante visualizar o limite entre o sistema e o ambiente onde está
inserido. É muito comum que, num sistema automatizado que substitua
outro já existente, o ambiente permaneça o mesmo. Em outras situa-
ções, é possível definir um nível de flexibilidade e, ao longo do proces-
so que envolve a engenharia de requisitos, estabelecer um limite, o
sistema e seu ambiente.
Você pode estar se questionando: qual é o limite a ser estabelecido? Bem,

a definição do limite do sistema é extremamente complexa e pode envolver
interesses que levam em consideração fatores não técnicos. É possível, por
exemplo, que a limitação ocorra de maneira deliberada, em que o processo
aconteça em um site, posicionando-se quando o custo do sistema for mais
elevado ou quando uma equipe de desenvolvimento do sistema precisar
ampliar sua atuação para implementar o sistema. Logo após a tomada de
decisão referente às delimitações do sistema, parte da tarefa que envolve a
análise consiste na definição desse contexto e das influências que o sistema
sofre do seu ambiente.
Um ambiente normalmente apresenta uma série de sistemas automati-
zados, como é demonstrado pelos modelos de contexto. Porém, estes mes-
mos modelos não apresentam a relação entre os sistemas no ambiente com
os que estão sendo desenvolvidos de forma mais específica. A produção e
o compartilhamento de dados entre os sistemas, conectados diretamente
ou por meio de redes, podem de alguma maneira influenciar nos atributos
e na elaboração do projeto do sistema. Para exemplificar isso, citamos os
modelos de contexto simples, utilizados com modelos que envolvem pro-
cessos de negócio. Segundo Sommerville (2011, p. 85), estes apresentam os
processos humanos e os automatizados em que os sistemas de software
específicos são empregados.

DIAGRAMA 1. MODELO DE CONTEXTO SIMPLES
<<Sistema>> <<Sistema>>
Sistema de registro Sistema de
de pacientes admissões
<<Sistema>>
<<Sistema>>
Sistema <<Sistema>>
Sistema de
degerenciamento MHC-PMS
prescrições
de relatórios
Sistema de Sistema de
estatísticas agendamentos
O Diagrama 1 mostra, com um exemplo, um modelo de contexto simples

através de um sistema de informação de pacientes ligados a outros sistemas,
inseridos no seu ambiente.
Percebe-se que o MHC-PMS está ligado a um sistema generalista de agenda-
mentos, e ao mesmo tempo se encontra interligado a um sistema onde se regis-
tram pacientes, compartilhando dados. Também existe uma conexão com os sis-
temas responsáveis pelo gerenciamento de relatórios, a acomodação dos leitos e
um sistema que colhe dados estatísticos direcionados à pesquisa. Ao fim, é possí-
vel verificar um sistema de prescrições com o objetivo de criar receitas destinadas
aos pacientes. Portanto, o que podemos visualizar com este modelo é que os siste-
mas podem compartilhar informações pertinentes com outros sistemas, a fim de
proporcionar um melhor funcionamento do sistema de maneira geral.
EXEMPLIFICANDO
MHC-PMS (Sistema de Gerenciamento de Pacientes) consiste em um
sistema de informações utilizadas em clínicas e hospitais. Ela tem como
referência um banco de dados que centraliza as informações referentes
aos pacientes, e seu projeto permite que seja disponibilizado em um PC.

Sommerville (2011, p. 85) nos indica outro exemplo do uso MHC-PMS, que
pode ser visualizado Diagrama 2, e demonstra graficamente um processo de
sistema. O modelo se baseia no comportamento de pacientes acometidos por
problemas mentais graves, o que representa certo perigo para os outros doen-
tes. Em casos como este, a internação normalmente é difícil e requer deter-
minações jurídicas para serem executadas. Um dos objetivos do MHC-PMS é
assegurar que as determinações sejam de fato aplicadas.
DIAGRAMA 2. EXEMPLO DE ATIVIDADES UML
Modelo de processos de internação involuntária

Transferir para
[Não disponível]
delegacia de polícia
Informar
assistência social
Encontrar local seguro
Transferir para Informar

Informar paciente [Disponível]
hospital seguro parentes próximos
dos direitos
[Perigoso]
Registrar decisão
de internação Atualizar registro
Admitir no hospital
[Não perigoso]
<<Sistema>>
Sistema de
MHC-PMS MHC-PMS
admissões
O Diagrama 2 registra as atividades da UML, mostrando as atividades que for-

mam um processo de sistema e o fluxo de controle de uma tarefa para outra. Para
facilitar a visualização, o círculo preenchido representa a fase inicial do processo, e
no final temos um círculo preenchido por outro. Os retângulos cujos cantos estão
na forma mais arredondada indicam as tarefas que precisam ser executadas.
É possível afirmar que as setas indicam o ciclo de trabalho de uma ta-
refa para outra, no qual uma barra considerada sólida é empregada para
demonstrar a coordenação de atividades que devem ser encerradas antes
da possível evolução. A barra sólida permite que uma série de tarefas possa
ser realizada simultaneamente.

Com isso, conclui-se que o objetivo de tais atividades é trazer subsídios su-
ficientes para facilitar a internação e o acompanhamento dos pacientes que
demandam mais cuidados.
Modelos de interação
A interação é uma prática comum entre os sistemas. Isso é visível desde a
interação entre os usuários até as que ocorrem entre os componentes. Quando
se trata da modelagem da interação, é preciso destacar sua importância graças
ao auxílio oferecido na identificação dos atributos dos usuários.
Problemas relacionados à comunicação podem ser reconhecidos pelo siste-
ma de modelação da interação. Diante disso, esta modelagem consegue auxi-
liar na compreensão da estrutura disponibilizada para o sistema e verificar se
ela consegue apresentar um nível de desempenho e confiança que atenda às
necessidades exigidas.
Este tipo de modelagem traz basicamente duas abordagens. São elas:
• Modelagem de caso de: propõe modelos de interação que envolvem um
sistema e agentes externos, ou seja, outros agentes ou sistemas diferentes;
• Diagramas de sequência: criam modelos de interação entre os compo-
nentes do sistema. É importante ressaltar que os agentes externos podem ser
incluídos nesta abordagem.
CURIOSIDADE
Por apresentarem níveis de detalhamento distintos, tanto os modelos de
caso quanto os diagramas de sequência podem ser empregados em con-
junto. Por exemplo, em um caso de uso que apresente um elevado nível,
os detalhes pertinentes às interações podem ser documentados em um
diagrama de sequência.
Desenvolvida na década de 1990 e incorporada ao primeiro release da

UML, a modelagem de caso de uso tem como principal função auxiliar e
apoiar a elicitação de requisitos, na qual, através de um cenário simplista,
é possível descrever as expectativas do usuário em relação ao sistema.
Essa modelagem simboliza uma atividade em caráter discreto, que envolve
um sistema com a interação externa.

Para mostrar um exemplo, observe o Diagrama 3, que trata do caso de uso
por meio da transferência de dados.
DIAGRAMA 3. MODELAGEM DE CASO DE USO
SISTEMA DE
RECEPCIONISTA TRANSFERIR
REGISTRO DE
DO MÉDICO DADOS
PACIENTES
O Diagrama 3 demonstra um caso de uso do MHC-PMS. Percebe-se que a

ilustração simboliza a missão de transferir os dados do MHC-PMS com destino
a um sistema generalista de registro de pacientes, em que é realizada uma
síntese dos dados colhidos. As setas indicam que a operação é iniciada pelo
recepcionista do médico, e os dados coletados são direcionados para o sistema
de registro de pacientes (SOMMERVILLE, 2011, p. 86).
DICA
Como pode ser visualizado, um diagrama de casos de uso oferece um
aspecto limitado de uma interação. Diante disso, é preciso disponibilizar
mais detalhes para compreender o sistema de maneira geral. Uma descri-
ção textual ou um diagrama de sequência são exemplos desses detalhes.
Tratando agora dos diagramas de sequência em UML, você pode compreen-

der que esses modelos são utilizados para gerar interação entre usuários e
objetos dentro de um sistema, além das interações entre os próprios objetos.
Precisamos ressaltar que UML harmoniza com diagramas de sequência, o que
possibilita definir modelagem para diversos tipos de interação. Como o próprio
nome diz, um diagrama de sequência apresenta uma série de interações que
aparecem ao longo de um caso de uso, de maneira particular ou em alguma
instância de caso de uso.

Com exceção de diagramas de sequência para criar um código ou documenta-
ção de maneira mais detalhada, não é necessária a inclusão de todas as interações
nesses diagramas. Segundo Sommerville (2011, p. 89), caso você desenvolva mo-
delos de sistemas na etapa inicial do desenvolvimento com o objetivo de dar apoio
à engenharia de requisitos e a um projeto de nível elevado, consequentemente
ocorrerão diversas interações submetidas às decisões de implementação.
Modelos estruturais
São modelos que apresentam características estáticas quando demons-
tram estrutura do projeto do sistema, ou dinâmicas quando expõem a or-
ganização do sistema no momento da sua execução. O desenvolvimento de
sistemas estruturais ocorre enquanto sua arquitetura é projetada.
Além da importância do projeto de arquitetura para a engenharia de soft-
ware, a inclusão de componentes e diagramas de implantação da UML apre-
senta os modelos de arquitetura. Nesse contexto, vamos abordar o uso de dia-
gramas de classe, utilizados para criar modelos referentes à estrutura estática
das classes de objeto dentro de um sistema de software. Utilizados na criação
de um modelo cujo sistema é orientado a objetos, o diagrama de classes expõe
as classes pertinentes a um sistema e suas ligações.
DICA
Quando você imaginar associações entre classes, entenda que há um
relacionamento entre elas. É comum que cada classe necessite de infor-
mações ou conhecimentos específicos.
Ao desenvolver um modelo ao lon-

go das fases do processo, é visível que
os objetos simbolizem elementos per-
tencentes ao nosso cotidiano, como um
paciente de hospital. Tais elementos
(objetos) servem como parte dos requi-
sitos necessários para executar proces-
sos iniciais de um projeto de software.

No desenvolvimento de uma aplicação, é comum estabelecer elementos adicio-
nais de implementação que disponibilizem a funcionalidade que o sistema exige.
Há uma variedade de níveis de detalhamento a que os diagramas de clas-
se em UML podem ser expostos. Ao desenvolver um modelo, de imediato é
normal observá-lo de maneira mais globalizada, reconhecer quais objetos são
essenciais e organizá-los como classes ou visualizar a existência de uma asso-
ciação e estabelecer uma relação entre as classes.
Levando-se em consideração o grau de detalhamento, é perceptível que os dia-
gramas de classe apresentam semelhanças com modelos semânticos de dados. Estes
modelos são empregados em banco de dados, em nível de projetos. Eles também
apresentam as entidades dos dados, seus requisitos associados e suas relações.
CURIOSIDADE
Não existe uma inclusão, por parte da UML, de uma notação específica
relacionada a esta modelagem de banco de dados. Existe a suposição
de que há o desenvolvimento direcionado a objetos, portanto, a UML cria
modelos utilizando objetos e a relação entre eles, mas para simbolizar um
modelo semântico de dados.
Outro ponto importante referente aos modelos estruturais é a generalização,

que trata de uma metodologia utilizada no cotidiano para gerenciar a complexidade.
A ideia de buscar características mais detalhadas a respeito de cada entidade é des-
cartada, pois o ideal é direcionar estas entidades para as classes mais generalistas e
aprender suas características. Com isso, é possível verificar se os membros distintos
pertencentes a essas classes possuem similaridades.
Uma boa prática para um projeto é analisar a modelagem de sistemas e verificar
se nas classes existe espaço para a generalização. A vantagem disso é que as infor-
mações similares serão mantidas em um único lugar. Em linguagens orientadas a
objeto – por exemplo, o Java –, a generalização é aplicada através de técnicas herda-
das de classes desenvolvidas dentro da linguagem.
Modelos comportamentais
Modelos comportamentais prezam pelo dinamismo do sistema quando ele
se encontra em execução. Graças a esta modelagem, é possível prever o que

pode ocorrer à medida que o sistema corresponde aos estímulos em seu am-
biente. Quando nos referimos aos estímulos, você pode entender como dados
que normalmente precisam ser processados pelo sistema ou como eventos
que aceleram o processamento do sistema.
Observando em mais detalhes, os sistemas de negócios estão relaciona-
dos ao processamento orientado por dados. Existe um controle na entrada
de dados no sistema com processamento em um nível mais baixo de eventos
externos, envolvendo uma sequência de ações nos dados e a geração de uma
saída (SOMMERVILLE, 2011, p. 93).
Modelos dirigidos a dados são um modelo comportamental que apresenta
uma série de atividades envolvidas no processamento de dados de entrada e
na criação de uma saída associada (SOMMERVILLE, 2011, p. 93). Sua utilidade
pode ser percebida durante a análise de requisitos, pois são empregados du-
rante todas as fases de um sistema.
Vale mencionar que os modelos de fluxo de dados são extremamente impor-
tantes para auxiliar os analistas a entender sua funcionalidade. Isso ocorre porque
tais modelos analisam e documentam como os dados associados a determinado
processo transitam pelo sistema. Com características simplistas e intuitivas, os
diagramas de fluxo de dados geralmente são explicados aos usuários do siste-
ma, os quais tendem a participar de maneira mais efetiva da validação do modelo.
CURIOSIDADE
Não existe apoio por parte da UML aos diagramas de fluxo de dados. Isso
se deve ao fato de que estes foram inicialmente sugeridos e utilizados
para modelar o processamento de dados. A motivação para isso se origina
dos data-flow diagrams (DFDs) que se concentram sobre as funções do
sistema, não reconhecendo os objetos do sistema.
Um segundo tipo de modelo comportamental é a modelagem dirigida a

eventos, a qual expõe como o sistema se comporta em eventos externos e
internos. Ela está referenciada na ideia de que um sistema possui uma quan-
tidade limitada de fases e que os estímulos podem causar mudanças de uma
etapa para outra.
A UML sustenta a modelagem baseada em eventos que envolvem diagra-
mas de estado, e estes apresentam as etapas do sistema e os eventos que

provocam mudanças de estado. Elas não expõem o fluxo de dados no sistema,
mas podem acrescentar informações referentes aos processamentos executa-
dos em cada fase.
Tipos de modelo de software

Neste curso, você visualizou os principais modelos de desenvolvimento
de software. Também foi visto que os modelos podem ser classificados como
prescritivos (que reúnem e organizam o desenvolvimento do software) ou
ágeis (que são mais flexíveis e adaptáveis). A aplicação desses métodos depen-
de do perfil da organização que emprega determinado software. Nas seções
seguintes, voltaremos a tratar dos tipos de software abordando modelos com-
plementares importantes para a organização.
Modelo codificar e consertar

Consiste primeiramente na parceria entre o cliente e os desenvolvedores, que
irão definir qual sistema será desenvolvido e implementar sua primeira versão.
A iteração com o cliente é importante no sentido de sempre corrigir o sistema,
inclusive os erros inevitáveis, ao ponto de atender as demandas dos clientes. Por
fim, entrega-se o produto.
É considerado um modelo bastante simplista, no qual não há uma relação das
ações executadas com os resultados alcançados. Porém, essa simplicidade per-
mite que alguns projetos, mesmo os guiados por outros modelos de ciclo de vida,
utilizem o modelo consertar e codificar.
CURIOSIDADE
Empresas de pequeno porte demandam esta modelagem, porém mais na
forma de pressão aos programadores do que nos processos organizacio-
nais. Se por ventura o sistema não agrada o cliente, cabe ao programador
adequar uma nova funcionalidade em tempo mais curto.
Percebe-se que o modelo apresentado é mais eficiente quando emprega-

do para criar sistemas pequenos em intervalos curtos ou para implementar
sistemas de curta duração. Diante disso, é possível perceber que este méto-

do tem a vantagem, entre outros aspectos, de não utilizar documentação,
ter progresso visível, além de conhecimentos ou treinamentos especiais não
serem necessários.
Um dos problemas dele está relacionado ao código, que geralmente já pas-
sou por correções, o que dificulta sua modificação. Além disso, é muito comple-
xo analisar a qualidade e seus riscos. Outro ponto negativo é o fato de o projeto
não ser ajustado durante sua execução, ou seja, na descoberta de erros, ele
precisa ser reiniciado. Portanto, apesar do fácil manuseio, o modelo consertar
e codificar tende a desenvolver sistemas instáveis e com erros.
Modelo V
Representa uma variação do modelo cascata, sendo possível descrever o elo
entre atividades de garantia de qualidade e ações ligadas à modelagem, comunica-
ção e tarefas iniciais de construção (PRESSMAN; MAXIM, 2016, p. 42).
DIAGRAMA 4. MODELO V
Modelagem Teste de
de requisitos aceitação
Projeto Teste de
da arquitetura sistema
Projetos Teste de
dos componentes integração
Geração Teste de
de código unidade
SOFTWARE
EXECUTÁVEL
Fonte: PRESSMAN; MAXIM, 2016, p. 43.

Visualiza-se que, conforme a equipe responsável pelo desenvolvimento de
software se desloca para baixo, ao lado esquerdo do V, os atributos essenciais
relacionados ao problema são filtrados em representações mais específicas
dos problemas encontrados e da solução apresentada. Por sua vez, a criação
do código provoca um deslocamento para o lado oposto, em que se executa
uma sequência de experimentos que atestam os modelos desenvolvidos à me-
dida que as equipes se deslocam para o lado esquerdo.
CURIOSIDADE
Do ponto de vista prático, não há distinções entre o ciclo de vida
clássico (cascata) e o modelo V. Ocorre que o modelo V disponibiliza
uma maneira de observar a forma como as ações – as quais envolvem
análise e verificação – são implementadas num trabalho de engenharia
realizado anteriormente.
É preciso entender que o modelo cascata é um dos mais antigos na enge-

nharia de software. É comum, devido à sua longevidade, que sua eficácia seja
questionada, até pelos seus defensores mais ferrenhos.
Referindo-se a seus problemas perceptíveis, podemos dizer que:
• Existe uma disparidade entre os projetos reais e o fluxo sequencial suge-
rido. Mesmo sabendo que os modelos lineares apresentam iterações, sabe-se
que isso ocorre de forma indireta. Logo, isso vai resultar em alterações que
causam certa falta de esclarecimento conforme a equipe do projeto avança.
• O cliente, por sua vez, não expõe explicitamente todas as suas demandas.
Como isso é uma exigência do modelo cascata, existe uma falta de adaptação
às incertezas na fase inicial de alguns projetos.
• A paciência do cliente é outro fator. Segundo Pressman e Maxim (2016, p. 42),
não haverá versão operacional à disposição sem antes estar chegando ao fim do
produto. A não verificação de uma falha até a revisão de um programa operacional
pode provocar um desastre.
CURIOSIDADE
A origem linear do modelo cascata conduz ao chamado “estado de blo-
queio”, quando alguns componentes da equipe responsável pelo projeto
precisam esperar outros membros finalizarem as atividades dependentes.

Atualmente, é perceptível que o dinamismo faz parte do trabalho com soft-
ware, o qual está suscetível a constantes mudanças. Já sabemos que o modelo
cascata é pouco adaptável a mudanças, porém pode ser de suma importância em
situações em que os atributos (requisitos) são fixos e o processo é executado até
o fim de maneira linear.
Praxis
É possível defini-lo como um processo destinado a dar suporte em projetos de
engenharia de software. “Praxis” significa “processo para aplicativos extensíveis
interativos” e simboliza o desenvolvimento de aplicativos gráficos interativos, os
quais têm como referência a tecnologia direcionada a objetos; são aplicados em
prazos curtos e são executados por equipes enxutas ou individualmente. Ele é
formado pela combinação entre o desenvolvimento do Prose e os elementos esco-
lhidos do PSP, TSP e do processo unificado. Lembre-se de que Praxis não disputa
espaço com nenhum desses processos, já que o foco de atuação é distinto. Na
verdade, este modelo serve de base para treinar os processos.
DICA
A UML é a notação de modelagem utilizada na Praxis, em todos os passos
em que for aplicável. As práticas gerenciais são inspiradas nas práticas-
-chave dos níveis 2 e 3.
Os estágios que compõem a Praxis são descritos através da sua nomencla-

tura, subdividida da seguinte forma:
• Passo: divisão formalizada de um processo. Abrange pré-requisitos, entra-
das, critérios de aprovação e resultados estabelecidos;
• Fase: setor em que ocorre a maior divisão do processo para fins geren-
ciais, tratando dos pontos principais relacionados à aceitação do cliente;
• Iteração: estágio em que se obtém um conjunto bem definido de objetivos par-
ciais de um projeto;
• Fluxo: etapa que apresenta um tema técnico;
• Etapa: fase que constitui um fluxo;
• Atividade: unidades de trabalho realizadas em um passo.

A nomenclatura descreve as atividades que compõem o Praxis. Ela abrange tan-
to fases quanto fluxos, no estilo do processo unificado, no qual uma fase é consti-
tuída de uma ou mais iterações, assim como um fluxo é dividido em uma ou mais
etapas. Iterações e etapas são exemplos de passos.
Os componentes de maior relevância na arquitetura do Praxis são baseados
nos elementos relacionados ao processo unificado, objetivando compatibilizar a
nomenclatura com um processo desenvolvido na indústria de software. Segundo
Paula Filho (2000), as fases da Praxis se dividem em:
• Concepção: as demandas dos usuários e os conceitos da aplicação são avalia-
dos de modo a justificar a especificação de um produto de software;
• Elaboração: o produto é detalhado a ponto de adaptar o domínio do pro-
blema, autenticar os requisitos e possibilitar um planejamento detalhado da
fase de desenvolvimento;
• Construção: cria-se uma liberação operacional do produto, atendendo
aos atributos especificados;
• Transição: refere-se ao produto quando este é disponibilizado para os
usuários, no intuito de passar pelos testes finais.
Quanto aos fluxos, é possível visualizar algumas subdivisões também. De
imediato, observamos os requisitos, os quais são o fluxo que objetiva disponi-
bilizar um conjunto de atributos de um produto através de um acordo firmado
entre cliente e fornecedor. A análise se refere aos fluxos que detalham e vali-
dam os requisitos, de maneira que possam ser utilizados como referência para
planejar e acompanhar a criação do produto.
O desenho fluxo tem como meta criar uma modelagem estrutural do produto,
desde que seja referência para a implementação, que visa a aplicar o desenho por
meio de elementos de código e de documentação relacionada. Por fim, temos os
testes, que focam a análise dos resultados obtidos na implementação. Isso ocorre
graças ao planejamento, além do desenho e da aplicação de uma série de testes.
O modelo de ciclo de vida de entrega evolutiva é referência para a divisão das eta-
pas do Praxis. Portanto, a nomenclatura escolhida para as iterações simboliza o tema
principal de cada uma. A concepção, por exemplo, apresenta a ativação como sua
única iteração. A elaboração apresenta iterações como levantamento dos requisitos,
que visa a capturar atributos dos usuários do produto, e de análise dos requisitos, que
objetiva, entre outros aspectos, validar os requisitos por meio das técnicas de análise.

A fase da construção apresenta uma das iterações denominada “desenho ini-
cial”, na qual é criado o desenho do produto em grau mais elevado de abstração,
possibilitando a divisão das funções e dos elementos do produto. Por fim, a tran-
sição, que começa pelos “testes beta”, é uma iteração que repete os testes no am-
biente dos usuários. Já na iteração de operação-piloto, o produto é empregado de
forma acompanhada.
O processo unificado aberto (OpenUP)

Podemos considerar que o processo unificado (UP) trata de uma propos-
ta que agrupa um conjunto de abordagens já estabelecidas, com o objetivo
de nortear os desenvolvedores de software. Para que você compreenda com
mais detalhes, é preciso visualizar algumas características importantes. Se-
gundo Hirama (2012, p. 41), o processo UP:
• Ser baseado em fases, que estão relacionados à partem mais dinâmi-
ca e fluxos de trabalho (workflows), que tratam das disciplinas referentes
ao desenvolvimento do software. Portanto, é possível afirmar que o UP
consegue mesclar aspectos estáticos e dinâmicos em um mesmo processo,
o que configura um modelo híbrido;
• É guiado pelo caso de uso, que se trata de uma ferramenta importante na espe-
cificação da função do software, a partir da ótica de um usuário ou sistema distinto;
• Concentra-se na arquitetura, que é o objetivo principal desde o início
do processo, pois ela expõe o ponto de vista dos componentes do sistema
e os elementos mais estruturais;
• É visível que o produto é obtido de maneira iterativa, em que o software é
criado através de versões menores. À medida que vai sendo incrementado com
as novas iterações, o resultado esperado é a construção de um sistema completo.
DICA
As fases do UP podem ser classificadas como: a) concepção, que define o
sistema de arquitetura e subsistemas; b) elaboração, em que os casos de uso
são detalhados, a arquitetura apresenta visões do sistema e a união dos dois
o completa; c) construção, na qual o produto é feito baseado na arquitetura e
direcionado aos que já estão prontos para ser transferidos a outros usuários;
e) transição, que envolve a correção de falhas, treinamento e melhorias.

É possível relacionar os fl uxos de trabalho a requisitos, análise de proje-
to, implementação e testes. Esta fase considera que um conjunto de ações
executadas corresponde a uma iteração, que resulta em um entregável (HI-
RAMA, 2012, p. 42). Vale ressaltar que o UP foi criado baseado num cenário
de abordagem orientada a objeto, sob uma proposta UML.
O Rational Unified Process (RUP), desenvolvido pela IBM/Rational, é um
exemplo de trabalho que se originou do UP e da proposta UML. Um dos benefí-
cios oriundos dessa união é a não vinculação das etapas dos fluxos de trabalho,
podendo ser aplicada em basicamente todas as fases do processo. Além disso,
a percepção de que a implantação do software é uma etapa pertencente ao
processo também pode ser considerada uma vantagem.
Então você pode utilizar esse processo em todos os tipos de desenvolvi-
mento de software? Não, pois o UP/RUP não é recomendável, por exemplo,
para aqueles que envolvem o processamento de um número extenso de dados.
CURIOSIDADE
O UP é bem organizado para auxiliar na interpretação de ações como minipro-
cessos do modelo cascata. Ele é incremental e iterativo, enquanto o resultado
alcançado pelo cascata serve de incremento para iterações posteriores.
Abordaremos com mais detalhes as modalidades de processo unificado nas

seções a seguir.
RUP
Como já visualizamos, o Rational Unified Process (RUP) é um modelo de pro-
cesso moderno, originado de trabalhos da UML. Trata-se de um processo hí-
brido que, segundo Sommerville (2011, p. 34), aborda elementos de todos os
modelos relacionados aos processos genéricos, demonstra práticas relevantes
nas especificações e no projeto, além de apoiar atividades relacionadas à pro-
totipação e à entrega incremental.
Enquanto os modelos de processo convencionais trazem uma forma exclu-
siva de processo, o RUP geralmente descreve algumas perspectivas. A primeira
trata da perspectiva dinâmica, que apresenta as etapas do modelo durante o

tempo de execução. A outra é a perspectiva estática, que expõe as ações feitas
durante o processo. Por fim, a perspectiva prática indica uma série de práticas
que podem ser empregadas durante o processo.
É importante citar que o RUP é formado por etapas que identificam quatro
estágios diferentes no desenvolvimento de software. Porém, diferente do que
ocorre no modelo cascata, as etapas do RUP estão ligadas exclusivamente à
área de negócios, e não a assuntos de caráter técnico. São elas:
• Concepção: estabelece um business case para o sistema. É um processo
que visa a identificar as entidades consideradas externas, que vão estabelecer
uma interação com o sistema e definir quais serão essas interações. É impor-
tante frisar que as informações geradas serão utilizadas para analisar o auxílio
do sistema em relação ao negócio. Caso se perceba que a contribuição foi irri-
sória, pode haver suspensões ou cancelamentos do projeto após esta etapa;
• Elaboração: cria um entendimento do problema dominante, determina
um framework da arquitetura para o sistema, implementa um plano do projeto
e verifica os riscos mais relevantes do projeto. Concluído este estágio, você pre-
cisa apresentar um modelo referente aos requisitos para o sistema, desde que
seja uma frequência de casos de uso da UML, uma descrição da arquitetura ou
até mesmo um plano direcionado ao desenvolvimento do software;
• Construção: relaciona-se ao projeto, à programação e à experimentação
do sistema. É visível, nesta fase, que alguns trechos do sistema serão produ-
zidos de forma paralela e integrada. O término desta fase representa a plena
execução do sistema de software com a documentação disponí-
vel para a entrega aos usuários;
• Transição: simboliza a mudança do sistema do setor
de desenvolvimento para os usuários, lembrando
que seu funcionamento ocorre em um ambiente
real (SOMMERVILLE, 2011, p. 34). Trata-se de
uma atividade custosa e às vezes apresenta
problemas, porém, na maioria dos casos, os
modelos de processo de software ignoram isso.
Ao fim desta fase, é possível ter um sistema de
software documentado e operando corretamente no am-
biente operacional.

DIAGRAMA 5. ETAPAS DO RUP
ITERAÇÃO DE FASE
Concepção Elaboração Construção Transição
Existem duas formas de realizar a iteração dentro do RUP. Primeiramente,

é necessário observar que cada etapa pode ser feita de maneira iterativa,
em que os resultados são alcançados de forma incremental. A outra forma
sugere que as fases agrupadas em conjunto podem ser aplicadas também de
maneira incremental.
Abordando a análise estática do RUP, verifica-se que é necessário focar
ações ao longo do desenvolvimento, denominadas de workflows, na descrição
do RUP. A modelagem de negócios é um exemplo de workflow, a qual afirma que
os negócios são modelados através de casos. Como o projeto do RUP é elabo-
rado em parceria com a UML, conclui-se que a descrição do workflow também
se baseia em modelos ligados à UML.
DICA
Como não existe uma ligação entre os workflows mais específicos
e as etapas do processo de desenvolvimento, sugerir análises está-
ticas e dinâmicas pode ser benéfico. De imediato, os workflows do
RUP atuam em todas as etapas do processo. No início, é demandado
um empenho maior em workflows; nas fases seguintes, nos testes e
na aplicação.
É preciso observar, do ponto de vista prático, que o RUP revela técnicas con-
sideradas importantes para a engenharia de software, de suma importância
para desenvolver sistemas. Segundo Sommerville (2011, p. 35), desenvolver um
software de forma iterativa, gerir requisitos, utilizar arquiteturas com base nos
componentes, estabelecer modelos de software de maneira visual, analisar a
qualidade do software e estabelecer um controle nas mudanças do software
são consideradas boas práticas na criação de sistema.

De fato, é preciso mencionar que o RUP não pode ser considerado um pro-
cesso aplicável a todos os tipos de desenvolvimento, porém ele simboliza um
conceito que une os modelos de processo genéricos que você já observou no
conteúdo aqui exposto. Podemos considerar que os workflows e a separação
das fases são inovações com maior relevância dentro do RUP. Vale citar tam-
bém que a implantação de um software é uma das etapas deste processo.
Conclui-se então que as fases (etapas) têm objetivos e características dinâ-
micas, diferentemente dos workflows, que são estáticos, não estão ligadas a
uma única etapa, porém podem ser empregadas ao longo de todo o desenvol-
vimento para atingir seus objetivos.
AUP
O Agile Unified Process (AUP) é uma abordagem simples, direcionada ao de-
senvolvimento de software, com a referência no RUP. Seu ciclo de vida é, segun-
do Cruz (2018, p. 321), interativo e apresenta uma série de versões.
Este ciclo de vida está referenciado na aplicação de quatro etapas, que serão va-
lidadas por meio de quatro marcos, que são aplicados ao fim das fases citadas. As dis-
ciplinas que estabelecem as ações a serem executadas complementam essas fases.
CURIOSIDADE
Na etapa inicial, ocorre uma iteração, assim como na fase de elaboração.
No estágio de construção, isso vai acontecer diversas vezes, a depender
da necessidade de iteração.
As etapas de AUP são sequenciais durante a implementação do projeto.

A primeira etapa refere-se à iniciação (inception phase), que tem como meta
visualizar o escopo inicial do projeto apresentado e a arquitetura sistêmica dis-
ponível. O objetivo aqui é adquirir algum tipo de financiamento para dar pros-
seguimento ao projeto (CRUZ, 2018, p. 322).
CURIOSIDADE
Podemos considerar que esta etapa é a que melhor se adapta para iniciar
um determinado projeto à medida que o cliente pede um preço ou escopo
fechado. A inception phase possibilita a criação de um pré-projeto, verifi-
cando detalhes que interferem no orçamento estipulado no projeto.

Devemos ressaltar que a inception phase proporciona algumas vantagens, como:
• Interação entre os componentes do projeto;
• Escopo do projeto em grau mais elevado;
• Custos previstos e cronogramas do projeto estabelecidos com assertividade;
• Riscos do projeto definidos antecipadamente;
• Análise do projeto e sua viabilidade;
• Elaboração do ambiente do projeto.
Outra fase é a elaboração, que pode ser denominada como elaboration
phase. Ela é responsável por testar a arquitetura do sistema observada na in-
ception phase. Mas como seriam os testes? Consistem na elaboração de um
protótipo do sistema que garanta à equipe criar um sistema capaz de suprir
as demandas dos requisitos identificados (CRUZ, 2018, p. 323). Neste estágio,
os atributos são detalhados para entender quais os riscos oferecidos pela ar-
quitetura, compreendendo o escopo presente nos requisitos e verificando a
viabilidade técnica do sistema.
DICA
Esta etapa se caracteriza pela construção, entre outros aspectos, de wi-
reframes, o que demonstra a possibilidade de construir um sistema dentro
dos atributos esperados.
A etapa da construção desenvolve o sistema para realizar testes de pré-pro-

dução, também conhecidos como homologação. Nos estágios anteriores, gran-
de parte dos atributos já havia sido identificada, além da arquitetura do sistema,
que foi determinada. A atividade principal aqui é a priorização e o entendimento
dos requisitos, a criação de modelos capazes de solucionar problemas e, poste-
riormente, os testes e a codificação do software.
Por fim, temos a fase de transição, que apresenta o sistema em execução.
É notório o uso de testes extensivos aplicados nesta etapa. Esta fase também
adéqua os produtos, revisa e trata erros relevantes.
Após a visualização e conceituação das fases da AUP, é possível estabelecer a
inserção dos marcos ao fim de cada uma das fases. Cada marco simboliza que os
critérios foram atendidos e que a fase foi encerrada corretamente, verificando se
os critérios foram plenamente atendidos.

Segundo Cruz (2018, p. 325), o AUP é determinado pelos seguintes marcos:
• Marco da fase de iniciação (objetivos do ciclo de vida): analisa o nível em
que se encontra o projeto. Deve haver um consenso entre as partes que com-
põem o projeto em alguns aspectos, como o escopo correto ou a aceitação dos
riscos identificados, por exemplo;
• Marco da fase de elaboração (arquitetura do ciclo de vida): além de veri-
ficar também o estado do projeto, as partes interessadas devem avaliar pontos
como a visão do projeto e se ela oferece uma visão mais realista ou a estabilida-
de da arquitetura do sistema;
• Marco da fase construção (capacidade operacional inicial): pontos como
a aceitação do sistema e documentação de apoio ou a concordância das despe-
sas correntes do projeto são os aspectos em que as partes interessadas preci-
sam apresentar concordância;
• Marco da fase de transição (lançamento do produto): stakeholders do proje-
to precisam concordar em aspectos relacionados à aceitação do sistema e aos pro-
cedimentos e documentações.
Outro aspecto importante relacionado à AUP são suas disciplinas, realizadas
sempre de maneira iterativa com o objetivo de estabelecer quais ações serão to-
madas pelos integrantes da equipe para elaborar um sistema que consiga aten-
der as demandas de um negócio visualizado ao longo das etapas e dos marcos
do AUP. As disciplinas são divididas em:
• Modelo (model): encontra uma solução para questões relacionadas ao pro-
jeto por meio da interpretação correta do negócio da empresa. A modelagem de
requisitos ou da arquitetura são exemplos de atividades que auxiliam na identi-
ficação destas soluções;
• Implementação: segundo Cruz (2018, p. 328), visa a transformar os modelos
em códigos executáveis, realizando experimentos inclusive de unitá-
rios. A prototipagem e a construção de códigos de maneira conti-
nuada são atividades que podem ser realizadas nesta disciplina;
• Teste: identifica falhas no momento da validação
do sistema por meio de uma análise objetiva, para
assegurar a qualidade do produto. O planejamento
inicial dos testes ou a validação da arquitetura são
algumas das atividades executadas na disciplina teste;

• Implantação: projeta a entrega do sistema e a realização do plano para
tornar o sistema acessível aos usuários. A depender do estágio em que o projeto
esteja ao longo do ciclo de vida, as tarefas da disciplina podem variar.
OpenUP
A metodologia Open Unified Process (OpenUP) está ligada ao processo uni-
ficado da área de engenharia de software. Entretanto, apresenta uma maneira
mais flexível de atuar, na qual utiliza uma forma mais ágil e colaborativa de de-
senvolver softwares. Os processos simples são caracterizados na construção
dessa metodologia e podem ser direcionados para outros tipos de software.
CURIOSIDADE
A OpenUP foi criada através da união das metodologias consideradas
ágeis (Scrum e XP) com a arquitetura que forma o processo unificado.
É preciso compreender que o OpenUP tem o núcleo aberto, o que possi-

bilita a ele o desenvolvimento de software de qualquer modalidade. Outro
ponto a ser frisado é o fato de que os processos e as práticas exclusivas po-
dem ser acessadas e aplicadas pelas organizações empresariais. Por meio
desta tecnologia, é determinada uma série de tarefas e funções empregadas
ao longo da execução e do gerenciamento do projeto.
No núcleo da OpenUP, existe uma série de premissas que o tornam uma
metodologia funcional. Seguir essas premissas possibilita a busca de referên-
cias de alto nível e, automaticamente, produtos no mesmo patamar. Podemos
dividir a metodologia OpenUP em quatro grandes princípios:
• Alinhamento de interesses e troca de conhecimentos de maneira colabo-
rativa;
• Maximização dos valores dos stakeholders através do equilíbrio das
prioridades concorrentes;
• Planejamento do processo e a redução dos riscos por meio do foco na
arquitetura;
• Feedback continuo de desenvolvimento através de envolvimento dos sta-
keholders.

Para aprofundar seu conhecimento sobre a metodologia OpenUP, é neces-
sário entender quais as demandas e as metas da equipe para criar um softwa-
re. É importante lembrar que a OpenUP é aberta a possíveis alterações, o que
torna a sua adaptação facilitada para a equipe.
Semelhante ao que ocorre no processo unificado, o OpenUP tem como
referência o ciclo iterativo e incremental, porém o objetivo é criar um mo-
delo que envolva agilidade e simplificação além dos pequenos incrementos
implementados.
Na etapa da concepção (iniciação), deve haver um consenso entre o escopo
e os objetivos do projeto. A elaboração exige a criação de uma arquitetura fun-
cional e concreta, com os riscos minimizados. Na construção, espera-se que o
sistema seja desenvolvido e as entregas incrementais sejam direcionadas aos
stakeholders. Por fim, temos a transição, em que se visualiza falhas no sistema
para que esteja completamente funcional.
Em relação às iterações, o OpenUP consegue manter a equipe comprome-
tida na entrega referente aos valores para os clientes. Com isso, é permitido
verificar erros e corrigi-los, dando sequência ao cronograma (Observe que aqui
o plano de iteração tem tempo e progresso centrados em itens prioritários).
Outros aspectos relevantes são os microincrementos, pequenas unidades de
trabalho pessoais. Essas unidades focam algum item de entrega predetermina-
do no plano de iteração, retornando rapidamente aos envolvidos para que as
decisões sejam tomadas, e os erros, corrigidos.
Dentro de uma equipe, é importante determinar o papel de cada membro
no intuito de auxiliar e estabelecer suas atribuições. A figura do analista é im-
portante, pois ele é o responsável pela ligação entre a equipe interna e os clien-
tes, diferente do que ocorre com o gerente de projeto, que planeja o software,
mantém a equipe focada e acompanha iterações com os clientes.
Ao fim, temos o conceito das disciplinas, que são divisões simbólicas dos
produtos de trabalho que precisam ser completados antes da finalização do
ciclo. São eles:
• Requisitos: reúnem tarefas ligas à análise de negócios;
• Arquitetura: expõe uma arquitetura estável;
• Implementação: organiza as atividades que alteram a arquitetura sugerida;
• Testes: dão os feedbacks sobre a maturidade do sistema;

• Gerência de projeto: oferece métodos auxiliando o trabalho do gerente no
suporte à equipe.
Swebok
O Swebok tem suas origens numa parceria entre o Institute of Electrical and
Electronics Engineers (IEEE) e a Computer Society e a Association for Computing
Machinery (ACM), com o objetivo de profissionalizar a área de engenharia de
software, por meio de um consenso entre as áreas de conhecimento e o seu
escopo. Sua indicação é para os diversos públicos ao redor do mundo, já que
seu objetivo principal é auxiliar as empresas a observar de maneira mais ampla
a engenharia de software como um todo. Este projeto é direcionado para profis-
sionais das mais diversas áreas de atuação (gestores, estudantes, professores e
instrutores de forma geral).
Podemos elencar aqui alguns objetivos ou princípios fundamentais que o
projeto Swebok dissemina. O primeiro é disponibilizar uma ótica consistente
da engenharia de software mundialmente, porém delimitando o campo de
atuação. Além disso, cabe ao Swebok caracterizar o conteúdo, ser um mate-
rial de apoio e promover o acesso ao conhecimento sobre a área de engenha-
ria de software.
CURIOSIDADE
O Swebok foi iniciado em 1998 através do Software Engine-
ering Coordinating Committee (SWECC). Seu financiamento
partiu das organizações como a ACM, a Boeing, entre
várias outras entidades.
Você pode conferir mais informações sobre Swebok no tex-
to Uma introdução ao Swebok, de André Luís Torres (2010).
Categorias do conhecimento da engenharia de software

Três referências de conhecimento são utilizadas para ilustrar o guia Swe-
bok: as geralmente aceitas, que se apresentam como práticas habituais, de-
terminadas e indicadas pela maioria das organizações; a pesquisa avançada,
que aborda práticas utilizadas de maneira mais restrita por algumas empresas

e com conceitos ainda em fase de desenvolvimento e validação nas organiza-
ções que atuam na área de pesquisa; e o especializado, que disponibiliza suas
práticas para algumas modalidades de software. Este guia normalmente divide
a engenharia de software em diversas áreas do conhecimento, que abrangem
desde os requisitos até a mensuração da qualidade do software.
CURIOSIDADE
O IEEE oferece dois tipos de certificação referentes ao Swebok: a Certi-
ficação de Associados para o Desenvolvimento de Software (CSDA) e a
Certificação Profissional para Desenvolvimento de Software (CSDP).
Áreas do conhecimento
Como já foi mencionado, o Swebok está dividido em dez áreas de conheci-
mento, além das disciplinas ligadas à engenharia de software. De início, temos os
requisitos, que demonstram as demandas e limitações do produto de software
que colaboram para resolver problemas. É possível visualizar que alguns erros
nos projetos de software estão relacionados aos requisitos. Isso ocorre graças
à complexidade na compreensão do que o usuário necessita. Com isso, é muito
importante gerenciar os requisitos para assegurar a qualidade de software.
Quando os requisitos são avaliados para criar uma descrição interna referen-
te ao software, para elaborá-lo, podemos dizer que está sendo realizada a execu-
ção do projeto de software. É nesta área que se estabelece, entre outros aspec-
tos, a arquitetura e os componentes de um sistema. Já a construção de software
envolve todas as áreas, porém com foco maior no projeto e testes de software. A
implementação e a verificação, por exemplo, compõem parte desta área.
Quando nos referimos à área de testes, sabemos que se trata do setor res-
ponsável pela verificação da qualidade do produto. É aqui que melhorias po-
dem ser realizadas, corrigindo erros à medida que são encontrados. A manu-
tenção de software, relacionada a todas as áreas do Swebok, dá suporte ao
produto durante o ciclo operacional.
A engenharia de software tem um olhar diferenciado para o setor de geren-
ciamento, já que este tem ligação com a gestão de pessoas. Além disso, existe
uma preocupação em melhorar os planejamentos e gerenciamentos da comu-

nicação entre essas pessoas para alcançar um bom resultado. Por fim, temos a
área de qualidade, que busca melhorar o produto de software estabelecendo
meios de elaborar estes produtos em tempo hábil e com os recursos disponí-
veis. Isso também envolve a qualidade do processo através do qual o software
é desenvolvido.
DICA
Importante citar que Swebok abrange também algumas disciplinas rela-
cionadas às áreas de conhecimento. A engenharia da computação, por
exemplo, incorpora setores como a tecnologia e as ciências de concep-
ção, entre outros. Outra disciplina é a ciência da computação, que se
relaciona a áreas do conhecimento como a linguagem de programação, a
engenharia de software, entre outras.
Aspectos do Swebok
O guia Swebok passa por constantes atualizações. Seu objetivo principal é
incluir novas áreas do conhecimento em detrimento de outras, acrescentan-
do um knowledge area (KA) referente às ferramentas profissionais. Este tema
é amplamente discutido através da CSDP, além da inclusão de KAs referentes
a alguns temas. Remover algumas disciplinas, adicionar material referente às
interfaces humanas e testes de software e redistribuir matérias entre as KAs
são algumas das funções pertinentes ao Swebok.

Sintetizando
Consideramos um modelo apenas como via superficial de um sistema, pois ig-
nora seus detalhes. Modelos de sistema complementares podem ser criados para
apresentar seu contexto, suas interações, sua estrutura e seu comportamento.
Modelos de contexto nos mostram como um sistema é ajustado e posicionado em
determinado ambiente, relacionando-o com outros sistemas e processos.
Os diagramas de caso de uso e diagramas de sequência demonstram as
interações entre o usuário do sistema que será planejado com outros usuários
ou sistemas. Os casos de uso expõem interações relacionando um sistema com
os agentes externos. E aos diagramas de sequência são adicionadas novas in-
formações, apresentando as iterações entre os elementos do sistema.
Quanto aos modelos estruturais, observa-se a organização aliada à arqui-
tetura de um sistema. Nesta modelagem, os diagramas de classe estabelecem
uma estrutura menos flexível de classes com um sistema. Os modelos compor-
tamentais, por sua vez, são empregados no intuito de apresentar a dinâmica no
comportamento do sistema no momento da sua execução. Eles podem ser inse-
ridos em modelos a partir de uma previsão dos dados trabalhados pelo sistema.
Tratando dos diagramas de atividades, é possível afirmar que estas são em-
pregadas para ajustar o processamento de dados, onde cada tarefa realizada
se relaciona a uma fase de processo. Os denominados diagramas de estado
são empregados para ajustar o comportamento de um sistema.
Os modelos de software podem organizar e agrupar ou ser mais flexíveis
e adaptáveis no desenvolvimento do software. Já o UP é uma proposta criada
para formar um conjunto de abordagens já estabelecidas para servir de guia
para os desenvolvedores de software.
O Swebok, dentre as suas características, tem a função de apresentar uma
visão concreta sobre a engenharia de software mundialmente.

CRUZ, F. Scrum e Agile em projetos: guia completo. 2. ed. Rio de Janeiro:
Brasport, 2018.
HIRAMA, K. Engenharia de software: qualidade e produtividade com tecno-
logia. Rio de Janeiro: Elsevier, 2012.
PAULA FILHO, W. P. Engenharia de software: fundamentos, métodos e pa-
drões. 3. ed. São Paulo: GEN, 2008.
PRESSMAN, R. S. Engenharia de software. Trad. José Carlos Barbosa dos
Santos. São Paulo: Pearson Education, 1995.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem
profissional. 8. ed. Nova York: McGraw-Hill Education, 2016.
SOMMERVILLE, I. Engenharia de software. Trad. Ivan Bosnic e Kalinka Gon-
çalves. 9. ed. São Paulo: Pearson Prentice Hall, 2011.
TORRES, A. L. L. Uma introdução ao Swebok. [S.l.]: [s.n.], 2010. Disponível
em: <http://www.cin.ufpe.br/~processos/TAES3/Livro/00-LIVRO/11-Swebok-
-v8_CORRIGIDO_Versao_Final_OK.pdf>. Acesso em: 19 abr. 2019.

QUALIDADE
DE SOFTWARE
(LIVRO 2)
Autoria Estelamaris Pellissari
DADOS DO FORNECEDOR
A violação dos direitos autorais é crime estabelecido pela Lei n.º 9.610/98 e punido pelo artigo 184 do
Código Penal.
SER_COD_QUASOFT_UNID1.indd 2 28/11/2019 11:58:50

Boxes
ASSISTA
CITANDO
CONTEXTUALIZANDO
CURIOSIDADE
tratado.
DICA
EXEMPLIFICANDO
EXPLICANDO

Sumário
Unidade 1 - Introdução à qualidade de software

Introdução aos conceitos de qualidade de software..................................................... 13

A qualidade de software................................................................................................... 13
Conceito de qualidade...................................................................................................... 15
Qualidade do produto e qualidade do processo............................................................. 17

PMBOK................................................................................................................................ 18
RUP....................................................................................................................................... 20
ISO........................................................................................................................................ 23
Garantia de qualidade ......................................................................................................... 27

Garantia de qualidade e suas atividades....................................................................... 28
Controle de qualidade.......................................................................................................... 29
Controle de qualidade e suas atividades....................................................................... 30
Sintetizando............................................................................................................................ 31

Sumário
Unidade 2 – Normas e métricas da qualidade de software

Normas e organismos normativos..................................................................................... 36

Níveis de normatização.................................................................................................... 38
Organização Internacional de Normalização (ISO)........................................................ 39

Certificação e adequação................................................................................................ 44
Elaboração de uma norma............................................................................................... 45
Capability Maturity Model Integration (CMMI)............................................................... 46
Métricas: visão geral............................................................................................................ 47
Métricas aplicadas aos métodos ágeis............................................................................ 49

Métricas em métodos ágeis............................................................................................. 55
Sintetizando............................................................................................................................ 58

Sumário
Unidade 3 - Padrões e teste de qualidade de software

Objetivos da unidade 62
Padrões de projeto 63
Padrões de projeto criacionais 64
Padrão de projeto de classe abstrata 65
Padrões estruturais 66
Padrões comportamentais 66
Teste de software 67
Tipos de testes de software 69
Inspeção e revisão de software 74

Processo de revisão 75
Inspeção 77
Etapas 79
Tipos de defeitos encontrados em cada aspecto 79
Sintetizando 82
Referências bibliográficas 83

Sumário
Unidade 4 - Processos de gerência da qualidade de software

Processos de gerência da qualidade do software......................................................... 87

Modelos de qualidade de software............................................................................... 88
Melhorias de processos ..................................................................................................... 96

Melhoria no processo de desenvolvimento de web app......................................... 101
MPS.BR – Melhoria do Processos de Software Brasileiro........................................ 102

Capacidade do processo.............................................................................................. 105
Casos de sucesso na implantação de melhoria de processo................................ 106
Sintetizando.......................................................................................................................... 108

Apresentação
A preocupação com qualidade de um produto é natural do mundo de hoje e

não seria diferente na área de software.
A baixa qualidade traz impactos negativos para o cliente de software, tais
como a perda de negócios, a perda de dados ou até mesmo a perda de tempo.
Nesse sentido, é possível dizer que existem diversos custos com os quais as
empresas desenvolvedoras de softwares devem arcar devido à má qualidade
de um sistema, como maior necessidade de manutenção, devolução de dinhei-
ro ao cliente, pagamento de multas, disputas judiciais decorrentes de pedidos
de indenização e, o mais grave, má reputação no mercado.
Dessa forma, a má qualidade de um Software pode levar a perdas finan-
ceiras não somente por parte dos compradores, como também entre quem
produz os sistemas.
Por esse motivo, a Engenharia de Software é uma área que tem a obrigação
de se preocupar com a qualidade e desenvolvimento dos softwares, fornecen-
do suporte adequado para garantir a entrega de um produto de qualidade.
Bons estudos!
QUALIDADE DE SOFTWARE 9

A autora
A professora Estelamaris Pellissari

é mestre em Ciências da Computação
pela Pontifícia Universidade Católica
do Rio Grande do Sul (PUCRS) em 2009,
possui especialização em Informática
na Educação pela Universidade Federal
de Lavras (UFLA) em 2005 e graduação
em Informática pela URI - Universidade
Regional Integrada do Alto Uruguai e
das Missões (2001). Atua há mais de 15
anos como professora de ensino téc-
nico, ensino superior e pós-graduação
presencial, além de ter atuado como
orientadora em cursos de graduação
e pós-graduação na modalidade EaD.
Também atuou por mais de oito anos
como administradora de um sistema de
gestão educacional.
Currículo Lattes:
Dedico este conteúdo a minha família, que me dá forças todos os dias para
abraçar novos desafios.

UNIDADE
1 INTRODUÇÃO À
QUALIDADE DE
SOFTWARE

Apresentar ao aluno os conceitos básicos de qualidade de software;
Compreender a importância da gestão da qualidade dentro da Engenharia de
Software;
Abordar os fundamentos de qualidade e metodologias para a gestão da
qualidade do software;
Conhecer os padrões de qualidade para processo e produto de software;
Compreender como garantir e controlar a qualidade de software.
Tópicos de estudo
Introdução aos conceitos de Controle de qualidade
qualidade de software Controle de qualidade e suas
A qualidade de software atividades
Conceito de qualidade
Qualidade do produto e qualida-

de do processo
PMBOK
RUP
ISO
Garantia de qualidade
Garantia de qualidade e suas
atividades

Introdução aos conceitos de qualidade de software
Os primeiros conceitos da qualidade foram iniciados e introduzidos no Ja-
pão. Desde então, esses conceitos de qualidade vêm agregando valor a inúme-
ras empresas em todo o mundo.
A qualidade de um produto, serviço ou processo é muito difícil de ser medida,
pois o que parece ser de boa qualidade para uma pessoa pode não parecer para
outra. Nesse sentido, a qualidade não pode ser caracterizada como algo definitivo
ou ser medida universalmente em parâmetros aceitáveis para todas as pessoas.
Além disso, como qualidade não significa perfeição, é natural que as em-
presas estabeleçam um nível aceitável de qualidade para um produto e, as-
sim, verifiquem se esse nível foi alcançado. Esse nível aceitável de qualidade
precisa ser o mais objetivo possível e deve ser extraído por meio de processos
estruturados, bem como por ferramentas apropriadas que medem a qualidade
definidas por órgãos especialistas no assunto.
A organização que fornece orientação, ferramentas e conceitos de qualida-
de para empresas é chamada de ISO (International Standardization Organiza-
tion ou Organização Internacional de Normalização, em português). Conforme
a ISO, qualidade é a adequação para atender às exigências definidas pela or-
ganização em conformidade com a necessidade do cliente, interessado em um
processo, serviço ou produto.
Diariamente, pessoas consomem diversos produtos, seja uma garrafa de
vinho, um dispositivo eletrônico ou um medicamento. Para a produção desses
itens, existem padrões estabelecidos por meio de metodologias aplicadas, tes-
tes e medições que são realizados por órgãos reguladores ou por especialistas
no assunto.
A qualidade de software
A preocupação com a qualidade de software surgiu na década de 90. A
abertura do mercado mundial trouxe, como consequência, a maior oferta de
produtos ou serviços. Além disso, com o advento da internet, o acesso à in-
formação tornou-se mais facilitado e, com isso, os softwares começaram a se
tornar mais integrados às nossas atividades diárias.

Dessa forma, as empresas perceberam que estavam desperdiçando bilhões
por ano em softwares que não apresentavam as características e funcionali-
dades prometidas ao cliente. Além disso, temiam que uma falha grave nesses
sistemas pudesse inutilizar importantes infraestruturas, acarretando aumento
significativo dos custos.
Em 1991, o sistema telefônico da Califórnia sofreu uma pane devido à mo-
dificação de três entre as milhões de linhas do código. Os custos resultantes
provocados por tal falha despertaram o interesse das empresas de desenvolvi-
mento de sistemas em investir em processos de qualidade.
No Brasil, o sistema do Enem apresentou alguns exemplos de má qualidade.
Em 2013, os usuários tiveram acesso aos dados de outros candidatos. Além
disso, em 2016, o SISU deixou 20 mil estudantes sem nota devido a uma falha
no banco de dados.
CURIOSIDADE
Pessoas que prestaram a prova na época informaram, via redes sociais,
que estavam com acesso a informações de pessoas desconhecidas, como
nomes, telefones e notas do Enem.
Ataques por vírus de computadores em sistemas mostram como a qualida-

de de um sistema pode ser afetada. Em 2017, houve um ataque por vírus, co-
nhecido como WannaCry, que infectou em torno de 300 mil de computadores
em apenas 4 dias. Esse vírus usava uma brecha do Windows que já havia sido
corrigida, mas muitos computadores não tinham realizado essa atualização e,
por esse motivo, foram infectados.
Existem muitos exemplos de impactos ainda mais sérios causados pelas
más práticas de Engenharia de Software. Um caso clássico foi a explosão do
Foguete Ariane 5, em 1996. O motivo da explosão foi a reutilização de um com-
ponente de software antigo que apresentava problemas. Essa falha fez com
que o foguete perdesse o controle e explodisse. De acordo com Koscianski e
Soares, que publicaram o livro Qualidade de software: aprenda as metodologias e
técnicas mais modernas para o desenvolvimento de software em 2007, o impacto
disso foi de 500 milhões de dólares.
Os problemas com a má qualidade são relativos para o uso de sistemas.
Há problemas em que é possível que o cliente consiga conviver sem que seja

afetado. Em outros casos, um problema de má qualidade pode trazer sérios
prejuízos, como ocorre majoritariamente em sistemas bancários.
EXEMPLIFICANDO
Imagine uma pane em um sistema bancário. O prejuízo seria gigante para
as empresas de softwares, para o banco e para os usuários. Os efeitos
poderiam ser catastróficos, bancos poderiam perder milhões de dólares e
clientes veriam seu dinheiro desaparecer. Consequentemente, a empresa
que desenvolveu perderia a credibilidade.
Portanto, a má qualidade em um processo de produção de um software

pode gerar sérios problemas e impactos. Constantemente, esses processos
são excluídos pelos gerentes de projeto devido à falta de equipe especializada,
à carência de ferramentas e até mesmo devido a cobranças pela entrega do
produto.
A demanda por qualidade de software tem motivado as empresas a desen-
volverem sistemas utilizando modelos que prezam pela qualidade. Além disso,
é fato que os consumidores estão à procura de preço e qualidade em qualquer
ramo que as empresas oferecem. Nesse sentido, a qualidade é o grande moti-
vador em todas as áreas de atividade humana.
A Engenharia de Software se dedica a melhorar os processos de desenvol-
vimento. As etapas que envolvem garantia da qualidade, por sua vez, fazem
parte da área de Engenharia de Software. Sendo assim, elas devem ser
colocadas em prática durante o desenvolvimento de sistemas
para as empresas conseguirem garantir a qualidade do produ-
to a ser entregue.
Conceito de qualidade
Qualidade de um software significa desenvolver um sistema sem defeitos?
Uma boa maneira de começarmos a conceituar qualidade de software é afas-
tar a ideia de que qualidade significa perfeição, pois é muito improvável que
um software seja totalmente livre de defeitos.
Qualidade de software é um processo que focaliza todas as etapas do de-
senvolvimento de um sistema e os componentes produzidos com o objetivo de

garantir a conformidade dos processos e dos produtos, prevenindo e eliminan-
do futuros defeitos.
Outro conceito de qualidade de software, definido pela ISO/IEC 9126-1, pu-
blicada em 2003, é a totalidade das características de um produto de software
que lhe confere a capacidade de satisfazer necessidades implícitas e explícitas
dos stakeholders.
Stakeholder é um termo utilizado em diversas áreas, como gestão de pro-
jetos e arquitetura de software, que define as partes interessadas no projeto,
produto ou serviço a ser entregue.
Desse modo, qualidade de software refere-se às características que os de-
senvolvedores especificam para um produto, englobando o grau de atendi-
mento das funcionalidades e características especificadas no modelo de requi-
sitos. A qualidade de um sistema deve atender às necessidades do cliente e aos
padrões de desempenho definidos pelo desenvolvedor, ou seja, deve ser fácil
de usar, e funcionar corretamente na visão do cliente e ser de fácil manuten-
ção, mantendo a integridade dos dados para evitar possíveis falhas, na visão
do desenvolvedor.
Apesar dos modelos aplicados na Engenharia de Software para garantir a
qualidade, o principal objetivo de qualidade de um software é garantir um pro-
duto final que satisfaça às expectativas do cliente dentro daquilo que foi acor-
dado inicialmente e detalhado no levantamento dos requisitos.
Na visão de usuário, entende-se
como qualidade de um produto seu
grau de conformidade com os respecti-
vos requisitos. Além disso, um software
de qualidade deve oferecer segurança
nas transações, disponibilizar servi-
ços essenciais, gerar competitividade
das empresas, etc. A qualidade de um
software deve estar em conformidade
com especificações e padrões de de-
senvolvimento; há necessidades explí-
citas e objetivos propostos por aque-
las pessoas que produzem software,

garantindo que tanto o produto do software quanto um bom processo de de-
senvolvimento atinjam níveis de qualidade mantendo sempre as necessidades
dos usuários.
Sendo assim, não basta dizer simplesmente que a qualidade de software é
importante, é preciso:
• Definir explicitamente o que realmente se quer dizer com qualidade de
software;
• Criar um conjunto de atividades que ajude a garantir que todo artefato
resultante da Engenharia de Software apresente alta qualidade;
• Realizar atividades de garantia e controle da qualidade de software em
todos os projetos de software;
• Usar métricas para desenvolver estratégias e aperfeiçoar a gestão da qua-
lidade.
Qualidade do produto e qualidade do processo

O autor Andrade, em seu livro Qualidade de software, publicado em
2015, afirma que “a qualidade do produto é profundamente afetada pela
qualidade do processo de desenvolvimento, portanto a qualidade deve ser
tratada juntamente ao processo, deve ser uma meta a ser alcançada e
aprimorada ao longo do processo (p. 13).” Tendo isso em mente, é impor-
tante ressaltar que os requisitos de qualidade não devem ser verificados
de forma tardia, após a entrega.
Quando um projeto de desenvolvimento de software é iniciado, o maior
desejo dos envolvidos é ter um produto com qualidade, com um valor justo
e que fique pronto dentro do prazo estabelecido. A utilização de metodo-
logias pode auxiliar o gerente de projetos na condução e monitoramento
das atividades.
Existem algumas metodologias para desenvolvimento de software
que descrevem como fazer o gerenciamento de quali-
dade de um sistema dentro do processo de produ-
ção. A seguir, essas metodologias serão abordadas
com foco na qualidade do produto e na qualidade
do processo.

PMBOK
O Guide to the Project management body of knowledge (PMBOK) é um
guia utilizado no mundo todo. Ele foi o resultado de um movimento liderado
pelo Project Management Institute (PMI), que agrupou os praticantes que fi-
zeram um estudo sobre a área de gestão de projetos, resultando em um guia
para interessados em gerenciamento de projetos. Este documento sistematiza
os conceitos e as ferramentas da gestão de projetos, dividindo-os em dez áreas
do conhecimento, conforme mostra a Figura 1.
Partes
Escopo Tempo
interessadas
Aquisição Custos
Integração
Riscos Qualidade
Recursos
Comunicações
humanos
Figura 1. Dez áreas do conhecimento, conforme PMBOK.
A área da Gestão da Integração envolve a integração de todas as áreas. O

PMBOK considera como áreas para gerar insumos as áreas de Gestão dos Re-
cursos Humanos e Gestão das Aquisições.
Outras áreas são consideradas pelo PMBOK enquanto áreas que devem ser
discutidas para manter o controle sobre o projeto, tais como as áreas de Ges-
tão de Comunicações, Gestão de Partes Interessadas e Gestão de Riscos.

Já as áreas consideradas pelo PMBOK como áreas essenciais e determinan-
tes para atingir os objetivos do projeto são as áreas de Gestão de Escopo, Ges-
tão de Tempo, Gestão de Custos e Gestão de Qualidade. Por esse motivo, na
Figura 2, escopo, tempo e custo estão próximo a uma pirâmide, significando
que se mudanças ocorrerem em qualquer uma das dimensões da pirâmide,
serão refletidas nas demais áreas.
Escopo
po
Cus
Tem
Qualidade to
Figura 2. Tripla restrição do projeto.
Além das áreas do conhecimento, o PMBOK divide o projeto em fases que for-
mam o ciclo de vida do projeto. São as fases pelas quais um projeto passa do
início ao término. O PMBOK considera que um projeto passa pelas seguintes fases:
• Iniciação: processo que autoriza o projeto ou fase. O grupo de iniciação
contempla o termo de abertura do projeto e a identificação das partes
interessadas;
• Planejamento: processo responsável por elaborar e documentar o tra-
balho do projeto. O planejamento incorpora todas as áreas de gerencia-
mento de projetos;
• Execução: processo responsável pela concretização dos planos do proje-
to. Fase que coloca o projeto para andar;
• Controle e monitoramento: processo responsável pela avaliação de de-
sempenho e averiguação do projeto além de controlar e monitorar suas
mudanças;

• Fechamento: processo responsável pelo encerramento formal do pro-
jeto. Nesta fase, são registradas as informações de erros e acertos para
possíveis e novos projetos.
PMBOK e o gerenciamento de qualidade
Para o PMBOK, o gerenciamento de qualidade garante a integridade desejada
e é determinado por meio do de três fases. Os processos envolvidos são:
• Planejamento da qualidade: possibilita uma visão geral do gerenciamento
da qualidade do projeto, sendo possível determinar os padrões de qualidade;
• Garantia da qualidade: aplicação das políticas e procedimentos adotados a
fim de garantir que atenda a todos os requisitos com a qualidade necessária;
• Controle da qualidade: monitoramento dos resultados para verificar se es-
tão dentro dos padrões estabelecidos de qualidade.
A Gestão da Qualidade (Quality Management) fala sobre o planejamento, a
garantia e o controle da qualidade do projeto.
Para o sucesso do projeto, é preciso medir a qualidade dos serviços e
dos produtos que farão parte da implementação. Nesse contexto, o PMBOK
fornece metodologias para o gerenciamento de qualidade de um software,
podendo ser usado como um guia para quem pretende fazer um planeja-
mento desse aspecto.
Para o PMBOK, o custo da qualidade se refere ao custo total de todos os es-
forços relacionados à qualidade. Um exemplo disso são os custos relacionados à
recall que as empresas são obrigadas, por lei, a realizar, com devolução de lotes
de produtos com defeitos e falhas ou troca de peças de um produto. Isso ocorre
muito em concessionárias de veículos automotivos, por exemplo.
RUP
O Rational Unified Process (RUP) é uma ferramenta que automatiza grande
parte do processo de produção de um software. Trata-se de um processo con-
figurável, que se adapta a pequenas equipes de desenvolvimento, bem como a
grandes organizações de desenvolvimento.
O RUP aprimora a produtividade da equipe, fornecendo a todos os membros
fácil acesso à base de conhecimento com diretrizes, modelos e ferramentas para
todas as atividades críticas de desenvolvimento. Dessa forma, todos os mem-

bros da equipe conseguem acessar a mesma base de conhecimento, ou seja, ele
garante que todos os membros da equipe compartilhem os mesmos documen-
tos e consigam ter a mesma visão do software que está sendo desenvolvido.
O RUP foi dividido entre as seguintes disciplinas: modelagem de negócios,
requisitos, análise e projeto, implementação, testes, implantação, gerencia-
mento de configuração e mudanças, gerenciamento do projeto e ambiente.
Suas fases são compostas por concepção, elaboração, construção e transição.
O que chama a atenção da metodologia do RUP é que ela faz com que os ciclos
do projeto sejam iterativos e incrementais, conforme apresentado na Figura 3.
QUADRO 1. DISCIPLINAS E FASES DO RUP
Iterações
Elab. Elab. Const. Const. Const. Trans. Trans.
Disciplinas Inicial
n° 1 n° 2 n° 1 n° 2 n° N n° 1 n° 2
Modelagem de negócio
Requisitos
Análise e projeto
Implementação
Teste
Implantação
Gerência de configuração
e mudanças
Gerência de projeto
Ambiente
Concepção Elaboração Construção Transição
Fases
A documentação de planejamento do RUP não é o levantamento de requisi-

tos no qual são conhecidas as necessidades do projeto, mas sim uma metodo-
logia que visa agregar qualidade ao desenvolvimento do software.
CURIOSIDADE
Você gostaria de navegar no RUP de uma forma interati-
va? Acesse o site e conheça mais sobre essa metodologia
de desenvolvimento e software.

RUP e o gerenciamento de qualidade
O Rational Unified Process propõe
uma abordagem iterativa, permitindo
que os defeitos sejam encontrados o
mais cedo possível e reduzindo radi-
calmente o custo de correção. No RUP,
a qualidade deve respeitar os requisi-
tos com base na confiabilidade, funcio-
nalidade e desempenho do software.
O gerenciamento da qualidade
envolve todos os participantes. Em
outras palavras, a qualidade deve ser
responsabilidade de todos os envol-
vidos no projeto, usando medições e
critérios que não devem ser tratados
de forma tardia em uma atividade se-
parada ou por um grupo separado.
Para gerenciar a qualidade, o RUP define as seguintes atividades em suas
disciplinas:
• Requisitos: é preciso entender com clareza todas as informações adqui-
ridas na coleta, levantamento e especificação, buscando entender todos os
requisitos com clareza;
• Análise e design: inclui a aplicação de avaliações e testes no design do
produto que será entregue, verificando se há alguma inconsistência com os
requisitos;
• Implementação: inclui verificar se os códigos estão seguindo os padrões
determinados para futuras manutenções, bem como se estão de acordo
com os requisitos e o design;
• Teste: é neste ponto que está centralizado o gerenciamento da qualidade,
uma vez que a maior parte do trabalho engloba as três disciplinas anterior-
mente explicadas;
• Ambiente: aqui é possível encontrar diretrizes sobre como configurar me-
lhor o processo para atender às necessidades do ambiente do software que
será instalado;

• Implementação: inclui avaliar os arquivos executáveis, verificar se eles
estão relacionados com requisitos levantados e se estão de acordo com o
design construído;
• Gerenciamento do projeto: fornece base para as revisões e auditorias,
além de fornecer ferramentas para avaliar o processo de desenvolvimento.
RUP X PMBOK
Embora o RUP tenha nomenclaturas diferentes para as fases do PMBOK
e, ainda, apresente uma fase a menos, fica claro que a base metodológica de
ambos é similar. Além disso, o PMBOK é uma metodologia que pode ser usada
para qualquer tipo de projeto em qualquer área. O RUP, por sua vez, é específi-
co para projetos de software.
No PMBOK, as fases do projeto são dependentes umas das outras e, no RUP,
as fases e iterações são dependentes e específicas para o desenvolvimento de
software. Ainda, no PMBOK a qualidade é tratada dentro da área do conheci-
mento de Gestão de Qualidade, e no RUP a qualidade é tratada dentro da disci-
plina gerenciamento de projetos e configuração e mudanças.
Cada organização pode utilizar uma ou mais metodologias no desenvolvi-
mento de software, o que deve ser levado em consideração são as particula-
ridades e as necessidades que cada produto vai apresentar para, em seguida,
definir quais são as metodologias que vão contribuir com o processo.
ISO
Em diversos produtos e serviços que as pessoas compram diariamente, seja
uma roupa de marca, um aparelho celular ou um simples brinquedo eletrônico,
existem padrões estabelecidos por meio de estudos, testes e aferições, realiza-
dos pelos órgãos reguladores. Na área de desenvolvimento de software, a orga-
nização responsável por estabelecer as normas para a qualidade de software é
chamada de ISO (Organização Internacional de Normalização).
As normativas ISO que definem a qualidade de software estão definidas na
ISO/IEC 9126. No Brasil, essas normas estão definidas na NBR ISO/IEC 9126-1.
Por meio da Associação Brasileira de Normas Técnicas (ABNT), são organizadas
comissões de estudo que se baseiam nas normas estabelecidas pela ISO.
A ISO 9126 estabelece um conjunto de normas para:

• Processos: definição das normas e das etapas que compõem o desenvol-
vimento de um software;
• Produtos: atributos que compõem a qualidade do software, dividindo-se
em internos e externos;
• Qualidade em uso: são definidas a aferição da qualidade na visão do
usuário e a facilidade de uso e operação do sistema.
A ISO/IEC 9126 (NBR 13596) define que a qualidade de software deve ser
dividida em seis amplas categorias, apresentadas no Diagrama 1. Este modelo
tem como objetivo servir de base na avaliação de produto de software.
DIAGRAMA 1. CATEGORIAS DE QUALIDADE DE SOFTWARE CONFORME A ISO 9126
Qualidade
Funcionabilidade Confiabilidade Usabilidade Eficiência Manutenibilidade Portabilidade
Adaptabilidade
Adequação
Analisabilidade Capacidade para ser
Acurácia Maturidade Inteligibilidade
Recursos Modificabilidade instalado
Interoperabilidade Tolerância a falhas Atratividade
Tempo Estabilidade Capacidade para
Segurança Recuperabilidade Operacionalidade
Testabilidade substituir
Conformidade
Conformidade
A primeira categoria é a funcionalidade. Nela, estão descritas todas as fun-

ções que satisfazem as necessidades explícitas e implícitas do produto, confor-
me o que foi estabelecido no levantamento de requisitos.
A segunda categoria é a confiabilidade, que tem relação com a capacidade
de tolerância a falhas, ou seja, o sistema tem que garantir que seu desempenho
se mantenha dentro do esperado.
A terceira categoria é a usabilidade. Nessa categoria, a preocupação consiste
em saber se o usuário vai conseguir utilizar o software. Além da capacidade de ope-
ração, o desenvolvimento deve ter um layout atraente e fácil de usar, bem intuitivo.
A quarta categoria é a eficiência. Essa categoria se preocupa em medir o con-
sumo dos recursos no menor tempo de execução conforme a capacidade física.

Desse modo, analisam-se os recursos e
os tempos utilizados conferindo se são
compatíveis com o nível de desempe-
nho requerido para o produto.
A quinta categoria é a manuteni-
bilidade. Nela, analisa-se a facilidade
para fazer correções nas atualizações
e alterações do produto. São definidas
a capacidade de modificação, melho-
rias, correção de falhas, dentre outras
necessidades de alterar o código do
desenvolvimento.
A sexta categoria é a portabilidade. Essa categoria mede como o sistema
pode ser transferido ou adaptado em outros ambientes e infraestruturas. De-
vem-se levar em consideração características como capacidade de hardware,
acesso a recursos de comunicação e idioma. É verificado se é possível utilizar o
produto em diversas plataformas com pequeno esforço de adaptação.
O autor Rezende, que publicou o livro Engenharia de Software e sistemas
de informação em 2005, afirma que os atributos que compõem cada cate-
goria são:
• Funcionalidade
• Adequação: o software se propõe a fazer o que é apropriado?
• Acurácia: descreve a capacidade de precisão nas saídas fornecidas
pelo software, e analisa se ele gera os resultados corretos ou con-
forme acordado.
• Interoperabilidade: descreve a capacidade de coexistência com ou-
tros sistemas dentro de um mesmo domínio, verificando se ele é capaz
de interagir com os sistemas especificados.
• Segurança de acesso: evita acesso não autorizado, acidental ou de-
liberado, a programas de dados. Esse atributo deve garantir o nível de
acesso e permissões dos usuários, bem como garantir que pessoas mal-
-intencionadas não acessem as informações do sistema.
• Conformidade: verifica se está de acordo com normas e convenções
previstas em leis e descrições similares.

Confiabilidade
• Maturidade: demonstra a capacidade de estar e permanecer livre de
falhas.
• Tolerância a falhas: esse atributo descreve a capacidade do sistema
de permanecer em funcionamento mesmo após a ocorrência de uma
falha, independentemente de sua causa.
• Recuperabilidade: mede o tempo de recuperação do sistema após a
ocorrência de falha.
• Usabilidade
• Inteligibilidade: compreende a forma como o usuário entende e iden-
tifica as funções no sistema e se terá facilidade em entender os concei-
tos utilizados.
• Atratividade: demonstra como o leiaute pode tornar o sistema intuiti-
vo para o usuário, auxiliando na compreensão e na operação das funcio-
nalidades, ou seja, ajuda o usuário a aprender a usar o sistema.
• Operacionalidade: descreve a facilidade de operação do usuário, mes-
mo na ocorrência de falhas, e se o usuário consegue sair ou controlar
uma operação caso o sistema venha a falhar.
• Eficiência
• Comportamento em relação aos recursos: são medidos os recursos
consumidos para realizar as tarefas do sistema e a capacidade de não
comprometer o desempenho de outros sistemas rodando em paralelo,
ou seja, quanto recurso utiliza para uma determinada tarefa.
• Comportamento em relação ao tempo: afere o tempo de resposta
das funcionalidades do desenvolvimento, ou seja, qual é o tempo de res-
posta e de processamento.
• Manutenibilidade
• Analisabilidade: descreve a capacidade de identificar as fa-
lhas do sistema.
• Modificabilidade: identifica como o sistema
deve se comportar ao sofrer alterações, ma-
nutenções no código ou mesmo remover de-
feitos, independentemente dos motivos ou
necessidades.

• Estabilidade: identifica os riscos de falhas quando se faz alterações,
manutenções no código ou mesmo remoção de defeitos.
• Testabilidade: descreve a capacidade de testar o sistema após sofrer
uma modificação ou falha.
• Portabilidade
• Adaptabilidade: representa a forma como o sistema vai poder ser utili-
zado em diferentes sistemas operacionais, banco de dados e hardwares.
• Capacidade para ser instalado: descreve a facilidade de instalação
em outros ambientes ou outras plataformas.
• Capacidade para substituir: descreve a facilidade de substituição por
outro software, sofrendo pouco impacto.
• Conformidade: permite identificar como o software convive com outras
aplicações sem que ocorram conflitos ou falha de ambos os sistemas.
A ISO é uma organização independente e não governamental presente em
diversos países. Ela desenvolve padrões internacionais aplicáveis em diversas
áreas da atividade humana.
Garantia de qualidade
Garantia da qualidade é a aplicação das políticas e procedimentos adotados com
objetivo de garantir que o produto atenda a todos os requisitos com a qualidade
necessária.
O IEEE é o instituto responsável por criar padrões de software,
o que inclui o processo de garantia da qualidade. A Software Qua-
lity Assurance (SQA - Garantia de Qualidade de Software) lida com os
processos de desenvolvimento do software, além de verificar se os processos estão
sendo seguidos e feitos de acordo com o que foi especificado.
Por exemplo: para desenvolver um software seguindo a metodologia do PMBOK
e RUP, é necessário entregar diversos documentos, dentre eles: um documento de
especificação de requisitos, o documento de escopo, a estrutura de análise do pro-
jeto (EAP), o cronograma, o plano de custo, etc. Todos esses artefatos criados devem
passar por aprovação de um cliente ou autorização de um gerente. Além disso, é
necessário fazer reuniões semanais com equipe e, a partir dessas reuniões, devem
ser gerados relatórios semanais para que possam ser entregues para alta direção.

Reparem que todas essas atividades são os processos, ou seja, processos de
gestão de desenvolvimento do software, que devem ser seguidos. E, dentro da SQA,
pode existir uma pessoa responsável, um analista de qualidade ou um auditor de
qualidade que vai checar se esses processos estão sendo realizados.
Checar se esses processos estão sendo executados é realizar a garantia da quali-
dade. A garantia da qualidade também verifica a possibilidade dos processos serem
melhorados.
Se uma equipe de software buscar a qualidade em todas as atividades do desen-
volvimento do software, a quantidade de reformulações feitas pode ser reduzida.
Isso resulta em custos menores e, mais importante, na redução do tempo de entre-
ga do produto final.
A partir do momento em que se entende o que é qualidade, a equipe de softwa-
re deve identificar um conjunto de atividades de SQA que filtre erros dos processos
antes de serem passados adiante. Para isso é criado um Plano de Garantia da Qua-
lidade de Software, que define a estratégia de uma equipe.
Garantir que o processo foi realizado ou que se está sendo melhorado é traba-
lhar para melhorar a eficiência dos processos e, assim, reduzir os defeitos.
Garantia de qualidade e suas atividades

Garantir a qualidade de software
envolve algumas atividades, tais como:
Padrões: o IEEE, a ISO e outras
organizações de padronização
produzem diversos padrões para
Engenharia de Software e seus os
respectivos documentos, que po-
dem ser adotados por uma organi-
zação de Engenharia de Software
ou impostos pelo cliente. O papel
da SQA é garantir que padrões ado-
tados sejam seguidos;
Auditoria: tipo de revisão efetua-
do pelo pessoal de SQA com o in-

tuito de assegurar que as diretrizes de qualidade estejam sendo seguidas
no trabalho de produção do software;
Testes: o papel da SQA é garantir que os testes sejam planejados e conduzi-
dos de modo que se tenha a maior probabilidade de alcançar seu objetivo;
Gerenciamento de mudanças: a SQA garante que práticas adequadas de
gerenciamento de mudanças tenham sido realizadas.
Controle de qualidade
Defeitos que não são removidos precocemente acabam sendo detectados
depois. Quanto mais tarde um defeito é corrigido, mais cara é a sua correção.
O pior caso acontece quando o defeito chega ao produto final, caso em que só
será removido por meio de uma operação de manutenção. Esta é a forma mais
cara de remoção de defeitos.
O controle de qualidade busca identificar esses defeitos precocemente por
meio da realização de testes, inspeções e checagem dos artefatos produzidos.
Além disso, o controle de qualidade engloba um conjunto de ações da Enge-
nharia de Software que ajudam a garantir que cada produto resultante de um
processo atinja suas metas de qualidade.
Os artefatos criados são revistos de modo que fiquem completos e consis-
tentes, buscando a correção dos defeitos. Por exemplo: um código deve ser
inspecionado a fim de encontrar e corrigir erros antes dos testes começarem.
Um software tem um conjunto de funcionalidades que devem ser atendi-
das. Dessa forma, um teste em um determinado software para checar se essas
funcionalidades estão de fato atendidas é fazer o controle de qualidade.
Para um melhor controle de qualidade, é importante que existam, dentro
do projeto, pessoas dedicadas às tarefas de controle de qualidade
e gestão de configurações. Outras pessoas têm de
ser ocupadas com atividades de padronização: pa-
drões têm de ser redigidos, revistos, distribuídos
e atualizados. Sendo assim, os desenvolvedo-
res precisam receber treinamento e assistên-
cia quanto ao uso de padrões para garantir a
qualidade do que é produzido.

Na Engenharia de requisitos é necessário definir requisitos não funcionais
do software, como o requisito não funcional de desempenho. Por exemplo:
uma determinada página de um sistema em desenvolvimento deve atender
o requisito não funcional de desempenho, que é carregar a página em três
segundos. Desse modo, checar se ela realmente está carregando em três se-
gundos é realizar controle de qualidade.
Pesquise mais e aprofunde o assunto sobre realizar testes em produtos,
ou sobre empresas que se preocupam em realizar esses testes e fazem compa-
rações de produtos que estão no mercado para ajudar o consumidor na hora
da compra.
ASSISTA
Assista ao vídeo Testamos e comparamos: saiba qual é o
melhor celular top de linha de 2018, no qual é apresentado
ao consumidor como são feitos alguns testes, com com-
parações sobre desempenho, performance, capacidade
de armazenamento.
Controle da qualidade e suas atividades

O controle da qualidade é orientado ao produto e envolve algumas ativida-
des, tais como: realizar revisões técnicas com intuito de revelar erros; realizar
teste de software para verificar se os dados de entrada correspondem aos re-
sultados esperados pelos usuários finais, além de realizar testes de desem-
penho e segurança; fazer inspeções no software para garantir que o produto
de trabalho atenda aos requisitos especificados; utilizar métricas de qualidade
de software apresentadas na Engenharia de Software para medir a qualidade;
realizar testes de qualidade em interfaces para verificar se o software possui
facilidade de uso, se é intuitivo o suficiente e se possui proteção contra erro do
usuário; fazer avaliação com os usuários sobre o produto entregue, buscando
a opinião e realizando as melhorias e coletar opiniões do cliente, promovendo
relatórios de acordo e gerenciamento de mudanças.
Dessa forma, é possível dizer que o controle de qualidade busque avaliar a
entrega e verificar se a entrega está cumprida dentro dos padrões estabeleci-
dos no planejamento da qualidade.

Sintetizando
Nesta unidade, aprendemos o quanto a qualidade é importante quando fa-
lamos de desenvolvimento de um software e como a falta dela afeta tanto os
desenvolvedores de software quanto os próprios clientes. No primeiro tópico,
vimos uma introdução sobre os conceitos de qualidade de software.
No segundo tópico, falamos sobre a qualidade do produto e qualidade do
processo, além de conhecermos uma metodologia para construção de produto
(PMBOK) e uma metodologia específica para software (RUP). Vimos como elas
colaboram para manter a qualidade do que é gerado. Também falamos um
pouco sobre a ISO e suas normas para atender softwares.
Em seguida, falamos sobre garantia e controle de qualidade. Desse modo,
para entender e praticar a qualidade de software, é preciso definir seu signifi-
cado, criar um conjunto de atividades (processos) que ajudem a garantir que
todo artefato resultante da Engenharia de Software apresente alta qualidade
e realizar atividades de garantia e controle da qualidade de software em todos
os projetos de software, usando métricas, padrões e metodologias para desen-
volver estratégias de aperfeiçoamento da gestão da qualidade e, consequente-
mente, da qualidade do produto final.

ANDRADE, M. Qualidade de Software. Rio de Janeiro: Seses, 2015.
ARTERO, M. A. Gestão de projetos de software. Londrina: Editora e Distribui-
dora Educacional S.A., 2016.
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS – ABNT. NBR ISO/IEC 9126-1:
Engenharia de Software - qualidade de produto - parte 1: modelo de qualidade.
Rio de Janeiro: ABNT, 2003. Disponível em: <https://jkolb.com.br/wp-content/
uploads/2014/02/NBR-ISO_IEC-9126-1.pdf>. Acesso em: 01 out. 2019.
BARTIÉ, A. Garantia da qualidade de software. Rio de Janeiro: Elsevier, 2002.
CAMPOS, F. M. Qualidade, Qualidade de Software e Garantia da Qualidade
de Software são as mesmas coisas? Linha de código, [s.l.], [s.d.]. Disponível
em: <http://www.linhadecodigo.com.br/artigo/1712/qualidade-qualidade-de-
-software-e-garantia-da-qualidade-de-software-sao-as-mesmas-coisas.aspx>.
Acesso em: 24 jul. 2019.
FOLHA DE SÃO PAULO. Falha no MEC deixa 20 mil de estudantes sem acesso
às notas. Folha Educação, 19 jan. 2017. Disponível em: <https://www1.folha.
uol.com.br/educacao/2017/01/1851210-falha-do-mec-deixa-20-mil-estudan-
tes-sem-acesso-as-notas-do-enem-2016.shtml>. Acesso em: 24 jul. 2019.
IG SÃO PAULO. Falha em site do Sisu vaza dados de candidatos durante inscri-
ção. Portal IG, 07 jan. 2013. Disponível em: <https://ultimosegundo.ig.com.br/
educacao/2013-01-07/falha-em-site-do-sisu-vaza-dados-de-candidatos.html>.
Acesso em: 24 de jul. 2019.
ISO – INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC DIS.
14598: Information Technology Evaluation of software product. Part 5: Process
for evaluators. Genebra: ISO, 1998.
KOSCIANSKI, A.; SOARES, M. S. Qualidade de software: aprenda as metodolo-
gias e técnicas mais modernas para o desenvolvimento de software. 2. ed. São
Paulo: Novatec, 2007.
KROLL, P.; KRUCHTEN, P. The Rational Unified Process Made Easy: A Practitio-
ner’s Guide to the RUP. Boston: Pearson, 2004.
OLHAR DIGITAL. Entenda o ciberataque que afetou mais de 200 mil PCs em
150 países. Disponível em: <https://olhardigital.com.br/especial/wannacry/>.
Acesso em: 24 jul. 2019.

OLHAR DIGITAL. Testamos e comparamos: saiba qual é o melhor celular top
de linha de 2018. Disponível em: <https://olhardigital.com.br/video/testamos-
-e-comparamos-saiba-qual-e-o-melhor-celular-top-de-linha-de-2018/77661>.
Acesso em: 09 ago. 2019.
PAULA FILHO, W. P. Engenharia de Software: fundamentos, métodos e pa-
drões. 3. ed. Rio de Janeiro: LTC, 2009.
PMBOK. Um guia do conhecimento em gerenciamento de projetos: Guia
PMBOK. 5. ed. EUA: Project Management Institute, 2013.
PRESSMAN, R. S. Engenharia de Software: Uma abordagem Profissional. 7.ed.
Porto Alegre: McGraw-Hill, 2011.
REZENDE, D. A. Engenharia de Software e sistemas de informação. 3 ed. Rio
de Janeiro: Brasport, 2005.
ROCHA, A. R.; MALDONADO, J. C.; WEBER, K. C. Qualidade de software: teoria
e prática. São Paulo: Pearson, 2001.
RUP-VC. Rational Unified Process. Disponível em: <https://www.cin.ufpe.br/~-
gta/rup-vc/index.htm>. Acesso em: 24 jul. 2019.

UNIDADE
2 NORMAS E MÉTRICAS
DA QUALIDADE DE
SOFTWARE

Apresentar ao aluno os conceitos sobre normas e normativos;
Compreender a importância de órgãos de normatização como ISO e ABNT;
Abordar os fundamentos ISO, CMMI, certificações e elaboração de normas e
métodos ágeis;
Conhecer métricas que podem ser aplicadas para software;
Compreender como aplicar métricas em metodologia ágil.
Tópicos de estudo
Normas e organismos Métricas aplicadas aos
normativos métodos ágeis
Níveis de normatização Métricas em métodos ágeis
Organização Internacional de
Normalização (ISO)
Certificação e adequação
Elaboração de uma norma
Capability Maturity Model Inte-

gration (CMMI)
Métricas: visão geral

Normas e organismos normativos
Nesta unidade, você vai aprender sobre normas e organismos normativos,
ou seja, os órgãos que produzem as normas para serem usadas em todo o
mundo. Aqui você terá que compreender o que é ISO, ABNT, CMMI, além de
como utilizar métricas para medir a qualidade de um software utilizando as
metodologias tradicionais. Também veremos conceitos básicos do desenvolvi-
mento ágil de software, como a metodologia Scrum, XP e FDD, e como utilizar
métricas no desenvolvimento ágil.
A Associação Brasileira de Normas Técnicas (ABNT) define normatização
como a atividade regulatória que estabelece o processo de formulação e apli-
cação de regras a fim de solucionar ou prevenir eventuais problemas, sendo
todas as partes cooperando com os resultados.
As normas têm como principal objetivo tornar mais seguro, limpo e eficien-
te o processo de desenvolvimento, fabricação e etc. Elas tornam o comércio en-
tre países mais justo; compartilha avanços tecnológicos; dissemina a inovação
e protege o consumidor. Com isso, as normas asseguram todas as característi-
cas desejadas em produtos e serviços, zelando pela qualidade, confiabilidade,
segurança, intercambialidade, eficiência, respeito ao meio ambiente e baixo
custo econômico, representados no Diagrama 1.
DIAGRAMA 1. OBJETIVOS DA NORMATIZAÇÃO
Segurança
Proteção
Comunicação do
produto
Objetivos Controle
Compatibilidade da normalização da
variedade
Eliminação
Proteção
de barreiras
do meio
técnicas e
Intercambia- ambiente
comerciais
lidade
Fonte: ABNT. Acesso em: 30/09/2019.

Sendo assim, as normas desempenham um importante papel na contribui-
ção para a grande gama de aspectos da sociedade, logo, notamos quando as
mesmas estão ausentes. Entre os incontáveis benefícios que as normas pro-
porcionam, mesmo sem notarmos, podemos citar:
• Padronização de parafusos e roscas, o que facilita reparos e manutenções;
• O estabelecimento de um consenso internacional de terminologias, que
torna o intercâmbio de tecnologias.
ASSISTA
Não deixe de conferir o vídeo Operadoras vão precisar
arrumar bagunça de fios em postes em SP, no qual é
apresentada uma determinação de órgãos regulatórios
das operadoras de telefonia. Com isso, você conhecerá
um excelente exemplo de como as normatizações são
necessárias e úteis para garantir diversos benefícios a
população, como segurança e conservação urbana.
Os grandes beneficiados com a estrutura de normas são:

• Empresas: ao adotar as normas, os fornecedores desenvolvem e ofere-
cem produtos e serviços que contemplam as necessidades de cada setor. E
ao utilizar normas internacionais, as empresas elevam sua capacidade de se
destacar mundialmente no mercado, o que contribui para seu crescimento
de forma geral;
• Inovadores: com as terminologias, compatibilidade e segurança, as inova-
ções aceleram a sua disseminação e implantação, pois seguindo tais itens
é possível reduzir a margem de erro já que desta forma as inovações são
apresentadas logo no início sem oferecer riscos e afins;
• Clientes: se beneficiam da ampla gama de concorrentes quando os pro-
dutos e serviços são baseados em normas, o que garante a qualidade e
durabilidade de determinados produtos, assim como suporte no caso de
possíveis falhas;
• Governos: prover bases científicas e tecnológicas para nutrir segurança,
saúde e legislação ambiental contribui para o bom andamento da indústria
e comércio;
• Países em desenvolvimento: o consenso mediante a eficácia e a neces-
sidade das normas internacionais é uma fonte muito importante de conhe-

cimento tecnológico, que define as características dos produtos e serviços
que serão exportados. Isso exerce influência direta nas tomadas de deci-
sões destes países, para que os mesmos evitem o desperdício dos seus re-
cursos;
• Qualquer pessoa: as normas asseguram que ferramentas, transportes
e máquinas em geral funcionem de maneira adequada, de acordo com o
idealizado pelo fabricante, a fim de garantir qualidade de vida.
• Planeta: as normas sobre a qualidade da água, do ar, dos solos, a emissão
de radiação, gases e outras diversas problemáticas ambientais, contribuem
com as diligências na preservação do meio ambiente.
Níveis de normatização
As normas são delimitadas pelo seu alcance geográfico, político ou econô-
mico. Sendo assim, podemos dividi-las em três níveis principais, que são:
• Nível nacional: atende apenas um país em específi co;
• Nível regional: atende somente uma porção geográfi ca, política ou eco-
nômica;
• Nível internacional: atende vários países do globo.
Diversos países participam da fundação, elaboração, aprovação e divulga-
ção dessas diretrizes.
Uma pirâmide comumente é utilizada para representar os níveis de nor-
matização. Na base dessa pirâmide está a normatização empresarial, no meio
encontramos as normatizações nacionais e no topo está a normatização inter-
nacional (confira a Figura 1).
• Nível internacional: tem abrangência mundial estabelecida pela Orga-
nização Internacional de Normalização (OMC);
• Nível regional/sub-regional: estabelecida por um grupo de países ou
região geográfi ca ou política. São representadas por
organismos regionais, como a Associação Merco-
sul de Normalização (AMN);
• Nível nacional: são normas elaboradas pelas
partes de interesse (governo, empresas, indús-
trias e consumidores) e geridas por um organis-

mo nacional de normalização, por exemplo: no Brasil temos a Associação
Brasileira de Normas Técnicas (ABNT);
• Nível de associação: são normas desenvolvidas por entidades técnicas,
juntamente com seus associados, para facilitar transações entre si. Essas
normatizações chegam a ser utilizadas de maneira ampla, se tornando
referências em algumas modalidades de comércio;
• Nível empresarial: implementadas por um conjunto de empresas com
o intuito de orientar a fabricação, compra e venda de seus produtos.
INTERNACIONAL ISO/IEC/ITU
REGIONAL/SUB-REGIONAL COPANT/AMN/CEN
NACIONAL ABNT/AFNOR/AENOR
ASSOCIAÇÃO ASTM/API
EMPRESARIAL
Figura 1. Pirâmide de níveis de normalização. Fonte: ABNT. Acesso em: 30/09/2019.
Organização Internacional de Normalização (ISO)

A Organização Internacional de Normalização (International Organiza-
tion for Standardization, em inglês), ou ISO, é uma organização indepen-
dente e não governamental fundada em 1947. Essa organização fica esta-
belecida em Genebra, na Suíça, e foi criada com o objetivo de desenvolver
e promover normas internacionais para produtos e serviços que possam
ser usado por todos os países do mundo. Essas normas são baseadas em

práticas e conhecimentos do trabalho voluntário de especialistas em todo
mundo. A ISO é composta por profissionais especializados no assunto
(PRESSMAN, 2011).
Cerca de 111 países integram essa importante organização internacio-
nal, especializada em padronização. No Brasil, é representada pela ABNT
e é através dessa associação que são organizadas comissões de estudo
que se baseiam nas normas estabelecidas pela ISO. As empresas aderem a
essas normas por interesses comerciais e de reconhecimento no mercado
nacional e internacional.
A ISO normatiza literalmente tudo e essas normas tornaram-se a base
para especificar produtos, organizar o fornecimento de serviços e até
mesmo para a elaboração de legislação em vários países.
CURIOSIDADE
Você sabia que o nome ISO vem do grego e foi escolhido não por conta
da tradução do nome – Organização Internacional de Normalização – e
sim para que a pronuncia da sigla seja igual em todos os países que falem
sobre a organização, independentemente de sua língua nativa.
A ISO define as normas por comitê e cada comitê tem uma numeração,
por exemplo:
• ISO 9000 – Gestão da Qualidade;
• ISO 14000 – Gestão Ambiental;
• ISO 2600 – Responsabilidade Social;
• ISO 31000 – Gestão de Riscos;
• ISO 22000 – Gestão de Segurança Alimentar;
A ISO possui uma família de normas que trata da qualidade, a ISO 9000.
A ISO 9000 foi desenvolvida para ajudar organizações na implementação
e operação de sistemas eficazes de qualidade. Ela auxilia a empresa na
seleção da norma mais apropriada para o seu negócio, assim como a sua
utilização.
A série é composta das seguintes normas (Quadro 1): ISO 9000 - Fundamen-
tos e vocabulário; ISO 9001- Sistemas de gerenciamento da qualidade e requi-
sitos; ISO 9004 - Sistemas de gerenciamento da qualidade e guia para melhoria
da performance; ISO 19011 - Auditorias internas da qualidade.

QUADRO 1. NORMAS ISO
Área industrial Normas Significado das normas
ISO 9000
Conjunto de normas publicadas
ISO 9001 pela ISO que especifica os itens
Qualidade necessários para a implantação
ISO 9004 de um Sistema de Gestão de
Qualidade.
ISO 19011
Fonte: ISO, 2014. (Adaptado).
ISO 9000-3
Para facilitar a aplicação em desenvolvimento de software, a ISO 9000-3
– que inclui orientações para a aplicação da ISO 9001 ao projeto, desenvol-
vimento, fornecimento, instalação e manutenção de software – define dire-
trizes para facilitar a aplicação da norma ISO 9001. Ela destina-se a fornecer
orientação quando um contrato entre duas partes exigir a demonstração da
capacidade do fornecedor em desenvolver, fornecer e manter produtos de
software (WAZLAWICK, 2013).
As diretrizes propostas na ISO 9000-3 cobrem questões como:
• Entendimento dos requisitos funcionais entre contratante e contratado;
• Uso de metodologias consistentes para o desenvolvimento de software;
• Gerenciamento de projeto desde a concepção até a manutenção.
DICA
Se você quiser saber mais sobre guia de qualidade apli-
cável software, não deixe de acessar a página oficial da
ISO, em especial, a seção sobre as normas 9000-3.
Uma organização que possui um sistema de gestão da qualidade, que está de

acordo com a norma ISO 9001, pode solicitar a certificação e obter o selo 9001
– no Brasil, é a ABNT NBR ISO 9001 -. Conquistar a certificação representa um
atestado de reconhecimento nacional e internacional da qualidade do trabalho.
A ISO 9001 passou por várias versões com o passar dos anos. Em 1987 em sua
primeira versão, ela orientava para procedimentos, direcionada para inspeção e
testes. Na sua segunda versão, em 1994, foi implantada a ação preventiva, mas
com foco em procedimento e baixo foco em gestão para resultados. No ano de

2000, surgiu a terceira versão que dava ênfase em processos, PDCA e melhoria
contínua. Em 2008, em sua quarta versão, tratava de norma mais genérica para
produtos e serviços retirando um pouco da burocracia.
ISO/IEC 9126
A ISO/IEC 9126 (NBR 13596) define que a qualidade de software deve ser divi-
dida em seis amplas categorias que têm como objetivo servir de base na avalia-
ção de produto de software, conforme apresentado por Rezende (2005).
A primeira categoria é a funcionalidade: nela estão descritas todas as fun-
ções que satisfazem as necessidades explícitas e implícitas para a finalidade a
que se destina o produto, de acordo com o levantamento de requisitos, com os
seguintes atributos:
• Adequação: observa se as funcionalidades do software estão adequadas às
necessidades do usuário;
• Acurácia: descreve a capacidade de precisão nas saídas fornecidas pelo
software, se ele gera os resultados corretos;
• Interoperabilidade: descreve a capacidade de interação com outros siste-
mas especificados;
• Segurança de acesso: esse atributo deve garantir o nível de acesso e per-
missões dos usuários e garantir que pessoas mal-intencionadas não acessem
as informações do sistema;
• Conformidade: verifica se está de acordo com normas e convenções previs-
tas em leis e descrições similares.
A segunda categoria é a confiabilidade, que tem que garantir que o desem-
penho do sistema se manterá dentro do esperado, com os seguintes atributos:
• Maturidade: demonstra a capacidade de estar e permanecer livre de fa-
lhas;
• Tolerância a falhas: esse atributo descreve a capacidade do sistema, mes-
mo após a ocorrência de uma falha, permanecer em funcionamento, inde-
pendentemente da sua causa;
• Recuperabilidade: mede o tempo de recuperação
do sistema após a ocorrência de falha.
A terceira categoria é a usabilidade. Esta catego-
ria se preocupa em como o usuário conseguirá uti-
lizar o software. Além da capacidade de operação, o

desenvolvimento deve ter um layout
atraente e fácil de usar, bem intuitivo.
Com os seguintes atributos:
• Inteligibilidade: compreende se o
sistema será fácil entender os con-
ceitos utilizados;
• Atratividade: demonstra como
o layout pode tornar o sistema
intuitivo para o usuário, se facili-
ta o usuário a aprender a usar o
sistema;
• Operacionalidade: descreve a
facilidade de operação do usuário,
se o usuário consegue sair ou con-
trolar uma operação caso o sistema
venha a falhar.
A quarta categoria é a eficiência. Essa categoria se preocupa em medir o
consumo dos recursos no menor tempo de execução conforme a capacida-
de física e analisa se os recursos e se os tempos utilizados são compatíveis
com o nível de desempenho requerido para o produto. Com os seguintes
atributos:
• Recursos: são medidos os recursos consumidos para realizar as tarefas
do sistema;
• Tempo: afere o tempo de resposta e de processamento.
A quinta categoria é a manutenibilidade, na qual a análise foca em sa-
ber se há facilidade para se fazer correções nas atualizações e alterações do
produto. Com os seguintes atributos:
• Analisibilidade: descreve a capacidade de identificar as falhas do sistema;
• Modificabilidade: identifica como o sistema deve se comportar ao sofrer
alterações, manutenções no código;
• Estabilidade: identifica os riscos de falhas quando se faz alterações e ma-
nutenções no código;
• Testabilidade: descreve a capacidade de testar o sistema, após este sofrer
uma modificação ou falha.

E a sexta categoria é a portabilidade. Essa categoria mede como o sistema
pode ser transferido e adaptado em outros ambientes e infraestruturas. É ve-
rificado se é possível utilizar o produto em diversas plataformas com pequeno
esforço de adaptação. Com os seguintes atributos:
• Adaptabilidade: representa a forma em que o sistema vai poder ser utiliza-
do em diferentes sistemas operacionais, banco de dados e hardware;
• Capacidade para ser instalado: descreve a facilidade de instalação em ou-
tros ambientes ou outras plataformas;
• Capacidade para substituir: descreve a facilidade de substituição por ou-
tro software, sofrendo pouco impacto;
• Conformidade: permite identificar como o software convive com outras
aplicações, sem que ocorra conflitos ou falha de ambos os sistemas.
Certificação e adequação
Em diversos produtos e serviços, existem padrões
estabelecidos por meio de estudos, testes e aferições,
realizados pelos órgãos reguladores, como a ISO (PRES-
SMAN, 2011).
As normativas da qualidade de software estão definidas
na ISO/IEC 9126. No Brasil, essas normas estão definidas na NBR
ISO/IEC 9126-1. Por meio da ABNT, são organizadas comissões de
estudo que se baseiam nas normas estabelecidas pela ISO.
A ISO 9126 estabelece um conjunto de normas para:
• Processos: nos quais estão definidas as normas das etapas que compõem
o desenvolvimento de um software;
• Produtos: estão definidos os atributos que compõem a qualidade do soft-
ware, podendo ser dividido em: internos e externos, em que está descrito
as formas de aferição dos atributos;
• Qualidade em uso: são definidas a aferição da qualidade na visão do
usuário e a facilidade de uso e operação do sistema (ARTERO, 2016).
A empresa que decide seguir as normas tem que definir as metas a serem
alcançadas e apresentar um projeto com a implantação de atividades de ges-
tão da qualidade para conseguir a certificação.

Elaboração de uma norma
Uma nova norma é elaborada a partir de uma demanda, para isso é
criado um documento técnico que pode ser apresentado por qualquer
pessoa, empresa ou entidade que tenha o intuito de normalizar algo. Este
documento é analisado para verificar se tal sugestão é viável e, então, o
documento é enviado para um comitê técnico, no caso de não existir uma
proposta para a criação de um. Sendo o assunto discutido de maneira am-
pla e com participação livre da sociedade, ele é possivelmente viabilizado.
Em vias de ser submetida à consulta pública, a norma elaborada é edi-
torada e recebe a sigla ABNT NBR e seu número para em seguida ser dispo-
nibilizada para consulta pública no site da ABNT, em que qualquer pessoa
pode enviar comentários ou sugestões. Após esse período, a norma é ho-
mologada e publicada pela ABNT.
Todo esse processo de elaboração de uma norma é representado no
Diagrama 2.
DIAGRAMA 2. PROCESSO DE ELABORAÇÃO DE NORMAS
NORMA
Programa de Não Sim
Elaboração
Normalização
do Projeto OK
Setorial
de Norma
(PNS)
Análise do
Consulta
Demanda Resultado da
Nacional
Consulta Nacional
Fonte: ABNT. Acesso em: 30/09/2019. (Adaptado).

A participação na elaboração de normas é aberta para todas as pessoas
interessadas e pode ser feita de diversas maneiras, tais como:
• Solicitando a elaboração de um documento técnico ABNT;
• Participando da elaboração de uma Norma Brasileira;
• Fazendo recomendação aos projetos de norma;
• Revisitando o conteúdo das normas brasileiras.
Capability Maturity Model Integration (CMMI)

Capability Maturity Model Integra-
tion (CMMI) ou Ciclo de Vida do Desen-
volvimento de Software, o CMMI é um
modelo de boas práticas de qualidade
e maturidade no processo de desen-
volvimento de um software. Foi criado
pelo Software Engineering Institute
(SEI) e fomentado pelo departamento
de defesa dos Estados Unidos.
O modelo CMMI tem como objetivo
ofertar às organizações um conjunto
de práticas para desenvolvimento e
manutenção de serviços e produtos tecnológicos, podendo ser utilizado como
um apoio nas ações de aperfeiçoamento da melhoria contínua em processos.
O CMMI considera que existem níveis de maturidade para serem alcançados
no processo de melhoria contínua, que são separados em cinco etapas (WA-
ZLAWICK, 2013).
Para que uma empresa consiga atingir os padrões de qualidades exigidos,
ela pode proceder por duas vias, sendo elas: a representação contínua que ve-
rifica os interesses da mesma em determinados processos ou a representação
por estágios que se organiza em etapas do nível 1 ao nível 5 (Figura 2).
Detalhe das principais características de cada nível:
• Nível 1 - Inicial: organização imatura, processos improvisados, pouco
compromisso com prazos ou custos, chances de desenvolvimento estão à
mercê das habilidades pessoais dos gerentes;

• Nível 2 - Gerenciado: políticas e procedimentos de gerenciamento e de-
senvolvimento de software estão definidas e são exercidas;
• Nível 3 - Definido: processos estabelecidos e padronizados, processos
pertencentes à organização e não a uma pessoa;
• Nível 4 - Quantitativamente gerenciado: existem metas quantitativas
para processos, medidas de qualidade e controle estatístico;
• Nível 5 - Otimização: engajamento na melhoria contínua de processos e
ações preventivas de problemas (BARTIÉ, 2002).
Foco contínuo na melhoria

5 OTIMIZAÇÃO
dos processos
Processos são medidos QUANTITATIVAMENTE

4
e controlados GERENCIADO
Processos são caracterizados para

3 DEFINIDO
organização e são proativos
Processos são caracterizados por projeto GERENCIADO

2
e as ações são frequentemente reativas
Processos são imprevisíveis, pouco INICIAL

1
controlados e reativos
Figura 2. Níveis de maturidade CMMI. Fonte: ISD Brasil. Acesso em: 15/08/2019. (Adaptado).
Métricas: visão geral

Os gestores de projetos de software acreditam que a utilização de métricas
tem sido uma ferramenta essencial na produção de um sistema. Ela se torna
importante, pois se consegue medir as características com objetivo de desco-
brir se os requisitos foram atendidos e se há um grau de qualidade satisfatório,
além disso, também serve para verificar o desempenho de desenvolvimento,
esforço, custo e tamanho, comparando dados planejados com dados reais.

Como a produção de um software gera diversos artefatos, é possível utilizar
os materiais gerados para fazer essas medições, a fim de checar a qualidade.
Pressman (2011) destaca alguns princípios necessários para fazer medições
em software:
• Todos os envolvidos no projeto devem reunir dados para estimativa de
desempenho;
• É necessário coletar dados de performance referentes à melhoria do software;
• É preciso considerar os projetos antigos como base para evitar os mesmos
problemas e erros nos projetos futuros.
Dessa forma, o autor também destaca as vantagens das aplicações de
métricas:
• Ajuda na verificação da qualidade do produto;
• É possível verificar o desempenho da equipe do projeto;
• Com base nos resultados das métricas, é possível fazer estimativas de
tempo, custo e escopo;
• Reforça a justificativa de aquisição de novos recursos a serem contratados
e implantados no projeto.
A seguir, destacaremos alguns tipos de métricas que podem ser utilizadas e
a finalidade de cada uma dentro da produção do produto.
Métrica de requisitos: verifica se o software atendeu aos requisitos so-
licitados pelo cliente. Nesta medição, leva-se em consideração os requisitos
levantados inicialmente e o que é apresentado na interface do sistema. Para
medir, é feita uma contagem e são comparados o resultado do que usuário
solicitou com o que foi atendido.
Métrica de projeto UML: essa métrica verifica o número de diagramas ge-
rados, tanto comportamentais quanto estruturais (UML), que delineiam o soft-
ware. Baseado no histórico de outros projetos, é possível calcular o escopo, o
tempo e ainda garantir a qualidade para este novo projeto.
Métrica de banco de dados: essa métrica tem como objetivo
avaliar o banco de dados físico e lógico. Com base no
número de tabelas criadas, número de registros
e número de colunas criadas, é possível medir a
quantidade de bytes necessários para armaze-
namento dos registros. Essa métrica ajuda a saber

qual período é necessário para a realização de um backup e o tamanho desse
backup num determinado tempo de uso do sistema.
Métrica de codificação: tem o objetivo de avaliar fisicamente o tamanho
do código-fonte do software. Mede o tamanho através da quantidade de linhas
do código-fonte, ou faz uma análise sobre a quantidade de comandos utiliza-
dos em cada linha.
Métrica de performance: avalia a performance do software quando está
em execução. Nesta métrica, deve ser possível medir em milissegundos o tem-
po que leva para executar ou abrir uma determinada funcionalidade do siste-
ma. Para isso, é interessante realizar testes de performances com ferramentas
automatizadas.
Métrica de implantação: mede o esforço médio de cada tarefa de implan-
tação, como por exemplo: configuração do sistema, instalação do servidor, do
banco de dados e de bibliotecas.
Medir permite conhecer e descobrir mais informações sobre seu projeto de
software. No mercado existem diversas ferramentas livres que colaboram
com essas métricas.
DICA
Uma dica é pesquisar mais sobre a ferramentas JMeter da Apache Foun-
dation e sobre a ferramenta SQL Injection e OpenVas, que são softwares
que auxiliam nas medições e que permitem a realização de diversos testes
automatizados, facilitando o resultado das métricas utilizadas no projeto.
Métricas aplicadas aos métodos ágeis

O foco das metodologias ágeis é dar mais destaque aos fatores humanos do
desenvolvimento do que nas definições dos processos de desenvolvimento. E
é por isso que a metodologia ágil está sendo considerada a mais adequada ao
trabalho de desenvolvimento de software (WAZLAWICK, 2013).
Dessa forma, os métodos ágeis apreciam os indivíduos e a interação entre
eles mais do que os processos e ferramentas, – que são o foco da metodologia
do PMBOK e RUP – dando mais ênfase ao software em funcionamento do que
à documentação gerada após a entrega. Na metodologia ágil, a colaboração
com o cliente dentro do projeto é mais importante do que a preocupação com

os documentos de contratos. O foco está em responder a mudanças e não em
seguir um planejamento com cronograma e escopo (BECK, 2001).
A metodologia ágil não se preocupa em seguir um planejamento respeitan-
do as fases, atividades que devem ser executadas para se chegar a um produto,
mas segue uma filosofia diferente dos modelos prescritivos, os modelos ágeis
focam valores humanos e sociais da equipe (WAZLAVICK, 2013).
As metodologias ágeis comparam a produção de um software com os pro-
cedimentos de concepção de uma obra de arte. Quando um pintor cria um
novo quadro, é comum começar com alguns desenhos e evoluir, fazendo acer-
tos e retoques até que a obra esteja concluída (TELLES, 2004).
Existem vários tipos de metodologias ágeis, as principais são:
• Scrum;
• Extreme Programming, mais conhecido como XP;
• Feature-Driven Development (FDD).
DIAGRAMA 3. TIPOS DE METODOLOGIAS ÁGEIS
• Um processo interativo e incremental;

SCRUM • Feitas verificações diárias durante a interação;
• Cada interação é um incremento do produto.
• Requisitos alteram constantemente;

XP • Para equipes pequenas;
• Desenvolvimento OO.
• Dividido em duas fases: concepção/planejamento e construção

FDD • Concepção e planejamento: o modelo sugere que se conceba e
planeje o produto em uma ou duas semanas antes de começar
a construir;
• Construção: desenvolvimento por interações em ciclos de uma
a duas semanas.

Vamos falar brevemente sobre cada metodologia.
Extreme Programming (XP)
O Extreme Programming é uma metodologia adequada para projetos que
possuem requisitos que se alteram constantemente, para pequenas equipes
de desenvolvimento de software e para o desenvolvimento de programas
orientados a objetos.
Desta forma, também é indicado para entregas que devem ser feitas com
prazo curto, ou seja, em que as partes executáveis do software sejam entre-
gues logo no início do desenvolvimento e a medida que vai ganhando novas
funcionalidades, novas versões são entregues e o software vai se tornando
maior, assim o projeto vai avançando até a entrega total.
Conforme Telles (2004), o XP (Extreme Programming) tem o seguinte formato:
• Gerente do projeto: responsável pelo relacionamento com o cliente, além
de sua responsabilidade atuar em todos os assuntos administrativos;
• Coach: é o responsável técnico pelo projeto, é de sua competência assegu-
rar o bom andamento do projeto, ele deve ter experiência no assunto e ser
tecnicamente bem preparado;
• Analista de teste: é responsável por trabalhar juntamente com o cliente
na realização de testes de aceitação e verificação de problemas. Ele leva
esses resultados para a equipe desenvolvedora fazer as alterações neces-
sárias, ou seja, as correções no sistema, fornecendo o feedback do que foi
testado;
• Desenvolvedor: é responsável por realizar a análise, o projeto e a codifica-
ção do sistema. Diferente das outras metodologias que dividem essa tarefa
em três especialidades, no XP ela é centralizada em uma só pessoa;
• Redator técnico: é responsável por documentar o sistema
com a ajuda da equipe de desenvolvimento. O objetivo é re-
tirar essa tarefa do desenvolvedor pra que ele foque somen-
te na construção e entrega do programa.
O XP focaliza seus objetivos em quatro pilares:
• Feedback: envolve o cliente na produção do
sistema com objetivo de obter rapidamente o
feedback, com isso, o cliente consegue apren-
der com o sistema que está utilizando e avalia

suas necessidades e assim conse-
gue gerar resultados para a equipe
de desenvolvimento;
• Comunicação: como o cliente
está bem envolvido, permite que a
equipe trate com atenção as neces-
sidades do cliente;
• Simplicidade: como o foco são
as necessidades do cliente, colocar
essas necessidades em prática é
suficiente;
• Coragem: é um pilar com foco nas
alterações conforme as necessidades
do cliente, ou seja, melhorar o que já
está funcionando é fundamental.
Scrum
Schwaber (2004) define a metodologia Scrum como um processo interativo
e incremental. Durante o desenvolvimento das atividades ocorrem interações,
uma após a outra, e a saída de cada interação é um incremento do produto.
Para isso, são feitas verificações diárias durante a interação, em que cada pes-
soa envolvida na equipe do projeto verifica o que foi desenvolvido pela outra,
fazendo as adequações necessárias.
Desta forma, são feitas reuniões periódicas com os membros da equipe
para criação de funcionalidades específicas. Seus aprendizados possuem afini-
dade com a metodologia XP, mas com graus de importância diferenciada.
O Scrum é um modelo ágil para a gestão de projetos de software que come-
ça com uma abordagem mais simples do produto que será produzido, do que
é esperado para entrega, e, para isso, tem como foco os principais elementos:
• Product Backlog: aborda uma lista com as necessidades desejadas para
o produto. Essa lista não precisa ser completa logo na primeira vez em que
é feita, o ideal é que ela seja revista assim que o projeto avança, incluindo e
tratando as novas necessidades que forem sendo descobertas;
• Sprint: é o tempo em que a equipe se compromete a entregar as funciona-
lidades definidas e colocadas no Sprint Backlog. O Scrum divide o processo

de construção do software em partes que va-
riam de duas a quatro semanas, que é chama-
do de Sprint. Se dentro do projeto uma nova
necessidade for encontrada, ela deverá ser
tratada na próxima Sprint;
• Sprint Backlog: aborda uma lista com as ta-
refas que o grupo envolvido no projeto deverá cumprir
naquele Sprint. Tais tarefas são selecionadas do Product
Backlog, com base nas prioridades definidas pelo Product
Owner. Cabe ao Product Owner manter o Sprint Backlog
atualizado, sinalizando as atividades já finalizadas e as que ainda preci-
sam ser finalizadas (WAZLAVICK, 2013).
O Scrum considera como membros da equipe:
• Scrum Master: é a pessoa com ampla formação técnica do modelo e
que se responsabiliza pela sua sustentação do projeto num todo. Trata-
-se de um facilitador do projeto que irá dosar a capacidade de sua equi-
pe e ainda deverá decidir se a equipe pode e consegue assumir novas
atividades;
• Product Owner: tem a missão de indicar as funcionalidades que irão
compor o Product Backlog e priorizar as funcionalidades mais importan-
tes a serem tratadas nas Sprints. É a pessoa responsável pelo projeto;
• Scrum Team: grupo de pessoas responsáveis pelo desenvolvimento do
software, no geral são este grupo tem entre seis e dez pessoas.
Feature-Driven Development (FDD)
O Desenvolvimento Dirigido por Funcionalidade é uma metodologia ágil
que enfatiza o uso de orientação a objetos. Ele foi criado para atender pro-
jetos e equipes de software de tamanhos médio e grande.
Como toda metodologia ágil, a funcionalidade é direcionada pelo cliente
e pode ser produzida em menos de uma semana. Dessa forma, toda funcio-
nalidade é finalizada e apresentada periodicamente para o cliente em forma
de projetos e codificações, ficando mais simples e fáceis de monitorar. Ten-
do todas as funcionalidades listadas, é possível priorizá-las de acordo com a
importância e dimensão do negócio. Assim, todo o escopo e cronograma do
projeto serão conduzidos por essa prioridade (MARQUES, 2012).

O Feature-Driven Development (FDD) é dividido em duas fases:
• Concepção e planejamento;
• Construção.
A concepção e planejamento do Feature-Driven Development aconselha
que se arquitete e planeje o software em até duas semanas antes de iniciar o
desenvolvimento. A concepção e planejamento inclui três subfases:
• DMA (Desenvolver Modelo Abrangente): Esse é o primeiro passo de
modelagem do sistema que será desenvolvido, etapa na qual especialistas
estabelecidos em grupos desenvolvem um modelo de negócio amplo, re-
presentado por diagramas que contenham as classes principais, diagramas
de sequência e decisões tomadas nesta fase;
• CLF (Construir Lista de Funcionalidades): Nesta fase, deve-se criar uma
lista de funcionalidades que satisfaçam os requisitos levantados. É uma
atividade inicial que abrange todo o projeto e deve ter a participação do
gerente de projetos, do gerente de desenvolvimento e do arquiteto-chefe.
• PPF (Planejar por Funcionalidade): nesta etapa é definida a ordem em
que as funcionalidades serão entregues e quanto tempo será reservado
para o desenvolvimento de cada versão (WAZLAVICK, 2013).
Construção: nesta fase o Feature-Driven Development (FDD) passa pelo
desenvolvimento que é realizado por revisões do software em períodos de
uma a duas semanas. A fase de construção inclui duas subfases:
• DPF (Detalhar por funcionalidade): esta fase é o período em que a pro-
gramação visual do software é criada por meio dos diagramas comporta-
mentais da UML (sequência ou comunicação).
• CPF (Construir por funcionalidade): é nesta fase em que se constrói o
código propriamente dito, com requisitos definidos (WAZLAVICK, 2013).
A equipe do FDD tem membros com os seguintes perfis:
• Gerente de projeto: é o administrativo e financeiro do projeto, responsá-
vel pelo de escopo, cronograma e recursos do projeto;
• Gerente de desenvolvimento: é o responsável pelas atividades diárias do
desenvolvimento;
• Arquiteto-chefe: é o responsável pela modelagem do projeto;
• Programadores-chefe: é o responsável pelas equipes de análise, modela-
gem e desenvolvimento;

• Proprietários de código/classe: são os desenvolvedores orientados pelo
programador-chefe, é de sua responsabilidade a modelagem, codificação e
a realização de testes e documentação do sistema;
• Especialistas do domínio: são os usuários, clientes, patrocinadores ou
analistas de negócio que são responsáveis por transmitir informações a res-
peito dos requisitos do software.
Como o FDD tem foco também em projetos maiores, outros papéis podem
ser incluídos, como:
• Gerente de versão: é o responsável por controlar a evolução do processo,
gerando relatórios em reuniões curtas com os programadores-chefe;
• Gerente de domínio: é o responsável por resolver seus desacordos de
opinião com relação ao domínio do sistema;
• Guru da linguagem: é de sua responsabilidade tirar dúvidas e fornecer
conhecimento da linguagem utilizada no desenvolvimento do sistema;
• Administrador de sistema: é sua responsabilidade configurar e resolver
problemas nas redes e nos servidores (MARQUES, 2012).
Métricas em métodos ágeis

Quando as empresas adotam as metodologias ágeis, as métricas têm
um papel importante; elas ajudam a equipe a obter um entendimento mais
amplo do processo de desenvolvimento do software, ajudam a melhorar
os acertos e medem o desempenho e a eficiência das soluções. Com as
métricas é possível acompanhar, monitorar e avaliar o sucesso ou a falha
de vários processos de negócios.
Algumas métricas podem ser usadas nas metodologias ágeis. Podemos
citar as principais, que são:
• Sprint Burndown;
• Release Burndown;
• Velocidade da equipe;
• Gráfico de controle;
• Diagrama de fluxo cumulativo.
A seguir, iremos falar os detalhes de cada tipo de métrica e suas carac-
terísticas.

Sprint Burndown
A Sprint Burndown é uma ferra-
menta importante de medição das
metodologias ágeis.
Sprint no Scrum é o tempo de
desenvolvimento de um ciclo de
trabalho. Em uma Sprint, a equipe
responsável determina o tempo e o
trabalho que são necessários para
finalizar um projeto. O relatório de
Sprint Burndown serve para acom-
panhar se todo o trabalho previsto está sendo concluído dentro do que foi
colocado na Sprint. Essa métrica ajuda no monitoramento e na finalização
do trabalho ao longo da Sprint. O objetivo é ter todo o trabalho que foi
previsto, concluído (CALAZANS; ALVARENGA, 2014).
Release Burndown
A Release Burndown é uma ferramenta de medição para acompanha-
mento do escopo do trabalho como um todo com o objetivo de mostrar
uma visão geral do projeto de software.
É possível acompanhar o projeto por inteiro, bem como Sprints indi-
viduais, com isso, é possível checar o trabalho que está previsto em cada
Sprint, o que foi concluído e ainda o que será acrescentado depois. Dessa
forma, é possível verificar a eficiência do planejamento (CHAGAS, 2014).
Velocidade da equipe
Velocidade da equipe é uma ferramenta de medição que verifica a quan-
tidade média de trabalho que uma equipe pode concluir em uma Sprint.
Uma previsão dos releases é calculada com facilidade com a utilização des-
sa métrica. O gerente de projeto pode usar essa métrica com objetivo de
prever qual o tempo usado pela equipe para trabalhar na entrega de um
produto, pois o resultado dessa métrica rastreia o trabalho previsto pelo
concluído (SATO, 2009).
Gráfico de controle
Gráfico de controle é uma ferramenta de medição que tem como obje-
tivo comparar o período gasto por uma atividade executada e o período

total que ela foi estimada, ou seja, essa métrica é utilizada para calcular
o tempo do status “em andamento” até o status “concluído”. Tem como
objetivo verificar a eficiência da equipe em relação às atividades, permi-
tindo que a equipe faça ajustes imediatos no que foi previsto e no que foi
concluído (CHAGAS, 2014).
Diagrama de fluxo cumulativo
O diagrama de fluxo cumulativo é uma ferramenta de medição que tem
como objetivo garantir que o andamento das tarefas da equipe seja in-
variável. O uso dessa métrica apresenta as prováveis restrições quando
comparados com históricos já realizados com aqueles que irão se realizar
(CHAGAS, 2014).
Conforme já mencionado, existem outras métricas além dessas. De
qualquer forma, qualquer tipo de métrica utilizada juntamente com me-
todologias ágeis colaboram para a criação de costumes de uma equipe;
elas ajudam na criação de metas e fornecem os resultados sobre o desem-
penho das equipes. Cabe ao gerente de projetos de software definir qual
será mais adequada para o seu negócio.

Sintetizando
Nesta unidade aprendemos o quanto as normas e métricas são importan-
tes quando falamos de desenvolvimento de um software e como a falta dela
afeta as empresas que as adquirem e até as que produzem. No primeiro tópico
tivemos uma introdução sobre normas e órgãos que criam esses normativos.
Normas são regulamentos que devem ser atendidos e que permitem ajustar
determinados comportamentos ou tarefas.
Em seguida, falamos sobre a ISO que é uma organização independente e
não governamental responsável pela criação de normas internacionais para
atender a qualidade e sobre o comitê de normas de qualidade que atende es-
pecificamente a produção de softwares. Na sequência, vimos sobre o Capability
Maturity Model Integration (CMMI): um modelo que visa ajudar as instituições no
melhoramento de processos durante o desenvolvimento de um projeto e fala-
mos sobre os cinco níveis de maturidade do CMMI.
Por fim, falamos sobre a importância da utilização de métricas para garan-
tir a qualidade durante a aplicação de metodologias de produção de software
que se orientam através do PMBOK e RUP. Abordamos também as métricas
que podem ser usadas quando são utilizadas as metodologias ágeis. Aprovei-
tamos que entramos no assunto sobre métodos ágeis e apresentamos alguns
dos métodos que são usados por empresas de grande e pequeno porte para
desenvolvimento de software: o método Scrum, o método XP e o método FDD.

ABNT. Normalização: Conceito: Definição. Disponível em: <http://www.abnt.
org.br/normalizacao/o-que-e/o-que-e>. Acesso em: 30 set. 2019.
ABNT. Normalização: Conceito: Objetivos. Disponível em: <http://www.abnt.
org.br/normalizacao/o-que-e/objetivos>. Acesso em: 30 set. 2019.
ARTERO, M. A. Gestão de projetos de software. Londrina: Editora e Distribui-
dora Educacional S.A., 2016.
BARTIÉ, A. Garantia da qualidade de software. Rio de Janeiro: Elsevier, 2002.
BECK, K. et al. Manifesto for agile software development. Disponível em:
<https://pdfs.semanticscholar.org/3eda/bb96a07765704f9c6a1a5542e39a-
c2df640c.pdf>. Acesso em: 15 ago. 2019.
CALAZANS, A. T. S.; ALVARENGA, M. S. Métricas para métodos ágeis de de-
senvolvimento: um estudo comparativo. Rio de Janeiro: SEGETEC, 2014.
CHAGAS, B. R. A. Conjunto de Métricas para Suporte aos Princípios do De-
senvolvimento Ágil de Software. Recife: BSI, 2014.
ISD Brasil. O que é CMMI? Disponível em: <http://www.isdbrasil.com.br/o-que-
-e-cmmi.php>. Acesso em: 15 ago. 2019.
ISO. ISO/IEC 90003: 2014. Disponível em: <http://www.iso.org/iso/home/sto-
re/catalogue_ics/catalogue_detail_ics.htm?csnumber=66240>. Acesso em: 13
ago 2019.
MARQUES, A. N. Metodologias ágeis de desenvolvimento: processos e com-
parações. Faculdade de tecnologia de São Paulo. São Paulo, 2012. Disponível
em: <http://www.fatecsp.br/dti/tcc/tcc00064.pdf>. Acesso em: 20 ago. 2019.
MEIRELLES, P. R. M. Monitoramento de métricas de código-fonte em pro-
jetos de software livre. Disponível em: <https://social.stoa.usp.br/arti-
cles/0030/6046/tesePauloMeirelles.pdf>. Acesso em: 20 ago. 2019.
OPERADORAS VÃO precisar arrumar bagunça de fios em postes em SP.
Postado por Olhar Digital. (1min. 08s.). Disponível em: <https://www.youtube.
com/watch?v=OCL826Mo6Bs>. Acesso em: 22 ago. 2019.
PRESSMAN, R. S. Engenharia de Software: uma abordagem profissional. 7. ed.
Porto Alegre: McGraw-Hill, 2011.
REZENDE, D. A. Engenharia de software e sistemas de informação. 3. ed. Rio
de Janeiro: Brasport, 2005.

SATO, D. T. Uso eficaz de métricas em métodos ágeis de desenvolvimento
de software. 2007. Dissertação (Mestrado em Ciência da Computação) - Insti-
tuto de Matemática e Estatística, Universidade de São Paulo, São Paulo, 2007.
Disponível em: <http://www.teses.usp.br/teses/disponiveis/45/45134/tde-
06092007-225914/pt-br.php>. Acesso em: 30 set. 2019.
SCHWABER, K. Agile Project Management with Scrum. Redmond: Microsoft
Press, 2004.
SOMMERVILLE, I. Engenharia de Software. São Paulo: Pearson Addison Wes-
ley, 2007.
TELLES, V. M. Extreme Programming: aprenda como encantar seus usuários
desenvolvendo software com agilidade e alta qualidade. São Paulo: Novatec,
2004.
WAZLAWICK, R. S. Engenharia de Software: conceitos e práticas. Rio de Janei-
ro: Elsevier, 2013.

UNIDADE
3 PADRÕES E TESTE
DE QUALIDADE DE
SOFTWARE

Conhecer os padrões de projeto de software;
Compreender a importância do teste de software;
Abordar tipos de testes de software;
Apresentar ao aluno conceitos de inspeção e revisão de software;
Compreender os processos de revisão, etapas e os tipos de defeitos de software.
Tópicos de estudo
Padrões de projeto
Padrões de projeto criacionais
Padrão de projeto de classe
abstrata
Padrões estruturais
Padrões comportamentais
Teste de software
Tipos de testes de software
Inspeção e revisão de software

Processo de revisão
Inspeção
Etapas
Tipos de defeitos encontrados
em cada aspecto

Padrões de projeto
Na engenharia de software, padrão
de projeto é uma solução geral repe-
tível para um problema comumente
ocorrido no projeto de software. O
padrão de projeto não é um desenho
acabado que pode ser transformado
diretamente em código, é uma descri-
ção ou modelo de como resolver um
problema que pode ser usado em muitas situações diferentes. Em outras pala-
vras, significa desenhar diferentes formas para resolver um mesmo problema.
Padrões de projeto podem acelerar o processo de desenvolvimento, forne-
cendo paradigmas de desenvolvimento testados e comprovados. O padrão de
projeto pode ser útil para consideração de problemas que podem não se tornar
visíveis antes da implementação. A sua utilização ajuda a evitar pequenos pro-
blemas que podem se tornar grandes em fases mais avançadas do processo de
desenvolvimento e melhora o entendimento do código para desenvolvedores
e arquitetos familiarizados com os padrões.
O grande problema que temos em padrões de projetos é que, muitas ve-
zes, as pessoas só entendem como aplicar determinadas técnicas de padrão de
projeto a certos problemas. No entanto, essas técnicas são difíceis de se aplicar
a uma gama maior de problemas. Isso acontece pois os padrões de projeto for-
necem soluções gerais, documentadas em um formato que não exige detalhes
que estejam ligados a um problema em específico.
Além disso, os padrões permitem que os desenvolvedores se comuniquem
melhor, usando nomes bem conhecidos e bem entendidos para interações du-
rante o processo de desenvolvimento de software. Padrões comuns de projeto
podem ser melhorados ao longo do tempo, tornando-se mais robustos.
ASSISTA
Para entender melhor sobre Padrões de Projetos, assista o vídeo Design Patter-
ns - Dicionário do Programador, do canal Código Fonte TV. O link se encontra nas
referências bibliográficas.

Fundamental para qualquer ciência ou disciplina de engenharia é um vo-
cabulário comum para expressar seus conceitos, e uma linguagem para rela-
cioná-los juntos. O objetivo dos padrões dentro da comunidade de software
é criar um corpo de literatura para ajudar os desenvolvedores de software a
resolver problemas recorrentes encontrados em todo o desenvolvimento de
software. Os padrões ajudam a criar um idioma compartilhado para comunicar
ideias e experiências sobre esses problemas e suas soluções. Codificar formal-
mente essas soluções e seus relacionamentos nos permite capturar com êxito
o conjunto de conhecimentos que define nossa compreensão de boas arquite-
turas que atendem às necessidades de seus usuários. Formar uma linguagem
padrão comum para transmitir as estruturas e mecanismos de nossas arquite-
turas nos permite raciocinar inteligivelmente sobre elas. O foco principal não é
tanto na tecnologia quanto na criação de uma cultura para documentar e dar
suporte à arquitetura e design de engenharia de som.
Padrões de projeto criacionais

Os padrões de projeto criacionais servem para desenhar a instanciação de
classes. Esse padrão pode ser dividido em padrões criacionais de classes e de
objetos. Embora os padrões de classe usem a herança de maneira eficaz no
processo de instanciação, os de objetos usam as técnicas de maneira eficaz
para realizar o trabalho.
Todos os padrões criacionais tratam de instanciar objetos da melhor
maneira. Exemplo: “Classe Criadora” especial pode tornar o programa mais
flexível e geral.
EXEMPLIFICANDO
O padrão de projeto criacional garante que, para uma classe específica,
possa existir somente uma única instância, a qual é acessível de forma
global e uniforme. Dessa forma, uma classe Singleton irá:
– Armazenar a única instância existente;
– Garantir que apenas uma instância será criada;
– Prover acesso a tal instância.
Exemplos práticos:
– Um sistema de arquivos, gerenciador de janelas, tabela de salários
(ajuste), leitor de teclado, entre outros.

Na Figura 1, é possível visualizar como a classe Singleton é representada.
Singleton Classe Singleton
$ instance : Singleton
Singleton()
getInstance() : Singleton
Singleton getInstance()
{
If(instance == null)
Instance = new
Singleton();
return instance;
Figura 1. Exemplo de Classe Singleton.
Padrões de projeto de classe abstrata

Fornece uma interface para criar classes de objetos relacionados ou de-
pendentes sem especificar suas classes concretas. Uma hierarquia que en-
capsula muitas “plataformas” possíveis e a construção de um conjunto de
“produtos”. Se uma aplicação for portável, ela precisa encapsular as depen-
dências da plataforma.
Essas “plataformas” podem incluir: sistema de menus, sistema operacio-
nal, banco de dados, etc. Muitas vezes esse encapsulamento não é planejado
antecipadamente e muitas instruções com opções para todas as plataformas
suportadas atualmente começam a repetir em todo código (Diagrama 1).

DIAGRAMA 1. EXEMPLO GENÉRICO DE PADRÃO DE PROJETOS DE CLASSE ABSTRATA
“interface”
Class1
AbstractProductOne
ProductOnePlatformOne ProductOnePlatformTwo
“interface”
AbstractPlatform
PlatformOne PlatformTwo “interface”

AbstractProductTwo
+makeProductOne()
+makeProductTwo()
ProductTwoPlatformOne ProductTwoPlatformTwo
return new ProductOnePlatformTwo );
return new ProductTwoPlatformTwo );
Padrões estruturais
Este tipo de padrão de projeto é interessante quando se deseja compor
objetos em estruturas de árvore para representar hierarquias todo-parte. Per-
mite que clientes tratem objetos individuais e compostos de maneira uniforme.
Eles descrevem como classes e objetos podem ser combinados para formar gran-
des estruturas. Objetos padrões descrevem como objetos podem ser compostos em
grandes estruturas utilizando composição ou inclusão de objetos com outros objetos.
Padrões comportamentais
Este tipo de padrão de projeto descreve padrões de comunicação entre
objetos ou classes, caracterizando o modo como classes e objetos interagem
e compartilham responsabilidades. Existem situações onde diversos objetos
(visualizações) devem representar um outro objeto (dados).

Funciona da seguinte forma:
1 - Define uma relação de dependência, de forma que quando um certo objeto
(assunto) tem seu estado modificado, os demais (observadores) são notificados;
2 - Possibilita baixo acoplamento entre os objetos observadores e o assunto.
Teste de software
De acordo com Amaral et al., em Metodologias de teste de software, de 2009,
devido aos métodos de desenvolvimento e complexidade dos softwares, eles
são altamente passiveis a erros. Esses erros podem ocorrer devido a proble-
mas na especificação dos requisitos, na modelagem de negócio, no modo que
a funcionalidade deve ser desempenhada, na complexidade do sistema e na
mudança de requisitos. Todos os desenvolvedores estão suscetíveis a erros de
programação, já que esses sistemas possuem alto grau de complexidade. Para
solucionar e evitar tal problemática, existe uma atividade em que se pode ava-
liar, testar e corrigir tais problemas, denominada teste de software, que é feita
de diversas maneiras e usando diversas metodologias, podendo ser vista como
uma parcela do processo que garante a qualidade de software.
A atividade de teste de software consiste em uma das etapas do desenvol-
vimento de um software cujo objetivo primordial é avaliar a possibilidade e a
existência de erros no sistema, para que então possam ser solucionados ou
evitados futuramente. Essa etapa busca verificar se o sistema se comporta de
acordo com o especificado nos requisitos levantados junto ao cliente, reduzin-
do a probabilidade de erros quando o sistema estiver em produção.
Neto, em seu artigo “Introdução a testes de software” na revista Engenharia
de software magazine, de 2015, declara que o teste de software busca a execu-
ção de um determinado sistema para avaliar se alcançou os objetivos propos-
tos, como também se processa corretamente para o seu fim específico. Portan-
to, o teste de software tem como objetivo principal verificar se o sistema possui
falhas, para que elas sejam eliminadas antes da entrega para o cliente.
Durante a década de 70, a ideia dos testes de softwares começava a ser
sedimentada, sendo um processo dependente de várias etapas e não só a re-
visão de códigos de linguagens. Este novo conceito trouxe inúmeros aspectos
positivos para o setor de TI, porém não houve redução de custos, já que se tes-

tava o software desde o início de seu
desenvolvimento. Atualmente, os tes-
tes de softwares são mais eficientes e
bem estruturados, o que gera meno-
res custos durante a execução.
Ainda na década de 70, esses tes-
tes eram executados pelas próprias
pessoas que desenvolviam o software,
sendo que esse método de validação
muitas vezes não era realizado, pois
eram executados apenas se houvesse
um tempo hábil. Porém, com o passar
dos anos, com a alta demanda e concorrência acirrada do mercado, aumen-
tou-se o nível de exigência por qualidade dos softwares e, assim, os testes so-
freram inúmeras inovações. Além desse aspecto, sabe-se que a execução dos
testes de softwares também influencia na avaliação do grau de qualidade, pois
é uma forma de revisão final das especificidades esperadas pelo projeto.
Vale ressaltar que a execução adequada de tal atividade acarreta inúmeros
benefícios, como a redução de custos, retrabalhos e o alinhamento da qualida-
de com a imagem institucional da empresa. Estima-se que defeitos de software
tenham custado cerca de US$ 60 bilhões em 2007. Bancos e fabricantes de celu-
lares são os segmentos mais dispostos a evitar tais erros e que mais investem
na terceirização deste serviço.
Segundo Amaral et al. na obra já citada, Metodologias de teste de software,
nos dias de hoje, o mercado na área de testes de software encontra-se em
expansão e evolução. Esses testes devem ser assegurados por normas e por
procedimentos escritos, a partir de órgãos certificados e qualificados mundial-
mente. Esses órgãos são: o SW-CMM (modelo de maturidade em capacitação),
SE-CMM (software de maturidade em capacitação), ISO 15504 (melhoria dos
processos de desenvolvimento de software e a determinação da capacidade
de processos de uma organização) e o mais conhecido CMMI (modelo de capa-
cidade e maturidade integrado). Especificamente no Brasil, existem os orgãos
IBQTS (Instituto Brasileiro de Qualidade em Testes de Software) e CBTS (Certifi-
cação Brasileira de Teste de Software).

No Brasil, grande parte das empresas utiliza da norma ISSO 9126 (NBR 13596
- padronização da avaliação da qualidade do software) sendo um certificado de qua-
lidade do processo de software, a qual possui requisitos que garantem que ele man-
tenha um desempenho positivo conforme as condições esperadas. A norma busca
definir sanções de qualidade para o software, avaliar as suas especificações durante
o seu desenvolvimento para averiguar se estão sendo cumpridos, descrever as ca-
racterísticas e atributos do software em desenvolvimento e também verificar se o
software desenvolvido possui realmente as especiações esperadas pelo cliente.
Sabe-se que durante a elaboração do software, os defeitos que aparecem
podem advir das atividades do próprio programador que o desenvolve. Mesmo
que sejam utilizados os métodos e as ferramentas apropriadas, os erros técni-
cos podem continuar presentes, por isso se faz necessário que haja a realiza-
ção dos testes de softwares também nas suas etapas de elaboração.
Tipos de testes de software

Conforme já mencionado, os erros ou defeitos podem surgir durante as
etapas de desenvolvimento do software, por isso se faz necessária a utiliza-
ção dos mais diversos testes, de acordo com o Quadro 1.
QUADRO 1. TIPOS DE TESTES PARA CONCEPÇÃO DE UM SOFTWARE
NÍVEL DO TESTE
Analisam-se unidades menores de um software, de modo isolado,

para verificar se há o funcionamento adequado de todas as partes. O
Teste de unidade
universo alvo desse tipo de teste são os métodos dos objetos ou mes-
mo pequenos trechos de código.
O teste de integração é utilizado após aplicar o teste de unidade, verifi-

cando se elas juntas funcionam adequadamente, pois há possibilidade
Teste de integração
de as unidades em funcionamento conjunto apresentarem incompati-
bilidades, mesmo após terem sido aprovadas no teste de unidade.
Busca falhas no software como se fosse um usuário final, assim, os

testes são realizados nos mesmos ambientes, com as mesmas condi-
Teste de sistema
ções e com os mesmos dados de entrada que um usuário utilizaria no
seu dia a dia de manipulação do software.
Neste caso, um grupo de usuários simulam operações de rotina do

Teste de aceitação sistema de modo a verificar se seu comportamento está de acordo
com o solicitado.
Fonte: NETO, 2015. (Adaptado).

DIAGRAMA 2. PARALELISMO ENTRE AS ATIVIDADES DE TESTE (À DIREITA) E
DESENVOLVIMENTO (À ESQUERDA)
Análise dos Teste de

requisitos aceitação
Especificação
Teste de sistema
do sistema
Desenho do
Teste de integração
sistema
Desenho do Teste unitário

componente
Codificação
Fonte: ROCHA, 2018.
Assim, durante o desenvolvimento do software, devem-se realizar os testes

conforme explicitados no Quadro 1. No Diagrama 2, tem-se exemplificados os tes-
tes a serem utilizados em consonância com cada etapa da concepção do projeto.
Conforme o Diagrama 2, a etapa de análise de requisitos deve ser associada
ao teste de aceitação a partir dos referentes documentos de requisitos. Depois,
deve-se realizar o teste de sistema de acordo com as especificações do projeto. Em
seguida deve-se realizar o planejamento dos testes de integração a partir do dese-
nho do sistema e, por fim, o teste unitário de acordo com desenho do componente.
A partir da codificação, são utilizadas diferentes técnicas de teste de software
para confirmar que ele está sendo executado de maneira correta, ou seja, sem erros
e sem que haja possibilidade de defeitos no futuro. Existem diversas técnicas que
podem ser aplicadas neste momento e de diferentes formas para validar os aspec-
tos principais do software, as quais são classificadas de acordo com a origem das
informações utilizadas para estabelecer os requisitos de teste. As técnicas de teste
existentes são: teste da caixa branca, teste da caixa-preta e o teste da caixa cinza.
O teste da caixa branca utiliza o aspecto interno do programa/sistema, es-
pecificamente o código fonte, para avaliar seus componentes como: fluxo dos
dados, condição, ciclos, entre outros. Como não há o contato direto com o có-

digo do software, valida-se o resultado da compilação e/ou publicação através
de um app mobile, um site na internet, um sistema desktop ou um serviço dis-
ponibilizado. Para implementá-lo, é preciso verificar o nível de qualidade que
se pretende obter do programa.
O teste da caixa preta, ou técnica funcional, difere do anterior pois prioriza os as-
pectos externos sem levar em consideração o modo de funcionamento do sistema,
já que o foco, neste caso, são atividades que o programa deve desempenhar. Para
isso, é preciso averiguar se os dados de entrada são compatíveis com os de saída.
Também temos o teste da caixa cinza, que basicamente é a junção dos dois
testes anteriormente explicitados. Este teste avalia os aspectos internos e tam-
bém os externos. Faz-se uma engenharia reversa para analisar o código, para
que haja o entendimento dos fatores limitantes e mensagens de erro que pos-
sam melhorar a construção de casos de testes (forma comumente utilizada
para a definição de testes estruturados de acordo com as melhores práticas).
Outras técnicas de teste podem ser utilizadas de acordo com necessidades de
negócio ou em relação as restrições tecnológicas, sendo essas técnicas os tes-
tes de regressão, carga, usabilidade e de estresse.
A cada inovação do software, é imprescindível que haja a realização do teste
de regressão, sendo possível avaliar se determinadas funcionalidades foram
modificadas, o que evita que erros antigos que foram eliminados possam re-
tornar com a nova função.
O teste de carga é feito para avaliar quanto o software suporta em questão
de dados e de transferências, sem que ocorram erros. Já o teste de usabilidade
é como um tipo de avaliação de satisfação do cliente, onde um determinado
grupo de pessoas avalia as funcionalidades do sistema, as dificuldades na sua
utilização e o que pode ser melhorado. Já o teste de estresse coloca o software
na potência máxima de funcionamento para verificar se possui erros quando
está nesse estado.
EXPLICANDO
Existem sistemas críticos que não podem gerar erros em hipótese alguma,
como o controle de tráfego aéreo, por exemplo, que compromete a vida
da população caso apresente erros. Para esses sistemas, muitas empre-
sas utilizam técnicas e metodologias, sendo elas a injeção controlada de
defeitos (ITool), a UMIL, testes automatizados e funcionais.

Os sistemas críticos utilizam informações através de linguagens de progra-
mação e podem ser regulados conforme as adversidades. Neste caso, essa
regulação é realizada por sensores e as linguagens de informação por equipa-
mentos controladores; a atuação é conduzida por dispositivos atuadores. Caso
haja falhas nesses dados, podem ocorrer acidentes irreversíveis e, por conta
disso, é imprescindível a utilização de ferramentas e metodologias inovadoras
que garantam a segurança.
O processo de injeção controlada de defeitos e a análise desses defeitos na
segurança do sistema é um tipo teste que foca nos defeitos introduzidos no
início do desenvolvimento do software.
Nakawaga e Maldonado, no artigo “ITOOL – Uma Ferramenta para injeção
de defeitos de softwares”, de 2013, suscitam que a injeção controlada de defei-
tos é uma técnica que avalia como o sistema se comporta perante eles, através
de seus impactos na segurança de sistemas críticos.
A ferramenta denominada ITool foi desenvolvida seguindo os pressupostos
da injeção controlada de defeitos, cujo principal objetivo é ajudar nos proble-
mas associados aos sistemas críticos, e funciona através de etapas de teste
manipulando condições que confrontam o programa original em relação ao
que contém erros.
A ferramenta ITool estabelece quatro tipos de defeitos: entidade (carac-
teres associados a um defeito) mal-empregada, falta de entidade, entidade
espúria e entidade simples incorreta. Estes tipos de defeitos são utilizados
como mecanismos para resolução de problemas durante o desenvolvimen-
to do software.
A ITool está disponível para as plataformas Solaris e Linux e é dividida em
três partes: interface gráfica, módulos funcionais executáveis e base de da-
dos. A interface gráfica é independente dos módulos funcionais executáveis,
permitindo que a ITool seja gráfica ou ativada através dos módulos funcionais
(shell scripts).
A UML (Unified Modeling Language) advém de um código de linguagem es-
pecifico associado ao desenvolvimento de sistemas orientados a objetos. Uti-
liza diagramas que representam o software em especifico, permitindo sua vi-
sualização por diferentes pontos. Com a versão 2.0 da UML, é possível utilizar
pacotes de perfis.

A UML, quando associada ao padrão IEEE829, tem a funcionalidade de va-
lidar requisitos implementados que uniformizam diferentes pontos para ge-
ração de casos de testes e até mesmo para casos de testes de uso estendido.
Já está no mercado uma ferramenta de auxílio dos testes que foi baseada nas
metodologias explicitadas. Ela possibilita documentação do projeto de teste, seus
dados e o detalhamento dos procedimentos, que seguem os seguintes aspectos:
1) Identificar a descrição do caso de uso e as suas vias secundarias;
2) Identificar pré-condições e pós-condições;
3) Desenvolver especificações de teste conforme cada caso;
4) Identificar as variáveis operacionais conforme cada caso;
5) Desenvolver os procedimentos para os testes.
A partir dessas novas metodologias e inovações de testes, Izabel, em sua
monografia Testes automatizados no processo de desenvolvimento de softwares,
de 2014, afirma que essas automatizações utilizam um software externo (que
não faça parte do software que está sendo testado) para o controle da exe-
cução dos testes e para que haja um comparativo entre os resultados encon-
trados com os resultados esperados. Através desse processo, podem-se au-
tomatizar algumas tarefas de teste repetitivas ou adicionar novos testes mais
específicos, que seriam difíceis de serem realizados manualmente.
Sabe-se que controlar a qualidade de software não é fácil, porém isso pode
ser realizado através de métodos ágeis de desenvolvimento de software (pro-
gramação extrema focada nos testes automatizados). Assim, a programação
extrema, ou XP, é eficaz para equipes pequenas e médias que buscam desen-
volver softwares com requisitos vagos e que sempre necessitam de alterações.
Tal fato está relacionado à necessidade de acompanhamento constante e o
continuo ajuste no software.
Os testes automatizados devem começar pelos testes pequenos, que po-
dem ser realizados pelas ferramentas chamadas de arcabouços, como o JSUnit,
CSUnit, entre outros. Outro tipo de teste importante é o de aceitação, já que
envolve todas as etapas de desenvolvimento do sistema.
Os testes funcionais são caracterizados como o teste da caixa preta, ante-
riormente explicitado, porém de maneira automatizada. Estes tipos de testes
fundamentam-se em duas perspectivas: determinar as funções que o software
deve realizar e gerar casos de teste com possibilidade de verificar essas fun-

ções. Na verdade, não somente as funções, mas também pode-se testar pe-
quenas partes dos componentes, como por exemplo, uma DLL.
Um exemplo de teste funcional é a ferramenta AFTT (Aspect-based Funcitio-
nal Testing Tool) presente em programas Java, a qual oferece suporte a alguns
critérios funcionais. Ela disponibiliza uma interface gráfica que permite que o
técnico responsável acesse as funcionalidades do software e, assim, os casos
de teste podem ser executados e interrompidos conforme necessidade.
Diante de todo o desenvolvimento discursivo, pode-se inferir que o teste
de software é uma das atividades mais trabalhosas do processo de desenvol-
vimento de um sistema em especifico, pois deve ser desenvolvido em diversas
etapas e todas elas devem ser testadas para avaliar se o mesmo está dentro
das especificações esperadas.
Ainda é preciso enfatizar o custo associado à criação do software, pois de-
pende da criticidade da aplicação a ser desenvolvida, sempre levando em conta
que diferentes perspectivas de projeto requerem uma preocupação diferencia-
da com as atividades de teste. Assim, a realização dos testes não compreende
apenas a geração e execução de casos de teste, mas também um bom planeja-
mento, gerenciamento e analise dos resultados.
Inspeção e revisão de software

Segundo Sommerville, em sua obra Engenharia de Software, de 2011, revisões
e inspeções são atividades que têm o intuito de controlar o nível de qualidade
dos entregáveis de projeto. Essas atividades envolvem um exame do software,
de sua documentação e de seus registros de processos, a fim de descobrir er-
ros e omissões e verificar se foram seguidos os padrões de qualidade. Revisões
e inspeções são normalmente utilizadas junto com testes de programa, pois
são uma parte do processo geral de validação e verificação de software.
No processo de uma revisão, um grupo de pessoas examina o software e a
documentação associada em busca de prováveis problemas e não conformidade
com padrões. A equipe gera documentos de avaliação do entregável conforme
o nível de qualidade foi solicitado e, com isso, toma decisões sobre o entregável.
Essas avaliações de qualidade têm como base documentos que foram pro-
duzidos durante o processo de desenvolvimento de software, que são: as espe-

cificações de software, projetos ou códigos, modelos de processos, planos de
testes, procedimentos de gerenciamento de configuração, padrões de proces-
so e manuais de usuário. A revisão tem como objetivo verificar a consistência e
a integridade dos documentos ou código em revisão e atestar que os padrões
de qualidade foram seguidos.
No entanto, as revisões não têm como finalidade apenas validação da con-
formidade com os padrões. Elas também são úteis em ajudar a descobrir pro-
blemas e omissões no software ou em sua documentação de projeto, sendo
que as conclusões das revisões são processos de gerenciamento e devem ser
formalmente apontadas como parte do processo. Caso sejam encontrados
problemas, os revisores devem enviar seus comentários aos autores do soft-
ware ou ao responsável por corrigir os erros ou as omissões.
As revisões e inspeções têm como objetivo garantir a melhoria da qualidade
de software e não avaliar o desempenho dos indivíduos que compunham a
equipe de desenvolvimento, sendo um processo público de detecção de er-
ros, em comparação com processos de testes de componente mais privados.
Precisamente, alguns erros cometidos por indivíduos são revelados a toda a
equipe de programação. Mas a fim de garantir que todos os desenvolvedores
continuem engajados no processo de revisão, os gerentes de projeto precisam
estar atentos às preocupações individuais. É necessário que uma cultura de
trabalho seja desenvolvida a fim de fornecer suporte sem procurar os culpados
pelos erros descobertos.
Processo de revisão
Existem muitas variações na modelagem do processo de revisão, mas nor-
malmente ele é composto de algumas fases.
Uma revisão tem por objetivos:
• Verificar se o artefato produzido satisfaz as especificações elaboradas
em fases anteriores;
• Identificar os desvios com relação aos padrões estabelecidos, inclusive
fatores que afetem a manutenibilidade;
• Sugerir melhorias;
• Promover a troca de conhecimento entre os participantes;

• Tornar o projeto, como um todo, mais viável.
Revisões estão incluídas no SEI Capability Maturity Model (CMM) como uma
área-chave de processo (KPA) de nível 3. O Capability Maturity Model Integra-
tion (CMMI), que engloba software, engenharia de sistemas e desenvolvimen-
to integrado de produtos, inclui a revisão como uma área do processo de
verificação do produto.
Características de Revisão
• O processo:
O processo de revisão é bem estruturado, dividido em fases e com proce-
dimentos a serem realizados em cada fase.
• Equipe:
O número de pessoas envolvidas deve ser pequeno (de 3 a 5). Pessoas
possuem papéis definidos na equipe: autor, revisor, etc.
• Diretrizes:
Os participantes devem receber o produto e a documentação associada
dias antes da reunião. A reunião tem duração pré-fixada (2 horas).
• Saídas:
Ata ou minuta da reunião e lista de itens a serem corrigidos
Uma revisão é uma leitura crítica do artefato e de sua documentação.
Para isso, são realizadas anotações da seguinte forma:
• Os problemas encontrados;
• Dúvidas e dificuldades de compreensão;
• Possibilidades de melhorias.
Alguns exemplos de artefatos do processo de desenvolvimento de soft-
ware são:
• Especificações;
• Modelos;
• Projetos;
• Código;
• Casos de teste;
• Processos de desenvolvimento;
• Planos;
• Padrões;
• Arquivos de auxílio para o usuário;

• Documentação para o usuário;
• Teses, dissertações.
Revisão é uma atividade na qual um artefato de software pode ser obser-
vado pela equipe do projeto, gerentes, usuários, clientes ou outras partes
interessadas. O objetivo da revisão é garantir que o artefato de software es-
teja em conformidade com suas especificações, além de verificar se seu de-
senvolvimento está de acordo com os planos, padrões e diretrizes aplicáveis
para o projeto.
De acordo com inúmeros autores, a revisão, quando praticada, encontra
de 60% a 80% do total dos problemas que podem ser encontrados em todo
o ciclo de desenvolvimento. Pode-se economizar aproximadamente 40% do
custo total de desenvolvimento quando se praticam revisões.
Inspeção
De acordo com Sommerville, em sua obra já citada, as inspeções de pro-
grama são “revisões em pares” em que os membros da equipe colaboram
para encontrar bugs no programa que está sendo desenvolvido. As inspeções
podem fazer parte dos processos de verificação e validação de software. Elas
complementam os testes, pois não exigem que o programa seja executado.
Isso significa que podem ser verificadas versões incompletas do sistema e
que representações, tais como modelos UML, podem ser checados.
As inspeções são técnicas estáticas de V&V realizadas sem que seja preci-
so executar o software. Elas são aplicadas em:
documento de requisitos;
• Diagramas de projeto;
• Código-fonte – apenas correspondência com a especificação.
Podem ser realizadas em todas as etapas do ciclo de vida de desenvolvi-
mento do software.
O conceito de inspeção foi introduzido pela IBM na década de 70 e trata-se
de uma técnica formal para revisão visual de artefatos de software para detec-
tar erros, violações de padrões de desenvolvimento e outros problemas. A ins-
peção é muito rigorosa e os inspetores são treinados em técnicas de inspeção.
Essa técnica é aplicada amplamente para revisar código de programa.

O objetivo das inspeções é verificar se o artefato de software satisfaz as
especificações estando de acordo com os padrões aplicáveis, identificar des-
vios e coletar dados de engenharia de software como defeito e esforço.
É importante praticar a técnica de inspeção, pois através dela é possível
identificar até 67% do total de defeitos durante o desenvolvimento. Desses
defeitos, 82% referem-se a design e código.
O Diagrama 3 a seguir descreve um esquema de inspecionamento em todos
os processos que contemplam o desenvolvimento de um sistema de qualidade.
DIAGRAMA 3. TESTE DE INSPEÇÃO
Inspeções
Especificação Arquitetura de Modelos de Esquemas de

Programa
de requisitos software projeto em UML banco de dados
Protótipo de
Teste
sistema
Prós e contras da realização de inspeção:

• Prós: processo formal realizado sistematicamente com resultados confiá-
veis, onde 60% a 90% dos erros de um programa podem ser encontrados em
uma única revisão.
• Contras: Resistência ao uso – pessoal especializado para realizar o proce-
dimento aumenta o custo do projeto.

Etapas
Segundo o artigo de Fagan, de 1986, Advances in software inspections, o
processo de inspeção é realizado por uma equipe multidisciplinar que repre-
sentam os seguintes papéis:
• Autor: é a pessoa que irá desenvolver o artefato que será inspecionado;
• Moderador: responsável por liderar as atividades de inspeção e reuniões;
• Redator: ele cataloga os defeitos encontrados e as soluções sugeridas
durante a inspeção;
• Inspetor: tem a função de encontrar erros no produto/solução.
O quadro a seguir apresenta um comparativo entre a revisão e a inspeção:
QUADRO 2. REVISÃO E INSPEÇÃO
ITEM NÍVEL DO TESTE INSPEÇÃO
1. Avalia a conformidade com as 1. Detectar e identificar defeitos

Objetivos especificações 2. Documentação dos defeitos
2. Garante a integridade 3. Verificar resolução
Qualificação 1. Experts técnicos

1. Inspetores formalmente treinados
dos participantes 2. Membros da equipe
A equipe de Revisão pede à

A equipe declara informa o resultado
liderança da equipe de Proje-
Poder decisório (Aceite/Re-trabalho/Verificação/Re-
to ou Gerência para levar as
-inspeção)
recomendações adiante
É importante saber que revisão e inspeção são aspectos diferentes com rela-
ção aos artefatos utilizados para o desenvolvimento de software, mas que juntos
podem minimizar problemas que podem ser encontrados em fases muito avança-
das do desenvolvimento de software e que podem trazer custos muito elevados.
Tipos de defeitos encontrados em cada etapa do

desenvolvimento
A inspeção deve ser realizada em documentos de requisitos e pode revelar
inúmeros defeitos. Podemos classificá-los como mostrado a seguir:

• Defeito de omissão: Algumas informações necessárias podem ter sido
omitidas. Por exemplo: omissão de uma funcionalidade ou da capacidade de
desempenho do sistema.
• Defeito de artefato incorreto: Existem situações em que os artefatos
produzidos nas etapas de desenvolvimento de software são contraditórios
com o sistema a ser produzido.
• Defeito de inconsistência: a informação aparece mais de uma vez no ar-
tefato e de forma diferente em cada aparição, causando incoerência.
• Defeito de ambiguidade: a informação ou até mesmo um artefato pode
levar a equipe de desenvolvimento a múltiplas interpretações.
• Defeito de informação estranha: uma informação que aparece no artefato e
embora esteja relacionada ao domínio, não é necessária para o sistema em questão.
A seguir, veremos exemplos de pontos de inspeção em narrativa de caso de uso.
QUADRO 3. MODELO DE CASO DE USO REVISADO
ELEMENTOS DA
CHECKLIST
NARRATIVA
• O nome do caso de uso descreve o objetivo a alcançar? Exemplo: Efetuar

login no sistema específico.
Caso de uso
• Cada caso de uso possui um código a ele associado? Exemplo: UC01 –
Efetuar Login.
Descrição • A descrição é resumida? Explica bem o objetivo principal?

Ator principal • O ator principal aciona o caso de uso?
• Foram redigidas como um conjunto de condições?
Elas estabelecem todas as condições necessárias para poder iniciar o
Pré-condições caso de uso?
• Falta alguma condição para iniciar o caso de uso?

• Possui entre 3 e 9 ações? Podem ocorrer casos que violem essa regra
• As ações estão redigidas segundo o padrão de redação?
• As ações do fluxo principal correspondem ao objetivo principal e não
consideram anomalias de execução?
Fluxo • Basta a satisfação das pré-condições para poder disparar o fluxo principal?
principal
• O fluxo principal pode ser disparado pelo ator principal?
• O fluxo principal resulta em algo que interesse ao ator principal?
• O fluxo principal é viável?
• O fluxo principal é capaz de assegurar a pós-condição ao terminar?
Observação: podem ser usados os critérios de qualidade de especificações.

• Cada fluxo alternativo é disparado por um evento ou condição clara-
mente definida?
• Cada fluxo alternativo se inicia em uma ação definida ou é genérico?

• A condição de disparo não é ambígua com relação aos demais fluxos
alternativos?
• A condição de disparo do fluxo alternativo pode ocorrer na prática?

Fluxos
alternativos
• Todas as condições anormais (exceções) foram consideradas? Considere
uma a uma as ações do fluxo principal e dos fluxos alternativos.
• As ações estão redigidas segundo o padrão de redação?

• O fluxo alternativo com término anormal é capaz de assegurar a garan-
tia mínima?
• Está claro qual será o resultado da execução do fluxo alternativo?

Observação: podem ser usados os critérios de qualidade de especificações.
Os defeitos encontrados no código fonte podem ser classificados em:

• Defeitos de omissão: pode ser causado por esquecimento do programa-
dor de algum elemento no programa, como um comando que atribui valor a
uma variável, por exemplo.
• Defeitos de comissão: um segmento de código incorreto, quando, por
exemplo, um operador aritmético errado é usado em uma expressão.
• Defeito de inicialização: inicialização incorreta de uma estrutura de dados.
• Defeitos de computação: qualquer computação incorreta para a geração
do valor de uma variável.
• Defeito de controle: causa a execução de um caminho de controle errado
para um valor de entrada.
• Defeito de interface: quando um módulo usa ou faz suposições sobre
dados que não fazem parte de seu escopo.
• Defeitos de dados: uso incorreto de uma estrutura de dados.
• Defeitos de linguagem: erros de ortografia e gramática.

Sintetizando
Nesta unidade, aprendemos o quanto os padrões de software são impor-
tantes quando falamos de desenvolvimento de um software e como a falta
desses padrões afeta as empresas que produzem.
Padrões de software servem para evitar problemas recorrentes em seu de-
senvolvimento e que podem se tornar ainda maiores em fases mais avançadas do
processo. Além disso, permitem o reuso de componentes que estão prontos e que
funcionam adequadamente em outros projetos. Além disso, os padrões colabo-
ram na qualidade do código, deixando-o mais organizado e com fácil manutenção.
No segundo tópico dessa unidade, tivemos uma introdução sobre teste de
software. Testá-los nos permite avaliar e corrigir problemas. É uma fase do con-
trole de qualidade que é executada para garantir que o software está atendendo
todos os requisitos esperados e que eles estão funcionando de forma adequada.
E, para finalizar, nos últimos tópicos falamos sobre as revisões e inspeções
de software, uma atividade que busca evitar que o trabalho seja refeito por
conta de atividades malfeitas e erros. As revisões e inspeções buscam garantir
a melhoria no processo e, consequentemente, a qualidade de software. Essas
duas técnicas podem ser empregadas em todas as fases do software e em to-
dos os artefatos gerados durante o desenvolvimento.

AMARAL D. et. al. Metodologias de teste de software. 11 f. 2009. Monografia -
Centro Universitário Fundação Santo André, São Paulo. 2009.
AMARAL, J. R. Ferramenta para geração de caso de teste funcional. 2017. 81
f. Coordenação do Curso de Sistemas de Informação, Universidade Estadual do
Mato Grosso do Sul, Mato Grosso do Sul. 2017.
CECHIN, S.; WEBER, T. S.; NETTO, J. C. Arquitetura para injeção de falhas em
protocolos de comunicação segura em aplicações críticas. Instituto de Infor-
mática – Universidade Federal do Rio Grande do Sul, Rio Grande do Sul. 2016.
Disponível em: <http://sbrc2016.ufba.br/downloads/WTF/155154.pdf>. Acesso
em: 23 ago. 2019.
DESIGN patterns – Dicionário do programador. Postado por Código Fonte TV
(8min. 22.s). Disponível em: <https://www.youtube.com/watch?v=J-lHpiu-Twk>.
Acesso em: 20 out. 2019.
DEMILLO, R. A.; MATHUR, A. P.; A grammar-based fault classification scheme
and its application to the classification of the errors of TEX. Software Engi-
neering Research Center, Purdue University, West Lafayette. 1995.
DIAS, L. C.; MENNA, R. S. Teste de desempenho a partir de modelos UML para
componentes de software. Revista da graduação, Porto Alegre, v.1, n.1. 2008
IZABEL, L. R. P. Testes automatizados no processo de desenvolvimento de soft-
wares. 2014. 65 f. Monografia - Curso de Engenharia Eletrônica e de Computação
da Escola Politécnica, Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2014.
MOLINARI L. Teste de Software – Produzindo sistema melhores e mais confiá-
veis. 4 ed. São Paulo: Editora Érica, 2012.
NAKAGAWA, E. Y.; MALDONADO, J. C. ITOOL – Uma Ferramenta para injeção de
defeitos de softwares. ICMC-USP. Disponível em: <http://www.inf.ufsc.br/sbes99/
anais/Sessao-Ferramenta-Completo/18-itool.pdf>. Acesso em: 23 ago. 2019.
NETO, A. C. D. Introdução a testes de software. 2015. Engenharia de softwa-
re magazine, [s.l.]. [s.d.]. Disponível em: <https://edisciplinas.usp.br/pluginfile.
php/3503764/mod_resource/content/3/Introducao_a_Teste_de_Software.pdf>.
Acesso em: 23 ago. 2019.
PEIXE, M. Qualidade de software: entenda as técnicas, processos, metodologias
e ferramentas de testes. Startupi. 2018. Disponível em: <https://startupi.com.

br/2018/10/qualidade-de-software-entenda-as-tecnicas-processos-metodolo-
gias-e-ferramentas-de-testes/>. Acesso em: 23 ago. 2019.
PRESSMAN, R. S. Engenharia de Software. 5. ed. Rio de Janeiro: McGraw-Hill, 2002.
ROCHA, A. C. Introdução a teste de software. STI – Universidade Federal da Pa-
raíba. Disponível em: <http://www.nti.ufpb.br/~caroline/curso/Aula01Curso%20
de%20Testes%20de%20Software%20-%20NTI.pdf>. Acesso em: 23 ago. 2019.
SOUZA, K. P.; GASPAROTTO, A. M. S. A importância da atividade de teste no de-
senvolvimento de software. In: Encontro Nacional de Engenharia de Produção,
31., 2013, Salvador. Anais...Salvador: ENEGEP, 2013.
SILVA, J. S. et. al. O processo de teste de software. Revista Tecnologias em Pro-
jeção, vol. 7, n. 2, Brasília, 2016.
SOMMERVILLE, I. Engenharia de Software, 9 ed. Londres: Pearson Educa-
tion, 2011.
FAGAN, M. Advances in Software Inspection. In: BROY, M.; DENERT, E. Pioneers
and their contributions to software engineering. Berlim: Springer, 2002.
PRESSMAN, R. S. Software Engineering: A Practitioner’s Approach. 5 ed. Nova
Iorque: McGraw Hill, 2000.

UNIDADE
4 PROCESSOS DE
GERÊNCIA DA
QUALIDADE DE
SOFTWARE
SER_COD_QUASOFT_UNID4_2.indd 85 28/11/2019 13:21:48

Apresentar ao aluno os conceitos sobre processos de gerência de qualidade
de software;
Compreender a importância da gestão da qualidade e os modelos de

qualidade de software;
Abordar os fundamentos sobre a melhoria de processos e melhoria de

processos de desenvolvimento para aplicativos web;
Conhecer sobre melhoria de processos de software brasileiro, capacidade de

processos.
Tópicos de estudo
Processos de gerência da quali-
dade do software
Modelos de qualidade de sof-
tware
Melhorias de processos
Melhoria no processo de de-
senvolvimento de web app
MPS.BR – Melhoria do Processo

de Software Brasileiro
Capacidade do processo
Casos de sucesso na implanta-
ção de melhoria de processo

Processos de gerência da qualidade do software
Com o avanço do uso dos sistemas de informação, é imprescindível a exis-
tência de softwares com alto percentual de qualidade, ou seja, softwares que
forneçam resultados corretos quando alimentados com dados válidos e que
identifiquem corretamente os dados de entrada inválidos.
Qualidade é um pré-requisito para as empresas que querem estar sempre no
mercado, de forma ativa, sendo um ponto fundamental para concorrer com as
empresas do mesmo ramo. Tal fato também está presente no setor da tecnologia
da informação, pois um software sem qualidade pode ocasionar erros catastrófi-
cos e de grande custo de manutenção para as empresas.
Assim, a qualidade de um software está ligada aos requisitos solicitados pelo
cliente e em conformidade com as regras de desenvolvimento. A qualidade de soft-
ware pode ser definida como a conformidade a requisitos funcionais e desempenho
explicitamente declarados, assim como a padrões de desenvolvimento claramente
documentados e a características implícitas que são esperadas em todo software
profissionalmente desenvolvido. Ou seja, a qualidade de um software se refere não
só a padrões de desenvolvimento, mas também à garantia de que o produto final
satisfaça as expectativas do cliente dentro, daquilo que foi requisitado.
Para que haja garantia da qualidade do software, os processos de gerência
da qualidade são indispensáveis, sendo, a engenharia de software, a precur-
sora neste quesito no início do século XX. Seu desafio era consolidar um proces-
so que assegurasse total qualidade a seus produtos e serviços, acompanhando
a velocidade das mudanças tecnológicas, as diferentes soluções disponíveis no
mercado e a divergência de interesses nas empresas do setor.
Neste mesmo século, muitas organizações foram formadas, e diversos pa-
drões de qualidade utilizados até hoje foram desenvolvidos, sendo os padrões
formados pelo IEE (Institute of Eletrical and Eletronics Engineers), ANSI (Ameri-
can National Stantards Institute), ISO (International Stantards Organization) e o
modelo CMM (Capability Maturity Model).
Outro fato que evidencia a necessidade dos processos de gerência para a
qualidade dos softwares, é que grande parte das indústrias desse sistema es-
tão despreparadas para atender às rápidas necessidades do mercado por não
investirem no aperfeiçoamento de seus processos internos.

Não há qualquer garantia de que a solução tecnológica con-
tratada será entregue dentro do prazo e a custos negociados,
o que acarreta em um alto risco do projeto se perder no meio
do caminho. Estudos apontam que mais de 30% dos projetos
de desenvolvimento de software são cancelados antes de serem finalizados,
mais de 70% apresentam falhas na entrega das funcionalidades esperadas,
sem contar o grande número de projetos que tem seus custos iniciais extra-
polados e o alto índice de descumprimento de cronogramas iniciais.
Diante de toda a problemática explicitada, vê-se a importância de uma
gestão de processos da qualidade do software bem sedimentada. Sabe-se
que esse tipo de gestão é baseada em um conjunto de métodos e técnicas
que auxiliam a organização na gestão de seu negócio, através do conhe-
cimento e entendimento de seus processos. As organizações do setor de
tecnologia da informação buscam formalizar seus processos, representan-
do-os através de uma linguagem comum e de entendimento uniforme. A
modelagem de processos de negócio e a aplicação de normas auxiliam nes-
ta formalização, pois ajudam a organização a responder a questões críticas
sobre o seu negócio, como, o que está sendo feito, por que está sendo feito,
onde, por quem, quando e de que forma é feito.
Modelos de qualidade de software

• CMMI (Capability Maturity Model Integration):
• Práticas necessárias à maturidade do processo de desenvolvimento
de software;
• Níveis variam de 0 (inicial) até 5 (em otimização).
• MPS.BR (Melhoria de Processos do Software Brasileiro):
• Modelo voltado para a realidade do mercado de pequenas empresas
de desenvolvimento de software no Brasil;
• Baseado nas normas ISO/IEC 12207 e 15504 e compatível com o CMMI;
• Apoiado pelo Ministério de Ciência e Tecnologia, FINEP e Banco Inte-
rativo de Desenvolvimento;
• Níveis variam de A (em otimização) até G (parcialmente gerenciado).
• MPT.BR (Melhoria do Processo de Teste Brasileiro):

• Modelo para apoiar organizações por meio do desenvolvimento da
disciplina de testes;
• Baseados em diversos outros modelos, tais como CMMI e MPS.BR;
• Níveis variam de 1 (parcialmente gerenciado) até 5 (automação e oti-
mização).
Especificamente, para a melhoria de processo de software, é vista a utiliza-
ção dos modelos e normas: CMM, CMMI, ISO/IEC 12207 e ISO/IEC 15504. Estes
modelos identificam processos fundamentais para a engenharia de software.
O CMM ou SWCMM é um modelo para medição da maturidade de uma
organização, no que diz respeito ao processo de desenvolvimento e admi-
nistração de software, cujo objetivo é definir qual o nível de maturidade
da instituição e traçar os planos de ação para o desenvolvimento da or-
ganização. As características principais deste modelo estão presentes no
Quadro 1.
QUADRO 1. CARACTERÍSTICAS DO MODELO CMM.
Determinar a capacitação da organização e apoiar a sua evolução de

Objetivo
acordo com os níveis estabelecidos.
Avaliação dos processos e enquadramento da organização em um dos

Abordagem
níveis de maturidade.
Organização alvo Organizações que necessitam de comprovação formal de sua capacidade.
Neste caso, um grupo de usuários simulam operações de rotina do

Definição de processos sistema de modo a verificar se seu comportamento está de acordo
com o solicitado.
Instrumento de
Questionário.
avaliação
- Pouca consideração à diversidade das organizações;

Limitações - Dificuldade de aplicação em pequenas organizações;
- Falta abordagem de produto.
Fonte: ALMEIDA, 2005.

Este modelo é uma iniciativa do SEI (Software Engineering Institute), exis-
tente no Carnegie Mellon University, o qual busca avaliar e melhorar a capaci-
tação de empresas que produzem softwares. O projeto CMM foi apoiado pelo
Departamento de Defesa dos EUA, que é um grande consumidor de softwares
e que precisava de um modelo formal que permitisse selecionar seus fornece-
dores de software de forma adequada. Mesmo não sendo uma norma emitida
por uma instituição internacional (como a ISO ou IEE, por exemplo), este méto-
do possui alto percentual de aceitação.
A base teórica do CMM são os princípios da qualidade total (TQM – Total Qua-
lity Management), que é definida como uma abordagem de gerenciamento para
uma organização centrada na qualidade, e se baseia na participação de todos os
seus membros, visando o sucesso a longo prazo, por meio da participação do
cliente e dos benefícios para os membros da organização e da sociedade.
Neste modelo, as organizações de software são enquadradas em um dos
cinco níveis de maturidade definidos, que possuem influência nos princípios
de qualidade de produto propostos por Walter Shewhart, W. Edwards Deming,
Joseph Juran e Philip Crosby. As classificações dos níveis do CCM estão dispos-
tas no Quadro 2.
QUADRO 2. ORGANIZAÇÃO DE SOFTWARES EM NÍVEIS DE MATURIDADE.
Nível CCM Descrição
O processo de software é desorganizado, até mesmo caótico. Possui

Nível 1 - Inicial poucos processos definidos, cujo sucesso depende dos esforços indi-
viduais.
Os processos básicos de gerenciamento de projeto são determinados

Nível 2 - Repetitivo
para controlar custos, cronogramas e funcionalidade.
As atividades de gerenciamento são documentadas, padronizadas e

Nível 3 - Definido
integradas em processos padrão para a organização.
São efetuadas medições detalhadas do processo de software e quali-

Nível 4 - Gerenciado
dade do produto e controlados quantitativamente.
A melhoria contínua do processo é possibilitada pela realimentação

Nível 5 - Otimizado quantitativa do processo e conduzida a partir de ideias e novas tec-
nologias.

Conforme demonstrado no Quadro 2, uma empresa no nível 1 não dá ga-
rantia de prazo, custo ou funcionalidade. No nível 2, a empresa já consegue
produzir bons softwares no prazo e a custo previsível. O nível 3 garante um
excelente nível de qualidade, tanto no produto quanto no processo de desen-
volvimento como um todo.
Não há muitas empresas que tenham chegado aos níveis 4 e 5. Vale res-
saltar que a empresa só é certificada em um dos níveis explicitados quando
consegue atingir todos os seus objetivos, como será apresentado no Quadro 3.
Para que uma empresa possa se qualificar em um determinado nível de
maturidade CMM, deve realizar os processos relacionados às áreas-chave da-
quele determinado nível. Todas as áreas-chave, de acordo com os níveis, estão
citadas no Quadro 3.
QUADRO 3. ÁREAS-CHAVE DE ACORDO COM OS NÍVEIS DE MATURIDADE DO CMM.
Nível CMM Foco Áreas-chave do processo
Prevenção de defeitos, gerencia-

Melhoramento continuo do pro-
Nível 1 - Inicial mento de mudanças tecnológicas
cesso.
e de processo.
Qualidade do produto e do pro- Gerenciamento quantitativo do

Nível 2 - Repetitivo
cesso. processo e do software.
Foco no processo da organização,

treinamentos, gerenciamento
Nível 3 - Definido Processo de engenharia e apoio.
integrado do software, coordena-
ções entre grupos e revisões.
Gerenciamento de requisitos, pla-

nejamento e acompanhamento
Processos de gerenciamento de de projeto de software, gerencia-
Nível 4 - Gerenciado
projetos. mento de subcontratos, qualida-
de assegurada de software e o ge-
renciamento de sua configuração.
Nível 5 - Otimizado Pessoas competentes e “heróis”.

Conforme o Quadro 3, as práticas-chave (foco) descrevem as atividades
que contribuem para atingir os objetivos de cada área-chave do processo. Vale
ressaltar que as práticas-base devem descrever “o que” deve ser feito e não
“como” os objetivos devem ser atingidos.
Outra metodologia para processos
de gerência da qualidade do software
é o CMMI (Capability Maturity Model
Integration ou Modelo Integrado de
Maturidade em Capacitação) que, na
verdade, é uma evolução do modelo
CMM, porém o CMMI é um modelo cí-
clico e não em cascata como o CMM.
CMMI é uma metodologia criada
pela SEI (Software Engineering Institu-
te) para ser um guia destinado a me-
lhorar os processos organizacionais e
a habilidade desses em gerenciar o desenvolvimento, a aquisição e a manuten-
ção de produtos e serviços. O CMMI organiza as práticas que já são conside-
radas efetivas em uma estrutura que visa auxiliar a organização a estabelecer
prioridades para a melhoria e também fornece um guia para a implementação
dessas melhorias.
A versão do CMMI (versão 1.3) foi publicada em 2010 e apresenta três mo-
delos:
• CMMI for Development (CMMI-DEV), voltado ao processo de desenvolvi-
mento de produtos e serviços;
• CMMI for Acquisition (CMMI-ACQ), voltado aos processos de aquisição e
terceirização de bens e serviços;
• CMMI for Services (CMMI-SVC), voltado aos processos de empresas presta-
doras de serviços.
A metodologia CMMI foi desenvolvida com o intuito de definir um ponto ini-
cial para modelos integrados, aprimorar as melhores práticas para a criação de
modelos baseados em lições aprendidas, para estabelecer um framework que
possibilite a integração futura de novos modelos e para a criação de uma forma
associada de avaliação de desempenho e treinamento de produtos.

QUADRO 4. DIVISÃO DOS NÍVEIS DO MÉTODO CMMI.
Estágios Características
Inicial - Abordagem da metodologia;
- Gerenciamento de requisitos;
- Planejamento de projeto, monitoramento e controle de projeto;
- Gerenciamento de fornecedores;
Gerenciado
- Medição e análise;
- Garantia da qualidade do processo e do produto;
- Gerenciamento de configuração.
- Desenvolvimento de requisitos;
- Solução Técnica;
- Integração do produto;
- Verificação e validação;
- Foco no processo organizacional;
Definido
- Definição do processo organizacional;
- Treinamento organizacional;
- Gerenciamento de riscos;
- Gerenciamento integrado do projeto;
- Análise da decisão e resolução.
- Gerenciamento quantitativo do projeto;

Quantitativamente - Performance do processo organizacional.
- Análise causal e resolução;

Otimização
- Inovação organizacional e implantação.
Para a implementação da metodologia CMMI na organização, o primeiro

passo é a identificação por meio de um método definido pelo SEI (SCAMPI –
SEI Members of the Assessment Method Integrated Team) e conduzido por um
avaliador credenciado do estágio em que a empresa se encontra no presente
momento, conforme os pressupostos do Quadro 4.
Após a verificação do estágio da empresa, verifica-se qual a próxima etapa
a ser alcançada e quais as competências que devem ser adquiridas neste pro-
cesso. Esta fase é importante, pois permite alcançar o sucesso e, consequente-
mente, a melhoria na qualidade dos serviços e produtos fornecidos pela área
de tecnologia da empresa.
Para assegurar a qualidade do software, existem as normas que auxiliam na
gestão dos mesmos, sendo elas a NBR ISO/IEC 12207 e a NBR ISO/IEC 15504. A

norma internacional NBR ISO/IEC 12207 – Tecnologia da Informação – Proces-
sos de Ciclo de Vida de Software (ISO12207:97) é usada como referência em
muitos países, inclusive no Brasil.
A norma NBR ISSO/IEC 12207 tem por objetivo auxiliar os envol-
vidos na produção de software a definir seus papéis, por meio
de processos bem definidos, e assim proporcionar às organiza-
ções que a utilizam um melhor entendimento das atividades a
serem executadas nas operações que envolvem, de alguma for-
ma, o software. (MACHADO, 2003, p. 07).
Essa norma define que os processos que envolvem o ciclo de vida do soft-
ware devem ser baseados em quatro classes: os processos fundamentais; os
de apoio; os organizacionais; e os processos de adaptação.
Processos fundamentais: atendem à contratação entre o adquirente e o
fornecedor e o desenvolvimento do software em si (operação ou manutenção
de produtos de software durante o ciclo de vida do mesmo).
Processos de apoio: auxiliam e contribuem para o sucesso e a qualida-
de do projeto de software, o qual é empregado e executado, quando ne-
cessário, para documentação, gerência de configuração, garantia da qua-
lidade, processo de verificação, processo de validação, revisão conjunta,
auditoria e resolução de problemas.
Processos organizacionais: são empregados por uma organização
para estabelecer uma estrutura constituída pelos processos de ciclo de
vida e pelas pessoas envolvidas no desenvolvimento do software. Esses
processos organizacionais (processos de gerência, infraestrutura, melho-
ria e treinamento) são geralmente empregados fora do domínio de pro-
jetos e contratos específicos, entretanto, os mesmos contribuem para a
melhoria da organização.
Processos de adaptação: definem as atividades necessárias para adaptar a
norma para sua aplicação na organização ou em projetos, e devem ser executa-
das com base em alguns fatores que diferenciam uma organização das outras
nos pontos de estratégia de aquisição, modelos de ciclo de vida de projeto, ca-
racterísticas de sistemas e cultura organizacional. A existência desse processo
permite que a norma seja adaptável a qualquer projeto, organização, modelo
de ciclo de vida, cultura e técnica de desenvolvimento.

A NBR ISO/IEC 15504, também conhecida como Spice, é um modelo que
possui como foco a melhoria dos processos de desenvolvimento de softwa-
re e a determinação da capacidade de processos de uma organização. A sua
existência justificou-se em função de estudos que comprovaram que a grande
maioria dos projetos de software não atendem aos objetivos traçados. Essa
norma define seis níveis de capacidade – sequenciais e cumulativos – que po-
dem ser utilizados para avaliar como uma organização está realizando um
determinado processo e também podem ser utilizados como um guia para a
melhoria. Os seis níveis de capacidade e suas respectivas caracterizações são:
Nível 0 (incompleto): há uma falha geral na satisfação do propósito do pro-
cesso. Existem poucos produtos de trabalho ou resultados dos processos.
Nível 1 (executado): o propósito do processo é alcançado, pois existe uma
concordância geral e informal de que esta ação deve ser executada e de quan-
do isto deve ser feito.
Nível 2 (gerenciado): o processo realizado descrito no Nível 1 agora é imple-
mentado de forma administrativa (planejado, monitorado e ajustado) e seus pro-
dutos do trabalho são adequadamente estabelecidos, controlados e mantidos.
Nível 3 (estabelecido): o processo é executado e gerenciado, utilizando um
processo padrão, baseado em princípios de uma boa engenharia de software.
Esse processo usa uma versão customizada e aprovada de um processo pa-
drão documentado para satisfazer os resultados definidos do processo. A prin-
cipal diferença em relação ao nível gerenciado é que há um processo padrão
capaz de atingir seus resultados definidos.
Nível 4 (previsível): nesse nível, o processo definido é executado consis-
tentemente na prática, dentro de limites de controle definidos, para atingir as
metas definidas do processo. Medições detalhadas de desempenho são cole-
tadas e analisadas, levando a um entendimento quantitativo da capacidade
do processo e uma melhora na habilidade para prever e gerenciar a execução.
Nível 5 (em otimização): neste caso, o desempenho do processo é continua-
mente melhorado para satisfazer objetivos correntes e futuros de negócio. Nes-
te nível, os objetivos quantitativos de eficiência e eficácia para o desempenho do
processo são estabelecidos, baseados nos objetivos de negócio da organização.
Um acompanhamento contínuo do processo é estabelecido pela obtenção de rea-
limentações quantitativas e a melhoria é obtida a partir da análise dos resultados.

Estabelecer normas e métodos para processos da qualidade do software
permite que haja uma padronização dos processos de desenvolvimento, au-
mentando a aderência a uma ferramenta de apoio à modelagem do software,
agregando facilidades de relacionamento e compreensão do usuário e do de-
senvolvedor, utilizando métodos sistêmicos. Isso vai diminuir os erros na mo-
delagem, o que evitará a manutenção exagerada, eliminando custos indevidos
e o tempo dedicado ao retrabalho.
Melhorias de processo
Um produto com qualidade é uma necessidade, uma vez que, desde o levan-
tamento de requisitos até a fase de desenvolvimento, os fatores que atendem
às necessidades do cliente devem estar em evidência, bem como o feedback
para melhoria contínua dos processos.
Com o objetivo de padronizar e aprimorar a avaliação da qualidade de
produtos de software, surgiu a Norma ISO/IEC 9126 desenvolvida em conjunto
com a ISO e IEC. Segundo a norma ISO/IEC 9126, a definição para avaliação de
produto de software refere-se à medição de quanto o produto de software, em
uso, atende às necessidades implícitas e explícitas.
Essa norma abrange os modelos de qualidade que um software deve seguir,
incluindo métricas externas, internas e qualidades de uso. Em outras palavras,
essa norma define um conjunto de parâmetros com o objetivo de padronizar a
avaliação da qualidade de software. Ela se enquadra no modelo de qualidade
das normas da família 9000. A norma brasileira correspondente é a NBR 13596,
que foi substituída pela NBR ISO/IEC 9126-1.
CONTEXTUALIZANDO
Para entender a importância de aplicar um conjunto de
parâmetros para a qualidade de software, confira uma
matéria sobre a Google, que decidiu mudar o processo de
revisão de aplicativos, buscando melhoria nos processos.
A norma ISO/IEC 9126, publicada em 1991, propõe um modelo de padro-

nização de qualidade de um produto de software. Segundo a Associação
Brasileira de Normas Técnicas (ABNT), a ISO/IEC 9126 permite que a qua-

lidade do produto de software seja especificada e avaliada em diferen-
tes perspectivas pelos envolvidos, por meio de etapas como: aquisição,
requisitos, desenvolvimento, uso, avaliação, apoio, manutenção, garantia
de qualidade e auditoria de software. Ela foca na qualidade do produto
de software, propondo atributos de qualidade distribuídos emseis cate-
gorias principais de avaliação: funcionalidade, confiabilidade, usabilidade,
eficiência, manutenibilidade e portabilidade.
Funcionalidade: diz respeito à possibilidade de o software responder
às necessidades do usuário. Suas subcategorias são: adequação, precisão,
interoperabilidade e segurança.
Confiabilidade: avalia se o software é imune a falhas. Suas subcatego-
rias são: maturidade, tolerância a falhas e recuperabilidade.
Usabilidade: faz referência à facilidade em usar o software. Suas sub-
categorias são: inteligibilidade, operacionalidade e atratividade.
Eficiência: avalia o desempenho do software em relação ao tempo e
aos recursos. Suas subcategorias são: comportamento em relação ao tem-
po e utilização de recursos.
Manutenibilidade: tem a ver com os processos de mudanças e adaptação.
Portabilidade: está relacionada com a mobilidade e a responsividade
do software. Suas subcategorias são: analisabilidade, modificabilidade, es-
tabilidade e testabilidade.
QUADRO 5. CARACTERÍSTICAS E SUBCARACTERÍSTICAS DA NORMA.
Características Subcaracterísticas Atributos Relevância
Atributos de software que evidenciam

a presença de um conjunto de funções
Adequação
e sua apropriação para as tarefas expli-
cadas.
Há atributos que evidenciam a geração de

Acurácia
resultados ou efeitos corretos abordados?
Funcionalidade Alta
Há a capacidade do software interagir
Interoperabilidade
com sistemas especificados?
O software tem atributos que fazem com

que ele esteja de acordo com as normas,
Conformidade convenções ou regulamentações pre-
vistas em leis e similares, relacionadas à
aplicação?

Características Subcaracterísticas Atributos Relevância
Maturidade Com que frequência apresenta falhas? Alta
Tolerância a falhas Ocorrendo falhas, como ele reage? Alta
Confiabilidade
É capaz de recuperar dados após uma
Recuperabilidade Média
falha?
Está de acordo com os padrões, normas

Conformidade Alta
relacionadas à confiabilidade?
É fácil encontrar uma falha, quando

Analisabilidade
ocorre?
Alta
Modificabilidade É fácil modificar e remover defeitos?
Existe risco de efeitos inesperados quan-

Portabilidade Estabilidade Média
do se faz alterações?
Está de acordo com as normas, e leis

Conformidade Alta
relacionadas à manutenibilidade?
Testabilidade É fácil testar o software modificado? Alta
Qual é o tempo de resposta e de proces-

Relação ao tempo
samento?
Quanto recurso usa? Durante quanto

Relação aos recursos
Eficiência tempo? Alta
Está de acordo com as normas, e leis

Conformidade relacionadas à eficiência?
Integridade O programa é seguro? Alta
Segurança Dados preservados Dados críticos e sigilosos preservados? Alta
Há controle do acesso ao sistema ou aos

Autenticação de acesso Alta
seus dados por pessoas não autorizadas?
Há como modificar o software ou

Modificabilidade Média
remover seus defeitos?
Há risco de efeitos inesperados ocasio-

Manutenibilidade Estabilidade
nados por modificações?
Alta
Testabilidade É fácil testar o software modificado?

Essa norma foi substituída pela ISO/IEC 5010, disponibilizada em 2011,
que adicionou as características que todos os softwares devem ter, de
forma a alcançar um nível muito alto de qualidade no software que será
entregue. Ela compreende oito características de qualidade: segurança,
compatibilidade e as seis características vistas na ISO/IEC 9126:
• Segurança:
- Controle do acesso ao sistema ou aos seus dados por pessoas não
autorizadas;
- Ausência de fraudes;
- Dados críticos e sigilosos preservados;
- Baixa probabilidade de invasão por hackers;
- Identificação dos responsáveis por cada transação realizada.
• Compatibilidade: para um software ser completo e eficaz, deve con-
ter elementos básicos e devem ser os mais compatíveis possíveis:
- Política e objetivos;
- Responsabilidades definidas;
- Sistemas documentados;
- Controle de documentos;
- Auditorias internas;
- Controle de processos críticos.
Além disso, a ISO/IEC 25010 também define:
1. Um modelo de qualidade de uso composto por cinco características
(algumas divididas em subcaracterísticas) relacionadas ao resultado da inte-
ração, quando um produto é usado em um contexto de uso específico. Esse
modelo de sistema é aplicável ao sistema humano-computador completo,
incluindo sistemas de computador em uso e produtos de software em uso.
2. Um modelo de qualidade do produto composto por oito características
(que são divididas em subcaracterísticas) relacionadas às propriedades está-
ticas do software e às propriedades dinâmicas do sistema de computador. O
modelo é aplicável a sistemas de computador e produtos de software.
As características definidas pelos dois modelos são relevantes para to-
dos os produtos de software e para todos os sistemas de computador.
As características e subcaracterísticas fornecem terminologia consistente
para especificar, medir e avaliar a qualidade do sistema e do produto de

software. Elas também fornecem um conjunto de características de quali-
dade com as quais os requisitos de qualidade declarados podem ser com-
parados quanto à integridade.
Embora o escopo do modelo de qualidade do produto seja destinado
a sistemas de software e computador, muitas das características também
são relevantes para sistemas e serviços mais amplos.
A ISO/IEC 25012 contém um modelo de qualidade de dados que é com-
plementar a esse modelo. O escopo dos modelos exclui propriedades pu-
ramente funcionais, mas inclui adequação funcional.
O escopo de aplicação dos modelos de qualidade inclui suporte à espe-
cificação e avaliação de software e sistemas de computador. Isso é reali-
zado através do uso intensivo de software sob diferentes perspectivas as-
sociadas à aquisição, requisitos, desenvolvimento, uso, avaliação, suporte,
manutenção, garantia e controle de qualidade e auditoria.
Os modelos podem, por exemplo, ser usados por desenvolvedores, ad-
quirentes, equipe de garantia e controle de qualidade e avaliadores inde-
pendentes (geralmente os responsáveis por especificar e avaliar a qualida-
de do produto de software). As atividades de desenvolvimento do produto
que podem se beneficiar do uso dos modelos de qualidade incluem:
• Identificação de requisitos de software e sistema;
• Validação da abrangência de uma definição de requisitos;
• Identificação de objetivos de design de software e sistema;
• Identificação de objetivos de teste de software e sistema;
• Identificação dos critérios de controle de qualidade como parte da
garantia da qualidade;
• Identificação dos critérios de aceitação para um produto de software
e/ou sistema de computador com uso intensivo de software;
• Estabelecimento de medidas de características de qualidade em apoio
a essas atividades.
Em relação a aplicabilidade, temos que pensar no quão importante é ter-
mos um software com qualidade abrangendo aspectos de confiabilidade.
Atualmente, a melhoria da qualidade do software tornou-se cada vez
mais comum nas organizações devido à necessidade de obtenção de me-
lhores resultados em todas as fases do ciclo de vida do software. A quali-

dade é geralmente transparente quando presente, mas a sua ausência é
facilmente percebida.
Alguns aspectos da qualidade podem ser medidos, com maior ou me-
nor facilidade. No entanto, o critério mais facilmente medido pode não
ser necessariamente o mais importante. A aceitação de um produto pode
depender de critérios que muitas vezes são difíceis de definir, envolvendo
compromissos e aceitações.
Melhoria no processo de desenvolvimento de web app

As tecnologias para o desenvolvimento web evoluem constantemente, per-
mitindo a construção de conteúdos cada vez mais diversificados, o que contri-
bui para o aumento constante na quantidade de pessoas que acessam a rede
todos os dias. Por isso, precisamos garantir a qualidade de interação, que con-
siste em um desafio a mais no projeto e desenvolvimento de websites.
A legislação determina que todos os cidadãos têm direito de acesso igua-
litário às informações, sendo assim, a acessibilidade é um ponto importante
de qualidade de um web app.
O desenvolvimento de aplicativos web não se limita apenas aos smartphones
ou tablets: este tipo de aplicativo é projetado para rodar em qualquer navega-
dor, seja em computadores fixos, laptops ou dispositivos móveis. Primeiramen-
te, vamos definir alguns requisitos básicos que um web app deve apresentar:
• Um desenvolvimento exclusivo: não importa o sistema operacional, o
mesmo desenvolvimento em HTML5 serve para todos os sistemas operacio-
nais existentes;
• Acessível a partir de qualquer navegador da web: seja Firefox, Safari,
Google Chrome etc. Podemos acessar um aplicativo da web desde qualquer
navegador que temos instalado no nosso dispositivo. Você pode acessar o
conteúdo tanto de um computador móvel, quanto de um tradicional.
• Aparece nos motores de busca tradicionais: aplicativos da web podem
ser encontrados em qualquer motor de busca do Google ou Yahoo.
O desenvolvimento de um web app ocorre através de tecnologias especifi -
cas para este fim. Sendo assim, o profissional responsável deve dominar bem
essas tecnologias para entregar, de fato, o que se espera do produto.

Para garantir a qualidade de um web app, os desenvolvedores podem (e
devem) considerar as normas ISO que já abordamos nesta unidade. A ISO
publicou mais de 13.700 normas internacionais, dos mais diversos setores e
aplicações, desde atividades tradicionais, como agricultura e construção, pas-
sando por engenharia mecânica, dispositivos médicos até o desenvolvimento
da mais nova tecnologia da informação.
Podemos dizer que as normas da ISO são ligadas à normalização de pa-
drões de gestão, com alta repercussão econômica e social, tendo impacto não
somente no setor de produção de bens tangíveis, mas também na área de
serviços, contribuindo para a sociedade como um todo, principalmente nos
aspectos de segurança e atendimento às exigências legais.
Entre as principais orientações contidas nas normas estudadas, o desen-
volvedor de web app deve focar-se, principalmente, em três características
delas: compatibilidade, manutenibilidade e acessibilidade. Ou seja, é preciso
garantir que o web app ofereça as seguintes características, para ser consi-
derado um produto bem-sucedido:
• Ser compatível com as mais diversas plataformas;
• Ter fácil manutenção e modificação, para ser aperfeiçoado com o passar
dos anos, o que implica que ele acompanhe os avanços tecnológicos;
• Ter interface funcional, amigável e agradável, garantindo a acessibilidade.
ASSISTA
Confira o vídeo #CPBSB2 - Progressive web apps - A revo-
lução no desenvolvimento web, que aborda um dos mais
interessantes conceitos disponíveis e relevantes, quando
falamos do desenvolvimento de web apps: o PWA.
MPS.BR – Melhoria do Processo de Software Brasileiro

MPS.BR – sigla de Melhoria do Processo de Software Brasileiro – é um guia
de implementação de serviços que fornece orientações para implementar, nas
organizações, os níveis de maturidade descritos no Modelo de Referência de
Serviços (MR-MPS-SV), detalhando os processos contemplados nos respectivos
níveis de maturidade, e os resultados esperados com a implementação dos
processos. Isto inclui atividades relacionadas à análise dos requisitos, desen-

volvimento do projeto (design), desenvolvimento do serviço, integração dos
diversos componentes, verificação e validação.
Entre os componentes do MPR.BR, temos:
• Guia Geral de Serviços: contém a descrição geral dos modelos MPS e de-
talha o Modelo de Referência de Serviços (MR-MPS-SV), seus componentes e as
definições comuns necessárias para seu entendimento e aplicação;
• Guias de Implementação de Software: série de 13 documentos que for-
necem orientações para implementar os níveis de maturidade descritos no
modelo de referência MR-MPS-SW.
DICA
Confira um resumo descritivo dessas regras de negócio no portal Softex,
disponível em: www.softex.br/mpsbr/.
O MPS.BR é um modelo de melhoria e avaliação de software voltado para

empresas de micro, pequeno e médio porte. O MPS.BR apresenta-se dividido
em três componentes importantes, que são:
• Modelo de Referência (MR-MPS);
• Método de Avaliação (MA-MPS);
• Modelo de Negócio (MN-MPS).
Esses componentes são definidos como guias ou documentos do MPS.BR.
DIAGRAMA 1. COMPONENTES DO MPS.BR.
Modelo MPS
ISO/IEC ISO/IEC
CMMI-DEV
12207 15504
Modelo de referência Método de avaliação Modelo de negócio

(MR-MPS) (MA-MPS) (MN-MPS)
Guia geral Guia de aquisição Documentos

Guia de avaliação
do programa
Guia de implementação
Fonte: Softex, [s.d]. Acesso em: 25/11/2019. (Adaptado)

Modelo de Referência MR-MPS: contém os requisitos que os processos
das unidades organizacionais devem atender para estar em conformidade com
o MR-MPS. Ele contém as definições dos níveis de maturidade, processos e atri-
butos do processo, e está descrito neste Guia Geral, em conformidade com os
requisitos de modelos de referência de processo da norma ISO/IEC 15504-2.
Guia de Aquisição: é um documento complementar destinado a organiza-
ções que pretendam adquirir software e serviços correlatos. O Guia de Aquisi-
ção não contém requisitos do MR-MPS, mas boas práticas para a aquisição de
software e serviços correlatos.
Guia de Implementação: composto de 7 partes que descrevem como im-
plementar cada um dos níveis do MR-MPS.
Guia de Avaliação: contém o processo e o método de avaliação MA-MPS,
os requisitos para os avaliadores líderes, avaliadores adjuntos e Instituições
Avaliadoras (IA). O processo e o método de avaliação MA-MPS também estão
em conformidade com a norma ISO/IEC 15504-2.
Modelo de Negócio MN-MPS: descreve regras de negócio para implemen-
tação do MR-MPS pelas Instituições Implementadoras (II), avaliação seguindo
o MA-MPS pelas Instituições Avaliadoras (IA), organização de grupos de em-
presas para implementação do MR-MPS e avaliação MA-MPS pelas Instituições
Organizadoras de Grupos de Empresas (IOGE), certificação de consultores de
aquisição e programas anuais de treinamento por meio de cursos, provas e
workshops MPS.BR.
Os níveis de maturidade estabelecem patamares de evolução de proces-
sos, caracterizando estágios de melhoria da implementação de processos na
organização.
O nível de maturidade em que se encontra uma organização permite pre-
ver o seu desempenho futuro ao executar um ou mais processos. O MR-MPS
define sete níveis de maturidade: A (em otimização), B (gerenciado quantita-
tivamente), C (definido), D (largamente definido), E (parcialmente definido), F
(gerenciado) e G (parcialmente gerenciado). A escala de maturidade se inicia no
nível G e progride até o nível A. Para cada um destes sete níveis de maturidade
é atribuído um perfil de processos que indica onde a organização deve colocar
o esforço de melhoria. O progresso e o alcance de um determinado nível de
maturidade do MR-MPS se obtêm quando são atendidos os propósitos e todos

os resultados esperados dos respectivos processos e dos atributos de proces-
so estabelecidos para aquele nível.
A divisão em estágios, embora baseada nos níveis de maturidade do CMMI-
-DEVSM, tem uma graduação diferente, com o objetivo de possibilitar uma im-
plementação e avaliação mais adequada às micros, pequenas e médias empre-
sas. A possibilidade de se realizar avaliações considerando mais níveis também
permite uma visibilidade dos resultados de melhoria de processos em prazos
mais curtos. No Quadro 6 é possível visualizar os níveis e seus processos.
QUADRO 6. NÍVEL DE MATURIDADE E SEUS PROCESSOS.
Nível de maturidade Processos
A Análise de causas de problemas e resolução.
B Gerência de projetos (evolução).
- Gerência de riscos;
- Desenvolvimento para reutilização;
C
- Análise de decisão e resolução;
- Gerência de reutilização.
- Verificação;
- Validação;
D - Projeto e construção do produto;
- Integração do produto;
- Desenvolvimento de requisitos.
- Gerência de projetos (evolução);

- Gerência de reutilização;
E - Gerência de recursos humanos;
- Definição do processo organizacional;
- Avaliação e melhoria do processo organizacional.
- Medição;
- Garantia de qualidade;
F - Gerência de configuração;
- Gerência de portifólio de projeto;
- Aquisição.
- Gerência de requisitos;
G
- Gerência de projetos.
Fonte: Softex,, [s.d]. Acesso em: 25/11/2019. (Adaptado)
Capacidade do processo
A capacidade do processo é representada por um conjunto de atributos
de processo descrito em termos de resultados esperados. A capacidade do
processo expressa o grau de refinamento e institucionalização com que o
processo é executado na organização/unidade organizacional. No MPS, à
medida que a organização/unidade organizacional evolui nos níveis de ma-

turidade, um maior nível de capacidade para desempenhar o processo deve
ser atingido pela organização. O atendimento aos atributos do processo (AP),
pelo atendimento aos resultados esperados dos atributos do processo (RAP)
é requerido para todos os processos no nível correspondente ao nível de ma-
turidade, embora eles não sejam detalhados dentro de cada processo.
Os níveis são acumulativos, ou seja, se a organização está no nível F, esta
possui o nível de capacidade do nível F que inclui os atributos de processo dos
níveis G e F para todos os processos relacionados no nível de maturidade F
(que também inclui os processos de nível G). Isto significa que, ao passar do
nível G para o nível F, os processos do nível de maturidade G passam a ser
executados no nível de capacidade correspondente ao nível F.
Diante da necessidade das organizações em melhorar a qualidade do processo
de software, o desafio é a utilização de uma metodologia para a implantação de
melhorias em processos de software que seja vinculada ao uso de ferramentas
específicas, com o objetivo de potencializar os resultados da implantação e obter
maior comprometimento com a evolução da maturidade da organização. A utili-
zação do modelo MPS.BR é vista como um alicerce para tal metodologia, porque
representa um modelo voltado à realidade brasileira e compatível com normas
internacionais, além de ser amplamente aceito pela indústria e academia.
Para colher os benefícios esperados com o programa MPS.BR deve haver a
conscientização da organização em adotar a melhoria de processos de softwa-
re como uma estratégia, treinando os seus gerentes e colaboradores e criando
um ambiente favorável.
Casos de sucesso na implantação de melhoria de processo

Segundo a Softex (2016), o MPS.BR é um programa com atenção espe-
cial às menores empresas, que constituem uma grande parte dos casos de
sucesso do modelo. Atualmente, existem no Brasil cerca de 650 certificações
concedidas a empresas que adotaram o programa MPS.BR. Alguns exemplos são
relacionados abaixo:
• A primeira empresa da região Sul a conquistar a certificação MPS.BR, foi a
Kenta, em 2006, que foi contemplada com a certificação de nível G obtendo suces-
so em seus processos e alcançando o próximo nível de maturidade (F) em 2008.

• A primeira empresa brasileira a conquistar o nível de maturidade C, foi
a Powerlogic, baseando seus processos em métodos ágeis (Scrum) em 2010.
• A empresa PD Case iniciou sua trajetória de certificação na MPS.BR com o
nível F, alcançado em 2007. A organização conseguiu otimizar seus processos
em três anos e alcançou o nível C em 2010, sendo esse renovado em 2014.
• A empresa Consult Brasil obteve sucesso na avaliação de processos, al-
cançando o Nível G de maturidade em junho de 2007.
• A empresa Teknisa Software alcançou o Nível G em maio de 2007, subin-
do de nível em 2009.
• A empresa ZCR obteve a certificação MPS de Nível C em novembro de
2013 sendo a primeira empresa baiana a conquistar tal certificação.
• A empresa DB1 Global Software obteve sucesso em seus projetos, alcan-
çando o nível A de maturidade MPS.BR em 2015.
• A empresa ATS Informática, em 2008, iniciou os os trabalhos para certi-
ficação no nível G de maturidade e em 2009 obteve êxito em todo o trabalho,
recebendo a certificação G. O nível F foi alcançado em 2011.
Os resultados da implantação do MPS.BR são, de longe, os mais benéficos
buscados por uma empresa para que seja alcançado uma gama de clientes
mais satisfeitos com seus projetos, mesmo porque os benefícios são notó-
rios a curto e longo prazo. Entre todos os benefícios, pode-se listar os mais
buscados: melhoria na produtividade, no grau de satisfação dos clientes, nas
estimativas de prazo e no faturamento.
Uma empresa com certificação de qualidade é mais visada pelos atuais e
futuros clientes e também pelos seus concorrentes, fazendo com que a dispu-
ta entre empresas fique mais acirrada.

Sintetizando
Nesta unidade, aprendemos o quanto os processos de gerência da qualida-
de do software são importantes quando falamos de desenvolvimento de um
software e como a falta do gerenciamento adequado afeta as empresas. Esses
processos servem para evitar problemas recorrentes no desenvolvimento de
software, que podem se tornar grandes problemas em fases mais avançadas
do processo de desenvolvimento, além disso, permitem melhor controle do
desenvolvimento do produto.
No segundo tópico, tivemos uma introdução sobre melhorias de processos
de desenvolvimento, como melhorar os processos ou eliminar processos que
não tem sentido.
E, para finalizar, falamos sobre as MPR.BR (Melhoria de Processos de Soft-
ware Brasileiro), um guia que busca melhoria de seus processos de serviços e
a instituições implementadoras, evitando que o trabalho seja refeito por conta
de atividades malfeitas ou incorretas, buscando garantir a melhoria no proces-
so e na qualidade de software.

#CPBSB2 - PROGRESSIVE WEB APPS - A revolução no desenvolvimento web.
Postado por Campus Party. (47 min. 08s.). son. color. port. Disponível em: <ht-
tps://youtu.be/ZwnA5JLr_YE>. Acesso em: 25 nov. 2019.
ABNT CATÁLOGO. ISO/IEC 15504. Disponível em: <https://www.abntcatalogo.
com.br/curs.aspx?ID=63>. Acesso em: 22 nov. 2019.
ABNT CATÁLOGO. ABNT NBR ISO/IEC 9126-1:2003. Disponível em: <https://
www.abntcatalogo.com.br/norma.aspx?ID=002815>. Acesso em: 22 nov. 2019.
ABNT CATÁLOGO. ISO/IEC 25010:2011. Disponível em: <https://www.abntcata-
logo.com.br/norma.aspx?ID=86628>. Acesso em: 22 nov. 2019.
ALMEIDA, K. As características do CMM e o desenvolvimento de software com
qualidade. Revista eletrônica de administração. Ed. 8, jun. 2005.
BARTIÉ, A. Garantia da qualidade do software: Adquirindo maturidade organi-
zacional. Rio de Janeiro: Elsevier, 2002.
BDPA. NBR 13596: tecnologia de informação - avaliação de produto de software-
características de qualidade e diretrizes para o seu uso. Disponível em: <https://
www.bdpa.cnptia.embrapa.br/>. Acesso em: 27 nov. 2019.
CRESPO, A. N.; SILVA, O. J.; BORGES, C. A.; SALVIANO, C. F. S.; TEIVE, M.; JUNIOR,
A. J.; JINO, M. Uma metodologia para teste de software no contexto da me-
lhoria de processo. Disponível em: <https://www.researchgate.net/publica-
tion/237497188/_Uma_Metodologia_para_Teste_de_Software_no_Contexto_
da_Melhoria_de_Processo>. Acesso em 27/11/2019.
DEVMEDIA. CMMI (Capability Maturity Model Integration). Disponível em:
<https://www.devmedia.com.br/cmmi-capability-maturity-model-integra-
tion/3530>. Acesso em: 01 set. 2019.
FELIPE, P. F. C.M.M.I. e Spice: um estudo comparativo na abordagem da engenha-
ria de requisitos. 2006. Monografia (Pós-graduação em Engenharia de Software)
– Universidade São Judas Tadeu, São Paulo, 2006. . Disponível em <www.cin.ufpe.
br/~pmr/qualidade/Monografia.pdf>. Acesso em: 01 set. 2019. 94f.
FILHO, W. P. P. Engenharia de software: fundamentos, métodos e padrões. Rio
de Janeiro: LTC, 2009.
FIORINI, S. Engenharia de Software com CMM, Rio de Janeiro: Brasport, 1998.
FUMSOFT. Empresa mineira é certificada no modelo MPS.BR (2015). Disponí-

vel em: <http://www.fumsoft.org.br/noticias/empresa-mineira-e-certificada-no-
-modelo-mps-br>. Acesso em: 25 nov. de 2019.
IAHN, A. Avaliação de processos de software utilizando a norma ISO/IEC
15504. 1999. 53 f. TCC (Bacharelado em Ciências da Computação) – Centro de
Ciências Exatas e Naturais, Universidade de Blumenau, Blumenau, 1999. Dis-
ponível em: <http://campeche.inf.furb.br/tccs/1999-I/1999-1anisioiahnvf.pdf>.
Acesso em: 01 set. 2019.
MACHADO, C. A. F. Definindo Processos do Ciclo de Vida de Software usando
a Norma ISO/IEC 12207. Lavras: UFLA/FAEPE, 2003.
NBR ISO/IEC 12207:1997, Tecnologia de Informação – Processos de Ciclo de Vida
de Software, Rio de Janeiro, ABNT. [s.d].
NOGUEIRA, M. Qual a importância da adoção da norma ISSO 12207 nas em-
presas de desenvolvimento de software. Disponível em: <https://www.resear-
chgate.net/publication/291147146_QUAL_A_IMPORTANCIA_DA_ADOCAO_DA_
NORMA_ISO_12207_NAS_EMPRESAS_DE_DESENVOLVIMENTO_DE_SOFTWARE>.
Acesso em: 01set. 2019.
OLHAR DIGITAL. Google muda seu processo de revisão de aplicativos depois
de ataque de pishing. Disponível em: <https://olhardigital.com.br/fique_segu-
ro/noticia/google-muda-seu-processo-de-revisao-de-aplicativos-depois-de-ata-
que-de-phishing/68248> Acesso em: 25 nov. 2019.
OLIVEIRA, M. N.; IREMAR, N. O. Processo de desenvolvimento de software de
acordo com a norma ISSO/IEC 15504. Pós em Revista, Ed. 5, jun. 2012.
PRESSMAN, R. S. Engenharia de software. São Paulo: Makron Books,1995.
SOMMERVILLE, I. Engenharia de software. São Paulo: Pearson Addison Wesley,
2003.
RUGGIERI R. Análise sobre a ISSO 9126 – NBR 13596. TI Especialistas, [s.l.], 24
out. 2016. Disponível em: <https://www.tiespecialistas.com.br/analise-sobre-iso-
-9126-nbr-13596/>. Acesso em: 22 nov. 2019.

TESTE DE
SOFTWARE
(LIVRO 3)
Autoria Ana Luiza Cerchiari de Andrade
Jailson Costa dos Santos
DADOS DO FORNECEDOR
A violação dos direitos autorais é crime estabelecido pela Lei n.º 9.610/98 e punido pelo
artigo 184 do Código Penal.
SER_COD_TESOFT_UNID1.indd 2 11/02/2020 17:21:03

Boxes
ASSISTA
CITANDO
CONTEXTUALIZANDO
CURIOSIDADE
tratado.
DICA
EXEMPLIFICANDO
EXPLICANDO

Sumário
Unidade 1 - Aspectos introdutórios do teste de software

Fundamentos de teste de software.................................................................................... 14
Desenvolvimento de software e teste de software........................................................ 24
Níveis de teste....................................................................................................................... 32
Teste de desenvolvimento.............................................................................................. 32
Teste unitário..................................................................................................................... 32
Teste de componentes.................................................................................................... 34
Teste de sistema............................................................................................................... 36
Teste de release............................................................................................................... 37
Testes baseados em requisitos...................................................................................... 37
Teste de cenário............................................................................................................... 38
Testes de desempenho.................................................................................................... 39
Teste de usuário............................................................................................................... 40
Sintetizando............................................................................................................................ 44

Sumário
Unidade 2 - Classificação de teste de software

Técnicas de teste de software........................................................................................... 48

Técnicas de teste de software caixa-preta................................................................. 49
Técnicas de teste de software caixa-branca.............................................................. 50
Tipos de teste de software.................................................................................................. 54

Exemplos de testes de tipos de software..................................................................... 58
Testes automáticos de software na prática..................................................................... 59

Noções de Java................................................................................................................ 59
Teste de cálculos com assertEquals. ........................................................................... 61
Teste de cálculos com assertTrue. ............................................................................... 66
Sobre asserts e sobre as anotações jUnits................................................................. 68
Sintetizando............................................................................................................................ 70

Sumário
Unidade 3 – Casos de testes: conceitos fundamentais

Extração de casos de teste................................................................................................. 74

Regras de extração de casos de teste......................................................................... 74
Exemplos de extração de casos de teste..................................................................... 77
Criando casos de teste......................................................................................................... 81

Geração de casos de testes do tipo caixa-preta........................................................ 83
Geração de casos de testes automática...................................................................... 84
Geração de casos de testes em tarefas....................................................................... 86
Automação de testes............................................................................................................ 87
Testes automatizados...................................................................................................... 87
Principais ferramentas de automação de testes........................................................ 88
Desafios benéficos da automação de testes.............................................................. 90
Gerenciamento de defeitos................................................................................................. 91
Processo de gestão de defeitos.................................................................................... 92
Ciclo de vida de um defeito............................................................................................. 93
Relatório de defeitos. ...................................................................................................... 94
Sintetizando............................................................................................................................ 97

Sumário
Unidade 4 - Medidas, gerenciamento e execução de testes de software
Objetivos da unidade.......................................................................................................... 100
Métricas para o teste de software................................................................................... 101

Métricas de profundidade, de quantidade e de severidade................................... 102
Métricas básicas e profundas..................................................................................... 104
Métricas relacionadas ao software............................................................................ 105
Ferramentas de suporte ao teste...................................................................................... 107

Ferramentas de suporte ao teste: primeiro teste...................................................... 108
Estratégia de teste e abordagem de teste................................................................. 111
Ferramentas de suporte ao teste: segundo teste..................................................... 112
Gerenciamento de teste de software.............................................................................. 115

Ferramentas de suporte ao gerenciamento de teste de software........................ 116
Planejamento e estimativa de teste............................................................................ 118
Sintetizando.......................................................................................................................... 125

Apresentação
Convidamos vocês, leitoras e leitores, a nos acompanhar e compreender

sobre a importância de testes de software, entrando em contato com conceitos
e fundamentos essenciais relacionados ao tema. Demonstraremos, na unidade
inicial, como são abordados e implantados os fundamentos do teste de soft-
ware, as etapas do processo de desenvolvimento e sua importância dentro da
área de tecnologia. Trataremos das conceituações referentes aos níveis de tes-
te, utilizados para conduzir e projetar testes em produtos de software.
Vamos explorar, também, ao longo da unidade, conceitos importantes rela-
cionados aos tipos de teste, seus principais aspectos relacionados a integração,
desempenho, configurações e características adotados no sistema de softwa-
re, visando à qualidade do software oferecido. Observaremos as técnicas de
testes que são adotadas para a identificação de erros ou bugs para atender as
necessidades do cliente final.
Outro ponto a estudarmos trata do uso de casos de teste e todos os aspec-
tos e características que envolvem a sua implementação. Veremos com maior
detalhamento sobre o processo de extração e desenvolvimento, evidenciando
o uso do random sampling, por exemplo, além da automação presente nos
testes e sua influência nos testes que serão realizados. Outro ponto importan-
te se refere ao gerenciamento de defeitos, que busca equacionar e solucionar
problemas para melhorar o nível de eficácia e eficiência de um sistema.
Por fim, vamos expor aspectos essenciais a métricas (mensurações) defi-
nidas para a realização do teste de software, além do gerenciamento desta
atividade. Identificaremos como é essencial que o modelo de planejamento
adote a estratégia que melhor se adapta à realização dos testes de software,
lembrando também da importância das ferramentas de suporte de teste, evi-
denciando seus benefícios ao processo de teste.
Bons estudos!
TESTE DE SOFTWARE 9

A autora
A professora Ana Luiza Cerchiari de

Andrade é mestre em Estudos Analíti-
cos de Dados em Engenharia e Tecno-
logia de Energia pela Universidad Eu-
ropea del Atlántico – Espanha (2017),
possui formação continuada em SQL,
PHP, jQuery, Data Science, HTML5 e
CSS3 pela 4Linux (2017), possui forma-
ção específica em Redes pela Impacta
(2017) e em Cisco pelo Senac (2017).
Além disso, possui Pós-Graduação em
Análise Estatística para Auditorias de
Ambientes e Sistemas pela Estácio de
Sá (2016) e é bacharela em Tecnolo-
gia da Informação pela Universidade
Anhembi Morumbi – UAM (2006). Planejamento Estratégico e Tecnologia
Tem uma empresa de tecnologia e da Informação, além de ter trabalhado
atualmente ministra aulas em quatro com desenvolvimento de sites e siste-
instituições. É professora de Lingua- mas tanto em empresas quanto para
gens de Programação para Aplicativos empresas de 2011 a 2018.
e Sites, Banco de Dados, Redes e Ad-
ministração em faculdades e colégios. Currículo Lattes:
Ministrou aulas em faculdades sobre http://lattes.cnpq.br/5870955794360235
Dedico este material ao meu amigo Fabio Carmine, que tem trocado
comigo experiências profissionais e acadêmicas ao longo de uma década.
TESTE DE SOFTWARE 10

O autor
O professor Jailson Costa dos Santos é

especialista em Engenharia de Software
pela Universidade Braz Cubas – UBS
(2018), especialista em Governança
em Tecnologia da Informação pela
Universidade Nove de Julho – Uninove
(2018), especialista em Docência do
Ensino Superior pela Universidade
Paulista – UNIP (2017) e graduado em
Análise e Desenvolvimento de Sistemas
pela Universidade Mogi das Cruzes –
UMC (2015).
Ministra disciplinas de Desenvolvimento
de Software, Algoritmos e Lógica de
Programação, Engenharia de Software
e Programação Web e Mobile para
cursos de Engenharia da Computação,
Sistemas da Informação e Tecnólogo em
Análise e Desenvolvimento de Sistemas.
Currículo Lattes:
Dedico este trabalho a Deus, pelo dom da vida e da aprendizagem, à minha

família, que sempre me incentiva com seu carinho e afago, e aos meus
alunos e alunas, que me motivam mediante novos desafios.

UNIDADE
1 ASPECTOS
INTRODUTÓRIOS DO
TESTE DE SOFTWARE

Apresentar os fundamentos de teste de software, evidenciando seus

conceitos e aspectos principais;
Abordar o desenvolvimento de software e os testes de software,
evidenciando suas funcionalidades;
Observar os principais conceitos referentes aos níveis de teste, verificando
implicações e atividades essenciais.
Tópicos de estudo
Fundamentos de teste de
software
Desenvolvimento de software
e teste de software
Níveis de teste
Teste de desenvolvimento
Teste unitário
Teste de componentes
Teste de sistema
Teste de release
Testes baseados em requisitos
Teste de cenário
Testes de desempenho
Teste de usuário

Fundamentos de teste de software
Ao tratar do desenvolvimento de software, certamente vamos nos atentar
a um requisito fundamental: os testes de validação. Porém o que podemos en-
tender sobre teste? Segundo Sommerville (2011, p. 144), o teste tem a função
de mostrar as funcionalidades de um programa e encontrar possíveis falhas
no momento anterior ao seu uso. No momento em que o software é testado, o
programa é executado, e os resultados almejados visam a encontrar erros ou
informações de requisitos não funcionais pertencentes a ele.
Quando tratamos do nível de importância atribuído aos testes de software,
e o seu impacto à qualidade, é necessária certa cautela. O desenvolvimento
de sistemas de software requer um conjunto de ações ligadas à criação, na
qual possíveis erros humanos poderão ficar em evidência. As falhas tendem a
surgir no início do processo, pois os objetivos determinados podem estar erro-
neamente especificados, além de erros posteriores nas etapas de
projeção e de desenvolvimento. Estas possibilidades fazem com
que o desenvolvimento de software esteja ligado à garantia
de sua qualidade (PRESSMAN, 1995, p.786).
ASSISTA
O vídeo Você ainda faz testes de software manuais?
introduz o tema de maneira descontraída e mostra, visual-
mente, exemplos práticos muito interessantes.
É importante frisar que as atividades ligadas aos testes de software são consi-
deradas elementos críticos da garantia de qualidade e simbolizam a análise mais
recente de especificação, projeção e codificação. Tais ações vêm sendo propaga-
das graças ao crescente aumento do software na condição de componente de sis-
tema e aos custos ligados aos erros de software. Normalmente, o projeto total em
teste dispende de uma porcentagem relevante do esforço de uma organização
de software. Só para citar um exemplo, uma atividade ligada a teste de software
em sistemas relacionados à vida humana (um controle de voo, por exemplo) pode
demandar um custo, muitas vezes, de três a cinco vezes maior em comparação à
outras áreas de engenharia de software (PRESSMAN, 1995, p. 787).

Ao longo desta unidade, nós observaremos e discutiremos as característi-
cas essenciais relacionadas às atividades de teste e as metodologias direciona-
das ao projeto de casos de teste. Estas características estabelecem os objetivos
presentes nos testes de software. Importante ressaltar que o projeto de casos
de testes acaba se concentrando em uma série de métodos para o desenvol-
vimento de casos que consigam suprir os objetivos gerais estabelecidos pelas
atividades de teste.
Para compreendermos como uma atividade de software se forma, é preciso
levar em consideração o ponto de vista da engenharia de software, que analisa
atividades como “anomalias”, de acordo com Pressman (1995, p.787), ao longo
das etapas ligadas à definição e ao desenvolvimento realizadas anteriormente.
Profissionais de engenharia normalmente tentam criar o software a partir de
um pensamento abstrato em uma implantação tangível. A partir daí, aparecem
as etapas de testes e o aspecto curioso pode ser observado. O engenheiro ou
engenheira desenvolverá um conjunto de casos de teste com a intenção de
destruir o software construído. Na prática, as atividades de teste é um procedi-
mento mais “destrutivo” do que “construtivo”.
O pensamento que devemos ter em relação ao desenvolvimento de software
é que a atividade de teste exige descartar e superar uma série de conflitos que
possam surgir no momento em que as falhas são observadas. Para evidenciar
esta ideia, Beizer (1990 apud PRESSMAN, 1995, p. 428) diz que existe uma falsa
conceituação de que se profissionais de programação fossem de fato muito
bons não haveria a necessidade de buscar bugs.
Quando observamos os objetivos da atividade de teste, Myers (1990 apud
PRESSMAN, 1995, p. 788) define um conjunto de normas que servem de objeti-
vos. A primeira norma determina que a atividade de teste deve ser vista como
um processo capaz de executar um programa com o objetivo de encontrar er-
ros. Na visão de Sommerville (2011, p. 145), este processo de teste visa também
expor tanto a profissionais de desenvolvimento quanto a clientes
que o produto software consegue atender suas solicitações.
Vale ressaltar que para os softwares considerados “custo-
mizados” haverá ao menos um teste destinado a cada
requisito, pertencente ao documento de requisitos. No
caso dos chamados softwares “genéricos”, haverá testes

para todos os aspectos do sistema, além das combinações estabelecidas, inse-
ridas ao release do produto. Estes são exemplos de testes de validação, pelos
quais o sistema é executado de maneira adequada, adotando uma série de
casos de teste que simbolizam a utilização prevista pelo sistema.
Outra regra considera que um bom caso de teste apresenta probabilida-
de elevada de expor uma falha, mesmo que ainda não tenha sido revelada.
Sommerville (2011, p. 144) frisa ainda que cabe ao teste de software observar
possibilidades do software de se apresentar de forma incorreta e distinta das
especificações definidas. Cabe aos testes de defeito eliminar os comportamen-
tos inadequados do sistema.
Na Figura 1, podemos observar as diferenças entre os testes de validação e
de defeitos. Para ficar mais elucidativo, Sommerville (2011, p.145) traz o exem-
plo da caixa preta. Como funciona? O sistema se caracteriza por aceitar en-
tradas através de uma série de entradas do tipo “I”, e criar saídas dentro de
uma série de saídas do tipo “O”. Importante frisar que determinadas saídas se
encontram equivocadas: elas fazem parte do grupo “Oe”, criadas pelo sistema
respondendo a entradas estabelecidas no grupo “Ie”.
É importante deixar claro que a prioridade visualizada nos testes de de-
feitos é buscar as entradas estabelecidas no conjunto Ie, porque elas expõem
questões relacionadas ao sistema. Os testes de validação, por sua vez, adotam
testes com entradas mais adequadas que se encontram fora do Ie, que se carac-
terizam por estimular o sistema a criar adequadamente as saídas.
Entradas que causam

Entrada de dados de teste Ie
comportamentos anômalos
Sistema
Saída de resultados de teste Oe Saídas que revelam defeitos
Figura 1. Modelo de entrada-saída de teste de programa. Fonte: SOMMERVILLE, 2011, p. 145. (Adaptado).

Estes objetivos (regras) apontam uma alteração robusta do ponto de vista.
Eles indicam que um teste bem-sucedido não é aquele em que nenhuma falha é
visualizada, e sim aquele que desenvolva testes que busquem, de maneira siste-
mática, as classes distintas de falhas em período e com esforço mínimos.
Caso a atividade de teste for direcionada com êxito, ela descobrirá os erros
presentes no software. Outra vantagem em relação à atividade de teste indica
que as funções de software estão sendo executadas, levando em consideração as
especificações estabelecidas, com as quais os requisitos de desempenho são cum-
pridos, mesmo que aparentemente. Vale frisar também que os dados compilados,
no momento em que a atividade de teste surte algum efeito, possibilitam a indica-
ção de confiabilidade e de qualidade de software de maneira geral. Porém, estas
atividades, assim como já tratamos, não podem esconder a presença dos bugs, ou
seja, precisam apresentar os erros do software caso eles estejam presentes.
Outro aspecto que devemos frisar é o fato do teste fazer parte de um extenso
processo de verificação e validação (V&V), que tem o objetivo de verificar se o
software em desenvolvimento consegue atender às suas especificações e dispo-
nibilizar a funcionalidade aguardada por quem usará o software. Esse processo
começa no momento em que as solicitações estão disponíveis, e se mantém em
todas as etapas do processo de desenvolvimento.
A verificação visa checar se o software consegue suprir as suas necessidades
funcionais e não funcionais. Para Sommerville (2011, p. 145), a validação é um
processo mais generalista, cuja função é assegurar que o software consiga suprir
as necessidades de clientes. A validação é fundamental, pois as especificações de
requisitos nem sempre suprem as demandas dos usuários do sistema.
EXPLICANDO
Os processos de verificação e de validação têm o objetivo de determinar um
nível de confiança garantindo que o software atenderá seus propósitos. O
sistema precisa ser, dentre outros aspectos, das expectativas dos usuários.
A finalidade do software está relacionada ao seu nível de confiança, ne-

cessário para um software ser utilizado no sistema, atingir as expectativas de
usuários, que já se acostumaram, de certa maneira, aos erros presentes no
sistema, porém, com o amadurecimento do software, esperam que sejam rea-

lizados testes mais completos nas versões posteriores. É importante deixar claro
que, no momento em que um sistema passa a ser comercializado, cabe a quem
o vende considerar os produtos concorrentes, o preço de mercado e os prazos
adequados de entrega (SOMMERVILLE, 2011, p. 146). Dentro de uma área mais
competitiva, uma organização empresarial pode lançar produtos antes de serem
testados e depurados.
O processo de verificação e validação (V&V) inclui inspeções e revisões respon-
sáveis por avaliar e observar, dentre outros aspectos, os atributos do sistema. Po-
demos considerar estes aspectos como as chamadas técnicas “estáticas’” de V&V,
que se caracterizam pelo fato do usuário não ter a necessidade de executar o soft-
ware para analisá-lo. A Figura 2 apresenta as inspeções e testes de software que
auxiliam o V&V em estágios distintos do processo de software; as setas apontam
os estágios do processo, no qual as técnicas podem ser empregadas.
Inspeções
Arquitetura Modelos de Esquemas

Especificação
de projeto em de banco Programa
de requisitos
software UML de dados
Protótipo
Teste
de sistema
Figura 2. Teste de Inspeção. Fonte: SOMMERVILLE, 2011, p. 146. (Adaptado).
É preciso compreender que as inspeções se concentram no código-fonte de

um sistema, principalmente; entretanto, seus requisitos ou modelos de proje-
to, de fato, podem ser inspecionados. Ao ser inspecionado o sistema, cabe ao

usuário adotar todo o seu conhecimento sobre ele e a linguagem de programa-
ção adequada para observar os possíveis erros.
Segundo Sommerville (2011, p. 147), podemos observar basicamente três
vantagens ou benefícios de utilizar a inspeção de software em relação aos testes:
• No momento em que os testes são realizados, possivelmente alguns erros
poderão impedir a visualização de outros erros. Isso gera algumas dúvidas,
pois, no momento em que um erro indicar uma saída inesperada, o usuário
não terá certeza se as distorções posteriores serão provenientes de um erro
novo ou efeitos do erro original. Sabendo que a inspeção consiste em um
processo estático – não há a necessidade, por parte do usuário, de se preo-
cupar com possíveis interações entre as falhas encontradas. Certamente, a
conclusão a que chegamos é de que uma única sessão de inspeção é capaz
de encontrar diversas falhas dentro de um sistema;
• Existe a possibilidade das versões incompletas de um sistema serem ins-
pecionadas sem o acréscimo de custos. Como isto funciona de fato? Caso
um programa se encontre incompleto, é preciso criar mecanismos de testes
específicos para realizar as análises das partes que se encontram disponíveis;
• Além de ter a função de encontrar falhas em um programa, uma inspe-
ção se caracteriza por levar em consideração outros requisitos de qualida-
de inerentes a um programa, como a portabilidade e a manutenibilidade
(SOMMERVILLE, 2011, p.147). É possível que a usuária ou usuário encontre al-
gum tipo de ineficiência que dificulte a manutenção e a atualização do sistema.
Vale ressaltar um aspecto importante: as inspeções não substituem os testes
de software tradicionais. As inspeções não são adequadas, por exemplo, para
encontrar falhas oriundas de interações realizadas em partes diferentes de um
programa. Outro ponto é o fato da dificuldade em formar uma equipe de inspe-
ção dentro de uma organização empresarial, já que normalmente as pessoas da
equipe ocupam também a função de desenvolver softwares.
A Figura 3 apresenta um modelo do processo de testes. Os casos
de teste são conceituados como especificações presentes nas
entradas do teste e da saída prevista pelo sistema. Além
disso, é possível obter uma declaração dos componen-
tes que estão sendo testados. É possível verificar que os
dados de teste representam as entradas geradas para a

realização dos testes no sistema, porém a execução destes testes pode ocorrer
de forma automatizada. Os resultados previstos serão os resultados alcança-
dos de forma automatizada, o que dispensa a busca por falhas na execução
dos testes.
Casos Dados Resultados Relatórios

de teste de teste de teste de teste
Executar Comparar
Preparar
Projetar casos programa resultados
dados de
de teste com dados para os casos
teste
de teste de teste
Figura 3. Um modelo do processo de teste de software. Fonte: SOMMERVILLE, 2011, p. 146. (Adaptado).
Outro aspecto que devemos mencionar se refere ao fluxo de informação da

atividade que adota um padrão, conforme se visualiza na Figura 4.
Configuração de SW
Resultado de teste Depuração
Erros Correções
Avaliação
Atividade de teste Dados da taxa

de erros
Resultados esperados
Modelo de
Configuração de teste
confiabilidade Confiabilidade
prevista
Figura 4. Fluxo de Informação de teste. Fonte: PRESSMAN, 2015, p. 790. (Adaptado).
Duas classes de entrada são disponibilizadas durante os processos de teste:

a primeira classe trata da configuração de software, que insere uma especifica-
ção de requisitos de software, especificação do projeto, além do código-fonte;
a segunda classe simboliza uma configuração de teste que se caracteriza por
inserir um plano e um procedimento referente aos testes, além das ferramen-

tas que serão empregadas e seus casos de testes com os resultados almejados.
Uma configuração de teste é compreendida como um subconjunto pertencente
à configuração de um software (PRESSMAN, 1995, p. 789).
DICA
Os testes são executados e os resultados analisados, ou seja, os resulta-
dos alcançados com os testes são relacionados aos resultados aguarda-
dos. No momento em que os dados com erros são expostos, é necessário
dar início ao processo de depuração.
O processo de depuração trata da imprevisibilidade no processo de teste.

Para se ter uma ideia, uma possível falha que indique um nível de discrepância
entre os resultados desejados e os reais pode levar um tempo considerável para
ser identificado e solucionado. Isso indica afirmar que a incerteza característica
do processo de depuração torna a atividade de teste mais complexa e com a
programação menos confiável.
No momento em que os resultados de testes forem agrupados e analisados,
a apresentação de softwares com um nível mais elevado de qualidade e con-
fiança começa a ser mais frequente. Quando a presença de falhas graves, que
influenciam a alteração de projetos, passarem a ser cotidiano, certamente os
níveis de confiança e qualidade serão questionados e automaticamente alguns
testes adicionais serão recomendados. Por sua vez, se as funções designadas
aos softwares forem executadas de maneira adequada, e as falhas visualizadas
serem de fácil correção, é possível se chegar basicamente a duas conclusões,
conforme Pressman (1995, p. 790): os níveis de qualidade e de confiança do soft-
ware são adequados ou aceitáveis; ou os testes não são apropriados para desco-
brir falhas mais complexas.
Precisamos ter em mente, como regra geral, que, se a atividade de teste não
encontrar nenhuma falha, é de se concluir que a configuração de teste não foi
devidamente elaborada, e que os erros serão expostos pelo usuário e soluciona-
dos por quem desenvolve no momento da manutenção, quando normalmente
os custos se elevam.
Os resultados que foram se acumulando ao longo da atividade de teste
também podem ser analisados de uma maneira mais formalizada. Os tipos
de confiabilidade do software normalmente utilizam dados que representam

o percentual de falhas para evitar uma ocorrência destes mesmos erros no
futuro. Na Figura 1 observamos que cada círculo simboliza uma mudança
com alto grau de complexidade.
Quando se fala em desenvolvimento de software, não podemos esquecer
de mencionar o projeto de casos de testes. O projeto de teste de software pode
ser visto como um desafio, assim como o projeto elaborado inicialmente do pró-
prio produto. Entretanto, assim como já visualizamos, as atividades de testes
são tratadas por boa parte de profissionais de engenharia de software como
uma espécie de análise tardia ao criar casos com resultados previsíveis e de bai-
xa garantia de totalidade. As atividades de teste visam projetar, dentre outros
aspectos, testes com elevada capacidade de descoberta de erros em tempo e
com esforço mínimos.
Houve uma época em que uma diversidade de técnicas de projeto de casos
de teste se transformou em um software. Essas técnicas disponibilizam a profis-
sionais de desenvolvimento uma abordagem mais sistemática dos testes, o que
significa dizer que elas oferecem uma metodologia que auxilia a integridade do
teste e permite alta chance de expor as falhas encontradas no software.
Segundo Pressman (1995, p. 791), independentemente do produto ou ser-
viço projetado pelo engenheiro ou engenheira de software, as duas formas de
testá-lo são: tendo conhecimento da função determinada que precise realizar
o produto ou serviço, sobre o qual os testes podem ser executados para com-
provar que cada função é feita operacionalmente; e conhecendo como funcio-
na internamente um produto, permitindo que os testes sejam realizados para
assegurar que a operação interna do produto apresente um comportamento
adequado às suas especificações.
Neste contexto, vamos nos deparar com duas conceituações referentes à
abordagem de teste: o teste de caixa preta e o teste de caixa branca.
Vamos tratar de cada um deles.
Levando em consideração um software inserido
no computador, o termo “teste de caixa preta” tra-
ta dos testes feitos dentro das interfaces de um
software. Este teste tem o objetivo de localizar
possíveis erros, porém, além desta funcionalida-
de, ele é empregado para comprovar que as fun-

ções atribuídas aos softwares são operacionais, ou seja, a entrada é aceita
de maneira adequada assim como a saída produzida corretamente, além de
garantir a integridade das informações de origem externa. Este modelo de
teste, contudo, não precisa necessariamente a estrutura lógica interna do
software que venha a ser adotada.
No que se refere ao teste de caixa branca, ela se baseia em uma série de
detalhes no procedimento. São testados os caminhos lógicos por meio do soft-
ware, disponibilizando casos de teste que colocam à prova grupos específicos de
condições ou laços (PRESSMAN, 1995, p. 792).
Em um primeiro momento, a impressão que fica é de que um teste de caixa
branca, se executado com cautela, pode gerar a totalidade de programas corre-
ta, ou seja, basta que sejam definidos os caminhos lógicos, desenvolver os casos
de teste, testá-los e analisar os resultados alcançados, gerando casos de testes
para colocar a lógica do programa em uma prova exaustiva. Tudo certo? Infeliz-
mente não, pois os testes exaustivos revelam problemas logísticos. Isso ocorre
porque a quantidade de caminhos logísticos possíveis pode ser extensa, mesmo
para programas de menor porte.
Laço = 20 vezes
Figura 5. Fluxo de informação de teste. Fonte: PRESSMAN, 1995, p. 792. (Adaptado).

A Figura 5 representa um projeto procedimental corres-
pondente a um programa Pascal, que contém 100 linhas
disponibilizando um laço único, que pode ser realizado no
máximo 20 vezes. Isto indica que algo próximo de 1014 cami-
nhos pode ser, de fato, realizado (PRESSMAN, 1995, p. 792). É
essencial, porém, que o teste de caixa branca não seja visto como algo
pouco usual, pois uma quantidade restrita de caminhos lógicos essenciais pode
ser escolhida. As estruturas de dados importantes podem ser avaliadas levando
em consideração a validade, e os atributos presentes nos testes de caixa branca
ou preta tendem a ser combinadas, visando disponibilizar uma abordagem que
torne a interface validada com o software e assegure, de maneira seletiva, e que
o funcionamento interno esteja plenamente adequado.
Desenvolvimento de software e teste de software

Você já parou para analisar o que significa um projeto e como ele é consti-
tuído? Um projeto é formado por um conjunto de procedimentos constituídos
por uma série de atividades executadas de forma organizada. Normalmente,
um projeto trata da criação de um produto ou serviço. Se associarmos este
conceito ao desenvolvimento de um software, perceberemos que este produto
é intangível e que apresenta uma série de variações complexas, o que dificulta
sua criação e qualificação.
Neste contexto, é essencial a inclusão de temas que tratem da engenha-
ria no que diz respeito ao desenvolvimento de software, pois ela permite a
uma gestora ou gestor conseguir fortalecer as práticas para desenvolver um
produto de software que atenda algumas normas de qualidade, abrangendo
basicamente três áreas essenciais: as técnicas adotadas, as ferramentas e os
procedimentos.
Um processo relacionado ao de desenvolvimento de software é definido
como uma série de atividades padronizadas e organizadas, que estabelecem,
desenvolvem, avaliam e mantêm um software. Por sua vez, objetiva, dentre
outros aspectos, determinar as atividades a serem realizadas, o momento em
que elas serão executadas, quem irá realizar estas tarefas e qual o nível de pa-
dronização adotado ao longo do desenvolvimento de um software.

É possível visualizar uma variedade de processos de desenvolvimento de
software, porém existem algumas atividades consideradas fundamentais à
boa parte dos processos disponíveis. A primeira atividade a ser realizada é de
levantamento de requisitos, que tem como objetivo ter uma noção geral do
problema, a partir do qual profissionais e usuários irão compartilhar visões
para a solução do problema encontrado. Neste cenário, profissionais e clientes
irão atuar de maneira conjunta para coletar e dar prioridade às necessidades
ou requisitos dos próximos usuários do software no futuro.
Além disso, é preciso perceber que o levantamento de requisitos é funda-
mental, também, porque trata de uma atividade essencial: o retorno de in-
vestimentos no projeto. Diversos projetos são descartados por conta do bai-
xo levantamento de requisitos adotado, o que indica a atuação deficiente dos
membros da equipe que não apresentaram um tempo necessário para execu-
tar essa fase do projeto, além de não entender as reais demandas dos clientes
levando em consideração o sistema criado.
Você pode se questionar: por que as necessidades de clientes são tão im-
portantes? É preciso entender, por exemplo, que estamos tratando de um sis-
tema de informações com o objetivo de automatizar alguns processos de ne-
gócios dentro de uma empresa. Esses procedimentos precisam estar alinhados
com as outras tarefas para que as atividades do processo de desenvolvimento
estejam de acordo com as necessidades reais de clientes.
A fase seguinte consiste na análise de requisitos, também conhecida como
especificação de requisitos. Mas o que seria esta “especificação”? É neste mo-
mento que profissionais irão avaliar detalhadamente os dados coletados na
fase anterior e começar a desenvolver modelos que simbolizem o sistema de
software que será desenvolvido. Compreender de maneira total os requisitos
de software é essencial para um desenvolvimento de software bem feito. Se-
gundo Pressman (1995, p. 231), não importa se um programa é bem projetado
ou codificado se ele for mal avaliado ou especificado, pois isso tra-
rá uma série de problemas a quem o desenvolve.
A missão de avaliar os requisitos consiste em um trabalho
que envolve quatro ações básicas: o processo de busca, o
refinamento, a modelagem e a especificação. O escopo
de software é melhorado constantemente nos seus de-

talhes. Neste contexto, os modelos de fluxo de informação, além do controle
requisitado, são criados, e as soluções opcionais são avaliadas e inseridas a
diversos componentes do software. Esta atividade é responsável por desen-
volver uma estratégia de resolução e não o método que será utilizado, ou seja,
primeiro se identifica as necessidades de clientes, e só depois se pensa na me-
todologia adequada para solucionar esta questão.
CONTEXTUALIZANDO
Analisar requisitos permite ao engenheiro ou engenheira de sistemas
especificar a função e o comportamento do software, apontando a interfa-
ce do software aliado a outros componentes do sistema, e definir quais as
limitações impostas ao projeto adotado.
Existe a crença de que analisar e especificar requisitos consiste em uma

tarefa simples. Porém não é; há uma série de situações que tornam esta ativi-
dade extremamente complexa. Para Pressman (1995, p. 231), a comunicação
extensa, as possibilidades de interpretações erradas e a ambiguidade são algu-
mas situações que podem tornar a análise de requisitos mais complexa.
Diante deste cenário, qual a barreira para analisar os requisitos? O que ge-
ralmente acontece é que as equipes responsáveis pelo desenvolvimento di-
recionam seus trabalhos para solucionar os problemas de softwares sem ao
menos entenderem quais são os problemas em questão. É nesta etapa que
se realiza o processo que tratamos na seção anterior: o V&V (validação e ve-
rificação) dos modelos desenvolvidos, antes da solução do problema em si. A
validação visa garantir que o sistema de software consiga suprir as necessida-
des efetivas de clientes. A verificação observa se os modelos desenvolvidos na
análise estão de acordo com as mesmas necessidades.
Quem desenvolve, assim como clientes, exerce uma função ativa na ava-
liação e especificação dos requisitos, ou seja, cabe a clientes, por exemplo, a
função de reformular um conceito referente e à função e à performance de
software de maneira detalhada. Já o papel da desenvolvedora ou desenvolve-
dor é agir como uma espécie de pesquisadora ou pesquisador, questionando e
apresentando soluções para os problemas (PRESSMAN, 1995, p. 231).
A análise de requisitos de software, para uma melhor conceituação, pode
ser divida em cinco subáreas. Segundo Pressman (1995, p. 232), elas são: iden-

tificação de problema, avaliação e síntese, modelagem, especificação e revi-
são. No início, a analista ou o analista normalmente estuda a especificação do
sistema, além do plano de projeto de software. Vale ressaltar que é essencial
compreender a atuação do software dentro de um cenário sistêmico e reava-
liar o escopo de software utilizado para criar expectativas de planejamento. Em
seguida, é necessário definir o nível de comunicação com a tarefa de análise,
visando assegurar a identificação do problema.
Analistas precisarão manter contato com a equipe técnica da organização
assim como a equipe responsável pelo desenvolvimento de software. Cabe à
gerente ou ao gerente de projeto exercer a função de coordenar para simpli-
ficar a abertura dos caminhos comunicativos e às analistas ou aos analistas a
função de identificar os componentes que apresentam problemas reconheci-
dos por clientes (PRESSMAN, 1995, p. 233).
O resumo de análise e resolução de questões é a maior área de esforço se-
guinte. Normalmente, analistas conseguem analisar o conteúdo e o fluxo infor-
macional, além de estabelecerem as funções e o comportamento do software,
definirem os aspectos de interface e visualizarem limitações presentes no proje-
to. De acordo com Pressman (1995, p. 233), cada atividade dessas tem a função
de descrever o problema de forma que a solução geral seja sintetizada.
Chegamos à etapa na qual é possível visualizar como o sistema irá funcio-
nar internamente, visando atender os requisitos de clientes. É o passo inicial
para realizar o desenvolvimento de qualquer produto ou sistemas ligados à
engenharia. Nesta etapa, devemos levar em consideração alguns aspectos
essenciais, tais como a arquitetura do sistema, a linguagem de programação
adotada, as características do sistema gerenciador de banco de dados (SGBD)
utilizado, entre outros.
É no projeto que a descrição computacional é apresenta-
da e o usuário fica sabendo o que o software deverá realizar,
lembrando que esta descrição deve estar alinhada com a
descrição executada na análise de requisitos. Ao utilizar
um dentre um conjunto de métodos existentes, esta
fase é capaz de produzir os chamados projetos de
dados, arquitetural e o procedimental. Vamos vi-
sualizar cada um deles.

Segundo Pressman (1995, p. 416), o projeto de dados é capaz de transfor-
mar o modelo de domínio de informação, desenvolvido durante a avaliação
das estruturas de dados, que serão solicitadas, para a implementação do soft-
ware. Já o projeto da arquitetura se caracteriza pela distribuição das classes de
objetos ligados ao sistema presente em subsistemas e componentes, que são
partilhados através dos recursos de hardware apresentados. Por sua vez, o
projeto procedimental altera os elementos estruturais em uma descrição pro-
cedimental do software. Nesta situação, o código-fonte é desenvolvido e as
atividades de teste são utilizadas para a integração e a validação do software.
Na Figura 6, visualizaremos o fluxo de informações realizado ao longo da
etapa técnica do processo referente à engenharia de software. A etapa do pro-
jeto é abastecida pelos requisitos do software que são indicados por modelos
comportamentais, dentre outros.
Modelo de informação
Modelo funcional Software

Projeto Módulos de integrado
de dados programa e validado
Modelo Projeto Código Teste
comportamental
Projeto
arquitetural
Outros requisitos
Figura 6. Projeto de software e engenharia de software. Fonte: PRESSMAN, 1995, p. 417. (Adaptado).
Segundo Pressman (1995, p. 415), o objetivo de qualquer projetista é criar

modelos ou simbolizar qualquer um que seja desenvolvido posteriormente.
Vale ressaltar que o procedimento pelo qual o modelo é criado é fruto de uma
combinação que envolve alguns aspectos, como:
• Intuição e análise com base na experiência de desenvolver entidades parecidas;
• Princípios que norteiam a forma pela qual o modelo é desenvolvido;
• Critérios que permitam que a qualidade seja avaliada;
• Interação que leve a uma representação do projeto final.
O projeto de software muda de forma contínua assim que novos métodos
e análises mais assertivas vão se desenvolvendo. Vale frisar que o projeto de

software ainda vem em um estágio ini-
cial de evolução, portanto ainda falta
uma metodologia mais definida.
O projeto de software pode ser inse-
rido independentemente do paradigma
de desenvolvimento utilizado. Ao dar
início aos requisitos de software, já ava-
liados e especificados, Pressman (1995,
p. 416) afirma que o projeto consiste na
primeira atividade técnica exigida para
o desenvolvimento e a análise de um
software, ou seja, cada atividade vai
alterar informações de maneira que o
resultado será um software de compu-
tador validado.
Os conceitos relacionados à engenharia de software abrangem tarefas re-
lacionadas à criação de software, dos requisitos, até o gerenciamento do sis-
tema instalado. Dentro deste contexto, a fase considerada mais crítica neste
processo se refere à implementação do sistema, que é responsável por criar
uma versão executável do software. Segundo Sommerville (2011, p. 135), a im-
plementação aborda o desenvolvimento de programas, independentemente
do nível de linguagens de programação utilizado.
Nesta fase, o sistema será codificado, levando em consideração a descri-
ção computacional da etapa do projeto, inserido em outra linguagem, na qual é
permitido compilar e gerar o código executável, visando o desenvolvimento do
software. Vale ressaltar, por exemplo, que, em um processo de desenvolvimento
orientado a objetos, o processo de implementação ocorre quando se definem
as classes de objetos do sistema e se adotam linguagens de programação, como
Java. As ferramentas de software e bibliotecas de classes existentes para acelerar
a execução podem ser adotadas na fase da implementação. O uso da ferramenta
CASE, por exemplo, auxilia na dinamização do processo de desenvolvimento.
De acordo com Sommerville (2011, p. 136), determinados aspectos referen-
tes à implementação são essenciais para a engenharia de software, e que ge-
ralmente não são abordados em textos de programação. São eles:

• Reúso: os softwares mais modernos são formados através do reúso de
elementos existentes ou por conta dos sistemas. No momento em que um
software for desenvolvido, é preciso utilizar, de maneira extensiva, os códi-
gos já existentes;
• Gerenciamento de configuração: ao longo do processo de desenvolvi-
mento, são desenvolvidas versões diferentes de cada elemento de software.
Caso o usuário não acompanhe as versões inseridas no sistema de gerencia-
mento de configuração, certamente haverá a possibilidade de inserir versões
errôneas destes elementos dentro do sistema;
• Desenvolvimento host-target: a criação de um software geralmente não
executa no mesmo computador como no ambiente de desenvolvimento de
software. É preciso desenvolver em um computador (o sistema host) e exe-
cutar em outro (o sistema target). Os sistemas host e target apresentam
normalmente o mesmo modelo, porém por diversas vezes são distintos.
Quando tratamos de implementação, é preciso falar de projeto orientado a
objeto. A fase de projeto orientado a objeto detalhado (Object-Oriented Design –
OOD) é parecido com os projetos de detalhes que utilizam qualquer metodologia
de projeto de software. As interfaces normalmente são descritas de forma deta-
lhada, assim como as estruturas de dados, que são mais refinadas e específicas.
Neste contexto, os algoritmos são descritos para cada unidade de programa uti-
lizando conceitos de projetos essenciais (PRESSMAN, 1995, p. 546).
O projeto detalhado se diferencia do projeto orientado a objeto, pois ele
pode ser inserido de maneira recursiva a qualquer momento. A definição recur-
siva da estratégia de solução é fundamental para alcançar um nível de projeto
e abstração de dados, no qual os detalhes referentes à implementação possam
ser de fato derivados.
Várias atividades de testes são realizadas com o intuito de validar o pro-
duto de software. Isso ocorre quando testes são executados a cada funcio-
nalidade pertencente aos modelos, considerando a especificação realizada
na etapa de projeto. O relatório de testes é o resultado mais imediato, pois
apresenta um conjunto de informações importantes sobre as falhas visuali-
zadas no sistema além da sua performance em diversos. Ao término da ativi-
dade, diversos módulos do sistema são integrados, o que vai desencadear no
produto de software.

Normalmente, um sistema de software disponibilizado comercialmente atin-
ge três níveis ou estágios de testes, sobre os quais trataremos com maior deta-
lhamento nas seções posteriores. São eles:
• Testes em desenvolvimento, com os quais o sistema é avaliado para bus-
car defeitos ou bugs ao longo do processo de desenvolvimento, e se caracte-
riza por incluir projetistas, programadores e programadoras neste processo;
• Testes de release, com os quais uma equipe independente de análise rea-
liza testes no sistema antes de disponibilizá-lo ao cliente final, observando
se o sistema consegue suprir as solicitações dos stakeholders de sistema;
• Testes de usuário, com os quais os usuários são responsáveis por testar
o ambiente dentro do seu próprio ambiente. Os chamados testes de aceita-
ção são considerados um modelo de teste do usuário com que clientes ava-
liam de maneira formal o sistema, para definir se ele será aceito por quem
o fornecerá ou se será preciso desenvolvimento incremental.
Se observarmos o processo de teste, na prática, veremos que ele nor-
malmente adota uma mescla de testes manuais e automatizados. Segundo
Sommerville (2011, p. 147), o teste manual se caracteriza pelo fato do avaliador
ou avaliadora executar o programa utilizando um conjunto de dados de teste
e comparar os resultados obtidos com as suas previsões, a quem cabe verifi-
car e informar as possíveis distorções aos desenvolvedores do programa. Já os
testes automatizados se caracterizam pelo fato dos testes estarem codificados
em programas executados toda vez que houver testes realizados em sistemas
em desenvolvimento. Geralmente, o teste automatizado é realizado de manei-
ra mais rápida em relação ao manual, principalmente quando se tratam de tes-
tes de regressão, nos quais testes anteriores são executados novamente com
o intuito de verificar se as mudanças no programa não inseriram novos bugs.
Vale ressaltar que a utilização de testes automatizados tem sido constante
ao longo do tempo. Porém, mesmo com sua extensidade, os tes-
tes jamais poderão ser automatizados na sua totalidade, pois
estas modalidades de testes se limitam a verificar se um pro-
grama realiza aquilo que é proposto, ou seja, é impossível
utilizar esta modalidade de teste, por exemplo, para
verificar se um programa apresenta efeitos colaterais
indesejados (SOMMERVILLE, 2011, p. 147).

Níveis de teste
Os testes são inseridos em destinos diferentes, em estágios distintos ou
em níveis que exigem certo esforço de trabalho. Normalmente, esses níveis
se diferenciam por conta destas funções, que são habilitadas de maneira mais
efetiva para conduzir e projetar testes, nos quais as técnicas utilizadas são mais
apropriadas para testes de cada nível. Diante disso, é essencial garantir um
equilíbrio que seja mantido em esforços de trabalho diferentes. Nas subseções
a seguir, verificaremos os principais níveis de testes adotados e os seus aspec-
tos fundamentais.
Teste de desenvolvimento
Quando tratamos de níveis (estágios) de testes, de imediato é preciso
falar sobre o teste do desenvolvedor. Esta modalidade de teste se caracte-
riza por incluir todas as atividades de testes executadas pela equipe res-
ponsável pelo desenvolvimento do sistema. Normalmente, o responsável
pelo teste do software é o próprio programador ou programadora que o
criou, apesar das exceções. Determinados processos de desenvolvimen-
to adotam programadores-testadores de maneira pareada, para os quais
cada programador apresenta um testador relacionado para criar testes e
auxiliar no processo. Em relação aos sistemas críticos, é preciso adotar um
procedimento mais formalizado por uma equipe de testes independente
atuando em uma equipe responsável pelo desenvolvimento, que cuidará
do desenvolvimento de testes realizados e pela manutenção dos seus re-
sultados.
Segundo Sommerville (2011, p. 148), ao longo do desenvolvimento, o
teste pode ser executado basicamente em níveis de detalhamento: testes
unitário, de componentes e de sistema. Verificaremos cada um deles.
Teste unitário
O teste unitário é o primeiro nível, e se caracteriza pelo fato dos elemen-
tos de programa ou até mesmo as classes de objetos serem avaliadas de

maneira individualizada. Esta modalidade de teste foca na verificação da
funcionalidade dos objetos ou da metodologia adotada.
No momento em que se testa as classes de objeto é preciso planejar os
testes para suprir as características do objeto. Neste contexto, é necessário
que o usuário teste todas as operações que estão relacionadas ao objeto,
além de estabelecer e observar os valores de todos os atributos ligados ao
objeto, e, por fim, inserir o objeto em todas as possibilidades de estado, si-
mulando as possíveis situações que causam as suas alterações.
Recomenda-se, sempre que possível, automatizar os testes unitários.
A explicação para isto vem do fato de que, na automatização, é possível
utilizar um framework de automação de teste, com o objetivo de redigir e
realizar testes dentro do seu programa. Os frameworks destinados aos tes-
tes unitários disponibilizam classes de teste gerais, as quais o usuário pode
aumentar para desenvolver casos de teste mais exclusivos. Diante deste ce-
nário, é possível realizar os testes implementados e informar sobre o status
(o sucesso ou o fracasso) dos testes executados.
Uma série completa de testes geralmente pode ser realizada em segun-
dos. Sendo assim, existe a possibilidade de executar os testes toda vez que
o programa sofrer algum tipo de alteração. Para Sommerville (2011, p. 149),
um teste automatizado consiste basicamente em três partes: a da configu-
ração, na qual o usuário dá início ao sistema com o caso de teste, indican-
do as entradas e saídas previstas; a chamada, que se caracteriza pelo fato
do usuário chamar o objeto ou o método que será testado; e a afirmação,
em que o usuário estabelece comparações do resultado da chamada com
o resultado previsto, ou seja, se a afirmação analisada for considerada ver-
dadeira, podemos considerar o teste bem-sucedido. Caso contrário, o teste
será considerado falho.
Outro detalhe fundamental quando tratamos de testes
unitários é a escolha de casos de teste unitário. Normal-
mente o teste envolve custos elevados e demanda tempo
extenso, por isso é essencial que o usuário selecione ca-
sos efetivos de teste unitário. O termo “efetivo”, em
relação a testes unitários, representa duas coisas:
que é preciso verificar primeiramente se os casos

de teste estão sendo utilizados da maneira esperada, o que consequente-
mente fará com que o componente teste o que se espera dele; e que, se
houverem falhas nos componentes, estes precisarão ser apresentados por
casos de teste.
É preciso, então, redigir dois modelos de casos de teste: um que repre-
sente o funcionamento habitual do programa do componente; e outro que
tenha como referência os testes de experiência, dos quais aparecem proble-
mas mais cotidianos. É necessário utilizar entradas atípicas para analisar se
eles são processados adequadamente e que não causam falhas ao compo-
nente. Existem duas maneiras efi cazes para auxiliar o usuário a selecionar
os casos de teste mais adequados. São elas:
• Teste de partição, no qual é possível reconhecer os grupos de entradas
que apresentam aspectos comuns e que recebem o mesmo tratamento. É
necessário que o usuário selecione os testes em cada um desses grupos;
• Teste com base em diretrizes, as quais o usuário utiliza para selecio-
nar casos de teste. Tais diretrizes indicam a experiência anterior dos ti-
pos de erros normalmente cometidos pelos programadores no momen-
to de desenvolver componentes.
Podemos considerar como normal o fato dos dados de entrada e os re-
sultados alcançados nos de saída de um software serem inseridos em clas-
ses diferentes, mesmo apresentando características comuns. Normalmen-
te, os programas apresentam um comportamento suscetível à comparação
a todos os componentes pertencentes a uma classe.
Teste de componentes
Outra subdivisão dos testes de desenvolvimento consiste nos chamados
“testes de componentes”, nos quais diversas unidades individuais passam a
ser integradas para desenvolver elementos compostos de diversos objetos
que interagem.
Sommerville (2011, p. 151) traz um exemplo que ilustra bem a execução
deste teste: vamos imaginar um sistema de estação meteorológica, no qual
o componente responsável pela reconfi guração adiciona objetos que tratam
de cada aspecto relacionado à reconfi guração. O usuário consegue ter aces-

so à funcionalidade dos objetos atra-
vés da interface de componente esta-
belecida. Os testes de componentes
compostos precisam estar centrados
em apresentar o comportamento da
interface de componente, que deve
estar alinhado a sua especificação,
lembrando que o usuário pode assu-
mir que os testes unitários aplicados
nos objetos individuais já foram fina-
lizados dentro do componente.
Certamente você pode deduzir que existe uma variedade de interfaces
entre os componentes de programa. A primeira interface que podemos tra-
tar são as interfaces de parâmetro, em que as referências de dados ou fun-
ções são transmitidas entre os componentes. É possível observar também
a interface de memória compartilhada, na qual um bloco de memória é par-
tilhado entre componentes, sendo que os dados são inseridos na memória
através de um subsistema e podendo ser recuperado por outros.
Também não podemos deixar de citar as interfaces de procedimento,
nas quais um componente encapsula uma série de processos, que podem
posteriormente ser chamados por outros componentes. Por fim, temos a
interface de passagem de mensagem, em que um componente faz a requisi-
ção de serviço de outro enviando-lhe uma mensagem. Lembrando que uma
mensagem de retorno abrange resultados da execução de um serviço.
Diversas interfaces podem gerar diferentes tipos de erros de interface,
que são as formas mais comuns de erros em sistemas complexos. Os erros
podem ser provenientes, por exemplo, do mau uso da interface, no qual um
componente chamador chama outro e comete uma falha na utilização da
sua interface. Outro erro é o mau-entendimento de interface, em que um
componente chamador não conhece as especificações de interface do outro
componente e realiza suposições, por vezes, errôneas sobre a performance
do componente que foi chamado. Por fim, temos os erros de timing, que são
cometidos em sistemas full time (em tempo real) que utilizam uma memória
partilhada ou até mesmo uma interface de troca de mensagens.

Teste de sistema
Ao longo do seu desenvolvimento, o teste de sistema envolverá a inte-
gração de componentes visando a criar uma versão sistêmica e, posterior-
mente, o chamado “teste do sistema integrado”. Esta modalidade de teste
analisa se existe compatibilidade entre os componentes, se há uma intera-
ção adequada entre eles e se conseguem transferir dados assertivos em
momento propício através de suas interfaces.
No momento da realização do teste de sistema, por exemplo, pode haver
uma integração dos componentes reusáveis criados separadamente e os cha-
mados “sistemas de prateleira”, juntamente com os componentes desenvol-
vidos recentemente. Nesta condição, o sistema completo será testado. Outro
aspecto importante é que, nesta fase, os componentes criados por membros
distintos do grupo poderão ser de fato integrados.
EXPLICANDO
O teste de sistema pode ser considerado um processo coletivo. Em
algumas organizações empresariais, o teste de sistema pode gerar
uma equipe independente, sem necessariamente ocorrer a inserção de
projetistas e programadores.
Pensemos o seguinte: no momento em que o usuário do sistema integra com-

ponentes com o objetivo de desenvolver um sistema, ele consegue adquirir um
comportamento emergente. Isso indica que certos componentes da funcionali-
dade do sistema só ficam evidentes quando disponibilizados juntos. Este com-
portamento pode ser projetado e necessita ser testado. Além disso, é necessário
que testes sejam desenvolvidos para analisar se o sistema esteja se limitando a
realizar somente aquilo que supostamente deve fazer.
Um questionamento pode ser realizado diante deste contexto: qual o mo-
mento ideal para finalizar os testes no sistema? Em boa parte dos sistemas é
extremamente complexo saber quanto é fundamental o teste de sistema e qual
o melhor momento para finalizar os testes. Não é possível realizar testes exaus-
tivos, dos quais cada sequência executável do programa seja de fato testada.
Nestas condições, os testes necessitam ser baseados dentro de um subconjunto
viável de casos de teste.

Teste de release
Um segundo estágio de teste de software é o teste de release, que,
segundo Sommerville (2011, p. 157), consiste no ato de testar um release
privativo de um sistema para ser utilizado fora da equipe de desenvolvi-
mento, ou seja, o que normalmente é para clientes e usuários. Dentro de
um projeto mais complexo, geralmente ele pode servir para outras equi-
pes que desenvolvem sistemas relacionados. Basicamente, existem duas
distinções importantes entre os testes de release e os testes de sistema ao
longo do processo de desenvolvimento: primeiramente, a equipe respon-
sável pelo teste de release é aquela que não esteve presente no processo
de desenvolvimento do sistema. A segunda distinção é que os testes de
sistema realizados pela equipe de desenvolvimento são centralizados na
busca por bugs no sistema, os chamados “testes de defeitos”. Isso indica
que o objetivo do teste de release é analisar se o sistema consegue suprir
os seus requisitos e se ele é bom para o uso externo.
O processo de teste de release visa persuadir o fornecedor
sobre a qualidade do sistema. Se isto de fato for uma condi-
ção verdadeira, o sistema pode ser apresentado como
um produto ou até mesmo disponibilizado a clientes,
desde que ofereça níveis de funcionalidade, desem-
penho e confiança determinados.
Testes baseados em requisitos

Os requisitos precisam ser testáveis, ou seja, o requisito precisa ser redi-
gido de tal maneira que um teste seja planejado para ele. Nesta condição, o
indivíduo responsável pelos testes irá observar se o requisito foi de fato aten-
dido. Os testes que se baseiam em requisitos, portanto, são con-
siderados uma abordagem sistemática destinada aos projetos
de casos de teste, de que o usuário considera cada requisito e
cria uma série de testes para eles.
Vamos pensar em um exemplo prático de requisi-
tos considerando o trabalho de um mecânico de auto-

móveis dentro de uma ofi cina, preocupado com a verifi cação de um ruído
proveniente do motor de um veículo. Se o carro apresenta um histórico de
falha e necessita, por exemplo, de um lubrifi cante especial, é preciso redigir
um relatório de aviso a ser emitido ao usuário do sistema geral ofi cina. Se o
usuário do sistema ignorar o aviso, é preciso que ele justifi que o motivo pelo
qual esse aviso foi ignorado.
Para observar se esses requisitos foram de fato atendidos, é preciso ela-
borar uma sequência de testes. No nosso exemplo, é preciso de imediato
definir alguma alteração na sua performance diante do tipo de lubrifi cante
utilizado. Caso existam alterações, os relatórios precisam ser emitidos em
forma de avisos ao usuário do sistema geral da ofi cina, para que ele forneça
um diagnóstico ao cliente final.
A que conclusão podemos chegar? É perceber que testar um requisito
não se trata apenas de escrever um único teste. Geralmente, é preciso re-
digir diversos testes para assegurar a cobertura dos requisitos, em que é
preciso manter registros de rastreabilidade dos testes que se baseiam em
requisitos, que unem os testes aos requisitos específi cos.
Teste de cenário
Podemos entender que o teste de
cenário é uma abordagem de teste de
release no qual o usuário idealiza ce-
nários para auxiliarem no desenvol-
vimento de casos de teste direciona-
dos ao sistema. Cenários devem ser
realistas, e usuários reais do sistema
devem ser capazes de se relacionar
com eles. Um teste de cenário deve,
dentre outros aspectos, estabelecer
uma relação entre os stakeholders e
acreditar na importância do sistema ser aprovado no teste. Estes testes pre-
cisam ser de fácil avaliação e, na ocorrência de problemas com o sistema, a
equipe responsável precisa identificá-los.

Caso um usuário se encontre na posição de testador de release, é neces-
sário observar a forma como o sistema se comporta quando são introduzidas
as entradas diferentes. O usuário pode cometer erros de maneira deliberada,
porém esses procedimentos verificarão a resposta do sistema às suas falhas.
É preciso que o usuário relate qualquer problema que venha a surgir, inclusi-
ve problemas ligados ao desempenho. Havendo lentidão no sistema, a forma
de utilizá-lo será diferenciada.
Testes de desempenho
Com a integração total do sistema existe a possibilidade de testá-lo para
propriedades emergentes, isto é, o desempenho e a confiabilidade estabe-
lecida. É importante salientar que os testes de desempenho são projetados
para garantir que o sistema processe as atividades destinadas a ela. Assim
como ocorre na execução de outros testes, os testes de desempenho normal-
mente demonstram que o sistema consegue atender os seus requisitos, no
que se refere à localização de problemas e falhas no sistema.
Segundo Sommerville (2011, p. 159), para comprovar se os requisitos de
desempenho estão sendo atendidos, será necessário, por exemplo, desen-
volver um perfil operacional. Trata-se de uma série de testes que indicam a
combinação efetiva de trabalho manipulado pelo sistema. A maneira mais efi -
ciente de encontrar os defeitos é projetando testes até os limites sistêmicos.
É o que denominamos dentro dos testes de desempenho como “estressar o
sistema” ao realizar demandas que se encontrem além dos limites de projeto
do software.
Este “teste de estresse” normalmente apresenta uma dupla funcionalida-
de: primeiro, é testar o comportamento de falha do sistema. Vale ressaltar
que as circunstâncias podem aparecer através de uma combinação espo-
rádica de situações, em que a carga exercida sobre o sistema
ultrapassa a carga prevista. Diante deste cenário, é essencial
que os erros do sistema não corrompam os dados ou causem
perdas de serviços do usuário.
A outra função é causar certo nível de “estresse” ao
sistema para apresentar defeitos que geralmente não

são revelados. Mesmo que existam argumentos que defendam que estes de-
feitos normalmente não são suscetíveis às falhas no sistema, podem surgir
combinações em que o teste de estresse possa ser replicado.
Para o entendimento de Sommerville (2011, p. 159), os testes de estres-
se são importantes para sistemas distribuídos que se baseiam em redes de
processadores. Esses sistemas geralmente entram em um processo de degra-
dação grave quando se encontram carregados, a rede se sobrecarrega com
dados que os processos precisam trocar, e estes processos vão se tornando
mais lentos no momento em que aguardam os dados solicitados de outros
processos. Cabe aos testes de estresse auxiliar na descoberta do início da
degradação, para que o usuário consiga adicionar controles ao sistema para
não aceitar operações além do limite estabelecido.
Teste de usuário
O teste de usuário é considerado um estágio em que usuários ou clientes dis-
ponibilizam entradas e conselhos sobre o teste de sistema. Ele é fundamental,
mesmo que a sua atuação ocorra em sistemas abrangentes ou até mesmo quando
os testes de release tenham ocorrido. Isso ocorre por conta das interferências no
ambiente corporativo do usuário que impactam, por exemplo, a confiabilidade e o
desempenho de um sistema.
O desenvolvedor de sistemas, neste contexto, não consegue replicar o ambien-
te de trabalho do sistema, já que os testes no ambiente do desenvolvedor são
artificiais. Os testes de usuário são subdivididos em:
• Teste alfa, pelo qual os usuários do software atuam em paralelo com a equi-
pe de desenvolvimento para realizar testes no software dentro do local do
desenvolvedor;
• Teste beta, pelo qual o release do software fica disponível aos usuários para
ser testado, além dos problemas encontrados pelos desenvolvedores do sistema;
• Teste de aceitação ao final, pelo qual clientes realizam testes no sistema,
visando a decidir a aceitação pela equipe de desenvolvimento de sistemas e
posteriormente serem implantados dentro do ambiente de clientes.
Nos testes alfa, os usuários e os desenvolvedores atuam conjuntamente
para realizar testes em um sistema desenvolvido. Isso indica que os usuários

conseguem reconhecer os problemas que normalmente passam despercebidos
para a equipe de testes de desenvolvimento. Os desenvolvedores atuam somen-
te por meio de requisitos, porém, por diversas vezes, estes requisitos acabam
não refletindo os fatores que afetam a utilização do software. Nesta condição,
os usuários conseguem disponibilizar informações referentes às práticas que co-
laboram com o projeto de testes, mais próximas da realidade.
Os testes alfa são constantemente utilizados no desenvolvimento de produ-
tos de software, além de auxiliarem a redução do risco de alterações inespera-
das neles que interfiram nos negócios. Porém, os testes alfa podem ser adotados
no momento em que o software customizado será desenvolvido.
Já no teste beta vamos observar que o mesmo acontece quando um release
antecipado de um sistema de software fica disponível a clientes-usuários para
que seja avaliado. Este tipo de teste é adotado em produtos de software utili-
zados em vários ambientes, ao contrário dos sistemas customizados. É pratica-
mente inviável para quem desenvolve produtos conseguir conhecer e replicar os
ambientes nos quais o software pode ser utilizado.
O teste beta é fundamental para verificar os problemas que envolvem a inte-
ração entre o software e os aspectos do ambiente no qual este produto é utiliza-
do. Podemos considerá-lo como um tipo de marketing, pelo qual clientes conse-
guem aprender sobre o funcionamento do sistema e o que pode ser feito por ele.
Por fim, há o teste de aceitação, que, segundo Sommerville (2011, p. 160), é
a parte considerada no desenvolvimento de sistemas mais customizados, que
normalmente ocorre depois do teste de release. Ele aborda o teste formal de um
sistema através de um usuário para verificar a sua aceitação. A aceitação, dentro
de uma organização corporativa, por exemplo, designa o pagamento que deve
ser realizado pelo sistema. Existem algumas etapas inerentes ao processo de
teste de aceitação, como na Figura 7.
Critérios Plano Resultados Relatório

Testes
de teste de teste de testes de testes
Negociar
Definir critérios Planejar testes Derivar testes Executar testes Aceitar ou
resultados
de aceitação de aceitação de aceitação de aceitação rejeitar sistema
de testes
Figura 7. O processo de teste de aceitação. Fonte: SOMMERVILLE, 2011, p. 160. (Adaptado).

A fase da definição de critérios de aceitação ocorre no início do processo,
antes da assinatura do contrato do sistema. O teste de aceitação adota crité-
rios inerentes ao contrato do sistema e que são definidos entre o cliente-usuá-
rio e o desenvolvedor. Um detalhe que não devemos deixar de tratar é o fato
de que na prática pode ser complexo escolher estes critérios na fase inicial do
processo, pois os requisitos detalhados muitas vezes não estão disponíveis,
além das possíveis alterações que estes requisitos sofrem ao longo do proces-
so de desenvolvimento.
Ao planejar os testes de aceitação a serem implantados, é preciso levar em
consideração alguns aspectos, como recursos e tempo, para realizar os testes
de aceitação e definir uma espécie de cronograma para a realização deles. Cabe
ao teste de aceitação debater sobre o atendimento dos requisitos solicitados, a
ordem de teste dos aspectos do sistema, definir os riscos aos quais o processo
de testes está sujeito e verificar uma forma de mitigar estes riscos.
Sobre o ato de derivar testes de aceitação, é preciso entender que, à medida
que os testes de aceitação são definidos, eles serão planejados para analisar a
existência ou não de um sistema aceitável. Os testes de aceitação visam a ates-
tar aspectos funcionais e não funcionais pertencentes ao sistema disponibilizan-
do a cobertura total dos requisitos de sistema, mesmo que na prática seja difícil
definir os critérios de aceitação.
Para executar testes de aceitação, é preciso compreender que esta ação deve
ocorrer dentro de um ambiente real em que o sistema será usado, porém al-
gumas vezes isso é inviável. Sendo assim, um ambiente de testes de usuário é
configurado para realizar esses testes. Vale frisar que automatizar esse processo
é algo complexo, pois parte dos testes de aceitação envolve testes de interações
utilizando usuários finais e o sistema.
Outro aspecto importante se refere à negociação dos resultados de teste,
que trata das possibilidades de se encontrar ou não qualquer falha no sistema.
Caso não for possível identificar qualquer possibilidade de erros
no sistema, o teste de aceitação estará completo e pronto para
a entrega. Entretanto, o que normalmente ocorre é encontrar
problemas. Sendo assim, cabe ao desenvolvedor e ao clien-
te estabelecer negociações para definir o status do siste-
ma e disponibilizá-lo ao público ou não.

Por fim temos o processo de aceite ou rejeição do sistema. Nesta fase, de-
senvolvedores e clientes se unem para decidir se o sistema será ou não aceito.
Caso se confirme que o sistema não é bom o suficiente, será necessário elevar
o nível de desenvolvimento para resolver os problemas visualizados. Ao con-
cluir esta etapa, a fase de testes de aceitação é repetida.

Sintetizando
Verificamos que o desenvolvimento de software está relacionado a um re-
quisito essencial: testes de validação. Estes testes têm o objetivo de apresentar
as funcionalidades de um programa e visualizar falhas antes do uso do progra-
ma. Observamos que o software testado no programa é realizado e os resul-
tados alcançados buscam erros ou informações de requisitos não funcionais
inseridos no programa.
Vimos que, ao desenvolver testes de software, um projeto pode ser enten-
dido como uma série de procedimentos formados por um conjunto de ativida-
des realizadas de forma organizada. A associação deste conceito ao desenvol-
vimento de um software nos traz a ideia da intangibilidade do produto, e que
apresenta uma série de variações.
Verificamos também que os testes são inseridos para finalidades diferentes
ou níveis que exigem esforço de trabalho. Normalmente, esses níveis se dife-
renciam graças à funcionalidade que são habilitadas de maneira mais efetiva,
para conduzir e projetar testes em que as técnicas são usadas.

PRESSMAN, R. S. Engenharia de Software. São Paulo: Pearson Education do
Brasil, 1995.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson Prentice
Hall, 2011.
VOCÊ ainda faz testes de software manuais? Postado por DevMedia.
(11min. 10s.). son. color. port. Disponível em: <https://www.youtube.com/
watch?v=fxL04i00jJw>. Acesso em: 21 jan. 2020.

UNIDADE
2 CLASSIFICAÇÃO DE
TESTE DE SOFTWARE

Conhecer as técnicas de teste de software de caixa-preta e de caixa-branca;
Compreender os tipos de teste mais comuns do mercado;
Aprender a realizar rotinas de testes em aplicativos;
Conhecer aplicações de testes.
Tópicos de estudo
Técnicas de teste de software Testes automáticos de software
Técnicas de teste de software na prática
caixa-preta Noções de Java
Técnicas de teste de software Teste de cálculos com
caixa-branca assertEquals
Teste de cálculos com
Tipos de teste de software assertTrue
Exemplos de testes de tipos de Sobre asserts e sobre as
software anotações jUnits

Técnicas de teste de software
Ao adquirir um produto, sempre testamos se seu funcionamento está
bom. Por exemplo, ao comprar uma televisão, testamos se os botões estão
funcionando e, caso não estejam, devolvemos ao estabelecimento no qual
compramos e pedimos outro em condições perfeitas. O mesmo ocorre com
softwares, no entanto, a empresa que fabrica o software não pode disponi-
bilizá-lo nas plataformas digitais sem antes ter a plena certeza que todos os
botões e mudanças de interfaces estão funcionando.
Ao testar um software, é necessário saber de algumas coisas. Imagine que
uma tela de saída que mostra o saldo de um cliente seja o resultado de vá-
rias outras telas de entrada. Para exemplificar, vamos dar nomes às telas:
a tela de saldo é o resultado das transações da tela transferências e da tela
de pagamentos, pois conforme o cliente move a conta, o saldo altera, logo,
a tela de saldo é uma tela de saída e a tela de transferências bancárias e a
tela de pagamentos são duas telas de entrada de informações. Seguindo
essa linha de raciocínio, para analisar erros no saldo, não adianta olhar ape-
nas a tela de transferências: é necessário checar se há erros nos scripts de to-
das as telas de entrada. Desse modo, deve-se verificar se há erros de cálculo
tanto na tela de pagamentos quanto na tela de transferências.
Além disso, cabe citar que existe um custo envolvido tanto para desco-
brir erros quanto para corrigi-los. Nesse sentido, pode-se dizer que o barato
pode sair caro; por exemplo: uma empresa pode investir muito dinheiro
para lançar um aplicativo nos sistemas Windows, Linux, Mac, Windows Pho-
ne, Android, iOS e verifi car, após o lançamento, que por falta de teste de
software o aplicativo não funciona bem no iPhone.
Embora muitas empresas acreditem que isto gere um custo desnecessá-
rio. , é necessário utilizar testes de software, a fim de evitar prejuízos nas
empresas. Apresentaremos, então, algumas técnicas para testar os
aplicativos. Normalmente, separa-se os testes em duas
classes de técnicas, a técnica de teste de caixa-pre-
ta e a técnica de teste de caixa-branca. Existem,
ainda, os testes de caixa-cinza, que muitos definem
como teste de caixa-preta e branca.

Técnicas de teste de software caixa-preta
Nos testes de caixa-preta, o testador não acessa os códigos, tampouco ana-
lisa o ambiente interior do código. Nesse tipo de teste, a análise ocorre somente
na interface externa.
Pode-se dizer o teste de caixa-preta abrange os níveis mais externos de
teste, pois consiste em uma análise da interface visual, e não do código. Veja,
a seguir, os exemplos de erros que os testes de caixa-preta avaliam:
• o programa possui campos de texto de formulário marcados como obriga-
tórios, mas não obriga o usuário a preenchê-los;
• o software possui campos de opção sim ou não, mas permite que o usuário
ative tanto o sim quanto o não simultaneamente;
• o programa permite campos de datas de nascimento com datas futuras;
• o sistema aceita valores campos de número, como quantidade e idade,
negativos;
• botões de mudança de tela não levam à tela correta;
• Existem NullPointers, ou seja, botões que não funcionam, links vencidos etc.
Já que essa técnica analisa os códigos externos, ela abrange os níveis mais ex-
ternos, ou seja, o programa por fora. Os níveis mais externos são: de integração,
de sistema, de aceitação, teste alfa e teste beta, conforme mostra o Diagrama 1.
DIAGRAMA 1. NÍVEIS DE TESTE PERTENCENTES À TÉCNICA CAIXA-PRETA
7 - Nível regressão: último a ser feito,

verifica se os outros testes mudaram algo.
6 - Nível beta: coloca o produto no mercado para que

o teste seja feito por um grupo maior de pessoas.
5 - Nível alfa: permite que um grupo menor de

Níveis de teste pessoas conhecidas testem o programa.
4 - Nível aceitação: o cliente testa o programa funcionando.
3 - Nível sistema: o pessoal de desenvolvimento

testa o programa funcionando.
2 - Nível de integração: testes de conexões entre telas.
1 - Nível unidade: primeiro a ser feito,

testa os códigos das unidades.

Ao analisar o Diagrama 1, pode-se notar que a ordem de testes de níveis é
realizada de baixo para cima e a técnica da caixa-preta analisa o programa por
fora, pois o tópico 1 analisa o programa por dentro, e os tópicos 2, 3, 4, 5 e 6
analisam o programa rodando por fora.
Técnicas de teste de software caixa-branca

Nos testes de caixa-branca, o testador acessa os códigos e analisa seus erros.
Os testes de caixa-branca podem ser de dois tipos e ter os seguintes subtipos:
• Cobertura lógica
• Cobertura de decisões;
• Cobertura de condições.
• Método dos caminhos básicos
Analisando testes de cobertura lógica –> cobertura de decisões, pode-
mos citar o seguinte exemplo: supondo que, para fazer uma compra de uma
prova de atletismo, a pessoa precise preencher um formulário, ter mais do que
18 anos e possuir nível médio em desempenho, considerando que existem as
opções iniciante, médio e avançado. Para esse exemplo, o programador criou
o seguinte código:
cobertura lógica –> cobertura de decisões
variavel_idade = int
variavel_nivel = String
se variavel_idade >=18 OU variavel_nivel == “médio” então imprima “Inscri-
to” e adicione ao banco de dados de “atletas nível inscritos”
O defeito lógico desse programa é o termo “OU”, pois a condição supunha o
atendimento a dois pré-requisitos para que o atleta conseguisse se inscrever, e
não apenas um ou outro requisito. Dessa forma, o testador precisa substituir o
critério “OU” pela condição “E”, conforme mostra o código a seguir:
variavel_idade = int
variavel_nivel = String
se variavel_idade >=18 E variavel_nivel == “médio” então imprima “Inscrito”
e adicione ao banco de dados de “atletas nível inscritos”
Cabe citar que int é igual aos valores numéricos inteiros e a String corres-
ponde aos valores em texto.

Agora que já abordamos a cobertura lógica de decisões, vamos analisar
a cobertura lógica – > cobertura de condições. Nesta última, podemos citar
o seguinte exemplo: uma pessoa está em um game Fifa e precisa escolher um
time para um campeonato que possui quatro times na semifinal, Alemanha,
Brasil, Itália e Nigéria. O script possui o seguinte esquema:
cobertura lógica – > cobertura de condições
variavel_time = String
uniforme_azul_branco_vermelho_ = Boolean
uniforme_vermelho_preto_amarelo = Boolean
uniforme_verde_branco= Boolean
caso variavel_time == “Itália”:
escolha uniforme_azul_branco_vermelho_ = TRUE
caso variavel_time == “Alemanha”:
escolha uniforme_vermelho_preto_amarelo= TRUE
caso variavel_time == “Nigéria”:
escolha uniforme_verde_branco = TRUE
Cabe citar que Boolean é um tipo de variável que retorna TRUE (verdadei-
ro) ou FALSE (falso). Além disso, é possível perceber que a opção “Brasil” está
ausente. Isso ocorre porque há muitos sites e programas que deixam espa-
ços sem programação, de modo que usuário não consegue realizar algumas
opções, como não conseguir voltar em algumas páginas. Quando isso ocorre,
dizemos que as condições não estão totalmente acobertadas, ou seja, existem
espaços nulos no sistema.
De acordo com os autores Pressman e Maxim, que publicaram o livro Enge-
nharia de software: uma abordagem profissional, em 2016:
Os testes caixa-branca focam a estrutura de controle do progra-
ma. São criados casos de teste para assegurar que todas as ins-
truções do programa foram executadas pelo menos uma vez du-
rante o teste e que todas as condições lógicas foram exercitadas
(p. 520).
Agora que já falamos da cobertura lógica de decisões e da cobertura ló-
gica de condições, vamos analisar o método dos caminhos básicos. Seu ob-
jetivo é fazer com que o programa tenha caminhos rápidos entre o comando
do usuário e a saída na tela. A vantagem desse método é simplificar o código,

uma vez que quanto mais simples e objetiva for a sequência de ações, mas fácil
será sua alteração.
O método de caminhos básicos realiza testes para avaliar a qualidade dos
fluxos através das seguintes ações:
• testar todos os caminhos do programa pelo menos uma vez;
• testar todas as condições de falso e verdadeiro;
• descobrir se o programa possui caminhos redundantes.
DICA
Existe um programa chamado FindBugs criado para testar erros automa-
ticamente. Esse programa é gratuito e existem tutoriais sobre baixá-lo e
manuseá-lo. Ele consegue descobrir rapidamente se há pontos nulos no
sistema, variáveis com nomes ruins, se as sessões são fechadas após o
usuário finalizar uma ação, entre outros.
A Figura 1 exemplifica um desenho de fluxo para um teste de caminho bá-

sico. Após realizar este fluxograma, o testador pode passar a fazer os testes em
cada nó e verificar se ele está fluindo corretamente. O objetivo não é entender
o código em si, mas como o método do caminho básico objetiva criar nós e
desenhar um fluxograma para descobrir quais fluxos devem funcionar, ou seja,
qual caminho o programa deve pegar. Uma vez descoberto o caminho ideal,
cabe ao testador avaliar cada nó.
3
1
2 3 4
10
4 13 11 5
5 6
12
7 6
8 7
8
9
10 9
11
12
13
Figura 1. Exemplo de método de caminhos básicos.

Cabe ressaltar, contudo, que existem alguns desenhos específicos para al-
guns formatos de estrutura condicional. Antes de montar o desenho, avalie
qual conjunto usar, de acordo com a Figura 2.
Se
While Repeat... until
Sequência
Nós do grafo de fluxo

Arestas do grafo de fluxo
Figura 2. Notação de grafo.
Desse modo, existem muitos itens a testar e é necessário criar um siste-

ma de organização para gerenciar todos esses testes. Recomenda-se começar
pelos testes de caixa-preta e, depois, passar para os de caixa-branca. Existem
vários métodos de organização, por exemplo, testadores que usam o MS Pro-
ject, que é um programa da Microsoft destinado a organizar agenda e projetos.
Existem, também, alguns métodos, como o método kanban, que organiza
as ações em quadros visuais afixados na parede, contendo ações a fazer, ações
iniciadas e ações concluídas. Outro ponto interessante é criar uma planilha de
controle. O Quadro 1 mostra um exemplo de planilha de controle de testes.
QUADRO 1. QUADRO DE CONTROLE DE TESTES
Software
Testador ##/##/##
Data de revisão
Método com Erro Data da

Nó Situação Responsável
erro específico correção
A documentação foi Método Inse- Faltou docu-
1 Não rirIntencao. mentar o mé-
feita corret amente?
corretamente? preencha(); todo apontado.
Os nomes dos arquivos,
2 Sim
classes e variáveis estão?
3 Existem campos falta ntes?
faltantes? Sim
Existe algum loop sem
4 Sim
condição de parada?
Existem pontos de
5 Sim
NullPointer não tratados?

Erro Data da
Nó Situação Método com erro Responsável
específico correção
Existe algum
Método PagarCom- A função IF está sem o
6 erro de Não
Cartao.preencha(); segundo parâmetro.
Cartao.preencha();
condição
condição?
As funções lógicas da
Existe algum Método Cadastro. interface cadastro es-
7 erro de cobertu- Não
preenc ha();
preencha(); tão sem a opção para
ra lógica?
telefones estrangeiros.
Existe o trata-
trata- Não está realizando
Método PagarDe-
8 mento de exce- Não o tratamento de ex-
pois.preencha();
ções? ceções.
9 - Sim
10 - Sim
Tipos de teste de software

Existem alguns tipos de teste de software e cada tipo pode pertencer à téc-
nica caixa-branca, à caixa-preta ou às duas caixas. Pode-se antecipar que, neste
momento, abordaremos os seguintes tipos:
• teste de funcionalidade;
• teste de desempenho;
• teste de usabilidade;
• teste de segurança;
• teste de configuração;
• teste de falhas e recuperação;
• teste de carga ou de estresse.
Para não confundirmos os conceitos, vamos recapitular: já vimos até agora
o que são níveis de teste, técnicas de teste e agora veremos os tipos de teste.
Os níveis correspondem à abrangência do teste (unidade, integração, sistema,
aceitação, alfa, beta e regressão), as técnicas correspondem ao modelo de abor-
dagem interno ou externo (caixa-branca e caixa-preta), e os tipos de teste, que
são nossos atuais objetos de estudo, podem ser definidos, de acordo com Rios e
Moreira, no livro Teste de software II, publicado em 2013:
Cronograma Básico: deve ser elaborado um cronograma
genérico que em linhas gerais estabeleça os prazos esti-
mados para execução dos testes ou das fases de testes,
de acordo com o projeto de desenvolvimento. Ambiente
de teste: Devem ser listadas as necessidades básicas de

ambiente, tais como equipamentos, softwares, pessoas e
ferramentas, sem ainda estabelecer detalhes. Abordagem
dos testes: Considerando-se os quatro testes básicos (uni-
tário, integração, sistema e aceitação) devem ser acorda-
das as responsabilidades de cada uma das partes pela sua
execução. Por exemplo, os testes de sistema só podem se
iniciar após a execução dos testes unitários e de integração
efetuados pela equipe de desenvolvimento (p. 72).
O teste de funcionalidade verifica se o programa está funcionando normal-
mente, checando as seguintes dúvidas: o e-mail está conseguindo receber e en-
viar mensagens? O botão de gravar está enviando os dados ao banco de dados?
A opção de salvar está funcionando? O programa permite salvar dados sem ao
menos o usuário digitar? O jogo pode ser pausado e reiniciado do ponto onde
estava? Dessa forma, o teste é realizado sob a ótica do usuário final.
O teste de desempenho verifica eficiência do programa, isto é, o tempo gas-
to. Para realizar tarefas, por exemplo, o tempo gasto para enviar um e-mail, o
tempo gasto para fazer uma transferência, o tempo gasto para um robô respon-
der o chat, o tempo gasto para fazer uma transferência, tempo de postagem de
fotos na rede social etc. O tempo afeta diretamente a qualidade do uso do soft-
ware e os usuários podem ficar insatisfeitos caso o sistema esteja muito lento.
Uma dúvida comum pode ser exprimida da seguinte maneira: quando
muitos usuários entrarem ao mesmo o sistema, ele pode ficar lento? Para
responder a essa e a outras questões, existem dois programas úteis e fa-
mosos para a realização testes de desempenho em software: um deles é o
jmeter e o outro é o WebLOAD. Ambos foram criados para testar a eficiên-
cia das aplicações.
Os dois programas simulam desempenho, permitindo ao testa-
dor checar como o programa responde com uma quan-
tidade “x” de usuários ao mesmo tempo. Além disso,
esses programas possuem temporizador, sendo
possível calcular quanto tempo levou a navegação
completa, além de gerar gráficos e relatórios.
A Figura 3 mostra a área de trabalho do pro-
grama jmeter, que possui, no campo esquerdo, as

ações “ir para home page”, “clicar no botão entrar”, “adicionar botões” etc. Na
área da direita, ele mostra resultados como o desempenho médio, desempenho
máximo, mínimo etc.
Figura 3. Captura de tela do aplicativo jmeter.
O teste de usabilidade serve para testar a experiência. Muitos autores

definem usabilidade com a utilidade, ou seja, quão útil é um sistema, logo,
de nada adianta ter um programa muito bonito e, ao mesmo tempo, inútil.
Sendo assim, é importante descobrir as necessidades do cliente ou da em-
presa que irá usar esse programa. Outro ponto fundamental é a escolha de
cores, leiautes e logo, uma vez que ele deve ter uma aparência agradável. No
aspecto estético, a navegação deve ser intuitiva e divertida.
É importante ressaltar os pontos de desistência de uma ação, por
exemplo, supondo que um usuário queira cancelar uma compra ou voltar
para uma tela, essa opção deve estar sempre presente. Para isso, é inte-
ressante a criação de atalhos, pois usuários mais experientes gostam de
utilizá-los. O teste de usabilidade também avalia se as respostas que o
programa gera para o usuário são pertinentes, úteis e, ao mesmo tempo,
de fácil entendimento.
Uma recomendação é fazer testes de usabilidade por meio da aná-
lise de expressões faciais. Esse teste funciona da seguinte maneira: são
selecionadas algumas pessoas que tenham o perfil do público-alvo para in-
teragir, em uma sala, com o aplicativo em teste. Essas pessoas, cientes de
que estão sendo filmadas, começam a mexer nesse aplicativo, instalado em
um computador. Em outra sala, os testadores filmam a tela e as expressões

desses usuários, conseguindo captar não apenas suas dificuldades ao ma-
nusear o programa, como também suas reações. O teste de usabilidade é
bem comum em grandes empresas.
O teste de segurança avalia se o sistema tem vazamento de dados ou
ausência de criptografia. Há empresas que contratam hackers para tentar
achar brechas no sistema operacional e, então, descobrir as falhas do sistema.
ASSISTA
Para conhecer alguns exemplos de teste de softwares,
assista ao trailer do filme Snowden: herói ou traidor. Esse
filme mostra a operação de diversos testes de software
nos EUA feitos por hackers contratados por empresas de
segurança do país.
O teste de configuração é útil para descobrir se o software funciona do

mesmo jeito em outros sistemas operacionais e em outros aparelhos e máqui-
nas. Um sistema deve ser adaptável, isto é, deve funcionar em vários sistemas
e computadores diferentes. Por isso, é muito importante testar não apenas a
instalação, como também o comportamento do programa em máquinas de
memória interna e em discos com tamanhos diferentes.
O teste de estresse ou de carga coloca o programa em situações extremas. Por
exemplo, imagine que muitos usuários acessam um sistema ao mesmo tempo, ou
então que muitas pessoas estão usando a rede da empresa ao mesmo tempo; essas
situações devem ser simuladas para saber até que ponto o sistema suporta tais car-
gas. Além disso, outras situações devem ser testadas, como a operação do software
em um sistema com pouca memória ou com ausência de recursos compartilhados.
O teste de falhas e recuperação avalia se o software consegue salvar os dados
caso haja uma queda de energia ou de rede. Essa queda pode ocorrer no cliente
e no servidor, por isso, o teste de falhas deve avaliar se os programas guardam as
últimas operações. Uma ação importante que os softwares precisam avaliar é a sin-
cronização do aplicativo no computador local com a nuvem, por exemplo, avaliar se
as fotos do celular são armazenadas na nuvem em forma de backup diariamente.
Técnicas como desligar o computador no meio de um processo, desligar o servidor
sem salvar um arquivo ou desligar a rede em uma transação ajudam a avaliar se o
sistema está protegido.

Exemplos de testes de tipos de software
Os testes podem ser feitos por meio de revisão visual ou de programas auto-
matizados, como o JUnit. Neste momento iremos exemplificar algumas formas
práticas de fazer os tipos de testes citados e abordar exemplos de testes de fun-
cionalidade e de usabilidade.
Para realizar o teste de funcionalidade, pode-se usar o seguinte método,
conforme mostra a Figura 4.
Figura 4. Captura de tela com dados de teste de funcionalidade.
Conforme mostra a Figura 4, é recomendável fazer essa tabela no Excel.

Além disso, muitas multinacionais que utilizam esse controle de planilha in-
cluem outra aba, mostrando a imagem de cada ação testada a fim de facilitar
a revisão dos testes.
Para realizar o teste de usabilidade, pode-se usar o mesmo modelo de tabe-
la, alterando os campos e textos, conforme Figura 5.

Figura 5. Captura de tela com teste de usabilidade.
Testes automáticos de software na prática

A partir de agora, iremos abordar a parte prática e técnica dos testes de softwa-
re. Muitos programadores acham a parte prática muito divertida, assim, para prati-
car, utilizaremos o programa Eclipse.
Para fazer testes de software, é necessário saber programar, desse modo, mos-
traremos algumas noções de Java e, depois, passaremos a parte prática de testes.
Noções de Java
Para compreender o teste que iremos mostrar na prática, é necessário
conhecer o mínimo de Java e a extensão JUnit. Por isso, mostraremos e ex-
plicaremos aqui duas classes em Java e, mais adiante, as classes em JUnit,
programa de teste de software. Agora, explicaremos classe CalculoCompra

e a classe Senha, ambas na linguagem Java. Observe o script da classe Cal-
culoCompra:
public class CalculoCompra {
public int soma(int precoBrinquedo, int precoBlusa) {
return precoBrinquedo + precoBlusa;
}}
Nesse script, a classe é pública e se chama CalculoCompra; nela, existe
um método público chamado soma, o qual cria a variável precoBrinquedo
e a variável precoBlusa. Essas variáveis são do tipo int, ou seja, números
inteiros. O método soma vai retornar a soma do preço dos dois valores caso
o cliente queira levar os dois.
Observe agora o script da classe Senha em java:
public class Senha {
public boolean comparaSenha (String senha, String confirmacaoSenha){
if(senha.equalsIgnoreCase(confirmacaoSenha)){
return true;
}
else{
return false;
}}}
Nesse script, a classe é pública e se chama Senha; nela, existe um mé-
todo público chamado comparaSenha, que cria a variável Senha e a va-
riável confirmacaoSenha. Essas variáveis são do tipo String, ou seja, são
textos. If é usado para situações nas quais algo é atingido. Dentro dos
parênteses do If, está escrito o seguinte comando: se a senha for igual à
sua confirmação, o sistema retornará sob o comando True, ou seja, ele é
verdadeiro. Logo, o usuário poderá entrar no sistema. O comando Else
significa “senão”, ou seja, se a senha não for igual à sua con-
firmação, o usuário não entra no sistema. Logo, ele retorna
para o comando False, ou seja, é falso.
Para fazer o teste dos códigos java citados, será neces-
sário usar um programa chamado Eclipse. Trata-se
de um programa gratuito de desenvolvimento de
softwares em linguagem Java e outras linguagens.

É muito simples utilizá-lo. Em primeiro lugar, baixe a dependência Java
e, em seguida, baixe o programa Eclipse. Instale a dependência e o Eclip-
se; algumas vezes, o Eclipse precisa ser executado com o sistema no modo
administrador. A Figura 6 mostra um site para instalar o Java e, depois, o
Eclipse. Após instalarmos os dois, usaremos uma dependência do Eclipse
chamada JUnit, que serve justamente para testes.
CURIOSIDADE
O programa Eclipse roda diversas linguagens de programação; ele funcio-
na com a linguagem Java, linguagem C++, linguagem C#, JavaScript, Php
etc., por isso, é uma plataforma útil para testes de software. Existe tam-
bém o programa NetBeans, que é bem parecido com o Eclipse e também
trabalha com várias linguagens.
Figura 6. Captura de tela com instalação Eclipse.
Teste de cálculos com assertEquals

Imaginemos um cenário bem simples: uma pessoa escolhe dois produtos e o
sistema precisa testar se a soma desses produtos está correta. Criaremos duas
classes em Java: a classe CalculoCompra e a classe CalculoCompraTeste, con-
forme mostra o Quadro 2. No teste, o preço do brinquedo é R$ 100,00 e o preço
da blusa é R$ 200,00. A soma deve dar R$ 300,00. No dia a dia, os programadores

usam apenas classes como a CalculoCompra e a outra é criada para testes. Ge-
ralmente, a classe de testes é nomeada com a palavra “teste” no final. Por exem-
plo: a ClasseCadastro será testada com a classe ClasseCadastroTeste.
A classe CalculoCompra, neste exemplo, possui duas variáveis que são nú-
meros inteiros: a variável brinquedo e a variável blusa. A classe possui o mé-
todo soma; ele está somando o valor do brinquedo com o valor da blusa, pois
no nosso exemplo, o usuário está levando os dois produtos. Desse modo, a
classe CalculoCompraTeste chama a classe CalculoCompra e testa se a soma
dos dois objetos resulta em 300. A função assertEquals verifica se a soma dos
dois valores da ClasseCompra fica igual a 300.
QUADRO 2. CLASSES PARA TESTE DE SOFTWARE
Classe CalculoCompra Classe CalculoCompraTeste
class CalculoCompraTeste {
public class CalculoCompra {
@Test
void Addtest() {
public int soma(int brinquedo,
soma(int brinquedo int CalculoCompra junit = new Cal-
blusa) {
blusa culoCompra();
return brinquedo+blusa;
brinquedo+blusa
int result = junit.soma(100,
junit.soma(100, 200);
}} assertEquals(300, re-
sult);
}}
Agora será demonstrado como executar esta operação no Eclipse. Primei-

ramente, abra o Eclipse, crie um novo projeto e coloque o nome de Primeiro-
Teste. Depois crie uma classe ao clicar, com o botão direito, no projeto Primei-
roTeste. O nome da classe será CalculoProduto, conforme mostra a Figura 7.

Figura 7. Captura de tela que mostra como criar a classe CalculoProduto.
Abra a classe CalculoProduto e digite a sintaxe a seguir:

public class CalculoProduto {
public int multiplicacao(int Preco, int Quantidade) {
return Preco * Quantidade;
}}

Como é possível perceber, o método muliplicacao multiplica a quantidade
de produtos pelo preço.
Em seguida, é necessário criar um teste com o JUnit. Para criá-lo, é necessá-
rio clicar com o botão direito na classe CalculoProduto e, em seguida, clicar e
NEW – JUnit Teste Case. Esse teste criará uma classe cujo nome pode ser Cal-
culoProdutoTeste. Ela irá verificar se a multiplicação está correta, conforme a
Figura 8.
Figura 8. Captura de tela que mostra como criar a classe de teste CalculoProdutoTeste.

A cada alteração no código, aperte Ctrl+s para salvar as classes e garantir a
efetivação do processo. Abra a classe CalculoProdutoTeste e digite a seguinte
sintaxe:
import static org.junit.jupiter.api.Assertions.*;
class CalculoProdutoTeste {
@Test
void Addtest() {
CalculoProduto junit = new CalculoProduto();
int result = junit.multiplicacao(20, 3);
assertEquals(60, result);
}}
Primeiramente, copie os códigos para as duas classes, porém vamos testar o
resultado da multiplicação de 2 x 30 = 20, para forçar o erro conforme a Figura 9.
Figura 9. Captura de tela com resultados de testes para resultado errado, o certo seria 60 no lugar de 20.
Agora, iremos fazer o Debug para executar o teste e, então, o resultado será
mostrado. Para isso, clique com o botão direito na ClasseProdutoTeste e faça o
Debug com o 1 JUnit Test, conforme mostra a Figura 10.
A Figura 10 mostra o erro em vermelho, portanto, caso colocássemos 20 no
lugar de 60 como resultado esperado, a barra ficaria vermelha escura e aparece-
ria um status de uma falha. Caso desse certo, a barra ficaria verde.

Figura 10. Captura de tela com resultados de testes para resultado errado com o valor de 20, e um exemplo com teste
correto com a cor verde.
Teste de cálculos com assertTrue

Vamos abordar, agora, testes práticos relacionados a condições lógicas. Já vimos
que existe o assertEquals, que verifica se o valor gerado é igual ao valor esperado.
Todavia, existem outros parâmetros: é possível usar o assertTrue para validar tex-
tos, por exemplo. Será que o programa exige realmente que a senha digitada
pelo usuário e a confirmação de senha sejam iguais?

Observe a classe Senha e crie-a no Eclipse conforme o seguinte procedimento:
Classe Senha
public class Senha {
public boolean comparaSenha (String senha, String confirmacaoSenha){
if(senha.equalsIgnoreCase(confirmacaoSenha)){
return true;
}
else{
return false;
}}}
Como pode ser visto, a classe Senha faz a seguinte verificação: Se (If) a variável
Senha for igual à variável confirmacaoSenha, retorne para o comando verdadeiro
(True). Caso contrário, retorne para o comando falso (False).
Agora, para testar esse script, basta criar uma classe de teste de acordo com os
passos a seguir:
1. Clique com botão direito na classe Senha;
2. Clique em New - JUnit Case Teste;
3. Coloque o nome dessa classe como SenhaTeste;
Após criar a classe de teste, digite o seguinte script:
Classe SenhaTeste
import static org.junit.jupiter.api.Assertions.*;
import org.junit.jupiter.api.Test;
class SenhaTeste {
@Test
void test() {

Senha teste = new Senha();
assertTrue(teste.comparaSenha(“1452”,”1452”));
}}
A classe SenhaTeste irá avaliar se a classe Senha está realmente compa-
rando as duas senhas por meio do comando AssertTrue. A resposta esperada
é a barra verde, pois 1452 é igual a 1452. Além disso, erros podem ocorrer por
várias razões, por exemplo, quando classes que não prestam atenção se a le-
tra está maiúscula ou minúscula. Outro erro comum pode ocorrer no próprio

código-fonte da classe. De uma forma ou de outra, para evitar problemas no
aplicativo, é sempre bom testá-lo.
Sobre asserts e sobre as anotações jUnits

O assertEquals serve para comparar valores de
igualdade. Por exemplo, suponha que um usuário
chamado Marcos faça log-in e, em seguida, apareça
uma tela dizendo “Bem-vindo, Marcos”. Tendo isso
em mente, o assertEquals irá verificar se o nome está
igual ao nome digitado na hora de entrar no sistema.
O assertFalse testa se um valor fica como falso. Por exemplo, em uma tela
de log-in, uma pessoa é obrigada a digitar seu nome de usuário e senha. Além
disso, para ter mais segurança, o programa faz um teste com captcha de iden-
tificação. Se o usuário digitar o captcha errado, deve ativar a função False,
impedindo-o de fazer log-in. Assim, o assertFalse verifica se realmente o
comando adequado está sendo gerado.
O assertNotNull testa se um valor não é nulo. Por exemplo, após um usuá-
rio digitar seu CEP, o programa deve gerar um valor para frete. Caso o sistema
gere um valor nulo, isso significa que o sistema está com mau funcionamento.
No entanto, se um usuário pode digitar um CEP errado, seria normal o siste-
ma gerar um valor nulo? Não, pois o sistema deve dar cobertura a todas as
alternativas. Sendo assim, caso ele digite um CEP com menos números ou
inexistente, o sistema deve alertar o usuário sobre o erro e jamais deixar em
branco ou nulo.
O assertNotSame é um teste muito interessante no qual cada objeto do
software possui códigos de memória. Vamos supor que Juliana possua o CPF
833.345.232-33 e que este CPF esteja registrado no sistema. Caso outra pes-
soa tente se cadastrar com o mesmo CPF, o assertNotSame marcará como
errado, ou seja, ele só aceita objetos diferentes.
O assertTrue faz o inverso do assertFalse, ou seja, o teste só passa se a
expressão for verdadeira. Muitos o confundem com o assertEquals, embora
haja diferenças: enquanto o assertEquals verifica se um resultado é igual ao
esperado, o assertTrue verifica se o teste do programa deu verdadeiro.

De modo semelhante, o assertSame faz o inverso do assertNotSame, pois
enquanto o assertNotSame permite apenas com CPFs diferentes, o assertSame
permite apenas objetos iguais. Como exemplo podemos citar aqueles casos
nos quais uma pessoa tenta entrar no e-mail e o sistema pede confirmação
do celular.
Além de existir os asserts, existem as anotações do Junit. Para quem qui-
ser se aprofundar nesse ramo profissional, elas são muito importantes. Como
exemplo, podemos mencionar a anotação @Test para fazer testes, a anotação
@Before, que serve para preparar o ambiente do teste, a anotação @After-
Class, entre outros.

Sintetizando
Com o objetivo em se aproximar da prática, essa Unidade abordou a utilidade
do teste de software. Desse modo, foi dito que é recomendável gastar uma fatia de
tempo e dinheiro para fazer testes, pois muitas vezes a falta de testes pode resultar
em problemas com o público-alvo e necessidade de refazer o código.
Falamos, também, sobre as técnicas de teste de software. Nesse contexto, divi-
dimos a classe “teste de software” em “classe caixa-branca” e “classe caixa-preta”. A
caixa-branca analisa o programa internamente, ou seja, analisa o código, verificando
se ele possui algum erro de cobertura ou de condição.
Erros de cobertura fazem com que o código despreze alguma situação, por exem-
plo, o programa pode não calcular o frete para um dos estados cadastrados no siste-
ma. Já erros de condição lógica fazem um caminho errado, por exemplo, após clicar
no botão adicionar, o sistema multiplica. Cabe ressaltar que a caixa-branca avalia o
código em si e a caixa-preta, por outro lado, é um teste que avalia o programa externa-
mente, do ponto de vista de usuário. Assim, foi visto que o teste de caixa-preta é feito
em níveis de testes externos do programa, como testar se botões estão levando à tela
certa, se tem algum problema na hora de preencher formulários etc.
Como foi visto, existem vários tipos de teste de software; vimos que o teste de
funcionalidade verifica se o programa funciona bem, e que o teste de usabilidade
avalia a experiência do usuário. Além disso, vimos que o teste de estresse avalia
como o programa se comporta caso muitos usuários acessem o mesmo recurso ao
mesmo tempo e que o teste de falhas e recuperação que avalia como o programa
salva os dados caso acabe a energia ou a internet. Para concluir, vimos que o teste de
segurança avalia se há brechas no sistema e também aprendemos sobre a utilidade
dos testes de desempenho e de configuração.
Vimos, também, exemplos práticos de rotinas de testes no Excel e operações de
testes do programa Eclipse, através da linguagem Java, o que é muito importante
para profissionais que desejam fazer testes que checam se as funções de igualdade
e de cálculo funcionam corretamente. Para isso, abordamos a forma
de instalação do Eclipse, bem como a criação de um exemplo práti-
co de teste com a função assertEquals; esse documento teve como
objetivo preparar o profissional para adentrar no mundo dos testes,
que usa, com bastante frequência, a extensão JUnit.

PRESSMAN, R.; MAXIM, B. Engenharia de software: uma abordagem profissio-
nal. 8. ed. São Paulo: McGraw Hill Brasil,1998.
RIOS, E.; MOREIRA, T. Teste de software II. São Paulo: Alta Books, 2013.
SNOWDEN – HERÓI OU TRAIDOR. Publicado por Telecine. (2 min. 19 s.). color.
son. eng. leg. Disponível em: https://www.youtube.com/watch?v=cJkp4blUyl8.
Acesso em: 22 jan. 2020.
ZADROZNY, B. Engenharia de software II. Paraná: UFF, 2006.

UNIDADE
3 CASOS DE TESTES:
CONCEITOS
FUNDAMENTAIS

Apresentar as características da extração de casos de teste, evidenciando
seus conceitos e aspectos principais;
Abordar o processo de criação de casos de teste e suas principais

funcionalidades;
Observar o processo de automação de testes, verificando seus principais

conceitos, tipos e vantagens
Debater aspectos do gerenciamento de defeitos, apresentando métodos e

técnicas utilizados.
Tópicos de estudo
Extração de casos de teste Automação de testes
Regras de extração de casos Testes automatizados
de teste Principais ferramentas de auto-
Exemplos de extração de casos mação de testes
de teste Desafios benéficos da automa-
ção de testes
Criando casos de teste
Geração de casos de testes do Gerenciamento de defeitos
tipo caixa-preta Processo de gestão de defeitos
Geração de casos de testes Ciclo de vida de um defeito
automática Relatório de defeitos
Geração de casos de testes em
tarefas

Extração de casos de teste
Podemos considerar a especifi cação das expectativas criadas por um in-
vestidor como um aspecto que interfere signifi cativamente na capacidade
de equipes de projeto de garantir suas solicitações dele em relação ao soft-
ware. Mesmo sem a definição destas especifi cações de requisitos, os casos
de teste são métodos capazes de auxiliar a formação das expectativas que
os investidores criam, possibilitando que elas sejam analisadas e validadas.
A equipe responsável pelos testes precisa planejá-los, de modo que
os requisitos sejam validados apropriadamente no momento em que um
conjunto de requisitos se encontre disponível. A validação do software em
comparação aos requisitos é realizada de maneira distinta, a depender do
modelo de requisito.
Observaremos nos subtópicos a seguir as principais regras e a deter-
minação para extrair casos de teste em softwares e os principais tipos de
exportação aplicados.
Regras de extração de casos de teste

Para tratarmos da extração de casos de teste, precisamos entender que
um caso de teste tem a finalidade imediata de solucionar um questionamento:
o que vamos testar? O usuário do sistema desenvolve um caso de teste visan-
do estabelecer o que será validado, para assegurar o funcionamento correto
aliado a um nível de qualidade elevado. Dentro desse contexto, um conceito
devemos entender: o de suítes de teste, que consiste na coleção de casos de
teste agrupados para executá-los.
Há uma expectativa de que as suítes de teste planejadas juntamente com os
requisitos sejam capazes de orientar a fase de desenvolvimento do software,
disponibilizando informações anteriores em relação ao fluxo de casos de teste
que serão executados, o que pode elevar o nível de qualidade dos componentes
que serão elaborados.
Os modelos de processos precisam ser detalhados em nível elevado, para
que as regras de extração dos testes sejam aplicadas, permitindo o destaque
dos componentes operacionais de cada atividade do processo. Tais regras po-

dem ser implementadas a partir da aquisição de requisitos candidatos, que se
baseiam basicamente em três passos:
1. Seleção de atividades: é a seleção das atividades que podem ser reali-
zadas pelo sistema, por indivíduos que o utilizam, ou através de atividades ma-
nuais passíveis de automatização. As atividades classificadas como manuais e
que não forem consideradas para a automatização serão descartadas, por não
possuírem os requisitos determinados;
2. Identificação dos requisitos candidatos: consiste na fase em que os mo-
delos de processos relacionados aos negócios são avaliados considerando uma
série de heurísticas, que são responsáveis por analisar a estrutura e a semântica
dos modelos de processos;
3. Consolidação de requisitos candidatos: consiste na fase em que os re-
quisitos candidatos observados na etapa anterior são analisados, e são geradas
informações referentes, por exemplo, aos sistemas que poderão invocá-los.
A análise da estrutura está baseada em padrões de workflow e supre todas
as possibilidades existentes de fluxos de atividades simbolizadas por um modelo
de processo. Em relação à avaliação semântica, podemos levar em consideração
os componentes pertencentes aos modelos, como o requisito de negócios. A se-
mântica destes elementos vai apontar as funcionalidades implementadas nos
serviços que apoiam o processo.
No momento posterior à identificação dos requisitos candidatos, existe a
possibilidade de estabelecer a extração dos casos de teste, através dos seguin-
tes procedimentos:
1. Definir a modelagem dos processos de negócio;
2. Aplicar os métodos de identificação de requisitos;
3. Determinar os casos de teste por métodos de criação de casos de testes
utilizados em outros modelos.
Neste terceiro passo, as heurísticas que visam à aquisição dos casos de teste
são utilizadas (SOUSA et al., 2014). Vamos ver quais regras são utilizadas.
Heurísticas de requisitos básicos (HRB):
• HRB1: um requisito candidato deve ser identificado da regra de negócio;
• HRB2: um requisito candidato precisa ser identificado para cada informa-
ção de entrada de uma tarefa (requisito de leitura). Da mesma maneira, um re-
quisito candidato de dado precisa ser identificado para cada informação de saída

de uma atividade (requisito de escrita) desde que as informações se encontrem
relacionadas a portadores de informação;
• HRB3: um requisito candidato precisa ser inserido para cada atividade au-
tomatizada.
Heurísticas de padrão de workflow (HPW):
• HPW1: um requisito candidato precisa ser identificado de uma série de ati-
vidades executadas, de maneira sequencial e automatizada, ou apoiadas por um
sistema;
• HPW2: um requisito candidato deve ser identificado de uma estrutura do
workflow em que tarefas podem ser realizadas de maneira repetitiva.
Heurísticas de cobertura de cenários (HCC):
• HCC 1: um fluxo de cenário é identificado no momento em que existir uma
sequência de tarefas executadas entre um evento inicial e um final. Na possibili-
dade de haver diversos fluxos a serem seguidos, todos deverão ser levados em
consideração;
• HCC 2: um fluxo de cenário é identificado quando existir uma sequência de
tarefas executadas entre eventos, independentemente de sua localização, por
exemplo, entre eventos inicial e intermediário ou eventos intermediário e final.
Por fim, a mensuração da efetivi-
dade presente nos casos de testes é
proposta através do uso de critérios de
cobertura (CC):
• CriCob1: todos os requisitos iden-
tificados pelas heurísticas precisam ser
levados em consideração nos casos de
teste, no mínimo uma vez, em um flu-
xo retirado do processo direcionado a
negócios;
• CriCob2: todos os fluxos identifi-
cados pelas heurísticas devem ser con-
siderados, nos casos de teste, no mínimo uma vez.
Ao final, profissionais da área de desenvolvimento de software precisam ana-
lisar a lista final que pertence aos casos de teste, visando identificar o que de fato
pode ser aplicado às suas demandas por teste.

Exemplos de extração de casos de teste
Para observar os exemplos de extração dos casos de teste, precisamos observar
as técnicas de derivação adotadas. Quando tratamos da derivação dos casos de tes-
te provenientes dos casos de uso, os casos de uso são vistos como uma técnica de
busca de requisitos inserida, de imediato, no método Objectory, sendo já considera-
dos componentes essenciais da linguagem de modelagem unificada (UML).
Segundo Sommerville (2011, p. 74), um caso de uso consegue identificar os
elementos que se encontram envolvidos em uma interação e o nome atribuído
a ela. A interação, por sua vez, é baseada em informações que são acrescidas
para descrevê-la com o sistema. A informação adicional pode ser apresentada
em forma de uma descrição textual ou até mesmo um conjunto de modelos grá-
ficos, como um diagrama de sequência. Os casos de uso são documentados em
diagramas de nível elevado.
Os casos de uso simbolizam as prováveis interações que serão apresentadas nos
requisitos do sistema. Não existem diferenças entre cenários e casos de uso que
atuam de maneira simplificada e rápida. Alguns usuários do sistema podem consi-
derar os casos de uso como cenário único, entretanto outros usuários encapsulam
diversos cenários dentro de como único caso de uso. Estes casos podem realizar
interações individualizadas entre os sistemas ou com os seus usuários, e todo caso
de uso precisa ser documentado utilizando uma descrição textual que pode ser rela-
cionada a outros modelos UML, criando um cenário com maior detalhamento.
Diante desse contexto, os casos de teste direcionados a um teste funcional
são derivados dos casos de uso, para a qual se destina o teste. É preciso criar um
conjunto de casos de teste para cada cenário desenvolvido de um caso de uso.
Por sua vez, os cenários de caso de uso são reconhecidos através da apresenta-
ção de alternativas que seguem o fluxo básico, até finalizá-lo.
Vamos observar na Figura 1 a presença de fluxos básicos e alternativos, em
um caso de uso, simbolizados por setas. O fluxo básico se caracteriza como uma
alternativa mais simples no caso de uso, já o fluxo alternativo se origina do fluxo
básico e, diante de uma condição específica, será executado posteriormente. É
importante salientar que um fluxo alternativo pode retornar a um básico, se for
originário de outro fluxo alternativo, ou até mesmo encerrar o caso de uso sem
retornar a um fluxo.

INICIAR
CASO DE USO
Fluxo básico
Fluxo alternado 3
Fluxo alternado 1
Fluxo alternado 4
Fluxo alternado 2
ENCERRAR ENCERRAR
CASO DE USO CASO DE USO
ENCERRAR
CASO DE USO
Figura 1. Fluxos de eventos em um caso de uso. Fonte: MINISTÉRIO DA CULTURA, 2006.
Outro modelo de extração de casos de teste vem da derivação destes casos

em especificações suplementares. Nem todos os requisitos de uma destinação
do teste serão apresentados nos componentes de requisitos funcionais, como as
especificações de casos de uso. Diante desse cenário, os requisitos não funcio-
nais e os de configuração acabam especificando aspectos adicionais do destino
do teste, como veremos a seguir.
Derivando casos de teste para testes de desempenho
As especificações suplementares que apresentam os requisitos do tipo “não
funcionais” são consideradas a entrada principal destinada aos casos de teste de
desempenho. Ao adquirir casos de teste direcionados ao teste de desempenho,
é preciso adotar as seguintes diretrizes (MINISTÉRIO DA CULTURA, 2006):

• Verificar se existe no mínimo um caso de teste identificado para cada sen-
tença dentro da especificação suplementar, que representa um critério de de-
sempenho. Normalmente esses critérios são apresentados através do tempo
por transação ou percentis;
• Verificar se há pelo menos um caso de teste identificado para cada caso de
uso crítico. Os casos de uso críticos são vistos nas instruções realizadas ante-
riormente ou em documentos que analisam a carga de trabalho que precisa ser
avaliada ao utilizar medidas de comportamento.
EXPLICANDO
Assim como nos casos de teste direcionados aos testes funcionais,
geralmente haverá mais de um caso de teste por cenário ou requisito de
uso. É comum definir vários casos de teste: que se encontra abaixo do
valor delimitado de desempenho (taxa média de transações), dentro do
parâmetro (taxa alta de transações), ou acima do valor limite (taxa máxi-
ma de transações).
Derivando casos de teste para testes de segurança/acesso

Os agentes que atuam no sistema e os casos de uso descrevem a interação
existente entre os usuários externos do sistema e as ações realizadas pelo siste-
ma, com o objetivo de criar os valores para os agentes. Os sistemas complexos
apresentam diversos agentes ou atores, sendo assim, é importante criarmos ca-
sos de teste que assegurem que eles consigam executar os casos de uso. Isso vai
acontecer se as diferenças presentes no fluxo de eventos do caso de uso forem
notadas, baseadas no modelo de atores.
Derivando casos de teste para testes de configuração
Podem existir diversas combinações entre o hardware e software que têm
suporte dentro dos sistemas distribuídos mais comuns. O teste deve ser reali-
zado com o intuito de observar se ele funciona ou se a sua execução ocorre de
maneira oportuna em configurações diferentes. O teste abrange, também, um
conjunto de combinações de elementos para identificar erros oriundos das inte-
rações de vários componentes.
A aquisição de um caso de teste destinado aos testes de configuração depen-
de da adoção de algumas diretrizes. São elas:
• Observar no mínimo a existência de um caso de teste que reconheça cada
configuração crítica. É preciso apenas identificar uma série de configurações inse-

ridas no hardware e software, adequadas para o ambiente de objetivo do teste e
priorizá-las, assegurando que as mais comuns sejam testadas em primeiro lugar;
• Verificar a existência de pelo menos um caso de teste para a configuração
suscetível a problemas. Tais configurações podem apresentar, por exemplo, re-
cursos de hardware com performance ruim, software co-residente com um his-
tórico de problemas de compatibilidade, além de clientes que utilizam o servidor
por uma conexão mais lenta.
Derivando casos de teste para testes de instalação
No teste de instalação, é preciso verificar a possibilidade de instalação do
seu objetivo em todos os cenários possíveis de instalação. Tais cenários podem
inserir o objetivo de teste em primeiro lugar ou uma versão nova ou build desse
objetivo. O teste de instalação também precisa assegurar que o objetivo do teste
seja realizado de maneira cabível no momento em que as condições forem con-
sideradas anormais.
Os casos de teste precisam abordar cenários de instalação do software, como
a mídia de distribuição. Os programas de instalação direcionados ao software
cliente-servidor possuem uma série específica de casos de teste. O programa de
instalação normalmente é dividido entre o servidor e o cliente, ao contrário dos
sistemas baseados em host. Dessa maneira, é essencial que o teste de instalação
realize a instalação de todos os componentes do objetivo do teste, incluindo o
cliente, as camadas intermediárias e os servidores.
Derivando casos de teste para outros testes não funcionais
Do ponto de vista da extração de casos de teste, a situação considerada ideal
é que o usuário consiga visualizar todos os recursos necessários para adquirir os
casos de teste em todos os modelos até aqui citados. Porém, não é estranho que
o usuário necessite complementar os que forem encontrados, como:
• Casos de teste para testes operacionais;
• Casos de teste que investigam gargalos de desempenho, recursos de volu-
me do sistema, ou que forçam falha no objetivo do teste.
Em boa parte dos casos, o usuário pode desenvolver variáveis ou agregados
dos casos de teste obtidos a partir daqueles identificados na fase anterior.
Derivando casos de teste para testes de aceitação do produto
O teste de aceitação do produto é considerado o experimento final na fase
anterior à implementação do software, cujo objetivo é observar se o software

está pronto e pode ser usado para atender as suas especificações. Trata-se de
um teste que envolve a preparação do software e os produtos de trabalho dis-
ponibilizados aos clientes.
A derivação dos casos de teste destinado a produtos de trabalho de um soft-
ware é descrita nas seções abordadas anteriormente. A depender do nível e do
formalismo do teste de aceitação do produto, os casos de teste serão similares
aos reconhecidos anteriormente ou um subconjunto. A profundidade dos casos
de teste não interfere no fato de haver a necessidade de estabelecer um acordo
com os critérios de aceitação do produto antes da implementação e execução
do teste do produto.
Criando casos de teste

Ao idealizar a execução de um
teste de software, é importante ter
em mente dois aspectos essenciais
que precisam ser geridos: um se re-
fere ao custo, e o outro ao benefício
gerado pela atividade de testes, lem-
brando que uma ação está relacio-
nada à outra. Ao realizarmos testes
em aplicações com alto nível de com-
plexidade, os custos pertinentes aos
testes normalmente aumentam de maneira rápida, o que pode ocasionar a
perda das vantagens disponibilizadas. As técnicas (métodos) apresentadas
nas próximas seções auxiliam a criação de cenários de testes, e certamente
diminuem os custos ligados ao planejamento e à execução das atividades.
Vamos imaginar a criação de uma página web sobre aquisição de com-
putadores customizados. O primeiro questionamento a nos fazer é: como
funcionará o site de compras de computadores e quais as funcionalidades
adequadas para a customização? Existem aspectos que possibilitam a confi -
guração de uma série de itens de um computador. Cada item permite diver-
sas escolhas realizadas pelo usuário, o que pode levar a uma infinidade de
combinações possíveis.

Ao se desenvolver uma suíte de testes capaz de se inserir nas combina-
ções de dados determinadas, isso pode ser encarado como um grande de-
safio, pois, mesmo com o processo de automatização, a criação de casos de
testes implica em trazer custos mais elevados. Em relação à execução dos
casos de teste, normalmente conseguimos perceber duas alternativas: criar
um sistema com base em normas para realizar as combinações possíveis,
ou conseguir um mecanismo de teste acessível no mercado. Porém, não é
tão fácil implantar as duas alternativas, que têm um conjunto de fatores que
justificam tal complexidade:
• Determinar todas as normas relacionadas à execução e validação dos
casos de teste não pode ser considerado corriqueiro;
• As regras desenvolvidas podem apresentar manutenção com custos
elevados;
• As ferramentas utilizadas nos testes são generalistas ou demandam um
empenho elevado para a customização.
Nestas condições, os custos de execução serão elevados, e geralmen-
te,não há tantos recursos disponíveis na realização das atividades de teste.
Portanto, devemos considerá-la entendendo as limitações de custo, esforço
e tempo, pois estes aspectos, por inúmeras razões, impedem a realização
de testes exaustivos ou os testes dos cenários de software. O custo da qua-
lidade gerado a partir de uma infraestrutura e de um tempo de desenvolvi-
mento de teste desejados, pode trazer benefícios superiores em relação ao
custo de ter uma falha presente no software.
Utilizar técnicas para reduzir o custo da qualidade é melhor do que
simplesmente testar o software, se levados em consideração os custos
elevados de planejamento e execução dos testes. Geralmente, a falta de
conhecimento sobre a dificuldade de se planejar e executar testes, por
exemplo, faz com que o software seja desnecessariamente testado de ma-
neira completa.
A qualidade de um sistema de software não é atingida por meio de fór-
mulas ou padrões. Por conta disso, é normal a utilização de técnicas esta-
tísticas. É possível, portanto, entender que existe um nível de dificuldade
para garantir a qualidade do software, porém, o maior desafio é levar este
conhecimento técnico a quem não o possui.

O passo final é estabelecer as entradas e verifi car se o software vai se de-
sempenhar de maneira adequada. Porém, é preciso compreender que o ato
de testar é uma atividade com alto nível de complexidade e que precisa ser
realizada levando em consideração as limitações impostas. Desta maneira,
é necessário atuar no sentido de maximizar o nível de cobertura dentro das
restrições de recursos definidos.
Geração de casos de testes do tipo caixa-preta

Para tratarmos da criação de um caso de teste específico para caixa-preta, é
preciso detalhar as abordagens utilizadas. As principais são: random sampling,
pairwise testing e N-wise testing. Vamos falar sobre cada uma delas.
A random sampling (amostragem aleatória) consiste em um método de
amostragem, na qual uma amostra selecionada apresenta o mesmo grau de
probabilidade de outra. Se uma amostra for selecionada de maneira aleatória,
sua representação precisa ter aspectos de imparcialidade em relação à popula-
ção total de amostras. Caso isso não ocorra, este tipo de variação é denominada
“erro de amostragem”.
A amostragem aleatória é considerada uma das maneiras mais comuns e
mais simples de buscar e coletar dados da população total. Neste tipo de amos-
tragem, cada componente de um subconjunto tem a mesma chance de ser se-
lecionado como parte do processo de amostragem. Entretanto, uma das des-
vantagens de seu uso se dá pela sua exigência para ser inserida uma listagem
completa da população de amostras.
Geralmente, o planejamento e a realização dos testes nos projetos são cur-
tos. Nessas condições, os analistas são obrigados a escolher combinações as-
sertivas para buscar a maior quantidade de defeitos de maneira acelerada. Para
solucionar esse problema e assegurar o nível de qualidade, os analistas de teste
adotam técnicas mais específicas.
Neste contexto, podemos citar o pairwise testing, que consiste na combina-
ção das entradas prováveis de um sistema usando uma forma inteligente para
criar uma quantidade mínima de saídas de teste e elevar o nível de variação das
entradas do sistema. Através desta técnica, as combinações de casos de teste e
o custo de realização do teste serão reduzidos.

CURIOSIDADE
Esta técnica foi utilizada em experimentos agrícolas, por exemplo. Nos
anos 20, ela passou a ser utilizada em informações tecnológicase, duran-
teos anos, o uso desse método reduziu os custos dos projetos
Esta técnica é realizada de forma manual, adotando o uso de matrizes defini-

das a priori, visando à criação de variações de casos de teste, através das variáveis
do sistema que se encontram na entrada. De imediato precisamos selecionar a
matriz mais adequada, e a quantidade de colunas dessa matriz será considerada o
número de entradas, se acrescentando mais uma. Em seguida pegamos as chan-
ces de entradas e realizamos a multiplicação dos dois maiores números.
Verificaremos que o resultado obtido desta operação consiste no número de
linhas da matriz e a quantidade de possíveis casos de teste. Após a seleção da
matriz, é preciso realizar as correlações entre a definição de cada linha e coluna
da matriz. Depois das correlações, o analista de teste pode retirar uma combina-
ção de teste, caso for constatada invalidez.
O teste N-wise, por fim, é um método para testes de interação do tipo com-
binada. Ao dar prioridade ao teste, os casos de teste serão reorganizados com
mais importância e detalhamento mais aprofundado. Uma nova meto-
dologia para a criação de casos de teste N-wise vem sendo adotada
com o intuito de atender três critérios diferentes, refe-
rentes à prioridade dada para cobertura de interação,
peso e divergência. A metodologia sugerida vai criar
um grupo pequeno de casos de teste em N, sendo
que casos com elevado nível de prioridade vão surgir
de imediato e com frequência.
Geração de casos de testes automática

Para falarmos sobre este modelo de criação de casos de teste, é preciso
ter em mente o método utilizado como linguagem de especifi cação e mo-
delagem: o RPOO (Redes de Petri Orientadas a Objetos). Os sistemas testa-
dos serão modelados dentro dessa linguagem. A ferramentas denominadas
JMobile tem a função de receber especifi cações na condição de entrada, e
vão criar o seu espaço de estados na forma de sistemas de transições rotu-

ladas (LTS). Importante frisar que as metas a serem alcançadas pelos testes
são especificadas no seu LTS respectivo. Do que se trata cada um destes
termos? Vamos visualizar detalhadamente cada um deles.
O RPOO é um formalismo desenvolvido para aproveitar os modelos com ca-
racterísticas estruturais, disponibilizadas pela orientação a objetos, em paralelo
aos modelos comportamentais das redes de Petri. O RPOO sugere um modelo
de sistemas com base em projeções oriundas da semântica ligada à orientação
de objetos e das redes de Petri. Os modelos RAPOO conseguem, por meio de
uma perspectiva orientada a objetos, apresentar as classes de um sistema e as
relações estabelecidas entre os objetos. Desta maneira, sempre existirá para
cada classe do sistema de objetos uma rede de Petri responsável por exibir a sua
performance interna.
Boa parte das ferramentas utilizadas na criação e na escolha automática de
casos de teste adota o LTS (Sistemas de Transições Rotuladas) como um procedi-
mento formal de entrada. Para que esta transformação se concretize, é preciso
falar da implementação do JMobile. Mas do que se trata? Bem, o JMobile Tools
tem como função principal auxiliar as ferramentas utilizadas nas simulações de
modelos RPOO e na criação de espaços nos estados, apresentando a sua API
classes e metodologias que disponibilizam acessos às informações pertinentes a
este modelo e às simulações realizadas. Paralelo a este API, é possível apresentar
um protótipo de ferramenta que possua habilidade de executar a simulação de
modelos RPOO, e a criação de um espaço de estados respectivos.
A TGV, por sua vez, é conhecida como uma ferramenta de auxílio aos cha-
mados testes funcionais (caixa-preta), que se baseia em metodologias de aná-
lise de modelos responsáveis por implementação automática dos casos de
testes do tipo funcional, direcionados aos sistemas reativos, por exemplo. Vale
dizer que o algoritmo de criação inserido por TGV tem como base aqueles usa-
dos para a avaliação de modelos, cujas funções estão ligadas às escolhas das
realizações no sistema que atendam às requisições do teste. Ao terminar este
procedimento, os casos de teste escolhidos serão disponibilizados em LTS, e,
através da utilização de outras ferramentas, poderão ser transformados em
outras modalidades de formato.
Boa parte das ferramentas de seleção dos casos de teste recebe o sistema
especificado em LTS e utiliza a técnica adquirida por meio de algoritmos para a

criação de testes de software, como ocorre no uso do TGV (Test Generation Ba-
sed on Verification Techniques), que consiste em ferramentas responsáveis pelo
desenvolvimento de casos de teste. Ele recebe o modelo de sistema na entrada
e o objetivo de teste já especificado, além de escolher, através da especificação,
os casos de testes baseados nestes objetivos. Diante disso, os casos de teste são
disponibilizados em LTS, o que permite sua implementação ou conversão para
outro tipo de linguagem.
Geração de casos de testes em tarefas

Ao longo do procedimento de verificação do software, é natural visua-
lizar um número extenso de cenários de teste que possam ser apresenta-
dos, independentemente do nível de complexidade que o sistema apre-
sente. A seleção dos melhores casos que serão utilizados é considerada
uma ação primordial durante este processo. Sem dúvida os casos de teste
são idealizados com a função de cobrir completamente os requisitos fun-
cionais e extremamente assertivos na busca de possíveis erros ou falhas
sistêmicos.
Para exemplifi car uma criação de casos de teste em tarefas é possível ex-
plorar o modelo navegacional do UsaTasker++. Através dele é viável extrair
casos de teste de um grafo simbolizando a execução de uma tarefa. Consi-
derando que determinada tarefa pode ser opcional, desordenada ou repe-
tida, existe a possibilidade de realizar uma atividade de maneiras distintas.
Existem diversos caminhos do ponto inicial ao final da atividade. Com isso,
o principal objetivo do UsaTasker++ é buscar todas essas alternativas, transfor-
mando cada chance em um caso de teste. Uma série de algoritmos foi criada
para processar um grafo direcionado, levando em consideração as funcionali-
dades do modelo navegacional, com o objetivo de criar todas as alternativas
que apresentam eventos iniciais e finais em comum. Técnicas distintas são ado-
tadas para processar o grafo, disseminadas nos seguintes passos:
1. Calibrar grafo: desenvolver uma lista adjacente que simbolize o grafo
básico e acrescente novas arestas;
2. Descoberta de caminhos: buscar todos os caminhos básicos inseri-
dos no grafo;

3. Aplicação de método de redução: retirar todos os caminhos conside-
rados inválidos;
4. Processamento fora de ordem: desenvolver caminhos incrementais
para simbolizar os eventos considerados fora de ordem;
5. Processamento de ciclo: desenvolver alternativas adicionais para
acrescentar os eventos repetidos.
Automação de testes
Se pensarmos em um sistema real, perceberemos que ele pode apresen-
tar uma quantidade expressiva de cenários de teste. Sabemos que um siste-
ma precisa passar por uma evolução de maneira rápida, além de apresentar
uma capacidade de controlar, o mais rápido possível, as prováveis falhas
ocorridas na segurança. Porém, é praticamente impossível analisar de ma-
neira especifi ca as alterações às quais o sistema está sujeito e verifi car se
alguma mudança surtiu efeito.
Diante deste contexto, para que a análise do sistema seja otimizada e os
comportamentos desejados sejam alcançados, é fundamental o uso de mé-
todos relacionados à automação de testes. Ela é vista como importante para
uma série de funcionalidades, como as aplicações extensas de Web, já que
consegue reduzir de maneira significativa o tempo para executar os testes
e auxiliar a disponibilização de produtos menos defeituosos. Ao longo deste
tópico verificaremos os conceitos fundamentais e as principais metodologias
ligadas à automação de testes.
Testes automatizados
Como podemos definir um teste automatizado e quais as suas funcionalida-
des? Um caso de teste realizado de maneira automatizada é considerado um script
que provém de uma sequência de ações, realizada dentro das interfaces gráficas
de uma aplicação, aliada ao uso de dados importantes. Depois que as pré-con-
dições são configuradas, a execução dos testes é realizada para comparar poste-
riormente os resultados alcançados (reais) com os resultados desejados. Ao final
de um relatório de teste, eles são apresentados para definir o status do resultado.

Em vez de focar a estrutura, a
condição interna do sistema ou as
características temporais, a automa-
ção normalmente vai focar o desem-
penho das entradas e saídas. Sendo
assim, os scripts são formados por
comandos que simulam as entradas
no sistema, além das análises para
definir comparações para as saídas.
Boa parte dos instrumentos de auto-
mação dão suporte ao processo de
gravação das tarefas no desenvolvi-
mento de script de teste correspon-
dente e na sua execução dentro de
um navegador.
Tais métodos são denominados de Capture and Replay, isto é, gravar e
repetir, cujas vantagens do seu uso estão relacionadas à redução de tempo
na codifi cação manual e simplifi cada dos scripts. Outro aspecto está rela-
cionado à chance de realizar a execução dos casos de teste, de acordo com
a necessidade, de maneira ágil e simplifi cada. Estas ferramentas são ampla-
mente adotadas no mercado e são essenciais, por exemplo, para elevar o
nível de qualidade das aplicações web.
Entretanto, as ferramentas Capture and Replay são desvantajosas em
alguns aspectos, pois eventualmente os scripts desenvolvidos apresentam
certo nível de inefi ciência, exigindo interferências manuais por diversas ve-
zes. Outra questão está ligada aos testes de regressão, nos quais qualquer
alteração na interface gráfi ca do sistema pode ocasionar em erros e impedir
sua execução.
Principais ferramentas de automação de testes

Dentro de uma demanda, é normal solicitar a automação de testes. Nesse
contexto, os instrumentos de automação geralmente vão ocupar uma função fun-
damental, pois são considerados os principais responsáveis pela realização desta

modalidade de atividade. Vamos tratar das principais ferramentas de automação
de testes que se encontram disponíveis no mercado.
A primeira ferramenta da qual vamos falar é o Selenium. De antemão, é pos-
sível dizer que o Selenium é atualmente a estrutura de automação de testes mais
empregada. Surgiu em 2004 e, desde então, não parou de evoluir, tornando-se a
principal escolha para testadores de código aberto que trabalham com aplicativos
inseridos na web.
Além de liderar no setor, o Selenium serve de referência para outras ferramen-
tas de automação, como o Katalon Studio, e dá suporte a vários ambientes ope-
racionais. Pode ser executado em Windows, Linux, entre outros, e em navegado-
res, como Google Chrome e Internet Explorer.
DICA
Programadores experientes no desenvolvimento de scripts e bibliotecas
específicas conseguem aproveitar o uso do Selenium de maneira mais
efetiva para cada modelo de teste necessário. O Selenium é uma ferra-
menta flexível, o que torna sua aplicação da automação de testes viável,
independentemente do software.
A ferramenta Robotium se caracteriza por ser um framework muito co-

nhecido destinado a aplicativos Android. É totalmente compatível com apli-
cações, sejam elas nativas ou híbridas, e possibilita a escrita simplificada da
automação de testes de caixa-preta. Sua função principal é criar uma simula-
ção de metodologias que normalmente serão executadas pelo indivíduo que
analisa os testes realizados. Isso pode incluir algumas atividades, como a in-
clusão de cadastro.
A ferramenta Appium é um instrumento de categoria open source direcionado
à automação de aplicações nativas ou híbridas. De característica multiplatafor-
ma, ela disponibiliza auxílio para simuladores móveis e para dispositivos reais. O
Appium se diferencia do Robotium, pois também pode ser utilizado na automação
de testes de softwares da plataforma iOS, o que aumenta o interesse dos desen-
volvedores. Através dele é possível executar testes sem levar em consideração a
linguagem de programação selecionada.
Outra ferramenta é o UFT, que consiste em um instrumento de teste comercial
bastante conhecido no que se refere aos testes funcionais de software. Esta fer-
ramenta disponibiliza um conjunto de recursos direcionado à APIs e testes GUI de

softwares para desktop, por exemplo. Além disso, adota o uso do VBScript com o
objetivo de deixar registrado os procedimentos de teste e controle.
Por fim, há o Watir, que também é adotado para realizar a automação de testes
em código aberto na web. Este procedimento se baseia em bibliotecas de código
Ruby e se caracteriza por ser compatível com testes para navegadores distintos,
como Mozilla Firefox e Opera. Também oferece suporte a outros testes orientados
a dados, integrando-se a ferramentas do tipo BBD.
É importante frisarmos que a execução de testes de software consiste em uma
atividade repetitiva e exaustiva. Não há possibilidade de descartar esta etapa de
desenvolvimento quando o objetivo é disponibilizar um produto de qualidade
para o cliente final. Portanto, a automação se torna uma excelente alternativa.
Uma das vantagens do instrumento de automação é possibilitar que o código
seja redigido uma única vez, indicando à máquina os testes que foram redigidos
para o software que vai executar, dentro de uma periodicidade. O resultado disso
gera um elevado nível de confiança na equipe de desenvolvimento, já que se torna
viável a alocação de tempo direcionada aos testes em tarefas, como a autocor-
reção das falhas possíveis, verificadas
pelos testes automatizados.
Outra vantagem da automação de
testes está ligada ao aumento da pro-
dutividade na criação do software e ao
atendimento das requisições do cliente,
que vai receber o produto ou serviço
isento de falhas.
Desafios benéficos da automação de testes

A execução de testes automatizados está em ascensão, pois existe a possibilida-
de de análise das funcionalidades do software de forma mais célere, com eficiência
e esforço mínimo. Todo o processo se caracteriza pela facilidade de realizar a repe-
tição dos esforços contínuos visando o teste da aplicação. Também existe a possibi-
lidade de realizar combinações complexas para testar a qualidade do software de
maneira mais eficiente, desconsiderando a falha do ser humano, o que dá aos testes
mais objetividade. Os casos de verificação do software geralmente são executados

através de códigos descritos e compreendidos por um computador. Sendo assim,
existe a possibilidade de elevar o grau de dificuldade dos testes, realizando várias
combinações que a mão de obra humana não teria capacidade.
Os testes automatizados são considerados as melhores alternativas para ana-
lisar a qualidade das aplicações, e podem agregar valor e mais destaque ao produ-
to. Por conta disso, podemos observar os benefícios que os testes automatizados
podem trazer para a qualidade do seu software a seguir:
• Custo inferior: o custo inicial pode ser mais elevado, porém após sua inser-
ção, o custo dos testes automatizados é reduzido, se comparado aos manuais.
Normalmente eles evitam bugs e questões operacionais, o que diminui o custo
referente à manutenção do software;
• Feedback mais rápido: a eficiência e a rapidez fazem com que os testes auto-
matizados possibilitem um retorno mais acelerado dos clientes e dos usuários. As-
sim, os bugs que podem surgir ocasionalmente podem ser corrigidos rapidamente;
• Mais eficiência: testes manuais precisam de um extenso tempo para realizar
o ciclo de desenvolvimento de um software. As melhorias simples na eficiência
dos testes impactam no custo final de um projeto. Com os testes automatizados, é
necessário menos tempo para serem realizados;
• Mais motivação à equipe: quando os feedbacks dos testes são demorados,
a equipe de desenvolvimento se sente desmotivada. Isso cria insatisfação tanto
nos testadores quanto na equipe de desenvolvimento. Os testes automatizados
encerram esse ciclo e motivam a equipe de desenvolvimento do software;
• Segurança de informação: apresentar coberturas de testes é fundamental
para o êxito do projeto. Normalmente profissionais passam horas corrigindo bugs
inseridos na produção em sistemas nos quais a segurança é deficitária. Graças aos
testes automatizados é possível fazer verificações contínuas de segurança, o que
evita a presença de hackers em um código falho.
Gerenciamento de defeitos
Quando nos referimos à garantia de qualidade de um software, tratamos
da busca e correção de erros presentes no produto. A qualidade é medida pela
quantidade de erros visualizados ao longo da realização dos testes. Geralmen-
te as pessoas indicam que a busca por defeitos é a uma função privativa do

teste de software. Seu objetivo principal é mensurar a qualidade da aplicação
executável ou dos itens adotados no desenvolvimento de um sistema.
A falha, dentro deste contexto, é proveniente de algum erro ou defeito co-
metido, certamente por uma disparidade entre a solicitação do usuário atra-
vés dos requisitos e o desempenho disponibilizado pela aplicação executável.
O sistema é extenso e complexo. Além de cumprir normas de qualidade,
qual solução podemos encontrar? Uma solução viável consiste na utilização
de um procedimento para gerir defeitos que estejam em integração com o
ciclo de vida, criação e teste de um software.
Compreender as ações de um processo de gestão de defeitos e selecio-
nar o instrumento apropriado para gerar um nível de automatização na ges-
tão do ciclo de vida de um defeito são atividades essenciais. Verifi caremos a
execução do processo de gerenciamentos de defeitos com o Mantis, instru-
mento open source para auxiliar este gerenciamento.
Processo de gestão de defeitos

Quando analisamos o processo de gestão de defeitos, precisamos verificar que a
sua principal funcionalidade é antecipar possíveis erros e reduzir os riscos inerentes
a um projeto. O uso da ferramenta automatizada apresenta uma base comum dis-
ponibilizada para a entrada de informações. Além disso, a gestão de defeitos expõe
uma forma de promover relação entre as equipes de desenvolvimento e de testes.
De maneira genérica, o termo “erro” é utilizado para apontar as distinções ocor-
ridas entre o valor alcançado em comparação ao valor desejado. Porém, seguindo
o padrão IEEE 610.12-1990, é possível diferenciar terminologias que normalmente
causam confusão no momento do gerenciamento. São elas:
TABELA 1. TERMINOLOGIAS DE GERENCIAMENTO DE DEFEITOS
Procedimento ou estabelecimento de dados errado, como uma instrução incorreta no

Defeito (Fault)
código.
Atividade humana que gera resultado errado, por exemplo, uma atividade incorreta
Engano (Mistake)
realizada pelo desenvolvedor.
Desvio observado no resultado apresentado em relação aos requisitos atingidos. A fa-

Falha (Failure) lha ocorre por conta de um erro, defeito ou engano, desenvolvendo uma performance
incorreta da aplicação.
Fonte: CAETANO, 2008.

O termo “defeito” é utilizado genericamente para referenciar um erro, engano,
defeito ou falha. Diante disso, os elementos essenciais de um processo de gestão de
defeitos podem ser enumerados da seguinte maneira:
1. Prevenção de defeitos: inserir
ações de prevenção e programação de
contingências baseadas na observação
dos riscos críticos do projeto para redu-
zir o impacto, caso os riscos se transfor-
mem em algo mais contundente;
2. Linha base entregável: determi-
nar linhas de base formalizadas, chama-
das baselines, através de uma gerência
de configuração inserida no software.
Cada linha base estabelece os requisitos disponíveis e que passarão por testes;
3. Identificação do defeito: estabelecer os métodos necessários para a busca e
a classificação dos defeitos, da mesma maneira que os critérios para identificá-los;
4. Solução do defeito: estabelecer as tarefas destinadas para correção e notifi-
cação posteriores do defeito. Diversas das tarefas são determinadas pela gerência
de configuração de software, visando assegurar o histórico e o acompanhamento
das alterações através do controle de versões;
5. Melhoria do processo: verificar as medições e relatórios de gestão para a
compreensão dos problemas e realizar a melhoria do processo de maneira contí-
nua;
6. Relatório de gestão: criar relatórios baseados em dados para acompanhar a
evolução dos testes e o nível de qualidade do sistema, de modo que algumas métri-
cas sejam inseridas para melhorar o processo.
Ciclo de vida de um defeito

A qualidade de um sistema pode ser mensurada pela quantidade de de-
feitos visualizados durante a realização dos testes. Sua execução é realizada
formalmente, por meio de testes estruturais ou funcionais, ao longo do uso
do sistema ou em desenvolvimento. Os defeitos podem ser classificados nas
seguintes categorias:

TABELA 2. CATEGORIA DE DEFEITOS
Faltante (Missing) O defeito ocorre por falta parcial ou total de um requisito.
Errado (Wrong) O defeito ocorre por requisito praticado de maneira incorreta.
O defeito ocorre por desempenho ou componente praticado sem a especificação do

Acréscimo (Extra)
requisito.
DICA
Assim que o defeito é localizado, intencional ou acidentalmente, o proce-
dimento seguinte é o relato desse defeito, através do procedimento defini-
do na gestão de defeitos. Este mecanismo pode ser uma simples planilha,
até uma ferramenta automatizada.
Quando o defeito for reportado, ele passará por um ciclo de vida estabe-
lecido anteriormente pelo processo de gestão de defeitos, cuja finalidade é
estabelecer os fluxos percorridos pelo defeito até sua finalização.
Relatório de defeitos
Como já observamos, os relatórios consistem em uma das partes essen-
ciais do processo de gestão de defeitos, porém são colocados em uma condi-
ção secundária. Algumas diretrizes precisam ser seguidas quando o relato de
um defeito está sendo realizado. Um relatório deve ser preciso e claro, pois
cabe ao usuário identificar se o defeito observado é um desvio da performan-
ce esperada, e não uma falha de compreensão.
Um relatório também precisa ser generalizante, pois um problema pode ocor-
rer em outras situações pertinentes ao software e mostrar que o defeito pode ser
reproduzível, descrevendo os procedimentos adequados para a sua reprodução.
Por fim, um relatório precisa ainda evidenciar a existência do defeito vi-
sualizado através de arquivos de saída, e a revisão, tendo a descrição e os
passos para que o defeito seja reproduzido.
Outro aspecto deixado em segundo plano é a classificação da severidade
e prioridade pertinentes aos defeitos, geralmente interpretada de maneira
errônea em diversas situações. Tal interpretação colabora para a priorização
ineficiente e a correção dos defeitos realizada de maneira agendada. Conse-

quentemente teremos um mau uso destes recursos, por conta da correção de
defeitos com nível de prioridade inferior.
De maneira sintetizada, a severidade de um defeito estabelece sua inter-
ferência no funcionamento de uma aplicação. Em contrapartida, a prioridade
aponta a ordem na qual os defeitos serão corrigidos. Os defeitos vistos como
mais severos são tratados com mais prioridade. No entanto, podem existir
diversas situações em que não podemos aplicar essa regra. Na Tabela 3 ve-
rificamos os critérios para determinar a severidade dos defeitos analisados.
TABELA 3. CLASSIFICAÇÃO DA SEVERIDADE.
Severidade Descrição
Elevada Impede totalmente o uso de uma funcionalidade básica ou aplicação inteira.
Impede plenamente o uso de uma funcionalidade básica, porém pode ser utilizada por
Mediana
um “workaround”, ou seja, um contorno conhecido.
Baixa Solicita melhorias no sistema.
Na Tabela 4 é possível verificar os critérios para determinar a prioridade

dos defeitos analisados.
TABELA 4. CLASSIFICAÇÃO DE PRIORIDADES.
Prioridade Descrição
O defeito precisa ser corrigido imediatamente, pois a aplicação não será liberada até
1
que ele seja sanado. O tempo de correção é de até um dia útil.
O defeito precisa ser corrigido o mais breve possível, pois a aplicação não será liberada
2
até que ele seja sanado. O tempo de correção é de até cinco dias úteis.
O defeito é de baixa prioridade, e a aplicação poderá ser executada mesmo sem a

3
correção dele.
Outra ferramenta importante é o Mantis, instrumento de open source

executado de forma automatizada e redigido em PHP, cujo objetivo é auxiliar
a gestão de defeitos. O Mantis se caracteriza por controlar todas as etapas do
ciclo de vida de um defeito através de fluxos personalizáveis.

EXPLICANDO
As condições iniciais para a instalação do Mantis requerem o PHP 4.0.6 ou
superior, MySQL 3.23.2 ou superior, Apache ou IIS.
Normalmente o Mantis é instalado, por padrão, em língua inglesa. Caso

o usuário deseje utilizá-lo em português brasileiro, precisará seguir alguns
procedimentos, descritos a seguir:
1. Realizar o login com o seu usuário e senha;
2. Clicar no menu “My Account” e selecione a opção “Preferences”;
3. No campo “Language”, escolher a opção “portuguese_brazil”;
4. Pressionar o botão “Update Prefs”.
Figura 3. Página inicial do Mantis. Fonte: CAETANO, 2008.
O Mantis apresenta um conjunto de funcionalidades, que podem ser reali-

zadas em qualquer plataforma que suporte PHP/Apache/MySQL. Além disso,
colabora dentre outros aspectos em:
• Desenvolvimento ilimitado de projetos e relatos de defeitos;
• Gestão do controle de acesso e níveis de permissões para usuários;
• Ciclo de vida dos defeitos (workflow) personalizável;
• Gerador interno de relatórios e gráficos;
• Estrutura para a criação de campos personalizáveis;
• Notificações por e-mail automáticas ou através de RSS Feeds;
• Integração com ferramentas de controle de versões (Subversion e CVS);
• Interface Webservice (SOAP) para integração com outras ferramentas;
• Mantis WAP – Suporte a dispositivos móveis.

Sintetizando
Verificamos que a equipe que cuida dos testes precisa planejá-los para que
os requisitos sejam validados adequadamente, no momento em que um con-
junto de requisitos esteja disponível. Observamos que a validação do software
é feita de maneira diferente em relação aos requisitos adotados.
Ainda vimos que, ao projetar a realização de um teste de software, é impor-
tante verificar o custo-benefício criado pela atividade de testes, pois aplicações
complexas aumentam os custos rapidamente, ocasionando perdas nas vanta-
gens disponibilizadas.
Outro aspecto relevante de que tratamos foi dos sistemas reais, que se ca-
racterizam por apresentar um número grande de cenários de teste. É impor-
tante frisar que um sistema passa por rápida evolução e uma capacidade de
controle dos possíveis erros que ocorrem na segurança.
Por fim, vimos o conceito relacionado à garantia de qualidade de um soft-
ware, no intuito de corrigir erros que surgirem. Normalmente a busca por de-
feitos é a uma função privativa do teste de software, cujo objetivo é medir a
qualidade de um sistema na aplicação executável e os itens adotados.

ANDRADE, A. P.; VIANA, P. Criação e geração de planos de teste de software. IBM,
2012. Disponível em: https://www.ibm.com/developerworks/br/local/rational/
criacao_geracao_planos_testes_software/index.html. Acesso em: 20 jan. 2020.
CAETANO, C. Gestão de defeitos: ferramentas open source e melhores práticas
na gestão de defeitos. DevMedia: plataforma para programadores, 2008. Dispo-
nível em: https://www.devmedia.com.br/gestao-de-defeitos-ferramentas-open-
-source-e-melhores-praticas-na-gestao-de-defeitos/8036. Acesso em: 06 jan.
2020.
FIGUEIREDO, A. L. L. Geração automática de casos de teste para sistemas
baseados em agentes móveis. 2005. 189 f. Dissertação (Mestrado em Infor-
mática) – Centro de Engenharia Elétrica e Informática, Universidade Federal de
Campina Grande, Campina Grande, 2005. Disponível em: http://dspace.sti.ufcg.
edu.br:8080/jspui/handle/riufcg/1743. Acesso em: 05 jan. 2019.
IBM. Visão geral dos casos de teste e da suíte de testes. IBM Knowledge Cen-
ter.. Disponível em: https://www.ibm.com/support/knowledgecenter/pt-br/
SSYMRC_6.0.4/com.ibm.rational.test.qm.doc/topics/c_testcase_overview.html.
Acesso em: 04 jan. 2020.
MINISTÉRIO DA CULTURA. Secretaria Especial da Cultura. Diretriz: casos de tes-
te. 2006. Disponível em: http://mds.cultura.gov.br/core.base_rup/guidances/gui-
delines/test_case_81FD1D9F.html. Acesso em 20 jan. 2020.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson Prentice
Hall, 2011.
SOUSA, H. P. et al. Extração de casos de teste a partir de modelos de processos
de negócio. In: WORKSHOP EM ENGENHARIA DE REQUISITOS, 2014, Púcon. WER
Papers. Rio de Janeiro: PUC-Rio, 2014. Disponível em: http://wer.inf.puc-rio.br/
WERpapers/artigos/artigos_WER14/paper43.pdf. Acesso em: 04 jan. 2020.

UNIDADE
4 MEDIDAS,
GERENCIAMENTO E
EXECUÇÃO DE TESTES
DE SOFTWARE

Conhecer as métricas do teste de software;
Explorar ferramentas de suporte ao teste de software;
Analisar ferramentas de suporte ao gerenciamento do teste de software;
Conhecer métodos de gerenciamento do teste de software.
Tópicos de estudo
Métricas para o teste Gerenciamento de teste
de software de software
Métricas de profundidade, de Ferramentas de suporte ao ge-
quantidade e de severidade renciamento de teste de software
Métricas básicas e profundas Planejamento e estimativa de
Métricas relacionadas ao teste
software
Ferramentas de suporte
ao teste
Ferramentas de suporte ao
teste: primeiro teste
Estratégia de teste e
abordagem de teste
Ferramentas de suporte ao
teste: segundo teste

Métricas para o teste de software
Como já abordado, existem diversas maneiras de realizar testes de soft-
ware – e em breve outras formas serão explanadas. Entretanto, primeira-
mente é necessário conceituar o que é métrica para, então, explorar as
métricas de teste de software.
A experiência na criação de softwares e desenvolvimento web tem mos-
trado que as empresas precisam lidar com problemas e processos. Posto
isso, podemos dizer que problemas são erros, como adaptação de tela ina-
dequada, erros de código, algoritmos que não funcionam, entre outros; ao
passo que processos referem-se a formas de trabalhar e estruturar a rotina,
bem como a atender clientes e usuários. Tendo isso em mente, pode-se afir-
mar que é relativamente comum que muitas empresas apresentem a se-
guinte objeção: “sabemos que a qualidade é importante, mas ela nos custa
tempo e dinheiro em demasia para obter o nível de qualidade de software
que realmente desejamos” (PERES, 2016, p. 25).
Geralmente, percebemos que existem erros de gestão que afetam a qua-
lidade de software, uma vez que, na ausência de uma rotina estruturada
em função de prioridades da manutenção de software, os programadores e
testadores muitas vezes somente “apagam incêndios” ao invés de se utiliza-
rem do tempo disponível para focar na qualidade, e esta rotina reativa não
dá espaço a uma rotina preventiva e proativa. Neste tipo de cotidiano, por
estarem o tempo inteiro reparando erros, os programadores não têm tem-
po – nem cabeça – para utilizar a criatividade a fim de prevenir problemas e
criar aplicações incríveis. Portanto, se faz necessário criar modelos e métri-
cas em testes de software que possam identifi car rapidamente quando um
erro se torna um padrão. Ao longo deste material, iremos elencar diversas
métricas, cabendo ao aluno escolher as mais pertinentes para cada traba-
lho. As métricas que serão explanadas estão elencadas a seguir:
• Métricas de profundidade, de quantidade e de seve-
ridade;
• Métricas básicas e profundas;
• Métricas relacionadas ao software: de situação,
de sumário, de riscos e de prazo de correção.

Métricas de profundidade, de quantidade e de severidade
Pense em um aplicativo de com-
pras. Um aplicativo possui, pelo me-
nos, dois itens que são cadastrados
no banco de dados: os produtos e os
clientes. Posto isso, a métrica de pro-
fundidade pode ser explicada como a
capacidade de testar os programas
até suas partes mais profundas, isto
é, o banco de dados. Outro exemplo
de métrica é relativa à quantidade de erros encontrada para cada tipo de
problema, como, por exemplo, uma empresa que realizou um teste e avaliou
dez erros de cobertura, três erros de mudança de tela e um erro de operação
lógica. Por fim, outro exemplo de métrica é relativa à severidade dos erros,
na qual o testador pode criar indicadores referentes a níveis de erros críticos,
níveis de relativa atenção e níveis menos prejudiciais. Logo, podemos resumir
estes três indicadores da seguinte forma:
Métrica que avalia a profundidade do teste:
• O exame avalia até a caixa-preta? Ou seja, ele avalia até a camada que
abrange a tela, os campos e os botões?
• O exame avalia até a caixa-branca? Ou seja, ele avalia mais que a tela,
analisando também os códigos?
• O exame avalia o funcionamento do banco de dados? Ou seja, avalia tam-
bém a qualidade da gestão de dados no servidor SQL realizada pelos ad-
ministradores de banco de dados (ou DBA – Data Base Administrator)? Em
outras palavras, além de avaliar a tela e os códigos, o exame avalia a forma
com que os dados são gerenciados no banco de dados?
• O exame avalia, além do supracitado, o modo de alimentação do banco
de dados? Ou seja, avalia também a qualidade das fontes de cadastros de
dados, ao realizar perguntas como: o departamento de estoque preenche
os dados corretos? As fontes de dados são confiáveis? As fontes de dados
são abundantes? As fontes, por algum viés, permitem valores nulos ou
errantes?

Métrica que avalia a quantidade de erros:
• Um exemplo amplamente utilizado é o intervalo escalar, como, por exem-
plo, de 0 até 10 erros, de 11 até 20 ou mais que 21;
• Cada escala de erros pode ser avaliada perante um indicador. Dois exem-
plos de indicadores, medidos sob o prisma do intervalo escalar, são:
• Quantidade de erros lógicos (0-10, 11-20 ou mais que 21);
• Quantidade de erros de documentação (0-10, 11-20 ou mais que 21).
• Existem testadores que, em vez de utilizar quantidade, empregam porcen-
tagem: encontrou-se 30% de erros de cálculo e 70% de erros de mudança
de interface, por exemplo.
Métrica que avalia a severidade:
• Erros de nível crítico ou urgente;
• Erros de nível intermediário, que exigem relativa atenção;
• Erros de nível leve.
É fato que nenhuma empresa quer gastar tempo ou dinheiro com testes
dispensáveis. No entanto, a prática tem mostrado que não existem testes que
sejam supérfluos, mas sim prioridades diferentes. Cabe à empresa escolher
bem as ferramentas ideais para testar seus softwares, uma vez que cada em-
presa programa em determinada linguagem, além de possuir tipos específicos
de programa. As empresas, geralmente, possuem um programa para criar soft-
wares, um programa para testá-los e uma linguagem de programação, além de
algumas métricas de teste.
Veja mais alguns softwares de teste:
• Para algumas empresas, o teste automático Selenium é o mais apropriado.
Empresas que criam websites, por exemplo, podem fazer grande proveito
desta ferramenta;
• Se a empresa utiliza mais aplicativos mobile, a ferramenta ideal é o
Robotion, que é capaz de realizar testes dispensando o uso excessivo
de códigos no ato do teste;
• Se os programas a serem testados forem mobile ou desktop, feitos em Java e
o testador for criterioso, vale a pena utilizar a ferramenta JUnit;
• Para quem quer simplicidade e flexibilidade, há o Ranorex, que, além de pos-
suir instalação simples, pode ser usado em praticamente qualquer navegador
e serve tanto para testes de websites como de programas desktops e mobile.

É importante conhecer e criar métricas de teste de software para poder
escolher o programa ideal para realizar testes, uma vez que há situações em
que o Selenium pode ser a melhor opção, outras em que o Robotion se faz mais
adequado e aquelas em que o Ranorex se mostra mais eficaz – tudo dependerá
muito do tipo de software que a empresa utiliza para criar programas.
ASSISTA
Para conhecer alguns exemplos de testes de software, as-
sista ao filme Piratas da informática, que mostra o desen-
volvimento dos softwares de dois sistemas muito conhe-
cidos. No filme, é possível ver a progressão dos testes
realizados por Bill Gates e Steve Jobs, a fim de alavancar
a Microsoft e a Apple, respectivamente.
Métricas básicas e profundas

Aqui, analisaremos duas métricas que podem ser utilizadas ao avaliar um
software: métricas básicas e métricas profundas. As métricas básicas são uti-
lizadas pelos testadores ou analistas de testes. Como exemplo, há o cálculo
da quantidade de testes que obtiveram êxito ou fracasso. Já as métricas pro-
fundas são empregadas pelo gestor de testes e avaliam dados mais apurados,
como o percentual de testes que funcionaram na primeira tentativa, a cobertu-
ra do teste e o custo médio de correção de erros identificados por aquele tipo
de teste. Vejamos alguns exemplos:
Métricas básicas:
• Avalia a quantidade de testes que identifi caram erros onde realmente
havia erros;
• Avalia a quantidade de testes que identifi caram erros onde não havia
erros.
Métricas profundas:
• Elenca quais testes funcionam na primeira tentativa e quais funcionam
somente a partir da segunda tentativa;
• Constata se o teste levanta unicamente erros muito complexos de se-
rem resolvidos;

• Descobre se os erros identifi cados pelo teste irão, de fato, mudar a ro-
tina da empresa para melhor.
Elas são muito importantes, visto que uma empresa que possua verba re-
duzida ou pouco tempo disponível precisa selecionar com cuidado seus testes,
e esta seleção está intimamente ligada às métricas. Para isso, é necessário “tes-
tar os testes” e avaliar a eficiência e utilidade de cada um.
Métricas relacionadas ao software

Aqui, serão evidenciadas quatro métricas que po-
dem ser utilizadas na avaliação de um software: de
status, sumário de ocorrências, tabela de riscos e pra-
zo de correção.
A métrica de status, ou de situação, compreende três
medidas: pendente, semipendente e concluído. O status de me-
dida pendente refere-se a quando um teste ainda não foi realiza-
do; o status de medida semipendente especifica um teste que já foi feito, com
erros já identificados, mas sem alterações executadas pelo programador; e,
por fim, o status de medida concluído relaciona-se a testes e alterações já rea-
lizados. Observe os exemplos:
• Falhas de código: status de medida pendente;
• Fotos que não aparecem: status de medida semipendente;
• Lentidão acima do normal: status de medida concluído;
• Links quebrados: status de medida concluído;
• Textos escritos em cima de outros objetos: status de medida semi-
pendente;
• Vídeos com áudio insatisfatório: status de medida pendente.
A segunda métrica relaciona-se à geração de um sumário de ocorrências,
ou seja, o programador faz um sumário com todos os problemas que ocorre-
ram no programa. Observe um exemplo de sumário:
1. Falhas de código: nove erros encontrados;
2. Fotos que não aparecem: um erro encontrado;
3. Lentidão acima do normal: oito erros encontrados;
4. Links quebrados: três erros encontrados;

5. Textos escritos em cima de outros objetos: dois erros encontrados;
6. Vídeos com áudio insatisfatório: um erro encontrado.
A terceira métrica relacionada ao software refere-se à geração de uma ta-
bela de riscos. Para demonstrá-la, observe a matriz presente no Quadro 1: na
primeira coluna estão os erros, na segunda encontram-se os níveis de erro e na
terceira encontram-se os grupos heurísticos, criados para classificar a catego-
ria do problema. Primeiramente, é necessário evidenciar que existem três indi-
cadores, a saber: risco alto, risco médio e risco baixo. Além disso, é importante
deixar claro que ainda não é o momento de se preocupar com a terceira coluna:
limite-se a analisar o Quadro 1.
QUADRO 1. ANÁLISE DE RISCOS EM TESTES DE SOFTWARES
Componente Severidade Risco heurístico
Erros de impressões Normal Popular
Erros na geração de relatórios Alto Novo, crítico
Erros de instalação Baixo Falhou recentemente
Erros nas imagens Baixo Complexo
Erros de usuário Alto Dependente de bloco superior
Fonte: BACH, 2002, p. 22. (Adaptado).
Agora, voltando a atenção para a terceira coluna, pode-se verificar que exis-
tem algumas categorias de grupos heurísticos de erros, a saber:
• A categoria popular é assim denominada quando o erro é encontrado
várias vezes no programa;
• A categoria novo refere-se a quando o erro nunca ocorreu antes;
• A categoria crítico é chamada assim quando o erro pode prejudicar o pro-
grama, de forma a destruir seu funcionamento;
• A categoria falhou recentemente é quando um problema surgiu neste
programa a partir de uma data recente;
• A categoria complexo refere-se a quando o problema é difícil de resolver;
• A categoria dependente de bloco superior é quando um erro está rela-
cionado à categoria pai, como, por exemplo, o campo de texto de um for-
mulário que só pode ser ajustado se a tabela a qual ele pertence também
for regulada.

Com base no Quadro 1, pode-se perceber que índices de severidade podem
ser delimitados por cores: verde representa níveis mais brandos de severidade,
amarelo representa níveis sérios e vermelho representa níveis alarmantes.
Por fim, a quarta métrica relacionada ao software é a geração de um prazo
de correção, ou seja, quantas horas são necessárias para corrigir o problema.
Por exemplo, imagine que você possui cinco problemas relacionados a links
quebrados e a correção levou 20 horas. Logo, o prazo médio de correção é de
quatro horas. Visto isso, não é necessário dizer que essa métrica é extrema-
mente importante no cotidiano das empresas.
Ferramentas de suporte ao teste

Uma boa ferramenta de suporte a testes de software é o Selenium, uma
suite que possui quatro ferramentas de teste. Este programa foi criado em
2004 com o objetivo de avaliar navegadores e sites, o que signifi ca que esta
ferramenta, atualmente muito famosa, é um testador de aplicações web. As
quatro ferramentas pertencentes a este programa são:
• Selenium Remote Control;
• Selenium WebDriver;
• Selenium IDE;
• Selenium Grid.
CURIOSIDADE
É interessante comentar que antes de seu surgimento, havia uma ferra-
menta da companhia Mercury, denominada QuickTest, que apresentava
muitos problemas. O jargão que deu nome ao Selenium foi concebido por
seu desenvolvedor, que afirmou que “o antídoto para o envenenamento
por mercúrio é o selênio” em uma piada interna.
A ferramenta Selenium Remote Control foi a primeira a ser concebida

e pode-se dizer que ela era bem limitada e não rodava em qualquer na-
vegador. Portanto, criou-se uma ferramenta que fosse mais sofisticada e
rápida, além de aceitar mais linguagens e funcionar em mais navegadores:
o Selenium WebDriver. Além destas duas ferramentas há a IDE, utilizada
para gerar testes rapidamente e gravar funções no navegador. Por fim, a

ferramenta Grid realiza testes em nuvens. Sobre a criação do programa su-
pracitado, Peres afirma que:
Em 2004, Jason Huggins estava testando uma aplicação interna da
ThoughtWorks (empresa que tem como foco o desenvolvimento ágil
de software) quando percebeu que poderia gerenciar melhor seu
tempo nas atividades de teste manuais. Para isso, ele criou uma bi-
blioteca Javascript que interagia com um browser e que em breve
passaria a interagir com os demais. A este projeto foi concedido o
nome de Selenium, que, na verdade, trata-se de uma analogia sobre
uma ferramenta de teste alternativa para testadores que não supor-
tavam mais ficar dependentes da ferramenta QuickTest, da empresa
Mercury, que por sinal era paga e bem cara. Na química, o antídoto
para o mercúrio é o selênio (PERES, 2016, p. 72).
Ferramentas de suporte ao teste: primeiro teste

Atualmente, a ferramenta Selenium funciona em qualquer navegador ou siste-
ma operacional e, para poder realizar testes mais elaborados, permite a adição de
plug-ins que aumentam as funcionalidades do programa. Além disso, o Selenium é
compatível com várias linguagens, como Java, C#, Python, PHP, Ruby, entre outras.
Para baixar o Selenium IDE, primeiramente é necessário instalar o Mozilla
Firefox, acessá-lo, colar <https://addons.mozilla.org/pt-BR/firefox/addon/sele-
nium-ide/> na barra de endereços e instalar a extensão, conforme a Figura 1.
Figura 1. Print mostrando a instalação da extensão Selenium.

Agora, iremos elaborar um teste. Para isso, clique na extensão do Selenium
no Firefox e crie um novo projeto chamado PrimeiroTeste. Sua IDE será aberta,
conforme evidencia a Figura 2.
Figura 2. Print que mostra a criação um novo projeto no IDE.
Agora, iremos realizar um teste para checar se o botão Cidadão do site

da Prefeitura de São Paulo realmente funciona. Ao clicar no botão Cidadão,
normalmente, o site deveria direcionar o usuário que esteja na página <http://
www.capital.sp.gov.br/> para a página <http://www.capital.sp.gov.br/cidadao>,
conforme demonstra a Figura 3.
Figura 3. Print da mudança de tela esperada.
Primeiramente, na página <http://www.capital.sp.gov.br/>, inicie o teste ao

clicar em REC, conforme evidencia a Figura 4.

Figura 4. Print da criação de um teste.
Após abrir o site em uma nova janela do Firefox de teste, posicione uma tela
de cada lado, conforme o Diagrama 1, clique com o botão direito na palavra
Cidadão e crie um @assert title.
DIAGRAMA 1. TESTE DE ABERTURA DA PÁGINA CIDADÃO
1. Clicar com o botão direito na palavra Cidadão e ativar @assert title
Botão play Botão pause
2.Digite a função Open para checar

se abre a página http://www.capital.
sp.gov.br/cidadao
3. Digite também a palavra /cidadao
4. Pause a gravação
O resultado deve gerar uma tela com fonte verde; caso ela esteja vermelha
significa que o link não está funcionando. Além disso, haverá uma barra verde,
o que evidencia que o testador identificou a mudança de página com êxito.

Estratégia de teste e abordagem de teste
Agora, serão discutidas três abordagens de teste,
em seguida quatro estratégias de teste e, para con-
cluir, um novo teste será realizado. A primeira abor-
dagem de teste a ser citada é a Big Bang, a segunda
é a integração descendente (top_down) e a terceira é a
integração ascendente (bottom_up).
A abordagem Big Bang testa cada módulo de forma individual, embora
teste todas as unidades simultaneamente. Por exemplo: suponha que um
programa possui a classe alunos, a classe matrícula, a classe pagamen-
to, a classe retirada de material, entre outras. Utiliza-se esta técnica para
testar rapidamente o programa como um todo. A vantagem desta classe
é que, quando tratando-se de programas menores, ela realiza testes com
rapidez. As desvantagens existentes são relacionadas à dificuldade em
precisar o motivo da falha e em assimilar se uma tela leva à outra, uma vez
que os testes são unitários.
A abordagem top_down testa de cima para baixo. Por exemplo: imagi-
ne que um programa possui a classe Anúncios_Carros e, dentro desta clas-
se, exista a classe Anúncios_Carros_Seminovos e Anúncios_Carros_Novos.
Logo, este modelo de teste avalia primeiro as classes maiores e posterior-
mente as classes filhas. A vantagem desta classe é que, por ser de alto
nível, ela identifica problemas em cascata, descobrindo rapidamente erros
que vão se repetir nas classes inferiores. A desvantagem refere-se à bu-
rocratização de este ser um modelo de teste realizado de cima para baixo,
o que faz com que os testes unitários das classes inferiores demorem para
acontecer. Se houver um problema apenas na classe inferior, por exemplo,
ele será identificado somente após o processo estar quase completo.
Por fim, a abordagem bottom_up testa de baixo para cima. Por exem-
plo: imagine que um programa tem a classe Anúncios Residências e, dentro
desta classe, exista a classe Anuncios_Casas e Anuncios_ Aptos. Portanto,
este modelo de teste avalia primeiro as classes menores e posteriormente
as classes mães. A vantagem desta classe é que fica mais fácil encontrar
erros lógicos e de cobertura, além de melhorar a usabilidade e a inter-

face da tela. Outra vantagem é que ela é rápida
de ser realizada quando há grande quantidade
de trabalhos. A desvantagem é que não adianta
resolver o problema de uma classe e deixar sua
classe irmã com problema, posto que isto gerará con-
fusão. Quando essa técnica é utilizada em uma empre-
sa, normalmente é porque o tempo está curto. Ela pode
servir como “tapa buraco” uma vez que os erros não são
documentados corretamente: a consequência é neutralizada sem que a
causa seja compreendida e avaliada – no entanto, ela pode ser útil quando
é um erro isolado e que não se repete.
Agora, discorramos brevemente sobre as estratégias de teste. A estra-
tégia de prevenção ocorre quando testes são realizados desde o início da
criação do programa. Ela é útil e acarreta em menos retrabalho, uma vez que
previne erros mais complexos e difíceis de serem localizados. A estratégia
corretiva é executada após o programa já estar pronto, a fim de focar ape-
nas no que deu errado. A estratégia de reutilização utiliza testes antigos em
novos softwares, contudo, para reutilizar o teste, o programa antigo deve ser
parecido com o novo que será testado, no que tange à estrutura. Por fim, a
estratégia de lista faz uma lista de parâmetros a serem assinalados e, após
analisar cada parâmetro, o checklist de cada tópico é realizado.
Ferramentas de suporte ao teste: segundo teste

O segundo teste que iremos fazer é relativo à checagem do funcionamen-
to dos campos de texto que estão na tela. Às vezes, ao criar um site, ícones
inoperantes são inseridos e perduram até o momento de colocar o site no ar
por razões estéticas. Nesse momento, é necessário linkar o ícone com sua
função correspondente; se for um campo de nome, que receba nomes, se
for uma lupa, que faça pesquisas, e assim por diante. Para isso, utiliza-se o
@assert_element_existe.
Posto isso, crie outro teste: clique na extensão do Selenium no Firefox e
clique na opção “gravar” para abrir o seguinte site: <http://www.ssp.sp.gov.
br/fale/Contato.aspx>, conforme demonstra a Figura 5.

Figura 5. Print da criação um novo teste.
Desta vez, utilizaremos uma maneira mais rápida para testar todos os
campos de uma vez só: ao abrir o navegador de teste, posicione as duas jane-
las uma do lado da outra e siga as instruções da Figura 6.
5. Todos irão aparecer aqui
1. Dê um clique no campo Nome
2. Dê um clique no campo E-mail

3. Dê um clique
no campo Cidade
4. Dê um clique no
campo Mensagem
Figura 6. Maneira prática de testar vários campos ao mesmo tempo.

Depois de cada tópico aparecer na tela de testes, altere os campos para
assert element present, a fim de checar se eles realmente estão linkados com
a função corresponde ao campo. Feito isso, interrompa a gravação e clique
em testar.
1. Mudar a função de cada botão campo para assert element present

2. Clique em pausar
3. Dar play
Figura 7. Teste para checar se vários campos realmente estão funcionando.

Podemos observar que o campo Nome é obrigatório na página pesquisa-
da, uma vez que possui um asterisco. Agora, faça o seguinte questionamento:
caso o usuário não digite o nome, o botão de enviar realmente irá falhar? É
necessário descobrir se o sistema recusa formulários sem nome, visto que
a intenção é esta: não funcionar se não houver nome, texto. O nome desta
função é @assert_not_text. Se a utilizarmos em um teste, ficará comprovado
que se não houver nome, de fato, haverá falha no sistema, o que é esperado
e desejado.
Existem diversos outros testes que podem ser feitos neste programa, ain-
da que a base seja esta. Alguns exemplos são:
• assertChecked: o teste funciona apenas se uma caixa de seleção estiver
marcada;
• assertEditable: avalia se o texto do campo pode ser editável;
• click: verifica se o elemento pode ser clicado;
• chooseOkOnNextConfirmation: verifica se, após clicar em ok, a caixa fecha;
• deleteAllCookies: verifica se o botão apaga cookies da página;
• dragAndDropToObject: verifica se o objeto pode ser arrastado.
Gerenciamento de teste de software

Até então, o foco esteve voltado para as métricas e os testes em si. No
entanto, a partir de agora, serão abordados alguns programas que realizam
o gerenciamento de teste de software, determinadas técnicas de gestão e,
por fim, será demonstrada a maneira correta de utilizar um programa de
gerenciamento.
As empresas, ao contratarem profissionais de tecnologia, não se limi-
tam a perguntar se estes profissionais sabem programar, criar ou testar. Os
seguintes questionamentos também podem surgir: quais linguagens você
utiliza? Quais IDEs (editor de texto web) você usa? Quais softwares
você usa para programar? Você já utilizou algum progra-
ma de teste?
O profissional de tecnologia é conhecido por seu
conhecimento prático. Por conseguinte, de nada
adianta ser capaz de discorrer sobre determinados

assuntos: é necessário, também, ter uma sabedoria alicerçada na prática,
além de passar confiança neste sentido. As empresas precisam de resulta-
dos e de pessoas que dominem tecnologias, e esta etapa jamais pode ser
negligenciada. É devido a isso que determinados programas de gerencia-
mento também devem ser conhecidos.
Ferramentas de suporte ao gerenciamento de teste

de software
Aqui falaremos de três programas: TestLink, TestMaster e RTH. Assim
sendo, pode-se afirmar que um dos programas mais famosos de geren-
ciamento de teste de software é o TestLink. Criado em 2005 na lingua-
gem PHP, ele utiliza navegadores para gerenciar testes, o que permite a
fácil comunicação entre gestores que estejam em localidades geográficas
diferentes. Dentre suas funções principais estão: a criação de planos de
teste para que as empresas possam acessá-los a qualquer momento; a
classificação de casos de teste por palavras-chave, a fim de que os testa-
dores e gestores possam acessar o teste de forma rápida; e a atribuição
de privilégios diferentes para os usuários. Por exemplo: o testador acessa
apenas os relatórios de teste nos quais ele mexe, o líder acessa o relatório
de todos os testes, o analista acessa o grupo de relatórios pelo qual ele é
responsabilizado e assim por diante.
O programa ainda permite a criação de gavetas na aba lateral esquer-
da, que abrange a aba de caso de testes com falha, a aba de plano de teste,
a aba de testes não executados, a aba de gráficos e a aba de custo de tes-
tes, além da aba de métricas. Existem também métricas de status, como:
executado, não executado, passou, com falha e completado.
O programa é muito fácil de ser instalado e, embora conhe-
cimentos básicos em PHP ajudem, eles não são
obrigatórios e um breve tutorial do YouTube já é
o suficiente para utilizá-lo com tranquilidade.
Outra ferramenta útil quando se trata de
gerenciamento de teste de software é o RTH.
Este programa tem alta usabilidade, pois, além

de sua interface ser muito intuitiva, ele permite visualizar as últimas mu-
danças realizadas na tela inicial. Além disso, ele cria árvores em requisitos
através de Inteligência Artificial, tornando algumas métricas prioritárias
sem esforço humano. Ele também mostra testes que passaram, testes re-
provados, entre outros, além de exibir a última data de cada teste logo na
tela inicial.
Esta ferramenta, que foi construída em PHP, é grátis e permite as se-
guintes funções:
• Criar casos de teste;
• Executar testes;
• Monitorar testes;
• Exportação para Excel;
• Geração de relatórios.
Por fim, a ferramenta TestMaster serve para a gestão de testes de
software. Em outras palavras, este programa é uma ferramenta de criação
de registros de teste que permite a geração de gráficos e relatórios, além
de realizar automação de testes. Ele é semelhante ao programa TestLink
e tem aceitabilidade para dados que provenham do MS Word e do SQL. O
TestMaster, que conta com menus com registros de total de testes, testes
feitos, testes e progresso, testes completos, testes reprovados e testes
aprovados, possui as seguintes funções:
• Criação de casos de teste;
• Execução de casos de teste;
• Criação e geração de relatórios manuais e automáticos;
• Automação de testes;
• Produção de índices de testes com êxito e testes que falharam;
• Apresentação de dados de probabilidade e dados estatísticos;
• Acesso em navegador;
• Compatível com arquivos de Python, como CSV, e do Word, tanto na
importação quanto na exportação.
Como pode ser notado, cada programa tem suas próprias qualida-
des. No TestMaster, a geração de dados estatísticos e a compatibilidade
com arquivos SQL e CSV auxiliam no levantamento de dados profundos e
de valor.

Figura 8. Aplicativo TestMaster.
DICA
O ideal é testar vários programas de gestão de testes de software e, en-
tão, fazer um estudo comparativo entre eles, a fim de descobrir quais usar.
Ainda neste quesito, também deve ser levado em consideração contratar
um profissional experiente da área, que possa aplicar treinamentos na
equipe de teste sobre a maneira correta de mexer nestas aplicações.
Planejamento e estimativa de teste

Agora, observe os oito passos para o gerenciamento de teste, de acor-
do com a Norma IEEE 829 de 1998:
1. Especificação do projeto;
2. Plano de teste;
3. Especificação do caso de teste;
4. Especificação dos procedimentos;
5. Relatório do progresso de teste;
6. Log de teste;
7. Relatório de incidentes de teste;
8. Relatório de sumário de teste.
EXPLICANDO
O IEEE (Instituto de Engenheiros Eletricistas e Eletrônicos) é uma orga-
nização sem fins lucrativos localizada nos EUA que cria conhecimentos
na área de tecnologia e eletrônica. Trata-se de uma grande organização,
dedicada a acompanhar e estimular o avanço tecnológico no mundo em
benefício da humanidade. Além disso, essa organização também cria
programas de premiação para invenções e normas, fazendo com que a
empresa que as siga seja reconhecida no meio.

O primeiro estágio a ser executado é a especificação do projeto, no que tange
aos tipos de teste. Por exemplo, se a empresa opta por fazer testes de estresse, de
desempenho, de funcionalidade e de usabilidade, deve-se delimitar:
• Tipos de teste de software a serem feitos: funcionalidade, usabilidade, estresse,
falhas, configuração;
• Níveis de teste: unidade, sistema, integração, aceitação, teste alfa, teste beta.
O segundo estágio a ser executado é um plano de teste. Este plano avalia algu-
mas perguntas, como: quem fará o teste? O que será testado? Com qual programa
o software será testado? Com qual frequência e em quais dias da semana ele será
testado? Quais métricas serão usadas?
Imagine uma empresa que criou uma loja virtual. A empresa, além de definir
qual software usará para testar esta loja, precisa implementar uma rotina de testes,
uma vez que lojas costumam crescer. Assim, ela precisa definir a periodicidade do
teste, o dia do teste e se será o programador ou outra pessoa quem realizará esse
teste, entre outras questões. O que importa é que tudo precisa ser planejado e, para
isso, esta etapa deve abranger os seguintes elementos:
• Software de teste a ser usado;
• Cronograma (recomenda-se o MS Project para realizá-lo);
• Nome das pessoas que irão testar;
• O que cada pessoa irá fazer.
O terceiro estágio a ser empregado é a especificação de quais casos de teste
serão aplicados, que é feita pelo líder de teste. Logicamente essa quantidade varia,
mas é importante ter uma lista advinda do gestor para saber por onde começar.
Ademais, o líder realizará suas escolhas com base nas métricas prioritárias da em-
presa. No exemplo em questão, as escolhas foram:
• Testar login;
• Testar calendário.
Nesta fase, as tarefas serão criadas e executadas. Entretanto, antes de corrigir
problemas, é necessário especificar os procedimentos. Levando em consideração o
exemplo citado, no qual o líder escolheu testar login e testar calendário, chegou o
momento de criar as tabelas de procedimento. Assim, a partir da especifi-
cação feita pelo líder de teste, o analista de teste criará a tabela de
especificação dos procedimentos, que pode ser observada na
Tabela 1 e responde aos seguintes tópicos:

• Resumo;
• Código do projeto;
• Data de início;
• Data de fim;
• Pré-condições;
• Entradas;
• Ação;
• Resultado esperado;
• Pós-condições;
• Testador.
TABELA 1. EXEMPLO DE CASO DE TESTE
Seção Descrição
Resumo Corresponde à explicação do teste. Exemplo: teste de login.

Código 2201
Data de início 23/01
Data de fim 25/01
Testador João Gomes
Para cada situação, descreve a situação inicial que

o sistema deve possuir.
Pré-condições Exemplo:
usuário “Marcia”
senha “333bg”
Descreve o que será feito.

Exemplo:
Entradas
Inserir usuário
Inserir senha
Ações envolvidas no processo.

Ação
Exemplo: clicar em entrar.
É o estado resultante do que se esperava atingir.

Exemplo: abrir a tela do usuário.
Após a execução, mostra o que deveria acontecer

Pós-condições para retornar a outro teste.
Exemplo: clicar em logout.
Seção Descrição
Resumo Teste de salvamento de calendário de eventos.
Código 2202
Data de início 25/01
Data de fim 27/01

Seção Descrição
Testador Julia Soares
Pré-condições Clicar em adicionar evento e abrir o calendário.
Entradas Inserir eventos.
Ação Após inserir eventos, clicar em publicar.
O calendário é carregado não apenas no PC local,

como também na nuvem.
Pós-condições Volta à tela de inserir evento.
Feito isso, recomenda-se utilizar um quadro Kanban, um mural afixado na

parede e que, normalmente, possui três colunas: to do, in progress e done, que
significa a fazer, em progresso e feito, respectivamente. Há ainda gestores que
incluem a coluna priority, que significa prioridade.
É possível utilizar também ferramentas de teste, como TestLink, TestMaster,
entre outras. Nesses programas, pode-se criar três pastas, uma com itens a fa-
zer, outra com itens já feitos e outra com aqueles em progresso. Aqui, referimo-
-nos ao quinto estágio, o relatório do progresso do teste, no qual podemos uti-
lizar algumas referências, como unidade do programa, classe Java do programa
ou tela de interface. Por exemplo:
• Unidade 1: Acabada;
• Unidade 2: Em andamento;
• Unidade 3: Em espera.
Ou
• Classe cliente: Em andamento;
• Classe loja: Em espera;
• Classe pagamento: Em espera.
Ou
• Tela boas-vindas: Acabada;
• Tela de dúvida: Acabada;
• Tela de cadastro: Em andamento.
O sexto estágio a ser realizado é o log de teste. Nesta fase, é útil criar uma lis-
ta de registros com as seguintes informações: data do teste, quem testou, quais
problemas foram apresentados, quais soluções foram encontradas e quais me-
didas serão tomadas para que isto não aconteça novamente. Esta fase é muito
importante, uma vez que, quando um cliente reclamar, a empresa terá os logs

de tudo que ocorreu. Programas de teste como o Selenium, QUnit, JMeter, entre
outros, geram estes relatórios e é sempre bom fazer uso destes recursos para
ter provas legais quando um cliente solicitar, por exemplo.
O sétimo estágio a ser executado é o relatório de incidentes de teste, que
se trata de um resumo mais apurado do log de teste:
As informações contidas neste documento são: número do caso de
teste, status, nome da pessoa responsável pela correção, priorida-
de para correção do erro pelo desenvolvedor, descrição detalha-
da do erro, podendo conter a mensagem de erro exibida na tela, e
nome e data de quem fez a correção (BLANCO, 2012, p. 95).
Ele detalha os resultados obtidos e os compara com os resultados esperados.
Este relatório configura-se como a continuação do caso de teste, mas com resul-
tados e medidas tomadas. Muitas empresas sérias possuem uma boa prática:
após os erros serem corrigidos e incluídos no relatório de incidentes, elas anali-
sam o programa mais uma vez, a fim de garantir que a correção do incidente não
gere outros problemas. Observe que, na Tabela 2, primeiro há os casos de teste
e depois o relatório de incidentes.
TABELA 2. RELATÓRIO DE INCIDENTES
Casos de testes
Nome Projeto: Sistema de Apoio a Tomada de Decisão
Resultado Resultado do Resultado do
ID Módulo Descrição Roteiro
esperado desenvolvedor teste
1) Escolher a Usuário1 -
Alterar Usuário2 -
lteração
Alteração opção Listar Exibir na lista 25/02/2010.
dados 15/02/2010;
1 Usuário; de usuários Mostra um
Usuár
Usuário cadastrais Executado com
2) Clicar em cadastrados. erro ao alterar
dos usuário. sucesso.
alterar na lista. usuário.
1) Escolher a
Mostrar a
opção Inserir
Verificar a mensagem “Campo Usuário2 - Usuário1 -
Alteração Usuário;
de preenchimento 15/02/2010; 25/02/2010.
2 validação 2) Deixar os
Usuá rio
Usuário obrigatório” para Executado com Executado com
dos campos. campos nome,
os campos nome, sucesso. sucesso.
e-mail e senha
senha e e-mail.
em branco.
Mostrar a
1) Escolher a
mensagem “O
opção Inserir
valor fornecido Usuário1 -
Verificar a Usuário; Usuário2 -
Alteração para este campo 25/02/2010.
validação 2) Inserir uma se- 15/02/2010;
3 não pode ter O campo senha
Usuá
Usuário nha com menos Executado com
dos cam
campos.
pos. de 2 caracteres menos que 6 aceita menos de
sucesso.
e mais que 32 6 caracteres.
ou mais de 32
caracteres” para o
caracteres.
campo senha.

Casos de testes
Resultado Resultado do Resultado do
ID Módulo Descrição Roteiro
esperado desenvolvedor teste
1) Escolher a
Mostrar a Usuário2 - Usuário1 -
lteração Verificar a
Alteração opção Inserir
mensagem “O 15/02/2010. 25/02/2010.
4 validação Usuário;
Usuár
Usuário dos campos. e-mail informado Executado com Executado com
2) Digitar um
não é válido”. sucesso. sucesso.
e-mail inválido.
Relatório de Incidente
Responsável Prioridade de Descrição do
ID Status Data e nome de quem corrigiu
pela correção correção erro
Pronto Mostra
um erro
1 para testar Usuário2 Alta 01/03/2010 - Usuário2
ao alterar
novamente usuário.
O campo
Pronto
senha aceita
3 para testar Usuário2 Alta 14/03/2010 - Usuário2
menos de 6
novamente
caracteres.
No cabeçalho
Pronto
o nome do
3 para testar Usuário1 Baixa 10/03/2010 - Usuário1
relatório está
novamente
errado.
Fonte: BLANCO, 2012.
Por fim, o oitavo estágio a ser realizado é o relatório de sumário de teste.

Ele é mais subjetivo e avalia a qualidade do software, o tempo de testes, o
tempo gasto na resolução de problemas, outros problemas gerados nas cor-
reções, quanto tempo eles duraram, se poderão ser aproveitados para outros
testes, se a empresa precisará de reformulação de funcionários, entre outras
questões. Sobre isso, Blanco afirma que:
Este é o documento final a ser preenchido pela equipe de teste
com as seguintes informações: nome do projeto; data do início
e fim do teste; descrição detalhada de como foi o teste; pessoas
envolvidas; os principais números dos testes, como por exem-
plo, número de casos de teste criados antes e durante a execu-
ção dos testes, e o número de execuções com sucesso; tipos de
status: completado com sucesso, completado com restrições, e
não completado; percentual de casos de teste executados; per-
centual de casos com sucesso e erros e percentual de casos de
testes corrigidos pelo desenvolvedor (BLANCO, 2012, p. 96).

Por fim, cabe citar que é sempre bom aplicar o método de gestão denomi-
nado de PDCA para obter a melhoria contínua. A sigla significa planejar (plan),
fazer (do), avaliar o que deu errado (check) e refazer o plano (act). Este méto-
do permite melhorar não só a rotina de trabalho dos programadores como
também dos testadores, analistas e líderes de teste, visto que esta área é um
ambiente propício para implementar melhorias, já que a mesma possui mé-
tricas, testes, correções e relatórios. Logo, é possível implementar mudanças.

Sintetizando
Nessa unidade vimos o que são métricas de teste de software, dentre as
quais analisamos métricas de profundidade, que dizem respeito a quão pro-
fundo um teste é, métricas de quantidade, que relacionam-se a quantos erros
o teste detecta, e de severidade, que avaliam quão danosos são os erros en-
contrados. Falamos também de métricas relacionadas ao software, como as
de situação, que mostram o status “realizada”, “pendente” ou “a começar”; de
sumário, um índice de todos os erros que ocorreram; de riscos, formadas por
matrizes de comparação; e de prazo, que medem a quantidade de horas que se
leva para testar e corrigir um erro em software.
Vimos também como criar testes de software com o programa Selenium
ID e, ainda, como baixá-lo, uma vez que ele é uma simples extensão do Mozilla
Firefox. Falamos do surgimento do Selenium e de suas quatro versões: IDE,
Remote Control, Grid e WebDriver. Além disso, houve um exemplo prático no
site da Prefeitura com os assert element present, que testa se um campo está
funcionando, e o not text, que mostra se o campo obrigatório realmente é obri-
gatório. Além disso, neste projeto vimos três programas de gerenciamento de
teste de software: o TestLink, com uma interface bem organizada e diversas
abas que facilitam a organização; o RTH, que auxilia a gestão de testes feitos
recentemente; e o TestMaster, que é ótimo para avaliar métricas de situação,
como concluído, pendente ou a iniciar.
Por fim, vimos ainda os oito estágios para o teste de software, a saber: es-
pecificação do projeto, em que a empresa determina o que será feito; o plano
de teste, em que a empresa determina prazos e cronograma; especificação
do caso de teste, em que a empresa determina quais testes serão realizados;
especificação dos procedimentos, em que a empresa destrincha os passos
para os casos de teste; relatório do progresso de teste, onde se acompanha o
status dos testes; log de teste, em que a empresa cria um re-
gistro com os testes realizados para futura pesquisa; relatório
de incidentes de teste, em que uma tabela de problema gerado
versus situação esperada é criada; e o relatório de sumário de
teste, que é o resumo geral daqueles testes.

BACH, J. Risk-based testing: how to conduct heuristic risk analysis. [s.l.]: Softwa-
re testing & quality engineering magazine, 2002.
BINDER, R. Testing object-oriented system: models, patterns, and tools. Bos-
ton: Addison Wesley, 2000.
BLANCO, M. Documentação de teste baseado na Norma IEEE 829 – estudo de
caso: “sistema de apoio à tomada de decisão”. T.I.S., São Carlos, v. 1, n. 1, p. 91-97,
2012.
ORBIUM. Aplicativo TestMaster: three reasons to invest in testmaster suíte.
2016. Disponível em: <https://orbium.com/wp-content/uploads/2016/06/Or-
bium-Products-Testmaster.pdf>. Acesso em: 18 jan. 2020.
PERES, H. Automatizando testes de software com Selenium. Rio de Janeiro:
Simplíssimos Livros, 2016.
PIRATAS da Informática 1999 - Trailer Legendado. Postado por Portal Clique.
(02min. 01s.). son. color. port. Disponível em: <https://www.youtube.com/wat-
ch?v=Tbk3tq2m25g>. Acesso em: 17 jan. 2020.
PRESSMAN, R.; MAXIM, B. Engenharia de software: uma abordagem profissio-
nal. 8. ed. São Paulo: McGraw Hill Brasil, 2016.
RIOS, E; MOREIRA, T . Teste de software II. São Paulo: Alta Books, 2013.
SAMPAIO, R. Requisitos da ferramenta TestLink: projeto resolução 553 CN 11
Anatel. 2017. Disponível em: <https://docplayer.com.br/20587377-Requisitos-fer-
ramenta-testlink-projeto-resolucao-553-cn-11-anatel-nono-digito.html>. Acesso
em: 18 jan. 2020.

Ebook - Engenharia, Qualidade e Teste de

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Ebook - Engenharia, Qualidade e Teste de

Enviado por

Direitos autorais:

Formatos disponíveis

ENGENHARIA,

gente criando o futuro

Capa_Engenharia de Software_A5.indd 1,3 25/09/19 12:38

eBook Completo para Impressao - Fundamentos da Educacao - Aberto.indd 1 20/11/2019 17:26:50

Diretor-presidente Jânyo Diniz

Diretoria Executiva de Ensino Adriano Azevedo

Diretoria Executiva de Serviços Corporativos Joaldo Diniz

Diretoria de Ensino a Distância Enzo Moreira

Autoria Jailson Costa dos Santos

Projeto Gráfico e Capa DP Content

Análise de Qualidade, Edição de Texto, Design Instrucional,

Edição de Arte, Diagramação, Design Gráfico e Revisão.

© Ser Educacional 2019

Rua Treze de Maio, nº 254, Santo Amaro

Recife-PE – CEP 50100-160

Informamos que é de inteira responsabilidade da autoria a emissão de conceitos.

ou forma sem autorização.

artigo 184 do Código Penal.

Imagens de ícones/capa: © Shutterstock

Engenharia de Software - Unidade_1_A5.indd 2 25/09/19 12:49

Engenharia de Software - Unidade_1_A5.indd 3 25/09/19 12:49

Unidade 1 - Aspectos introdutórios da engenharia de software

Introdução à engenharia do software............................................................................... 19

Mitos e desafios do desenvolvimento de software........................................................ 27

Fundamentos dos processos de desenvolvimento do software................................... 30

Engenharia de Software - Unidade_1_A5.indd 4 25/09/19 12:49

Engenharia de Software - Unidade_1_A5.indd 5 25/09/19 12:49

Unidade 2 - Modelos de software e métodos ágeis

Modelos de processos clássicos de software................................................................ 56

Modelos de processos contemporâneos de software................................................... 75

Métodos ágeis de desenvolvimento.................................................................................. 80

Engenharia de Software - Unidade_1_A5.indd 6 25/09/19 12:49

Unidade 3 - Garantia da qualidade

A garantia da qualidade de software................................................................................ 91

Normas de qualidade aplicadas no desenvolvimento do software.......................... 101

Métricas de qualidade de software................................................................................ 109

Engenharia de Software - Unidade_1_A5.indd 7 25/09/19 12:49

Unidade 4 - Modelagem de sistemas

Modelagem de sistemas.................................................................................................... 125

Tipos de modelo de software............................................................................................ 136

O processo unificado aberto (OpenUP)........................................................................... 141

Engenharia de Software - Unidade_1_A5.indd 8 25/09/19 12:49

Esta disciplina pretende abordar os conceitos fundamentais da en-

Engenharia de Software - Unidade_1_A5.indd 10 25/09/19 12:49

Engenharia de Software - Unidade_1_A5.indd 11 25/09/19 12:49

O Professor Jailson Costa dos Santos

Engenharia de Software - Unidade_1_A5.indd 12 25/09/19 12:49

Engenharia de Software - Unidade_1_A5.indd 13 25/09/19 12:50

Apresentar os aspectos introdutórios da engenharia de software e suas

Abordar os mitos e desafios existentes no desenvolvimento dos

Observar os fundamentos dos processos de desenvolvimento de

Engenharia de Software - Unidade_1_A5.indd 14 25/09/19 12:50

Engenharia de Software - Unidade_1_A5.indd 15 25/09/19 12:50

Engenharia de Software - Unidade_1_A5.indd 16 25/09/19 12:50

A crise de software e a Idade Média

Engenharia de Software - Unidade_1_A5.indd 17 25/09/19 12:50

Causas da crise de software

Engenharia de Software - Unidade_1_A5.indd 18 25/09/19 12:50

Introdução à engenharia do software

Engenharia de Software - Unidade_1_A5.indd 19 25/09/19 12:50

Ao longo deste capítulo, veremos os conceitos relacionados ao desenvolvi-

Software: conceitos e características

Engenharia de Software - Unidade_1_A5.indd 20 25/09/19 12:50