Unicesumar - Projeto Implementação e Teste de Software

Prévia do material em texto

PROJETO, 
IMPLEMENTAÇÃO 
E TESTE DE 
SOFTWARE
Professora Esp. Janaína Aparecida de Freitas
GRADUAÇÃO
Unicesumar
C397 CENTRO UNIVERSITÁRIO DE MARINGÁ. Núcleo de Educação a 
Distância; FREITAS, Janaína Aparecida de. 
 
 Projeto, Implementação e Teste de Software. Janaína 
Aparecida de Freitas.
 Reimpressão - 2020.
 Maringá-Pr.: UniCesumar, 2016. 
 223 p.
“Graduação - EaD”.
 
 1. Projeto. 2. Implementação . 3. Software 4. EaD. I. Título.
ISBN 978-85-459-0318-5
CDD - 22 ed. 005.1
CIP - NBR 12899 - AACR/2
Reitor
Wilson de Matos Silva
Vice-Reitor
Wilson de Matos Silva Filho
Pró-Reitor de Administração
Wilson de Matos Silva Filho
Pró-Reitor de EAD
Willian Victor Kendrick de Matos Silva
Presidente da Mantenedora
Cláudio Ferdinandi
NEAD - Núcleo de Educação a Distância
Direção Operacional de Ensino
Kátia Coelho
Direção de Planejamento de Ensino
Fabrício Lazilha
Direção de Operações
Chrystiano Mincoff
Direção de Mercado
Hilton Pereira
Direção de Polos Próprios
James Prestes
Direção de Desenvolvimento
Dayane Almeida 
Direção de Relacionamento
Alessandra Baron
Head de Produção de Conteúdos
Rodolfo Encinas de Encarnação Pinelli
Gerência de Produção de Conteúdos
Gabriel Araújo
Supervisão do Núcleo de Produção de 
Materiais
Nádila de Almeida Toledo
Supervisão de Projetos Especiais
Daniel F. Hey
Coordenador de Conteúdo
Fabiana De Lima
Design Educacional
Ana Salvadego
Iconografia
Amanda Peçanha dos Santos, Ana Carolina 
Martins Prado
Projeto Gráfico
Jaime de Marchi Junior, José Jhonny Coelho
Arte Capa
Arthur Cantareli Silva
Editoração
Matheus Felipe Davi
Qualidade Textual
Hellyery Agda G. Silva
Naiara Valenciano
Pedro Barth
Ilustração
Marta Sayuri Kakitani
Ficha catalográfica elaborada pelo bibliotecário 
João Vivaldo de Souza - CRB-8 - 6828
Impresso por:
Viver e trabalhar em uma sociedade global é um 
grande desafio para todos os cidadãos. A busca 
por tecnologia, informação, conhecimento de 
qualidade, novas habilidades para liderança e so-
lução de problemas com eficiência tornou-se uma 
questão de sobrevivência no mundo do trabalho.
Cada um de nós tem uma grande responsabilida-
de: as escolhas que fizermos por nós e pelos nos-
sos farão grande diferença no futuro.
Com essa visão, o Centro Universitário Cesumar 
assume o compromisso de democratizar o conhe-
cimento por meio de alta tecnologia e contribuir 
para o futuro dos brasileiros.
No cumprimento de sua missão – “promover a 
educação de qualidade nas diferentes áreas do 
conhecimento, formando profissionais cidadãos 
que contribuam para o desenvolvimento de uma 
sociedade justa e solidária” –, o Centro Universi-
tário Cesumar busca a integração do ensino-pes-
quisa-extensão com as demandas institucionais 
e sociais; a realização de uma prática acadêmica 
que contribua para o desenvolvimento da consci-
ência social e política e, por fim, a democratização 
do conhecimento acadêmico com a articulação e 
a integração com a sociedade.
Diante disso, o Centro Universitário Cesumar al-
meja ser reconhecido como uma instituição uni-
versitária de referência regional e nacional pela 
qualidade e compromisso do corpo docente; 
aquisição de competências institucionais para 
o desenvolvimento de linhas de pesquisa; con-
solidação da extensão universitária; qualidade 
da oferta dos ensinos presencial e a distância; 
bem-estar e satisfação da comunidade interna; 
qualidade da gestão acadêmica e administrati-
va; compromisso social de inclusão; processos de 
cooperação e parceria com o mundo do trabalho, 
como também pelo compromisso e relaciona-
mento permanente com os egressos, incentivan-
do a educação continuada.
Seja bem-vindo(a), caro(a) acadêmico(a)! Você está 
iniciando um processo de transformação, pois quando 
investimos em nossa formação, seja ela pessoal ou 
profissional, nos transformamos e, consequentemente, 
transformamos também a sociedade na qual estamos 
inseridos. De que forma o fazemos? Criando oportu-
nidades e/ou estabelecendo mudanças capazes de 
alcançar um nível de desenvolvimento compatível com 
os desafios que surgem no mundo contemporâneo. 
O Centro Universitário Cesumar mediante o Núcleo de 
Educação a Distância, o(a) acompanhará durante todo 
este processo, pois conforme Freire (1996): “Os homens 
se educam juntos, na transformação do mundo”.
Os materiais produzidos oferecem linguagem dialógica 
e encontram-se integrados à proposta pedagógica, con-
tribuindo no processo educacional, complementando 
sua formação profissional, desenvolvendo competên-
cias e habilidades, e aplicando conceitos teóricos em 
situação de realidade, de maneira a inseri-lo no mercado 
de trabalho. Ou seja, estes materiais têm como principal 
objetivo “provocar uma aproximação entre você e o 
conteúdo”, desta forma possibilita o desenvolvimento 
da autonomia em busca dos conhecimentos necessá-
rios para a sua formação pessoal e profissional.
Portanto, nossa distância nesse processo de cresci-
mento e construção do conhecimento deve ser apenas 
geográfica. Utilize os diversos recursos pedagógicos 
que o Centro Universitário Cesumar lhe possibilita. Ou 
seja, acesse regularmente o AVA – Ambiente Virtual de 
Aprendizagem, interaja nos fóruns e enquetes, assista 
às aulas ao vivo e participe das discussões. Além dis-
so, lembre-se que existe uma equipe de professores 
e tutores que se encontra disponível para sanar suas 
dúvidas e auxiliá-lo(a) em seu processo de aprendiza-
gem, possibilitando-lhe trilhar com tranquilidade e 
segurança sua trajetória acadêmica.
A
U
TO
R
A
Professora Esp. Janaína Aparecida de Freitas
Bacharel em Informática pela Universidade Estadual de Maringá (2010). 
Especialização em MBA em Teste de Software pela Universidade UNICEUMA, 
Brasil. (2012). Trabalhou na iniciativa privada, na área de Analise de Sistemas e 
Testes de Software. Têm experiência na área de Engenharia de Software com 
ênfase em Análise de Requisitos, Gestão de Projetos de Software, Métricas e 
Estimativas, Qualidade e Teste de Software. Atualmente cursando o Técnico 
em Qualidade no Senac-PR e Licenciatura em Letras - Português/Inglês na 
UniCesumar. Atualmente é Professora Mediadora dos cursos de graduação 
ADS – Analise e Desenvolvimento de Sistemas e SI – Sistemas para Internet 
na modalidade de ensino EAD pela UniCesumar (2015).
http://lattes.cnpq.br/4906244382612830
SEJA BEM-VINDO(A)!
Prezado(a) acadêmico(a)! Seja bem-vindo(a) à disciplina Projeto, Implementação e Teste 
de Software. Neste curso, iremos abordar as atividades existentes no processo de desen-
volvimento de software, que são as atividades que envolvem o projeto, a implementa-
ção e o teste de software. 
As unidades do livro foram organizadas de forma contínua, ou seja, a unidade seguinte 
sempre está vinculada com a unidade anterior, portanto, é bom que você leia e entenda 
todo o conteúdo de uma unidade para passar para a próxima. 
Vamos iniciar na unidade I conhecendo os conceitos sobre as fases Projeto, Implementa-
ção e Teste de Software, com o objetivo de compreender a importância destes conceitos 
como partes do processo de desenvolvimento do software. 
Seguindo para a unidade II, vamos conhecer mais a fundo os conceitos que envolvem 
a fase do Projeto e compreender a sua importância e com isso entender como ele pode 
minimizar a distância entre o sistema e o mundo real. Vamos representar o software, 
fornecendo detalhes sobre o seu funcionamento, estruturas, interface e todos os com-
ponentes necessários para desenvolver um sistema. Fase em que deve ser conferido e 
verificado se os requisitos do cliente poderão ser atendidos. No projeto é onde geramos 
uma descrição detalhada informando tudo o que o software deverá fazer e como este 
irá se comportar, sempre levando em conta o que foi levantado na análise de requisitos 
junto ao cliente. 
Depois, na unidade II, na fase de implementação, que é o momento em que desenvol-
vemos o código, vamos ver que além de ser escrito, precisamos testá-lo e depurá-lo, as-
sim como compilá-loe, por fim, ter um produto executável por completo. Durante este 
processo, o ideal é que se utilize um controle de versões para acompanhar as diferentes 
mudanças do código durante o desenvolvimento. Na fase de Implementação, vamos 
detalhar os componentes previstos no projeto, descrevendo todos os componentes de 
código fonte e código binário, em nível de linguagem de programação ou de acordo 
com as tecnologias escolhidas no levantamento de requisitos.
E por fim, nas unidades IV e V, vamos aprender que quando a empresa desenvolvedora 
de software busca por qualidade, ela percebe que é necessário investir pesado em tes-
tes de software e que existem vários tipos de testes no mercado para atender as suas 
necessidades, e que pode ser preciso implantar mais de um tipo ou investir em métricas 
de software para garantia da qualidade destes testes. Ganhando espaço na comunidade 
de software, as métricas de teste de software veem conquistando e sendo de grande 
importância para as empresas que buscam qualidade e eficiência em seus projetos. 
Espero que sua leitura seja agradável e que esse conteúdo possa contribuir para seu 
crescimento pessoal e profissional. Vamos começar nossos estudos?
Boa leitura!
APRESENTAÇÃO
PROJETO, IMPLEMENTAÇÃO 
E TESTE DE SOFTWARE
SUMÁRIO
09
UNIDADE I
INTRODUÇÃO AO PROJETO, IMPLEMENTAÇÃO E TESTES DE SOFTWARE
15 Introdução 
16 Introdução ao Projeto, Implementação e Teste de Software 
21 Projeto de Software 
26 Implementação de Software 
28 Teste de Software 
32 Considerações Finais 
40 Referências 
41 Gabarito 
UNIDADE II
PROJETO DE SOFTWARE
45 Introdução
46 A Fase de Projeto de Software 
49 Conceitos Básicos de Projeto de Software 
52 Qualidade do Projeto 
54 Modelo do Projeto 
55 Projeto da Arquitetura do Software 
63 Projeto de Componentes 
68 Projeto de Interface do Usuário 
71 Modelos de Análise e Projeto de Interfaces 
SUMÁRIO
10
77 Projeto de Dados
80 Considerações Finais 
88 Referências 
89 Gabarito 
UNIDADE III
IMPLEMENTAÇÃO DE SOFTWARE
93 Introdução
94 Implementação de Software 
97 Atividades da Implementação de Software 
100 Características da Implementação de Software 
101 Estilo de Programação e Codificação 
103 Comentários 
106 Depuração 
109 Asserções e Programação Defensiva 
110 Otimização de Desempenho 
112 Refatoração 
114 Considerações Finais 
123 Referências 
124 Gabarito 
SUMÁRIO
11
UNIDADE IV
TESTE DE SOFTWARE
127 Introdução
128 Introdução ao Teste de Software 
132 Conceitos Básicos de Teste de Software 
135 Ciclo de Vida do Teste de Software 
139 Técnicas de Teste de Software 
145 Papéis e Cargos de Teste de Software 
148 Ambiente de Teste 
153 Considerações Finais 
162 Referências 
163 Gabarito 
UNIDADE V
PROCESSO DE TESTE DE SOFTWARE
167 Introdução
168 Documentação de Teste de Software 
178 Relatórios de Teste de Software 
184 Validação e Verificação em Testes de Software 
188 Ferramentas de Teste de Software 
SUMÁRIO
12
194 Métricas e Medição
204 Gerência de Risco em Teste de Software 
213 Considerações Finais 
221 Referências 
222 GABARITO 
223 CONCLUSÃO 
U
N
ID
A
D
E I
Professora Esp. Janaína Aparecida de Freitas
INTRODUÇÃO AO PROJETO, 
IMPLEMENTAÇÃO E TESTES 
DE SOFTWARE
Objetivos de Aprendizagem
 ■ Conceituar Projeto, Implementação e Teste de Software. 
 ■ Compreender a importância desses conceitos como áreas da 
Engenharia de Software.
Plano de Estudo
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
 ■ Introdução ao Projeto, Implementação e Teste de Software
 ■ Projeto de Software
 ■ Implementação de Software
 ■ Teste de Software
INTRODUÇÃO
Olá, aluno(a)! Começamos nossos estudos apresentando alguns conceitos já 
estudados e que fazem parte do processo de software. Mostrarei a você como 
ele é composto de atividades que são necessárias para o desenvolvimento de um 
sistema. No processo de software, existem vários modelos e com algumas ativi-
dades básicas, por exemplo: a análise de requisitos, o projeto, a implementação, 
os testes, a implantação e a manutenção. No nosso livro, vamos estudar apenas 
as atividades que envolvem o projeto, a implementação e o teste de software. 
Nesta primeira unidade, serão apresentados os conceitos sobre as fases (ati-
vidades ou etapas): Projeto, Implementação e Teste de Software, com o objetivo 
de compreender a importância desses conceitos como partes do processo de 
desenvolvimento do software. 
Na fase de Projeto é onde vamos representar o software, fornecendo detalhes 
sobre o seu funcionamento, estruturas, interface e todos os componentes neces-
sários para desenvolver um sistema. Fase onde deve ser conferido e verificado se 
os requisitos do cliente poderão ser atendidos. No projeto é onde geramos uma 
descrição detalhada informando tudo o que o software deverá fazer e como este 
irá se comportar, sempre levando em conta o que foi levantado na análise de 
requisitos junto ao cliente. 
Após a fase de Projeto, passamos a fase de implementação, ou seja, a pro-
gramação, a codificação do código e onde determinamos a linguagem que será 
usada para o desenvolvimento do sistema. Nesta fase, construímos o software 
baseado nas definições técnicas da fase de projeto e entramos na prática do 
desenvolvimento do sistema. 
Na fase de testes, passamos a validar o sistema que foi implementado. Nesta 
fase são testados os códigos à procura de defeitos, problemas que podem ocor-
rer na interface e outros que possam surgir quando o sistema é integrado. 
Assim, nosso objetivo nesta unidade é entender os conceitos das etapas que 
envolvem o processo de software e como são relacionadas. 
Vamos, portanto, aos conceitos! Boa leitura!
Introdução
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
15
©shutterstock
INTRODUÇÃO AO PROJETO, IMPLEMENTAÇÃO E TESTES DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E16
INTRODUÇÃO AO PROJETO, IMPLEMENTAÇÃO E 
TESTE DE SOFTWARE
Para compreendemos os conceitos de Projeto, Implementação e Teste de Software, 
é necessário que revisemos alguns conceitos do processo de software que já foram 
estudados. Vamos lá?
Conforme Sommerville (2011, p. 42), um processo de software é conside-
rado um conjunto de atividades, que pode levar a construção de um software, 
e embora existam processos diferentes, algumas atividades fundamentais são 
comuns a todos, como:
 ■ Especificação de software: define a funcionalidade do software e as res-
trições sobre sua operação devem ser definidas. 
 ■ Projeto e Implementação de software: definem as funcionalidades para 
que o software atenda à especificação dada pelo cliente. 
Introdução ao Projeto, Implementação e Teste de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
17
 ■ Validação de software: o software deve ser validado para garantir que faça 
o que o cliente deseja.
 ■ Evolução de software: o software deve evoluir para atender as necessida-
des mutáveis do cliente. 
No nosso livro vamos estudar apenas as atividades que envolvem o projeto, a 
implementação e o teste de software, momento em que o software é validado. 
Após os Requisitos de Software terem sido especificados e modelados, é 
iniciada a primeira fase, o Projeto, em que é definido como o software será cons-
truído, sua arquitetura, interfaces, componentes que poderão ser utilizados e 
outras características que podem ser determinantes para se gerar um software. 
Conforme Pressman (2011, p. 206), é na fase de requisitos que é convertido o “que” 
é para ser feito e detalhado e na fase de projeto é indicado o “como” deverá ser o 
desenvolvimento, fornecendo detalhes da arquitetura e os componentes essen-
ciais para a implementaçãodo sistema. O profissional responsável por essa fase 
é conhecido como o Arquiteto de Software, que possui experiência como pro-
gramador e possui amplos conhecimentos sobre a Gerência de Projetos. 
Na segunda etapa, codificamos o sistema conforme o que foi definido na 
etapa de Projeto. Nesta fase, definimos a linguagem que será usada, ferramentas 
que poderão auxiliar, bibliotecas de classes para acelerar as tarefas, e ferramen-
tas CASE, que podem ser usadas para agilizar a compreensão na hora de gerar 
os códigos e a documentação do software. O profissional responsável por essa 
etapa é o Programador ou Desenvolvedor, que precisa ter um bom raciocínio 
lógico e gostar de resolver problemas. 
Depois na terceira etapa, é o momento em que os Testes são executados. 
Nessa fase, fazemos a validação do comportamento de cada funcionalidade dos 
módulos do sistema. É nessa fase que verificamos o que foi definido na Análise 
de Requisitos e rastreamos os possíveis erros e falhas que possam ter ficado em 
alguma fase. Neste momento, os resultados dos testes executados são mostrados 
em relatórios, que mostram as informações sobre os erros encontrados e como 
o software está se comportando até o momento. O profissional responsável por 
essa fase é o Testador, que pode ser conhecido por outras denominações como: 
Gerente de Testes, Projetista de Testes, Analista de Testes, entre outros nomes. 
INTRODUÇÃO AO PROJETO, IMPLEMENTAÇÃO E TESTES DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E18
Assim, ao final da etapa de Testes, todos os módulos do sistema são rela-
cionados e integrados dando origem ao produto de software, que deve ser 
mostrado ao usuário para que ele verifique se o sistema desenvolvido atende as 
suas necessidades. 
Na visão de Pressman, as atividades do processo de software:
Para muitos projetos de software, as atividades metodológicas são 
aplicadas iterativamente conforme o projeto se desenvolve. Ou seja, 
comunicação, planejamento, modelagem, construção e emprego são 
aplicados repetidamente quantas forem as iterações do projeto, sendo 
que cada iteração produzirá um incremento de software. Este disponi-
bilizará uma parte dos recursos e funcionalidades do software. A cada 
incremento, o software torna-se mais e mais completo. (PRESSMAN, 
2011, p. 41).
Para Sommerville (2011, p.124) “o Projeto e Implementação de software é um 
estágio do processo no qual um sistema de software executável é desenvolvido. 
O Projeto de software é uma atividade criativa em que você identifica os compo-
nentes de software e seus relacionamentos com base nos requisitos do cliente. A 
Implementação é o processo de concretização do projeto como um programa. O 
Projeto e a Implementação estão intimamente ligados e, ao elaborar um projeto, 
você deve levar em consideração os problemas de implementação”. E os testes de 
software? O teste mostra o que um programa faz e o que ele foi proposto a fazer 
e assim descobrir as falhas que o sistema tem antes do uso do cliente. Isso por-
que nessa fase testamos o que foi projetado e o que foi implementado.
Vamos resumir as fases para que fique mais claro o que veremos nesta 
disciplina: 
 ■ Projeto: é esclarecido “como” o software será desenvolvido.
 ■ Implementação: é definida a linguagem que será usada para programar (codificar) 
o sistema.
 ■ Teste: o software é testado, levando em consideração o que foi levantado nos 
requisitos.
Introdução ao Projeto, Implementação e Teste de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
19
Figura 1- Modelo Cascata 
Projeto de
 sistema e software
Implementação e 
teste de unidade
Integração e 
teste de sistema
Operação e
manutenção
De�nição de 
requisitos
Fonte: Sommerville, (2011).
Conforme Pressman (2011, p. 207), o Projeto de Software reside no núcleo téc-
nico da engenharia de software sendo aplicado independentemente do modelo 
de processos de software utilizado, iniciando-se assim que os requisitos de sof-
tware forem analisados e modelados sendo assim, o projeto é a última ação da 
engenharia de software da atividade de modelagem e prepara a cena para a fase 
de implementação (geração de código) e depois para os testes (validação). 
INTRODUÇÃO AO PROJETO, IMPLEMENTAÇÃO E TESTES DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E20
Agora, aluno(a), vamos entender um pouco mais sobre cada fase nesta unidade, 
e, depois, com mais detalhes nas unidades posteriores do livro. Começaremos 
conhecendo um pouco mais sobre a fase de Projeto de Software. 
O Processo de Software
Processo é um conjunto de atividades, ações e tarefas realizadas na criação 
de algum produto de trabalho (work product). Uma atividade esforça-se para 
atingir um objetivo amplo (por exemplo, comunicação com os interessados) 
e é utilizada independentemente do campo de aplicação, do tamanho do 
projeto, da complexidade de esforços ou do grau de rigor com que a en-
genharia de software será aplicada. Uma ação envolve um conjunto de ta-
refas que resultam num artefato de software fundamental. Uma tarefa se 
concentra em um objetivo pequeno, porém, bem definido (por exemplo, 
realizar um teste de unidades) e produz um resultado tangível. No contex-
to da engenharia de software, um processo não é uma prescrição rígida de 
como desenvolver um software. A intenção é a de sempre entregar software 
dentro do prazo e com qualidade suficiente para satisfazer àqueles que pa-
trocinaram sua criação e àqueles que irão utilizá-lo.
Fonte: Pressman (2011). 
“Todo engenheiro de software deve reconhecer que modificações são natu-
rais. Não tente combatê-las.”
(Pressman).
©
shutterstock
Projeto de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
21
PROJETO DE SOFTWARE
O conceito de Projeto de Software, conforme Pressman, é definido como:
A atividade de projeto de software engloba o conjunto de princípios, con-
ceitos e práticas que levam ao desenvolvimento de um sistema ou produto 
com alta qualidade. Os princípios de projeto estabelecem uma filosofia 
que prevalece sobre as atitudes e ações do desenvolvimento, orientando as 
atividades para realizar o projeto. Os conceitos de projeto devem ser esta-
belecidos e entendidos antes de aplicar a prática de projeto, que deve levar 
à criação de várias representações do software que servem como um guia 
para a atividade de construção que se segue. (2011, p. 206). 
Por sua vez, Sommerville define Projeto de Software como:
Um projeto de software é a descrição da estrutura de software a ser im-
plementada, dos dados que são partes do sistema, das interfaces entre os 
componentes do sistema, e às vezes dos algoritmos usados. (2011, p. 50). 
Podemos citar outros conceitos de Projeto. Conforme a ABNT (Norma técnica 
NBR 10006), projeto é considerado um “Processo único, consistindo de um grupo 
de atividades coordenadas e controladas com datas para início e término, empre-
endido para alcance de um objetivo conforme requisitos específicos, incluindo 
limitações de tempo, custo e recursos”. 
O Projeto de Software faz parte dos processos da Engenharia de software, ele 
inicia logo após a Análise de Requisitos ter sido levantada, analisada e modelada. 
O projeto tem como objetivo definir uma estrutura que possa ser implementada 
em um produto de software e que atenda aos requisitos especificados para ele 
na análise. Na Análise de Requisitos é levantado “o que” será implementado, no 
Projeto de Software é definido “como” será construído. 
INTRODUÇÃO AO PROJETO, IMPLEMENTAÇÃO E TESTES DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E22
O projeto de software é um processo que possuias seguintes atividades: 
estrutura de dados, arquitetural, componentes e interface. Cada um dos proje-
tos citados acima, será detalhado na unidade II do livro.
Conforme Pressman (2011, p. 206), o Projeto de Software cria uma repre-
sentação fornecendo detalhes sobre a arquitetura do software, as estruturas de 
dados, interfaces e componentes fundamentais para implementar um sistema. 
Quando pensamos em projeto, devemos sempre ter em mente que quanto 
mais detalhado e refinado ele for, mas fácil e tranquila será a próxima fase de 
implementação. Portanto, é importante conhecer todas as tecnologias envolvidas 
em que o software será implantado e suas soluções, caso ocorram imprevistos. A 
qualidade do software pode ser avaliada nesta fase, pois o projeto serve de base 
para as demais fases no desenvolvimento de um sistema. 
Conforme Pressman (2011, p.116), os modelos de requisitos representam os 
requisitos dos clientes. Os modelos de projeto oferecem uma especificação con-
creta para a construção do software. 
Figura 2 - Transformando o modelo de requisitos no modelo de projeto.
 
Projeto de dados/classes
Projeto arquitetural
Projeto de 
interface
Projeto de 
componentes
Modelos de projeto
Elementos baseados 
em cenários
Casos de uso - texto
Diagramas de casos de uso
Diagramas de atividades
Diagramas de Raias
Diagramas de �uxo 
de dados
Diagramas de �uxo de dados
Diagramas de �uxo de controle
Narrativas de processamento
Elementos baseados 
em classes
Diagrama de classes
Pacotes de análise
Modelos CRC
Diagramas de colaboração
Elementos 
comportamentais
Diagramas de estados
Diagramas de sequência
Modelos de 
análise
Fonte: Pressman, (2011). 
Projeto de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
23
Segundo Pressman (2011, p. 178) o modelo de requisitos é usado para preen-
cher a lacuna entre uma representação sistêmica que descreve o sistema (como 
o usuário imagina) como um todo ou a funcionalidade de negócio, e o modelo 
de projeto de software é usado para descrever a arquitetura da aplicação de sof-
tware, a interface do usuário e a estrutura no nível de componentes.
Figura 3 - A Fase do Projeto
Domínio do 
problema
Domínio da 
solução
Análise e 
Especi�cação 
de Requisitos 
(o quê)
Projeto
(como)
Mundo Real
Mundo 
Computacional
Implementação
Fonte: Falbo, (2012).
Seguindo a visão de Pressman sobre a fase de projeto, temos:
O processo de projeto passa de uma visão macro do software para uma 
visão mais estreita que define os detalhes necessários para implementar 
um sistema. O processo começa concentrando-se na arquitetura. São 
definidos subsistemas; são estabelecidos mecanismos de comunicação 
entre os subsistemas; são identificados componentes; e é desenvolvida 
uma descrição detalhada de cada componente. Além disso, são proje-
tadas interfaces externas, internas e para o usuário. (PRESSMAN, 2011, 
p. 226).
INTRODUÇÃO AO PROJETO, IMPLEMENTAÇÃO E TESTES DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E24
Conforme Falbo (2012), o objetivo da fase de projeto é definir e especificar uma 
solução a ser implementada para um problema. Assim, podemos dizer que é 
uma fase em que tomamos muitas decisões, pois temos ao nosso alcance mui-
tas soluções que podem ser possíveis. Ainda, segundo Falbo (2012), o projeto é 
um processo de refinamento.
Assim, de maneira geral, Falbo (2012, p. 10) descreve que um projeto deve:
 ■ Considerar abordagens alternativas com base nos requisitos do problema.
 ■ Restrições e conceitos de projeto.
 ■ Ser rastreável a sua especificação.
 ■ Não “reinventar a roda”, isto é, reutilizar soluções.
 ■ Exibir uniformidade (estilo) e integração (interfaces bem definidas entre-
componentes da coisa a ser construída).
 ■ Ser estruturado para acomodar mudanças.
 ■ Ser passível de avaliação da qualidade.
 ■ Ser revisado para minimizar erros.
Também, segundo Falbo (2012, p. 10) em geral, um modelo de projeto deve:
 ■ Prover uma visão da totalidade do que deve ser construído.
 ■ Decompor o todo em partes e prover diferentes visões.
 ■ Refinar e descrever com mais detalhes cada parte ou visão do que deve 
ser construído, de modo a prover orientação para a construção de cada 
detalhe.
Projeto de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
25
Planejamento de projetos
Uma coisa é exigir dos engenheiros de software estimativas de prazos, e 
cobrar o cumprimento dos prazos prometidos. Clientes e gerentes podem 
e devem fazê-lo. Outra coisa é pressioná-los para que façam promessas que 
não podem ser cumpridas. Uma frase comum desta cultura é: “Não me in-
teressa como você vai fazer, desde que entregue no prazo!”. Na realidade, o 
cliente ou gerente deve, no seu próprio interesse, ter algum meio de checar 
se o cronograma e orçamento propostos são realistas; se preciso, recorren-
do aos serviços uma terceira parte. A cultura do prazo político é ruim para 
todos. Para os desenvolvedores, ela significa estresse e má qualidade de 
vida. Para os gerentes, perda de credibilidade e prejuízos. E para os clientes, 
produtos de má qualidade e mais caros do que deveriam. Ainda por cima, 
entregues fora do prazo.
Fonte: Paula Filho, (2009).
“Os princípios de projeto estabelecem uma filosofia que prevalece sobre as 
atitudes e ações do desenvolvimento, orientando as atividades para realizar 
o projeto.”
(Pressman). 
©shutterstock
INTRODUÇÃO AO PROJETO, IMPLEMENTAÇÃO E TESTES DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E26
IMPLEMENTAÇÃO DE SOFTWARE
Conforme Sommerville (2011, p. 25), a implementação de software é o pro-
cesso de conversão de uma especificação do sistema em um sistema executável. 
A fase de implementação sempre começa quando a fase de projeto tiver sido 
encerrada. Na Implementação de Software serão detalhados os componentes 
que foram descritos na fase de projeto, como os códigos-fonte usados na lin-
guagem de programação, lembrando que devem ser conforme as tecnologias 
que foram informadas. 
Na implementação é definida a linguagem de programação, que pode ser 
Java, C#, PHP, C++ ou qualquer outra, que possa desenvolver o que foi mode-
lado na fase de projeto. O código é escrito por programadores e é importante 
que haja uma organização na escrita das instruções. Essa organização pode ser 
definida com a criação de padrões a serem seguidos pela equipe de programação. 
Exemplo de padrões que podem ser definidos: declaração de nomes de variáveis, 
formato de cabeçalhos, comentários dos códigos e como documentar o código. 
Nessa fase, construímos e codificamos os programas e os módulos que envol-
vem o software são integrados. 
Pressman (2011, p. 395) afirma que os problemas de confiabilidade de software 
podem quase sempre ser associados a defeitos de projeto ou de implementação. 
Implementação de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
27
Ele afirma que todas as falhas que um software possui estão associadas aos pro-
blemas na fase de projeto e de implementação. Segundo o autor, as falhas são 
de ambos, tanto do cliente, quanto de quem desenvolve o software. 
A fase de implementação é uma maneira de formalizar ou mostrar, utili-
zando uma linguagem de programação, das análises e os modelos levantados 
nas fases de requisito e de projeto, e gerando assim um sistema que possa exe-
cutar as tarefas que foram descritas pelo usuário. Pressman afirma que podemos 
definir a implementação como sendo a fase de programação que transformará 
o projeto em um sistema com forma computacional mais palpável pelo usuário. 
Na fase de implementação, tambémpodem ser iniciados alguns testes (fase 
que será vista posteriormente), por exemplo, os testes de depuração de erros que 
são executados durante a programação e podem ser executados pelos próprios 
programadores. É importante que nessa fase as “versões” do sistema que estão 
sendo implementadas sejam controladas e gerenciadas, para que se tenha um 
controle de tudo o que está sendo codificado e alterado. 
Questões importantes na implementação de software
A implementação demanda grande parte do tempo no processo de desen-
volvimento de um software, por ser uma das atividades mais trabalhosas 
e exigir grandes habilidades do profissional da área de informática. Assim, 
antes de se iniciar a etapa de implementação de um software, é necessário 
escolher o ambiente de programação e tratar outras questões que possam 
influenciar direta ou indiretamente no bom desempenho dessa atividade.
Além da escolha do ambiente de programação, existem boas práticas a se-
rem seguidas para facilitar, principalmente, a manutenção do software e, 
ainda, alguns problemas a serem solucionados relativos à documentação, 
às rotinas de teste, à integração da equipe de desenvolvimento e à compo-
sição de arquivos de configuração da aplicação. No caso de um ambiente 
orientado a objetos, outros problemas surgem, como, por exemplo, contro-
le de instâncias e relacionamentos entre objetos e persistência de objetos.
Fonte: Valentim, Dias e Pacheco (2008). 
©shutterstock
INTRODUÇÃO AO PROJETO, IMPLEMENTAÇÃO E TESTES DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E28
TESTE DE SOFTWARE
Segundo Weber et al. (2001), a qualidade de software é determinada pela quali-
dade dos processos que são usados durante a fase de desenvolvimento do software. 
A qualidade de software é o resultado de atividades que foram realizadas no 
processo de desenvolvimento desse software. Quando se fala em qualidade de 
software, é necessário lembrar que o projeto do software, o processo de desen-
volvimento e o produto final têm que ter qualidade também (REZENDE, 2005).
O software tornou-se um componente importante e de sucesso para várias 
empresas desenvolvedoras, fazendo que haja uma crescente busca pela quali-
dade do seu produto final, o software (WEBER et al., 2001). Conforme Pressman 
(2011), a atividade de teste de software é uma garantia de qualidade de software 
e ela é a última fase que representa a revisão do que foi especificado nas fases de 
projeto e implementação. 
Conforme Sommerville (2011), os objetivos da fase de teste de software 
podem ser expressos, de forma mais 
clara por:
 ■ Atividade de Teste: processo 
de executar um programa 
com a intenção de localizar 
um defeito/erro.
 ■ Caso de teste bom: apresenta 
uma elevada probabilidade 
de revelar um defeito/erro 
ainda não descoberto.
“Quando seu cliente tiver uma necessidade legítima, mas sem a mínima 
ideia em relação a detalhes, faça um protótipo para uma primeira etapa.”
(Pressman).
Teste de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
29
O objetivo de qualquer empresa de software é produzir software com qua-
lidade, nos prazos estabelecidos e que obtenha a satisfação do cliente. Para isso, 
devemos produzir o software conforme os requisitos que foram levantados e 
implementá-los nos prazos estabelecidos e com um nível de defeitos aceitável, 
para a satisfação do cliente (PRESSMAN, 2011). 
Conforme Molinari (2003), o teste é uma atividade que deve ocorrer paralela 
ao desenvolvimento e conduzida nas diversas fases do processo de desenvol-
vimento de software. E, para isso, o teste deve ser planejado, controlado e 
supervisionado por profissionais experientes. A equipe de teste deve identificar 
e minimizar os erros no software e executar atividades em paralelo ao teste, como 
documentação e relatórios. Bastos (2006) aponta que quanto menos defeitos 
forem deixados no software nas fases iniciais, menos custos terá a sua manuten-
ção depois do software estiver pronto. 
Sobre o teste, Pressman (2000, p. 78) afirma:
O teste muitas vezes requer mais trabalho de projeto do que qualquer 
outra ação da engenharia de software. Se for feito casualmente, perde-
-se tempo, fazem-se esforços desnecessários, e, ainda pior, erros pas-
sam sem ser detectados. Portanto, é razoável estabelecer uma estratégia 
sistemática para teste de software.
De acordo com Molinari (2003), todo software que se destina ao público e/ou 
ao mercado deve sofrer um nível mínimo de teste. Assim, quanto maior o nível 
de complexidade do software, mais testes e técnicas de testes se tornam neces-
sários para a obtenção da sua qualidade.
Sem os testes, não se consegue garantir que o software irá se comportar con-
forme o esperado ou conforme as solicitações do cliente, e isso pode ser negativo 
para a empresa que o desenvolveu. Mas caso na empresa não se tenha uma análise 
de requisitos ou uma documentação do software detalhada, a equipe de desen-
volvimento e a equipe de teste não saberão se o que está sendo construído é o 
que o cliente espera. Pensando nisso, Molinari (2003) destacou axiomas e con-
ceitos que podem ser usados no processo de teste, e que em muitos casos são 
considerados como verdades no mundo dos testes. Podem ser listados como:
INTRODUÇÃO AO PROJETO, IMPLEMENTAÇÃO E TESTES DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E30
 ■ Não é possível testar um programa completamente.
 ■ Teste de software é um exercício baseado em risco.
 ■ Teste não mostra que bugs não existem, mas sim, o contrário.
 ■ Quanto mais bugs são encontrados, mais bugs poderão aparecer.
Rios (2008, p.13) denuncia que os testadores querem destruir o software, nocau-
teando através da busca de falhas e indicando seus erros, pois conforme o autor, 
uma vez que se indicam os defeitos de um software, ele pode ser corrigido e com 
isso, se torna muito melhor. 
Conforme Rios e Moreira (2013, p.10), “se não se podem descobrir todos 
os defeitos de um programa e em decorrência disso nunca se pode afirmar que 
ele está 100% correto, por que testar? Porque o propósito dos testes é descobrir 
e corrigir os problemas e, com isso melhorar a sua qualidade. O quanto se quer 
melhorar dependerá de quanto se deseja investir”. O autor ainda acrescenta, que 
“na prática, não se pode testar um programa por completo e garantir que ele 
ficará livre de bugs. É quase impossível testar todas as possibilidades de formas 
e alternativas de entrada de dados, bem como testar as diversas possibilidades e 
condições criadas pela lógica do programador” (RIOS; MOREIRA, 2013, p. 10). 
Conforme Pressman (2011, p. 402), “muitas estratégias de teste de software 
já foram propostas na literatura. Todas elas fornecem um modelo para o teste e 
todas têm [...] características genéricas”, e elas são:
 ■ Executar um teste eficaz, proceder revisões técnicas eficazes. 
 ■ Teste começa no nível de componente e progride em direção à integra-
ção do sistema. 
 ■ Diferentes técnicas de teste são apropriadas para diferentes abordagens.
 ■ O teste é feito pelo desenvolvedor do software e (para grandes projetos) 
por um grupo independente de teste.
 ■ O teste e a depuração são atividades diferentes, mas a depuração deve ser 
associada com alguma estratégia de teste.
Teste de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
31
Para Pressman (2011), o teste dificilmente chega ao fim. O que acontece é uma 
transferência do desenvolvedor para o seu cliente, ou seja, toda vez que um cliente 
usa o sistema, um teste está sendo realizado. 
“Os problemas de confiabilidade de software podem quase sempre ser asso-
ciados a defeitos de projeto ou de implementação”.
(Pressman).
O testador deve saberexatamente o seu nível de competência que é medi-
do pela sua experiência e pelos cursos que fez. Não tente testar um software 
para o qual você não tenha o conhecimento técnico suficiente. Testar sof-
twares embarcados não é a mesma coisa que testar softwares comerciais. 
A sua graduação como testador deve sempre dizer até onde você poderá 
chegar com o seu trabalho, logo não ultrapasse limites, pois nessas faixas é 
que poderão aparecer os seus maiores defeitos. Aquele testador que regis-
tra um defeito dando palpites técnicos sobre como o software deveria ser 
desenvolvido, com toda a certeza está ultrapassando os seus limites. Conhe-
ça a sua área de atuação e os limites que demarcam os seus conhecimentos 
daqueles inerentes aos do desenvolvedor.
Fonte: Rios (2008). 
INTRODUÇÃO AO PROJETO, IMPLEMENTAÇÃO E TESTES DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E32
CONSIDERAÇÕES FINAIS
Chegamos ao fim da nossa primeira unidade do livro. Nela discorremos sobre 
as fases que envolvem o processo de desenvolvimento do software e vimos tam-
bém os conceitos voltados ao projeto, à implementação e o teste de software. 
Foram apresentados aspectos relativos ao projeto, mostrando a importância 
dela e como essa fase é fundamental para o desenvolvimento de um software. 
Um dos principais objetivos visto da fase de projeto, e que ela define como vai 
ser a arquitetura do software, tendo como base o que foi levantado na análise 
de requisitos. 
 Ao longo da unidade, foram relacionados os conceitos de implementação, 
pois é nesta fase que o projeto se transformará em um sistema, em que os códi-
gos de programação serão codificados baseados nas definições descritas na fase 
de projeto. A implementação faz uso de linguagens de programação, podendo 
ser visuais e orientadas a objeto, do que foi analisado na análise de requisitos e 
o que foi determinado na fase de projeto. 
Vimos os conceitos iniciais sobre qualidade, que está intimamente relacio-
nada às atividades de teste. Também verificamos que sem os testes o software 
pode se comportar de maneira inesperada ou ainda não seguir o foi esperado 
ou analisado. Isso pode fazer com que o cliente ache que pagou por um produto 
que ele não solicitou, e tal fato pode ser negativo para a empresa que está desen-
volvendo o sistema. 
Espero que, até aqui, já tenho colaborado com o seu entendimento do que é 
projeto, implementação e teste de software, já que estes são os nossos principais 
assuntos que serão discutidos durante o nosso estudo durante a disciplina. Nas 
próximas unidades do livro há informações mais detalhadas sobre cada uma das 
fases. Preparado(a)? Então, vamos continuar com a leitura!
33 
1. Após os Requisitos de Software terem sido especificados e modelados, é iniciada 
a primeira fase, em que é definido como o software será construído, sua arqui-
tetura, interfaces, componentes que poderão ser utilizados e outras característi-
cas que podem ser determinante para se gerar um software. Qual o nome desta 
fase? 
2. Assinale a alternativa correta, marcando com (V) a assertiva verdadeira e com (F) 
a assertiva falsa sobre os processos de software. 
( ) Projeto e Implementação de software: definem as funcionalidades para que o 
software atenda à especificação dada pelo cliente. 
( ) É nesta fase que são testados os códigos à procura de mais requisitos, que 
possam causar problemas que podem ocorrer na interface e outros que possam 
surgir quando o sistema é integrado. 
( ) A implementação de software é o processo de conversão de uma especifica-
ção do sistema em um sistema executável.
( ) O projeto de software é a última ação da engenharia de software da ativida-
de de modelagem e prepara a cena para a fase de implementação (geração de 
código) e, depois, para os testes (validação). 
Assinale a opção com a sequência CORRETA.
a. V, F, V, V.
b. F, V, V, F.
c. V, V, V, F.
d. F, V, F, F.
3. Descreva os conceitos de projeto, implementação e testes de software. 
4. A afirmação que diz que: “todas as falhas que um software possui estão associa-
das aos problemas na fase de projeto e de implementação” está correta? 
5. O objetivo de qualquer empresa de software é produzir software com qualidade, 
nos prazos estabelecidos e que obtenha a satisfação do cliente. Estamos falando 
de:
( ) Projeto.
( ) Implementação.
( ) Programação.
( ) Teste.
( )Requisitos.
34 
6. Assinale a alternativa correta que preenche sequencialmente as lacunas do tex-
to.
Na ____________ é esclarecido “como” o software será desenvolvido. Por sua 
vez, no ____________ é definida a linguagem que será usada para programar 
(codificar) o sistema. E no _______________ o software é testado, levando em 
consideração o que foi levantado nos requisitos. 
a. Implementação, teste, projeto.
b. Teste, implementação, projeto.
c. Projeto, teste, implementação.
d. Projeto, implementação, teste.
7. Quais os profissionais responsáveis pelas fases: Projeto, Programação e Imple-
mentação de Software? 
8. Qual das fases do processo de desenvolvimento de software, cria-se uma repre-
sentação fornecendo detalhes sobre a arquitetura do software, as estruturas de 
dados, interfaces e componentes fundamentais para implementar um sistema? 
35 
SUPORTE A PADRÕES NO PROJETO DE SOFTWARE
Alexandre Dantas, Gustavo Veronese
Alexandre Correa, José Ricardo Xavier, Cláudia Werner
1 – Introdução
Fundamentalmente, o projeto de software envolve uma sistemática de decomposição 
da solução, a começar pela descrição em mais alto nível dos principais elementos do 
sistema e, em seguida, criando uma visão mais detalhada de como as características e 
funções deste sistema deverão estar integradas. Projetar software orientado a objetos 
é uma tarefa difícil, e projetar software orientado a objetos reutilizável e flexível é ainda 
mais difícil. Este trabalho apresenta mecanismos de suporte à representação, sugestão 
e identificação de conhecimentos obtidos a nível de projeto, no ambiente de desenvol-
vimento de software 
[...]
2 – Representação do Conhecimento de Projeto
Projetistas de sistemas de software vêm, ao longo dos anos, reconhecendo a importân-
cia de se representar e explorar o conhecimento obtido durante a construção de siste-
mas. Uma das formas consiste no reconhecimento e utilização de boas práticas, idéias e 
soluções já aplicadas em situações de sucesso e fracasso em projetos de software, como 
heurísticas de projeto, padrões e anti-padrões.
2.1 – Heurísticas de Projeto
Uma heurística de projeto é uma diretriz resultante de conhecimento e experiência que 
serve como um conselho para tomada de decisões de projeto, sendo de grande im-
portância no sentido de guiar o projetista na elaboração de boas soluções ao longo do 
desenvolvimento. É importante notar que uma heurística não deve ser vista como uma 
regra inviolável que deva ser seguida em todas as circunstâncias. Possíveis violações a 
estas heurísticas devem ser consideradas como avisos ou indicadores de que alguma 
decisão de projeto pode ter sido tomada incorretamente. 
[...]
36 
2.2 – Padrões
Podemos pensar em um padrão como a reutilização da essência de uma solução para 
determinados problemas similares. Sintetizando as definições encontradas na literatura, 
podemos dizer que um padrão resolve um problema recorrente, em um determinado 
contexto, fornecendo uma solução que comprovadamente funcione, além de informar 
os resultados e compromissos da sua aplicação, e subsídios para que seja possível adap-
tar esta solução a uma variante do problema. Ao contrário das heurísticas, os padrões 
disponíveis na literatura estão descritos de forma explícita e organizada. Embora exis-
tam várias formas de descrição de um padrão, de modo geral, a descrição de um padrão 
deve conter as seguintes informações: Nome do padrão, o problema, o
contexto, a solução, as consequências, o uso conhecido e os padrões que são relacio-
nados. SegundoBuschmann, quanto maior o número de padrões em um sistema de 
padrões, maior é a dificuldade de entendê-los e utilizá-los. 
[...]
2.3 – Anti-Padrões
Um anti-padrão pode resultar da falta de conhecimento de uma solução mais adequada, 
ou ainda da aplicação de um padrão (teoricamente, uma boa solução) no contexto in-
correto. Os anti-padrões descrevem soluções Inadequadas para um problema que resul-
ta em uma situação ruim, ou então descrevem como sair de uma situação ruim e chegar 
a uma boa solução. A presença de “bons” padrões em um sistema bem sucedido pode 
não ser suficiente. É preciso mostrar que estes padrões geralmente não ocorrem em 
sistemas mal sucedidos, e que determinadas construções inadequadas (anti-padrões) 
encontradas em sistemas mal sucedidos geralmente não estão presentes em sistemas 
bem sucedidos.
[...]
3 – Suporte a Padrões no Ambiente Odyssey
A partir da representação do conhecimento de projeto através dos conceitos descritos 
na seção anterior, foi implementado um conjunto de mecanismos em um ambiente de 
desenvolvimento de software visando apoiar a utilização deste conhecimento durante 
o projeto de software orientado a objetos. Nesta seção, apresentamos detalhes sobre a 
implementação e funcionamento destes mecanismos.
[...]
37 
Instanciação de Padrões de Projeto
O mecanismo de instanciação de padrões de projeto procura oferecer ao usuário proje-
tista uma forma de replicar uma solução com base em um padrão identificado para uma 
situação adequada ao seu projeto em desenvolvimento. Para isso, o padrão, conforme 
representado no catálogo, é transportado para o diagrama de classes do projetista. Este 
transporte é caracterizado pela cópia da estrutura de classes e relacionamentos que cor-
respondem ao padrão.
[...]
3.3 – Seleção de padrões arquiteturais
Um dos aspectos críticos de se desenvolver software com ênfase arquitetural é a seleção 
de um estilo, ou padrão arquitetural [9]. Neste sentido, identificamos a oportunidade 
de apoiar a seleção de padrões arquiteturais utilizando uma abordagem orientada pela 
necessidade de se obter determinadas características de qualidade para o software a ser 
produzido. Estas características são baseadas na norma ISO/IEC 9126-1.
O suporte a padrões do ambiente Odyssey oferece um mecanismo para realização de 
uma comparação entre os requisitos de qualidade arquiteturais identificados para a 
aplicação e os obtidos pela utilização de cada padrão catalogado, com a intenção de 
se chegar a um indicador de padrão que melhor represente uma solução para o atendi-
mento aos requisitos esperados.
[...]
3.4 – Deteção de Padrões e Anti-Padrões
O suporte a padrões do ambiente Odyssey fornece um mecanismo de detecção de 
construções boas, assim como ruins. O principal objetivo desta detecção é fornecer su-
porte para a reestruturação de sistemas orientados a objetos legados, e também para 
a avaliação de sistemas ainda em desenvolvimento. A detecção de construções típicas 
(padrões) permite que o projeto do sistema seja entendido em um nível maior de abs-
tração, além de permitir uma avaliação sobre a utilização destes padrões no projeto.
Fonte: Dantas et al., (2002). 
MATERIAL COMPLEMENTAR
Análise e Projeto de Sistemas – Como analisar, planejar, desenvolver e implementar 
sistemas de informação
Lucas Nogueira Padrão
Editora: Viena
Sinopse: Para que um software atinja seu objetivo fi nal, são necessárias diversas etapas que 
são analisadas e discutidas neste livro. A análise e projeto de sistemas consiste em um extremo 
cuidado e infi nito esmero para chegar a um sistema de qualidade.
O livro Análise e Projeto de Sistemas – Como analisar, planejar, 
desenvolver e implementar sistemas de informação foi escrito 
de forma clara e objetiva. Entre os tópicos abordados estão: a análise 
de sistemas, ciclo de vida, metodologia de desenvolvimento, 
diagramas, projeto e implementação, análise de requisitos do 
sistema, tipos de objetos e métodos, herança e polimorfi smo, 
administração de banco de dados, modelagem de processamento 
de dados, redes e tecnologias de transmissão, sistemas distribuídos, 
engenharia de software e seus princípios, metodologias ágeis de 
desenvolvimento de softwares, testes de software e de validação, 
gerência de projetos PMBOK, gerência de projetos de TI.
No fi nal do livro ainda temos um capítulo com exercícios para 
treinar os conhecimentos adquiridos.
Apresentação: Processo de Comunicação. Para saber mais sobre Processo de Comunicação, 
acesse o vídeo produzido pela profa. Daniela Karine Ramos. Dicas valiosas sobre comunicação. 
Não perca!
Em: <http://www.youtube.com/watch?v=_C3AmzKpJbQ&feature=player_embedded>
Acesso em: 20 de out. 2015. 
Material Complementar
MATERIAL COMPLEMENTAR
Apresentação: Como trabalhar com testes de software? Nesse vídeo é dado algumas dicas 
do por que escolher a área de teste de software que pode ser uma boa escolha para começar 
a trabalhar na área de TI, ou mesmo como uma opção para buscar um nova oportunidade do 
mercado de trabalho, visando crescimento na carreira profissional. 
Em: <https://www.youtube.com/watch?v=rL48FS-99ac>
Acesso em: 20 de out. 2015.
Apresentação: Atividades básicas ao processo de desenvolvimento de Software. Esse artigo 
demonstra as principais atividades básicas, comuns aos processos de desenvolvimento de 
software, seus conceitos relevantes, utilizados em organizações que buscam um padrão de 
qualidade no desenvolvimento de suas aplicações. Recomendo que tire um tempinho e leia as 
informações contidas neste link para complementar seus estudos. Acesse o site e leia o artigo na 
íntegra. 
Em: <http://www.devmedia.com.br/atividades-basicas-ao-processo-de-desenvolvimento-de-
software/5413#ixzz3p8FdCqmy>. Acesso em: 17 de maio 2016
REFERÊNCIAS
BASTOS, A. Base de Conhecimento em Teste de Software. Niterói: Traço & Photo, 
2006.
DANTAS, A. R., VERONESE, G.; CORREA, A.; XAVIER, J. R.; WERNER, C. Suporte a Padrões 
no Projeto de Software. Caderno de Ferramentas do XVI Simpósio Brasileiro de 
Engenharia de Software. Gramado, 2002.
FALBO, R. de A. Projeto de Sistemas de Software: Notas de aula. Vitória: - Universi-
dade Federal do Espírito Santo, 2012
MOLINARI, L. Testes de Software: Produzindo Sistemas Melhores e Mais Confiáveis. 
São Paulo: Érica, 2003.
PAULA FILHO, W. de P. Engenharia de Software: fundamentos, métodos e padrões. 
São Paulo: Editora LTC, 2009
PRESSMAN, R. Engenharia de Software. 7. Ed. Porto Alegre: AMGH, 2011.
REZENDE, D. A. Engenharia de Software e Sistemas de Informação. Rio de Janei-
ro: Editora Brasport, 2005.
RIOS, E. Caratê Aplicado ao Teste de Software. Niterói: Imagem art Studio, 2008. 
RIOS, E.; MOREIRA, T. Teste de Software. 3 ed. Rio de Janeiro: Alta Books, 2013
SOMMERVILLE, I. Engenharia de Software. São Paulo: Pearson Prentice Hall, 2011. 
WEBER, K. C., ROCHA, A. R. C.; MALDONADO, J. C. Qualidade de Software – Teoria e 
Prática. São Paulo: Prentice Hall, 2001.
VALENTIM, Lucio Gerônimo; DIAS, M. M.; SANTOS, R. C. S. P. Questões importantes 
na implementação de software. Revista Tecnológica. v. 17. Maringá: 2008, p. 73-80. 
Disponível em: <http://periodicos.uem.br /ojs/index .php/ RevTecnol/article/down-
load /7985/5161>. Acesso em: 25 mar. 2016.
GABARITO
41
1. Após o levantamento dos requisitos de software, é iniciada a fase de Projeto de 
software. 
2. Alternativa A - V, F, V, V.
3. Projeto: a fase de Projeto de Software faz parte dos processos da Engenharia 
de software, tendo início após a Análise de Requisitos ter sido levantada e seu 
objetivo é definir uma estrutura que possa ser implementada em um produto de 
software e que atenda os requisitos especificados para ele na análise. 
Implementação: na fase de Implementação de Software são detalhados os com-
ponentes que foram descritos na fase de projeto, como os códigos fonte que 
serão usados na linguagem de programação.
Teste: a fase de Teste de Software é uma atividade que deve ocorrer paralela 
ao desenvolvimento e conduzidanas diversas fases do processo de desenvolvi-
mento de software. 
4. Os grandes problemas de confiabilidade de software podem quase sempre ser 
associados a defeitos encontrados na fase de projeto ou de implementação, 
onde as falhas são de ambos, tanto do cliente, quanto de quem desenvolve o 
software. 
5. Teste.
6. D - Projeto, implementação, teste
7. Projeto: o profissional responsável é conhecido como o Arquiteto de Software, 
que possui experiência como programador e possui amplos conhecimentos so-
bre a Gerência de Projetos.
Implementação: o profissional responsável por esta etapa é o Programador ou 
Desenvolvedor, com um bom raciocínio lógico, gosta de resolver problemas. 
Teste: o profissional responsável por esta fase é o Testador, que pode ser conhe-
cido por outras variações como: Gerente de Testes, Projetista de Testes, Analista 
de Testes entre outros nomes.
8. Projeto de software.
U
N
ID
A
D
E II
Professora Esp. Janaína Aparecida de Freitas
PROJETO DE SOFTWARE
Objetivos de Aprendizagem
 ■ Compreender a importância do projeto de software, mostrando os 
artefatos que serão criados durante o seu desenvolvimento.
 ■ Entender a importância do projeto e como ele pode minimizar a 
distância entre o sistema e o mundo real.
Plano de Estudo
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
 ■ A fase de Projeto de Software
 ■ Conceitos básicos de Projeto Software
 ■ Qualidade do Projeto
 ■ Modelo do Projeto
 ■ Projeto da Arquitetura do Software
 ■ Projeto de Componentes
 ■ Projeto de Interface de usuário
 ■ Modelos de Análise e Projeto de Interfaces
 ■ Projeto de Dados
INTRODUÇÃO
Caro(a) aluno(a), na unidade anterior, foi introduzido o objetivo do nosso livro 
e as etapas que envolvem o processo de software e a forma com que se relacio-
nam entre si. Descrevemos as etapas que vamos ver: o Projeto, a implementação 
e o teste de software. 
Nesta unidade, convido você a dar continuidade ao estudo destas etapas que 
envolvem o processo de software, nos aprofundando mais na etapa de Projeto. 
Vamos, portanto, conhecer mais a fundo os conceitos que envolvem o Projeto 
e compreender a sua importância e com isso entender como ele pode minimi-
zar a distância entre o sistema e o mundo real. 
Você já parou para pensar como é importante a interface de qualquer sis-
tema, pois são desenvolvidos para serem manuseados por pessoas? Na fase de 
Projeto, definimos como vai ser esta interface com o usuário, como serão dis-
postos os menus, as janelas, os ícones e todos os componentes que irão fazer 
parte do sistema a ser desenvolvido e suas funcionalidades. Também fazem parte 
desta fase, como será o comportamento do sistema, como serão apresentadas 
as informações de relatórios, comprovantes e tudo que envolve a impressão de 
informações ao usuário.
Essa fase inicia após ter sido finalizado o levantamento de requisitos de sof-
tware junto ao cliente. No Projeto definimos como o software será construído, 
como será desenvolvida a sua arquitetura, a interface com o usuário, componentes 
que poderão ser utilizados e outras características que podem ser determinante 
para se gerar um sistema. Esta fase de Projeto possui como objetivo essencial 
mostrar e definir uma solução possível a ser implementada com base no que foi 
levantado na análise de requisitos. 
Também nesta unidade, serão apresentados os principais aspectos relati-
vos ao Projeto de software, algumas técnicas, modelos e tipos de projetos para 
que possamos chegar ao final das fases que envolvem um processo de software 
e com um sistema de qualidade.
Vamos a fase de Projetos! Boa leitura!
Introdução
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
45
©shutterstock
PROJETO DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E46
A FASE DE PROJETO DE SOFTWARE
Conforme Pressman (2011), Projeto é lugar onde a cria-
tividade está em alta, em que os requisitos do cliente e 
a sua necessidade de sistema se juntam para o desenvol-
vimento de um produto ou sistema. Ele afirma que o Projeto cria um 
modelo ou uma representação em que é definido o “como fazer”, for-
necendo todos os detalhes sobre a arquitetura, a estrutura, a interface e os 
componentes essenciais para implementar o sistema. 
Na fase de Projeto, o principal objetivo é definir uma estrutura que possa ser 
implementada baseada no que foi descrito nos requisitos que foram levantados 
para o sistema junto ao cliente. Você saberia disser qual a diferença entre a aná-
lise e o Projeto? Na análise de requisitos, é modelado o domínio do problema e 
no Projeto é modelada a solução para o problema, mas ambos devem estar em 
sintonia, alinhados em um único fluxo, pois o objetivo dos dois é a solução final 
do problema, neste caso, como software que será desenvolvido. 
Na fase de Projeto é decidido como o sistema irá se comportar, em termos 
de: software, hardware, infraestrutura de rede, a interface de usuário, formulá-
rios que devem ser preenchidos e os relatórios que o sistema irá fornecer; outros 
programas específicos que possa vir a usar, quais bancos de dados e arquivos 
que serão necessários.
Como vimos, na primeira unidade, quem realiza esta etapa é conhecido 
como o Arquiteto de Software, que possui experiência como programador e pos-
sui amplos conhecimentos sobre a Gerência de Projetos. Tal profissional deve 
compreender e dominar as tecnologias pertinentes, conhecer técnicas de mode-
lagem e metodologias de desenvolvimento, entender as estratégias de negócios 
da instituição onde atua, além de conhecer produtos, processos e estratégias de 
concorrentes.
A Fase de Projeto de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
47
Pressman (2011) afirma que o projeto é importante, pois ele permite que 
o sistema seja modelado ou o produto construído. Quando o sistema é mode-
lado, ele pode ser avaliado para verificar a qualidade e com isso ser aperfeiçoado 
antes de passar para a fase de implementação, ou de testes a serem realizado, 
ou ainda, que os usuários finais apontam os erros. Conforme o autor, o projeto 
de software pode mudar ao longo de seu desenvolvimento, à medida que novos 
métodos, uma melhor análise e entendimento do problema ou ainda, surja uma 
nova solicitação do cliente. 
O projeto é considerado o núcleo técnico da Engenharia de Software e, 
com isso ele pode ser aplicado em qualquer modelo de processo que seja ado-
tado pela empresa. Por ser iniciado após a análise de requisitos, o projeto é visto 
como a última atividade de modelagem, antes da geração do código, ou seja, ele 
deve ser bem modelado, para que a etapa de construção ocorra sem alterações 
(PRESMANN, 2011, p. 207). 
Na etapa de projeto, deve ser considerado como o sistema funcionará inter-
namente, para que os requisitos do cliente possam ser atendidos. Para isso, esta 
etapa também é dividida em fases, ou melhor, caracterizada por um conjunto 
de projetos, que ocorrem paralelamente. Conforme Sommerville (2011, p. 110), 
a fase de projeto deve ter:
 ■ Projeto da Arquitetura do Software: é a parte em que definimos os com-
ponentes estruturais e seus relacionamentos.
 ■ Projeto de Dados: projeto que tem como objetivo definir a estrutura de 
dados para implementar o software.
 ■ Projeto de Interfaces: nesta parte é descrito como será a comunicação den-
tro do sistema, com outros sistemas e com os usuários que iram utiliza-los. 
 ■ Projeto de Componentes: detalhamos os procedimentos dos componen-
tes estruturais da arquitetura do software. 
PROJETO DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E48
Figura 1 - Modelo Geral do Projeto de Software.
Projeto de 
arquitetura
Especi�cação 
de requisitos
Especi�caçãoabstrata
Projeto de 
interface
Atividades de projeto
Produtos de projeto
Projeto de 
componente
Projeto de 
estrutura de 
dados
Projeto de 
algoritmo
Arquitetura 
de sistema
Especi�cação 
de software
Especi�cação 
de interface
Especi�cação 
de estrutura 
de dados
Especi�cação 
de algoritmo
Especi�cação 
de componente
Fonte: Sommerville (2011).
Agora, aluno(a) vamos conhecer os importantes conceitos de projeto de software 
que envolve o desenvolvimento de sistemas. Ótima leitura. 
A importância do projeto de software pode ser definida em uma única pa-
lavra — qualidade. Projeto é a etapa em que a qualidade é incorporada na 
engenharia de software. O projeto nos fornece representações de software 
que podem ser avaliadas em termos de qualidade. Projeto é a única maneira 
em que podemos traduzir precisamente os requisitos dos interessados em 
um produto ou sistema de software finalizado. O projeto de software serve 
como base para todas as atividades de apoio e da engenharia de software 
que seguem. Sem um projeto, corremos o risco de construir um sistema ins-
tável — um sistema que falhará quando forem feitas pequenas alterações; 
um sistema que talvez seja difícil de ser testado; um sistema cuja qualida-
de não pode ser avaliada até uma fase avançada do processo de software, 
quando o tempo está se esgotando e muito dinheiro já foi gasto.
Fonte: Pressman (2011).
©shutterstock
Conceitos Básicos de Projeto de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
49
CONCEITOS BÁSICOS DE PROJETO DE SOFTWARE
Conhecer os conceitos básicos e fundamentais do projeto de software é essencial, 
para passar ao arquiteto de software uma base para ele saber qual o método 
de projeto pode ser aplicado no sistema. Nessa fase é importante que os 
conceitos sejam assimilados e entendidos, para que se possa projetar 
um projeto de software com características desejáveis. 
Conforme Pressman (2011, p. 212), os principais con-
ceitos relacionados ao projeto de software são: 
Abstração: o projeto deve considerar uma solução para 
qualquer problema com vários níveis de abstração, come-
çando com um nível de abstração mais alto (solução mais 
abrangente) e depois para níveis de abstração mais baixos (solução 
mais detalhada). E que os elementos de projeto sejam representados 
por suas características essenciais, e os detalhes desnecessários sejam 
descartados.
Refinamento: processo de elaboração definida em alto nível de abstração e depois 
vai descendo a níveis de abstração mais baixos. Abstração e refinamento se comple-
mentam, pois a abstração especifica os níveis mais altos e mais baixos e o refinamento 
ajuda a revelar os detalhes menores, conforme o projeto vai evoluindo. 
Modularidade: o projeto é dividido em módulos/componentes que são inte-
grados para corresponder aos requisitos levantados. Possui algumas vantagens 
como a facilidade de entendimento, pois cada módulo pode ser estudado sepa-
radamente e com isso facilitar o desenvolvimento, uma vez que cada módulo 
pode ser projetado, implementado e testado separadamente, diminuindo os erros 
e facilitando a manutenção. 
O projeto de software sempre deve começar levando em consideração os 
dados — a base para todos os demais elementos do projeto. 
(Pressman). 
PROJETO DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E50
Padrões: fornece uma descrição ao arquiteto de software permitindo deter-
minar qual o padrão a ser aplicado e quais podem ser reutilizados no sistema. 
Arquitetura: estrutura ou organização dos módulos/componentes do programa 
e como eles interagem. O conceito de arquitetura está amplamente ligado aos aspec-
tos da estrutura hierárquica dos módulos e as estruturas de dados de um software. 
Hierarquia de Controle: é a representação da estrutura do software rela-
cionando aos componentes. Aqui o objetivo não é apresentar os detalhes dos 
procedimentos e sim de estabelecer os relacionamentos entre os componentes 
de software, seus níveis de abstração e refinamentos.
Encapsulamento: define e impõe restrições de acesso tanto a detalhes pro-
cedurais em um módulo quanto em qualquer estrutura de dados local usada 
pelo módulo. A interface que foi definida deve revelar o mínimo da sua estru-
tura interna e com isso reduzir os efeitos colaterais que possam vir a ocorrer.
Estrutura de Dados: representam os relacionamentos lógicos, como estão 
organizados os métodos de acesso, as associações e as alternativas de processa-
mento de informações, pois, à medida que o Projeto vai se aproximando da fase 
de Implementação, as representações vão se tornando cada vez mais importan-
tes, já que as estruturas de dados exercem um grande impacto no projeto final. 
Procedimentos de Software: expressam os detalhes da operação de cada 
módulo/componente do software individualmente. Estes detalhes são: como 
a informação é processada, pontos de decisão, quais as sequências de evento, e 
que operações serão repetitivas. 
Ocultação de Informação: seu objetivo é propor uma maneira de decom-
por o problema, assim, obter módulos menores do software no desenvolvimento. 
Com isso, o Arquiteto de Software ganha um alto grau de independência entre 
os módulos, facilitando a sua modificação, quando necessário, e em consequ-
ência, a fase de testes. 
Conceitos Básicos de Projeto de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
51
No próximo tópico vamos conhecer a qualidade do Projeto de software e 
entender porque a qualidade é tão importante e porque começamos a introdu-
zi-la nessa fase. Boa leitura. 
Um conjunto de conceitos fundamentais de projeto de software evoluiu ao 
longo da história da engenharia de software. Embora o grau de interesse em 
cada conceito tenha variado ao longo dos anos, cada um resistiu ao tempo. 
Esses conceitos fornecem ao projetista de software uma base a partir de 
qual métodos de projeto mais sofisticados podem ser aplicados. Ajudam-
-nos a responder as seguintes questões:
• Quais critérios podem ser usados para particionar o software em compo-
nentes individuais?
• Como os detalhes de função ou estrutura de dados são separados de uma 
representação conceitual do software?
• Quais critérios uniformes definem a qualidade técnica de um projeto de 
software?
Os conceitos fundamentais de projeto de software fornecem a organização 
necessária para estruturá-la e para “fazer com que ele funcione corretamen-
te”.
Fonte: Pressman (2011).
Existe uma tendência de ir imediatamente até o último detalhe, pulando as 
etapas de refinamento. Isso induz a erros e omissões e torna o projeto muito 
mais difícil de ser revisado. Realize o refinamento gradual.
(Pressman).
©shutterstock
PROJETO DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E52
QUALIDADE DO PROJETO
Você deve estar se perguntando por que o 
Projeto de Software é considerado uma das 
fases mais importantes do desenvolvimento 
de um software? Ele é considerado impor-
tante, porque é nele que iniciamos a etapa 
de qualidade e ele serve como base para as 
outras fases do processo. 
Segundo Pressman (2011, p 358), a qualidade de software pode ser dividida 
em duas partes: Qualidade do Processo e Qualidade do Produto. Quando nos 
referimos à qualidade do produto, o foco maior está na qualidade dada ao pro-
duto final, que é feita por meio de avaliações no software acabado. Já a qualidade 
do processo do software concentra-se no modo como o software foi produzido 
ao longo do seu desenvolvimento e como é feita a sua manutenção. 
Segundo Weber et al. (2001), a qualidade de software é determinada pela 
qualidade dos processos que são usados durante a fase de desenvolvimento do 
software. Para Rezende (2005), apreocupação com a qualidade deve estar vol-
tada para a melhoria do Processo que envolve o desenvolvimento do software. 
Se garantirmos, pois, a Qualidade do Processo, podemos também garantir a 
Qualidade do Software. 
Segundo Gimenes (1994), o processo de software pode ser definido como um 
conjunto de todas as atividades relacionadas ao desenvolvimento, controle, vali-
dação e manutenção de um software. Segundo Sommerville (2011), o resultado 
do processo é um produto que mostra a forma como o processo de desenvolvi-
mento foi conduzido e ele define o processo de software como sendo um conjunto 
de atividades e resultados associados que produzem um produto de software. 
O termo Qualidade possui várias definições as quais variam de acordo com 
a abordagem utilizada. A seguir uma que é bastante utilizada na literatura: 
“Conformidade com as especificações” (CROSBY, 1990): Crosby sugere que 
o gerenciamento da qualidade deve ser feito desde o início do desenvolvimento, 
para tentar evitar defeitos e diminuir o retrabalho. No desenvolvimento de sof-
tware, este conceito significa que devemos nos preocupar com a qualidade desde 
Qualidade do Projeto
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
53
o início do processo (levantamento de requisitos e a parte de modelagem), para 
reduzir os problemas nas fases finais (codificação e testes). 
Falamos muito em qualidade, mas o que é um software com qualidade? Como 
avaliamos a qualidade de um projeto? Conforme Pressman (2011, p. 209), para 
que o nosso Projeto obtenha qualidade, ele sugere características que nos aju-
dam na avaliação de um bom Projeto:
 ■ O projeto deve implementar todas as especificações definidas nos requisitos. 
 ■ O projeto deve ser um guia legível para as próximas etapas do processo 
de software (implementação e teste).
 ■ O projeto deve fornecer uma visão geral do software, como dados, pos-
síveis funções e como ele deve se comportar.
Essas características ajudam na avaliação e na obtenção de um projeto com quali-
dade. Mas o que é Qualidade de Projeto? Para Pressman (2011, p. 359), “refere-se 
às características que os projetistas especificam para um produto. A qualidade 
dos materiais, as tolerâncias e as especificações de desempenho, todos são fato-
res que contribuem para a qualidade de um projeto. Quanto mais materiais de 
alta qualidade forem usados, tolerâncias mais rígidas e níveis de desempenho 
maiores forem especificados, a qualidade de projeto de um produto aumentará 
se o produto for fabricado de acordo com essas especificações”.
Quando se desenvolve um software, a qualidade de um projeto reúne tudo 
o que foi especificado no modelo de requisitos, suas funções e suas caracterís-
ticas e se o sistema resultante atende às necessidades e às metas especificadas. 
Nos próximos tópicos você vai conhecer os modelos de projeto, como se divi-
dem e como funcionam. Continue a sua leitura!
“O clamor por maior qualidade de software começou realmente quando o 
software passou a se tornar cada vez mais integrado em todas as atividades 
de nossas vidas.” 
(Pressman).
©shutterstock
PROJETO DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E54
MODELO DO PROJETO
Conforme Pressman (2011, p. 221), o Modelo de Projeto pos-
sui quatro elementos que são considerados os principais 
e mais importantes: arquitetura, dados, interfaces e 
componentes. Esse modelo pode ser dividido em 
duas dimensões: processo e abstração.
A dimensão de processo vai mostrando uma 
evolução do projeto conforme as tarefas vão sendo 
executadas, e a dimensão de abstração, mostra o 
nível de detalhamento de cada elemento do modelo 
de análise e que vão sendo transformados e refinados no 
modelo de projeto, conforme ilustrado na figura 2:
PREMISSAS DA QUALIDADE 
Fazer acontecer: Qualidade requer comprometimento, particularmente 
vindo do topo do gerenciamento. Cooperação entre a equipe e o gerente 
deve ser fundamental para ”fazer acontecer”. 
Zero-defeito: Muitas pessoas acreditam que existe o “zero-defeito” para 
serviços e produtos. Isso é irreal. O sensato é definir níveis aceitáveis de de-
feitos. 
Qualidade = alto custo: Qualidade é frequentemente associada a custo, 
significado de alta qualidade = alto custo. Falso. Isso causa uma confusão 
entre a qualidade do projeto e a qualidade de conformidade. ”Não posso 
testar o produto por que não tenho infraestrutura, e a infra-estrutura não 
permite o teste do produto. O que fazer?”. Qualidade demanda especifica-
ção de requerimento e suficiente detalhamento deles. 
Padrões inibem a criatividade: O pessoal ”técnico” acredita, em geral, que 
padrões inibem sua criatividade, e com isso padrões não são seguidos, en-
tretanto, para a qualidade acontecer, padrões e procedimentos deve ser se-
guido.
Fonte: Costa (2010).
Projeto da Arquitetura do Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
55
Figura 2- Dimensões do Modelo de Projeto
Diagramas de classes
Pacotes de análise
Modelos CRC
Diagramas de colaboração
Diagramas de �uxo de dados
Diagramas de �uxo de controle
Narrativas de processamento
Casos de uso - texto
Diagramas de casos de uso
Diagramas de atividade
Diagramas de raias
Diagramas de colaboração
Diagramas de estados
Diagramas de sequência
Projeto técnico da interface
Projeto de navegação
Projeto da interface grá�ca do 
usuário
Diagramas de classes
Pacotes de análise
Modelos CRC
Diagramas de colaboração
Diagramas de �uxo de dados
Diagramas de �uxo de controle
Narrativas de processamento
Diagramas de estados
Diagramas de sequência
Diagramas de componentes
Classes de projeto
Diagramas de atividade
Diagramas de sequência
Realização das classes de 
projeto
Subsistemas
Diagrama de colaboração
Re�namentos para:
Realizações das classes de 
projetos
Subsistemas
Diagramas de colaboração
Elementros da 
arquitetura
Elementros da 
interface
Elementros de 
componentes
Elementros de 
implantação
Re�namentos para:
Diagramas de componentes
Classes de projetos
Diagramas de atividades
Diagramas de sequência
Requisitos:
Restrições
Interoperabilidade
Metas e con�gurações
Realizações das classes de 
projeto
Subsistemas
Diagramas de colaboração
Diagramas de componentes
Classes de projeto
Diagramas de atividade
Diagramas de sequência
Diagramas de implantação
Modelo de análise
Dimensão de Processo
Alto
Baixo
Modelo de projeto
Fonte: Pressman (2011, p. 221).
Agora, vamos conhecer um pouco de alguns desses elementos que fazem parte 
do Modelo de Projeto. Aproveite(m) ao máximo cada informação sobre esses 
projetos. Boa leitura.
PROJETO DA ARQUITETURA DO SOFTWARE
Conforme Pressman (2011, p. 229), o “projeto de arquitetura representa a estru-
tura de dados e os componentes de programa necessários para construir um 
sistema computacional”. Quem realiza essa atividade é o arquiteto de sistemas, 
ele escolhe os estilos de arquitetura com base na análise de requisitos. 
Você deve estar ser perguntando, porque é importante fazer um projeto de 
arquitetura? Já pensou em construir uma casa sem uma planta dela? Você sabe-
ria por onde começar? Mas ao ver a planta de uma casa, você saberia, pois ela 
mostra a casa de um contexto geral, mais ampla, e com isso você pode imaginar 
PROJETO DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E56
como ela será. O projeto de arquitetura é isso, ele dá uma visão geral do sistema 
e lhe mostra se você entendeu o contexto do sistema e o que é para desenvolver, 
ou seja, você pode imaginar como ele será. 
O projeto arquitetural antecede a etapa de construção do software, ele deter-
mina as partes da implementação e como estas devem interagir e se relacionar. 
A arquitetura garante a unidade e a consistência entreas partes e a sua repre-
sentação serve como guia para o projeto da implementação, teste e implantação 
do sistema. 
A arquitetura de software serve para modelar a estrutura de um sistema, 
por meio de dados e componentes que se relacionam entre si. Pressman (2011, 
p. 230) define que quando se considera a arquitetura, por exemplo, de um edifí-
cio, pensamos em vários atributos diferentes, desses os mais simples até os mais 
complexos. Mas a arquitetura envolve mais que isso, são vários componentes inte-
grados para formar um todo, que satisfaça as necessidades expressas do cliente. 
A arquitetura é constituída por decisões, algumas grandes e outras pequenas, e a 
maioria precisa ser tomada no início do Projeto e podem ter impacto em outras 
fases do projeto que estão por vir. 
Conforme Sommerville (2011, p. 106), a arquitetura de software pode tra-
balhar com dois níveis de abstração que são:
1. Arquitetura em pequena escala em que a preocupação é com a maneira 
como um programa individual é decomposto em componentes.
2. Arquitetura em grande escala em que a preocupação é com a arquitetura 
de sistemas distribuídos complexos que incluem outros sistemas, progra-
mas e componentes. 
Projeto da Arquitetura do Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
57
VISÕES DE ARQUITETURA 
A arquitetura de software pode ser representada por visões de arquitetura, em 
que cada visão aborda um determinado conjunto de questões específicas dos que 
estão envolvidos no processo de desenvolvimento do sistema, como os usuários 
finais, os designers do projeto, gerentes de projeto, engenheiros de sistema etc. 
As visões de arquitetura são usadas para a tomada das principais decisões de 
design estrutural, pois mostram como a arquitetura de software é decomposta 
em componentes. Conforme Pressman (2011, p. 232) “cada visão desenvol-
vida como parte da descrição arquitetural trata uma necessidade específica do 
interessado”. Assim, as decisões que foram tomadas, podem mostrar uma visão 
sobre a estrutura do sistema e como ele foi adequado às necessidades dos inte-
ressados. Sommerville (2011, p. 109) define as principais visões de arquitetura: 
Cada um de nós possui uma imagem mental daquilo que a palavra arqui-
tetura significa. A implicação é que os diferentes interessados verão uma 
arquitetura sob diversos pontos de vista orientados por conjuntos de in-
teresses distintos. Isso implica que uma descrição de arquitetura é, na ver-
dade, um conjunto de artefatos que refletem diferentes visões do sistema. 
Por exemplo, o arquiteto de um importante conjunto comercial tem de tra-
balhar com uma série de interessados diferentes. O principal interesse do 
proprietário do conjunto comercial (um dos interessados) é garantir que ele 
seja esteticamente agradável e que forneça espaço e infraestrutura suficien-
tes para garantir sua lucratividade. Consequentemente, o arquiteto tem de 
criar uma descrição usando visões de edifício que atendam os interesses do 
proprietário. A descrição de arquitetura de um sistema baseado em softwa-
re deve apresentar características análogas àquelas citadas para o conjunto 
comercial.
Fonte: Pressman (2011).
PROJETO DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E58
 ■ Visão de Casos de Uso: mostra os casos de uso e cenários que abrangem 
comportamentos significativos em termos de arquitetura, classes ou ris-
cos técnicos. É um subconjunto do modelo de casos de uso.
 ■ Visão Lógica: mostra as classes de design mais importantes e sua organiza-
ção em pacotes e subsistemas, e a organização desses pacotes e subsistemas 
em camadas. É um subconjunto do modelo de design.
 ■ Visão de Implementação: mostra uma visão geral do modelo de imple-
mentação e sua organização em termos de módulos em pacotes e camadas. 
É um subconjunto do modelo de implementação.
Além dessas visões, você pode incluir outras adicionais como: visão da interface 
do usuário, visão de segurança, visão de dados, e assim por diante. Para docu-
mentar estas visões de arquitetura, você pode usar o documento de arquitetura 
de software. O documento de arquitetura de software é usado para fornecer uma 
visão geral de arquitetura do sistema, podendo usar diversas visões de arquite-
tura para descrever diferentes aspectos do sistema. No próximo tópico vamos 
conhecer os padrões de arquitetura que são mais usados. Boa leitura!
Os modelos de arquitetura de um sistema de software podem ser usados 
para focar a discussão sobre os requisitos de software ou de projeto. Como 
alternativa, podem ser usados para documentar um projeto para que este 
possa ser usado como base para um projeto e uma implementação mais 
detalhados e para a futura evolução do sistema. É impossível representar 
todas as informações relevantes sobre a arquitetura de um sistema em um 
único modelo de arquitetura, pois cada modelo mostra apenas uma visão 
ou perspectiva do sistema. Pode mostrar como um sistema é decomposto 
em módulos, como os processos de run-time interagem, ou as diferentes 
formas como são distribuídos os componentes do sistema através de uma 
rede. Tudo isso é útil em momentos diferentes. Portanto, para ambos, proje-
to e documentação, geralmente você precisa apresentar múltiplas visões da 
arquitetura de software. 
Fonte: Sommerville (2011). 
©shutterstock
Projeto da Arquitetura do Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
59
PADRÕES DE ARQUITETURA DO SOFTWARE
Coloque em foco a representação de arquitetura que irão orientar todos 
os demais aspectos do projeto. Procure investir o tempo neces-
sário para revisar cuidadosamente as documentações 
de arquitetura. Nesta fase, um erro poderá gerar um 
grande impacto negativo nas próximas fases do 
desenvolvimento do sistema. 
Quando descrevemos a arquitetura de um sof-
tware precisamos apresentar as características 
desejadas pelo cliente . Com isso, os desenvolve-
dores querem uma orientação clara e precisa sobre 
o projeto, e os clientes querem garantias de que esta arquitetura atenderá suas 
necessidades de negócios.
 Para Sommerville (2011, p. 108) cada sistema é único, quando o domínio da 
aplicação é o mesmo, frequentemente possuem arquiteturas semelhantes, pois 
refletem os conceitos principais. Assim, é interessante ao projetar uma arquite-
tura de sistema, decidir se o seu sistema vai ser uma aplicação com classes mais 
gerais e verificar o que tem em comum, e quais dessas você pode reusar. 
Mas você deve estar se perguntando: porque seria interessante reusar? A 
reutilização é um aspecto fundamental para o desenvolvimento de um sistema, 
principalmente na fase de projeto. Muitos sistemas que já foram desenvolvidos 
e estão em uso, são similares a sistema que estão sendo desenvolvidos e muita 
das informações já usadas podem ser reutilizadas para solucionar problemas 
recorrentes no projeto. 
“A arquitetura de software deve modelar a estrutura de um sistema, bem 
como a maneira por meio da qual dados e componentes procedurais cola-
boram entre si.”
(Pressman).
PROJETO DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E60
A arquitetura de um software pode se basear em padrões ou estilos de arquite-
tura. Conforme Sommerville, (2011, p. 108) “os padrões de arquitetura capturam 
a essência de uma arquitetura que tem sido usada em diferentes sistemas de sof-
tware”. Assim, ao definir uma arquitetura de um sistema, você deve analisar os 
padrões mais comuns, quais os seus pontos fortes e fracos e como eles podem 
ser usados, pois um padrão é uma solução que já foi testada e aprovada para um 
problema em comum.
Pressman (2011, p. 235) define que o padrão de arquitetura ou estilo impõe 
muita transformação aum projeto de arquitetura de um sistema. Por sua vez, 
Sommerville (2011, p. 108) afirma que “a ideia de padrões como uma forma de 
apresentar, compartilhar e reusar o conhecimento sobre sistemas de software é 
hoje amplamente usada”. Contudo vamos pensar em um padrão de arquitetura 
somente em sistemas bem-sucedidos de sistemas desenvolvidos anteriormente. 
Afinal o que é um padrão? Um padrão é usado para descrever um problema 
que ocorreram repetidas vezes, e é usada uma solução para esse problema de 
forma que possamos reutilizar esta solução encontrada. Em outras palavras, 
eles são soluções para problemas que alguém algum dia teve, achou a solução 
aplicando um modelo que foi documentado e que agora você pode usar inte-
gralmente ou de acordo com a sua necessidade. 
O padrão mostra uma solução de arquitetura que ajuda a servir como base 
para o projeto da arquitetura. Conforme Sommerville (2011, p. 108) devemos 
pensar em padrão de arquitetura como uma descrição abstrata, que seja estili-
zada, com boas práticas experimentadas e que tenham sido testadas em diferentes 
sistemas e ambientes e, com isso, incluir informações de uso desse padrão, para 
saber se ele é adequado e quais os seus pontos fortes e fracos. 
A escolha do padrão arquitetural a ser usado deve estar associado ao tipo 
de sistema e seus requisitos não funcionais. Para ajudar na escolha podemos 
pensar em algumas perguntas: O sistema a ser desenvolvido é interativo? Ele 
vai possui muitas variações? Quais os requisitos não funcionais que podemos 
considerar importantes? E quanto a sua confiabilidade? E a sua adaptabilidade? 
Quando respondemos a estas perguntas, podemos perceber que na composi-
ção de padrões, temos padrões diferentes que levam o projeto a consequências 
diferentes, mesmo quando os padrões abordam problemas semelhantes que são 
Projeto da Arquitetura do Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
61
encontrados e em alguns padrões de projeto, sistemas complexos podem vir a 
possuir mais de um padrão arquitetural. 
Nos próximos tópicos, vamos conhecer brevemente alguns padrões comu-
mente que são usados em diferentes tipos de sistemas. Entre os padrões de 
arquitetura comumente usados estão: modelo-visão-controlador, arquitetura 
em camadas, repositório, cliente-servidor e duto e filtro. 
Vamos aos padrões de arquitetura mais conhecidos:
MVC (Modelo-Visão-Controlador): esse padrão é considerado a base do 
gerenciamento de interações para muitos dos sistemas que são baseados em Web. 
Na descrição deste padrão você pode incluir o nome do padrão, uma descrição 
breve, podendo ser um modelo gráfico associado, exemplos de tipos de sistema 
em que este padrão pode ser usado novamente, suas vantagens e desvantagens.
Arquitetura em Camadas: este padrão de arquitetura é organizado em 
camadas separadas e em cada camada só depende dos recursos e serviços ofere-
cidos pela camada que se encontra imediatamente abaixo dela. Esta arquitetura 
é considerada mutável e portável, pois enquanto ela não for alterada, a camada 
pode ser substituída por outra equivalente. Mas quando ela muda ou tem novos 
recursos adicionados, apenas a camada adjacente é afetada.
Arquitetura de Repositório: esse padrão de arquitetura descreve como 
um conjunto de componentes que estão interagindo podem compartilhar seus 
dados. Normalmente, os sistemas organizam os seus dados em torno de um 
banco de dados ou repositório compartilhado. Assim, este padrão é adequado 
para as aplicações nas quais os dados são gerados por um componente e usa-
dos por outro. Um exemplo, um ambiente controlado por versões, que mantém 
o controle de todas as alterações do sistema e permite que seja feita a reversão 
para versões anteriores. 
Arquitetura Cliente-Servidor: esse padrão de arquitetura é organizado em 
um conjunto de serviços e servidores associados e clientes que acessam e usam 
os serviços. Normalmente este padrão é utilizado em arquiteturas de sistemas 
distribuídos.
Arquitetura de Duto e filtro: esse padrão de arquitetura é um modelo de 
organização em tempo de execução de um sistema, com entradas e saídas de 
informações. Conforme Sommerville (2011, p. 114) “os dados fluem de um para 
PROJETO DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E62
o outro e transformam-se enquanto se movem por meio da sequência”. Assim, 
cada etapa desta transformação, é implementada como uma transformação. 
Caro(a)Aluno(a) foram apresentados alguns dos padrões de arquitetura e 
descritos brevemente alguns que são comumente usados, mas existem outros. 
Para obterem mais informações sobre os padrões de arquitetura recomendo que 
leiam o Saiba Mais. Boa leitura!
Depois do aprofundamento no Saiba Mais, vamos para o próximo tópico 
onde vamos conhecer o Projeto de componentes e seus conceitos. Bons estudos!
Um padrão de arquitetura, assim como um estilo arquitetural, impõe trans-
formação no projeto de arquitetura. Entretanto, padrão difere de estilo em 
alguns modos fundamentais: (1) o escopo de um padrão é menos abran-
gente, concentrando-se em um aspecto da arquitetura e não na arquitetu-
ra em sua totalidade; (2) um padrão impõe uma regra sobre a arquitetura, 
descrevendo como o software irá tratar algum aspecto de sua funcionali-
dade em termos de infraestrutura os padrões de arquitetura tendem a tra-
tar questões comportamentais específicas no contexto da arquitetura (por 
exemplo, como as aplicações em tempo real tratam a sincronização ou as 
interrupções). Os padrões podem ser usados com um estilo de arquitetura 
para dar forma à estrutura global de um sistema. Um estilo arquitetural é 
uma transformação imposta no projeto do sistema inteiro. O objetivo é es-
tabelecer uma estrutura para todos os componentes do sistema. 
Fonte: Pressman (2011).
Como projetista, trabalhe arduamente para derivar tanto as abstrações pro-
cedurais quanto a de dados que atendam ao problema em questão. Se elas 
puderem atender um domínio inteiro dos problemas, tanto melhor.
(Pressman).
©shutterstock
Projeto de Componentes
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
63
PROJETO DE COMPONENTES
Conforme Pressman (2011, p. 257) “o projeto de componentes ocorre depois 
da primeira iteração do projeto de arquitetura tiver sido completa”. Para ele, o 
conjunto completo de componentes de software é definido durante o projeto de 
arquitetura. O projeto de componentes procura detalhar as estruturas de dados, 
definir os algoritmos, as características da interface que serão usadas, os meca-
nismos de comunicação que serão alocados para cada um dos componentes do 
software. 
Quem realiza as atividades do projeto de componentes é o Engenheiro de 
Software. Você deve estar se perguntando: Qual a importância do projeto de 
componentes no desenvolvimento do software? Bem, nesta fase, ao analisar o 
projeto até aqui você já deve ser capaz de determinar se o software irá funcionar 
ou não, antes que ele seja implementado. Certo? Pois o projeto de componen-
tes é usado para representar o software de uma forma que possamos “revisar” 
os detalhes, como as estruturas de dados definidas, as interfaces e se os algorit-
mos irão funcionar. 
A base do projeto de componentes é formada pelas representações de projeto 
de dados, de arquitetura e de interface. Uma dica interessante, é que normal-
mente é possível fazer uso de componentes de software reutilizáveis, ao invés 
PROJETO DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E64
de implementar novos. O principal artefato utilizado durante o projeto de com-
ponentes são que cada componente, pode ser representado em notação gráfica, 
tabular ou baseado em texto. 
Para Pressman (2011,p. 258) não importa o tipo de mecanismo que será 
utilizado para representar o projeto de componentes, as estruturas de dados, 
as interfaces e os algoritmos definidos, pois eles devem atender a uma série de 
metas de projeto bem fundamentadas que vão auxiliam a evitar erros à medida 
que o projeto evolui. 
Mas o que é um componente de software? Conforme Gimenes e Huzita (2005) 
é uma unidade de software independente que encapsula, seu projeto e a imple-
mentação, oferecendo serviços, por meio de interfaces definidas, que serão usadas 
para o meio externo. Pressman (2011) define que um componente é um bloco 
construtivo modular para ser usado em software de computador e com relação 
à orientação a objetos, um componente é um conjunto de classes colaborativas. 
Um componente é considerado uma unidade independente que pode ser 
utilizado junto com outros componentes, formando um sistema mais complexo. 
No entanto o significado de componente vai depender do ponto de vista do res-
ponsável pelo projeto de componentes, o engenheiro de software. Mas qual seria 
este ponto de vista? Conforme Pressman (2011) temos três pontos de vistas que 
são utilizados. São eles:
Visão Orientada a objetos: um componente é um conjunto de classes cola-
borativas ou podem ter um componente com uma única classe.
Visão Tradicional: para essa visão, um componente é o elemento funcio-
nal de um programa que incorpora a lógica de processamento, as estruturas de 
dados e uma interface que habilita o componente para que os dados sejam for-
necidos a ele.
Visão relacionada com processos: um componente é utilizado a partir da 
reusabilidade, ou seja, que façamos o uso de componentes de software ou de 
padrões de projeto já existentes.
Projeto de Componentes
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
65
PROJETO DE COMPONENTES BASEADOS EM CLASSES
Conforme Pressman (2011, p. 262) “o projeto de componentes apoia-se nas 
informações desenvolvidas como parte do modelo de requisitos e representa-
das como parte do modelo de arquitetura”. Assim, quando se desenvolve um 
projeto orientado a objetos, o projeto de componentes define a elaboração de 
classes específicas contidas no modelo de requisitos. Na atividade de constru-
ção do projeto, a descrição detalhada de atributos, operações e interfaces é um 
dos detalhes mais importantes.
Para Pressman (2011, p. 262) temos alguns princípios básicos de projeto que 
são utilizados pelo projeto de componentes. São eles:
 ■ Princípios do aberto-fechado (OCP): um componente deve permitir 
que ele seja estendido sem a necessidade de modificações internas no 
próprio componente.
 ■ Princípio da substituição (LSP): este princípio exige que qualquer classe 
derivada de uma classe-base honre o contrato entre a classe-base e os 
componentes que a usam. 
 ■ Princípio da inversão de dependência (DIP): este princípio define que 
quanto mais um componente depender de outros componentes concre-
tos, mais difícil será de estendê-lo depois.
 ■ Princípio da segregação de interfaces (ISP): este princípio sugere que se 
crie uma interface específica para cada categoria de clientes.
 ■ Princípio da equivalência de reuso de versões (REP): esse princípio 
sugere que quando se usa classes ou componentes tendo usado o reuso, 
existe um contrato estabelecido entre o desenvolvedor da entidade reu-
tilizável e quem irá fazer uso dela.
 ■ Princípio do fechamento comum (CCP): esse princípio sugere que as 
classes que são alteradas juntas, devem permanecer juntas.
 ■ Princípio comum da reutilização (CRP): esse princípio sugere que as clas-
ses que não são reutilizadas juntas não devem ser incluídas em um pacote. 
PROJETO DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E66
CONDUÇÃO DE PROJETO DE COMPONENTES
As etapas que veremos a seguir representam um conjunto de tarefas para um 
projeto de componentes orientado a objetos.
Etapa 1 → Identificar todas as classes de projeto correspondentes ao domí-
nio do problema.
Etapa 2 → Identificar todas as classes de projeto correspondentes ao domí-
nio de infraestrutura.
Etapa 3 → Elaborar todas as classes de projeto que não são obtidas como 
componentes reutilizáveis. Devemos especificar detalhes de mensagens e 
componentes que colaboram entre si, interfaces para cada componente, atri-
butos e tipos de dados e o fluxo de processamento contido em cada operação. 
Etapa 4 → Descrever fontes de dados persistentes (bancos de dados e arqui-
vos) e identificar as classes necessárias para gerenciá-los.
Etapa 5 → Desenvolver e elaborar representações comportamentais para uma 
classe ou componente.
Etapa 6 → Elaborar diagramas de implantação para fornecer detalhes de 
implementação adicionais.
Etapa 7 → Refatorar toda representação de projetos de componentes e sem-
pre considerar alternativas.
Conforme Pressman (2011, p. 274), “não se deve ter uma visão restrita. Sempre há 
soluções alternativas de projeto, e os melhores projetistas consideram (ou quase 
todas) elas antes de se decidirem pelo modelo de projeto final”. Assim, procure 
desenvolver alternativas e analise cuidadosamente cada uma delas, usando os 
princípios e as etapas para o desenvolvimento do seu projeto. 
No próximo tópico conheceremos o Projeto de Interface do usuário e seus 
conceitos. Boa leitura!
Vamos seguir em frente? 
Projeto de Interface do Usuário
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
67
Projetar componentes para reutilização requer mais que um bom projeto 
técnico. Essa atividade também requer mecanismos de controle de configu-
ração efetivos.
(Pressman).
O projeto de componentes ocorre depois da primeira iteração do projeto de 
arquitetura tiver sido completa. Neste estágio, a estrutura geral dos dados e 
programas do software já foi estabelecida. O intuito é traduzir o modelo de 
projeto em software operacional. Porém, o nível de abstração do modelo de 
projetos existente é relativamente alto e o nível de abstração do programa 
operacional é baixo. A tradução pode ser desafiadora, é uma porta aberta 
para a introdução de erros sutis difíceis de detectar e corrigir em estágios 
posteriores do processo de software. Os componentes preenchem a arqui-
tetura de software e, como consequência, desempenham um papel para al-
cançar os objetivos e requisitos do sistema a ser construído. Pelo fato de os 
componentes residirem na arquitetura de software, devem se comunicar e 
colaborar com outros componentes e entidades (por exemplo, outros siste-
mas, dispositivos, pessoas) existentes fora dos limites do software.
Fonte: Pressman (2011).
©shutterstock
PROJETO DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E68
PROJETO DE INTERFACE DO USUÁRIO
O projeto de interfaces é usado para descrever como um software se comunica 
com outros sistemas e como as pessoas o utilizam. Conforme Pressman (2011, 
p. 287) “o projeto de interface do usuário cria um meio de comunicação efetiva 
entre o ser humano e o computador”. Quem realiza o projeto de interface com 
o usuário é o Engenheiro de Software. 
Mas porque ele é importante? Imagine um software que seja difícil de ser 
utilizado, com erros aparecendo a todo o momento, lento e Você não vai gos-
tar certo? Independente de ele ser complexo e possuir um poder computacional 
grande. Por isso o projeto de interface do usuário precisa ser de fácil percepção 
e correto, sem erros que possam deixar o usuário inseguro. 
O projeto de interface deve iniciar pela identificação do usuário, das tarefas 
e do ambiente que são informações levantadas na análise de requisitos. Devemos 
nos perguntar: quem é o usuário? Como ele aprende a interagir com um novo 
sistema? Como ele interpreta uma informação produzida pelosistema? O que 
ele espera do sistema? A partir dessas informações, os cenários são criados e pas-
sam a ser analisados para definir como serão os objetos e as ações que a interface 
irá desempenhar. Portanto, é muito importante que você conheça os usuários 
e as suas tarefas.
Projeto de Interface do Usuário
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
69
Os cenários tem papel fundamental no projeto de interface do usuário, pois 
eles são a base para a criação do layout da tela que irá representar graficamente 
o projeto, como ícones a serem utilizados, botões, textos descritivos, títulos de 
janelas e menus. Os artefatos usados nesta fase são: a criação dos cenários de 
usuários, são gerados layouts de tela e desenvolvidos protótipos de interface de 
forma interativa. Os mecanismos que são utilizados para as interações são cha-
mados de interface gráfica do usuário (graphical user interface – GUI). Pressman 
cita as regras de ouro que foram publicadas sobre projeto de interfaces de Theo 
Mandel (apud Pressman 2011, p. 288), em que:
1. O usuário deve estar no comando.
2. Procure reduzir a carga de memória do usuário.
3. Procure tornar a interface do sistema mais consistente. 
Para o autor, as regras descritas acima são a base que formam o conjunto de 
princípios que devem ser usados para orientar o projeto de interface de usuá-
rio durante o desenvolvimento do sistema na fase de projeto do software. Agora 
vamos entender um pouquinho cada uma dessas regras de ouro:
Deixar o usuário no comando: procure escutar o que o cliente deseja como 
ele quer que o sistema reaja as suas necessidades e concretize as suas tarefas. 
Pense que o cliente quer controlar o sistema.
Reduzir a carga de memória do usuário: procure criar uma interface ao 
usuário bem desenhada e que não cause esgotamento à memória do usuário, pois 
quanto mais o usuário lembrar, mas sujeito a erros será a interação com o sistema. 
Tornar a interface consistente: procure apresentar uma interface com infor-
mações de forma consistente, como: informações visuais organizadas de acordo 
com regras de projeto, mecanismos de entrada restritos, mecanismos de nave-
gação bem definidos e padronizados, entre outros.
Normalmente, os usuários julgam um sistema pela sua interface ao invés 
de suas funcionalidades e um projeto de interface pobre é uma das razões que 
podem levam muitos sistemas de software a nunca serem utilizados.
Perceberam como é importante a interface do sistema com o usuário? É a 
parte fundamental de um software, pois ela fica visível para o usuário e com ela, 
PROJETO DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E70
se comunica para realizar suas tarefas. Muitos de vocês, usuários de computa-
dor já encontraram muitas interfaces difíceis de usar, de entender e assimilar? 
No entanto em muitas situações, fomos obrigados a usá-las porque não temos 
outras opções. Por isso, quando for planejar uma interface de boa qualidade, 
lembre-se: considere o fator humano, procure entender o usuário e, seu com-
portamento e seu nível de habilidade. 
Os usuários podem ser classificados como:
Novatos: nenhum conhecimento sintático do sistema e pouco conhecimen-
to semântico da aplicação ou uso do computador em geral.
Usuários intermitentes e com conhecimento: razoável conhecimento se-
mântico da aplicação, mas lembrança relativamente baixa das informações 
sintáticas necessárias para usar a interface.
Usuários frequentes e com conhecimento: bom conhecimento semântico e 
sintático que muitas vezes levam à “síndrome do usuário poderoso”. 
Por exemplo, se fosse perguntado ao usuário de determinado processador 
de texto para descrever sua operação, a percepção do sistema orientaria 
a resposta. A precisão da descrição irá depender do perfil do usuário (por 
exemplo, novatos dariam no máximo uma resposta muito superficial). Um 
usuário que entenda completamente de processadores de texto é capaz de 
dar uma descrição mais completa de sua função do que o novato que inves-
tiu semanas tentando aprender o sistema.
(Pressman).
Modelos de Análise e Projeto de Interfaces
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
71
MODELOS DE ANÁLISE E PROJETO DE INTERFACES
Conforme Pressman (2011, p. 291), temos quatro modelos distintos ao se ana-
lisar e projetar uma interface do usuário, os quais são:
 ■ Modelo de Usuário: é estabelecido o perfil dos usuários do sistema. Aqui 
devemos classificar os usuários em: novatos (nenhum conhecimento do 
sistema), usuários intermitentes (razoável conhecimento) e usuários fre-
quentes (bom conhecimento e são indivíduos que procuram atalhos e 
modos de interação abreviados). 
 ■ Modelo de Projeto: um modelo do projeto de interface é criado.
 ■ Modelo Mental: nesse modelo se molda como o usuário percebe a inter-
face e se ela atende às suas necessidades. 
 ■ Modelo de Implementação: onde a aparência e a percepção da interface, 
juntamente com todas as informações de apoio, descrevem como será a 
sintaxe e a semântica da interface do usuário. 
Até mesmo um usuário novato quer atalhos; mesmo usuários frequentes e 
com conhecimentos algumas vezes precisam de orientação. Dê a eles aquilo 
de que precisam. 
(Pressman).
PROJETO DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E72
O PROCESSO
Para Pressman (2011, p. 292), “o processo de análise e projeto de interfaces do 
usuário é interativo e pode ser representado usando-se um modelo espiral”. 
Começamos no interior na espiral e vamos englobando as atividades: análise e 
modelagem de interface, projeto da interface, construção da interface e a valida-
ção da interface. Como as atividades são em espiral, isto implica que cada uma 
das atividades ocorrerá mais de uma vez. 
Figura 3: O processo de projeto de interface do usuário
Validação da interface
Construção da interface Projeto da interface
Análise e modelagem da 
interface
Fonte: Pressman (2011, p. 293).
Conforme Pressman (2011, p. 293) a análise de interfaces possui o foco no perfil 
dos usuários que irão usar o sistema, seus níveis de habilidades, área de conhe-
cimento e sua receptividade. O projeto de interface define as representações da 
tela do sistema e sua usabilidade. Na construção da interface desenvolvemos o 
protótipo que permite avaliar os cenários em geral. Na validação da interface 
verificamos se a interface foi implementada corretamente, incluindo todas as 
tarefas de usuário, e também, se atende os requisitos gerais definidos aos usuá-
rios, grau de facilidade, aprendizado e aceitação por parte dos usuários. 
Modelos de Análise e Projeto de Interfaces
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
73
ANÁLISE DE INTERFACE
Pressman (2011, p. 294) afirma que “um princípio fundamental de todos os mode-
los de processos de engenharia de software é o seguinte: entender o problema 
antes de tentar desenvolver uma solução”. Quando fazemos a análise de interfa-
ces do usuário, entender o problema significa: entender os usuários, as tarefas que 
os usuários devem realizar o conteúdo que será apresentado e o ambiente onde 
essas tarefas serão conduzidas. A seguir, os elementos da análise de interfaces:
 ■ Análise de Usuários: devemos entender os usuários, para isso invista um 
tempo conversando com eles, entrevistando e colha o maior número de 
informações possíveis. 
 ■ Análise e Modelagem de tarefas: devemos identificar as tarefas que os 
usuários irão desempenhar via interface do usuário. 
Entrevistas com os usuários: na abordagem mais direta, membros da 
equipe de software se encontram com os usuários finais para entender me-lhor suas necessidades, motivações, cultura de trabalho e uma miríade de 
outras questões. 
Informações do pessoal de vendas: o pessoal de vendas se encontra re-
gularmente com usuários e pode reunir informações que ajudarão a equipe 
de software a classificar os usuários e compreender melhor seus requisitos.
Informações do pessoal de marketing: a análise de mercado pode ser 
inestimável na definição de segmentos de mercado e no entendimento de 
como cada segmento poderia usar o software de modos sutilmente dife-
rentes.
Informações do pessoal de suporte: a equipe de suporte conversa diaria-
mente com os usuários. Eles são, provavelmente, a fonte mais provável de 
informações sobre o que funciona e o que não funciona, o que os usuários 
gostam e o que não gostam, quais recursos geram questionamentos e quais 
são fáceis de ser usados.
Fonte: Pressman (2011).
PROJETO DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E74
 ■ Análise do Conteúdo exibido: devemos considerar o formato e a esté-
tica do conteúdo que será exibido aos usuários. 
 ■ Análise do Ambiente de trabalho: devemos analisar o ambiente de tra-
balho dos usuários, como ambientes físicos e a cultura do local. 
ETAPAS DO PROJETO DE INTERFACE
Depois que a análise de interface estiver pronta, todos os objetos e ações que foram 
solicitados pelo usuário foram detalhados, a atividade de projeto de interface se 
inicia. Conforme menciona Pressman (2011, p. 300) “o projeto de interface, assim 
como todo projeto de engenharia de software, é um processo iterativo. Cada etapa 
de um projeto de interface do usuário ocorre uma série de vezes, elaborando e 
refinando informações desenvolvidas na etapa anterior”.
Existem diversos modelos diferentes de projeto de interfaces do usuário, mas 
Pressman sugere a seguinte combinação de etapas: 
1. Fazer o uso das informações que foram desenvolvidas durante a análise 
de interfaces.
2. Modelar as ações dos usuários (eventos).
3. Mostrar cada estado da interface como irá aparecer ao usuário.
4. Mostrar como o usuário interpreta o estado do sistema.
Independente de como se dará o início das tarefas do projeto, por onde vamos 
iniciar, seja por esboço ou definindo objetos e ações, o importante é sempre 
seguir as regras de ouro mencionadas anteriormente, não esquecer de modelar 
como a interface será implementada e considerar como será o ambiente a ser 
usado pelo usuário. 
Aplicação das etapas para projeto de interfaces: devemos definir os objetos 
e quais as ações aplicadas a eles. Para isso, os cenários devem ser minunciosa-
mente analisados e descrito um caso de uso para exemplificar as etapas do projeto 
de interface do usuário. 
Modelos de Análise e Projeto de Interfaces
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
75
Padrões de projeto de interface do usuário: devemos definir os padrões 
de projeto para as interfaces de usuário, já que muitos podem desenvolver ações 
em comum. 
Questões de projeto: devemos definir algumas questões de projeto como:
 ■ qual o tempo de resposta do sistema? 
 ■ quais recursos de ajuda serão disponibilizados ao usuário?
 ■ como serão tratadas as informações de erro que pode aparecer aos usuários?
 ■ como será a atribuição de nomes a comandos e menus?
Acessibilidade às aplicações: devemos definir que o projeto de interfaces tenha meca-
nismos que permitam fácil acesso para quem é portador de necessidades especiais. 
Internacionalização: devemos definir que o projeto de interfaces leve em 
conta as necessidades de diferentes localidades e idiomas. 
Sobre a interface do usuário, Pressman (2011) afirma que
A interface do usuário é a janela para o software. Em muitos casos, ele 
molda a percepção do usuário quanto à qualidade de um sistema. Se a 
janela for embaçada, ondulada e quebrada, o usuário poderá rejeitar 
um sistema computacional que de outra forma seria poderoso (PRES-
SMAN, 2011, p. 313).
Com isso, podemos perceber que a interface do usuário é a parte mais importante 
de um projeto de software. Se ela for mal projetada, o usuário terá dificuldades 
e com isso a aplicação pode falhar. 
Vamos seguir em frente nos estudos? No próximo tópico vamos conhecer o 
Projeto de Estrutura de dados e seus conceitos. Continue a sua leitura! 
“Acima de tudo, invista tempo conversando com os usuários de fato, mas 
seja cauteloso. Uma opinião firme não significa necessariamente que a 
maioria dos usuários irá concordar”.
(Pressman).
PROJETO DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E76
Durante essa etapa de análise de interface, são considerados o formato e 
como ele é exibido pela interface. Entre as perguntas feitas e respondidas, 
temos:
• Os diferentes tipos de dados são alocados em posições geográficas consis-
tentes na tela?
• O usuário pode personalizar a localização do conteúdo na tela?
• Foi atribuída identificação apropriada na tela para todos os conteúdos?
• Se for preciso apresentar um relatório grande, como seria subdividido para 
facilitar sua compreensão?
• Haverá mecanismos disponíveis para ir diretamente a informações resumi-
das em conjuntos de dados volumosos?
• A saída gráfica será apresentada em escala para caber nos limites do dispo-
sitivo de exibição utilizado?
• Como serão usadas cores para melhorar o entendimento?
• Como serão apresentadas ao usuário mensagens de erro e alertas?
As respostas a essas (e outras) questões nos ajudarão a estabelecer os requi-
sitos para apresentação de conteúdo.
Fonte: Pressman (2011).
©shutterstock
Projeto de Dados
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
77
PROJETO DE DADOS
À medida que nos aproximamos da fase de implementação, o projeto de estrutura de 
dados assume uma importância significantiva, já que a estrutura dos dados representa 
os relacionamentos lógicos entre os diferentes elementos de dados individuais e uma 
vez que estas vão definir a complexidade procedimental do software (ou de seus com-
ponentes). O projeto de dados define como são organizados, como 
será os métodos de acesso, o processamento das informações, entre 
outros. O modelo de domínio da informação é transformado nas 
estruturas de dados que serão exigidas para implementar o software. 
A escolha da estrutura que será usada no projeto de dados vai 
depender muito da experiência anterior do projetista.
O tipo de aplicação a ser desenvolvida e o nível de 
criatividade do projetista, vão definir a forma como são orga-
nizados os elementos de dados e a sua complexidade em cada 
estrutura. É muito importante que seja estabelecido de que 
forma serão armazenados os dados do sistema. 
Questões de projeto
À medida que o projeto de uma interface do usuário evolui, quatro ques-
tões de projeto comuns quase sempre vêm à tona: tempo de resposta do 
sistema, recursos de ajuda ao usuário, informações de tratamento de erros 
e atribuição de nomes a comandos. Infelizmente, muitos projetistas não tra-
tam desses problemas até um ponto relativamente avançado do processo 
de projeto (algumas vezes a primeira vaga ideia de um problema não ocor-
re até que um protótipo operacional esteja disponível). Em geral, decorrem 
iterações desnecessárias, atrasos de projeto e frustração por parte do usu-
ário final. É muito melhor estabelecer cada um desses como um problema 
de projeto a ser considerado no início do projeto de software, quando as 
mudanças são fáceis e custam pouco.
Fonte: Pressman (2011).
PROJETO DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E78
O projeto dos dados é composto pela seleção das representações lógicas dos 
objetos de dados identificados na etapa de levantamento dos requisitos. Algunsprincípios devem ser seguidos para obter resultados satisfatórios no andamento 
do projeto de dados. São eles: 
 ➢ Realizar uma análise sistemática no que diz respeito aos dados, a exemplo 
do que é feito com os aspectos funcionais e comportamentais do software.
 ➢ Realizar a identificação das estruturas de dados e das operações a serem 
realizadas por elas.
 ➢ Realizar a criação de um dicionário da estrutura de dados.
 ➢ Procurar adiar decisões de baixa prioridade no que diz respeito ao pro-
jeto de dados.
 ➢ Procurar limitar a representação das estruturas de dados aos módulos 
que as utilizarão.
 ➢ Realizar a criação de uma biblioteca de estruturas de dados úteis e das 
operações a serem aplicadas a elas, em caso de reusabilidade. 
 ➢ Procurar usar uma linguagem de programação e projeto que suporte tipos 
abstratos de dados.
Mas porque o projeto de dados é importante? Será que ele influencia a quali-
dade do projeto? O Projeto de Dados possui uma importante influência sobre 
a qualidade do software que está sendo desenvolvido, seus conceitos de oculta-
ção de informação, abstração de dados que são oferecidos como a base para o 
projeto. Nessa fase do projeto todos os detalhes dos dados que serão manipu-
lados pelo sistema devem ser analisados com cuidado, sejam dados de entrada, 
de saída ou dados internos. 
O que seria uma estrutura de dados? É uma representação das relações 
lógicas existentes entre cada elemento individual de um dado. Ela é con-
siderada tão importante quanto à estrutura do programa definida para a 
arquitetura do software. Por qual motivo? Ela afeta o projeto procedural final. 
É importante observar que as estruturas de dados podem ser representadas em 
diferentes níveis de abstração. Vamos usar como exemplo a PILHA, que é um 
Projeto de Dados
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
79
modelo conceitual de estrutura de dados que pode ser implementado por uma 
lista ligada ou utilizando um vetor. Dependendo do nível de detalhe do projeto 
em que se está, o funcionamento da pilha pode ou não ser especificado.
Vamos conhecer agora algumas das possíveis estruturas de dados que podem 
ser utilizadas:
Listas: é uma estrutura de dados que funciona como um array. Com a dife-
rença que para cada posição, podem ser armazenados vários dados. O conjunto 
de dados armazenado em cada posição é chamado de nó. A lista é formada, é 
um conjunto de dados. 
Vetor sequencial: representam um conjunto de itens escalares organizados 
como um grupo ou uma lista. Exemplo:
Text: array[1..200] of string;
A: array[1..30] of integer;
Item escalar: representa um único elemento de informação endereçado por 
um identificador. Exemplos:
var i: integer;
var c: char;
Podem ser usadas outras estruturas de dados mais complexas, mas a escolha 
da estrutura que será usada no projeto de dados vai depender muito da experi-
ência anterior do projetista. 
Com isso, concluímos o conteúdo desta unidade. Desejo que você aproveite 
o máximo tudo o que vimos até aqui. Continue com os estudos, pois ainda temos 
muito pela frente. Bons estudos!
O projeto de dados se concentra em arquivos ou bancos de dados; no nível 
dos componentes, o projeto de dados considera as estruturas de dados para 
implementar os objetos de dados locais.
(Pressman).
PROJETO DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E80
CONSIDERAÇÕES FINAIS
Nesta unidade, analisamos a importância da fase de Projetos dentro do processo 
de desenvolvimento de software. Foram apresentados aspectos importantes rela-
tivos ao projeto e como essa fase é fundamental para o desenvolvimento de um 
software. Aprendemos que na fase de projeto é onde definimos a arquitetura 
do software, a interface com o usuário, os componentes que fazem parte dele e 
como será a estrutura de dados do software, tendo como base o que foi levan-
tado na análise de requisitos. 
Esta fase de projeto de software se caracteriza por ser a definição física do 
sistema, onde podemos definir como vai ser as interfaces do nosso sistema, em 
que especificamos mais os casos de usos, pois eles vão ajudar os programadores 
a escrever o código fonte deste sistema, que é a próxima fase, ou seja, a imple-
mentação do software. 
Um programa com uma arquitetura de dados fraca será difícil de adaptar e 
melhorar. Na verdade, para muitas aplicações, a arquitetura das informações 
tem mais a ver com a viabilidade de longo prazo de um programa do que o 
próprio código-fonte. Em muitos casos, a reestruturação dos dados começa 
com uma atividade de engenharia reversa. A arquitetura de dados atual é 
dissecada e os modelos de dados necessários são definidos. Identificam-se 
os objetos de dados e atributos, e as estruturas de dados existentes são revi-
sadas quanto à qualidade. Quando a estrutura de dados é fraca (por exem-
plo, estão implementados em arquivos de texto, quando uma abordagem 
relacional simplificaria muito o processamento), os dados passam por uma 
reengenharia.
Devido à arquitetura de dados ter uma forte influência sobre a arquitetura 
do programa e os algoritmos que a constituem, mudanças nos dados resul-
tarão invariavelmente em mudanças de arquitetura ou de nível de código.
Fonte: Pressman (2011).
Considerações Finais
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
81
Também aprendemos que quanto mais detalhado for o projeto de software, 
melhor para as próximas fases, principalmente a implementação, que veremos 
no próximo capítulo. Apesar que se todas as fases do processo de software forem 
bem detalhadas, chegamos ao final com um sistema com menos falhas e erros de 
desenvolvimento, pois todas as fases se complementam e se relacionam entre si. 
Ao longo da unidade, nos aprofundamos nos conceitos de projeto, os prin-
cipais aspectos, técnicas, modelos e tipos de projetos. Com esse conhecimento 
adquirido e com os próximos, possamos chegar ao final das fases que envolvem 
um processo de software, obtendo um sistema eficiente e com qualidade. 
Com isso, chegamos ao final da unidade II do livro e ao final de uma das fases 
do processo de desenvolvimento do software. Espero que você tenha conseguido 
entender os conceitos relacionados à fase de projeto. Se entendeu, conseguirá 
entender as próximas fases do processo de software que estão por vir nas próxi-
mas unidades. Continue sua leitura!
82 
1. Na fase de Projeto o principal objetivo é definir uma estrutura que possa ser im-
plementada baseada no que foi descrito nos requisitos que foram levantados 
para o sistema junto ao cliente. Você saberia dizer qual a diferença entre a análise 
e o Projeto?
2. Assinale a alternativa correta, marcando com (V) a assertiva verdadeira e com (F) 
a assertiva falsa, sobre o processo de software:
( ) Na fase de Projeto é decidido como o sistema irá se comportar, em termos de: 
software, hardware, internet, tipo de telefone, a interface de usuário, formulários 
que devem ser preenchidos e os relatórios que o sistema irá fornecer; outros 
programas específicos que possa vir a usar, quais bancos de dados e arquivos 
que serão necessários. 
( ) Na fase de Projeto é decidido como o sistema irá se comportar, em termos 
de: software, hardware, infraestrutura de rede, a interface de usuário, formulários 
que devem ser preenchidos e os relatórios que o sistema irá fornecer; outros 
programas específicos que possa vir a usar, quais bancos de dados e arquivos 
que serão necessários. 
( ) Na fase de Projeto é decidido como o sistema irá se comportar, em termos de: 
estrutura de cabos, hardware, infraestrutura de telefonia, a interface de usuário, 
formulários que devem ser preenchidos e os relatórios que o sistema irá forne-
cer; outros programas específicos que possa vir a usar, quais bancos dedados e 
arquivos que serão necessários. 
Assinale a opção com a sequência CORRETA.
a. V, F, V.
b. F, V, V.
c. V, V, V.
d. F, V, F.
3. Os principais conceitos relacionados ao projeto de software são: 
I. Abstração, refinamento, padrões, desenho, hierarquia de controle, encapsula-
mento, estrutura de dados, procedimentos de software, ocultação de informa-
ção.
II. Abstração, refinamento, modularidade, padrões, arquitetura, hierarquia de con-
trole, encapsulamento, estrutura de dados, procedimentos de software, oculta-
ção de informação.
III. Abstração, refinamento, modularidade, padrões, arquitetura, hierarquia de fun-
ções, encapsulamento, estrutura de dados, procedimentos de software, oculta-
ção de informação.
83 
Assinale a opção com a sequência CORRETA.
a. Somente a questão III está correta.
b. Somente as questões I e II estão corretas.
c. Somente a questão II está correta. 
d. Todas estão corretas. 
4. Por que o Projeto de Software é considerado uma das fases mais importantes do 
desenvolvimento de um software? 
5. O significado de componente vai depender do ponto de vista do responsável 
pelo projeto de componentes, o Engenheiro de Software. Mas qual seria este 
ponto de vista? 
6. Vimos que existem diversos modelos diferentes de projeto de interfaces do usu-
ário, mas sugerimos algumas combinações de etapas, que são:
I. Fazer o uso das informações que foram desenvolvidas durante a análise de in-
terfaces.
II. Modelar as ações dos engenheiros.
III. Mostrar cada estado da interface como não irá aparecer ao usuário.
IV. Mostrar como o usuário interpreta o estado do sistema. 
Assinale a opção com a sequência CORRETA.
a. Somente a questão III está correta.
b. Somente as questões I e IV estão corretas.
c. Somente a questão II está correta. 
d. Todas estão corretas. 
84 
O CONCEITO DE INTERFACE NO CONTEXTO DO DESIGN
Tatiana Silva Bevilacqua
Introdução
O design é uma área que vem se desenvolvendo muito nas últimas décadas e cuja im-
portância tem sido cada vez mais reconhecida. O trabalho de um designer muitas vezes 
é visto como algo meramente visual, ou seja, como se fosse a finalização meramente 
estética para determinados trabalhos serem visualmente atraentes. É certo que o design 
tem seu lado “plástico”, mas isso é apenas uma pequena parte de um processo complexo 
e abrangente.
O designer trabalha diretamente na interface, no trânsito entre usuário e objeto. No en-
tanto, mesmo os próprios designers muitas vezes não questionam efetivamente o que 
é a interface, não compreendendo como pode ser possível seu projeto não ser tão efi-
ciente quanto planejado. Os conceitos de interface já foram pontuados por diferentes 
profissionais e teóricos, não apenas da área do design. O próprio termo “interface” traz 
consigo sua significação de um modo amplo: é algo que se interpõe entre duas coisas 
distintas entre si. No entanto, esta definição não basta. É preciso, primeiramente, en-
tender a ideia de interface, para depois compreender onde ela é encontrada no design, 
identificar no contexto do design é o primeiro passo para sua conceituação. 
A Grande Questão do Design
Antes de maiores aprofundamentos, é importantíssimo pontuar qual o conceito de de-
sign considerado nesta pesquisa. No escopo deste trabalho, considera-se que o design 
é projeto e é feito para servir a alguém, ao usuário. Da mesma forma que um médico 
existe em função do paciente, o designer existe em função do usuário. No senso comum 
o design possui uma função meramente “cosmética”, de finalização, para deixar os pro-
dutos mais elegantes, mais agradáveis esteticamente. Na verdade, neste senso mora um 
dos maiores problemas do design, conferindo ao designer um papel menor. O designer 
não deveria participar do projeto apenas em sua etapa final ou estética, quando outras 
decisões importantes já foram tomadas, mas este deve, participar ativamente de todas 
as etapas de desenvolvimento de um projeto. Esta é a idéia fundamental que o designer 
Gui Bonsiepe defende.
Para Bonsiepe, o design é o elo entre as ciências de desenvolvimento de produtos e as 
ciências humanas que tratam o usuário. À engenharia, por exemplo, cabe desenvolver 
tecnologias, trabalhar sobre o maquinário. Ao marketing cabe inserir estas tecnologias 
na sociedade. Pode-se até considerar que à sociologia cabe estudar os efeitos em gran-
de escala destas novas tecnologias, ou seja, seus reflexos na sociedade. Enfim, cada área 
atua em uma parte deste complexo sistema de consumo. O design tem sua ação bem 
definida, bem como as outras áreas, mas nem sempre lhe é concebida a verdadeira fun-
ção. Ao design cabe estudar o objeto e o usuário, para adaptar aquele às características 
físicas e cognitivas deste.
85 
Da Interface
Temos que levar em conta que interface não é uma “coisa”, mas o espaço no qual se 
estrutura a interação entre corpo, ferramenta (objeto ou signo) e objetivo da ação.” (...) 
a interface revela o caráter da ferramenta dos objetos e o conteúdo comunicativo das 
informações. A interface transforma objetos em produtos. A interface transforma sinais 
em informação interpretável. A interface transforma simples presença física (Vorhande-
nheit) em disponibilidade (Zuhandenheit). A ferramenta é o que possibilita a interação, 
é um objeto, algo fisicamente presente e projetado para se adequar às diferentes partes 
da interação, ou então um signo, um “código”, imagens ou mensagens.
Há então, neste pensamento, uma diferenciação entre interface e ferramenta. A interfa-
ce, justamente por não ser algo moldável, ou palpável, não é a coisa em si, mas o espaço. 
O termo “espaço” não como sinônimo de “lugar”, algo definido por Brenda Laurel e que 
veremos a seguir. No pensamento de Bonsiepe o usuário é o foco do projeto, é a ele 
que o designer serve, e é ele quem deve se “satisfazer”. Sua satisfação é a realização de 
determinada tarefa, ou seja, o usuário deseja realizar uma tarefa e esta deve ser realizada 
de maneira fácil. Esses são os elementos básicos de estudo do design, são os elementos 
caracterizadores da interface. Em cada domínio do design a interface possui suas carac-
terísticas mais específicas.
Conclusão
A interface, no design, é uma realidade criada para simplificar a vida do usuário, ou seja, 
para tornar real uma tarefa que o usuário deseja realizar, da maneira mais natural possí-
vel. Esta realidade é o meio em que ocorre uma interação. As características do usuário e 
suas necessidades caracterizam a interface. As ferramentas, ou seja, os objetos a serem 
projetados pelos designers devem refletir estes conceitos de forma imperceptível ao usu-
ário, como sugerido por Norman. Para Laurel, a interface é um lugar onde ocorre a intera-
ção enquanto Bonsiepe entende a interface como o meio em que o sistema de interação 
está imerso. Ao tirarmos do objeto em si a responsabilidade de ser a interface, é muito 
mais fácil compreender em cima de quê o design deve trabalhar para desenvolver pro-
dutos cada vez mais eficientes. Como dito no início do artigo, o visualmente agradável é 
apenas uma pequena parte, é uma consequência, de algo muito mais complexo. Quanto 
mais agradável ao olhar, maior é a tendência de ser passivo a esta informação visual. 
Quanto mais confortável é um objeto, maior a tendência de sentir-se bem em um sofá.
É esta ideia que deve ser desenvolvida no design, entender as necessidades do usuário. 
O design não pode ter a pretensão de querer evidenciar seus benefícios para o usuário, 
ele deve simplesmente resolver seus problemas.
Atualmente, o grande foco da ergonomia é estudar as necessidades humanas, físicas e 
psicológicas, para adaptar o objeto ao usuário. Mais uma vez, o design caminhando para 
adequar os objetos aos seres humanos e não o caminho contrário. Sendo assim, é nítida 
a relação deste objetivo ao conceito de interface invisível de Don Norman.
Fonte: Bevilacqua (2007). 
MATERIAL COMPLEMENTAR
Projeto de Software: Da programação à arquitetura: Uma 
abordagem baseada emJava
Eric Braude
Editora: Bookman (edição digital)
Sinopse: Projeto de software é um guia completo sobre teoria e 
prática de projetos da programação à arquitetura, tratando desde 
o nível de código, com questões de programação, até abstração e 
escopo. Na obra, o autor analisa as questões de projeto de nível.
A queda Hitler projeto software gestão 
Divertido vídeo sobre a sátira utilizando parte do fi lme ‘A queda as ultimas horas de Hitler’ para 
descrever como funcionaria uma reunião do gerenciamento de um projeto de software. 
<https://www.youtube.com/watch?v=I2OUo1GLm5E>.
Interface de Aplicação em Projetos de Software 
Vídeo muito interessante sobre a interface de aplicação. A implementação da interface da 
aplicação é sempre um grande desafi o para o desenvolvedor de software. Pensando nisso Ramon 
Durães está promovendo um bate-papo nesse vídeo para discutir a importância de se pensar na 
experiência do usuário e o quanto essa questão é importante para o desenvolvedor de software. 
Aproveite e aprofunde seus conhecimentos. 
<https://www.youtube.com/watch?v=BMjOO4k5tJc>.
Material Complementar
MATERIAL COMPLEMENTAR
Desafios do Projeto de Software
Um artigo com metáforas muito interessante sobre os desafios de um projeto de software. Este 
artigo é baseado em uma parte do quinto capítulo do livro Code Complete, por McConnell, 
2ª edição. Um livro excelente sobre a criação de software, onde os princípios não entram em 
obsolescência com o passar do tempo, ao contrário das implementações das linguagens de 
programação. McConnell sabe o valor da metáfora no mundo abstrato da programação de 
computadores. Ele inclusive trata disso em seu livro. Não perca, vale a pena ler. Acesse o link em: 
<http://bussola.code-squad.com/2015/05/27/desafios-projeto-de-software/>.
Definindo a Arquitetura de um Projeto de Software
Vamos saber mais sobre a Arquitetura de um Projeto de Software? Leia este artigo. Ele mostra 
como como definir uma boa arquitetura, como começar, quais ferramentas podem ser usadas, 
como aplicar a separação de responsabilidades ao seu projeto de software, como utilizar os 
padrões de projeto e como determinar um processo bem definido de desenvolvimento de 
software. 
Disponível em: <http://imasters.com.br/framework/dotnet/net-definindo-
a-arquitetura-de-um-projeto-de-software/?trace=1519021197&source=sin
gle>.
PROTOTIPAGEM DE INTERFACES NA PRÁTICA
Otimizando a identificação e especificação de requisito
Este artigo mostra como a prototipagem vem ganhando cada vez mais valor no mercado e já é 
utilizada em muitas empresas. Entretanto, ainda é vista muitas vezes apenas como uma forma 
de comunicação entre o requisito e o desenvolvimento, representando somente a disposição 
da tela. Na verdade, a prototipagem permite a validação e melhor entendimento dos requisitos 
levantados com o usuário, além de lhe proporcionar uma visão prévia do produto que será 
construído. As técnicas aqui apresentadas no artigo permitem otimizar a produtividade da equipe 
e minimizar o retrabalho. Excelente leitura, aproveite!
<http://www.univale.com.br/unisite/mundo-j/artigos/48Prototipagem.pdf>.
REFERÊNCIAS
BEVILÁCQUA, T. S. O conceito de interface no contexto do design. Anais do 3º Con-
gresso Internacional de design da informação, 2007.
COSTA, C. de F. Qualidade do Produto e Processo de Software. Brasília: 2010.
CROSBY, P. B. Qualidade, falando sério. São Paulo: McGraw-Hill, 1990.
GIMENES, I. M. S. Uma Introdução ao Processo de Engenharia de Software. XIII 
Jornada de atualização em Informática. Caxambu – MG, 1994.
GIMENES, I.; HUZITA, E. Desenvolvimento Baseado em Componentes: Conceitos 
e Técnicas. São Paulo: Editora Ciência Moderna, 2005. 
PRESSMAN, R. Engenharia de Software. 7. ed. Porto Alegre: AMGH, 2011.
REZENDE, D. A. Engenharia de Software e Sistemas de Informação. 3. ed. Rio de 
Janeiro: Editora Brasport, 2005.
SOMMERVILLE, I. Engenharia de Software. São Paulo: Pearson Prentice Hall, 2011. 
WEBER, K. C., ROCHA, A. R. C.; MALDONADO, J. C. Qualidade de Software – Teoria e 
Prática. São Paulo: Prentice Hall, 2001.
GABARITO
89
1. Na análise de requisitos é modelado o domínio do problema e no Projeto é mo-
delada a solução para o problema.
2. D - F, V, F.
3. C - Somente a questão II está correta. 
4. Ele é considerado importante, porque é nele que iniciamos a etapa de qualidade 
e ele serve como base para as outras fases do processo de software. 
5. Conforme Pressman (2011) são três pontos de vistas que são utilizados. São eles: 
Visão Orientada a objetos: para esta visão, um componente é um conjunto 
de classes colaborativas ou podem ter um componente com uma única classe. 
Visão Tradicional: para esta visão, um componente é o elemento funcional de 
um programa que incorpora a lógica de processamento, as estruturas de dados 
e uma interface que habilita o componente para que os dados sejam fornecidos 
a ele. Visão relacionada com processos: para esta visão, um componente é uti-
lizado a partir da reusabilidade, ou seja, que façamos o uso de componentes de 
software ou de padrões de projeto já existentes. 
6. B. Somente as questões I e IV estão corretas.
U
N
ID
A
D
E III
Professora Esp. Janaína Aparecida de Freitas
IMPLEMENTAÇÃO DE 
SOFTWARE
Objetivos de Aprendizagem
 ■ Compreender a importância da implementação de software.
 ■ Entender as questões fundamentais que precisam ser consideradas 
durante a implementação do software.
 ■ Apresentar os conceitos e técnicas que envolvem a implementação e 
a depuração.
Plano de Estudo
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
 ■ Implementação de Software
 ■ Atividades da Implementação de Software
 ■ Características da Implementação de Software
 ■ Estilo de programação e codificação
 ■ Comentário
 ■ Depuração
 ■ Asserções e Programação Defensiva
 ■ Otimização de Desempenho
 ■ Refatoração
INTRODUÇÃO
Caro(a) Aluno(a), na unidade anterior aprendemos sobre a fase de projeto e a 
sua importância no processo de desenvolvimento do software. Nesta unidade do 
livro, vamos aprender todos os aspectos da fase da Implementação, com exce-
ção da fase dos testes que será vista nas próximas unidades.
Nesta unidade, vamos conhecer mais a fundo os conceitos que envolvem a 
fase de Implementação, compreender a sua importância, entender as questões 
fundamentais que são consideradas durante esta fase. Na fase de projeto é gerada 
uma descrição computacional, mencionando o que o software deve fazer, e deve 
ser coerente com a descrição realizada no levantamento de requisitos. Na fase 
de Implementação, o projeto é traduzido para uma forma passível de execução 
pela máquina. A fase de Implementação realiza esta tarefa, isto é, cada unidade 
de software do projeto detalhado é escrita.
Nesta fase ocorre a codificação/programação dos requisitos de software, 
baseado nas definições técnicas analisadas na fase de projeto. A Implementação 
atualmente pode utilizar linguagens de programação visuais e orientadas a objeto, 
com ambientes de desenvolvimento fáceis e amigáveis para o desenvolvimento 
dos códigos.
Na fase de Implementação detalhamos os componentes previstos no pro-
jeto, descrevendo todos os componentes de código fonte e código binário, em 
nível de linguagem de programação ou de acordo com as tecnologias escolhi-
das no levantamento de requisitos.
Na fase de Implementação, o resultado da escolha correta do ambiente de 
programação e demais ferramentas, no final é com certeza um software de boa 
qualidade, pois não basta saber programar em uma linguagem de programação 
para implementar um software, é necessário, também, conhecer e aplicar boas 
práticas de programação e usar ferramentas disponíveis para tornar esta fase 
mais eficiente e eficaz.
Vamos, a fase de Implementação! Boa leitura e bons estudos!
Introdução
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
93
©shutterstock
IMPLEMENTAÇÃODE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIIU N I D A D E94
IMPLEMENTAÇÃO DE SOFTWARE
Conforme Tsui e Karam (2013, p. 135), “o objetivo final da maioria dos projetos 
de engenharia de software é produzir um programa funcional. O ato de trans-
formar o projeto detalhado em um programa válido em alguma linguagem de 
programação, juntamente com todas as suas atividades de apoio é aludido como 
implementação”. Nessa fase, ocorre a codificação/programação dos requisitos de 
software, baseado nas definições técnicas da fase de projeto.
Na fase de implementação desenvolvemos o código, mas ela vai além disso. 
Nessa fase, vamos ver que além de ser escrito o código, precisamos testá-lo e 
depurá-lo, assim como compilá-lo e, por fim, ter um produto executável com-
pleto. Durante este processo, o ideal é que se utilize um controle de versões para 
acompanhar as diferentes versões do código durante o desenvolvimento.
 O profissional responsável por desenvolver esta etapa é conhecido por 
Programador ou Desenvolvedor, cujo perfil apresenta excelentes capacidades 
lógicas e analíticas. 
A fase de Implementação detalha os componentes previstos no projeto, des-
crevendo todos os componentes de código fonte e código binário, em nível de 
linguagem de programação ou de acordo com as tecnologias escolhidas. 
Implementação de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
95
A fase de implementação envolve as seguintes atividades: codificação, depura-
ção, compilação, integração e testes. A atividade de codificação mostra a estrutura 
e o comportamento que foram descritos na fase de projeto. Os testes podem ser 
iniciados durante a fase de implementação e a depuração de erros pode ocor-
rer durante a codificação, podendo ser utilizada algumas ferramentas e técnicas. 
Ao se iniciar a fase de implementação, é necessário escolher o ambiente que 
vai ser programado, boas práticas para facilitar a manutenção depois, rotinas de 
testes que devem ser executados, documentações pertinentes a esta fase, arquivos 
de configuração e outras questões que possam influenciar direta ou indireta-
mente no bom desempenho desta fase. Em caso do ambiente de implementação 
escolhido for orientado a objetos, outras questões devem ser analisadas, como 
relacionamentos entre objetos, métodos, controle de instâncias e persistência 
de objetos. Para Beck (2013, p. 13), “melhorar a comunicabilidade do software 
também aumenta a flexibilidade. Quando mais pessoas puderem ler, entender 
e modificar o código rapidamente, mais opções se tem para mudanças futuras”. 
Na fase de implementação, o programador procura mapear corretamente 
as representações (ou modelos) obtidas no projeto para uma dada linguagem 
de programação. As características de uma linguagem de programação podem 
exercer um impacto significativo no desenvolvimento da codificação, segundo 
diferentes ângulos.
A fase de implementação demanda grande parte do tempo no processo do 
desenvolvimento de um software, considerada uma atividade trabalhosa e que 
exige profissionais que tenham habilidades e experiência na área. 
A fase de implementação inclui algumas tarefas, como por exemplo:
 ■ Planejamento detalhado da implementação das unidades de cada iteração.
 ■ Implementação das classes e outros elementos do modelo de projeto, 
geralmente arquivos de código fonte.
 ■ Verificação das unidades, por meio de revisões, inspeções e testes de 
unidade.
 ■ Compilação, ligação das unidades e integração das unidades entre si. 
 ■ Integração das unidades com componentes reutilizados.
IMPLEMENTAÇÃO DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIIU N I D A D E96
Quando falamos de integração, nos referimos à ligação de um componente desen-
volvido com outro que necessite dos seus serviços.
Conforme Sommerville (2013, p. 135), “o estágio mais crítico desse pro-
cesso é, naturalmente, a implementação do sistema, estágio em que você cria 
uma versão executável do software”. A fase de implementação pode envolver o 
desenvolvimento de programas em alto e baixo nível de linguagens de programa-
ção. Para Sommerville (2013, p. 136), existem alguns aspectos de implementação 
que são importantes, como:
1. Reuso: quando se está desenvolvendo um sistema, devemos fazer o maior 
uso possível de códigos já existentes. 
2. Gerenciamento de configuração: quando se está desenvolvendo um sis-
tema, são geradas muitas versões diferentes, sendo interessante usar um 
gerenciamento de configuração para o controle. 
3. Desenvolvimento host-target: o desenvolvimento de um sistema ocorre 
em um computador (sistema host) e é executado em outro (sistema tar-
get), podendo ser do mesmo tipo ou muitas vezes diferentes. 
Para Beck (2013, p. 5), “muitas decisões na programação são únicas e a codi-
ficação seria mais eficaz se programadores gastassem menos tempo nas partes 
mundanas e repetitivas do trabalho e tivessem mais tempo para resolver proble-
mas verdadeiramente únicos”. 
Caso não consiga encontrar uma linguagem de padrões que trate do domí-
nio de seu problema, procure analogias em um outro conjunto de padrões. 
(Pressman).
Atividades da Implementação de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
97
ATIVIDADES DA IMPLEMENTAÇÃO DE SOFTWARE
Durante a fase de implementação é gerado algumas documentações que são 
importantes para o uso do software que está sendo desenvolvido. As documenta-
ções envolvidas são: manuais de usuários, ajuda on-line, material de treinamento, 
demonstrações e outros recursos que podem produzir uma documentação que 
auxilie o uso do sistema por parte dos usuários. A documentação constitui um 
elemento essencial tanto para atividades de validação do software como (e prin-
cipalmente) para as tarefas de manutenção.
Conforme aumenta a importância do software, a comunidade da área tenta 
desenvolver tecnologias que tornem mais fácil, mais rápido e mais barato 
desenvolver e manter programas de computador de alta qualidade. Algu-
mas dessas tecnologias são direcionadas a um campo de aplicação espe-
cífico (por exemplo, projeto e implementação de sites); outras são focadas 
em um campo de tecnologia (por exemplo, sistemas orientados a objetos 
ou programação orientada a aspectos); e ainda outras são de bases amplas 
(por exemplo, sistemas operacionais como o Linux). Entretanto, nós ainda 
temos de desenvolver uma tecnologia de software que faça tudo isso, sen-
do que a probabilidade de surgir tal tecnologia no futuro é pequena. Ainda 
assim, as pessoas apostam seus empregos, seu conforto, sua segurança, seu 
entretenimento, suas decisões e suas próprias vidas em software. Tomara 
que estejam certas.
Fonte: Pressman (2011).
IMPLEMENTAÇÃO DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIIU N I D A D E98
Figura 1: Fluxo da Implementação
Fonte: Santos Neto, (2007).
O Fluxo de Implementação inicia-se com o desenho detalhado, que segue para 
a codificação, em que é feita a tradução do desenho detalhado no código de 
uma ou mais linguagens de programação. Na codificação, podemos utilizar as 
IDE (Integrated Development Enviroment), que são ferramentas para desen-
volvimento que possuem bibliotecas, atalhos, wizards e outras funcionalidades 
integradas, que facilitam a vida do programador. 
Projeto de 
arquitetura
Desenho 
detalhado
Inspeção de 
implementação
Testes de 
unidade
Integração
Implementação 
completa
Unidades veri�cadas
Defeitos encontrados
Implementação incompleta
Codi�cação
Atividades da Implementação de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98.
99
Depois as unidades de código fonte produzidas são passadas por uma revisão 
de código, em que são eliminados os defeitos primários, como erros de digitação 
ou de uso da linguagem mesmo. Essa revisão também deve ser feita pelos progra-
madores. Na sequência, vem a atividade de Inspeção de implementação em que é 
verificado de forma mais rigorosa o código por meio de um grupo de revisores. 
Na atividade de testes de unidade são feitos testes usando componentes de 
teste que devem também ter sido desenhados, revistos, codificados e compila-
dos nas atividades anteriores. Um teste de unidade é aquele que testa uma única 
unidade do sistema. O teste de unidade testa de maneira isolada as prováveis 
dependências que aquela unidade tem. 
Quando o sistema é orientado a objeto, a unidade pode ser uma classe. Por 
exemplo: ao executar o teste de unidade para a classe Vendedor, essa lista de tes-
tes testará o funcionamento da classe Vendedor, de forma isolada, sem interações 
com outras classes do sistema. Os testes de unidades devem ser feitos usando 
componentes de teste que devem também ter sido projetados, revistos, codifi-
cados e compilados nas atividades anteriores. 
A atividade Integração liga as unidades implementadas com os componen-
tes construídos em liberações anteriores, reutilizados de projetos anteriores ou 
adquiridos comercialmente. O código executável resultante passa para a fase de 
testes para realização dos testes de integração.
“O estágio de implementação do desenvolvimento de software é o processo 
de conversão de uma especificação do sistema em um sistema executável.”
(Sommerville).
©shutterstock
IMPLEMENTAÇÃO DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIIU N I D A D E100
CARACTERÍSTICAS DA IMPLEMENTAÇÃO DE 
SOFTWARE
Para Tsui e Karam (2013, p. 135) sempre é bom ter em mente algumas caracte-
rísticas que devem ser encontradas em uma boa implementação:
 ■ Legibilidade: o código deve ser facilmente lido e entendido. 
 ■ Mantenabilidade: o código deve ser facilmente modificado e mantido. 
 ■ Desempenho: códigos em que a execução seja a mais rápida possível. 
 ■ Rastreabilidade: todos os elementos do código 
devem corresponder a um elemento do projeto.
 ■ Exatidão: a implementação deve fazer aquilo 
que foi definido no levantamento de requi-
sitos e no projeto. 
 ■ Integridade: todos os requisitos levantados 
devem ser atendidos. 
O engenheiro de software, com frequência, assume compromissos de imple-
mentação para conseguir que o protótipo entre em operação rapidamente. 
Um sistema operacional ou linguagem de programação inapropriados po-
dem ser utilizados simplesmente porque se encontram à disposição e são 
conhecidos; um algoritmo ineficiente pode ser implementado simplesmen-
te para demonstrar capacidade. Após um tempo, pode-se acomodar com 
tais escolhas e esquecer todas as razões pelas quais eram inapropriadas. 
Uma escolha longe da ideal acaba se tornando parte integrante do sistema.
Embora possam ocorrer problemas, a prototipação pode ser um paradigma 
efetivo para a engenharia de software. O segredo é definir as regras do jogo 
logo no início, isso significa que todos os envolvidos devem concordar que 
o protótipo é construído para servir como um mecanismo para definição de 
requisitos. Portanto, será descartado (pelo menos em parte) e o software 
final é arquitetado visando qualidade.
Fonte: Pressman (2011).
Estilo de Programação e Codificação
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
101
Para a obtenção dessas características, é necessário um esforço e que exista um 
relacionamento entre elas, uma influencia na outra. Por exemplo: as otimizações 
de desempenho frequentemente reduzem a legibilidade e a mantenabilidade. 
Na fase de implementação, a preocupação é com a correção, a eficiência, a fle-
xibilidade dos aspectos executáveis para o modelo que está sendo desenvolvido. 
Podemos utilizar algumas ferramentas nesta fase, por exemplo: compiladores, 
interpretadores, editores, depuradores, geradores de código, geradores de tes-
tes, formuladores de código, analisadores etc.
ESTILO DE PROGRAMAÇÃO E CODIFICAÇÃO
Um fator que é essencial para a obtenção de um código claro e que ofereça facili-
dade de manutenção é a boa utilização dos mecanismos presentes na linguagem 
adotada que são os estilos de programação e codificação.
É importante para a empresa adotar estilos ou padrões de codificação. Estes 
estilos fornecem e especificam algumas regras de: atribuição de nomes de variá-
veis, endentações e estilos de comentários entre outros. Isto é importante quando 
se trabalha em equipe e quando outros programadores estiverem realizando a 
depuração ou a manutenção de seu código posteriormente. 
Muitos programadores, geralmente, trabalham em equipe, necessitando se 
integrar, testar e muitas vezes alterar os códigos que são produzidos por outros 
programadores. Por isso, é importante que haja padrões de codificação para a 
fase de implementação. Tais padrões devem ser seguidos por todos os progra-
madores, de modo que o código e a documentação sejam claros para quaisquer 
membros da equipe.
A seguir vamos ver algumas questões importantes que devem ser utilizadas e 
que podem afetar o estilo das codificações, conforme Tsui e Karam (2013, p. 136): 
IMPLEMENTAÇÃO DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIIU N I D A D E102
Atribuição de nomes: essa questão refere-se à escolha de nomes que serão 
usados em variáveis, classes, métodos e outros elementos de programação. Outro 
ponto importante é a consistência, assim, procure utilizar sempre nomes com 
a mesma palavra ou abreviação para um dado conceito e evite usar o mesmo 
nome ou abreviação para conceitos diferentes. 
Separação de palavras e utilização de maiúsculas/minúsculas: em muitos 
casos, um nome poderá ser composto por mais de uma palavra e em algumas 
linguagens de programação possuem diferentes convenções para combinar as 
palavras para um identificador. Assim, seria recomendado que se utilizasse as 
convenções-padrões para a sua linguagem. 
Endentação e espaçamento: se refere ao acréscimo de espaços horizontais 
antes de algumas linhas para melhorar a estrutura do código. Para muitos, é um 
erro do programador iniciante não endentar o código de forma apropriada. A 
endentação afeta a legibilidade e a mantenabilidade do código. 
Tamanho da função/método: códigos com grandes funções ou métodos são 
mais propensos a erros do que os menores até certo ponto, pois, às vezes, méto-
dos muitos pequenos podem gerar muitos erros também. 
Questões de atribuição de nomes de arquivo: uma das grandes vantagens 
quando se adota um padrão é especificar como devem ser atribuídos os nomes 
de arquivos, assim a localização de todos os elementos é facilitada. 
Elementos particulares de programação: temos várias linguagens de pro-
gramação diferentes e que suportam recursos diferentes e muitos destes recursos 
são considerados perigosos. 
“Um abordagem de bom senso para a implementação: mantenha simples, 
ajuste para satisfazer as necessidades locais, e certifique-se de que tudo 
agregue valor.”
(Pressman).
©shutterstock
Comentários 
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
103
COMENTÁRIOS 
Conforme Tsui e Karam (2013, p. 
136), “os comentários são muito 
importantes e podem ajudar ou 
prejudicar significativamente a legi-
bilidade e a mantenabilidade”. Neste 
caso, quando usamos os comentá-
rios durante o desenvolvimento, 
podem surgir alguns problemas, 
por exemplo:
 ■ Eles podem desviar a atenção 
do código e tornar o código mais difícil de ler.
 ■ Eles podem estar errados, aumentando a incidência de erros. 
Outro caso que pode ocorrer, os comentários podemficar desatualizados con-
forme os códigos vão mudando e com isso, criando novos erros. Isso porque, 
eles podem estar errados desde a primeira vez e como não são testados e atua-
lizados, a funcionalidade pode ter mudado. 
Os textos das mensagens são mais voláteis que o código da aplicação. Du-
rante o período de implantação, as mensagens tendem a ser alteradas para 
serem mais bem compreendidas pelo usuário. Uma boa prática é armaze-
nar estas mensagens fora do código fonte da aplicação. Isto permite que 
os textos sejam alterados sem que a aplicação seja compilada novamente. 
Além disso, os erros de negócio mostrados para o usuário devem estar na 
linguagem utilizada pelo usuário. Isto implica que o mecanismo de mensa-
gem precisa armazenar os textos das mensagens em diversas linguagens, o 
que contribui para a utilização de um repositório que armazena essas men-
sagens.
Fonte: Valentin, Dias e Pacheco (2008). 
IMPLEMENTAÇÃO DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIIU N I D A D E104
Apesar de alguns problemas, os comentários podem ajudar a esclarecer o 
código, assim como outras fontes relacionadas a ele. Entretanto, é preciso des-
tacar que eles representarem algum nível de duplicação do código, em certos 
momentos. Um comentário que não possui relação ao código o qual ele foi inse-
rido pode causar muitos erros que se tornam difíceis de encontrar e corrigir.
Para Tsui e Karam (2013, p. 136), os comentários podem ser definidos nos 
seguintes tipos:
Repetição do código: comentários que normalmente são feitos por pro-
gramadores novatos. Para não gerar confusão, devem ser evitados, pois são um 
desperdício de esforço e irão distrair os leitores. 
Explicação do código: alguns programadores costumam explicar na lin-
guagem o que o código faz, em casos de códigos complexos. Mas em quase toda 
situação, se o código é muito complexo que exija uma explicação, ele deve ser 
revisado.
Marcador no código: muitos programadores utilizam marcadores para 
indicar que está com itens incompletos, para indicar mudanças ou quem fez as 
alterações. Neste caso, é recomendado que seja usado um gerenciador de ver-
são para controle. 
Resumo de código: são muito úteis para que os programadores enten-
derem o código, desde que estejam sempre atualizados. Esse resumo, sempre 
atualizado, eliminará a necessidade de comentários ao longo do código, o que 
dificulta a manutenção. 
Descrição do objetivo do código: são os comentários mais úteis, pois ele 
descreve o que o código deve fazer e não o que ele faz. Neste caso, se o código 
não fizer o que foi descrito, ele estará errado. 
Referências externas: usados para vincular comentários a entidades exter-
nas, como por exemplo, livro, outros programas ou a existência de dados de 
inicialização nas tabelas do banco de dados. 
Comentários 
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
105
Os comentários podem mostrar outro problema sério, podem ser utiliza-
dos para justificar as práticas de codificação inadequada. Muitos programadores 
podem produzir códigos excessivamente complexos e difíceis de dar manuten-
ção, com isso vão acrescentando comentários em vez de revisá-lo e reescreve-lo 
usando um bom padrão. 
Conforme Tsui e Karam (2013, p. 136), muitos especialistas recomendam 
que se evitem os comentários em excesso e que os programadores devem buscar 
incluir os comentários em seu lugar e, especialmente, na forma da descrição da 
intenção do programador. Para isso, encoraje os programadores a utilizar bons 
nomes e boas práticas de programação, reservem os comentários para referên-
cias externas e declarações de intenções e no caso de códigos mais complexos, 
que não podem ser revisados, recomendar a utilização de comentários de resu-
mos, que são mais fáceis de fazer a manutenção. 
Durante a execução de uma atividade, alguns erros podem ocorrer. O usu-
ário que iniciou a atividade precisa ser informado sobre o que deu errado. 
O recurso de tratamento de exceções das linguagens é um avançado meca-
nismo que auxilia neste controle de erros e de mensagens. É necessário es-
tendê-lo para criar um mecanismo capaz de controlar exceções de negócio. 
Erros de variáveis não inicializadas, de tipos incompatíveis de dados, de índi-
ce inválido de vetor, entre outros, são erros da linguagem que devem ser se-
parados dos erros de negócio, que seriam: erro ao iniciar um processo; erro 
ao executar um serviço; erro ao registrar a movimentação na conta; erro de 
saldo insuficiente para a operação. Geralmente, erros de linguagem revelam 
bugs da aplicação, enquanto que erros de negócio revelam inconsistência 
nos dados da aplicação ou dos parâmetros fornecidos para algum processo.
Fonte: Valentin, Dias e Pacheco (2008).
©shutterstock
IMPLEMENTAÇÃO DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIIU N I D A D E106
DEPURAÇÃO
Conforme Tsui e Karam (2013, p. 139), “depuração é o ato de localizar e corri-
gir erros no código. Os erros geralmente são descobertos através de testes, mas 
podem ser encontrados por outros meios, incluindo as inspeções de códigos e 
por meio do uso normal do programa”. 
Depurar é considerado um processo 
usado para reduzir ou encontrar bugs no 
seu sistema. De uma forma geral, depurar o 
código não é uma tarefa fácil de ser execu-
tada. Um dos motivos, é que podem ocorrer 
muitas variações que podem vir a atrapalhar 
esse processo, um exemplo é a linguagem que 
está sendo utiliza e ferramentas disponíveis 
para fazermos a depuração de um código. 
Mas devemos tomar cuidado, pois depu-
rar é um processo iterativo. Você estará 
criando possíveis hipóteses em cima do erro, criando possíveis testes para pro-
var estas hipóteses, podendo alterar o código para corrigir os erros encontrados. 
Mas caso essas hipóteses sejam falsas pode ser necessário voltar atrás e iniciar o 
processo com novas hipóteses. 
Tsui e Karam (2013, p. 139) identificam quatro fases no processo de depu-
ração e elas podem ser resumidos da seguinte maneira:
Estabilização (reprodução): nessa fase reproduzimos o erro em uma confi-
guração particular, no caso, a máquina do programador e assim verificar os erros 
que estão ocorrendo. O mais importante desta fase é a identificação do erro e 
das condições em que ele ocorre. Os resultados dessa fase são um conjunto de 
testes que reproduzem o erro várias vezes, desde situações mais simples. A fase 
de estabilização pode ser considerada muito difícil às vezes, pois podem ocorrer 
erros aleatórios, que ao serem testados mais de uma vez, produzem resultados 
diferentes. 
Depuração
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
107
Localização: nessa fase ocorrem as descobertas de seções do código que 
podem levar aos erros. Esta fase é a que envolve a parte mais difícil de ser veri-
ficada. Mas se a fase de estabilização encontrar situações de testes, a fase de 
localização se torna mais fácil e mais óbvia. 
Correção: nessa fase o processo de correção envolve possíveis alterações do 
código para a correção dos erros, desde que tenha ocorrido antes a estabiliza-
ção e a localização do que causou os erros, melhorando as chances de corrigi-lo. 
Caso tente corrigir os erros de forma aleatória pode ser que sejam introduzi-
dos novos erros. 
Verificação: nessa fase é feita as verificações e certificações de que o erro 
realmente foi corrigido. Também é verificado que não há outros erros que pos-
sam ter sido introduzidos no código durante a alteração. Pois, uma alteração no 
código não corrigirá o erro e ainda poderá introduzir novos erros. 
Segundo Tsui e Karam (2013, p. 139) “erros em um programa podem ser 
categorizados em erros de sintaxe e erros lógicos”. Em linguagens compiladas os 
erros de sintaxetendem a ser fáceis de encontrar, pois o compilador irá detectar 
e ele irá fornecer informações sobre a sua localização, apesar de os compilado-
res não possuírem uma linguagem clara. 
Mas para facilitar a depuração, já que ela possa ser considerada uma tarefa 
muito complicada, existem algumas ferramentas que podem te ajudar no pro-
cesso de depuração. Conforme Tsui e Karam (2013, p. 139) são elas:
 ■ Comparadores de código-fonte: ajudam a encontrar as alterações no 
código.
 ■ Verificadores Ampliados: usados para encontrar problemas com sin-
taxe, lógica e estilo. 
 ■ Depuradores Interativos: permite que sejam verificadas as variáveis, esta-
beleça pontos de interrupção, saltar em pontos de seu código. 
 ■ Bibliotecas especiais: construídas para reimplementar as bibliotecas 
padrão, possuem segurança extra, para detectar e evitar erros. 
 ■ Traçadores de perfil: ferramentas que descrevem as pré e as pós-condi-
ções, ferramentas de cobertura que ajudam nos testes. 
IMPLEMENTAÇÃO DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIIU N I D A D E108
A depuração é uma tarefa importante a fim de evitar erros e, consequentemente 
evitar uma necessidade de transformação total do código depois de pronto. O 
programador ao utilizar uma ferramenta de depuração possui uma ajuda extra, 
pois uma ferramenta que só precisa configurar um breakpoint corretamente e 
seguir os passos para a depuração faz com que não ocorra perda de tempo. Ou 
seja, a depuração é algo rotineiro na vida dos programadores e algo importante, 
pois ajuda sempre a descobrir os erros. 
Por que a depuração é tão difícil? Com toda certeza, a psicologia humana 
tem muito mais a ver com a resposta do que a tecnologia de software. No 
entanto, algumas características dos erros fornecem alguns indícios:
1. O sintoma e a causa podem ser geograficamente remotos. Isto é, o sinto-
ma pode aparecer em uma parte de um programa, enquanto a causa pode 
realmente estar localizada em um ponto muito afastado. 
2. O sintoma pode desaparecer (temporariamente) quando outro erro for 
corrigido.
3. O sintoma pode ser causado por erro humano que não é facilmente ras-
treável.
4. O sintoma pode ser um resultado de problemas de temporização, e não 
de problemas de processamento. Pode ser difícil reproduzir com precisão as 
condições de entrada.
[...]
7. O sintoma pode ser intermitente. Isso é particularmente comum em siste-
mas embutidos que acoplam hardware e software inextricavelmente.
8. O sintoma pode ocorrer devido a causas distribuídas por várias tarefas, 
executando em diferentes processadores.
Fonte: Pressman (2011, p. 490).
©shutterstock
Asserções e Programação Defensiva
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
109
ASSERÇÕES E PROGRAMAÇÃO DEFENSIVA
Para Tsui e Karam (2013, p. 140), “uma técnica 
muito útil consiste na utilização de asserções, 
o que está relacionado aos conceitos mais 
formais de precondições e pós-condições”. 
As técnicas assertivas são validações lógicas 
de uma condição que é julgada necessária 
para o correto funcionamento do código no 
momento em que elas são verificadas. Mas 
o que isso significa? Quando a validação de 
alguma condição é testada pela técnica asser-
tiva, significa que uma condição assumida 
instrui o sistema a notificar sempre que essa condição não for satisfeita, sempre 
mostrando e garantindo que não haja um comportamento imprevisto.
Falamos em pre - condições e pós-condições. O que significam? Precondição 
é uma condição em que seu módulo solicita condições de produzir resultados 
corretos e uma pós-condição é uma condição que deve se manter após a valida-
ção do seu código e que a precondição tenha sido atendida. 
Conforme Tsui e Karam (2013, p. 140), as precondições e as pós-condições 
podem ser utilizadas com métodos formais também, onde se pode provar que 
um código sempre funciona efetivamente e de forma correta sempre atento para 
a finalidade na qual as assertivas se propõem e, assim, evitar que sejam usadas 
erroneamente.
A prática de programação defensiva é muito usada e instrui o 
código fonte a identificar falhas e comportamentos que não foram ori-
ginalmente previstos e, assim, detectar bugs em seus estágios iniciais. 
Essa prática é muito utilizada para validar as entradas de métodos/rotinas, e sua 
proposta é validar condições consideradas obrigatórias e que, quando não satis-
feitas, identificam uma falha ou erro no sistema.
©shutterstock
IMPLEMENTAÇÃO DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIIU N I D A D E110
OTIMIZAÇÃO DE DESEMPENHO
Segundo Tsui e Karam (2013, p. 140) “o desempenho é um aspecto importante 
de praticamente qualquer programa, mas temos que entender as contraparti-
das. A otimização para o desempenho 
geralmente (mas nem sempre) piora a 
mantenabilidade e a legibilidade”. 
Mas devemos sempre pensar em 
exatidão, que é mais importante do que 
desempenho quando se está escrevendo 
um código. Mas toda regra tem as suas 
exceções e, neste caso, em sistemas de 
tempo real, o desempenho de uma ação 
dentro de um limite de tempo faz parte 
da exatidão. Vocês devem estar se per-
guntando: Por que otimizar o código? 
Porque temos muitos sistemas de tempo real que são usados em mercados, são 
altamente sensíveis a custos, seu consumo de energia deve ser minimizado, em 
muitos casos o espaço físico é restrito. 
Técnicas de programação defensiva são mecanismos preventivos contra 
a ocorrência de falhas de hardware ou de software. Para a verificação da 
segurança de sistemas de aplicações críticas, técnicas de injeção de falhas 
foram desenvolvidas, propiciando o teste dos mecanismos de tolerância a 
falhas em condições muito semelhantes às do ambiente operacional real. 
A introdução de técnicas de programação defensiva aumenta a segurança 
dos sistemas de aplicações críticas. Não há, na literatura pesquisada, qual-
quer referência a uma avaliação quantitativa das técnicas de programação 
defensiva. Esta tese é a descrição de um trabalho experimental, que visa esta 
avaliação quantitativa, e se organiza em algumas etapas. Primeiro, algumas 
técnicas de programação defensiva são apresentadas, caracterizadas e elei-
tas como objeto de avaliação. 
Fonte: Secall (2007).
Otimização de Desempenho
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
111
Conforme Tsui e Karam (2013, p. 141), o erro mais comum que um pro-
gramador pode cometer é se preocupar no início com o desempenho do código 
e não lembrar que o primeiro objetivo ao escrever o programa, é que ele esteja 
correto e que seja de fácil manutenção e que após ele estiver pronto, será o 
momento de se preocupar com o desempenho, caso este não esteja satisfatório. 
Em alguns casos, somente algumas partes de um código que podem vir a cau-
sar lentidão e que precisam passar por otimização de desempenho, em outros 
casos, partes de um programa podem vir a serem executados somente algumas 
vezes e que não causaram impacto no desempenho. 
Assim como em qualquer outra atividade no desenvolvimento de um software, 
devemos fazer uma análise antes de ser efetuada qualquer otimização de desem-
penho no código, porque, às vezes, não se tem tempo no cronograma do projeto 
e o tempo de trabalho de um programador é muito caro, que compensa deixar o 
programa como está e simplesmente comprar um novo hardware mais apropriado. 
Existem algumas ferramentas que podem ser utilizadas para a otimização 
de desempenho, como o Profiler, um traçador de perfil que roda o programa e 
calcula quanto tempo ele gasta em cada parte do código e com isso facilitar a 
procura de gargalos de desempenhos em módulos que precisam ser otimizados. 
Sobre a otimização, Tsui e Karam (2013, p. 141) afirma que
Em algunscasos, um mau desempenho é um sintoma de um design 
ou codificação deficiente, e tornar o código mais simples e mais fácil 
também resultará em um melhor desempenho. Em muitos casos, deve 
ser possível modularizar o código de modo que as otimizações de de-
sempenho fiquem ocultas em locais bem específicos e que a maior par-
te do código esteja clara. Um bom compilador de otimização também 
pode encarregar-se de muitas otimizações de desempenho sem que o 
programador sacrifique a clareza.
Para isso, adotar boas práticas de programação e usar algumas escolhas crite-
riosas de design, ajuda de forma significativa o desenvolvimento de um código 
correto, rápido e de fácil manutenção. Uma das melhores práticas seria reutili-
zar o máximo possível de código de alta qualidade já existente e se utilizar das 
bibliotecas padrão inclusas em seu compilador. Segundo Tsui e Karam (2013, 
p. 141), procure conhecer e utilizar bem sua biblioteca para desenvolver códigos 
de alta qualidade em vez de reimplementá-lo em um novo código. 
©shutterstock
IMPLEMENTAÇÃO DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIIU N I D A D E112
REFATORAÇÃO
Segundo Tsui e Karam (2013, p. 141), “mesmo quando se utiliza as melhores 
práticas e se faz um esforço consciente para produzir softwares de alta quali-
dade, é altamente improvável que se produza consistentemente programas que 
não possam ser melhorados”.
Refatoração é a mudança de um código 
fonte, na estrutura interna do software 
visando melhorar o entendimento e a manu-
tenibilidade sem alterar seu comportamento 
e suas funções externas. A refatoração surgiu 
quando alguns desenvolvedores foram anali-
sar seus códigos para alterar ou incluir novas 
funcionalidades, eles começaram a verifi-
car que os códigos já existentes estavam em 
grande parte desestruturados, trechos repe-
tidos e de difícil compreensão e manutenção. 
Conforme Tsui e Karam a respeito da refatoração, 
Martin Fowler (1999) popularizou o termo refatoração para referir-se à 
atividade de aprimoramento de seu estilo de código sem alterar o seu 
comportamento. Ele também utiliza este termo para cada uma das mu-
danças individuais que você pode efetuar para melhorar a estrutura de 
seu código. Fowler define um catálogo de sintomas indicando que o seu 
código precisa de refatoração (o que ele chama de “maus cheiros”) e 
fornece um catálogo de refatoração úteis (TSUI; KARAM, 2013, p. 141).
A refatoração é considerada uma das técnicas mais poderosa para a produção 
de um bom código. Tsui e Karam (2013, p. 141) citam o catálogo de “maus chei-
ros” fornecido por Fowler:
 ■ Código duplicado mostrando desperdício.
 ■ Método longo.
 ■ Classe grande.
Refatoração
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
113
 ■ Instruções switch (em linguagens OO, podem ser substituídas por poli-
morfismo, assim o código fica mais claro).
 ■ Inveja da funcionalidade, quando um método tende a utilizar mais de um 
objeto de uma classe diferente a aquele que pertence.
 ■ Intimidade inapropriada, na qual uma classe refere-se a partes privadas 
de outras classes.
Para Tsui e Karam (2013, p. 142), “qualquer um destes sintomas, bem como os 
outros que Fowler cita e aqueles que você desenvolverá, indicará que seu código 
pode ser melhorado. Você pode utilizar refatoração para ajudá-lo a lidar com 
estes problemas”. 
Apesar de trazer benefício para um código fonte existente, a refatoração pode 
apresentar riscos se aplicada da forma errada, tais como: atraso do projeto, intro-
dução de falhas no sistema, tornar o código ilegível e não modificável, portanto, 
é uma mudança que deve ser efetuada com cuidado.
Quando os desenvolvedores começaram a analisar seus códigos para in-
cluírem novas funcionalidades ou modificarem as já existentes, eles obser-
varam que os códigos estavam em sua maioria desestruturados, de difícil 
compreensão, manutenção e com trechos duplicados. A refatoração surgiu 
por meio dessa observação. Algumas pessoas pensam que Refatoração é 
apenas uma limpeza de código, mas ela vai, além disso, porque fornece 
técnicas específicas para cada tipo de alteração. Então se forem usadas da 
forma correta deixa-o menos propenso a erros. Refatoração é a alteração de 
um código fonte, visando melhorar o entendimento e a manutenibilidade 
sem alterar suas funções externas. Apesar de trazer benefícios para um códi-
go fonte existente, a refatoração pode apresentar riscos se não aplicada da 
forma correta, tais como: atraso do projeto, introdução de falhas no sistema, 
tornar o código ilegível e não modificável.
Fonte: Barrozo, Vinhas e Reis (2013). 
IMPLEMENTAÇÃO DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIIU N I D A D E114
CONSIDERAÇÕES FINAIS
Nesta unidade, analisamos a importância da fase de implementação dentro do 
processo de desenvolvimento de software. Vimos algumas características de uma 
boa implementação, como: legibilidade, mantenabilidade, desempenho, rastreabi-
lidade, exatidão e integridade. Foram apresentados aspectos sobre a codificação, 
como atribuir nomes de variáveis, comentários e vários outros itens importan-
tes de uma boa implementação. 
Aprendemos que na fase de implementação temos algumas atividades adi-
cionais que podem ser desenvolvidas para melhorar a qualidade do código e 
corrigir erros, como depuração, otimização de desempenho e refatoração. 
Ao longo da unidade, aprendemos que a implementação é a fase mais crítica 
do processo de desenvolvimento do software, pois criamos a versão executável do 
software e convertemos a especificação do sistema em um sistema executável. A 
fase da implementação é a escrita do sistema em uma linguagem de programação 
pelo programador. A Implementação, atualmente, pode utilizar linguagens de 
programação visuais e orientadas a objeto, com ambientes de desenvolvimento 
fáceis e amigáveis para o desenvolvimento dos códigos.
Vimos que não basta saber programar em uma linguagem de programação 
para implementar um software, é necessário, também, conhecer e aplicar boas 
práticas de programação e usar ferramentas disponíveis para tornar esta fase mais 
eficiente e eficaz. Aprendemos como ocorre a codificação/programação dos requi-
sitos de software, baseado nas definições técnicas analisadas na fase de projeto. 
Depois desta fase, com o conhecimento que já adquirimos de projeto e 
implementação, podemos passar para a próxima unidade e nos aprofundamos 
nos conceitos de teste de software, para juntos chegarmos ao final das fases que 
envolvem um processo de software e obtermos um sistema eficiente e com qua-
lidade. Preparados? Então, continue sua leitura!
115 
1. Na fase de implementação, quais as atividades que são desenvolvidas? Assinale 
a alternativa correta.
a. Codificação, depuração, compilação, integração e expressão.
b. Codificação, depuração, fatoração, integração e testes.
c. Codificação, depuração, compilação, integração e testes.
d. Codificação, degustação, compilação, integração e testes.
e. Codificação, depuração, compilação, concretização e testes.
2. Na fase de implementação desenvolvemos algumas tarefas que são utilizadas 
para iteração, revisões, integração, entre outras. 
I. Planejamento detalhado da implementação das unidades de cada iteração.
II. Implementação das classes e outros elementos do modelo de projeto, geral-
mente arquivos de código fonte.
III. Verificação das unidades, por meio de revisões, inspeções e testes de unidade. 
IV. Compilação, ligação das unidades e integração das unidades entre si e com 
componentes reutilizados.
V. Abstração, refinamento, arquitetura, hierarquia de funções das unidades de 
cada interação. 
Assinale a opção com a sequência CORRETA.
a. Somente a questão III está correta.
b. Somente as questões I e II estão corretas.
c. Somente as questões I, II, IIIe IV estão corretas. 
d. Todas estão corretas. 
3. Quais as características que devem ser encontradas em uma boa implementa-
ção? Assinale a alternativa correta.
a. Legibilidade, Mantenabilidade, Desempenho, Rastreabilidade, Classificação e 
Integridade. 
b. Legibilidade, Mantenabilidade, Integração, Rastreabilidade, Exatidão e Integri-
dade. 
c. Legibilidade, Manutenção, Desempenho, Rastreabilidade, Exatidão e Integri-
dade. 
d. Facilidade, Mantenabilidade, Desempenho, Rastreabilidade, Exatidão e Inte-
gridade. 
116 
4. Complete as lacunas no texto abaixo:
_______________________ é considerado um processo usado para reduzir ou 
__________________ no seu sistema. De uma forma geral, _________________ 
o código não é uma tarefa fácil de ser executada. Um dos motivos, é que podem 
ocorrer muitas _____________ que podem vir a atrapalhar esse processo, um 
exemplo é a linguagem que está sendo utiliza e ferramentas disponíveis para 
fazermos a ______________ de um código. 
5. A refatoração é considerada uma das técnicas mais poderosas para a produção 
de um bom código. Tsui e Karam (2013, p. 141) citam o catálogo de “maus chei-
ros” fornecido por Fowler. 
I. Código duplicado mostrando desperdício, método longo, classe grande, Ins-
truções switch.
II. Inveja dos funcionários e dos programadores do código.
III. Intimidade inapropriada, na qual uma classe refere-se a partes privadas de ou-
tras classes.
IV. Decisões de como o sistema irá se comportar, em termos de: estrutura de ca-
bos, hardware, infraestrutura de telefonia, a interface.
V. Inveja da funcionalidade, quando um método tende a utilizar mais de um ob-
jeto de uma classe diferente a aquele que pertence.
Assinale a opção com a sequência CORRETA.
a. Somente a questão III está correta.
b. Somente as questões I, II e IV estão corretas.
c. Somente as questões I, II, III e IV estão corretas. 
d. Todas estão corretas. 
117 
REFATORAÇÃO DE APLICAÇÕES WEB: UM ESTUDO DE CASO
Jean Carlos Dalcero, Bruno Batista Boniati
1. Introdução
Com a evolução da Internet, a importância e demanda das aplicações Web aumentou 
muito, em especial nos últimos anos. Os sistemas defasados ou não planejados podem 
possuir inúmeras falhas e limitações. Porém, essas características podem ser melhoradas 
por meio de técnicas e normas padronizadas que surgiram para o melhoramento dessas 
aplicações, fazendo com que os sistemas possam ser desenvolvidos com facilidade no 
entendimento e inclusão de novas funcionalidades por parte dos desenvolvedores (...).
2. Refatoração
O conceito de refatoração vem originalmente da comunidade de programação orienta-
da a objetos, datando do início dos anos 90, mas sendo popularizada por Martin Fowler 
em 1999 com o livro “Refactoring” (Addison-Wesley, 1999). Fowler (1999) define refatora-
ção como o processo de aperfeiçoamento do código-fonte de um sistema de software, 
tornando-o mais bem entendido, menos custoso na modificação e sem mudanças no 
comportamento externo (...).
Baseando-se nesses conceitos pode-se dizer que refatoração é o emprego de técnicas 
para melhorar o projeto do software auxiliando na reestruturação do código fonte, vi-
sando promover atributos não funcionais de software, tais como extensibilidade, modu-
laridade, reusabilidade, complexidade e eficiência.
3. Refatoração para Aplicações Web
Técnicas de refatoração são amplamente utilizadas em linguagens de programação 
como Java e C. Porém, não é só código orientado a objetos ou linguagens orientadas 
a objetos que podem produzir código ruim e com necessidade de refatoração. Pode-se 
dizer que não somente linguagens de programação, mas qualquer sistema suficiente-
mente complexo e mantido ao longo do tempo pode se beneficiar de refatoração.
Em um sistema Web, o lado servidor de uma grande aplicação distribuída, funciona 
geralmente sobre uma base de dados relacional, enquanto que o lado cliente é uma 
ou mais páginas web, quase sempre construídas com códigos HTML (HyperText Markup 
Language), CSS (Cascading Style Sheets) e JavaScript. O HTML tornou o desenvolvimento 
dessas aplicações mais rápidas, mas não as tornou mais fáceis, mais simples ou menos 
complexas (...).
118 
3.1. Validade
A validade garante que somente elementos e atributos especificados no HTML apare-
çam, mostrando o mesmo conteúdo para usuários de diversos navegadores. Para Harold 
(2010), adicionar atributos alt em imagens é uma técnica de refatoração essencial, uma 
vez que dá assistência para usuários com deficiências de visão à medida que navegado-
res de áudio vierem embarcados em celulares, carros e outros dispositivos direcionados 
a esse público.
3.2. Leiaute
Harold (2010) cita que usar a semântica adequada para cada elemento torna as páginas 
inteligíveis para leitores de tela e faz com que sejam mostradas apropriadamente para 
diferentes plataformas. Muitos elementos, como o table são usados abusivamente para 
tornar as páginas com aparência agradável. Atualmente, tem-se trabalhado bastante 
com o desenvolvimento de páginas Web utilizando o conceito “tableless”, ou seja, sem 
tabelas. O padrão de desenvolvimento com o CSS e tags div permite a separação da 
camada de apresentação, tornando a manutenção das páginas mais fácil, dentre outros 
benefícios.
3.3. Acessibilidade
A web tem o poder de integrar à sociedade as pessoas com necessidades especiais. As 
páginas Web devem ser projetadas de modo que não precisem saber qual o tipo de 
dispositivo o usuário está utilizando, seja ele um monitor de vídeo ou um leitor de tela. 
Harold (2010) lembra que os usuários com limitações visuais que utilizam leitores de 
tela não podem usar o leiaute visual de uma página para determinar quais rótulos estão 
associados a quais campos. É preciso rotular, deixar explícito cada um dos campos não 
ocultos, de forma que eles sejam facilmente identificados pelos dispositivos. Para cada 
elemento visível do tipo input, textarea ou select, deve existir ao menos um elemento do 
tipo label associado.
119 
3.4. Aplicações Web
Atualmente, muitos sites não são mais apenas estáticos, são aplicações completas para 
entrada de dados, processamento de texto, jogos e muito mais. Com a evolução das 
aplicações vem também a necessidade de tornar as páginas mais rápidas e seguras, de 
modo que o usuário passe a utilizar essas ferramentas sem medo de que seus dados 
sejam expostos e que o sistema suporte toda a demanda requerida.
Um exemplo de refatoração é a substituição de requisições GET inseguras por POST. 
As requisições GET utilizam a própria URL para enviar os dados para o servidor, essas 
requisições podem ser navegadas por robôs, pré-carregadas, armazenadas em cache, 
repetidas ou acessadas automaticamente. Operações inseguras como, por exemplo, ca-
dastrar, alterar ou excluir um cliente, devem ser realizadas apenas via POST, evitando 
que os dados sejam manipulados sem o consentimento do usuário (...).
Na questão segurança, usar sequência de escape para as entradas de usuário é funda-
mental. Atualmente, a fonte mais comum de falhas de segurança na Web é a injeção 
de código SQL (Structured Query Language). Harold (2010) cita que é provavelmente 
mais fácil encontrar um site baseado em banco de dados com uma vulnerabilidade de 
injeção de código SQL que um site que não possua uma. Harold (2010) ainda diz que a 
injeção de código SQL tem levado ao roubo de dados confidenciais de clientes, fraudes 
de cartão de crédito, phishing, spams e a quase todos os outros tipos de crimes auxilia-
dos por computador que possamos imaginar (...).
Fonte: Dalcero e Boniati (2014).
MATERIAL COMPLEMENTAR
Fábrica de Software - Implantação e Gestão de Operações
Aguinaldo Aragon Fernandes e Descartes de Souza Teixeira
Editora: Atlas
Sinopse: Este livro ensina como projetar, implantar e contratar 
uma fábrica de software, bem como estruturar uma plataforma de 
off shore de desenvolvimento de software. Trata-se de uma obra de 
referência para todos os que queiram entender melhor os aspectosque contornam uma operação de desenvolvimento de software em 
larga escala. A experiência vivida pelos autores e o conhecimento que 
trazem sobre tecnologia da informação representam inestimáveis 
fontes de informação para toda a comunidade brasileira da área.
Padrões de Programação - Para Fábrica de Software, 
Analistas e Programadores
Cláudio Rodrigues
Editora: Ciência moderna
Sinopse: Essencial para profi ssionais e estudantes de programação, 
“Padrões de Programação” traz os conhecimentos básicos para o 
desenvolvimento de softwares simples, baseando-se nos padrões 
de programação em questão. São apresentados os padrões, e como 
eles ajudam a projetar um software. O autor mostra também como 
aplicar cada um dos padrões, baseando-se em exemplos práticos e 
de fácil entendimento.
Material Complementar
MATERIAL COMPLEMENTAR
Refatoração para Padrões
Joshua Kerievsky
Editora: Bookman
Sinopse: Este livro mostra a conexão entre padrões de projeto e 
refatoração, uma das práticas-chave de programação eXtrema (XP). 
Adotando padrões ao estilo do livro clássico de Gamma e cols, Padrões 
de Projeto, e usando código do mundo real, Kerievsky documenta o 
raciocínio e os passos que fazem parte de muitas das transformações 
de projeto baseadas em padrões. Inclui maneiras práticas de começar a 
trabalhar, de grande valor até para iniciantes em padrões ou refatoração. 
Não perca tempo escrevendo código perfeito
Este artigo mostra que precisamos escrever bons códigos: código que seja compreensível, correto 
e seguro. Precisamos refatorá-lo, revisá-lo e escrever bons testes, sabendo o tempo todo que 
alguns trechos desse código, ou talvez todo o código, poderão ser jogados fora em breve. Temos 
que reconhecer que alguns dos nossos trabalhos serão necessariamente desperdiçados e otimizar 
nosso tempo pensando nisso. Faça o que precisa ser feito e nada mais. Não perca tempo tentando 
escrever o código perfeito. Confi ram. Ótima leitura! 
Acesse o site e leia o artigo na íntegra.
Disponível em: <http://imasters.com.br/desenvolvimento/
nao-perca-tempo-escrevendo-codigo-perfeito/?trace=1519021197&source=single/>.
Não “otimize” seu código
Este artigo mostra de forma divertida, o porquê não devemos otimizar o código. Será? Mas aí 
podemos pensar: como é cruel quando um software é lento. Acredito que todos vocês, pelo 
menos alguma vez, já se irritaram com um software lento em algum estabelecimento. O que pode 
passar despercebido é que, além da irritação, a lentidão pode causar outros impactos, até mesmo 
na sociedade! Leia este artigo e dê a sua opinião. Boa leitura. Acesse o site abaixo e leia o artigo 
completo.
Disponível em: <http://tableless.com.br/nao-otimize-seu-codigo/>.
MATERIAL COMPLEMENTAR
Como ser um bom programador
O artigo mostra algumas dicas de como ser um bom programador. O autor mostra algumas 
qualidades e alguns esforços que fazem a diferença entre um bom programador e um 
programador mediano. Vale a pena ler
Leia o artigo na íntegra acessando o site abaixo. Boa leitura!
Disponível em: <http://www.linhadecodigo.com.br/artigo/1153/como-ser-um-bom-programador.
aspx#ixzz3xhlT8GuP>.
Dicas para programar melhor
Artigo muito interessante com dicas, seja para uma linguagem específica, seja para a área da 
programação. Não são dicas para todas as linguagens, entretanto, algumas por serem genéricas, 
podem ser fornecidas e servem como base para toda a área e não somente para esta ou aquela 
linguagem. É disto que este artigo trata: dicas de como programar melhor. Vamos lá? Leia o artigo 
completo acessando o site abaixo e veja o que o autor explica sobre este assunto. Muito legal. Boa 
leitura! 
Disponível em: <http://imasters.com.br/artigo/6980/linguagens/dicas-para-programar-melhor/>.
Não se repita? DRY e o dilema entre código duplicado e alto acoplamento
Artigo muito interessante sobre o princípio do não se repita. O princípio DRY (“não se repita”) 
busca reduzir a duplicação de código e os problemas de manutenção resultantes, mas quando 
é mal aplicado aumenta o acoplamento e atrapalha a leitura do código. Conheça a opinião de 
vários especialistas sobre o princípio, suas aplicações e armadilhas. Artigo muito interessante, leia 
na íntegra acessando o site abaixo. 
Disponível em: <http://www.infoq.com/br/news/2012/07/DRY-acoplamento-duplicacao>.
Programe defensivamente com asserções
Artigo sobre como se programar defensivamente com asserções e como utilizá-las. O autor faz 
uma comparação ao trânsito e como é dirigir defensivamente, isto é, se prevenir dos problemas 
antes que eles aconteçam, evitando situações que coloquem em risco você ou os demais. Muito 
interessante. 
Acesse o site e leia o artigo na íntegra.
Disponível em: <https://pythonhelp.wordpress.com/2012/09/09/
programe-defensivamente-com-assercoes/>.
REFERÊNCIAS
123
BARROZO, G. C.; VINHAS, H. M.; REIS, J. C. de S. Refatoração: Aperfeiçoando Um Có-
digo Existente. Alfenas: UNIFENAS, 2013.
BECK, K. Padrões de Implementação, Porto Alegre: Bookman, 2013.
DALCERO, J. C.; BONIATI, B. B. Refatoração de Aplicações Web: Um Estudo de Caso. 
Anais do EATI: Encontro Anual de Tecnologia da Informação. Frederico Westpha-
len: 2014, p. 334-337. 
PRESSMAN, R. Engenharia de Software. 7. ed. Porto Alegre: AMGH, 2011.
SANTOS NETO, P. de A. dos. Modulo IV - Introdução à Engenharia de Software. 
Teresina: Universidade federal do Piauí, 2007.
SECALL, J. M. Avaliação comparativa do impacto do emprego de técnicas de 
programação defensiva na segurança de sistemas críticos. São Paulo: Escola Po-
litécnica, 2007.
SOMMERVILLE, I. Engenharia de Software, São Paulo: Pearson Prentice Hall, 2011. 
TSUI, F. KARAM, O. Fundamentos de engenharia de software, 2 ed. Rio de Janeiro: 
LTC, 2013.
VALENTIN, L. G.; DIAS, M. M.; PACHECO R. C. S. Questões importantes na implementa-
ção de software. Revista Tecnológica. v. 17, 2008, p. 73-80. Disponível em: <http://
periodicos.uem.br/ojs/index.php /RevTecnol/article/download/7985/5161>.Acesso 
em: 25 mar. 2016. 
GABARITO
1. C - Codificação, depuração, compilação, integração e testes.
2. C - Somente as questões I, II, III e IV estão corretas. 
3. C - Legibilidade, Manutenção, Desempenho, Rastreabilidade, Exatidão e Integri-
dade. 
4. Depurar é considerado um processo usado para reduzir ou encontrar bugs no 
seu sistema. De uma forma geral, depurar o código não é uma tarefa fácil de ser 
executada. Um dos motivos, é que pode ocorrer muitas variações que podem vir 
a atrapalhar esse processo, um exemplo é a linguagem que está sendo utilizada 
e ferramentas disponíveis para fazermos a depuração de um código. 
5. B - Somente as questões I, II e IV estão corretas.
U
N
ID
A
D
E IV
Professora Esp. Janaína Aparecida de Freitas
TESTE DE SOFTWARE
Objetivos de Aprendizagem
 ■ Definir Teste de software, seus objetivos e seus conceitos.
 ■ Estudar os conceitos sobre defeitos e níveis de teste de software.
 ■ Apresentar a documentação usada nos testes de software e suas 
técnicas.
Plano de Estudo
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
 ■ Introdução ao Teste de Software
 ■ Conceitos básicos de Teste de Software
 ■ Ciclo de Vida do Teste de Software
 ■ Técnicas de Teste de Software
 ■ Papéis e Cargos de Teste de software
 ■ Ambiente de teste
INTRODUÇÃO
Olá Aluno (a)! Vamos para mais uma unidade de estudos? Avançando em nosso 
aprendizado sobre as fases do processo de desenvolvimento de software, vamos 
estudar a fase de Teste de Software e entender porque ela é importante e essen-
cial para garantir a qualidade do software. 
Nesta unidade, vamos aprender que o principal objetivo do teste de software 
é auxiliar na busca de um produto de software com o mínimo de erros possíveis. 
Para realizarmos esta tarefa, faz-se necessário o uso de ferramentas que auxiliem 
no processo de teste de software. 
Mas você, aluno(a), deve se perguntar: por que se faz necessário testes em 
software? Imagino que você tenha acesso a diferentes softwares diariamente, 
por exemplo,aplicações bancárias, sejam elas acessadas pela web, celular ou 
caixa eletrônico, entre outras. Você poderia imaginar o desastre se essas aplica-
ções não fossem muito bem testadas? Você se sentiria seguro em realizar uma 
transação bancária pela web? Acho que não, certo? Esses exemplos servem para 
mostrar que softwares que não funcionam corretamente e que não foram tes-
tados podem trazer diversos prejuízos e grandes impactos para as pessoas e 
empresas que os utilizam. 
Mas vamos pensar, falhas podem ocorrer, certo? E, neste caso, temos vários 
tipos de falhas, por eventos externos ao software, como quedas de luz, radiação, 
calor, poluição, campos magnéticos ou eletrônicos e muitos outros. Por outro 
lado, algumas causas dos problemas de software que são encontrados podem ser 
causadas por erros ou enganos humanos. Esse erro gera um defeito (bug) no sof-
tware, e o bug gera uma falha no sistema.
Vamos aprender nesta unidade também, que os testes têm funções especí-
ficas em cada fase do desenvolvimento do software. Além disso, servem para 
reduzir os riscos de ocorrências de problemas e erros no ambiente do usuário e 
isso pode representar a confiabilidade do software. Boa leitura!
Introdução
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
127
©shutterstock
TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IVU N I D A D E128
INTRODUÇÃO AO TESTE DE SOFTWARE
O teste é uma atividade de verificação e validação do software e consiste na aná-
lise dinâmica, isto é, na execução do produto de software com o objetivo de 
verificar a presença de defeitos no produto e aumentar a confiança de que está 
correto.
Hoje existe uma crescente preocupação pela necessidade de melhoria do sof-
tware, percebida pelas próprias empresas, seja por exigência do mercado ou pelos 
clientes, como você, que utilizam esses softwares. Uma das formas das empre-
sas melhorarem a qualidade do software por elas desenvolvido é por meio da 
implantação equipes de testes, cujo o objetivo é testar os sistemas produzidos e 
atingir um nível de qualidade aceitável e em um espaço de tempo cada vez menor. 
Entretanto, quando uma empresa desenvolvedora de software busca garantir 
a qualidade, ela percebe que é necessário investir pesado em testes de software. 
Levando em conta que existem vários tipos de testes no mercado para aten-
der as suas necessidades, a empresa deve levar em conta que pode ser preciso 
implantar mais de um tipo ou investir em métricas de software para garantia da 
qualidade desses testes. 
1. Planejamento
2. Preparação
3. Especificação
4. Execução
5. Entrega
Introdução ao Teste de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
129
Para Sommerville (2011, p. 144), “o teste é destinado a mostrar que um 
programa faz o que é proposto a fazer e para descobrir os defeitos do programa 
antes do uso”. Conforme Sommerville, quando se testa o software, devemos exe-
cutar o programa e incluir dados fictícios (simular como se fosse um usuário) e 
os resultados do teste são utilizados para procurar erros, anomalias ou se algum 
atributo não estiver funcionando adequadamente. 
Segundo Pressman (2011, p. 427), “uma vez gerado o código fonte, o sof-
tware deve ser testado para descobrir (e corrigir) tantos erros quanto possível 
antes de fornecê-lo ao seu cliente”.
Mas você deve estar se perguntando: Por que testar? Quando é preciso tes-
tar? Como testar? E quando os testes devem começar?
Para responder a estas dúvidas, vamos ver o que pensa Tsui e Karam (2013, 
p. 147). Os autores afirmam que os testes de software geralmente possuem dois 
objetivos principais:
 ■ Os testes devem encontrar defeitos no software, para que eles possam ser 
corrigidos ou minimizados.
 ■ Os testes fornecem uma avaliação geral de qualidade e uma estimativa 
das possíveis falhas. 
Para Tsui e Karam (2013), exceto os programas mais simples, os testes de sof-
tware não podem provar que um produto funciona e sim que ele pode apenas 
encontrar defeitos e que ele funciona para as situações em que foi testado, mas 
sem garantir seu funcionamento em outras situações que não foram testadas. 
Mas se os testes não foram executados de forma correta? Nesse caso, pode for-
necer alguma garantia de que o software irá funcionar para as situações semelhantes 
às dos testes, não temos, porém, como provar que o software irá funcionar para 
todos os casos. Vale ressaltar que, mesmo se um teste não detectar defeitos, isso 
não quer dizer necessariamente que o produto não é um produto de boa qualidade. 
Muitas vezes, a atividade de teste empregada pode ter sido conduzida sem 
planejamento, sem critérios e sem uma sistemática bem definida, sendo, por-
tanto, os testes de baixa qualidade. Ainda que os testes não possam demonstrar a 
ausência de defeitos, como benefício secundário, podem indicar que as funções 
do software parecem estar funcionando de acordo com o especificado.
TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IVU N I D A D E130
Passamos agora a conhecer algumas definições de teste:
 ■ Testar é verificar se o software está fazendo o que deveria fazer, de acordo 
com seus requisitos, e não está fazendo o que não deveria fazer (RIOS; 
MOREIRA, 2013).
 ■ Testar é o processo de executar um programa ou sistema com a intenção 
de encontrar defeitos (teste negativo) (MYERS, 1979).
 ■ Testar é qualquer atividade que a partir da avaliação de um atributo ou 
capacidade de um programa ou sistema, seja possível determinar se ele 
alcança os resultados desejados (HETZEL, 1998). 
De acordo com Pressman (2011), todo software que se destina ao público e/ou 
ao mercado deve sofrer um nível mínimo de teste. Assim, quanto maior o nível 
de complexidade do software, mais testes e técnicas de testes se tornam neces-
sários para a obtenção da sua qualidade.
Segundo Tsui e Karam (2013, p. 147), “os testes de software consistem na veri-
ficação dinâmica do comportamento de um programa com base em um conjunto 
finito de situações de teste, selecionado de forma apropriada a partir do habitual-
mente infinito domínio de execuções, em relação ao comportamento esperado”. 
Mas como toda atividade complexa que possui muitas ações, o teste deve ser 
planejado, ter seus objetivos determinados, a definição de quais metodologias e 
técnicas devem ser aplicadas, e de quais recursos e ferramentas devem ser utili-
zados para executar os testes. 
“Um testador bem treinado, com experiência prática e com o espírito aberto 
para novos aprendizados dificilmente será derrotado.” 
(Rios).
Introdução ao Teste de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
131
Portanto, teste é um conjunto de atividades que podem ser planejadas com 
antecedência e executadas sistematicamente. Por essa razão, deverá ser definido 
para o processo de software um modelo, que pode ser chamado de template para 
o teste. Nesse template criamos um conjunto de etapas no qual pode-se colocar 
técnicas específicas de caso de teste e métodos de teste.
Para Sommerville (2011, p. 144), o processo de teste apresenta dois objeti-
vos distintos:
1. Demonstrar ao desenvolvedor e ao cliente que o software atende seus 
requisitos. 
2. Descobrir situações em que o software se comporta de maneira incorreta, 
indesejável ou de forma diferente do que foi especificado. 
No próximo tópico, vamos conhecer os conceitos básicos utilizados na fase de 
teste de software. Boa leitura!
O teste, da maneira como é executado pela maioria das empresas – como 
uma etapa dentro do processo de desenvolvimento e, em geral, executado 
pelos próprios desenvolvedores e pelos usuáriosdo sistema, serve apenas 
para garantir que as especificações ou os requisitos do negócio foram de 
fato implementados. Como o processo de desenvolvimento cria produtos 
com defeitos, necessário se faz descobrir esses defeitos. Em um modelo de 
garantia de qualidade, isso é suficiente. Quem poderia garantir que um sof-
tware testado pelos próprios desenvolvedores está corretamente testado? 
Com toda a certeza, existem exceções, mas a melhor maneira de testar um 
software é ter um processo de teste claramente definido. Os defeitos exis-
tentes nos softwares, na maior parte das vezes, constituem-se em riscos tan-
to para o negócio, quanto para a imagem da empresa.
Fonte: Bastos, Rios, Cristalli e Morreira (2007). 
©shutterstock
TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IVU N I D A D E132
CONCEITOS BÁSICOS DE TESTE DE SOFTWARE
Alguns conceitos que envolvem testes de software devem ser entendidos para 
facilitar o entendimento desse processo. Conforme Bastos et al. (2007, p. 283), 
“Erro: resultado de uma falha humana. Defeito: resultado de um erro existente 
num código ou num documento”. 
Conforme a terminologia padrão para Engenharia de Software do Institute 
of Electrical and Electronics Engineers (IEEE), defeitos são considerados 
parte do universo físico, provocados por pessoas e que podem levar a ocasionar 
erros em um software, fazendo com que ele fique diferente do que foi especifi-
cado. Resumindo, os erros provocam e geram falhas no sistema, e estas causam 
um comportamento que não se esperava e que pode afetar e inviabilizar a utili-
zação de um software. 
Para alguns autores, o conceito de defeito é: 
“É uma não conformidade em relação ao que o software se propõe a 
fazer, que diz que faz e não faz” (MOLINARI, 2003).
“Resultado de um erro existe num código ou num documento” (BAS-
TOS et al., 2007). 
Conceitos Básicos de Teste de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
133
Quando executamos testes em um software, podemos demonstrar a presença 
de defeitos, mas não podemos provar que eles não existem. Você concorda com 
isso? Os testes quando executados, reduzem a probabilidade dos defeitos ocor-
rerem em um sistema, mas não garante que ele esteja perfeito e livre de defeitos.
Para Bastos et al. (2007), os defeitos são resultados de erros existentes no 
software desenvolvido por pessoas. Segundo ele, devemos ter por base os seguin-
tes princípios:
 ■ O objetivo primordial é evitar defeitos. Ao testarmos os requisitos, estamos 
tentando evitar que defeitos ocorram em outras fases do desenvolvimento 
do software.
 ■ Evitar defeitos é minimizar os riscos, não só os do projeto de desenvolvi-
mento do software como também os do projeto de teste. 
 ■ Integração com os desenvolvedores, para que as duas equipes atuem em 
conjunto e harmonia.
Para entendermos bem os defeitos, Bastos et al. (2007) descreve que um defeito 
pode ocorrer em função de desvios do que foi levantado na análise de requisi-
tos. Segundo ele, temos:
 ■ Defeitos decorrentes da falta de concordância com a especificação do 
produto
 ■ Defeitos decorrentes de situações inesperadas, mas não definidas nas 
especificações do produto.
Conforme Rios e Moreira (2013), temos alguns tipos de defeitos que podem ser:
 ■ Defeitos de interface com os usuários: são defeitos gerados de funcio-
nalidade, usabilidade, desempenho e resultados (saídas). 
 ■ Defeitos introduzidos no tratamento de defeitos: esses defeitos podem 
ser subdivididos em: prevenção de defeitos, detecção de defeitos e recu-
peração de defeitos.
 ■ Defeitos de Limite: defeitos de valores extremos (maior, menor etc.) ou 
fora dos limites estabelecidos.
TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IVU N I D A D E134
 ■ Defeitos de Cálculo.
 ■ Defeitos de Controle de Fluxo.
 ■ Defeitos de Inicialização ou fechamento.
 ■ Defeitos de Manuseio ou interpretação de dados.
 ■ Defeitos de condição de disputa.
 ■ Defeitos de carga.
 ■ Defeitos de hardware ou software.
 ■ Defeitos de controle de versão.
Existem outros tipos de defeitos, dependendo de como são classificados. É inte-
ressante a empresa ter uma lista com os tipos de defeitos e ir adicionando ou 
classificando conforme os defeitos forem surgindo e assim, facilitando as corre-
ções e prevenções dos defeitos. Pois, conforme Bastos et al. (2007), “a maneira 
mais elementar de prevenir defeitos é detectá-los nos estágios iniciais do desen-
volvimento do software”. 
Preparados para o próximo tópico? Vamos aprender sobre o Ciclo de vida 
do teste de software. Vamos seguir com a leitura!
“Saber identificar a importância dos defeitos é fundamental para entender o 
impacto que eles causarão no sistema e nos negócios”.
(Bastos et al).
©shutterstock
Ciclo de Vida do Teste de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
135
CICLO DE VIDA DO TESTE DE SOFTWARE
Conforme Bastos et al. (2007, p. 29), “quanto antes os testes 
iniciarem, mais barato será corrigir defeitos encontrados. 
Para que isso seja possível, é preciso que o 
processo de teste, assim como o processo 
de desenvolvimento, tenha também um 
ciclo de vida”. As etapas do Ciclo de Vida 
de Teste de Software são: 
1. Planejamento.
2. Preparação.
3. Especificação.
4. Execução.
5. Entrega.
É preciso rastrear a origem dos defeitos, visando identificar a origem do 
problema. Entretanto, uma vez identificada a origem do problema, as ações 
tomadas jamais deverão visar punir alguém e sim melhorar os processos. A 
importância de um defeito está diretamente relacionada à frequência com 
que ele ocorre, ao custo para corrigi-lo, ao custo para identifica-lo e a sua 
correspondência para o sistema e para os negócios. 
Frequência: com que frequência esse tipo de bug ocorre?
Custo da correção: qual o custo para corrigir o defeito após a sua ocorrência?
Custo da instalação: qual o custo de disponibilizar a atualização para todos 
os clientes? Esse custo depende do número de instalações?
Consequência: qual é a consequência desse defeito? O que acontecerá na 
ocorrência desse defeito?
Fonte: Bastos, Rios, Cristalli e Moreira (2007).
TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IVU N I D A D E136
Segundo Bastos et al. (2007), pode existir outras etapas no Ciclo de Vida de 
testes, mas a estrutura básica consiste sempre na mesma, mudando apenas a ter-
minologia usada. Mas os autores ressaltam que além de uma metodologia de 
teste, baseada em ciclo de vida de testes, deve ser compatível com a metodolo-
gia usada para o desenvolvimento do sistema. 
Figura 1: Modelo de Integração entre os processos de desenvolvimento e Teste 
Modelo de Integração entre os processos de 
desenvolvimento e teste
Gerência de Requisitos
Validação
Teste Unitário
Teste de Aceitação
Teste de Sistema e 
Teste de Integração
Teste
Especi�cação
Execução (1)
Execução (2)
Entrega
Desenvolvimento
Desenho Lógico 
e Físico
Construção
Implantação
Entrega
P
l
a
n
e
j
a
m
e
n
t
o
P
l
a
n
e
j
a
m
e
n
t
o
Fonte: Rios e Moreira (2013). 
Ciclo de Vida do Teste de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
137
Agora vamos conhecer cada etapa do Ciclo de Vida de testes:
Planejamento: nessa etapa é elaborada a Estratégia de Teste e o Plano de Teste 
a ser utilizados. Esta etapa deve permanecer ativa até que o projeto seja concluído. 
Preparação: o objetivo dessa etapa é preparar o Ambiente de Teste (equi-
pamentos, pessoal, ferramentas de automação, base de testes) para que os testes 
sejam executados conforme planejados.
Especificação:nessa etapa temos as seguintes atividades: elaborar/ revi-
sar casos de testes e elaborar/ revisar roteiros de testes. Eles serão elaborados à 
medida que a equipe de desenvolvimento libera os módulos ou partes para o teste. 
Execução: nessa etapa os testes são executados e os resultados obtidos são 
registrados.
Entrega: nessa etapa o projeto é finalizado e toda documentação é finali-
zada e arquivada.
Figura 2: Planejamento e Controle 
Planejamento e Controle
Procedimentos 
iniciais
EntregaEspeci�cação Entrega
Preparação
Fonte: Rios e Moreira (2013).
Conforme Rios (2008), quem testa um software sem fazer um plano de teste não 
vai conseguir fazer um procedimento bem feito. O planejamento dos testes per-
mite ao gerente de teste prever situações futuras, tais como as necessidades de 
ambiente, de recursos humanos, dentre outros, que precisam ser tratados sempre 
como um projeto e como tal precisa ser planejado. Um trabalho bem planejado 
com um bom plano de teste bem feito, evitará muitas vezes inúmeras pressões 
a que o testador ou a equipe de teste estará submetido. 
TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IVU N I D A D E138
No próximo tópico, vamos definir as diversas técnicas de teste que podem 
ser aplicadas. Boa leitura. 
“Ao considerar que o desenvolvedor comete erros banais muitas vezes dei-
xamos de entrar fundo nos seus testes, que também acabam sendo negli-
genciados.”
(Rios).
O processo de avaliação de um sistema demanda planejamento. Esse é o 
passo inicial para delimitar as tarefas do processo, tais como os tipos de tes-
tes que serão realizados, a partir da proposta de desenvolvimento. No pla-
nejamento são especificados os casos de teste. Estes podem ser definidos a 
partir dos casos de uso, podendo ser do tipo negativo (ações imprevistas) 
e positivo (ações previstas). A aplicação prática de testes de software so-
mente é possível com a definição e aplicação de diretrizes mínimas a serem 
seguidas pelas equipes técnicas da instituição. É importante que os testes 
de software cubram todos os aspectos de um sistema, desde suas interfaces 
até as linhas de código. A revisão detalhada, sistêmica e auxiliada de rotei-
ros, procedimentos e checklists, de um sistema permite o amadurecimento 
da solução antes de sua efetiva liberação, evitando transtornos e problemas 
maiores, garantindo segurança, qualidade, eficiência e satisfação. 
Fonte: Primão, Ribeiro e Kreutz (2010). 
©shutterstock
Técnicas de Teste de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
139
TÉCNICAS DE TESTE DE SOFTWARE
Técnicas de teste são procedimentos técnicos e gerenciais que ajudam na avalia-
ção e melhorias do processo. Conforme Bastos et al. (2007, p. 49), “ a realização 
dos testes deve refletir as ações tomadas para descobrir erros introduzidos na 
codificação das funcionalidades definidas nas 
especificações dos programas e outros erros 
inseridos durante a codificação do programa”. 
Conforme Tsui e Karam (2013), há uma 
grande variedade de técnicas de teste, aplicá-
veis a diferentes circunstâncias. Elas podem 
ser utilizadas para classificar diferentes con-
ceitos de testes, técnicas de design de situação 
de testes, técnicas de execução de teste e orga-
nizações de testes. 
A técnica de testes estrutural tende a reve-
lar erros que ocorrem durante a codificação 
do programa, garante que a implementação 
de uma funcionalidade será toda testada na 
codificação. A análise estrutural deve ser uti-
lizada em todas as fases do ciclo de desenvolvimento do software. A fase de testes 
de software é dividida em dois tipos:
Os testes funcionais garante o atendimento aos requisitos, ou seja, que os requi-
sitos estão corretamente codificados. São conhecidos como testes de Caixa Preta. 
Figura 3: Técnica de Teste Funcional 
?
Fonte: Pressman (2011).
TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IVU N I D A D E140
Os testes estruturais garantem que os softwares e os programas sejam estrutu-
ralmente sólidos e que funcionem no contexto técnico em que serão instalados. 
São conhecidos como testes de Caixa Branca.
Figura 4: Técnica de Teste Estrutural 
?
Fonte: Pressman (2011)
Cada um desses testes possuem várias técnicas que ajudam o processo a asse-
gurar o funcionamento adequado de alguns aspectos do sistema ou da unidade. 
TESTE ESTRUTURAL 
Para Bastos et al. (2007) o objetivo principal dos testes estruturais é garantir que 
o produto seja estruturalmente sólido e que funcione corretamente. 
As técnicas para esse tipo de teste são desenhadas, não para garantir que o sis-
tema seja funcionalmente correto, e sim para que ele seja estruturalmente robusto. 
Sendo assim, os testes estruturais ou caixa-branca estabelecem os objetivos do 
teste com base em uma determinada implementação, analisando os detalhes 
do código fonte e elaborando casos de teste que cubram todas as possibilidades 
do componente de software. Dessa maneira, todas as variações originadas por 
estruturas de condições/repetições são testadas. Conforme Bastos et al. (2007), 
as técnicas podem ser divididas de acordo com o tipo de teste:
 ■ Testes de carga: verifica o volume de dados que um sistema consegue pro-
cessar. Ele permite monitorar o comportamento do sistema diante de uma 
situação onde há um grande número de acessos simultâneos.
 ■ Testes de conformidade: são realizados para garantir a conformidade 
com as metodologias e encorajar e auxiliar os profissionais de TI adotá-
-las. Avalia-se a documentação do sistema de aplicação é racional e está 
Técnicas de Teste de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
141
completa, garante a conformidade aos padrões, procedimentos e guias 
de TI e verifica se as metodologias de desenvolvimento e de manuten-
ção são seguidas. 
 ■ Testes de desempenho (performance): verifica o desempenho do sistema 
em um cenário previsto de baixa ou média carga. Por meio dele é possí-
vel mensurar o tempo de resposta ao acionar os comandos disponíveis e 
obter informações a respeito dos recursos físicos necessários num cená-
rio comum de funcionamento.
 ■ Testes de estresse: seu objetivo é avaliar o comportamento do software 
sobre condições críticas, tais como restrições significativas de memória, 
de área de disco e de CPU. Transações, tabelas internas, espaço em disco, 
saídas, capacidade do computador e interação com pessoas são aspectos 
que devem passar pelo teste de estresse. 
 ■ Testes de execução: são desenhados para avaliar o comportamento do 
sistema no ambiente de produção e verificar se são atendidas as premissas 
de desempenho estabelecidas. Os testes de execução verificam os tempos 
de resposta, os tempos de processamento e desempenho. 
 ■ Testes de operação: são desenhados principalmente para estabelecer se o 
sistema é executável durante a operação normal. Ele determina se a docu-
mentação da operação está completa, garante os mecanismos de suporte, 
avalia o treinamento dos operadores e testa se os operadores estão usando 
a documentação preparada, e se conseguem efetivamente operar o sistema. 
 ■ Testes de recuperação (contingência): recuperação é a capacidade de rei-
niciar operações após a perda da integridade de uma aplicação. O teste de 
recuperação é responsável por garantir a continuidade das operações após 
um desastre, o teste de recuperação não só verifica o processo de recu-
peração como também a eficácia das partes componentes do processo. 
 ■ Testes de segurança: são desenhados com o intuito de avaliar a ade-
quação dos procedimentos de proteção e as contramedidas projetadas. 
Os defeitos de segurança não aparecem de maneira tão óbvia como os 
demais, assim os testes de segurança visam descobrirdefeitos muito difí-
ceis de identificar. 
TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IVU N I D A D E142
TESTE FUNCIONAL 
Para Bastos et al. (2007), “os testes funcionais são desenhados para garantir que 
os requisitos e as especificações do sistema tenham sido atendidos”. Os testes 
funcionais ou caixa-preta utilizam as especificações (de requisitos, análise e pro-
jeto) para definir os objetivos do teste e, portanto, para guiar o projeto de casos 
de teste. No teste funcional, o componente de software a ser testado é abor-
dado como se fosse uma caixa-preta sem considerar o comportamento interno 
do mesmo. Entre os tipos de técnicas na execução dos testes funcionais temos:
 ■ Teste de controle: ele garante que os dados estejam completos e corretos, 
as transações sejam autorizadas, a manutenção das informações da trilha 
de auditoria seja realizada, os processamentos sejam eficientes, eficazes e 
econômicos e que atendam às necessidades dos usuários. 
 ■ Teste de interconexão: são desenhados para garantir que a intercone-
xão entre os softwares de aplicação funcione corretamente. Determina 
se os parâmetros e dados são transferidos corretamente entre os softwa-
res, garante o momento certo de execução e a existência de coordenação 
das funções entre os softwares e se a documentação pertinente é correta 
e completa.
 ■ Testes paralelos: serve para determinar se os resultados de um novo 
software de aplicação são consistentes com o processamento do antigo 
sistema ou da antiga versão do sistema. Ele ajuda a assegurar que a nova 
versão do software execute corretamente e que demonstre consistências 
e inconsistências entre as duas versões. 
 ■ Testes de requisitos: verificam se o sistema executa corretamente as fun-
cionalidades e se ele é capaz de sustentar essa correção após sua utilização 
por um período de tempo contínuo. 
 ■ Testes de regressão: eles voltam a testar segmentos de códigos já testa-
dos após a implementação de uma mudança em outra parte do software. 
Sempre que ocorrem mudanças em um segmento de código, problemas 
podem surgir em outros segmentos já testados. 
Técnicas de Teste de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
143
 ■ Testes de suporte manual: verificam se os procedimentos de suporte 
manual estão documentados e completos, determinam se as responsabi-
lidades pelo suporte manual foram estabelecidas, se o pessoal que dará 
suporte manual está adequadamente treinado e se ele está interligado 
apropriadamente com o segmento automatizado.
 ■ Testes de tratamento de erros: eles determinam a capacidade do sistema 
de tratar apropriadamente transações incorretas, se todas as condições de 
erro esperadas são reconhecidas pelo sistema, se foi atribuída responsa-
bilidade para processar os erros identificados e se é mantido um controle 
razoável sobre os erros durante o processo de correção.
Na tabela 1 podemos ver uma lista com alguns outros tipos de testes que podem 
ser utilizados: 
Tabela 1: Alguns Tipos de Teste
TIPO DE TESTE DESCRIÇÃO
Teste de Unidade Teste em um nível de componente ou classe. É o teste cujo objetivo é um “pedaço do código”. 
Teste de Integração
Garante que um ou mais componentes combinados (ou unida-
des) funcionam. Podemos dizer que um teste de integração é 
composto por diversos testes de unidade.
Teste Positivo-negativo Garante que a aplicação vai funcionar no “caminho feliz” de sua execução e vai funcionar no seu fluxo de exceção. 
Teste de caixa-preta
Testar todas as entradas e saídas desejadas. Não se está preo-
cupado com o código, cada saída indesejada é vista como um 
erro. 
Teste caixa-branca O objetivo é testar o código. Às vezes, existem partes do código que nunca foram testadas. 
Teste de Interface Verifica se a navegabilidade e os objetivos da tela funcionam como especificados e se atendem da melhor forma ao usuário.
Teste de aceitação do 
usuário
Testa se a solução será bem vista pelo usuário. Ex: caso exista 
um botão pequeno demais para executar uma função, isso 
deve ser criticado em fase de testes (aqui, cabem quesitos fora 
da interface também).
Teste de Volume Testar a quantidade de dados envolvidos (pode ser pouca, nor-mal, grande ou além de grande). 
TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IVU N I D A D E144
Testes de Configuração Testar se a aplicação funciona corretamente em diferentes am-bientes de hardware ou de software.
Testes de Instalação Testar se a instalação da aplicação foi OK.
Teste de sistemas Testar a execução do sistema como um todo para validar a exatidão e perfeição na execução de suas funções
Teste de Usabilidade
Testar e simular as condições de utilização do software sobre a 
perspectiva do usuário final. Esses testes focalizam a facilidade 
de navegação entre as telas, clareza dos textos e as mensagens 
que são apresentadas aos usuários, dentre outros aspectos da 
interface do sistema.
Testes de Progressão Testa apenas as funcionalidades (ou requisitos não funcionais) especificados para a versão.
Teste de Fumaça
Teste que consiste em um teste rápido, executando as prin-
cipais funcionalidades do sistema, sem se preocupar com as 
condições de erro. O mesmo que teste do Caminho Feliz.
Fonte: Bastos et al. (2007)
Outras técnicas de teste podem e devem ser utilizadas de acordo com a necessi-
dades da empresa. Conforme Pressman (2011), algumas técnicas se destacam, 
por exemplo: teste de desempenho, teste de usabilidade, teste de carga, teste de 
stress, teste de confiabilidade e teste de recuperação. Em alguns livros, alguns 
autores mostram a definição de uma técnica de teste chamada de “caixa cinza”, 
que mescla as técnicas de caixa preta e caixa branca. 
Preparados para o próximo tópico? Vamos conhecer os papéis e cargos para 
quem participa nos projetos de teste de software. Boa leitura!
“Nos testes os riscos servirão de elemento de definição dos níveis de priori-
dade do projeto.”
(Bastos et al.).
©shutterstock
Papéis e Cargos de Teste de Software 
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
145
PAPÉIS E CARGOS DE TESTE DE SOFTWARE 
Nessa seção trataremos sobre alguns papéis 
que uma pessoa pode desenvolver em um 
projeto de teste de software. Ela poderá 
acumular mais de um dos papéis que serão 
citados, de acordo com suas característi-
cas e restrições do projeto que está sendo 
desenvolvido. O Teste de Software possui 
algumas nomenclaturas de cargos definidos 
como “default” para área, mas alguns autores 
e especialistas da área podem mostrar com 
algumas variações. 
Uma das maneiras de priorizar os testes de um software é analisar os prin-
cipais riscos para o negócio que uma determinada falha poderia causar. Va-
mos supor que, em um dado software, um dos requisitos do produto seja 
um tempo de resposta adequado à necessidade do negócio. O usuário do 
software definiu um tempo de resposta por página em torno de dois ou 
três segundos. O usuário desse sistema concluiu, após estudos de merca-
do, que um tempo de resposta superior a dois ou três segundos poderia 
levar os clientes a desistir do negócio. Para minimizar esse risco, é preciso 
fazer um teste de performance, simulando as condições reais, para verificar 
o comportamento do software. Claro que também seria necessário simular 
um número definido de usuários acessando o software ao mesmo tempo. 
Com isso queremos dizer, portanto, que um dos riscos para o negócio seria 
um tempo de resposta superior a dois ou três segundos. 
Fonte: Bastos et al. (2007). 
TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IVU N I D A D E146
Na Tabela 2, é mostrada a Matriz de Responsabilidade com as funções quecada um deve desenvolver na fase de testes:
Tabela 2 – Matriz de responsabilidades 
Líder do Projeto de Testes
É o técnico responsável pela liderança de um projeto de 
testes especifico, normalmente, seja um projeto novo ou 
um de manutenção. 
Arquiteto de Teste
É o técnico responsável pela montagem da infraestrutura 
de teste, montando o ambiente de teste, escolhendo as 
ferramentas de teste e capacitando a equipe para executar 
o seu trabalho nesse ambiente de teste. 
Analista de Teste
É o técnico responsável pela modelagem e elaboração dos 
casos de Teste e pelos scripts de teste. Pode ser que em 
alguns casos os scripts sejam elaborados pelos testadores. 
Testador Técnico responsável pela execução dos casos de teste e scripts de teste. 
Fonte: Rios (2013).
Qual o perfil de um bom testador? Um bom testador deve ser explorador, resolver 
problemas, ser incansável, ser criativo, ser perfeccionista, exercitar o julgamento, 
ser diplomático e também ser persuasivo. 
Conforme Rios (2008, p. 40), “o trabalho do testador é muitas vezes estres-
sante e cansativo. Encontrar defeitos num software não é fácil e envolve atenção e 
cuidado. O bom testador deve ter o perfeito controle do seu trabalho para poder 
negociar nessas condições de alta pressão”.
O bom testador deve conhecer o processo de desenvolvimento do software 
no qual está inserido, pois suas atividades fazem parte desse processo. O tes-
tador deve conhecer quais são os artefatos de entrada e saída de cada fase do 
processo, principalmente das que envolvem atividades de testes. 
Segundo Tsui e Karam (2013, p. 147), “um testador é um profissional técnico 
cuja função para o item em particular sob teste é simplesmente compor situa-
ções de teste e garantir sua execução. Embora o conhecimento de programação 
seja extremamente útil para os testadores, os testes constituem uma atividade 
diferente com requisitos intelectuais diferentes”. 
Papéis e Cargos de Teste de Software 
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
147
Esses são os perfis mais conhecidos, mas algumas empresas podem utili-
zar outros como, por exemplo: automatizador de testes, analista homologador, 
entre outros. 
Vamos seguir em frente? No próximo tópico vamos conhecer como é o 
ambiente em que os testes de software são desenvolvidos. Bons estudos!
“Um grupo independente de teste não tem o “conflito de interesses” que os 
criadores de software podem ter.”
(Pressman).
O teste executado por uma equipe independente, mas integrada à equipe 
de desenvolvimento, precisa ter um projeto e um líder para que seja condu-
zida até o sucesso final. Nesta visão, o líder de teste deve estar alocado tão 
logo o plano de projeto comece a ser elaborado. Nunca é demais lembrar 
que a utilização de desenvolvedores como os próprios testadores nunca 
deu certo e dificilmente irá funcionar, pois é como deixar a raposa tomar 
conta do galinheiro. Os desenvolvedores tendem a usar métodos informais 
e incompletos de teste, o que permite que os problemas ocorram só quan-
do o sistema é liberado para a produção. Muitas vezes, esses problemas po-
derão aparecer meses ou até anos depois, quando a equipe de desenvolvi-
mento já estiver alocada em outro projeto ou até em outra empresa. Testar o 
software usando os desenvolvedores como testadores sai mais caro do que 
montar uma equipe específica de teste. 
Fonte: Bastos et al. (2007). 
©shutterstock
TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IVU N I D A D E148
AMBIENTE DE TESTE
O ambiente de testes é um conjunto específico de configurações de hardware, 
software e outros ambientes necessários para a execução de testes mais precisos 
e que simulem o ambiente do usuário. Conforme Bastos et al. (2007, p. 77) “o 
ambiente de teste tem uma relação direta com a estratégia de teste adotada no 
projeto. O ambiente não é apenas uma configuração de hardware, mas toda a 
estrutura em que o teste será executado”. As configurações do ambiente de teste 
nos fornece uma ideia de como conduzir os testes necessários e como serão as 
atividades de avaliação. Fornecer um ambiente conhecido e controlado para a 
condução desses testes ajuda a assegurar que os resultados sejam precisos e váli-
dos na busca de falhas e resolução de erros. 
Ambiente de Teste
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
149
Figura 5: Ambiente de Teste de Unidade 
Interface
Estruturas de dados locais
Condições de fronteira
Caminhos independentes
Caminhos de manipulação de erro
Pseudocontrolados Pseudocontrolados
Pseudocontrolador
RESULTADOS
Casos 
de teste
Módulo a 
ser 
testado
Fonte: Pressman (2011).
Conforme Bastos et al. (2007), o escopo do ambiente poderá ser definido pelo 
nível de teste a ser executado:
 ■ Quanto maior o nível: o ambiente de teste deverá ser capaz de reprodu-
zir as características do ambiente de produção.
Ainda segundo os autores, o ambiente de teste pode e deve ser planejado em duas 
fases do ciclo de vida do projeto de teste: na estratégia de teste e no plano de teste. 
Figura 6: Fluxograma de teste
Gerenciamento do 
processo de testes 
(indicadores de 
desempenho)
Criação do 
ambiente de 
testes
Execução dos 
testes 
dinâmicos
Planejamento 
dos testes 
dinâmicos
De�nição da 
estratégia de 
testes
Fonte Bastos et al. (2007).
TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IVU N I D A D E150
Para Bastos et al. (2007), a distribuição da preparação do ambiente pode se dar 
em: fases, estágio ou níveis de teste:
Teste unitário: estágio mais baixo da escala de testes e aplicado aos meno-
res componentes de código.
Teste de integração: aplicado à combinação das unidades de componentes.
Teste de sistema: aplicado ao sistema como um todo.
Teste de aceitação: teste final do sistema de funcionalidade e usabilidade. 
VOLUME DOS DADOS
Segundo Bastos et al. (2007, p. 81), é a “criação de um ambiente o mais real pos-
sível, tendo como base o escopo do teste. Isso inclui o volume de dados de teste”. 
O volume de dados está diretamente relacionado à necessidade e à abrangência 
da massa de teste para cada fase ou estágio, nas etapas iniciais (unidade e integra-
ção) não existe a necessidade de uma grande quantidade de dados para exercitar 
a aplicação, mas nas fases de sistema e aceitação, é necessário um grande volume 
para garantir a qualidade dos testes.
Bastos et al. (2007) definem que a técnica e o tipo de teste que estão sendo 
executados nos diferentes estágios também são fatores importantes nesse pro-
cesso. Por exemplo: para um teste de carga ser executado, é necessário um grande 
volume de dados e que este seja criado de maneira estruturada e o mais próximo 
possível da realidade. 
A criação de um ambiente isolado, organizado, representativo e mensurável 
para os testes garante a descoberta de erros reais, que realmente poderiam acon-
tecer na produção e que foram descobertos ainda em tempo de desenvolvimento. 
Conforme Bastos et al. (2007, p. 83), “é preciso que a preparação do ambiente seja 
discutida o quanto antes, e suas necessidades básicas (equipamentos, softwares, 
browsers, etc) devem ser identificadas no momento inicial do projeto”. Com o 
andamento do projeto de testes, esse ambientes ganham mais detalhes e come-
çam a ser implementados, mais a frente, na fase de implementação do teste, o 
volume de dados será criado e o ambiente previamente estabelecido será utili-
zado para executar os cenários de teste elaborados. 
Ambiente de Teste
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
151
Segundo Bastos et al. (2007), ao definirmos o ambiente de teste devemos 
considerar:■ O sistema operacional.
 ■ A arquitetura do sistema.
 ■ A identificação dos componentes.
 ■ O meio de acesso ao sistema.
 ■ A linguagem de programação utilizada.
 ■ A conectividade entre os ambientes. 
Para Mecenas e Oliveira (2005), os ganhos para o processo de qualidade dos pro-
jetos com a criação de um ambiente independente são:
 ■ Ambiente controlado.
 ■ Dados íntegros.
 ■ Base de dados reduzida.
 ■ Utilização de massa de dados construída e não real.
 ■ Facilidade no gerenciamento.
 ■ Testes não tendenciosos.
 ■ Trabalhar na prevenção dos erros e não na correção deles.
 ■ Garantia da utilização das normas e dos padrões especificados.
 ■ Teste de todos os módulos e não apenas dos que sofreram alteração, garan-
tindo que nada tenha sido alterado após a manutenção. 
A criação desses ambientes libera a equipe de desenvolvimento para continuar 
produzindo novos códigos, sem prejuízo à integridade do ambiente, mesmo 
durante a execução dos testes, e possibilita a realização dos testes de iteração e 
sistema, de modo a permitir a integração das diferentes camadas e/ou ambientes. 
TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IVU N I D A D E152
Projete testes para executar todos os caminhos de manipulação de erro. Se 
não fizer isso, o caminho pode falhar quando for solicitado, piorando uma 
situação já ruim.
(Pressman).
O teste de software é uma das atividades que buscam contribuir para a me-
lhoria da qualidade do software. O teste revela a presença de defeitos no 
software e atende as exigências de qualidade de software. O objetivo do 
presente trabalho foi esclarecer como o teste de software influência a qua-
lidade do software no mercado. A metodologia utilizada para desenvolvi-
mento do trabalho foi baseada em revisão bibliográfica, em materiais publi-
cados em livros, revistas, jornais, rede eletrônica, periódicos especializados, 
monografias e dissertações como fonte de coleta de dados. Diante da in-
cessante competitividade do mercado atual, empresas procuram garantir a 
qualidade de seus produtos como fator que represente sua capacidade em 
desenvolver sistemas com qualidade. No mercado existem várias técnicas 
de teste de software que auxiliam essa garantia. 
Fonte: Barbosa e Torres (2011). 
Considerações Finais
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
153
CONSIDERAÇÕES FINAIS
Nessa unidade analisamos a importância da fase de teste de software dentro do 
processo de desenvolvimento de software. Vimos alguns conceitos básicos, seu 
ciclo de vida e as técnicas que envolvem o teste de software.
Vimos questionamentos sobre o que aconteceria se os testes não forem exe-
cutados de forma correta. Verificamos como podemos fornecer uma garantia ao 
cliente de que ele irá funcionar em diversas situações. Aprendemos que, mesmo 
se um teste não detectar defeitos, isso não quer dizer necessariamente que o pro-
duto não tenha uma boa qualidade.
Ao longo da unidade, aprendemos que realizar testes não consiste simples-
mente na geração e execução de casos de teste, mas envolvem também questões 
de planejamento, gerenciamento e análise de resultados.
Aprendemos que quanto antes os testes iniciarem, mais barato será a corre-
ção dos defeitos encontrados. Para isso ser possível, é preciso que o processo de 
teste, assim como o processo de desenvolvimento, tenha também um ciclo de vida.
Conhecemos uma grande variedade de técnicas de teste, aplicáveis a diferen-
tes circunstâncias. Vimos que elas podem ser utilizadas para classificar diferentes 
conceitos de testes, técnicas de design de situação de testes, técnicas de execu-
ção de teste e organizações de testes.
Também vimos como as configurações do ambiente de teste nos fornecem 
uma ideia de como conduzir os testes necessários e como serão as atividades de 
avaliação, pois eles nos asseguram que os resultados sejam precisos e válidos na 
busca de falhas e resolução de erros.
Depois dessa unidade, com o conhecimento que já adquirimos sobre os tes-
tes de softwares, podemos passar para a próxima unidade e nos aprofundamos 
ainda mais nos de teste de software. Preparados? Então continue com sua leitura!
154 
1. Conforme Tsui e Karam (2013, pg. 147), os testes de software geralmente pos-
suem dois objetivos principais: 
I. Os testes devem encontrar defeitos no software, para que eles possam ser cor-
rigidos ou maximizados e restaurados.
II. Os testes fornecem uma avaliação geral de qualidade e uma estimativa das 
possíveis falhas. 
III. Os testes devem encontrar defeitos no software, para que eles possam ser 
corrigidos ou minimizados.
IV. Os testes geram uma avaliação de cada componente e uma estimativa dos 
possíveis sucessos. 
V. Os testes não encontram defeitos e apenas fornecem uma avaliação geral de 
qualidade. 
Assinale a opção com a sequência CORRETA.
a. Somente a questão I está correta.
b. Somente as questões II e III estão corretas.
c. Somente as questões I, IV e V estão corretas.
d. Todas estão incorretas. 
e. Todas estão corretas. 
2. Para Sommerville (2011), o processo de teste apresenta dois objetivos distintos:
I. Demonstrar ao desenvolvedor e ao cliente que o software atende seus requi-
sitos. 
II. Descobrir situações em que o software se comporta de maneira incorreta, in-
desejável ou de forma diferente do que foi especificado. 
III. Demonstrar ao usuário e ao cliente que o software não atende seus requisitos. 
IV. Demonstrar ao desenvolvedor e ao cliente que o software não atende seus 
requisitos. 
V. Descobrir situações em que o software se comporta de maneira correta, dese-
jável ou de forma igual do que foi especificado.
155 
Assinale a opção com a sequência CORRETA.
a. Somente as questões I e II estão corretas.
b. Somente as questões I e III estão corretas.
c. Somente a questão I está correta.
d. Somente as questões III e V estão corretas. 
e. Todas estão corretas. 
3. A técnica de testes estrutural tende a revelar os erros que ocorrem durante a 
codificação do programa, garante que a implementação de uma funcionalidade 
será toda testada na codificação, além disso, a análise estrutural deve ser utiliza-
da em todas as fases do ciclo de desenvolvimento do software. A fase de testes 
de software é dividida em dois tipos. Assinale a resposta correta:
a. Testes Funcionais e Testes Estruturais.
b. Teste de Cor Cinza e Testes Estruturais.
c. Testes Funcionais e Teste de capacidade.
d. Testes Estruturais e Testes de energia.
e. Nenhuma resposta correta. 
4. Você já deve ter passado alguma experiência com algum “bug” de software em 
algum momento. Descreva alguma experiência com “bug” que tenha passado 
ou tenha conhecimento. 
5. Uma calculadora está para somar 2+2 e deu um resultado igual a 3. Qual é o tipo 
de defeito?
a. Defeito de interface.
b. Defeito de cálculo.
c. Defeito de limites.
d. Defeito de carga.
e. Defeito de desempenho.
156 
A ATIVIDADE DE TESTE DURANTE O CICLO DE VIDA DO SOFTWARE
Autora: Luciane Neves 
1. Introdução
A fase de testes ocupa, normalmente, 40% do tempo planejado para um projeto e um 
erro descoberto tardiamente em um sistema provoca um acréscimo de 60% nos custos 
do projeto. Nenhum programador ou analista, por mais experiente que seja, está imune 
à falhas de codificação e projeto.
Estes são alguns dos motivos que têm feito com que a atividade de teste de software 
tenha se tornado um dos itens mais estudados no contexto de aprimoramento da qua-
lidade de software[...].
2. Qualidade de software e testes
A história da garantia de qualidade no desenvolvimento de software tem paralelo com a 
história da qualidade no processo de manufatura de hardware [...].
Neste artigo entende-se que a atividade de teste deve ser usada em todas as etapas do 
processo de desenvolvimento de software e que, ao invés de representar uma última 
revisão, seja utilizada como “milestone”entre todas as fases do projeto[...].
3. Teste de software
Este capítulo abordará os aspectos fundamentais da atividade de teste, por meio de 
revisão bibliográfica. Os princípios, limitações e objetivos da atividade de teste serão 
apresentados nos itens que se seguem. Veremos também as características principais 
de cada classe de testes.
3.2 Princípios do teste de software
Alguns dos itens que são comuns a todos os autores e pesquisadores do assunto “teste 
de software” e que descrevem os fundamentos e princípios desta atividade estão rela-
cionados abaixo:
Conforme a Lei de Pareto, 80% dos erros podem ser localizados em 20% do projeto, 
geralmente nos módulos principais do sistema.
A atividade de teste não prova a ausência de erros, apenas a sua existência.
Bons casos de teste são aqueles que encontram falhas no sistema até então não desco-
bertas.
Bons casos de teste são projetados levando em conta os requisitos do projeto.
Um critério que pode ser utilizado para determinação do esforço a ser gasto na ativida-
de de teste de software é verificar qual o grau de severidade das consequências advin-
das do seu mau funcionamento.
157 
A probabilidade de encontrar um erro em uma determinada parte do sistema é propor-
cional ao número de erros já encontrados nessa parte.
O objetivo da atividade de teste pode ser entendido da seguinte forma:
No início de cada fase verificar se essa etapa do projeto reflete exatamente os requisitos 
e definições da fase imediatamente anterior [...].
Verificar se não existem erros de lógica no projeto e código, no fluxo de dados, no en-
tendimento de requisitos, de codificação, tipográficos ou de interface em todas as fases 
do projeto.
Identificar e interferir na presença do erro, iniciando-se a depuração, sendo que quanto 
antes for descoberta a falha, menos custoso será para adequá-la.
Ter em mente que, uma vez que errar é humano e atividade de desenvolvimento de sof-
tware é um exercício bastante complexo, os erros existem e devem ser descobertos [...].
3.4 Classificação dos testes
Podemos classificar os métodos de teste de acordo com suas características básicas. Po-
de-se descrever resumidamente cada um destes grupos da seguinte forma:
Testes estáticos ou testes humanos: não são feitos por meio da execução real do pro-
grama, mas sim por meio da sua execução conceitual [...].
Testes dinâmicos: requerem que o programa seja executado e, por isso, seguem o mo-
delo tradicional de teste de programa, no qual o programa é executado com alguns 
casos de teste. 
Testes funcionais: uma vez que testes exaustivos não são viáveis, características do do-
mínio de entrada são examinadas para que se tente descobrir formas de derivar um 
conjunto de dados de teste representativo que consiga exercitar completamente a es-
trutura do sistema.
Testes estruturais: diferentemente dos testes funcionais, que se preocupam com a fun-
ção que o programa desempenha sem se preocupar com a maneira como a função foi 
implementada, o teste estrutural enfoca a implementação e a estrutura da função [...].
Testes de unidade: concentra-se no esforço de verificação da menor unidade de pro-
jeto de software: o módulo. Por meio do uso da descrição do projeto detalhado como 
guia, caminhos de controle importantes são testados para descobrir erros dentro das 
fronteiras do módulo. Esse teste baseia-se sempre na caixa branca, e esse passo pode ser 
realizado em paralelo para múltiplos módulos [...].
Testes de integração: o objetivo é, a partir dos módulos testados no nível de unidade, 
construir a estrutura do programa que foi determinada pelo projeto de forma sistemá-
tica, testando também a interface dos módulos. A integração pode ser incremental ou 
não-incremental. 
158 
Testes de validação: o teste de validação pode ser considerado bem sucedido quando 
o software funciona da maneira esperada pelo cliente. A validação do software, na fase 
de testes, é realizada por meio de uma série de testes de caixa preta que demonstram a 
conformidade com os requisitos.
Testes alfa e beta: são os testes de aceitação, feitos pelo usuário, que dificilmente opera 
o sistema da forma prevista, e visam descobrir erros cumulativos que poderiam deterio-
rar o sistema no decorrer do tempo. 
Teste de segurança: o teste de segurança tenta verificar se todos os mecanismos de 
proteção embutidos em um sistema o protegerão de acessos indevidos. Todas as formas 
de ataque devem ser simuladas. 
Testes de estresse: o teste de estresse é feito para confrontar o sistema com situações 
anormais. O teste de estresse executa o sistema de forma que exige recursos em quanti-
dade, frequência ou volume anormais.
Teste de desempenho: o teste de desempenho é idealizado para testar o desempenho 
do software quando executado dentro do contexto de um sistema integrado. 
Embora seja difícil medir e definir um software como sendo de boa qualidade, é fácil 
identificar um software de má qualidade. Os erros frequentes, o mau funcionamento ou 
a inadequação aos requisitos são sempre notados.
Fonte: Neves (2009)
Material Complementar
MATERIAL COMPLEMENTAR
Teste de Software
Emerson Rios, Trayahú Moreira
Editora: Alta Books
Sinopse: Tratar essa atividade de teste de software como uma daquelas 
inseridas no processo de desenvolvimento, quando era executada por 
programadores e analistas de sistemas, não atende mais ao nível atual 
de complexidade das aplicações. Os testadores são técnicos altamente 
qualifi cados, os quais precisam acumular uma gama enorme de 
conhecimentos para poderem desempenhar suas atividades. Esse livro dá 
um enfoque gerencial aos principais aspectos relacionados com teste de 
software e procura servir de base para que gerentes e testadores possam 
absorver os conhecimentos necessários para suas funções na época atual. 
Desta forma, os autores apresentam além das métricas e metodologias, 
como os testes devem ser corretamente organizados e executados na 
empresa, e o que os gerentes precisam saber para montar um ambiente de 
teste estruturado e adequado aos novos técnicos dos projetos de teste de 
software. Nessa edição de Teste de Software, os autores Emerson Rios e Trayahú Moreira incluíram 
o capítulo Documentação de Teste, onde o leitor adquire informações sobre a norma IEEE 
829:2008, que trata da documentação que deve ser usada em projetos de teste de software.
Testes de Software - Produzindo Sistemas Melhores e Mais Confi áveis
Leonardo Molinari
Editora: Érica
Sinopse: Esse livro, para melhor entendimento do leitor, está dividido em 
três partes. A primeira mostra a visão macro da qualidade de software e 
seus principais elementos. Em seguida, traz testes de software em detalhes 
e, por último, as principais áreas de testes. O autor faz uma análise do 
mercado de ferramentas de automação de testes e exercícios de fi xação. A 
qualidade de software, ao longo do tempo, tem se modifi cado e evoluído. 
Então, como desenvolver sistemas usando uma nova ciência em explosão 
no mundo, chamada de testes de software? A resposta a esta pergunta 
é tratada do início ao fi m deste livro. Ele é dividido em três partes: visão 
macro da qualidade de software e seus principais elementos, testes de 
software em detalhes e principais ou grandes áreas de teste. Contém ainda 
análise do mercado de ferramentas de automação de testes e exercícios de 
fi xação ao fi nal dos capítulos.
MATERIAL COMPLEMENTAR
Base de Conhecimento Em Teste de Software - 3ª Ed. 
2012
Emerson Rios, Anderson Bastos, Ricardo Cristalli e Trayahú Moreira.
Editora: Martins Editora
Sinopse: Obra de referência para os profi ssionais da área, 
indicada para o leitor que começa a se preparar para os exames 
de certifi cação. A fi m de auxiliá-lo ainda mais nessa tarefa, foram 
selecionados os temas mais abordados nos principais exames. 
De maneira complementar, esta obra, desde sua primeira edição, 
é também fonte de consulta para a execução das atividades 
relacionadas ao teste de software.
Como trabalhar com testes desoftware?
Nesse vídeo é dado algumas dicas do por que escolher a área de teste de software pode ser uma 
boa escolha para começar a trabalhar na área de TI, ou mesmo como uma opção para buscar um 
nova oportunidade do mercado de trabalho, visando crescimento na carreira profi ssional.
Disponível em: <https://www.youtube.com/watch?v=rL48FS-99ac>.
Introdução à garantia de qualidade de software e ferramentas para teste
Veja neste artigo uma introdução à garantia de qualidade e ferramentas de teste de software. 
Atualmente, muito se fala sobre qualidade de software, entretanto, os desenvolvedores por vezes 
não sabem se estão no caminho certo. Para esclarecer um pouco sobre este assunto, nesse artigo 
vamos tratar alguns pontos principais sobre este tema. Boa leitura!
Leia mais em: <http://www.devmedia.com.br/introducao-a-garantia-de-qualidade-de-software-
e-ferramentas-para-teste/28027#ixzz3xmj2tx5q>.
Material Complementar
MATERIAL COMPLEMENTAR
Formando Equipes Eficientes de Teste de Software
Nesse artigo o autor mostra a importância de se formar equipes e times eficientes em teste de 
software, qualificações e requisitos tanto técnicos como gerenciais básicos que são necessários 
e completam o perfil ideal para trabalhar na área de teste de software. Também é mostrado 
o Processo de Formação de Equipes de Teste de Software, como desenvolver um modelo de 
hierarquia para projetos de teste de software. O autor mostra um guia «quase completo» para 
ser e contratar um bom Analista de teste de Software (Requisitos técnicos e requisitos Pessoais e 
Profissionais). Excelente artigo. 
Para ler o artigo na íntegra, acesse o link: 
<http://www.linhadecodigo.com.br/artigo/1419/formando-equipes-eficientes-de-teste-de-
software.aspx#ixzz3zICtaNLl>
Artigo que mostra como o ciclo de vida do teste faz parte do ciclo de vida do software e eles 
devem ser iniciados ao mesmo tempo. O processo de design e desenvolvimento de testes pode 
ser tão complexo quanto o processo de desenvolvimento do software em si. Se os testes não 
forem iniciados juntamente com os primeiros releases executáveis do software, o esforço de teste 
retardará a descoberta de muitos problemas no ciclo de desenvolvimento. Boa leitura!
Para ler o artigo na íntegra, acesse o site:
<http://www.wthreex.com/rup/process/workflow/test/co_lifet.htm>.
REFERÊNCIAS
BARBOSA F. B.; TORRES I. V. O Teste de Software no Mercado de Trabalho. Revista 
Tecnologias em Projeção. V. 2, 2011, p. 49-52.
BASTOS A.; RIOS E.; CRISTALLI R.; MOREIRA T. Base de Conhecimento em Teste de 
Software. 2 ed. São Paulo: Editora Martins, 2007.
HETZEL W. C. The Complete Guide to Software Testing. 2 ed. United States: John 
Wiley & Sons, 1998.
MECENAS I.; OLIVEIRA V. Qualidade em software. Rio De janeiro: Alta Books, 2005. 
MOLINARI, L. Testes de Software: Produzindo Sistemas Melhores e Mais Confiá-
veis. São Paulo: Érica, 2003.
MYERS G. J. The Art of Software Testing. New York: John Wiley & Sons, 1979. 
NEVES, L. A atividade de teste durante o ciclo de vida do software. Bate byte. (on-
line). 2009. Disponível em: <http://www.batebyte.pr.gov.br/modules/ conteudo/
conteudo.php?conteudo=1097> Acesso em: 19 Mar. 2016
PRESSMAN, R. Engenharia de Software. 7. ed. Porto Alegre: AMGH, 2011.
PRIMÃO A. P.; RIBEIRO P. da S.; KREUTZ D. L. Estudo de Caso: Técnicas de Teste como 
parte do Ciclo de Desenvolvimento de Software. In: Anais do IX Simpósio de Infor-
mática da Região Centro do RS. Santa Maria: UNIPAMPA, 2010. 
RIOS, E. Caratê Aplicado ao Teste de Software. 1 ed. Niterói: Imagem Art Studio, 
2008. 
RIOS, E. ; MOREIRA, T. Teste de Software. 3 ed. Rio de Janeiro: Alta Books, 2013.
SOMMERVILLE, I. Engenharia de Software. São Paulo: Pearson Prentice Hall, 2011.
 TSUI, F.; KARAM, O. Fundamentos de engenharia de software. 2 ed. Rio de Janeiro: 
LTC, 2013.
GABARITO
163
1. B - Somente as questões II e III estão corretas.
2. A - Somente as questões I e II estão corretas.
3. A - Testes Funcionais e Testes Estruturais 
4. Um exemplo de “bug” pelo qual passei: “Ao atualizar um cliente com a última 
versão disponível, ele reclamou que quando efetuava uma venda com baixa do 
depósito, o produto baixava duas vezes no estoque, uma do depósito e outra na 
loja. Ao verificar os testes que tinham sido feitos, o erro não ocorria, pois a venda 
baixava somente do depsito, como era a regra de venda do cliente. O analista foi 
verificar e descobriu que alguém do suporte tinha “alterado” uma configuração 
das baixas de estoque, alterando assim a regra do cliente e fazendo com que 
ocorresse esse erro. Ao voltar à configuração original, as vendas foram efetuadas 
corretamente”.
5. B - Defeito de cálculo, pois a calculadora efetuou o cálculo e produziu um resul-
tado errado, causado basicamente por: lógica errada, defeito de codificação e/
ou imprecisão no cálculo. 
U
N
ID
A
D
E V
Professora Esp. Janaína Aparecida de Freitas
PROCESSO DE TESTE DE 
SOFTWARE
Objetivos de Aprendizagem
 ■ Compreender a Documentação de Teste de Software.
 ■ Ter uma Visão geral da Validação e Verificação.
 ■ Entender as técnicas e os critérios utilizados para validar um software.
 ■ Aprender sobre algumas ferramentas utilizadas para a automação de 
testes.
 ■ Compreendendo as Medidas de melhoria do processo.
 ■ Possuir uma Visão geral sobre os riscos em teste de software. 
Plano de Estudo
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
 ■ Documentação de Testes de Software
 ■ Relatórios de Teste de Software
 ■ Validação e Verificação em Teste de Software
 ■ Ferramentas de Teste de Software
 ■ Métricas e Medição
 ■ Gerência de Risco em Teste de Software
INTRODUÇÃO
Olá, caro(a) aluno(a)! Vamos para a última unidade do livro? Avançando em 
nosso aprendizado sobre a fase de teste de software, vamos nos aprofundar um 
pouco mais, aprendendo sobre os documentos que devem ser produzidos pela 
equipe de testes e porque ele é necessário e essencial para garantir a qualidade 
dos testes e sua manutenção. 
Nessa unidade, vamos aprender sobre validação e verificação e suas diferenças 
no teste de software e apresentaremos técnicas de verificação e validação que são 
fundamentais para identificar os defeitos do software. Atendendo, dessa forma, 
ao grande objetivo das organizações: evitar que os erros perdurem, ou melhor, 
que sejam descobertos antes que o software seja liberado para sua utilização. 
Também vamos aprender os principais conceitos relativos à automação de 
testes, sobre o que pode e quais devem ser os critérios na hora de escolher a fer-
ramenta para determinado teste e a metodologia empregada na empresa. 
Vamos aprender nesta unidade, também, sobre as métricas e medição e ver 
porque o ato de medir e estimar é a parte mais importante de um projeto de sof-
tware que seja bem-sucedido e com qualidade. 
E por fim, vamos aprender sobre como gerenciar os riscos no projeto de 
teste de software, quais regras e metodologias podem ser usadas para reduzir os 
riscos de ocorrências de problemas e erros no ambiente do usuário e como isso 
pode representar a confiabilidade no software. 
Os softwares que utilizamos são desenvolvidos por seres humanos, que são 
passíveis de falhas. Principalmente porque a maioria dos erros é humana e tem 
origem na falta de comunicação (analistas e desenvolvedores), entendimento (o 
desenvolvedor acha que entendeu) e transformação das informações (desenvol-
veu como entendeu). Se os softwares não funcionam corretamente podem trazer 
diversos prejuízos e grandes impactos para as pessoas e empresas que os utilizam. 
Por isso, é necessário testar, pois os testes diminuem os riscos. Aproveite a leitura!
Introdução
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
167
©shutterstock
PROCESSO DE TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E168
DOCUMENTAÇÃODE TESTE DE SOFTWARE
Conforme Bastos et. al (2007), durante o ciclo de um projeto de teste, o analista 
de teste gasta com a documentação do teste em torno de 50% a 60% do tempo. 
Será que é tão importante gastar tanto tempo assim com a documentação de 
teste? Para Bastos et. al (2007) sim, pois os documentos que são definidos pela 
norma e cobrem tarefas de planejamento, especificação ou elaboração e análise 
dos resultados. A norma ou padrão IEEE 829 (Institute of Electrical Engineers) 
especifica que devem ser usados os seguintes documentos:
 ■ Plano de Teste.
 ■ Especificação de Projeto de Teste:
- Projeto de teste.
- Casos de teste.
- Procedimentos de teste.
Documentação de Teste de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
169
 ■ Relatórios de Teste: 
- Relatório de Passagem de Itens de Teste.
- Relatório de Log de Teste.
- Relatório de Incidentes de Teste.
- Relatório de Sumário de Teste.
Segundo a norma, esses são os documentos mínimos necessários para que um 
processo de testes funcione convenientemente, ou seja, bem sucedido. Empresas 
que trabalham com automação de teste, com certeza, já possuem softwares que 
geram automaticamente todos, ou quase todos, os documentos citados. 
Figura 1: Relacionamento entre os documentos de teste no processo de teste
Itens de Teste 
Artefatos usados 
nos testes
Itens de Teste 
Artefatos usados 
nos testes
Especi�cação do 
Procedimento de 
Teste
Plano de Teste
Relatórios de 
Itens de teste
Documentos 
projeto desenv
Especi�cação de 
Projeto de Teste
Especi�cação de 
Projeto de Teste
Especi�cação de 
Projeto de Teste
Especi�cação de 
Caso de Teste
Fonte: IEEE 829 (1998).
PROCESSO DE TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E170
PLANO DE TESTE
O Plano de Teste, documento básico gerado através da etapa de planejamento, 
serve como escopo de referência durante a execução do teste e também serve como 
documento de comunicação junto ao cliente que contratou o serviço de teste. 
Ao passarmos para a etapa de especificação precisamos ter em mãos o Plano de 
Teste. Para Bastos et al. (2007, p. 150), “apresenta o planejamento para a execu-
ção do teste, incluindo a abrangência, a abordagem, os recursos e o cronograma 
das atividades de teste. Identifica os itens e as funcionalidades a serem testadas, 
as tarefas a serem realizadas e os riscos associados com a atividade de teste, des-
crevendo ainda os diferentes ambientes que serão utilizados durante o teste”. 
Executar testes para cobrir todo o sistema e garantir que o mesmo não terá 
mais nenhum defeito, é uma atividade custosa e muitas vezes impossível de ser 
realizada. Muitas empresas adotam alguns padrões de conteúdo de plano de 
teste para auxiliar nessa atividade, como IEEE, QAI e se for tratar o teste como 
um projeto, temos o PMBOK. Geralmente, a base de conteúdo do plano de teste 
segue o modelo IEEE 829, entretanto, pode variar de empresa para empresa. O 
IEEE 829 procurou adotar ou basear o Plano de Teste no padrão PMI.
Principais Funções de um Plano de Teste
O Plano de teste possui várias funções, dependendo de sua situação. Vamos lis-
tar as principais:
 ■ Suportar o desenvolvimento da qualidade dos produtos, de forma sábia, 
sincronizada com as decisões.
 ■ Descrever e justificar a estratégia de testes para com os requisitos do pro-
duto a ser testado.
 ■ Suportar o início e a organização do projeto de teste, incluindo aí prepara-
ções, pessoal, delegação de responsabilidades, planejamento das tarefas etc.
 ■ Suportar o gerenciamento diário e a evolução do projeto de teste e da 
estratégia.
Documentação de Teste de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
171
 ■ Suportar a efetiva coordenação, colaboração e outros relacionamentos 
entre os membros da equipe e o resto do projeto.
 ■ Identificar e gerenciar quaisquer riscos ou questões que possam impac-
tar no projeto.
 ■ Ter as informações históricas do projeto, de forma a suportar auditoria e 
melhorias para futuros projetos.
Principais etapas de elaboração de um Plano de Teste
Pode-se dizer que um Plano de teste segue algumas etapas durante sua elabo-
ração e utilização:
 ■ Definição do escopo: define o que se deve testar em nível macro.
 ■ Identificação de requisitos e casos de teste: identificação dos requisi-
tos de teste de forma hierárquica e descritiva, de maneira que possamos 
entendê-los. Identificação dos casos de teste que contenham os requeri-
mentos de teste em detalhes, incluindo os passos de execução dos testes.
 ■ Identificação das propriedades: o que se deve testar e em qual ordem.
 ■ Definição da estratégia: identificação das técnicas de teste que serão uti-
lizadas em quais requisitos.
 ■ Identificação de recursos: quem fará o que e o que será utilizado (sof-
tware, hardware etc.).
 ■ Criação de Schedule: elaboração de um cronograma de teste.
 ■ Geração de documento de Plano de Teste: geração da documentação 
formal e revisada, com as devidas análises do planejamento de teste.
 ■ Atualização constante do Plano de Teste: aqui o plano de teste será atu-
alizado com resultados finais de cada teste e com os defeitos encontrados.
PROCESSO DE TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E172
Tabela 1: Conteúdo de um Plano de Teste segundo IEEE 829
ITEM DESCRIÇÃO
Identificador do plano de testes Identificador único para o plano.
Introdução Objetivos, histórico, escopo, referências a documentos.
Itens a testar Conjunto dos itens cobertos pelo plano.
Aspectos a testar Conteúdo dos testes que serão feitos.
Aspectos que não serão testados Aspectos significativos que não serão testados.
Abordagem Opções metodológicas que são aplicá-veis ao conjunto dos testes.
Critérios de completeza e sucesso
Condições que devem ser satisfeitas e 
estado que deve ser atingido para que 
o conjunto dos testes seja considerado 
bem sucedido.
Critérios de suspensão e retomada Problemas graves que podem provocar a interrupção dos testes.
Resultados do teste Artefatos que serão produzidos durante a realização da bateria de testes.
Tarefas de teste Lista detalhada das tarefas que são cobertas por este plano.
Ambiente Hardware e software das configurações usadas para o conjunto dos testes.
Responsabilidades Responsabilidades de cada um dos participantes dos testes.
Agenda Data de inicio e de fim de cada tarefa do plano.
Riscos e contingências Ricos e contingências aplicáveis aos testes deste plano.
Aprovação Nomes e assinaturas dos responsáveis pela aprovação do plano.
Fonte: Norma IEEE Std. 829 (1998).
Documentação de Teste de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
173
Segundo Bastos et al. (2007, p. 154), “o caso de teste deve ter as características a 
seguir para que possa ser usado e atender às expectativas de validação da qualidade”:
 ■ Efetivo: testar o que se planejou testar.
 ■ Econômico: sem passos desnecessários.
 ■ Reutilizável: que possa ser repetido.
 ■ Rastreável: que possa identificar o requisito a ser testado.
 ■ Autoexplicativo: que possa ser testado por qualquer testador.
ESPECIFICAÇÃO DE PROJETO DE TESTE
Segundo Bastos et al (2007, p. 155), “trata-se de um detalhamento da abordagem 
apresentada no plano de teste que identifica as funcionalidades e as caracterís-
ticas a serem testadas pelo projeto. Esse documento também aponta os casos e 
os procedimentos de teste”. 
Projeto de Teste
O objetivo principal do projeto de teste é facilitar o entendimento e acompanha-
mento do plano de testes, por meio da sua abertura em diversos projetos de teste. 
O projeto deteste deve conter os seguintes campos:
 ■ Identificador: código único que identifique o projeto de teste.
 ■ Features a serem testadas: listar todas as funcionalidades ou programas 
que serão testados.
 ■ Abordagem refinada: refinar a abordagem do plano de teste.
 ■ Casos de teste com a sua respectiva identificação: breve descrição dos 
casos de teste e sua respectiva identificação.
 ■ Critérios de passagem e falha por Features: condição para que uma fun-
cionalidade passe pelos testes.
PROCESSO DE TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E174
CASOS DE TESTE
O caso de teste é a especificação mais detalhada do teste, com níveis de detalhes 
de campos de telas, formulários etc. Ele estabelece o que será testado e quais as 
informações que serão empregadas durante os testes dos cenários e quais serão 
os resultados esperados. Para isso acontecer é necessário estabelecer a massa a 
ser utilizada no teste de forma a validar todos os requisitos do software. 
Os casos de teste incluem dados de entrada, resultados esperados, ações e con-
dições gerais para a execução do teste. Utiliza também a nomenclatura de plano 
de caso de teste. Identifica o maior número de cenários e variações de determi-
nado requisito de software. Segundo Bastos et al. (2007, p. 152), “o plano de caso 
de teste é o documento que registra todo o planejamento dos testes dos requisitos 
estabelecidos durante o ciclo de desenvolvimento do software. Esse documento 
determina o que será testado, e seu principal objetivo consiste em identificar o 
maior número de cenários e variações de determinado requisito de software”. 
Os testadores enfrentam o desafio de testar, tanto quanto possível, dentro 
do disponível e geralmente em um curto cronograma, sendo impossível testar 
exaustivamente todas as combinações de casos de teste de um sistema.
Definição do Caso de Teste
Em geral, define-se formalmente um caso de teste como a especificação mais 
detalhada do teste, como os campos de tela, formulários e estabelece quais infor-
mações serão usadas durante os testes dos cenários e quais serão os resultados 
possíveis esperados. Segundo Bastos et al. (2007), é necessário para isso, deter-
minar a massa a ser utilizada no teste de modo a validar todos os requisitos do 
software. Um bom caso de teste deve conter:
 ■ Identificação das condições de teste: 
- pré-condições.
- pós-condições.
- critério de aceitação.
Documentação de Teste de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
175
 ■ Identificação dos casos de testes (o que testar).
 ■ Detalhamento da massa de entrada e saída.
 ■ Critérios especiais para geração da massa de teste.
 ■ Especificação das configurações de ambiente no qual o teste será executado 
(sistema operacional, ferramentas, origem de dados etc. – onde testar).
 ■ Definir o tipo de implementação do teste (automático/manual – como 
testar).
 ■ Definir o cronograma, ou seja, em qual fase esse teste será executado 
(quando testar).
 ■ Listar as interdependências, caso existam, entre os casos de teste. 
ELABORAÇÃO DE CENÁRIOS DE TESTE
Os critérios de teste servem para orientar o testador na geração de casos de tes-
tes. Os casos de testes gerados devem exercitar os elementos quando o software 
for testado. Um requisito que não é verificável, não terá um caso de teste asso-
ciado a ele. Existem métodos que auxiliam na escolha de critérios para a geração 
dos cenários de testes. 
 ■ Método Step-by-Step: tem por objetivo produzir rapidamente casos 
de testes completos para a especificação do sistema. Cobre: domínio 
entrada testando valores limites, valor médio, condições de erros e entra-
das inválidas.
 ■ Método PairWise de Teste ou Combinação Dupla: tem por objetivo 
cobrir ao menos um caso de teste para cada combinação de valores vali-
dados entre dois parâmetros. 
 ■ Gráfico de Causa e Efeito: tem por objetivo oferecer uma representação 
concisa das condições lógicas e das ações correspondentes, em que ela-
boramos causas (condições de entrada) e efeitos (ações) são relacionados 
para um módulo e um identificador é atribuído a cada um.
PROCESSO DE TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E176
 ■ Método Classe de Equivalência: tem por objetivo reduzir o número de 
caso de teste a um nível controlável, mas mantendo uma cobertura de 
teste razoável. 
 ■ Método Valores Limítrofes: tem por objetivo validar os valores limites 
do domínio de entrada de um determinado sistema. Ao invés de selecio-
nar qualquer valor de uma determinada classe de equivalência, os casos 
de testes selecionados são os valores das fronteiras.
Figura 2: Caso de teste como centro motivador do teste
Con�guraçõesRequisitos
O que motivou meu teste?
Quando devo testar? Como devo testar?
Caso de Teste
Onde devo testar?
Iteração Implementação
Fonte: Bastos et al. (2007).
PROCEDIMENTO DE TESTE
Especifica os passos necessários para executar um grupo de casos de teste (cená-
rios de teste ou funcionalidades do software). Muitos chamam o procedimento 
de teste de teste de roteiro de teste.
Documentação de Teste de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
177
O procedimento de teste é composto pelos seguintes campos:
 ■ Identificador: código que permite identificar de uma forma única o pro-
cedimento de teste.
 ■ Propósito: passos necessários para executar um grupo de casos de teste.
 ■ Requisitos especiais: descrever procedimentos especiais necessários para 
executar esse procedimento.
 ■ Passos do procedimento:
- Log: para analisar os resultados.
- Configurações: necessárias para executar o procedimento.
- Procedimento de início.
- Ações necessárias durante o procedimento.
- Medições.
- Suspensão.
- Reinício.
- Parar.
- Restaurar.
- Contingências.
“Como todas as outras etapas de teste, a validação tenta descobrir erros, 
mas o foco está no nível de requisitos — em coisas que ficarão imediata-
mente aparentes para o usuário final.”
(Pressman).
©shutterstock
PROCESSO DE TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E178
RELATÓRIOS DE TESTE DE SOFTWARE
Os relatórios dos testes do software 
registram os dados relativos à execu-
ção de um dos tipos de teste. Cada 
novo relatório deve ser adicionado 
sequencialmente aos relatórios dos 
testes do software. Os relatórios 
necessários para acompanharmos a 
evolução dos projetos de teste segundo 
a norma IEEE 829, são:
 ■ Relatório de Passagem de Itens.
 ■ Relatório de Log de Teste.
 ■ Relatório de Incidentes de Teste.
 ■ Relatório de Sumário de Teste.
A fase de elaboração dos testes tem como papel principal a atividade de 
elaboração dos cenários de teste, que serão executados, ou melhor, testa-
dos na fase seguinte. Um cenário é uma história hipotética que visa ajudar a 
solucionar um problema complexo, recriando ou visualizando um caminho 
a ser seguido. O conceito de “planejamento baseado em cenários” ganhou 
popularidade nos planejamentos militares e passou a ser utilizado em várias 
outras atividades que exigiam um planejamento detalhado. Um bom cená-
rio é aquele que pode ser usado por qualquer pessoa. O cenário de teste é 
o caminho a ser seguido ou a situação a ser testada. O cenário que serve de 
base para o teste é descrito numa especificação do sistema: por exemplo, 
na Unified Modeling Language (UML), é o caso de uso. O caso de teste é o 
cenário a ser executado para verificar se o que foi especificado está devida-
mente implementado. 
Fonte: Bastos, Rios, Cristalli e Moreira (2007). 
Relatórios de Teste de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
digo
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
179
Figura 3: Resumo do Fluxo de geração de documentos
Execução do Teste
Especi�cação do 
Projeto de Teste
Plano de Teste
Procedimentos 
de Teste
Diário de 
Teste
Diário de 
Teste
Especi�cação do 
Projeto de Teste
Especi�cação do 
Projeto de Teste
Relatório 
encaminhamento 
item de teste
Relatório 
Resumo de teste
Casos de 
Teste
Incidente 
de Teste
Incidente 
de Teste
Fonte: Norma IEEE 829, 1998.
Segundo o IEEE 829 esses seriam os Relatórios de Testes necessários para que 
o projeto atinja os seus objetivos. Agora vamos conhecer melhor cada relató-
rio. Preparado(s)?
RELATÓRIO DE PASSAGEM DE ITENS DE TESTE
O objetivo do relatório de passagem de itens é identificar os itens de teste que 
serão entregues para o teste, com a identificação do executor do teste e outros 
responsáveis, a localização onde estarão disponíveis para serem usados e baixa-
dos e o estado de cada um desses artefatos ou item de teste. 
Segundo o IEEE 829, o relatório de passagem de itens deve ter os seguin-
tes campos:
 ■ Identificador: deve ter um código único como identificador para o 
relatório.
PROCESSO DE TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E180
 ■ Itens passados: deve ter uma lista com a relação dos itens de teste.
 ■ Localização: deve ter a descrição do local onde estão armazenados os 
itens de teste e orientações de como acessá-los.
 ■ Estado: deve ter uma descrição do estado de cada item de teste que foi 
passado. 
 ■ Aprovações: deve ter um registro dos envolvidos no envio e recebimen-
tos do relatório. 
Deve fazer parte desse relatório todos os artefatos recebidos pela equipe de teste 
para a execução do seu trabalho. Um exemplo pode ser o plano de projeto, a 
relação dos casos de uso, a relação dos programas que deverão ser testados etc.
RELATÓRIO DE LOG DE TESTE
Segundo Bastos et al. (2007), o objetivo do relatório de log é descrever tudo 
de relevante que ocorre durante o projeto de teste, de tal forma que seja um 
documento básico de registros de todas as atividades desenvolvidas e outras 
ocorrências. Pode ser considerado o log um diário de ocorrências da atividade 
de execução dos testes. 
Conforme o IEEE 829, o relatório de log deve ter os seguintes campos:
 ■ Identificador: deve ter um identificador único para o relatório 
especificamente.
 ■ Descrição: deve descrever o que estava sendo testado, incluindo identi-
ficação, versão etc.
 ■ Entradas das atividades e eventos
- Descrição da execução: identificação do que estava sendo executado, 
por quem e quando.
- Resultados: de cada item executado.
- Registrar se o teste foi bem sucedido ou se ocorreram problemas.
- Informações sobre o ambiente.
Relatórios de Teste de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
181
- Registrar qualquer situação especial de ambiente necessária para a exe-
cução do item de teste.
- Eventos anormais.
- Registrar qualquer tipo de evento que tenha ocorrido e impedido a exe-
cução dos itens de teste ou que tenha contribuído para a sua não correta 
execução.
RELATÓRIO DE INCIDENTES DE TESTE
Conforme Bastos et al. (2007), o objetivo do relatório de incidentes de teste é 
registrar qualquer ocorrência no projeto de teste que necessite de alguma inves-
tigação. O uso mais comum desse relatório é o registro dos defeitos ocorridos 
durante o teste de sistema que devam ser transmitidos para a equipe de desen-
volvimento, para que ela tome as providências pertinentes.
O Relatório de Incidentes de teste deve ter o seguinte conteúdo básico:
 ■ Identificador do relatório: deve ter um identificador único do relatório.
 ■ Sumário da ocorrência: deve descrever em detalhes o que estava sendo 
feito quando ocorreu o incidente.
 ■ Descrição do incidente: o IEEE 829 sugere que seja descrito o incidente 
contendo os seguintes campos.
- Entradas.
- Resultados esperados.
- Resultados encontrados.
- Problemas.
- Data e hora da ocorrência.
- Sugestões de procedimentos a serem tomados.
- Ambiente.
PROCESSO DE TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E182
- Tentativas de contornar o problema.
- Testadores envolvidos.
- Observadores.
 ■ Impacto: o impacto causado pela ocorrência deve ser descrito.
RELATÓRIO DE SUMÁRIO DE TESTE
Para Bastos et al. (2007), o relatório de sumário de teste fornece um sumário das 
atividades realizadas durante um determinado projeto e mostra resumidamente 
as ocorrências durante todas as atividades realizadas. Esse relatório é usado para 
fechar o projeto de testes. 
O Relatório de Sumário de Teste deve ter o seguinte conteúdo básico:
 ■ Identificador do relatório: deve ter um identificador único do relatório.
 ■ Sumário: deve ser listado o que foi testado, registrando identificações, 
versões, o ambiente usado e os documentos referenciados e usados no 
projeto de testes.
 ■ Variações: devem ser listados os procedimentos adotados que sejam dife-
rentes do que foi inicialmente planejado, sobretudo, se não constar no 
plano de teste.
 ■ Avaliações do processo: devem ser relatadas todas as ocorrências que 
possa causar impacto na qualidade do software liberado para o cliente. 
 ■ Sumário dos resultados: devem ser listados todos os parâmetros que 
possam quantificar o projeto de testes que está sendo encerrado, por 
exemplo: número de casos de teste, número de execuções de cada caso 
de teste, número de defeitos encontrados etc.
 ■ Avaliação do teste: deve ser avaliado o projeto de teste e procurar identifi-
car, por exemplo, alguns riscos que ainda não foram mitigados e que podem 
causar problemas no momento em que o software entre em produção. 
Relatórios de Teste de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
183
 ■ Sumário de atividades: deve listar as pessoas envolvidas no projeto de 
testes, o número de horas consumidas por atividade no projeto, tempo 
total consumido e outras informações relevantes.
 ■ Aprovações: deve listar o nome das pessoas responsáveis pelas aprova-
ção do projeto de teste. 
Os relatórios de teste são compostos por quatro documentos: Diário de Tes-
te, Relatório de Incidente de Teste, Relatório Resumo de Teste e Relatório de 
Encaminhamento de Item de Teste. O Diário de Teste exibe os registros cro-
nológicos dos dados relevantes relacionados com a execução dos testes. O 
Relatório de Incidente de Teste documenta qualquer evento que ocorra du-
rante a atividade de teste e que necessite de análise posterior. No qual são 
relatados os erros que podem ocorrer durante da execução do teste. Esses 
erros podem ser causados tanto pela falha na construção do teste como por 
erros encaminhados para o responsável pela correção. O Relatório-Resumo 
de Teste mostra um resumo dos resultados das atividades de teste associa-
das com uma ou mais nesses resultados. os itens encaminhados para teste 
no caso de equipes distintas serem responsáveis pelas tarefas de desenvol-
vimento e de teste.
Fonte: Blanco (2012).
“A menor ‘unidade’ que pode ser testada em software orientado a objeto é 
a classe. O teste de classe é controlado pelas operações encapsuladas pela 
classe e o comportamento de estado da classe.”
(Pressman).
©shutterstock
PROCESSO DE TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E184
VALIDAÇÃO E VERIFICAÇÃO EM TESTES DE 
SOFTWARE 
Nesse tópico iremos aprender sobre as técnicas 
de verificação e validação e como são fun-
damentais para identificar os defeitos do 
software. Preparado(s)? Então, vamos seguir 
em frente. 
Pressman (2011, p. 402) define que 
“o teste de software é um elementode 
um tópico mais amplo, muitas vezes 
conhecido como verificação e validação 
(V&V). Verificação refere-se ao conjunto de 
tarefas que garantem que o software imple-
menta corretamente uma função específica. 
Validação refere-se a um conjunto de tarefas que asseguram que o software foi 
criado e pode ser rastreado segundo os requisitos do cliente”. 
Quando se executa os testes de software, um importante objetivo é o de veri-
ficar se o produto desenvolvido satisfaz os requisitos solicitados pelo cliente. Um 
software pode conter defeitos, porém, se algum trecho do código nunca for exe-
cutado, ou se o código não for exaustivamente executado, este defeito poderá 
não aparecer. 
O QUE É VERIFICAÇÃO? 
A verificação tem o objetivo de avaliar se o que foi planejado realmente foi rea-
lizado, se os requisitos, funcionalidades documentados foram implementados.  
Segundo Bastos et al. (2007, p. 30), “a verificação realiza inspeções e revisões 
sobre os produtos gerados pelas diversas etapas do processo de teste”. 
Validação e Verificação em Testes de Software 
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
185
O QUE É VALIDAÇÃO? 
A validação tem o objetivo de avaliar se o que foi entregue atende às expectativas. 
Ou seja, se os requisitos, independente do que foi planejado, estão implemen-
tados para atender ao negócio (cliente).  Segundo Bastos et al. (2007, p. 30), 
“avalia se o sistema atende aos requisitos do projeto (usuário). Os testes unitá-
rios, os de integração, de sistema e de aceitação podem ser classificados como 
testes de validação”.
Entendeu a diferença entre verificação e validação? Para facilitar e enten-
der bem a diferença entre verificação e validação, vamos responder às perguntas: 
 ■ Verificação: “Estamos construindo corretamente o sistema?”
 ■ Validação: “Estamos construindo o sistema correto?”
Conforme Bastos et al. (2007), a primeira pergunta diz respeito ao que foi cons-
truído e a segunda diz respeito ao entendimento do que era para ser construído. 
Durante o desenvolvimento do software, podem surgir diversos tipos de 
problemas e erros que acabam resultando na obtenção de um produto diferente 
daquele que se esperava. Para que tais sejam descobertos antes de o software 
ser liberado para utilização, existe as atividades de Validação e Verificação, ou 
“V&V”, com a finalidade de garantir que tanto o modo pelo qual o software está 
sendo construído quanto o produto em si esteja em conformidade com o espe-
cificado nos requisitos. 
Para Bastos et al. (2007), as atividades de V&V não se aplicam apenas ao 
produto final, mas devem ser conduzidas durante todo o processo de desenvol-
vimento do software, desde a sua concepção, desenvolvimento e sua entrega, 
pois englobam diferentes técnicas. 
Alguns autores costumam dividir as atividades de V&V em estáticas e dinâmi-
cas. As estáticas são aquelas que não requerem a execução ou mesmo a existência 
de um programa ou modelo executável para serem conduzidas. As dinâmicas 
são aquelas que se baseiam na execução de um programa ou de um modelo.
PROCESSO DE TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E186
VERIFICAÇÃO E VALIDAÇÃO NO CONTEXTO DA QUALIDADE 
As atividades de verificações e validações são consideradas úteis na garantia da 
qualidade do software, principalmente porque são fortemente recomendadas pelos 
modelos atuais de qualidade de software, tais como as normas ISO e o CMMI. 
Segundo o IEEE, as atividades de verificação e validação possuem técnicas 
de revisão, análise e teste para determinar se o sistema de software desenvol-
vido está de acordo com a análise de requisitos. A qualidade do software está 
diretamente relacionada à satisfação do cliente, sendo assim, as empresas estão 
percebendo a importância em produzir software com qualidade. Como já vimos 
anteriormente, o teste de software é um dos elementos importantes na garantia 
da qualidade de software.
Existe a Norma IEEE 1012 - Software Verification and Validation, que trata 
da padronização dos processos de verificação e validação de Software (Standard 
for Software Verification and Validation). Ela é aplicada durante o ciclo de vida 
de desenvolvimento do software, onde inclui o processo de aquisição, desenvol-
vimento, operação e manutenção de sistemas (Institute of Eletrical and Eletronics 
Engineers). 
Na Norma IEEE 1012, está descrito que o objetivo dela é estabelecer proce-
dimentos de verificação e validação, incluindo atividades e tarefas de apoio ao 
processo de ciclo de vida do software, garantindo que os requisitos do sistema 
estejam corretos, completos, consistentes e testados, e com isso, diminuindo os 
riscos operacionais do projeto, pois é verificado se os produtos de desenvolvi-
dos em determinada atividade estão de acordo com as exigências dessa fase, e 
se o software satisfaz às necessidades do usuário.
Validação e Verificação em Testes de Software 
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
187
A Norma IEEE 1012 possui três princípios básicos:
1. Prover um padrão mínimo de requisitos que seja escopo do documento 
denominado plano de verificação e validação do software - SVVPs 
(Software Verification and Validation Plans).
2. Definir especificações mínimas de atividades de verificação e validação 
(V&V), incluindo os requisitos de entrada e saída, as quais devem ser 
incluídas no documento SVVPs. 
3. Sugerir atividades de verificação e validação (V&V) opcionais para serem 
usadas sob medida no documento SVVPs, conforme os esforços V&V 
necessários.
A Norma IEEE 2012 também solicita que alguns itens básicos sejam definidos 
em cada fase do projeto, tais como:
 ■ Atividades de Verificação e Validação.
 ■ Critérios e métodos.
 ■ Entradas e Saídas.
 ■ Cronograma.
 ■ Recursos.
 ■ Riscos.
 ■ Regras e Responsabilidades. 
Para as atividades de Validação e Verificação que são associadas à fase de teste, 
ela recomenda a execução de testes de unidade, integração, sistema e aceitação, a 
documentação dos resultados obtidos e defeitos detectados na execução dos testes. 
©shutterstock
PROCESSO DE TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E188
FERRAMENTAS DE TESTE DE SOFTWARE
Algumas ferramentas prestam auxílio diretamente à observação de compor-
tamento do código, como os depuradores, monitores (profilers) e geradores de 
casos de teste.
A automação de testes consiste em testar um software com outro software. 
Confuso? A automação é como robôs (vários scripts) construídos para usar o 
sistema no lugar dos usuários, podem ser mais rápidos na execução dos testes e 
detecção dos erros e trabalham em uma escala maior. 
Para Bastos et al. (2007, p. 87), “as ferramentas de teste podem aliviar o fardo 
da produção e da execução de teste, da geração de informações e da comunica-
ção. A escolha da ferramenta apropriada é um aspecto importante do processo 
de teste”. Mas vamos a uma pergunta: qual a diferença entre ferramentas e téc-
nicas de teste? Na unidade anterior, vimos várias técnicas de teste, e os conceitos 
de ferramentas e técnicas são importante no processo de teste. Conforme Bastos 
et al. (2007), o testador precisa entender as técnicas de teste primeiro, para que 
depois consiga entender quais ferramentas de teste devem ser utilizadas com 
cada técnica. Pois, a ferramenta é um recurso para o testador, mas sem a técnica 
é insuficiente para conduzir os testes. 
Ferramentas de Teste de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
189
Sobre as ferramentas de teste, Bastos et al. (2007, p. 87) menciona que:
A seleção da ferramenta afeta aeficiência e a eficácia do teste. As fer-
ramentas de teste são o apoio dos profissionais da área de teste, pois 
cobrem grande parte das atividades de teste e são aplicáveis em todas 
as fases do ciclo de vida do desenvolvimento do software. Algumas téc-
nicas são manuais, e outras, automáticas, algumas fazem testes estáti-
cos, e outras, dos dinâmicos, algumas avaliam a estrutura do sistema e 
outras, sua função.
A atividade de teste gera grande número de informações que, muitas vezes, 
necessitam de várias repetições e isso exige muita coordenação e comunicação 
entre a equipe. Mas por que automatizar? Para responder esta pergunta, vamos 
conhecer os objetivos da automação de testes:
 ■ Aumenta a consistência e abrangência dos testes.
 ■ Reduz o tempo ou esforço de teste.
 ■ Diminui o custo dos testes.
 ■ Aumenta a produtividade do desenvolvimento de software como um todo.
 ■ Aumenta a qualidade do produto final.
Temos várias razões para usar a automação de testes. Mas o que devemos auto-
matizar no projeto de teste? Quais testes são interessantes serem automatizados? 
Vamos listar o que devemos automatizar: 
 ■ Testes de regressão.
 ■ Smoke tests (teste de fumaça).
 ■ Tarefas repetitivas e que demandam muito esforço.
 ■ Cálculos matemáticos.
 ■ Funcionalidades críticas.
Entretanto, nem todos os testes devem ser automatizados. Mas a automação dos 
testes faz com que a equipe de testes seja liberada para a realização de testes mais 
complexos que exigem um ser humano ou testes mais específicos, como os de 
segurança, usabilidade, entre outros. Temos que alertar que a automação de testes 
exige que o ambiente de testes esteja com os dados rigorosamente controlados.
PROCESSO DE TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E190
Hoje no mercado existem diferentes versões desse tipo de ferramenta. Os 
geradores de casos de teste estruturais criam casos de testes com base na estrutura 
do código-fonte. Um exemplo de ferramenta é a TestComplete, da AutomatedQA, 
que pode ser integrada às plataformas de desenvolvimento mais comuns atual-
mente. Geradores funcionais definem os casos de teste a partir das especificações 
do código, como o AETG Web Service. Como a ferramenta não depende do códi-
go-fonte, a rigor pode ser utilizado com qualquer linguagem de programação.
A aplicação de critérios de teste (escolher o que será testado) sem o apoio 
de ferramentas automatizadas tende a ser uma atividade propensa a erros e 
limitada a programas muito simples. Tal aspecto motiva o desenvolvimento de 
ferramentas automáticas para auxiliar na condução de testes efetivos e na aná-
lise dos resultados obtidos por estes testes. 
Apesar de não auxiliarem diretamente na determinação das entradas de um 
programa, necessárias para a execução de caminhos específicos, grande parte 
das ferramentas de teste apresenta ao usuário os requisitos de teste exigidos para 
que os critérios sejam satisfeitos. Assim, de certa maneira, orientam e auxiliam 
o usuário na elaboração dos casos de teste.
Abaixo, segue uma lista com algumas das ferramentas para testes de sof-
tware mais utilizadas:
 ■ JUnit: é um framework altamente eficaz e largamente utilizado na cria-
ção e execução de testes unitários de códigos. 
 ■ Selenium: ferramenta usada para a realização de testes integrados e de 
aceitação. 
 ■ JMeter: ferramenta com o propósito principal para testes de carga e stress 
de aplicações e pode ser usado para testes integrados e de aceitação. 
 ■ Clover: ferramenta para análise de cobertura dos testes existem na 
aplicação, integrado a várias IDEs – Eclipse. Existem diversas opções 
semelhantes: JCoverage, Cobertura etc.
Ferramentas de Teste de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
191
CARACTERÍSTICAS DOS TESTES AUTOMATIZADOS
Os testes automatizados possuem algumas características, para que sejam rea-
lizados com precisão:
Conciso: devem ser simples, dentro do possível. 
Explícito: devem ser relatados os desvios que ocorrem durante a execução.
Repetível: devem ser executados quantas vezes forem necessário. 
Robusto: devem produzir os mesmos resultados consistentes e sem altera-
ções externas ou de ambiente.
Necessário: devem identificar desvios entre o que foi especificado e o que 
foi desenvolvido.
Clareza/Manutenção: devem ter instruções de códigos claras e de fácil 
entendimento. 
Eficiente: devem ter desempenho satisfatório.
Independente: devem satisfazer as precondições e permitir a execução em 
qualquer ordem. 
Rastreável: devem ser restreáveis a partir dos requisitos e demais origens. 
Mas como escolher a ferramenta de testes ideal? Para isso, segue abaixo uma 
checklist com alguns critérios que podem ser utilizados para escolher a ferra-
menta certa.
 ■ Facilidade de uso.
 ■ Manuais e guias com informações utéis.
 ■ Suporte técnico e treinamento.
 ■ Integração com outras ferramentas.
 ■ Possibilidade de automatizar várias tecnológias.
 ■ Linguagem de script robusta.
 ■ Recursos de depuração de scripts.
 ■ Suporte para múltiplas plataformas e navegadores.
 ■ Reconhecimento de objetos e suas propriedades.
PROCESSO DE TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E192
 ■ Recursos para comparação de arquivos (*.txt, *.pdf etc).
 ■ Recursos para acesso a banco de dados.
 ■ Recursos para a criação de testes dirigidos a dados.
 ■ Execução dos testes distruibuídos em múltiplos computadores simultâneos.
 ■ Geração de relatórios detalhados com o resultado da execução dos testes.
Sommerville (2011, p. 466) define que
uma organização tem a intenção de introduzir uma nova ferramenta de 
teste de software. Antes de introduzir a ferramenta, em um determina-
do momento você registra o número de defeitos de software descober-
to. Essa é uma baseline de avaliação da eficácia da ferramenta. Depois 
de algum tempo usando a ferramenta, esse processo é repetido. Se mais 
defeitos foram encontrados durante o mesmo período, depois que a 
ferramenta foi introduzida, você poderá decidir se ela fornece suporte 
útil para o processo de validação de software. 
PROCESSO DE AUTOMAÇÃO DE TESTES
O processo de automação de testes, consiste nas seguintes etapas:
Decidir automatizar os testes: estudar o retorno de investimentos, os para-
digmas e tipos de testes existentes para evitar falhas. 
Aquisição de uma ferramenta de automação de testes: definir critérios e 
o processo de aquisição das ferramentas. Demonstrar os benefícios, limitações 
e restrições da ferramenta.
Introdução da automação de testes nas organizações: conduzir os proce-
dimentos e melhores práticas que serão adotadas para a atividade de automação 
de testes. 
Planejamento, projeto e desenvolvimento dos testes automáticos: plane-
jar e desenvolver os testes automatizados de um projeto.
Ferramentas de Teste de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
193
Execução e controle da automação de testes: executar os testes automa-
tizados desenvolvidos. Também coletar métricas para o controle, por exemplo, 
indicadores de progresso, cobertura e eficiência. 
Revisão e melhoria do processo: conduzir avaliações com o objetivo de 
melhorias no processo de automação de testes.
“Ao desenvolver um cronograma, divida o trabalho, anote as dependências 
entre as tarefas, atribua esforço e tempo para cada tarefa e defina responsa-
bilidades, resultados e pontos de controle.”
(Pressman).
O teste de software é uma das principais atividades realizadas para melho-
rar a qualidade de um produto em desenvolvimento. Seu principal objeti-
vo é revelar a presença de erros no software o mais cedo possível no ciclo 
de desenvolvimento de software, buscando minimizar o custoda correção 
dos mesmos. Embora o teste de software seja uma atividade bastante com-
plexa, geralmente ela não é realizada de forma sistemática devido a uma 
série de fatores como limitações de tempo, recursos e qualificação técnica 
dos envolvidos. A automação de parte do teste de software tem sido vista 
como a principal medida para melhorar a eficiência dessa atividade, e vá-
rias soluções têm sido propostas para esta finalidade. A automação do teste 
consiste em repassar para o computador tarefas de teste de software que 
seriam realizadas manualmente, sendo feita geralmente por meio do uso de 
ferramentas de automação de teste. 
Fonte: Fantinato et al. (2002).
©shutterstock
PROCESSO DE TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E194
MÉTRICAS E MEDIÇÃO
Conforme Pressman (2011, p. 538), “um elemento-chave de qualquer processo de 
engenharia é a medição. Você pode usar medidas para melhorar o entendimento 
dos atributos dos modelos criados e para avaliar a qualidade dos produtos ou sis-
temas construídos. Por sua natureza, a engenharia é uma disciplina quantitativa”. 
Mas vocês devem estar se perguntando: por que medimos e avaliamos? 
Medimos principalmente para obter controle de um projeto e, portanto, poder 
gerenciá-lo. Medimos e avaliamos para estimar se estamos pertos ou longe dos 
objetivos definidos no plano em termos de conclusão, qualidade, compatibili-
dade com os requisitos etc.
E por que é importante medir? Segundo Pressman (2011), sempre haverá 
um elemento qualitativo no desenvolvimento do software e, em alguns casos, a 
avaliação qualitativa pode não ser suficiente. A métrica proporciona uma base 
por meio da qual a análise, projeto, codificação e teste podem ser conduzidos 
mais objetivamente e avaliados de maneira mais quantitativa.
Para entendermos melhor sobre métricas e medição, vamos apresentar alguns 
conceitos relacionados a métricas, que serão fundamentais para se entender o 
conteúdo a ser tratado nos próximos tópicos. 
Métricas e Medição
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
195
Mas qual a diferença entre uma medida e uma métrica? E os indicadores? São 
termos que são usados com frequência e que em algum momento você já ouviu 
falar. Vamos apenas nos ater ao contexto de engenharia de software. Segundo 
Pressman (2011, p. 539): 
 ■ Medida: indicação quantitativa da extensão, quantidade, capacidade ou 
tamanho de algum atributo de um produto ou processo. 
 ■ Medição: é o ato de determinar uma medida. O IEEE define métrica como 
“uma medida quantitativa do grau com o qual um sistema, componente 
ou processo possui determinado atributo”. 
 ■ Indicador: é uma métrica ou combinação de métricas que proporcionam 
informações sobre o processo de software, em um projeto de software ou 
no próprio produto. Um engenheiro de software coleta medidas e desen-
volve métricas para obter indicadores.
 Pressman (2011, p. 594) define que
o principal objetivo da engenharia de software é produzir um sistema, 
aplicação ou produto, de alta qualidade, dentro de um prazo que satis-
faça as necessidades do mercado. Para atingir esse objetivo, devem-se 
aplicar métodos eficazes, combinados com modernas ferramentas den-
tro do contexto de um processo de software bem desenvolvido. Além 
disso, um bom engenheiro de software (e bons gerentes de engenharia 
de software) deve medir se a alta qualidade será obtida.
As métricas de processo têm impacto de longo prazo. Seu objetivo é melhorar o 
próprio processo. As métricas de projeto muitas vezes contribuem para o desen-
volvimento de métricas de processo.
Sommerville (2011) define que a medição tem um objetivo a longo prazo 
que é o de ser usada para revisões e fazer julgamento sobre a qualidade de sof-
tware. Segundo o autor, ao usar a medição de software, o sistema poderia ser 
parcialmente avaliado e com isso deduzir um valor para a qualidade do sistema 
e se ele atingir o valor estipulado, ele poderia ser aprovado. A medição também 
pode ser usada para realçar áreas do software que podem ser melhoradas.
PROCESSO DE TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E196
CONCEITOS RELACIONADOS A MÉTRICAS DE TESTE DE 
SOFTWARE
Conforme Trodo (2009), “o enfoque das métricas de teste de software são a pro-
dutividade e qualidade. Quando medimos um processo, estamos avaliando a 
produtividade, e quando estamos medindo um produto, a qualidade é que está 
sendo avaliada”. 
A respeito das métricas de teste, o referido autor pontua que:
As métricas de teste são um padrão de medidas muito útil para a veri-
ficação da efetividade e da eficiência de diversas atividades do desen-
volvimento de software. Também são usadas para prover informações 
como estimativas do esforço necessário para o teste. É importante que 
elas sejam capturadas e utilizadas corretamente para que possam auxi-
liar na melhoria do processo de desenvolvimento do software através 
de informações objetivas e pragmáticas para iniciativas de mudanças 
do processo (TRODO, 2009, p. 15).
Trodo (2009) menciona que as métricas de teste subdividem-se em:
 ■ Métricas básicas: obtidas diretamente do esforço do teste. Exemplo de 
métricas básicas: quantidade de casos de teste criados, executados, bloquea-
dos, reexecutados, que passaram, que falharam e que estão sob investigação.
 ■ Métricas derivadas: obtidas pelo gerente ou pelo líder de teste, por meio 
da conversão das métricas básicas em dados mais úteis. Exemplo de métri-
cas derivadas: percentual dos testes concluídos, da cobertura dos testes, 
dos casos de testes que passarão, ou que estão bloqueados, das falhas na 
primeira execução, dos defeitos, do retrabalho, da efetividade e da efici-
ência dos testes, a taxa de defeitos descobertos e o custo de remoção dos 
defeitos.
Conforme Trodo (2009, p. 16)
as principais medidas de um teste são a cobertura e qualidade. A cober-
tura diz respeito à abrangência do teste e a qualidade é uma medida de 
confiabilidade, estabilidade e desempenho do objetivo do teste. A avalia-
ção da cobertura fornece uma medida para avaliar a conclusão dos testes 
e a avaliação dos defeitos detectados indica a qualidade do software.
Métricas e Medição
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
197
Alguns atributos podem ajudar os testadores nas métricas de teste. Para 
Trodo (2009) os atributos são:
 ■ Senso de antecipação: é baseado na experiência e significa pensar adiante, 
nos tipos de métricas que podem ser úteis. 
 ■ Disciplina: auxilia os testadores a lidaram com o fato de que o serviço de 
testar é uma tarefa repetitiva e, por vezes, tediosa. 
 ■ Uso de ferramentas: ajuda os testadores a gerenciar melhor a tarefa de 
testar o software.
Conforme Trodo (2009) alguns objetivos nos guiam para usamos as métri-
cas de teste:
 ■ Analisar os defeitos.
 ■ Analisar a eficácia e a eficiência dos testes e do processo como um todo.
 ■ Avaliar a produtividade do processo.
 ■ Analisar o retorno de investimento.
 ■ Determinar o esforço para automação dos testes.
 ■ Calcular o tempo e os recursos para automação dos testes.
 ■ Avaliar o andamento dos testes.
 ■ Planejar os recursos, prazos e benefícios do processo de testes.
 ■ Identificas áreas que necessitam de melhorias.
 ■ Melhorar a exatidão das estimativas.
 ■ Formar uma baseline para as estimativas.
 ■ Auxiliar no gerenciamento do projeto e da execução dos testes.
 ■ Auxiliar nos contratos de software.
 ■ Auxiliar no relacionamento com os clientes.
 ■ Auxiliar na melhoria do processo de desenvolvimento do software.
 ■ Avaliar os benefícios de novos métodos e ferramentas.
PROCESSO DE TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610de 19 de fevereiro de 1998.
VU N I D A D E198
 ■ Embasar eventuais solicitações de novas ferramentas e treinamento.
 ■ Avaliar o impacto na qualidade e na produtividade do produto ou do pro-
cesso que eventuais variações podem causar.
 ■ Viabilizar a tomada de decisão de forma ágil.
 ■ Detectar tendências nos dados.
 ■ Identificar áreas de riscos.
 ■ Visualizar se o produto está pronto para a liberação ao cliente.
 ■ Indicar a qualidade de forma geral.
Segue uma lista de perguntas que podem ser feitas e respondidas quando se usa 
métricas de software:
 ■ Quando parar de testar?
 ■ Quanto tempo falta para terminar o ciclo de testes?
 ■ Quanto já foi testado?
 ■ Os testes serão concluídos dentro do prazo previsto?
 ■ Quanto teste ainda tem que ser feito em determinada área?
 ■ Já foi testado o suficiente?
 ■ Qual o custo dos testes?
 ■ Qual o custo para corrigir os defeitos?
 ■ Quantos defeitos podem esperar?
 ■ Quais os tipos de defeitos encontrados?
 ■ Quantos defeitos já foram corrigidos?
 ■ Quais as áreas do software que têm mais ou menos defeitos?
 ■ Quão estável é a funcionalidade que está sendo testada?
 ■ Qual a técnica de teste que é mais efetiva?
Métricas e Medição
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
199
 ■ Estamos testando de forma difícil ou inteligente?
 ■ Temos um programa de teste robusto ou um suíte de testes fraca?
 ■ Quais os defeitos prioritários?
 ■ Qual o testador que encontrou mais defeitos?
 ■ Quantos defeitos foram localizados por um determinado testador?
 ■ Quantos defeitos foram encontrados pelo usuário?
Para Trodo (2009), é difícil para a equipe de testes responder a todas as pergun-
tas. Conforme o autor cita, por exemplo, para a pergunta “Quanto já foi testado?”, 
o uso da métrica da cobertura dos testes, que é o percentual dos testes que já 
foram concluídos, para respondê-la. Se os testadores não têm as estimativas não 
conseguem responder as perguntas, pois não sabem exatamente o quanto ainda 
precisam testar e assim achar que testaram o suficiente.
MÉTRICAS DE TESTE DE SOFTWARE EXISTENTES
As métricas de teste de software existentes, segundo Trodo (2009), são:
Métricas de produto: servem como auxiliar no controle da qualidade do 
produto que está sendo testado. Temos vários relatórios que são gerados para 
esse tipo de métrica, como os relatórios de defeitos no produto. Exemplo de 
métricas de produto:
Como muitos fatores afetam o trabalho de software, não use métricas para 
comparar indivíduos ou equipes.
(Pressman). 
PROCESSO DE TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E200
 ■ Número de ocorrências.
 ■ Status das ocorrências.
 ■ Índice de Densidade de defeitos.
 ■ Índice de Severidade de defeitos.
 ■ Tempo para arrumar um defeito.
 ■ Tempo médio para encontrar um defeito.
 ■ Qualidade de falhas encontradas no produto.
 ■ Tipos de defeitos encontrados.
 ■ Cobertura dos testes.
 ■ Efetividade de Caso de teste.
 ■ Defeitos por quantidade de linhas de código (Kloc).
 ■ Situação ou Tendência dos defeitos em função do tempo.
 ■ Providências adotadas em relação aos defeitos.
 ■ Defeitos por módulo.
 ■ Defeitos por tecnologia utilizada.
Métricas de Processo: servem para auxiliar no controle da qualidade do pro-
cesso de testes. Segue alguns exemplos de métricas de processo:
 ■ Número de Casos de teste.
 ■ Taxa de falhas na primeira execução dos Casos de Teste.
 ■ Custo dos testes.
 ■ Curva S.
 ■ Curva Zero Bug Bounce.
 ■ Relação entre defeitos e ocorrências.
 ■ Ocorrências pendentes de correção.
Métricas e Medição
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
201
 ■ Probabilidade de defeitos.
 ■ Mudanças no escopo.
 ■ Densidade de defeitos por Unidade.
Métricas de Projeto: os relatórios sobre o status do projeto, o andamento do 
processo, como funcionalidade, qualidade etc., despesas e outros consumos de 
recursos, são produzidos usando as métricas de projeto. Exemplos de métricas 
de projeto:
 ■ Tempo de teste estimado X Tempos de teste efetivamente utilizado.
 ■ Fator de segurança.
 ■ Tempo necessário para executar um teste.
 ■ Tempo disponível para o esforço de teste.
 ■ Taxa de esforço de teste.
 ■ Categoria de defeitos.
As métricas de teste são, geralmente, identificadas quando se inicia o projeto e 
devem ser quantificáveis, de fácil coleta, simplificadas e que tenham um propó-
sito. As métricas que foram coletadas devem ser sempre exploradas na avaliação 
do andamento e da integridade do projeto e devem ser guardadas para uso no 
futuro em outras estimativas de projetos novos. 
PROBLEMAS NA UTILIZAÇÃO DAS MÉTRICAS DE TESTE DE 
SOFTWARE
Conforme Trodo (2009, p. 81), “as métricas de teste de software são bastante úteis 
ao processo de teste, porém, é importante observar algumas dificultadas rela-
cionadas ao assunto. As questões tratadas variam de problemas gerenciais e de 
relacionamento a observações específicas sobre como o uso isolado das métri-
cas pode fornecer informações equivocadas”.
PROCESSO DE TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E202
Abaixo, seguem algumas dicas de cuidado a serem adotadas quando se ana-
lisa a qualidade:
 ■ As métricas de teste por si só não fornecem a percepção adequada da real 
qualidade aplicada.
 ■ As métricas de teste não devem ser analisadas isoladamente. 
 ■ O estudo da origem dos problemas como parte da análise das métricas 
provê resultados mais confiáveis.
 ■ Uma análise sistemática e completa das métricas de teste é importante 
para que sejam consideradas como ferramentas confiáveis para medir a 
qualidade da aplicação.
 ■ As tendências de algumas métricas de teste podem ser analisadas por 
diversos ciclos de teste, enquanto outras são relativas a um ciclo de teste 
específico.
O que achou das métricas de teste? Difícil? O que envolve a qualidade pode ser 
considerado um conceito complexo, porque pode significar diferentes situações 
para diferentes pessoas. Assim, como temos diferentes empresas com diferentes 
projetos, não há uma simples medida para qualidade de software que seja acei-
tável para todos. Mas sempre devemos pensar que para melhorar a qualidade de 
software, devemos definir quais aspectos de qualidade que interessa a empresa 
para depois decidir quais serão usados e, depois, como medi-los. 
Gerência de Risco em Teste de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
203
“Medindo-se características da especificação, é possível obter informações 
quantitativas sobre peculiaridade e totalidade.”
(Pressman).
Assim como qualquer outra disciplina de engenharia, o desenvolvimento 
de software requer um mecanismo de medição para obter as informações 
sobre a execução do processo necessárias para o seu correto entendimento 
e avaliação. Medir é o processo por meio do qual números ou símbolos são 
atribuídos a características das entidades do mundo real de forma a tornar 
possível caracterizar cada entidade por meio de regras claramente defini-
das. O uso de métricas nos ajuda a entender e a interagir com o mundo para, 
então, poder melhorá-lo. Muitas métricas foram propostas e aplicadas em 
casos práticos a fim de alcançar os seguintes objetivos: i) melhorar o enten-
dimento sobre o processo, produto, recursos e ambiente de desenvolvimen-
to e, assim, estabelecer bases para comparação entre medições; ii) avaliar o 
andamento do projeto comparando com dados planejados; iii) fazer previ-
sões sobre o futuro andamento do projeto baseado em comportamentos 
passados; iv) promover melhorias identificando falhas, ineficiências e outras 
oportunidades paramelhorar a qualidade do produto e o desempenho do 
processo.
Fonte: Gomes, Oliveira e Rocha (2001). 
©shutterstock
PROCESSO DE TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E204
GERÊNCIA DE RISCO EM TESTE DE SOFTWARE
Bastos et al. (2007, pg. 89) define que “a análise de riscos em projetos de teste 
de software, embora tenha suas características próprias, deve seguir as mesmas 
regras e metodologias aplicadas a projetos de software em geral”. A atividade 
de teste é bastante cara. Podendo custar até 45% do valor inicial do projeto. A 
grande competitividade, o surgimento de softwares cada vez mais complexos e 
a necessidade de qualidade relacionada à satisfação do cliente, justificam este 
investimento. 
A análise de risco, segundo Bastos et al. (2007) é tratada no escopo de projeto 
pelo PMI e de processo pelo modelo CMMI e, em cada uma dessas abordagens, 
o projeto ou processo de Teste de Software pode perfeitamente ser enquadrado.
Quando avaliamos os riscos de um projeto, conforme Bastos et al. (2007), 
estamos buscando aqueles fatos que poderão acarretar em perdas para a empresa. 
Não podemos sempre aliar um risco a uma perda. Um risco pode estar sempre 
presente, mas nem sempre ele gera uma perda. Existem riscos que sempre se 
transformam em perdas. Para Bastos et al. (2007) um avião sempre corre risco 
de cair, mas a perda só existirá se isso ocorrer. Resumindo, podemos dizer que 
o risco é uma probabilidade de ocorrência de uma perda para a empresa. 
Gerência de Risco em Teste de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
205
Conforme Bastos et al. (2007) exemplifica, hoje, qualquer empresa corre risco, 
se em algum momento seus computadores pararem de funcionar. Um site fora 
do ar pode trazer muitos prejuízos para uma empresa. O risco para uma empresa 
está relacionado ao grau de dependência em relação ao seu equipamento. Agora, 
imagine, a ocorrência de erros de software e os prejuízos a uma empresa caso o 
seu software seja interrompido? Se por ventura o sistema de faturamento sofra 
algum defeito e ele seja interrompido e a empresa deixe de receber o dinheiro? 
Segundo Bastos (2007), devido a estes problemas, gerentes de TI passaram a 
investir para evitar riscos de defeitos em seus softwares, criando planos de con-
tingência para contornar os problemas. 
CONCEITUANDO RISCO
Quando falamos de risco, estamos sempre pensando na perda que a empresa 
pode ter devido a sua ocorrência. Esta definição extraída do dicionário Houaiss, 
é bastante clara: risco é a probabilidade de insucesso, de malogro de determi-
nada coisa, em função de acontecimento eventual, incerto, cuja ocorrência não 
depende, exclusivamente, da vontade dos interessados. 
Tratar riscos depende de algumas decisões objetivas que poderão prevenir 
sua ocorrência ou, na pior das hipóteses, evitar que a sua ocorrência se reverta 
em sérios prejuízos.
Mas o que leva um risco a se tornar uma perda? Ele se torna potencialmente 
uma perda quando ocorre a ameaça de sua ocorrência. E como elas podem ser 
reduzidas? Podem ser reduzidas com o uso de mecanismos de controle, que aju-
dam a controlar as ameaças e com isso evitar a sua ocorrência. 
“Medindo-se características da especificação, é possível obter informações 
quantitativas sobre peculiaridade e totalidade.”
(Pressman).
PROCESSO DE TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E206
Segundo Bastos et al. (2007), “quando os meios de controle são insuficien-
tes ou inadequados para administrar a ocorrência de um risco, surgem então, 
vulnerabilidades”. Para os autores, a análise de riscos é o processo de avaliar ris-
cos, ameaças, controles e vulnerabilidades. 
Muitas informações? Para compreendermos melhor o gerenciamento de ris-
cos, vamos conhecer alguns conceitos, conforme Bastos et al. (2007). 
Riscos: uma perda grande para a empresa e pode ser medido usando a aná-
lise de risco.
Análise de risco: avaliação dos recursos de informação, seus controles e 
suas vulnerabilidades. 
Ameaça: capacidade de alguém explorar a vulnerabilidade de um sistema.
Vulnerabilidade: é uma falha de projeto, implementação ou programação. 
Controle: maneira de reduzir as causas de riscos, evitando a sua ocorrência 
ou reduzindo a sua frequência. 
Então, podemos disser que os riscos podem causar grandes danos às empre-
sas, se caso vir a acontecer uma ameaça de ocorrência. Seguindo informações de 
Bastos et al. (2007), o risco é uma materialização de uma ameaça e com a aná-
lise de riscos podemos identifica-los e com isso medir seu nível de severidade. 
Podemos dividir os riscos presentes na área de tecnologia, ligados ao uso 
de computadores em: riscos por ameaça física ou riscos decorrentes da ação 
de pessoas. No caso de riscos por ameaça física, temos terremotos, incêndios, 
enchentes etc. No caso de riscos decorrentes da ação de pessoas, temos: erros de 
documentos preenchidos errados, erros durante a operação do sistema, erros de 
alimentação de dados, entre outros. 
RISCOS RELATIVOS AO TESTE DE SOFTWARE
A atividade de testar o software está bastante ligada ao risco. Teste custa dinheiro, 
e quanto maior for a cobertura dos testes, tanto mais terá que ser investido para 
que haja a garantia de que nenhum defeito irá ocorrer quando o software estiver 
em produção. As empresas concordarão em investir em teste, caso a ocorrência 
de um defeito seja um risco para o negócio.
Gerência de Risco em Teste de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
207
Conforme Bastos et al. (2007), os testes exaustivos visam garantir que nenhum 
defeito irá ocorrer quando o software for entregue, certamente não será execu-
tado pela maioria das empresas. Geralmente, as equipes de teste das empresas 
procuram um nível de cobertura que minimizem a possibilidade de defeitos gra-
ves, pois existem prazos a serem cumpridos. E o que os testadores podem fazer 
para minimizar esses defeitos? Os testadores podem procurar cobrir as partes 
mais importantes do software, em que estão os maiores riscos para os negócios. 
O risco é um dos elementos mais importantes para ser considerado na elabora-
ção do projeto de testes, por isso, precisa ser analisado e incluído no plano de 
testes, porque esses riscos possuem níveis de prioridade altos.
Segundo Bastos et al. (2007, p. 93), “é importante lembrar que, quanto mais 
bem organizada a equipe de testes, melhores serão os resultados e é sempre bom 
lembrar que o risco é um dos elementos mais importantes a ser trabalhado no 
momento de se elaborar o projeto de testes”. Assim, ao fazermos uma análise 
dos riscos devemos pensar em:
 ■ Probabilidade de ocorrência do risco.
 ■ O impacto e a perda que estão associados a esse risco.
Os riscos podem estar associados, por exemplo, ao uso de uma nova tecnologia 
ainda não perfeitamente dominada pela equipe de desenvolvimento, ou pelas 
prioridades estabelecidas para algumas funcionalidades do negócio. 
Mas como saber qual o número de testes a ser executado para minimizar 
os defeitos ou a probabilidade para que não ocorrerem? Segundo Bastos et al. 
(2007), o total de testes a ser executado está diretamente relacionado ao total 
de riscos envolvidos. Uma análise de riscos bem feita, com uma adequação dos 
recursos disponíveis pela equipe, ajuda a estabelecer quais as prioridades do que 
será testado. Na tabela 2, podemos analisar que a maior prioridade de teste é 
dada a funcionalidade em que o impacto causado pelo defeito e a probabilidade 
de ocorrência de um risco são grandes (AA). 
PROCESSO DE TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E208
Tabela2: Qualificação dos riscos - Probabilidade versus impacto 
IMPACTO QUE O RISCO CAUSA AO NEGÓCIO
PROBABILIDADE DE OCORRÊNCIA DO RISCO
Alta Média Baixa
Alto AA AM AB
Médio MA MM MB
Baixo BA BM BB
Fonte: Bastos et al. (2007).
Bastos et al. (2007, p. 94) pontua que “os riscos mudam no decorrer do tempo 
– o que era um risco alto em um determinado momento pode deixar de ser no 
momento seguinte, e o que é risco em um determinado ambiente pode deixar 
de ser um risco em outro”. 
RISCOS DO PROCESSO DE TESTE
Conforme Bastos et al. (2007) se considerar-nos apenas a atividade de testar, alguns 
riscos básicos podem ser caracterizados. Segue uma lista dos possíveis riscos básicos:
Orçamento: o orçamento é insuficiente para executar o teste completo e 
com isso as prioridades podem sofrer mudanças.
Qualificação da equipe técnica de teste: deve ser avaliado se a equipe de 
teste está preparada com a tecnologia adotada. 
Ambiente de teste: o ambiente de teste deve estar o mais próximo do ambiente 
do cliente.
Ferramentas: a escolha de ferramentas pode ser um projeto específico que 
poderá conter seus próprios riscos. 
 “Quanto mais você sabe, melhor você estima. Portanto, atualize suas esti-
mativas à medida que o projeto avança.”
(Pressman).
Gerência de Risco em Teste de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
209
Metodologias: executar testes sem uma metodologia adequada é um risco 
que podem trazer resultados indesejados à qualidade do sistema.
Cronograma de recebimento de programas para teste e Cronograma 
para devolução: negociar prazos adequados e que atendam ao padrão mínimo 
de qualidade estabelecido para o negócio. 
Testware: deve ser criada uma metodologia que permita guardar a documen-
tação para uso futuro e o fato de não precisarmos refazer esse material diminui 
os riscos dos testes malfeitos. 
Novas tecnologias: o uso de novas tecnologias e novos ambientes para ope-
ração dos sistemas trouxe um novo elemento de risco para as empresa e com isso 
a equipe de testes deve dominar o uso de novas tecnologias. 
DETERMINAÇÃO DA MAGNITUDE DOS RISCOS
Segundo Bastos (2007, p. 96), “o problema muitas vezes consiste em determinar como 
classificar o risco e qual o custo de criação de um controle que evite a ocorrência 
desse risco”. A relação custo-benefício precisa ser avaliada antes de tomar qualquer 
decisão, porque o custo do controle do risco pode ser maior do que o risco mesmo. 
O QAI – Quality Assurance Institute estabelece que um risco pode ser deter-
minado das seguintes formas:
Intuição ou julgamento: um técnico qualificado e experiente da área de teste 
usa a sua intuição, aliado a sua experiência, para dizer que a ocorrência de um risco 
pode custar mais caro do que os controles necessários para que ele não ocorra. 
Consenso: consenso na equipe de que aquele risco tem um grau alto de seve-
ridade, nesses casos, não há necessidade de medir-se financeiramente o custo do 
risco, pois há consenso que a sua ocorrência causará um prejuízo muito grande, e 
o bom senso indica a criação de algum tipo de controle que evite a sua ocorrência. 
Fórmula de Risco: magnitude do risco é calculada por meio de uma fórmula. 
Existem dados financeiros que permitem medir o custo da perda pela ocorrên-
cia do risco. Medindo-se cada custo pelo número de ocorrências, por exemplo, 
por ano, temos uma estimativa de perdas. Nesse caso, podemos ter resultados 
bastante precisos sobre as perdas. 
PROCESSO DE TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E210
RISCOS BASEADOS NAS CARACTERÍSTICAS DA QUALIDADE 
Bastos et al. (2007) afirma que devemos tomar cuidado especial quando se clas-
sificam os riscos do projeto de testes e os riscos da ocorrência de defeitos. Para 
os autores, um projeto de testes, como todo projeto, está envolto em uma lista de 
possibilidade de riscos, que podem, por sua vez, fazer com que o software seja 
mal testado e com isso, pode ocasionar a ocorrência de defeitos. 
Como podemos minimizar a ocorrência de defeitos no software? Para mini-
mizar a ocorrência de defeitos nos softwares, é utilizado uma norma de qualidade, 
como a Norma ISO/IEC 9126-1. A Norma ISO/IEC 9126-1 estabelece caracte-
rísticas de qualidade que todo software deve ter. Na tabela 3 apresentamos uma 
lista de algumas características:
Tabela 3: Algumas características de qualidade dos softwares – ISO/IEC – 9126-1 
CARACTERÍSTICA DESCRIÇÃO
Funcionalidade
Capacidade do software de fornecer funcionalidades que 
atendam à necessidade definida quando usado sob determi-
nadas condições preestabelecidas.
Confiabilidade
Capacidade do software de manter um nível específico de 
desempenho quando usado sob determinadas condições 
preestabelecidas. 
Usabilidade
Capacidade do software de ser entendido, aprendido, usado 
e atrativo quando empregado sob determinadas condições 
específicas.
Eficiência
Capacidade do software de manter o desempenho, em rela-
ção aos recursos disponíveis, quando usado sob determina-
das condições específicas.
Manutenibilidade Capacidade do software de ser mantido.
Portabilidade Capacidade do software de ser transferido de um ambiente para outro.
Fonte: Bastos et al. (2007).
Gerência de Risco em Teste de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
211
Para garantir que o software não perca nenhuma das características de quali-
dade estabelecidas pela norma, Bastos et al. (2007) sugere que seja necessário 
fazer uma associação entre os tipos de teste e as características de qualidade que 
se quer alcançar ou cumprir. Lembra dos tipos de testes que vimos na unidade 
IV? Vamos recordar, associando-os com as características de qualidade que pos-
sam ser atendidas.
Tabela 4: Características de qualidade com os tipos de teste 
CARACTERÍSTICA EXEMPLOS DE TESTES
Funcionalidade Teste de funcionalidade
Confiabilidade Teste de estresse
Usabilidade Teste de usabilidade
Eficiência Teste de desempenho
Manutenibilidade Teste Caixa-branca (entre outros)
Portabilidade Teste de produção (entre outros)
Fonte: Bastos et al. (2007).
Uma lembrança importante que o testador deve sempre manter em mente ao 
fazer a sua análise de riscos é que os riscos mudam com o tempo. Caso o sistema 
precise alguns anos depois voltar a ser testado, em decorrência de uma manuten-
ção grande, pode ser que os riscos também tenham que sofrer uma manutenção. 
Neste caso, uma nova estratégia de testes deverá ser traçada. Para Bastos et al. 
(2007) “uma das maneiras de reduzirmos os riscos do software é testarmos o 
software adequadamente”. 
Chegamos ao final de mais uma unidade. E agora? Finalizamos os testes? 
Você(s) deve(m) estar se perguntando, depois de tudo que aprendemos sobre os 
testes: “quando os testes de software param?”.
PROCESSO DE TESTE DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E212
A resposta para esta pergunta vai depender de cada projeto. Mas podem ter 
diversos motivos para definir em um projeto, quando os testes devem parar, por 
exemplo: prazo, orçamento e riscos. Conforme Pressman (2011) os testes trazem 
informações suficientes para a tomada de decisão pelos engenheiros do projeto 
e com isso o grau de maturidade e qualidade do software que está sendo desen-
volvido. Mas o bom é saber que sempre temos uma versão beta. 
Está comprovado que quanto mais cedo for detectado e corrigido um defei-
to, menor será o impacto e a propagação nas demais fases do ciclo de vida. 
Desta forma, devemos procurar identificar os defeitos o mais breve dentro 
do processo de desenvolvimento, ou seja, já a partir da identificação dos re-
quisitos do sistema. O pior resultado obtido por um sistema de informação é 
quando seus requisitosnão correspondem àqueles esperados por seus usu-
ários. Se a análise de requisitos for “pobre”, todo o restante do processo esta-
rá comprometido e o risco de insucesso do projeto será bastante alto. Para 
auxiliar na identificação de defeitos durante a etapa de análise de requisitos 
podemos recorrer às inspeções. Inspeções são uma das poucas técnicas de 
revisão disponíveis para aplicação em artefatos de software que não o códi-
go-fonte, podendo ser aplicadas a qualquer tipo de documento escrito, se-
jam eles especificações de requisitos, documentos ou modelos de projeto. 
Fonte: Costa Júnior e Melo (2003). 
Considerações Finais
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
213
CONSIDERAÇÕES FINAIS
Nesta unidade, aprendemos a importância dos documentos de testes de software 
dentro do projeto de testes. Vimos quais os documentos mínimos necessários 
para que um processo de testes funcione convenientemente, ou seja, bem suce-
dido. Aprendemos sobre o Plano de Testes, que é um escopo de referência durante 
a execução do teste e também serve como documento de comunicação junto ao 
cliente que contratou o serviço de teste.
Vimos sobre os Casos de Teste, que estabelecem o que será testado e quais as 
informações que serão empregadas durante os testes dos cenários e quais serão 
os resultados esperados. Aprendemos sobre os Relatórios de Testes do Software 
que são usados para registrar os dados relativos à execução de um dos tipos de 
teste. Cada novo relatório deve ser adicionado sequencialmente aos Relatórios 
dos Testes do Software.
Ao longo desta unidade, aprendemos também sobre verificação e validação, 
e suas diferenças. Vimos que a verificação refere-se ao conjunto de tarefas que 
garantem que o software implemente corretamente uma função específica e a 
validação, que refere-se a um conjunto de tarefas que asseguram que o software 
foi criado e pode ser rastreado segundo os requisitos do cliente
Outro tópico importante que aprendemos, foram sobre as ferramentas de 
teste, que são o apoio dos profissionais da área de teste, pois cobrem grande 
parte das atividades de teste e são aplicáveis em todas as fases do ciclo de vida 
do desenvolvimento do software. 
Além disso, aprendemos sobre as métricas e medições. A métrica propor-
ciona uma base por meio da qual a análise, projeto, codificação e teste podem 
ser conduzidos mais objetivamente e avaliados de maneira mais quantitativa.
E chegando ao final da unidade, aprendemos sobre a gerência de riscos, em 
que vimos como a análise de riscos em projetos de teste de software, embora 
tenha suas características próprias, deve seguir as mesmas regras e metodolo-
gias aplicadas aos projetos de software.
214 
1. Conforme vimos, os documentos que são definidos pela norma cobrem tarefas 
de planejamento, especificação ou elaboração e análise dos resultados. A norma 
ou padrão IEEE 829 (Institute of Electrical Engineers) especifica que devem ser 
usados quais documentos? 
2. O Plano de teste possui várias funções, dependendo de sua situação. Quais são 
as principais funções de um Plano de Teste:
I. Suportar o desenvolvimento da qualidade dos produtos, de forma sábia, sin-
cronizada com as decisões e não ter as informações históricas do projeto, de 
forma a suportar auditoria e melhorias para futuros projetos.
II. Descrever e justificar a estratégia de testes para com os requisitos do produto 
a ser testado.
III. Suportar o início e a organização do projeto de teste, incluindo aí preparações, 
pessoal, delegação de responsabilidades, planejamento das tarefas etc.
IV. Suportar o gerenciamento diário e a revolução do projeto de implementação 
e da estratégia.
V. Suportar a efetiva coordenação, colaboração e outros relacionamentos entre 
os membros da equipe e o resto do projeto. Identificar e gerenciais quaisquer 
riscos ou questões que possam impactar no projeto.
Assinale a opção com a sequência CORRETA.
a. Somente a questão II, III e V está correta.
b. Somente as questões I e II estão corretas.
c. Somente a questão II está correta. 
d. Todas estão corretas. 
215 
3. Podemos considerar como objetivo da Verificação e Validação: 
a. A capacidade do produto de software de evitar falhas decorrentes de defeitos 
no software.
b. Determinar a completeza da documentação do software.
c. Garantir que tanto o modo pelo qual o software está sendo construído quanto 
o produto em si esteja em conformidade com o especificado.
d. Testar o software até que ele não apresente defeitos. 
4. Para se modelar a confiabilidade de software é necessário considerar, exceto:
a. A remoção de defeitos
b. A prevenção de defeitos
c. A introdução de defeitos
d. O ambiente no qual o software é executado
5. Qual a importância da Gerência de Risco em projetos de Teste de Software? 
216 
GERENCIANDO RISCOS NOS PROJETOS DE SOFTWARE
por Mauricio Aguiar
Consta que o risco é uma ciência nascida no século dezesseis, durante a Renascença. A 
palavra risco tem origem na antiga palavra italiana “risicare”, que significa ousar. Naquela 
época, os jogos de azar levaram à descoberta da teoria das probabilidades, indispensá-
vel à determinação do risco. Hoje em dia, mais e mais organizações envolvidas com a 
produção de software voltam-se para o Gerenciamento de Riscos, como forma de ante-
cipar e minimizar o efeito de eventos que possam impactar negativamente os objetivos 
dos projetos de software. Neste artigo introduziremos alguns conceitos básicos para o 
Gerenciamento de Riscos em projetos de software.
Riscos em Projetos de Software
O risco em um projeto de software é uma medida da probabilidade e da perda relacio-
nadas à ocorrência de um evento negativo que afete o próprio projeto, seu processo ou 
o seu produto. Em outras palavras, qualquer coisa que possa acontecer e ameaçar o bom 
andamento do projeto é um risco. 
O risco do projeto relaciona-se com aspectos operacionais, organizacionais e contratu-
ais. Este tipo de risco é uma responsabilidade do Gerente do Projeto, nele estando in-
cluídos limitações de recursos, interfaces externas, relacionamentos com fornecedores 
e restrições contratuais. Exemplos comuns são fornecedores incapazes de responder à 
altura e falta de apoio da organização para o projeto. 
A falta de controle sobre as dependências externas do projeto torna extremamente di-
fícil o gerenciamento dos riscos. Normalmente, o maior risco dos projetos de software é 
financeiro – tem a ver com a obtenção dos recursos orçamentários. O risco do processo 
inclui tanto procedimentos técnicos quanto gerenciais. Nos procedimentos gerenciais, 
esse tipo de risco será encontrado no planejamento, na obtenção de recursos humanos, 
no acompanhamento e controle do projeto, na garantia da qualidade e na gerência de 
configuração. Nos procedimentos técnicos, o risco será encontrado em atividades tais 
como a análise de requisitos, o design, a codificação e o teste. 
O risco do produto está associado as suas características. Esse tipo de risco é uma res-
ponsabilidade técnica (não gerencial). Será encontrado na estabilidade dos requisitos, 
na performance do design, na complexidade do código e nas especificações de teste. O 
maior risco relativo ao produto nos projetos de software refere-se aos requisitos.
Gerenciamento de Riscos em Projetos de Software
O Gerenciamento de Riscos de Software consiste em avaliar e controlar os riscos que 
afetam o projeto, processo ou produto de software. A melhor maneira de descobrir os 
riscos é definir, inicialmente, os objetivos e metas do projeto. Os riscos são gerenciados 
tendo em vista objetivos específicos, podendo afetar apenas o trabalho que falta para 
alcançá-los. 
217 
As perguntas importantes são: qual o risco contido no plano? Qual o risco contido no 
trabalho ainda restante? A incerteza é inerente a todas as suposições do projeto. [...] 
A probabilidade de ocorrência do risco é um dos fatorespara a determinação de sua 
prioridade. Um dos conceitos fundamentais do Gerenciamento de Riscos é a perda. É 
preciso que haja um potencial de perda para que haja risco.
Um Processo para Gerenciamento de Riscos
O risco nos projetos de software pode ser gerenciado através das seguintes atividades: 
identificação dos riscos, análise dos riscos, planejamento dos riscos, acompanhamento 
dos riscos e resolução dos riscos. O processo começa com a identificação dos riscos. Tudo 
o que se referir a incerteza, experiências anteriores, preocupações e questões a resolver 
pode ser útil na identificação dos riscos. Várias fontes podem ser utilizadas nesta fase: pes-
soas incluem clientes, integrantes da equipe, organizações envolvidas, disponibilidade, 
capacidade, experiência etc.; produto e processo abrangem requisitos, prazos, estimati-
vas, receitas, despesas, orçamento, restrições de natureza legal, estilo de gerenciamento, 
tamanho e escopo do projeto etc.; tecnologia inclui mudanças, inovação, adoção e uso, 
integração e interfaces, experiência específica, segurança, arquitetura, escalabilidade etc. 
[...] Em seguida, deve-se calcular a exposição referente a cada risco, definida como o 
produto da probabilidade de ocorrência do risco pelo respectivo impacto. A exposição 
é utilizada na priorização dos riscos. O planejamento dos riscos inclui a definição de ce-
nários para os riscos mais importantes, a definição de alternativas de solução para esses 
cenários, a escolha das alternativas mais adequadas, o desenvolvimento de um Plano 
de Ação de Riscos, assim como o estabelecimento de limiares ou disparadores para a 
ação. O acompanhamento dos riscos envolve a monitoração dos cenários de riscos, a 
verificação de que os limiares foram ou não atingidos, bem como a análise das medidas 
e indicadores referentes aos riscos [...]
Gerenciamento de Riscos e o PMBOK
O Project Management Institute (PMI) define um processo genérico para o Gerenciamen-
to de Riscos, ligeiramente diferente do exposto acima. Segundo o Project Management 
Body of Knowledge – PMBOK, o Gerenciamento de Riscos é o processo sistemático de 
identificação, análise e resposta aos riscos dos projetos. Inclui maximizar a probabilida-
de e as consequências dos eventos positivos, bem como minimizar a probabilidade e 
consequência dos eventos negativos, em relação aos objetivos do projeto. 
Ferramenta para Gerenciamento de Riscos
Um ferramenta gratuita para o Gerenciamento de Riscos em geral (não apenas de sof-
tware) é o software TRIMS, desenvolvido pelo BMP Center of Excellence, uma organização 
patrocinada pela Marinha e pelo Departamento do Comércio Norte-Americanos, bem 
como pela Universidade de Maryland. O software contém o questionário para avaliação 
de riscos do Software Engineering Institute, para utilização em projetos de software.
Fonte: Aguiar (online, 2016). 
MATERIAL COMPLEMENTAR
Planeje seus Testes de Software e não morra na praia.
Imagem Art Studio 
Editora: Imagem Art Studio
Sinopse: Um gerente ou um líder de projeto, normalmente não tem 
tempo para fi car pesquisando em livros as informações que precisa. Por 
outro lado, a informação, quando encontrada, é apresentada de uma 
forma complexa e muitas vezes inacessível para um acesso rápido. Um 
livro leve, de fácil leitura, não signifi ca que é um documento superfi cial. 
Nós nos preocupamos em passar por todos os tópicos importantes 
que envolvem o planejamento nos projetos de teste de software. 
Desta forma, tomamos como objetivo o Plano de Teste, instrumento 
básico de planejamento desses projetos, e abordamos numa linguagem 
acessível tópicos como: Processo; Planejamento; Equipe; Documentação; 
Ambiente e Estimativas. Além disso, o livro tem um anexo sobre a história 
do teste de software no Brasil e no mundo e uma visão rápida sobre teste 
ágil. Achamos melhor esta abordagem do que incluir um capítulo sobre 
metodologia de teste.
Garantia da Qualidade de Software
Alexandre Bartié 
Editora: Elsevier
Sinopse: Totalmente alinhado com as mais modernas metodologias 
existentes no mercado, este livro coloca você diante dos conceitos mais 
avançados sobre como aplicar um “Processo de Garantia da Qualidade 
de Software” na sua empresa. Usando uma abordagem simplifi cada e 
de fácil de entendimento, possibilita aos leitores assimilar gradualmente 
os aspectos mais relevantes envolvidos na implantação de um 
“Processo de Garantia da Qualidade de Software”. Estabelece uma visão 
corporativa de qualidade de software e prepara a organização ao desafi o 
de incorporar estes conceitos no seu dia a dia. Combinando visão 
acadêmica com realidade empresarial, o livro apresenta um modelo 
metodológico viável tanto para as organizações que nunca iniciaram um 
SPI (Software Process Improvement) quanto às organizações que buscam 
atingir os níveis CMM 2 e 3.
A busca pela viabilidade na aplicação das melhores práticas voltadas à 
garantia da qualidade de software torna este livro uma peça-chave para fazer uma verdadeira 
revolução na sua organização.
Material Complementar
MATERIAL COMPLEMENTAR
Apresentação: Padrão para Documentação de Teste de Software. Veja neste artigo uma 
apresentação do Padrão para Documentação de Teste de Software (IEE 829 - Standard 
for Software Test Documentation). O padrão apresentado nesse artigo é o IEEE 829, 
está relacionado com o processo de testes, etapa do processo de desenvolvimento de 
software de suma importância para garantia e controle da qualidade. Sua abrangência 
vai desde testes unitários até testes de aceitação e tem por objetivo definir 
documentos consistentes e adequados capazes de definir, registrar e prover condições 
de análise dos resultados obtidos ao longo do processo.
Para consultá-lo, acesse o link <http://www.devmedia.com.br/padrao-para-
documentacao-de-teste-de->software/26534>.
Apresentação: Ferramentas de suporte ao Teste de Software. Artigo que apresentada 
algumas ferramentas de diferentes características e classificações voltadas para 
fornecer um amplo suporte ao teste de software. Maior agilidade nas atividades 
do Processo de Teste, como a utilização de ferramentas de suporte ao teste pode 
contribuir para consideráveis ganhos de tempo, produtividade, confiabilidade e 
principalmente com a qualidade em cada uma das etapas do ciclo de vida do teste. Ao 
longo do artigo serão apresentadas algumas ferramentas de diferentes características 
e classificações voltadas para fornecer um amplo suporte ao teste de software. Muito 
interessante o artigo. 
Para consultá-lo, acesse o link: <http://www.devmedia.com.br/ferramentas-de-
suporte-ao-teste-de-software/28642#ixzz417IrA2S2>.
MATERIAL COMPLEMENTAR
Apresentação: Como trabalhar com testes de software? Nesse vídeo serão 
apresentadas dicas do porque escolher a área de Teste de Software e como essa pode 
ser uma oportunidade para você aluno(a) entrar no mercado de trabalho em uma das 
áreas de TI que mais cresce.
Para consultá-lo, acesse o link: <https://www.youtube.com/watch?v=rL48FS-99ac>.
Apresentação: Métricas e Estimativas de Software - O início de um rally de 
regularidade. Este artigo descreve as métricas e estimativas de software de uma 
forma legal, fazendo você imaginar que faz parte de uma equipe de rally, e que você 
e sua equipe tenham que atravessar um deserto enorme e cheio de obstáculos e que 
vocês precisem calcular o tempo e distância, por meio do uso de estimativas. Depois 
é mostrado ao longo do artigo, conceitos sobre as métricas e estimativas de software. 
Aproveitem. Boa leitura!
Para consultá-lo, acesse o link: <http://www.linhadecodigo.com.br/artigo/102/
metricas-e-estimativas-de-software-o-inicio-de-um-rally-de-regularidade.
aspx#ixzz40u61nr9f>
CONCLUSÃO
221
Chegamos ao final do nosso estudo sobre Projetos, Implementação e Teste de Sof-
tware. Espero que você tenha conseguido entender os conceitos relacionados que 
fazem parte do processo de software e como ele é composto de atividades que são 
necessárias para o desenvolvimento deum sistema. 
Estudamos os aspectos relativos ao projeto, mostrando a sua importância e como 
essa fase é fundamental para o desenvolvimento de um software. Um dos principais 
objetivos da fase de projeto é que ela define como vai ser a arquitetura do software, 
tendo como base o que foi levantado na análise de requisitos. 
Depois de aprendermos sobre a fase de projeto, passamos a analisar a importância 
da fase de implementação dentro do processo de desenvolvimento de software. 
Após a implementação do software, passamos a fase de testes, em que é hora de va-
lidar e verificar se ele realmente está funcionando. Aprendemos conceitos e vimos 
que as razões de realizar testes não consistem simplesmente na geração e execução 
de casos de teste, mas em uma atividade que envolve também questões de plane-
jamento, gerenciamento e análise de resultados. 
Vimos como compreender os processos de teste de software, mapear e implantar 
técnicas de teste, melhorar os testes de software, planejar as estratégias, inspecio-
nar a qualidade do produto, do processo e do projeto com base em métricas e indi-
cadores, utilização de ferramentas para auxílio à gestão de teste e gestão de defei-
tos, avaliar a qualidade de uso do software por meio de avaliações de usabilidade, 
automatização de testes unitários, funcionais e não funcionais.
Esperamos ter alcançado o objetivo inicial, que era mostrar a importância das ativi-
dades que fazem parte do processo de desenvolvimento do software que são as fa-
ses: projeto, a implementação e o teste de software. Desejamos que a utilização do 
que foi apresentado aqui possa ser adotado ou te ajudar na empresa em que você 
trabalha (ou que irá trabalhar) e que te garanta sucesso e realização profissional. 
Muito obrigada pela atenção em todas as unidades e até uma próxima!
Prof.ª Janaína.
REFERÊNCIAS
AGUIAR, M. Gerenciando Riscos nos Projetos de Software. Developers’ Magazine. 
(Online). Disponível em: <http://www.bfpug.com.br/islig-rio/Downloads/Geren-
cia_de_Riscos.pdf>. Acesso em: 16 mar. 2016. 
BASTOS A.; RIOS E.; CRISTALLI R.; MOREIRA T. Base de Conhecimento em Teste de 
Software. 2 ed. São Paulo: Editora Martins, 2007. 
BLANCO M. Z. Documentação de teste baseado na Norma IEEE 829 – estudo de caso: 
Sistema de apoio a tomada de decisão. T.I.S. v. 1, n. 1, São Carlos; 2012, p. 91-97.
COSTA JÚNIOR P. J. da.; MELO W. L. Um processo de inspeção utilizando leitura 
baseada em perspectiva aplicado à análise de requisitos do unified process. 
UCB - Universidade Católica de Brasília, 2003. 
FANTINATO M.; CUNHA A. C. R. da; DIAS S. V.; MIZUNO S. A.; CUNHA C. A. Q. AutoTest 
– Um Framework Reutilizável para a Automação de Teste Funcional de Software. 
Hífen (PUCRS. Impresso). v. 26. Porto Alegre: 2002, p. 77-83.
GOMES A.; OLIVEIRA K.; ROCHA A. R. Avaliação de Processos de Software baseada 
em Medições. In: XV Simpósio Brasileiro de Engenharia de Software, Rio de Ja-
neiro: 2001, p. 84-99.
IEEE, The Institute of Electrical and Electronics Engineers. IEEE Std 829: Standard 
for Software Test Documentation. New York: IEEE Computer Society, September, 
1998.
PRESSMAN, R. Engenharia de Software. 7. ed. Porto Alegre: AMGH, 2011.
RIOS, E. Caratê Aplicado ao Teste de Software. 1 ed. Niterói: Imagem Art Studio, 
2008. 
RIOS, E. ; MOREIRA, T. Teste de Software. 3 ed. Rio de Janeiro: Alta Books, 2013.
SOMMERVILLE, I. Engenharia de Software. São Paulo: Pearson Prentice Hall, 2011.
TRODO, L. D. Uso de Métricas nos Testes de Software. Trabalho de Conclusão de 
Curso Ciência da Computação da Universidade Federal do Rio Grande do Sul. 128 f. 
Porto Alegre, 2009 .
GABARITO
223
1. Os documentos são:
• Plano de Teste.
• Especificação de Projeto de Teste.
• Projeto de teste.
• Casos de teste.
• Procedimentos de teste.
• Relatórios de Teste.
• Relatório de Passagem de Itens de Teste.
• Relatório de Log de Teste.
• Relatório de Incidentes de Teste.
• Relatório de Sumário de Teste.
2. A - Somente as questões II, III e V estão corretas.
3. C - Garantir que tanto o modo pelo qual o software está sendo construído quan-
to o produto em si esteja em conformidade com o especificado.
4. B - A prevenção de defeitos.
5. A Gerência de riscos é muito importante em projetos de testes, pois a equipe 
de teste sempre estará focada em atacar os riscos maiores, ou seja, defeitos gra-
ves, que podem gerar uma maior implicação no processo, pois sabemos que os 
prazos são apertados e não existe um tempo para gastar na atividade de teste. 
Assim, no Plano de Teste esses riscos serão os de maior prioridade.