Proj Impre e Teste de Software PDF

PROJETO,
IMPLEMENTAÇÃO
E TESTE DE
SOFTWARE
Professora Esp. Janaína Aparecida de Freitas
GRADUAÇÃO
Unicesumar
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
C397 CENTRO UNIVERSITÁRIO DE MARINGÁ. Núcleo de Educação a
Ana Salvadego
Distância; FREITAS, Janaína Aparecida de.
Iconografia
Projeto, Implementação e Teste de Software. Janaína Amanda Peçanha dos Santos, Ana Carolina
Aparecida de Freitas. Martins Prado
Reimpressão - 2018.
Maringá-Pr.: UniCesumar, 2016. Projeto Gráfico
223 p. Jaime de Marchi Junior, José Jhonny Coelho
“Graduação - EaD”.
Arte Capa
1. Projeto. 2. Implementação . 3. Software 4. EaD. I. Título. Arthur Cantareli Silva
Editoração
ISBN 978-85-459-0318-5 Matheus Felipe Davi
CDD - 22 ed. 005.1
CIP - NBR 12899 - AACR/2 Qualidade Textual
Hellyery Agda G. Silva
Naiara Valenciano
Ficha catalográfica elaborada pelo bibliotecário Pedro Barth
João Vivaldo de Souza - CRB-8 - 6828
Ilustração
Impresso por:
Marta Sayuri Kakitani
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.
AUTORA

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
APRESENTAÇÃO
PROJETO, IMPLEMENTAÇÃO
E TESTE DE SOFTWARE
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á-lo e, 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!
09
SUMÁRIO
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

10
SUMÁRIO
77 Projeto de Dados
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
123 Referências
124 Gabarito
11
SUMÁRIO
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
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

12
SUMÁRIO
194 Métricas e Medição
204 Gerência de Risco em Teste de Software
221 Referências
222 Gabarito
223 Conclusão
I
INTRODUÇÃO AO PROJETO,
UNIDADE
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
15
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.
Reprodução proibida. Art. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
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
16 UNIDADE I
©shutterstock
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.

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ção do 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 Teste de Software

18 UNIDADE I
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.

19
Figura 1- Modelo Cascata
Definição de
requisitos
Projeto de
sistema e software
Implementação e
teste de unidade
Integração e
teste de sistema
Operação e
manutenção
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 Teste de Software

20 UNIDADE I
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).
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.

21
©shutterstock
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.
Projeto de Software
22 UNIDADE I
O projeto de software é um processo que possui as 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
Elementos baseados Diagramas de fluxo
componentes
em cenários de dados
Casos de uso - texto Diagramas de fluxo de dados
Diagramas de casos de uso Diagramas de fluxo de controle Projeto de
Diagramas de atividades Narrativas de processamento interface
Diagramas de Raias Modelos de
análise
Projeto arquitetural
Elementos baseados Elementos
em classes comportamentais
Diagrama de classes Diagramas de estados Projeto de dados/classes
Pacotes de análise Diagramas de sequência
Modelos CRC
Diagramas de colaboração Modelos de projeto
Fonte: Pressman, (2011).

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
Análise e
Domínio do Especificação
Mundo Real
problema de Requisitos
(o quê)
Projeto
(como)
Domínio da
solução Mundo Implementação
Computacional
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).
Projeto de Software
24 UNIDADE I
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.

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).
Projeto de Software
26 UNIDADE I
©shutterstock
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.

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ém podem 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).
Implementação de Software
28 UNIDADE I
“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
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: apre-
senta uma elevada probabilidade de
revelar um defeito/erro ainda não
descoberto.
©shutterstock

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:
Teste de Software
30 UNIDADE I
■■ 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.

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 saber exatamente 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).
Teste de Software
32 UNIDADE I
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. Segundo Buschmann, 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 final, 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 infinito 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 polimorfismo,
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 final 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.
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
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.
Material Complementar
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.
41
GABARITO
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 conduzida nas 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.
II
UNIDADE
PROJETO DE SOFTWARE
■■ 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 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
45
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
46 UNIDADE II
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-
©shutterstock
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.
PROJETO DE SOFTWARE
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.
A Fase de Projeto de Software

48 UNIDADE II
Figura 1 - Modelo Geral do Projeto de Software.
Especificação
de requisitos
Atividades de projeto
Projeto de
Projeto de Especificação Projeto de Projeto de Projeto de
estrutura de
arquitetura abstrata interface componente algoritmo
dados
Especificação
Arquitetura Especificação Especificação Especificação Especificação
de estrutura
de sistema de software de interface de componente de algoritmo
de dados
Produtos de projeto
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.
PROJETO DE SOFTWARE
49
O projeto de software sempre deve começar levando em consideração os

dados — a base para todos os demais elementos do projeto.
(Pressman).
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 ©shutterstock
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.
Conceitos Básicos de Projeto de Software

50 UNIDADE II
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.
PROJETO DE SOFTWARE
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”.
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).
Conceitos Básicos de Projeto de Software

52 UNIDADE II
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 ©shutterstock
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), a preocupaçã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
PROJETO DE SOFTWARE
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).
Qualidade do Projeto
54 UNIDADE II
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).
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: ©shutterstock
PROJETO DE SOFTWARE
55
Figura 2- Dimensões do Modelo de Projeto
Alto
Modelo de análise
Diagramas de classes Casos de uso - texto Diagramas de classes Requisitos:

Pacotes de análise Diagramas de casos de uso Pacotes de análise Restrições
Modelos CRC Diagramas de atividade Modelos CRC Interoperabilidade
Diagramas de colaboração Diagramas de raias Diagramas de colaboração Metas e configurações
Diagramas de fluxo de dados Diagramas de colaboração Diagramas de fluxo de dados
Diagramas de fluxo de controle Diagramas de estados Diagramas de fluxo de controle
Narrativas de processamento Diagramas de sequência Narrativas de processamento
Diagramas de estados
Diagramas de sequência
Realização das classes de
projeto
Subsistemas Projeto técnico da interface
Diagramas de componentes Realizações das classes de
Diagrama de colaboração Projeto de navegação
Classes de projeto projeto
Projeto da interface gráfica do
Diagramas de atividade
Subsistemas
Modelo de projeto usuário
Diagramas de sequência Diagramas de colaboração
Refinamentos para: Diagramas de componentes
Realizações das classes de Refinamentos para: Classes de projeto
projetos Diagramas de componentes Diagramas de atividade
Classes de projetos Diagramas de sequência
Subsistemas
Baixo Diagramas de atividades
Diagramas de colaboração
Diagramas de sequência Diagramas de implantação
Elementros da Elementros da Elementros de Elementros de
arquitetura interface componentes implantação
Dimensão de Processo
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 da Arquitetura do Software

56 UNIDADE II
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 entre as 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 DE SOFTWARE
57
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.
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:

58 UNIDADE II
■■ 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).
PROJETO DE SOFTWARE
59
“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).
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
©shutterstock
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.

60 UNIDADE II
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 a um 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 DE SOFTWARE
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

62 UNIDADE II
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!
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.
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!
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).
PROJETO DE SOFTWARE
63
©shutterstock
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 Componentes
64 UNIDADE II
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 SOFTWARE
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 Componentes
66 UNIDADE II
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 SOFTWARE
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.
Projeto de Interface do Usuário

68 UNIDADE II
©shutterstock
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 pelo sistema? 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 SOFTWARE
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 Interface do Usuário

70 UNIDADE II
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).
PROJETO DE SOFTWARE
71
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).
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.
Modelos de Análise e Projeto de Interfaces

72 UNIDADE II
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 Análise e modelagem da

interface
Construção da interface Projeto da interface
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.
PROJETO DE SOFTWARE
73
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.
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.

74 UNIDADE II
■■ 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.
PROJETO DE SOFTWARE
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).

76 UNIDADE II
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.
PROJETO DE SOFTWARE
77
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.
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 ©shutterstock
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.
Projeto de Dados
78 UNIDADE II
O projeto dos dados é composto pela seleção das representações lógicas dos
objetos de dados identificados na etapa de levantamento dos requisitos. Alguns
princí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 SOFTWARE
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 Dados
80 UNIDADE II
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.
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.
PROJETO DE SOFTWARE
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!
Considerações Finais
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
( ) 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
( ) 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 de dados e
arquivos que serão necessários.
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

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.
b. Somente as questões I e IV 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).
Projeto de Software: Da programação à arquitetura: Uma

abordagem baseada em Java
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 filme ‘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 desafio 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>.
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.
WEBER, K. C., ROCHA, A. R. C.; MALDONADO, J. C. Qualidade de Software – Teoria e
Prática. São Paulo: Prentice Hall, 2001.
89
GABARITO
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.
IMPLEMENTAÇÃO DE
III
UNIDADE
SOFTWARE
■■ 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
■■ 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
93
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
94 UNIDADE III
©shutterstock
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.
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
96 UNIDADE III
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).
97
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.
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.
Atividades da Implementação de Software

98 UNIDADE III
Desenho
detalhado
Projeto de
arquitetura
Codificação
Inspeção de Testes de
implementação unidade
Defeitos encontrados
Unidades verificadas
Integração
Implementação incompleta
Implementação
completa
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.
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).
Atividades da Implementação de Software

100 UNIDADE III
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.
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. ©shutterstock
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):
Estilo de Programação e Codificação

102 UNIDADE III
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).
103
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).
COMENTÁRIOS
©shutterstock
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 podem ficar 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.
Comentários
104 UNIDADE III
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.
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).
Comentários
106 UNIDADE III
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-
©shutterstock 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.
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 sintaxe tendem 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.
Depuração
108 UNIDADE III
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.
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-
©shutterstock
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.
Asserções e Programação Defensiva

110 UNIDADE III
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
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-
©shutterstock
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.
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 alguns casos, 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.
Otimização de Desempenho
112 UNIDADE III
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 ©shutterstock
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.
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).
Refatoração
114 UNIDADE III
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.
c. Somente as questões I, II, III e IV 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.
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.
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).
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
offshore de desenvolvimento de software. Trata-se de uma obra de
referência para todos os que queiram entender melhor os aspectos
que 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 profissionais 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.
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. Confiram. Ó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/>.
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/>.
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>.
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/>.
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>.
123
REFERÊNCIAS
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.
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.
IV
UNIDADE
TESTE DE SOFTWARE
■■ 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
■■ 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
127
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
128 UNIDADE IV
©shutterstock
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.
TESTE DE SOFTWARE
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.
Introdução ao Teste de Software

130 UNIDADE IV
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”.
“Um testador bem treinado, com experiência prática e com o espírito aberto
para novos aprendizados dificilmente será derrotado.”
(Rios).
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.
TESTE DE SOFTWARE
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ários do 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).
Introdução ao Teste de Software

132 UNIDADE IV
©shutterstock
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).
TESTE DE SOFTWARE
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.
Conceitos Básicos de Teste de Software

134 UNIDADE IV
■■ 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).
TESTE DE SOFTWARE
135
É 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).
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.
©shutterstock
Ciclo de Vida do Teste de Software

136 UNIDADE IV
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
Teste Desenvolvimento
Validação Desenho Lógico
Especificação
e Físico
P P
l l
a Teste Unitário
a
n Execução (1) Construção n
e e
j j
a a
m Teste de Sistema e m
Teste de Integração
e Execução (2) Implantação e
n n
t t
o o
Teste de Aceitação
Entrega Entrega
Fonte: Rios e Moreira (2013).
TESTE DE SOFTWARE
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 Especificação Entrega Entrega

iniciais
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.
Ciclo de Vida do Teste de Software

138 UNIDADE IV
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).
TESTE DE SOFTWARE
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- ©shutterstock
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
?
Técnicas de Teste de Software

140 UNIDADE IV
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á
TESTE DE SOFTWARE
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 descobrir defeitos muito difí-
ceis de identificar.

142 UNIDADE IV
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.
TESTE DE SOFTWARE
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 em um nível de componente ou classe. É o teste cujo
Teste de Unidade
objetivo é um “pedaço do código”.
Garante que um ou mais componentes combinados (ou unida-
Teste de Integração des) funcionam. Podemos dizer que um teste de integração é
composto por diversos testes de unidade.
Garante que a aplicação vai funcionar no “caminho feliz” de sua
Teste Positivo-negativo
execução e vai funcionar no seu fluxo de exceção.
Testar todas as entradas e saídas desejadas. Não se está preo-
Teste de caixa-preta cupado com o código, cada saída indesejada é vista como um
erro.
O objetivo é testar o código. Às vezes, existem partes do código
Teste caixa-branca
que nunca foram testadas.
Verifica se a navegabilidade e os objetivos da tela funcionam
Teste de Interface
como especificados e se atendem da melhor forma ao usuário.
Testa se a solução será bem vista pelo usuário. Ex: caso exista
Teste de aceitação do um botão pequeno demais para executar uma função, isso
usuário deve ser criticado em fase de testes (aqui, cabem quesitos fora
da interface também).
Testar a quantidade de dados envolvidos (pode ser pouca, nor-
Teste de Volume
mal, grande ou além de grande).

144 UNIDADE IV
Testar se a aplicação funciona corretamente em diferentes am-

Testes de Configuração
bientes de hardware ou de software.
Testes de Instalação Testar se a instalação da aplicação foi OK.
Testar a execução do sistema como um todo para validar a
Teste de sistemas
exatidão e perfeição na execução de suas funções
Testar e simular as condições de utilização do software sobre a
perspectiva do usuário final. Esses testes focalizam a facilidade
Teste de Usabilidade 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.
Testa apenas as funcionalidades (ou requisitos não funcionais)
Testes de Progressão
especificados para a versão.
Teste que consiste em um teste rápido, executando as prin-
Teste de Fumaça 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.).
TESTE DE SOFTWARE
145
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).
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
©shutterstock
algumas variações.
Papéis e Cargos de Teste de Software

146 UNIDADE IV
Na Tabela 2, é mostrada a Matriz de Responsabilidade com as funções que

cada um deve desenvolver na fase de testes:
Tabela 2 – Matriz de responsabilidades
É o técnico responsável pela liderança de um projeto de

Líder do Projeto de Testes testes especifico, normalmente, seja um projeto novo ou
um de manutenção.
É o técnico responsável pela montagem da infraestrutura
de teste, montando o ambiente de teste, escolhendo as
Arquiteto de Teste
ferramentas de teste e capacitando a equipe para executar
o seu trabalho nesse ambiente de teste.
É o técnico responsável pela modelagem e elaboração dos
Analista de Teste casos de Teste e pelos scripts de teste. Pode ser que em
alguns casos os scripts sejam elaborados pelos testadores.
Técnico responsável pela execução dos casos de teste e
Testador
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”.
TESTE DE SOFTWARE
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.
Papéis e Cargos de Teste de Software

148 UNIDADE IV
©shutterstock
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.
TESTE DE SOFTWARE
149
Figura 5: Ambiente de Teste de Unidade
Interface
Pseudocontrolador Estruturas de dados locais
Condições de fronteira
Caminhos independentes
Módulo a Caminhos de manipulação de erro
ser
testado
Pseudocontrolados Pseudocontrolados
Casos
de teste
RESULTADOS
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
Definição da
estratégia de
testes Gerenciamento do
Criação do
processo de testes
ambiente de
(indicadores de
testes
desempenho)
Planejamento Execução dos

dos testes testes
dinâmicos dinâmicos
Fonte Bastos et al. (2007).
Ambiente de Teste
150 UNIDADE IV
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.
TESTE DE SOFTWARE
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.
Ambiente de Teste
152 UNIDADE IV
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).
TESTE DE SOFTWARE
153
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.
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

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)
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
qualificados, 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 fixação. A
qualidade de software, ao longo do tempo, tem se modificado 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 fim 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
fixação ao final dos capítulos.
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 profissionais da área,
indicada para o leitor que começa a se preparar para os exames
de certificação. A fim 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 de software?

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 profissional.
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>.
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
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.
TSUI, F.; KARAM, O. Fundamentos de engenharia de software. 2 ed. Rio de Janeiro:
LTC, 2013.
163
GABARITO
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.
PROCESSO DE TESTE DE
V
UNIDADE
SOFTWARE
■■ 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
■■ 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
167
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
168 UNIDADE V
©shutterstock
DOCUMENTAÇÃO DE 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.

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 Itens de Teste

Documentos
Artefatos usados Artefatos usados
projeto desenv
nos testes nos testes
Plano de Teste
Especificação de Especificação de Especificação de Relatórios de

Projeto de Teste Projeto de Teste Projeto de Teste Itens de teste
Especificação de
Caso de Teste
Especificação do
Procedimento de
Teste
Fonte: IEEE 829 (1998).
Documentação de Teste de Software

170 UNIDADE V
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.

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.

172 UNIDADE V
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.
Objetivos, histórico, escopo, referências
Introdução
a documentos.
Itens a testar Conjunto dos itens cobertos pelo plano.
Aspectos a testar Conteúdo dos testes que serão feitos.
Aspectos significativos que não serão
Aspectos que não serão testados
testados.
Opções metodológicas que são aplicá-
Abordagem
veis ao conjunto dos testes.
Condições que devem ser satisfeitas e
estado que deve ser atingido para que
Critérios de completeza e sucesso
o conjunto dos testes seja considerado
bem sucedido.
Problemas graves que podem provocar
Critérios de suspensão e retomada
a interrupção dos testes.
Artefatos que serão produzidos durante
Resultados do teste
a realização da bateria de testes.
Lista detalhada das tarefas que são
Tarefas de teste
cobertas por este plano.
Hardware e software das configurações
Ambiente
usadas para o conjunto dos testes.
Responsabilidades de cada um dos
Responsabilidades
participantes dos testes.
Data de inicio e de fim de cada tarefa do
Agenda
plano.
Ricos e contingências aplicáveis aos
Riscos e contingências
testes deste plano.
Nomes e assinaturas dos responsáveis
Aprovação
pela aprovação do plano.
Fonte: Norma IEEE Std. 829 (1998).

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 de teste 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.

174 UNIDADE V
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.

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.

176 UNIDADE V
■■ 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
O que motivou meu teste? Onde devo testar?
Requisitos Configurações
Caso de Teste
Iteração Implementação
Quando devo testar? Como devo testar?
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.

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).

178 UNIDADE V
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
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:
©shutterstock
■■ 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.

179
Figura 3: Resumo do Fluxo de geração de documentos
Plano de Teste
Especificação do Especificação do Especificação do

Projeto de Teste Projeto de Teste Projeto de Teste
Relatório
Casos de Procedimentos
encaminhamento
Teste de Teste
item de teste
Execução do Teste
Diário de Diário de
Teste Teste
Incidente Incidente
de Teste de Teste
Relatório
Resumo 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.
Relatórios de Teste de Software

180 UNIDADE V
■■ 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.

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.

182 UNIDADE V
- 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.

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.
“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).
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).

184 UNIDADE V
VALIDAÇÃO E VERIFICAÇÃO EM TESTES DE

SOFTWARE
©shutterstock
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 elemento de
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”.

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.
Validação e Verificação em Testes de Software

186 UNIDADE V
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.

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.
Validação e Verificação em Testes de Software

188 UNIDADE V
©shutterstock
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.

189
Sobre as ferramentas de teste, Bastos et al. (2007, p. 87) menciona que:

A seleção da ferramenta afeta a eficiê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.
Ferramentas de Teste de Software

190 UNIDADE V
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.

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.

192 UNIDADE V
■■ 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.

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 custo da 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).

194 UNIDADE V
©shutterstock
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.

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.
Métricas e Medição
196 UNIDADE V
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.

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.
198 UNIDADE V
■■ 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?

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.
Como muitos fatores afetam o trabalho de software, não use métricas para
comparar indivíduos ou equipes.
(Pressman).
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:
200 UNIDADE V
■■ 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.

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”.
202 UNIDADE V
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.

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 para melhorar a qualidade do produto e o desempenho do
processo.
Fonte: Gomes, Oliveira e Rocha (2001).
Gerência de Risco em Teste de Software

204 UNIDADE V
©shutterstock
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.

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.
“Medindo-se características da especificação, é possível obter informações

quantitativas sobre peculiaridade e totalidade.”
(Pressman).
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.

206 UNIDADE V
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.

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).

208 UNIDADE V
Tabela 2: Qualificação dos riscos - Probabilidade versus impacto
PROBABILIDADE DE OCORRÊNCIA DO RISCO

IMPACTO QUE O RISCO CAUSA AO NEGÓCIO
Alta Média Baixa
Alto AA AM AB
Médio MA MM MB
Baixo BA BM BB
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”.
“Quanto mais você sabe, melhor você estima. Portanto, atualize suas esti-
mativas à medida que o projeto avança.”
(Pressman).
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.

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.

210 UNIDADE V
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
Capacidade do software de fornecer funcionalidades que
Funcionalidade atendam à necessidade definida quando usado sob determi-
nadas condições preestabelecidas.
Capacidade do software de manter um nível específico de
Confiabilidade desempenho quando usado sob determinadas condições
preestabelecidas.
Capacidade do software de ser entendido, aprendido, usado
Usabilidade e atrativo quando empregado sob determinadas condições
específicas.
Capacidade do software de manter o desempenho, em rela-
Eficiência ção aos recursos disponíveis, quando usado sob determina-
das condições específicas.
Manutenibilidade Capacidade do software de ser mantido.
Capacidade do software de ser transferido de um ambiente
Portabilidade
para outro.

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)
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?”.

212 UNIDADE V
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 requisitos nã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).

213
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.
a. Somente a questão II, III e V está correta.
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 fatores para 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).
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 simplificada 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 desafio
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.
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 ficar 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 significa que é um documento superficial.
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.
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>.
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: 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>
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>.
221
CONCLUSÃO
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 de um 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.
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.
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 .
223
GABARITO
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.

Proj Impre e Teste de Software PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Proj Impre e Teste de Software PDF

Enviado por

Direitos autorais:

Formatos disponíveis

PROJETO,

Professora Esp. Janaína Aparecida de Freitas

NEAD - Núcleo de Educação a Distância

Professora Esp. Janaína Aparecida de Freitas

INTRODUÇÃO AO PROJETO, IMPLEMENTAÇÃO E TESTES DE SOFTWARE

16 Introdução ao Projeto, Implementação e Teste de Software

46 A Fase de Projeto de Software

49 Conceitos Básicos de Projeto de Software

55 Projeto da Arquitetura do Software

68 Projeto de Interface do Usuário

71 Modelos de Análise e Projeto de Interfaces

97 Atividades da Implementação de Software

100 Características da Implementação de Software

101 Estilo de Programação e Codificação

109 Asserções e Programação Defensiva

110 Otimização de Desempenho

114 Considerações Finais

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

PROCESSO DE TESTE DE SOFTWARE

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

194 Métricas e Medição

204 Gerência de Risco em Teste de Software

213 Considerações Finais

Olá, aluno(a)! Começamos nossos estudos apresentando alguns conceitos já

Nesta primeira unidade, serão apresentados os conceitos sobre as fases (ati-

INTRODUÇÃO AO PROJETO, IMPLEMENTAÇÃO E

Para compreendemos os conceitos de Projeto, Implementação e Teste de Software,

INTRODUÇÃO AO PROJETO, IMPLEMENTAÇÃO E TESTES DE SOFTWARE

outras características que podem ser determinantes para se gerar um software.

Introdução ao Projeto, Implementação e Teste de Software

Assim, ao final da etapa de Testes, todos os módulos do sistema são rela-

Para Sommerville (2011, p.124) “o Projeto e Implementação de software é um

INTRODUÇÃO AO PROJETO, IMPLEMENTAÇÃO E TESTES DE SOFTWARE

Figura 1- Modelo Cascata

Fonte: Sommerville, (2011).

Conforme Pressman (2011, p. 207), o Projeto de Software reside no núcleo téc-

Introdução ao Projeto, Implementação e Teste de Software

“Todo engenheiro de software deve reconhecer que modificações são natu-

INTRODUÇÃO AO PROJETO, IMPLEMENTAÇÃO E TESTES DE SOFTWARE

O conceito de Projeto de Software, conforme Pressman, é definido como:

Por sua vez, Sommerville define Projeto de Software como:

Podemos citar outros conceitos de Projeto. Conforme a ABNT (Norma técnica

O projeto de software é um processo que possui as seguintes atividades:

Figura 2 - Transformando o modelo de requisitos no modelo de projeto.

Fonte: Pressman, (2011).

INTRODUÇÃO AO PROJETO, IMPLEMENTAÇÃO E TESTES DE SOFTWARE

Segundo Pressman (2011, p. 178) o modelo de requisitos é usado para preen-

Figura 3 - A Fase do Projeto

Fonte: Falbo, (2012).

Seguindo a visão de Pressman sobre a fase de projeto, temos:

Conforme Falbo (2012), o objetivo da fase de projeto é definir e especificar uma

Também, segundo Falbo (2012, p. 10) em geral, um modelo de projeto deve:

INTRODUÇÃO AO PROJETO, IMPLEMENTAÇÃO E TESTES DE SOFTWARE

vida. Para os gerentes, perda de credibilidade e prejuízos. E para os clientes,

16 Introdução ao Projeto, Implementação e Teste de Software

46 A Fase de Projeto de Software

49 Conceitos Básicos de Projeto de Software

55 Projeto da Arquitetura do Software

68 Projeto de Interface do Usuário

71 Modelos de Análise e Projeto de Interfaces

97 Atividades da Implementação de Software

100 Características da Implementação de Software

101 Estilo de Programação e Codificação

109 Asserções e Programação Defensiva

110 Otimização de Desempenho

114 Considerações Finais

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

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

204 Gerência de Risco em Teste de Software

213 Considerações Finais