GERAL engenharia de software

Prévia do material em texto

Autor: Prof. André Luiz Dias Ribeiro
Colaboradores: Prof. Luciano Soares de Souza
 Profa. Adriane Paulieli Colossetti
 Profa. Jorge Rodolfo Beingolea Garay
Engenharia de Software II
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Professor conteudista: André Luiz Dias Ribeiro
Mestre em Engenharia Elétrica pela Escola Politécnica da USP em 2006, certificado em Project 
Management Professional (PMP), Personal Professional Coaching (PPC) e profissional da área 
de Tecnologia da Informação há 25 anos, exercendo diversos níveis profissionais da área, desde 
programador de computadores a diretor da área de informática.
Há dez anos atua como professor dos cursos de graduação em Sistemas de Informação, Ciência 
da Computação e Engenharia de Produção e em cursos de pós‑graduação em Gerenciamento de 
Projetos e Engenharia de Software. Responsável pela coordenação interdisciplinar de Engenharia 
de Software nos cursos de graduação e pela orientação de trabalhos de conclusão dos cursos de 
graduação e pós‑graduação.
 
© Todos os direitos reservados. Nenhuma parte desta obra pode ser reproduzida ou transmitida por qualquer forma e/ou 
quaisquer meios (eletrônico, incluindo fotocópia e gravação) ou arquivada em qualquer sistema ou banco de dados sem 
permissão escrita da Universidade Paulista.
Dados Internacionais de Catalogação na Publicação (CIP)
R484t Ribeiro, André Luiz.
Engenharia de Software II. / André Luiz Ribeiro. – São Paulo: 
Editora Sol, 2015.
188 p., il.
Nota: este volume está publicado nos Cadernos de Estudos e 
Pesquisas da UNIP, Série Didática, ano XVII, n. 2‑025/15, ISSN 1517‑9230.
1. Qualidade de software. 2. Processos de manutenção. 
3. Gestão da configuração. I. Título.
CDU 681.3.02
U500.53 – 19
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Prof. Dr. João Carlos Di Genio
Reitor
Prof. Fábio Romeu de Carvalho
Vice-Reitor de Planejamento, Administração e Finanças
Profa. Melânia Dalla Torre
Vice-Reitora de Unidades Universitárias
Prof. Dr. Yugo Okida
Vice-Reitor de Pós-Graduação e Pesquisa
Profa. Dra. Marília Ancona‑Lopez
Vice-Reitora de Graduação
Unip Interativa – EaD
Profa. Elisabete Brihy 
Prof. Marcelo Souza
Prof. Dr. Luiz Felipe Scabar
Prof. Ivan Daliberto Frugoli
 Material Didático – EaD
 Comissão editorial: 
 Dra. Angélica L. Carlini (UNIP)
 Dra. Divane Alves da Silva (UNIP)
 Dr. Ivan Dias da Motta (CESUMAR)
 Dra. Kátia Mosorov Alonso (UFMT)
 Dra. Valéria de Carvalho (UNIP)
 Apoio:
 Profa. Cláudia Regina Baptista – EaD
 Profa. Betisa Malaman – Comissão de Qualificação e Avaliação de Cursos
 Projeto gráfico:
 Prof. Alexandre Ponzetto
 Revisão:
 Juliana Mendes
 Virgínia Bilatto
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Sumário
Engenharia de Software II
APRESENTAÇÃO ......................................................................................................................................................9
INTRODUÇÃO ...........................................................................................................................................................9
Unidade I
1 CONCEITOS SOBRE QUALIDADE DE SOFTWARE .................................................................................. 11
1.1 Benefícios da qualidade ..................................................................................................................... 12
1.2 Obstáculos da qualidade ................................................................................................................... 13
1.3 Visões da qualidade ............................................................................................................................. 14
1.4 Importância da qualidade ................................................................................................................. 14
1.5 Garantia da qualidade ........................................................................................................................ 16
1.6 Controle da qualidade ........................................................................................................................ 16
1.7 Sistemas de Gestão da Qualidade (SGQ) .................................................................................... 17
1.7.1 Fatores para implantação de um SGQ............................................................................................ 18
1.7.2 A NBR ISO 9000 – norma‑padrão ................................................................................................... 19
1.7.3 NBR ISO 9000‑3 – Norma para empresas de desenvolvimento de software ................ 20
2 GESTÃO DA QUALIDADE DO PRODUTO DE SOFTWARE .................................................................... 23
2.1 Modelo de McCall ................................................................................................................................ 23
2.1.1 Visão de operação ................................................................................................................................... 24
2.1.2 Visão de revisão ....................................................................................................................................... 25
2.1.3 Visão de transição ................................................................................................................................... 25
2.2 ISO/IEC 9126 – Características de qualidade do produto de software........................... 29
2.2.1 Métricas de qualidade........................................................................................................................... 32
2.3 Norma ISO/IEC 12207 – Ciclo de vida do software ................................................................ 33
2.3.1 Processos fundamentais ...................................................................................................................... 34
2.3.2 Processos de apoio ................................................................................................................................. 35
2.3.3 Processos organizacionais ................................................................................................................... 35
2.3.4 Processos de adaptação ....................................................................................................................... 36
2.4 ISO/IEC 14598 – Avaliação de produto de software .............................................................. 37
2.4.1 Relação entre as séries das normas ISO/IEC 9126 e ISO/IEC 14598 ................................... 39
2.5 ISO/IEC 25000 – SQuaRE (Software Product Quality 
Requirements and Evaluation) ............................................................................................................... 41
Unidade II
3 FUNDAMENTOS DE QUALIDADE PARA PROCESSO DE SOFTWARE ............................................. 49
3.1 Norma ISO/IEC 15504 – Spice – Melhoria do Processo de Software.............................. 50
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
3.1.1 Níveis de maturidade ............................................................................................................................ 54
3.1.2 Pontuação dos atributos para determinação do nível de maturidade ............................. 57
4 MODELOS DE QUALIDADE PARA PROCESSO DE SOFTWARE ......................................................... 59
4.1 Capability Maturity Model Integration (CMMI) ....................................................................... 59
4.1.1 Estrutura do CMMI ................................................................................................................................. 60
4.1.2 Áreas de processo ................................................................................................................................... 61
4.1.3 Representaçãoa aplicação da norma na organização ou em projetos de software que possuem características 
específicas. Esses processos permitem que a norma seja adaptável a qualquer empresa de desenvolvimento.
Para exemplificar a abrangência de utilização da norma, a seguir são descritas as atividades envolvidas 
no processo fundamental de desenvolvimento da norma ISO/IEC 12207 (1995):
• análise dos requisitos do sistema;
• projeto da arquitetura do sistema;
• análise dos requisitos do software;
• projeto de arquitetura do software;
• projeto detalhado do software;
• codificação e testes do software;
• integração do software;
• testes de qualificação do software;
• integração do sistema;
• teste de qualificação do sistema;
• instalação do software;
• apoio à aceitação do software.
37
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
A norma ISO/IEC 12207 define os requisitos básicos, a partir desse conjunto, para que as 
organizações elaborem e definam a sua metodologia de desenvolvimento de software. Vale lembrar 
que metodologias são amplas e atendem a qualquer tipo de projeto, portanto deve haver, no 
início do projeto, um processo de customização da metodologia para adequá‑la às condições de 
execução de cada projeto.
2.4 ISO/IEC 14598 – Avaliação de produto de software
A norma ISO/IEC 14598 foi publicada em 1999 e estabelece um conjunto de tarefas com 
o objetivo de padronizar a avaliação da qualidade do produto de software. Trata‑se de um 
complemento da norma ISO/IEC 9126 e deve ser utilizada em conjunto com esta. A norma ISO/
IEC 14598 possui atividades para medir as características de um produto de software, relatórios 
e documentos de avaliação (1999).
A norma fornece subsídios para a avaliação de um produto de software em desenvolvimento ou já 
existente e descreve detalhadamente como avaliar cada característica do produto de forma quantitativa. 
A avaliação não se limita a avaliar o código ou o produto pronto, mas todos os artefatos produzidos 
durante o ciclo de vida do software, tais como: especificação de requisitos, protótipo de telas, modelo 
de dados, roteiro de testes, entre outros.
A norma ISO/IEC 14598 está subdividida em seis partes, e o objetivo de cada série está detalhado no 
Quadro 3.
Quadro 3 – Objetivo da série de normas da ISO/IEC 14598 (1999)
Norma Título Objetivo
14598‑1 Parte 1 – Visão geral Descrição geral da estrutura da norma e dos 
processos de avaliação 
14598‑2 Parte 2 – Planejamento e gestão Tarefas de planejamento e gestão do processo de 
avaliação 
14598‑3 Parte 3 – Processo para 
desenvolvedores
Atividades de avaliação durante o processo de 
desenvolvimento de software 
14598‑4 Parte 4 – Processo para adquirentes Atividades de avaliação do processo de seleção para 
aquisição do software 
14598‑5 Parte 5 – Processo para avaliadores Descrição do processo e das atividades de avaliação 
para os avaliadores 
14598‑6 Parte 6 – Documentação de módulos 
de avaliação
Descrição de métodos e ferramentas para apoio ao 
processo de avaliação 
A série de normas descreve o processo de avaliação do produto de software sob três perspectivas: 
desenvolvedor, adquirente e avaliador. Cada perspectiva possui quatro fases distintas no processo de 
avaliação: análise, especificação, projeto e execução, conforme exibido no Quadro 4.
38
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade I
Quadro 4 – Definição do processo de avaliação segundo a norma ISO/IEC 14598 (1999a)
Análise Especificação Projeto Execução
Processo para 
desenvolvedor
Definir as métricas 
dos requisitos de 
qualidade 
Criar requisitos de 
qualidade 
Planejar a avaliação 
durante a construção 
Monitorar e 
controlar a qualidade 
durante a construção 
Processo para 
adquirente
Estabelecer 
o escopo da 
avaliação 
Definir métricas 
externas a serem 
realizadas 
Planejar, programar 
e documentar a 
avaliação 
Monitorar e 
controlar a avaliação 
Processo para 
avaliador
Descrever os 
objetivos da 
avaliação 
Definir escopo da 
avaliação e das 
medições 
Documentar 
os processos a 
serem usados pelo 
avaliador 
Obter os resultados 
a partir das ações 
de medição e 
verificação 
Isso se faz necessário, uma vez que cada um desses envolvidos tem um papel diferente na construção 
do produto. O avaliador deve se preocupar em estabelecer as métricas que serão aplicadas considerando 
os padrões estabelecidos. O desenvolvedor deve se preocupar em criar processos e formas de medição 
da qualidade do produto durante sua construção. O adquirente tem a responsabilidade de avaliar um 
produto de software que está sendo adquirido e, para isso, precisa criar parâmetros e métricas que 
deixem claros os critérios adotados no seu parecer.
Para melhor descrever o conteúdo da norma ISO/IEC 14598, a seguir é descrito em detalhes o 
processo de avaliação de produtos de software sob a abordagem da série 14598‑1, pois esse ciclo se 
repete nas demais séries incluindo as tarefas específicas de cada uma delas.
São quatro fases distintas que são apresentadas na Figura 13.
1) Estabelecer os requisitos de avaliação.
2) Especificar a avaliação.
3) Projetar a avaliação.
4) Executar a avaliação.
39
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
Establecer requisitos de 
avaliação
Especificar a avaliação
Projetar a avaliação
Executar a avaliação
Estabelecer o propósito da avaliação
Selecionar medidas
Obter as medidas
Identificar tipos de produto(s) a serem avaliados
Estabelecer níveis de pontuação para as medidas
Comparar com critérios
Especificar modelo de qualidade
Estabelecer critérios para julgamento
Julgar os resultados
Produzir o plano de avaliação
Figura 13 – Visão geral do processo de avaliação da série ISO/IEC 14598
1) Estabelecer os requisitos de avaliação
Consiste em dizer quais características do produto de software fazem parte do processo e devem 
estar associadas às características de qualidade definidas na norma ISO/IEC 9126‑1. Nessa fase, é 
importante adequar as características da qualidade ao produto a ser avaliado, pois cada software 
tem suas características específicas e que devem ser respeitadas.
O resultado dessa fase consiste em dizer quais são os padrões de qualidade esperados.
2) Especificar a avaliação
Essa fase consiste em definir as medidas quantitativas para as características selecionadas na 
fase de requisitos. Além disso, devem‑se definir as metas e os critérios de avaliação de cada uma 
das medidas. Novamente as séries da norma ISO/IEC 9126‑2 e ISO/IEC 9126‑3 que definem as 
métricas internas e externas podem ser utilizadas como referência.
3) Projetar a avaliação
O objetivo dessa fase é descrever quem, como, o que, quando e onde as avaliações são aplicadas 
e documentadas para permitir a análise comparativa da evolução das medidas realizadas.
4) Executar a avaliação
Nessa fase, a avaliação é aplicada e se obtêm os resultados quantitativos das medidas. Esses 
resultados são comparados com as metas estabelecidas de acordo com os critérios definidos.
2.4.1 Relação entre as séries das normas ISO/IEC 9126 e ISO/IEC 14598
A partir da descrição das fases do processo de avaliação é possível verificar que há uma forte relação 
entre as normas ISO/IEC 9126 e ISO/IEC 14598. Portanto, ambas devem ser utilizadas em conjunto para 
a obtenção de melhores resultados no processo de avaliação. Essa relação é apresentada na Figura 14.
40
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade I
Observa‑se que há convergência entre as normas no que tange às características e subcaracterísticas 
definidas na série ISO/IEC 9126‑1 e, principalmente, na definição das métricas internas, das externas e 
na qualidade em uso descrita nas séries ISO/IEC 9126‑2, ISO/IEC 9126‑3 e ISO/IEC 9126‑4. As métricas 
são essenciais para que o processo de avaliaçãoseja realizado.
A série de normas da ISO/IEC 14598 define detalhadamente o processo de avaliação e como essas 
métricas são utilizadas durante a aplicação do modelo de avaliação do processo de software.
Lembrando que a avaliação da qualidade do produto de software também está envolvida nesse 
cenário de avaliação.
O processo de avaliação é iniciado com a definição do produto de software que faz parte da avaliação, 
a elaboração do plano de avaliação e a definição dos papéis e responsabilidades das pessoas envolvidas 
no processo.
O passo seguinte é escolher, do conjunto de características e atributos de qualidade da norma ISO/
IEC 9126, aqueles que se aplicam à avaliação em questão. A seguir, procede‑se à avaliação do produto, 
considerando que diagramas, modelos e documentos serão avaliados como requisitos de qualidade 
interna (ISO/IEC 9126‑3), enquanto o código e a aplicação serão avaliados como requisitos externos (ISO/
IEC 9126‑2). Para cada um desses requisitos de qualidade definidos devem ser estabelecidas métricas 
que são a referência das metas a serem atingidas. Estas podem variar em uma escala atribuída pelo 
avaliador, em que será definido o valor mínimo aceitável de avaliação para cada requisito.
Ao final, com base nas medidas coletadas pelo processo de avaliação, realizam‑se a avaliação dos 
resultados e o julgamento se o produto atende ao conjunto de requisitos da qualidade definidos.
Recursos e 
ambiente
Processo de 
avaliação
Efeitos do produto 
de software
14598-1
14598-2
14598-6
9126-3
14598-5
14598-4
14598-3
9126-1
9126-2 9126-4
Produto de 
software
Suporte à 
avaliação
Processo de 
avaliação
Métricas 
internas
Métricas 
externas
Métricas de 
qualidade em 
uso
Figura 14 – Relação entre as séries de normas ISO/IEC 9126 e ISO/IEC 14598
41
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
Portanto, a utilização das normas ISO/IEC 14598 e ISO/IEC 9126 deve ser em conjunto, pois são 
complementares. A geração do resultado da avaliação da qualidade deve ser realizada sempre com a 
participação do pessoal do produto que está sendo avaliado e de um avaliador certificado pela ISO.
2.5 ISO/IEC 25000 – SQuaRE (Software Product Quality Requirements and 
Evaluation)
O Modelo SQuaRE é a nova versão das normas ISO/IEC 9126 e ISO/IEC 14598 para especificação 
e avaliação da qualidade do produto de software publicada em 2008, com o objetivo de unificar o 
processo de medição da qualidade do software.
O objetivo da criação dessa norma é atualizar as informações de requisitos de qualidade, alinhar 
com novos conceitos de avaliação da qualidade, aumentar a consistência entre os atributos da 
qualidade descritos na norma ISO/IEC 9126 e o processo de avaliação da norma ISO/IEC 14598 e 
incluir procedimentos novos. Com isso, obtém‑se um documento único e consistente para todo o 
processo de qualidade.
A ISO/IEC 25000 contém cinco séries distintas, cuja estrutura é ilustrada na Figura 15.
ISO/IEC 25000
Guia do SQuaRE
Planejamento e Gerenciamento de Qualidade
ISO/IEC 25001
Modelo de 
qualidade
ISO/IEC 25002
Medição de 
qualidade
ISO/IEC 25003
Requisitos da 
qualidade
ISO/IEC 25004
Avaliação da
qualidade
Figura 15 – Séries de normas ISO/IEC 25000
 Observação
A estrutura da norma ISO/IEC 25000 (SQuaRE) está em processo de 
revisão e deve sofrer alterações.
A série ISO/IEC 25000 faz uma introdução geral sobre a norma e definição gerais sobre os termos 
utilizados nas séries. Também descreve orientações de como utilizar a norma e o relacionamento 
entre elas.
A série ISO/IEC 25001 corresponde à norma ISO/IEC 9126, que descreve as características dos 
requisitos de qualidade externos e internos. Detalha os requisitos de qualidade do produto de software.
A série ISO/IEC 25002 fornece um modelo de referência para medição da qualidade e orientações 
para a aplicação das métricas.
42
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade I
A série ISO/IEC 25003 apoia a especificação dos requisitos de qualidade durante a fase de 
levantamento de requisitos para um novo produto de software, ou seja, auxilia na definição dos padrões 
de qualidade esperados. Traz da norma ISO/IEC 9126 o conceito da relação de requisitos de qualidade 
com os requisitos do software.
A série ISO/IEC 25004 descreve os requisitos, as orientações para o processo de avaliação de produto 
de software e a definição dos documentos necessários para registrar todo o ciclo de medição realizado 
durante a avaliação. Apresenta uma estrutura de avaliação da qualidade oriunda das normas ISO/IEC 
9126‑1 e ISO/IEC 14598.
A Figura 16 mostra o conteúdo básico de cada uma das séries da norma ISO/IEC 25000, em que se 
pode observar a total interação com as normas de origem ISO/IEC 9126 e ISO/IEC 14598.
ISO/IEC 25000
ISO/IEC 25001
ISO/IEC 25002
ISO/IEC 25003
ISO/IEC 25004
• Guia do SQuaRE
• Planejamento e gestão
• Modelo de qualidade
• Planejamento e gestão
• Modelo de referência para medição
• Elementos de medida de qualidade
• Medição da qualidade interna
• Medição da qualidade esterna
• Medição da qualidade em uso
• Guia de referência de avaliação
• Módulo de avaliação
• Processo de avaliação para desenvolvedores
• Processo de avaliação para adquirintes
• Processo de avaliação para avaliadores
• Requisitos de qualidade
Figura 16 – Conteúdo básico da série de normas ISO/IEC 25000
43
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
 Observação
A norma ISO/IEC 25000 (SQuaRE) é mais recente, atualizada e incorpora 
todos os conceitos das normas ISO/IEC 9126 e ISO/IEC 14598. Portanto, 
deve‑se priorizar a sua utilização em relação às anteriores.
A norma ISO/IEC 25000 organiza, completa e elimina alguns conflitos que existem entre as normas 
ISO/IEC 9126 e ISO/IEC 14598, e ainda possui exemplos de utilização da norma que facilitam seu uso. 
Portanto, torna‑se a referência para ser aplicada nas avaliações de produto de software.
 Resumo
Nesta unidade, verificamos quão importante é o tema Qualidade 
de Software. Embora exista uma forte resistência das equipes de 
desenvolvimento de software e das próprias empresas fornecedoras de 
software, as organizações‑clientes estão cada vez mais exigentes com a 
qualidade do produto que recebem.
Abordamos que o conceito básico de qualidade sobre fazer certo da 
primeira vez é muito pouco utilizado, prevalecendo a técnica de tentativa 
e erro. Não se atua de forma preventiva diante dos problemas que podem 
ocorrer e que, embora conhecidos, não são tratados, e as atitudes tornam‑se 
reativas. O ato de revisar todo e qualquer artefato antes de entrega ao 
cliente simplesmente é ignorado na maioria das vezes. Além disso, os 
desenvolvedores continuam a pensar que o gerente é o responsável pela 
qualidade do software, quando a responsabilidade é de toda a equipe. 
Seguindo e praticando esses princípios básicos, os resultados colhidos 
estão cada vez mais alinhados com as expectativas e com a satisfação dos 
usuários finais.
Vimos também que os obstáculos à qualidade são muitos. Vão desde a 
cultura da organização que fornece o software e atua segundo o modelo 
corrente, que considera: “Se está dando certo até agora, para que alterar?”, 
quando os resultados poderiam ser muito melhores, até os próprios clientes, 
que continuam a contratar essas empresas que fornecem software ruim 
em vez de outras com processos de qualidade, porque simplesmente “Todo 
projeto de software é assim mesmo. Sempre está tudo com problema.”; 
além disso, os preços dessas empresas são mais baixos.
Aprendemos ainda que outro fator relevante como obstáculo à 
qualidade são as características dos softwares atuais que aumentaram 
44
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade I
muito a complexidade da interface com o usuário, as soluções técnicascada vez mais detalhadas para permitir uma infinidade de mídias a fim de 
consumir as informações e as necessidades de prazo cada vez menores para 
a construção do sistema. Além disso, temos a divergência das visões dos 
envolvidos no processo de desenvolvimento, em que cada um quer ver os 
resultados à sua maneira, mas são antagônicos; por exemplo: o cliente quer 
um produto rápido e barato, o usuário quer que atenda a todas as funções 
que ele deseja e que o sistema esteja sem erros, o desenvolvedor quer 
apenas codificar e ver seu programa funcionando e o gerente do projeto 
precisa que o sistema funcione dentro do prazo e do custo orçado. Essas 
diferentes visões tornam a qualidade do software um elemento deixado em 
segundo plano.
Abordamos ainda que, para ter qualidade em tudo o que é produzido, 
não basta testar no final para ver se está tudo certo. Como visto, a qualidade 
é um processo preventivo e, para tal, requer que sejam tomadas ações 
de garantia da qualidade durante o desenvolvimento, com verificações 
e validações de tudo o que for produzido. Ao final, tem‑se o controle 
da qualidade, que é a aplicação de testes para ter o aceite do software 
produzido. Portanto, vimos que para minimizar os problemas de qualidade, 
as empresas precisam se dedicar mais à garantia dessa qualidade, o que 
é realizado durante o processo de desenvolvimento, buscando atuar 
fortemente na prevenção de problemas e ter o controle de qualidade, 
realizado ao final, apenas como um atestado de que o produto atende aos 
requisitos do usuário.
Aprendemos também que a norma ISO/IEC 9000 trouxe para a área 
de Tecnologia da Informação os fundamentos de um SGQ, em que a 
preocupação está em transformar as atividades realizadas por pessoas 
em atividades perenes e que possam ser repetidas por qualquer indivíduo 
treinado e capacitado no processo. O SGQ define um conjunto de processos 
para que as empresas formalizem o seu padrão de trabalho, atendendo a 
um conjunto de requisitos essenciais para a elaboração de um trabalho. A 
norma NBR/ISO 9000 é o nome genérico que se dá às diversas normas que 
abordam o assunto. As normas básicas para garantia da qualidade são as 
contratuais – ISO 9001, ISO 9002 e ISO 9003 –, e as organizações só podem 
ser certificadas em relação a essas normas.
Conhecemos também a norma NBR/ISO 9000‑3 – Norma para 
Empresas de Desenvolvimento de Software –, que define as diretrizes para 
facilitar a aplicação da norma ISO 9001 a organizações que desenvolvem, 
fornecem e mantêm software. Publicada em junho de 1993, essa norma é 
dividida em três partes: atividades de estrutura, atividades do ciclo de vida 
e atividades de suporte. Nas atividades de ciclo de vida, a NBR/ISO 9000‑3 
45
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
abrange questões relacionadas ao entendimento dos requisitos funcionais, 
o uso de metodologias consistentes para desenvolvimento de software 
e o gerenciamento do projeto, desde a concepção até a implantação do 
software. Portanto, o objetivo da norma NBR/ISO 9000‑3 é indicar quais 
processos a organização deve ter e manter para o desenvolvimento do 
software com qualidade.
Vimos que a certificação ISO 9000 é reconhecida no mercado por muitas 
empresas e traz uma série de benefícios às organizações que adotam o 
sistema, como abertura de novos mercados, maior satisfação do cliente e 
menores custos de desenvolvimento. Para realizar a certificação, a empresa 
deve analisar o seu processo e treinar os funcionários para a conscientização 
da necessidade da qualidade. Na sequência, desenvolve os procedimentos 
necessários ao sistema da qualidade, seleciona um órgão certificador que 
irá avaliar se o sistema está de acordo com a norma, faz pré‑auditorias e 
realiza a auditoria final de aderência ao SGQ para a certificação.
Abordamos ainda que, durante a definição, deve‑se tomar cuidado 
para que o processo não se torne burocrático, do tipo que ninguém usa. 
Este deve se adaptar ao dia a dia da empresa, e não o contrário, senão o 
manual somente será lido quando houver processo de certificação. Além 
disso, a organização será reavaliada a cada dois anos e deverá manter o 
pessoal treinado e atualizado quanto aos processos para que não perca o 
certificado, pois isso pode ser muito custoso em termos financeiros e de 
imagem junto aos clientes. O gestor do SGQ deve ser o responsável por 
manter esse processo.
Foram apresentadas também as principais normas para verificação 
da qualidade de um produto de software nas organizações. Essas normas 
têm como objetivo minimizar os problemas de qualidade resultantes do 
processo de desenvolvimento de um software.
Em seguida, vimos que as primeiras preocupações com qualidade do 
produto de software surgiram em 1977, com McCall, que já destacava a 
visão de produzir um software pensando nas fases seguintes de operação 
e de manutenção, e não apenas na conclusão do trabalho. Isso mudou 
a forma de produção de software e deu origem a diversas normas que 
focam avaliar a qualidade dos produtos de software. O foco dos requisitos 
de McCall está em três abordagens. A primeira é a abordagem de revisão, 
com os requisitos de facilidade de manutenção, flexibilidade e facilidade de 
testes. Outra está relacionada à operação do produto com os requisitos de 
correção, confiabilidade, integridade e eficiência. A última abordagem é a 
de transição, com os requisitos de portabilidade, reúso e interoperabilidade.
46
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade I
Abordamos ainda que a norma de qualidade de produto de software 
pioneira foi a ISO/IEC 9126, que atribuiu características e subcaracterísticas 
ao software para permitir a avaliação de quão alinhada ao padrão de 
qualidade esperado a aplicação construída está, gerando uma avaliação 
quantitativa que possibilita a aceitação do produto ou a tomada de ações 
corretivas. Aprendemos que a norma segue basicamente os requisitos 
não funcionais definidos por McCall de forma reestruturada e acrescenta 
uma visão de facilidade de uso e funcional. Essas seis características 
são subdivididas para facilitar a avaliação. Para a característica de 
funcionalidade, são avaliadas a adequação, a acurácia, a segurança de 
acesso e a conformidade. Na confiabilidade, são avaliadas a maturidade, a 
tolerância a falhas, a recuperabilidade e a conformidade. Para a usabilidade, 
avaliam‑se os requisitos de facilidade de operação da aplicação. Para a 
eficiência, o foco é a avaliação do desempenho. Para a manutenibilidade, 
são abordados os requisitos de facilidade para incorporar mudanças. Para a 
portabilidade, são avaliados os requisitos de múltiplos ambientes.
Em seguida, vimos que a norma ISO/IEC 12207 já traz o foco de 
processo de desenvolvimento de software, abordando o ciclo completo, 
desde a concepção até a manutenção das aplicações, definindo uma forma 
estruturada para a construção de um sistema, independentemente do 
processo de desenvolvimento pela organização: espiral, incremental ou 
iterativo.
Aprendemos que a norma ISO/IEC 14598 traz os conceitos de avaliação 
quantitativa do produto de software e é utilizada em conjunto com a norma 
ISO/IEC 9126 para produzir notas relacionadas aos padrões de qualidade 
esperados e à avaliação de cada requisito de qualidade.
Finalmente, abordamos a norma ISO/IEC 25000 – SquaRE –, que unificou 
as normas ISO/IEC 9126 e ISO/IEC 14598 em apenas uma, incluindo novas 
atualizações e proporcionando maior facilidade de uso, por trazer todos os 
conceitos de requisitos de qualidade do produto de software e avaliação na 
mesma norma.
 Exercícios
Questão 1. No controle da qualidade, uma atividade deve ser executada visando avaliar se as ações 
de qualidade planejadas estão sendo executadas de acordo com o processo estabelecido. Essa atividade 
chama‑se auditoria e pode gerar ações corretivas no caso de não encontrar conformidades. Essasações 
corretivas são comumente classificadas em três tipos. Qual das alternativas corresponde ao tipo de ação 
corretiva que verifica especificamente se as ações de qualidade planejadas estão sendo executadas de 
forma adequada?
47
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
A) Auditorias de produto.
B) Auditorias de processo.
C) Auditorias de sistemas de qualidade.
D) Sistemas de gestão de qualidade.
E) Garantia de qualidade.
Resposta correta: alternativa B.
Análise das alternativas
A) Alternativa incorreta.
Justificativa: essa ação corretiva verifica apenas a conformidade do produto, e não os processos 
sobre os quais foi elaborado.
B) Alternativa correta.
Justificativa: somente essa ação corretiva de auditoria permite verificar se as ações de qualidade 
estão sendo executadas de forma adequada. Isso é possível com a verificação de cada ação (processo, 
etapas) do ciclo planejado.
C) Alternativa incorreta.
Justificativa: essa ação corretiva observa e avalia o processo como um todo e mensura os resultados, 
avalia a eficácia da utilização do sistema de qualidade implantado, e não especificamente de cada 
processo executado pelo sistema em questão.
D) Alternativa incorreta.
Justificativa: sistemas de gestão têm como objetivo padronizar processos de uma empresa, e não 
especificamente verificar as ações de qualidade planejadas.
E) Alternativa incorreta.
Justificativa: não verificam a execução de ações de qualidade planejadas. Essa alternativa está focada 
na garantia de qualidade do produto gerado com a adequação de padrões.
Questão 2. Um Sistema de Gestão da Qualidade (SGQ) tem como objetivo padronizar os processos 
de uma empresa para a produção de seu produto final, proporcionando a satisfação de seus clientes e a 
melhoria contínua dos seus processos (ANTONIONI, 1995). Existem diversos fatores que podem motivar 
a implantação de um SGQ. 
48
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade I
Assinale a alternativa que apresenta o fator mais relevante à necessidade de um SGQ. 
A) Diminuir o entrosamento entre empresa e cliente com o intuito de não dificultar os processos 
produtivos, regras de negócios e o ciclo planejado de entrega do produto.
B) Diminuir o volume de dados relacionados às atividades ou dos processos de qualidade com o 
intuito de facilitar a tomada de decisão.
C) Diminuir o volume de dados relacionados aos processos de gestão e das etapas de geração de um 
produto para flexibilizar as correições e melhorias.
D) Evitar medir de forma contínua a satisfação do cliente. 
E) A alta direção de uma empresa reconhece que a qualidade é um diferencial e patrocina o processo.
Resposta desta questão na plataforma.
49
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
Unidade II
3 FUNDAMENTOS DE QUALIDADE PARA PROCESSO DE SOFTWARE
Os modelos vistos até o tópico 2 são voltados para a qualidade do produto de software, ou seja, 
para o produto final. No entanto, para que o resultado seja adequado e o produto atenda aos requisitos 
estabelecidos, faz‑se necessário que a empresa tenha um processo de desenvolvimento consolidado e 
maduro que organize e padronize o processo.
Os modelos de qualidade voltados para a avaliação do processo de desenvolvimento auxiliam as 
empresas a construírem uma estrutura adequada e robusta para a produção do software, orientando‑as 
a respeito de como podem evoluir e atingir graus de maturidade cada vez mais elevados. Os modelos 
abordados neste tópico são apresentados no Quadro 5.
Quadro 5 – Modelos de qualidade para avaliação de processo de software
Modelo Objetivo
ISO/IEC 15504 (Spice) Modelo cujo objetivo é fazer a avaliação de processo de desenvolvimento de software 
CMMI Modelo de maturidade de desenvolvimento de software que auxilia as empresas a 
aprimorarem o seu processo 
MPS.BR Modelo que tem como objetivo a melhoria do processo de software voltado para a 
realidade brasileira 
O surgimento desses modelos de qualidade de processos vem desde a metade da década de 1980, 
com o aparecimento do SGQ da ISO 9000 e a introdução do Capability Maturity Model (CMM) pelo 
Software Enginnering Institute/Carnegie‑Mellow University (SEI/CMU), no início da década de 1990, 
que apresenta uma descrição das atividades necessárias para uma empresa atingir um alto nível de 
qualidade no desenvolvimento de software. A partir do CMM, foi elaborada a ISO/IEC 15504, modelo 
Spice, para padronizar o processo de avaliação de qualidade. Com a atualização do CMM, que se tornou 
CMMI, o modelo ficou mais abrangente e detalhado em relação à avaliação da maturidade. No Brasil, em 
razão dos altos custos de implementação do modelo CMMI, foi criado o modelo brasileiro denominado 
de Melhoria de Processos do Software Brasileiro (MPS.BR), cujo objetivo é reduzir os custos de evolução 
para as pequenas e médias empresas brasileiras, com vistas à evolução e à avaliação da maturidade.
 Saiba mais
SEI/CMU é um instituto de pesquisa sobre engenharia de software nos 
Estados Unidos dedicado à melhoria do processo de desenvolvimento de 
sistemas. Visite o site: .
50
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade II
A cronologia da evolução dos modelos de qualidade de processos é apresentada na Figura 17.
ISO 9000 ISO 9000
SPICE
ISO 
12207
CMM TR CMM 1.0 CMM 1.1 CMM I
ISO 
15504 MPS.BR
ISO 9000
1985 1990 1995 2000 2005
Figura 17 – Cronologia dos modelos de qualidade para avaliação de processo de software
3.1 Norma ISO/IEC 15504 – Spice – Melhoria do Processo de Software
A norma ISO/IEC 15504 foi publicada em 1998 e é o resultado da combinação do Modelo de Qualidade 
de Processo de Software CMM, da norma ISO/IEC 12207, da qual trouxe os processos de ciclo de vida, da 
ISO 9001, da ISO 9000‑3, dentre outros.
O significado de Spice é Software Process Improvement and Capability Determination, ou seja, 
Melhoria do Processo de Software e Determinação da Capacidade, que está relacionada à maturidade 
das empresas na construção do software. Essa norma descreve um conjunto de processos que agregam 
uma série de boas práticas da Engenharia de Software e classificam as empresas em seis níveis de 
maturidade que permitem a avaliação do grau de qualidade de desenvolvimento de software em que as 
organizações se encontram, de acordo com as práticas utilizadas.
A Spice está dividida em duas partes: Processo de Desenvolvimento e Processo de Capacidade. Na 
primeira parte os requisitos são descritos e classificados de acordo com a norma ISO/IEC 12207, que 
contém: os processos de engenharia de software, o processo de aquisição, os processos de gerência e os 
organizacionais. Na segunda parte são descritos os requisitos de maturidade das empresas de software 
de acordo com o modelo CMM.
 Lembrete 
Maturidade refere‑se aos graus de conhecimento e de execução das 
melhores práticas de Engenharia de Software que levam as empresas a 
produzirem software com qualidade.
A norma ISO/IEC 15504 possui nove séries que descrevem o processo e estão ilustradas na Figura 18.
51
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
Parte 7
Guia para 
melhoria de 
 processo
Parte 3
Realização de uma 
avaliação
Parte 2
Modelo de referência 
para processos e 
capabilidade
Parte 4
Guia para realização de 
uma avaliação
Parte 5
Modelo para 
avaliação e guia de 
indicadores
Parte 8
Guia para determinação 
da capabilidade de 
fornecedor
Parte 1
Conceitos e guia 
introdutório
Parte 9
Vocabulário
Parte 6
Guia para qualificação de 
avaliadores
Figura 18 – Série de normas da ISO/IEC 15504
1. Partes normativas
• ISO/IEC 15504‑2 – Modelo de Referência para Processo e Capacidade: descreve o processo para a 
realização da avaliação da capacidade da organização.• ISO/IEC 15504‑3 – Requisitos para a Realização de uma Avaliação: é um guia de procedimento 
para a realização da avaliação da maturidade.
2. Partes informativas
• ISO/IEC 15504‑1 – Visão Geral da Norma: apresenta uma série de conceitos e guia introdutório da 
descrição dos procedimentos na norma.
• ISO/IEC 15504‑4 – Resultados de uma Avaliação: é um guia para a utilização dos resultados da avaliação.
• ISO/IEC 15504‑5 – Modelo de Utilização: apresenta um exemplo para a utilização da norma.
• ISO/IEC 15504‑6 – Guia para a Qualificação de Avaliadores: descreve os procedimentos para 
treinamento e certificação dos avaliadores do processo.
• ISO/IEC 15504‑7 – Guia para Melhoria de Processo.
• ISO/IEC 15504‑8 – Descrição para Determinação da Maturidade.
• ISO/IEC 15504‑9 – Vocabulário de Termos.
52
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade II
Como a série ISO/IEC 15504‑2 é a principal do modelo da norma ISO/IEC 15504, são detalhadas aqui 
a lista dos processos de desenvolvimento e a determinação dos níveis de maturidade que as organizações 
podem alcançar e exibidas nos Quadros 6 e 7.
Quadro 6 – Categorias do processo de desenvolvimento na norma ISO/IEC 15504‑2
Categoria Processo
Cliente‑fornecedor
• Aquisição
• Fornecimento
• Levantamento de requisitos
• Operação e suporte ao usuário final 
Engenharia de Software
Construção
• Levantamento de requisitos
• Análise
• Projeto de software
• Construção do software
• Integração do software
• Teste de software
• Integração e testes de sistema
Manutenção
Apoio
• Documentação
• Gestão da configuração
• Garantia da qualidade
• Verificação
• Validação
• Revisão conjunta
• Auditoria
• Resolução de problemas 
Gerenciamento
• Gestão de projetos
• Gestão da qualidade
• Gestão de riscos 
Organização
• Alinhamento gerencial
• Melhoria
• Gestão de recursos humanos
• Medições
• Reutilização 
Fonte: ISO (2003c).
53
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
Quadro 7 – Descrição dos níveis de maturidade na norma ISO/IEC 15504‑2
Nível de capacidade Características básicas
0 – Incompleto Processo inexistente ou geralmente falho 
1 – Executado Atinge os objetivos, mas sem controle de escopo, prazo e custos e sem 
padrões de qualidade 
2 – Gerenciado Atinge os objetivos de prazo, custo e qualidade, e os produtos são 
gerenciados 
3 – Estabelecido Processo estabelecido, executado e gerenciado mediante adaptação ao 
padrão definido 
4 – Previsível Processo estabelecido e totalmente controlado por medições específicas 
5 – Otimizado Melhoria de forma contínua e disciplinada 
Fonte: ISO (2003c).
O processo de desenvolvimento descreve os processos necessários para a aquisição da engenharia 
para a construção do produto de software, os procedimentos para manutenção do software, os processos 
para a garantia da qualidade, os processos relacionados ao gerenciamento e a descrição de como a 
estrutura da organização deve contribuir para o processo de desenvolvimento de software.
Os níveis de maturidade determinam o quanto uma organização tem domínio de todo o ciclo de 
produção de software, bem como de todos os processos que podem garantir a produção de um software 
de qualidade e a capacitação contínua das pessoas envolvidas.
3. ISO/IEC 15504‑2 – O processo de desenvolvimento
Nessa parte, a norma incorpora os requisitos da ISO/IEC 12207, detalhando como deve ser realizado o 
processo de desenvolvimento, abordando os aspectos primários concernentes à Engenharia de Software 
e à relação cliente‑fornecedor, além dos processos de apoio à qualidade, à gestão e dos processos 
organizacionais.
4. ISO/IEC 15504‑2 – Determinação da maturidade
Nessa parte, a norma incorpora os requisitos do CMM publicado pelo SEI/CMU e estabelece um 
roteiro de seis níveis de maturidade, conforme a Figura 19, em que cada nível representa o estágio 
de conhecimento e qualidade em que a organização se encontra. Tais estágios podem ser alcançados 
sequencialmente, à medida que a empresa evolui e aperfeiçoa os seus processos de qualidade.
54
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade II
4 – Previsível
5 – Otimizado
3 – Estabelecido
2 – Gerenciado
1 – Executado
0 – Incompleto
Figura 19 – Níveis de maturidade na norma ISO/IEC 15504‑2
Cada nível de maturidade possui características básicas para avaliação de uma empresa, que, por 
sua vez, tem um conjunto de atributos específicos que permitem medir a evolução da capacidade 
de cada item, com o objetivo de determinar se as condições mínimas para atingir o nível desejado 
foram alcançadas. As características básicas para que uma organização atinja os níveis de maturidade 
esperados pela avaliação do processo são descritas no Quadro 7.
Para que o processo possa fazer a avaliação de cada nível com base nessas características, são 
descritos atributos de processo que permitem que essas sejam avaliadas de forma quantitativa.
A medição quantitativa é muito importante para todo processo de avaliação, pois permite que seja 
determinado quão perto ou distante da maturidade um atributo está, com base na nota atribuída 
durante a avaliação.
3.1.1 Níveis de maturidade
A norma ISO/IEC 15504 – Spice descreve os níveis de maturidade e seus respectivos atributos que 
permitem a sua qualificação conforme descrito e apresentado no Quadro 8.
Os atributos devem ser atendidos de forma cumulativa, à medida que a organização evolui em seus 
processos.
55
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
Quadro 8 – Atributos por nível de maturidade na norma ISO/IEC 15504‑2
Nível de capacidade Atributos relacionados
0 – Incompleto Nenhum atributo
1 – Executado 1.1
2 – Gerenciado 2.1 e 2.2
3 – Estabelecido 3.1 e 3.2
4 – Previsível 4.1 e 4.2
5 – Otimizado 5.1 e 5.2
Fonte: ISO (2003c).
• Nível 0 – Incompleto
Nenhum processo é utilizado e não gera os resultados esperados. Esse nível também é conhecido 
como caótico. Não há atributos de processo para classificar esse nível.
• Nível 1 – Executado
O processo consegue alcançar alguns de seus objetivos e gerar os produtos de trabalhos esperados.
— Atributo
— Área de Processo 1.1 – Atributo de execução de processo
O processo transforma as necessidades do cliente em produtos de trabalho que geram os 
resultados esperados para o projeto.
• Nível 2 – Gerenciado
O processo, além de executado, é feito de maneira gerenciada, planejada, controlada, acompanhada, 
verificada e corrigida de acordo com as condições estabelecidas.
— Atributos
— Área de Processo 2.1 – Atributo de gestão de execução de processo
Esse atributo mede até que ponto o processo é gerenciado para gerar os produtos de 
trabalho que satisfazem aos seus objetivos.
— Área de Processo 2.2 – Atributo de gestão dos produtos de trabalho
Esse atributo mede até que ponto os produtos de trabalho são documentados, controlados 
e verificados.
56
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade II
• Nível 3 – Estabelecido
O processo, agora, além de executado e gerenciado, é definido com base em princípios de 
engenharia de software e tem âmbito organizacional.
— Atributos
— Área de Processo 3.1 – Atributo de definição de processo
Esse atributo mede até que ponto o processo é definido com base em um procedimento 
padronizado.
— Área de Processo 3.2 – Atributo de recursos de processo
Esse atributo mede até que ponto o processo faz uso de recursos humanos e materiais para 
ser executado de maneira bem‑sucedida.
• Nível 4 – Previsível
O processo, agora, além de ser executado, gerenciado e definido, também passa a ser medido 
quantitativamente em relação aos resultados produzidos.
— Atributos
— Área de Processo 4.1 – Atributo de medida
Esse atributo mede até que ponto as mensurações feitas são utilizadas paraassegurar a 
execução do processo no que se refere a alcançar os objetivos de negócio da empresa.
— Área de Processo 4.2 – Atributo de controle de processo
Esse atributo mede até que ponto o processo é controlado por intermédio de coleta, análise 
e uso de medições, com o objetivo de servir como base para ações corretivas, quando 
necessário.
• Nível 5 – Otimizado
O processo, agora, além de executado, gerenciado, definido e medido dentro de limites quantitativos, 
pode ser mudado e evoluído de maneira dinâmica e controlada.
— Atributos
— Área de Processo 5.1 – Atributo de inovação
Esse atributo mede até que ponto mudanças na definição, na gerência e na execução do 
processo são controladas.
57
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
— Área de Processo 5.2 – Atributo de melhoria contínua
Esse atributo mede até que ponto as mudanças de processo contribuem para a melhoria 
contínua.
 Observação
Embora seja um padrão ISO, a norma ISO/IEC 15504 é pouco utilizada 
no mercado, em que o modelo de qualidade do CMMI é o mais reconhecido 
no âmbito internacional, e o MPS.BR, no mercado brasileiro.
3.1.2 Pontuação dos atributos para determinação do nível de maturidade
A partir da definição de cada área de processo dos níveis de maturidade, os atributos podem ser 
medidos quantitativamente para avaliar o grau de capacidade em que o processo é utilizado em uma 
organização.
A norma ISO/IEC 15504 possui uma escala de faixa com quatro valores que avaliam o atendimento 
aos requisitos do atributo de processo, conforme segue.
1. N (Não atendido)
— 0% a 15%: há pouca ou nenhuma evidência de que o atributo foi satisfeito.
2. P (Parcialmente atendido)
— 16% a 50%: há evidências de uso contínuo e repetitivo de uma prática, no entanto algumas 
práticas ainda não são utilizadas.
3. L (Largamente atendido)
— 51% a 85%: há evidências de uso contínuo e repetitivo das práticas; porém, durante a execução, 
há variação no uso do processo dentro da empresa.
4. F (Totalmente atendido)
— 86% a 100%: há evidências de uso contínuo e repetitivo das práticas e não há diferenças 
significativas na execução do processo em todas as áreas da organização.
A avaliação do processo de software dentro da organização considerando essas quatro faixas permite 
a classificação do grau de maturidade em que a empresa se encontra. Essa avaliação deve ser feita por 
examinadores treinados e capacitados pela ISO e deve seguir o processo descrito na norma ISO/IEC 
15504‑5.
58
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade II
 Observação
O termo evidência indica que existe um artefato ou documento 
provando que determinada prática é realizada. Por exemplo: a ata é uma 
evidência da realização de uma reunião.
Exemplo de aplicação
Para realizar uma avaliação utilizando a norma ISO/IEC 15504 é necessário que seja elaborado o plano de 
avaliação, o qual descreve o que será avaliado em cada item do processo de desenvolvimento, como isso será 
feito e os responsáveis por cada etapa. Deve haver duas fases: uma avaliação preliminar e outra definitiva. O 
tempo compreendido entre as duas avaliações serve para a organização adequar‑se às não conformidades 
apontadas na avaliação preliminar. Por exemplo: ao avaliar o atributo 1.1 de execução de processo, foi avaliado 
com nota P – Atende parcialmente, indicando que algumas práticas ainda não são utilizadas. A organização 
tem o tempo até a avaliação definitiva para gerar as evidências de utilização das práticas pendentes.
Uma vez definidos o plano de avaliação e os responsáveis, é necessário estabelecer o processo de 
avaliação que deve conter, no mínimo:
• planejamento;
• coleta de dados;
• validação dos dados coletados;
• atribuição de nota;
• registro dos resultados.
No planejamento são definidos os projetos que devem participar da avaliação e suas respectivas equipes.
A coleta e a validação dos dados são feitas pela equipe do projeto e pelos avaliadores, com o intuito 
de garantir que os dados sejam válidos como evidência.
Considerado válido o dado, deve ser atribuída uma nota a cada atributo do processo. As notas 
possíveis são: N (Não atendido), P (Parcialmente atendido), L (Largamente atendido) e F (Totalmente 
atendido). Para ser considerada em um nível de capacidade, a nota mínima de uma organização tem de 
ser L ou F, e obrigatoriamente F nos níveis anteriores.
Ao final, é feita uma avaliação conjunta para registrar os resultados da avaliação. Na Tabela 5 são 
exemplificados resultados de avaliações hipotéticas realizadas sobre os processos do ciclo de vida de um 
software.
59
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
Tabela 5 – Resultados das avaliações de processos do ciclo de vida de um software
Nível 1 2 3 4 5
Capacidade
Atributos 1.1 2.1 2.2 3.1 3.2 4.1 4.2 5.1 5.2
Elicitação de 
requisitos F L F P P ‑ ‑ ‑ ‑ 2
Projeto de 
arquitetura P P L N N ‑ ‑ ‑ ‑ 0
Projeto do 
software F F F F L L N ‑ ‑ 3
Construção F P L P N ‑ ‑ ‑ ‑ 1
Testes de 
software F F F F F L L ‑ ‑ 4
No processo Projeto de software, verifica‑se que está no nível 3, pois sua nota para os atributos dos 
níveis 1 e 2 é igual a F.
Para o processo Arquitetura de software, verifica‑se que se encontra no nível 0, pois não contém 
nenhum atributo nos níveis anteriores com nota igual a F.
4 MODELOS DE QUALIDADE PARA PROCESSO DE SOFTWARE
Os modelos de qualidade para processo de software visam verificar o quanto uma empresa está 
madura em relação à execução das melhores práticas de desenvolvimento de aplicações, uma vez que, 
se boas práticas forem aplicadas em todos os níveis, a qualidade do software será consequência disso. A 
seguir, são apresentados os dois modelos mais utilizados no mercado.
4.1 Capability Maturity Model Integration (CMMI)
O CMMI é um modelo de qualidade de software, desenvolvido pelo Software Engineering Institute, 
da Carnegie‑Mellow University (SEI/CMU), para o Departamento de Defesa Norte‑americano – United 
States Department of Defense (DoD), com o objetivo de avaliar a maturidade das empresas que fornecem 
software para o departamento.
Sua primeira versão foi publicada em 1991, quando ainda era denominado Software Capability 
Maturity Model (SW‑CMM) e abrangia outras áreas além do desenvolvimento de software. No ano 2000 
foi publicada a primeira versão do CMMI, que foi criado com o objetivo de unificar os modelos CMM 
existentes. Em sua versão atual há descrição para os processos de desenvolvimento de software, aquisição 
e serviços. O modelo CMMI é reconhecido mundialmente pelas empresas que adquirem software.
O CMMI descreve orientações de quais processos devem ser implementados pela organização 
para atingir a maturidade no desenvolvimento de software, mas não descreve o “como fazer”. Cada 
organização deve definir os seus próprios processos para implantar as melhores práticas previstas 
no modelo.
60
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade II
Ao verificar esses diversos modelos apresentados, você deve estar se perguntando: “Qual a vantagem 
para uma empresa implantar o modelo CMMI?”. Além de “abrir portas” para o fornecimento de software 
em diversos países e proporcionar a redução dos custos, podemos citar:
• processo de desenvolvimento padronizado;
• melhoria nas estimativas de prazos e custos;
• aumento de produtividade por repetição dos processos;
• satisfação do cliente e da equipe;
• alta qualidade dos produtos de software.
CMM 1991 CMMI‑SW 2000
Figura 20 – Evolução do Modelo CMM para o CMMI
4.1.1 Estrutura do CMMI
O CMMI é estruturado em níveis de um a cinco que representam o grau de maturidade da empresa 
no processo de software. Essa divisão o difere do modelo Spice, que tem níveis de zero a cinco.
Cada nível de maturidade possui um conjunto de boas práticas denominadas áreas de processoque precisam ser executadas durante o desenvolvimento do software. Da mesma forma que o 
modelo Spice, o CMMI não diz como fazer, apenas descreve o que as empresas devem realizar 
para atingir o nível de qualidade esperado. Cada qual deve estabelecer o seu processo para atingir 
os níveis de maturidade.
Esses níveis podem ser representados de duas formas: contínua ou estagiada. A representação por 
estágio é mais utilizada e reconhecida no mercado de Tecnologia da Informação. Essas representações e 
suas estruturas são apresentadas em detalhes a seguir.
 Observação
O termo projeto é utilizado para descrever o desenvolvimento de um 
software dentro de um tempo determinado para produzir algo inédito na 
visão dos usuários.
61
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
4.1.2 Áreas de processo
As áreas de processo – process areas (PA) representam todas as boas práticas de Engenharia de 
Software que devem ser aplicadas no processo de construção de um software. Para cada área de processo 
existem tarefas que precisam ser praticadas para verificação de evidência de execução daquela PA.
São 25 áreas de processo divididas em quatro categorias, conforme a Figura 21.
CMMI
Gerência de 
processos
Gerência de 
projetosSuporte
Engenharia
Figura 21 – Categorias do CMMI
• Área de Gerenciamento de Processos
— Possui as áreas de processo relacionadas às ações organizacionais que permitem a definição, a 
implantação, o monitoramento, a avaliação e a medição dos processos. São elas:
— Foco no Processo Organizacional.
— Definição do Processo Organizacional.
— Treinamento Organizacional.
— Desempenho do Processo Organizacional.
— Inovação e Desenvolvimento Organizacional.
62
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade II
• Área de Gerenciamento de Projetos
— Descreve as áreas de processo que definem as boas práticas para o planejamento, a execução, o 
controle e o encerramento dos projetos de software. São elas:
— Planejamento de Projetos.
— Monitoramento e Controle de Projetos.
— Gerência de Acordos com Fornecedores.
— Gerência Integrada de Projetos.
— Gerência de Riscos.
— Integração de Equipes.
— Gerência de Fornecedores Integrada.
— Gerência Quantitativa de Projetos.
• Área de Engenharia
— Envolve as áreas de processo voltadas para a construção e a manutenção do software. São elas:
— Gerência de Requisitos.
— Desenvolvimento de Requisitos.
— Solução Técnica.
— Integração de Produtos.
— Verificação.
— Validação.
• Área de Suporte
— Relaciona as áreas de processo que servem de apoio ao desenvolvimento e à manutenção do 
software. São elas:
— Gerência de Configuração.
63
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
— Garantia da Qualidade do Processo e do Produto.
— Medição e Análise.
— Ambiente Organizacional para Integração.
— Análise de Decisões e Resoluções.
— Análise de Causas e Resoluções.
Os detalhes do que consiste cada área de processo são descritos a seguir, nas representações contínua 
e estagiada do Modelo CMMI.
4.1.3 Representação do modelo CMMI
O CMMI apresenta duas abordagens para definição do nível de evolução em que uma organização 
se encontra. São as representações contínua e estagiada.
A representação contínua permite a uma organização atingir diferentes níveis de capacidade para 
cada PA do modelo, priorizando a que traz maiores benefícios. Por exemplo, uma determinada área 
de uma organização pode estar no nível 3 para a PA de Gerência de Requisitos, mas, para a PA de 
Planejamento de Projetos, pode ainda estar no nível 2. A representação contínua apresenta seis níveis 
de capacidade, de zero a cinco.
No caso da representação estagiada, o modelo reúne as áreas de processo em níveis e está estruturada 
de forma que permita a evolução gradual da organização na melhoria contínua e a maturidade dos seus 
processos. A representação estagiada apresenta cinco níveis de maturidade, de um a cinco.
 Lembrete
A representação contínua refere‑se ao nível de capacidade do processo 
que é a habilidade técnica de se fazer algo e alcançar o resultado esperado.
4.1.4 Representação contínua
Os níveis de capacidade do modelo CMMI para a representação contínua estão divididos em seis 
estágios e representados na Figura 22.
64
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade II
0
Incompleto
1
Realizado
2
Gerenciado
3
Definido
4
Quantitativo
5
Otimizado
Figura 22 – Níveis de capacidade da representação contínua
• Nível 0: o processo praticamente não existe e é totalmente reativo.
• Nível 1: o processo é mais definido, mas ainda reativo.
• Nível 2: o processo é gerenciado e repetível.
• Nível 3: o processo ocorre em nível organizacional e é proativo.
• Nível 4: o processo é medido e controlado.
• Nível 5: o processo é constantemente melhorado.
As áreas de processo que são abrangidas pela representação contínua estão distribuídas em quatro 
categorias, de acordo com a ilustração da Figura 21. A utilização da representação contínua é útil para 
organizações que possuem diferentes níveis de evolução nas diversas PAs do modelo CMMI. Dentre suas 
principais vantagens estão:
• estrutura compatível com a ISO/IEC 15504 – Spice;
65
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
• fornecimento de maior flexibilidade focando áreas de processo específicas de acordo com metas 
e objetivos da organização;
• maior visibilidade das melhorias alcançadas em cada PA;
• menor investimento inicial.
4.1.5 Representação por estágio
A representação estagiada apresenta um roteiro sequencial para a implementação do modelo em 
que cada nível alcançado dá suporte para a implementação dos níveis subsequentes, garantindo uma 
evolução sólida e sustentável.
 Lembrete
A representação estagiada refere‑se ao nível de maturidade do 
processo que é a capacitação atingida na execução das atividades definidas.
De acordo com a ilustração da Figura 23, são cinco os níveis de maturidade para representar em que 
ponto a organização se encontra no processo de melhoria contínua.
1
Inicial
2
Gerenciado
3
Definido
4
Quantitativo
5
Otimizado
Figura 23 – Níveis de maturidade da representação por estágio
• Nível 1: o processo é imprevisível, pouco controlado e muito reativo.
• Nível 2: o processo ocorre por projetos, e a qualidade é alcançada por repetição.
66
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade II
• Nível 3: o processo ocorre em nível organizacional e é proativo.
• Nível 4: o processo é medido e controlado.
• Nível 5: o processo é constantemente melhorado.
As áreas de processo estão distribuídas nos cinco níveis de maturidade de forma que permita a melhoria 
gradativa do nível de qualidade do software nas empresas, conforme apresentado no Quadro 9.
A utilização da representação estagiada é a mais usada e mais comum no mercado de software, pois 
deriva do modelo CMM original. Entre suas principais vantagens tem‑se:
• Classificação facilmente identificada no mercado de aquisição de software.
• Modelo sequencial e gradativo de melhoria.
• Foco na melhoria da organização.
Em uma avaliação, atribui um nível de maturidade em que a organização se encontra, permitindo, 
assim, comparar organizações de forma direta.
Quadro 9 – Áreas de processo da representação por estágio
Nível de maturidade Áreas de processo
5 – Otimizado
• Análise de Causas e Resoluções
• Inovação e Desenvolvimento Organizacional
4 – Quantitativo
• Desempenho do Processo Organizacional
• Gerência Quantitativa de Projetos
3 – Definido
• Foco no Processo Organizacional
• Definição do Processo Organizacional
• Treinamento Organizacional
• Gerência Integrada de Projetos
• Gerência de Riscos
• Integração de Equipes
• Gerênciade Fornecedores Integrada
• Desenvolvimento de Requisitos
• Solução Técnica
• Integração de Produtos
• Verificação
• Validação
• Ambiente Organizacional para Integração
• Análise de Decisões e Resoluções
67
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
2 – Gerenciado
• Planejamento de Projetos
• Monitoramento e Controle de Projetos
• Gerência de Acordos com Fornecedores
• Gerência de Requisitos
• Gerência de Configuração
• Garantia da Qualidade do Processo e do Produto
• Medição e Análise 
Fonte: SEI (2006).
O CMMI não diz qual a melhor representação a ser utilizada. A escolha é exclusiva da empresa 
que aplica o modelo, de acordo com o nível de qualidade em que a organização se encontra, a sua 
maturidade organizacional e a disponibilidade financeira que possui para investir. O Quadro 10 apresenta 
uma análise comparativa entre as duas representações.
Quadro 10 – Áreas de processo da representação por estágio
Contínua Por estágio
Maior flexibilidade na melhoria dos processos A melhoria de processos já está preestabelecida 
Foco na melhoria dentro da área de processo Foco na melhoria organizacional 
Evoluções das áreas de processos podem ocorrer de 
forma diferente Resultados são gerais, por nível de maturidade 
Práticas genéricas nas áreas de processo em todos 
os níveis 
Práticas genéricas para as áreas de processo dos níveis 
2 e 3 
Fonte: SEI (2006).
Como a representação por estágio é a mais utilizada e reconhecida no âmbito internacional, 
a seguir, são detalhados os níveis de maturidade do modelo CMMI da representação estagiada 
apresentada no Quadro 9. Lembrando ainda que CMMI não é uma certificação de qualidade, mas sim 
uma avaliação do nível de maturidade em que as empresas se encontram no momento, realizada por 
empresas autorizadas pelo SEI/CMU para executá‑la e com uma validade de três anos, período após 
o qual deve ser feita nova avaliação.
4.1.5.1 CMMI – Nível 1: Inicial
O Nível 1 representa um processo de software denominado caótico. Nesse nível, o processo é 
caracterizado como imprevisível, reativo aos problemas que ocorrem e baseado em esforços individuais 
para o sucesso do projeto. Normalmente, não há planejamento do projeto, os cronogramas são irreais, 
não há controle dos requisitos do software, o foco está apenas na codificação e o cliente avalia o 
produto somente ao final do projeto.
Como resultado desse cenário, a equipe não acredita que a modelagem, os processos, a 
documentação e os padrões sejam significativos para o sucesso do projeto, e a execução deste se dá 
68
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade II
com esforços e prazos fora das expectativas do cliente, causando insatisfação do cliente e constante 
desmotivação da equipe.
4.1.5.2 CMMI – Nível 2: gerenciado
No Nível 2 são implementadas as sete áreas de processos básicas que estabelecem um conjunto de 
atividades mínimas necessárias para a execução e o controle de um projeto de software. Essas atividades 
focam o processo de gerenciamento de projetos para permitir que estes tenham êxito com base na 
repetição de sucesso de projetos anteriores. Essas sete áreas são:
• Gerência de Requisitos.
• Planejamento de Projeto.
• Monitoração e Controle de Projeto.
• Garantia da Qualidade do Processo e do Produto.
• Gerência de Acordo com Fornecedores.
• Gerência de Configuração.
• Medição e Análise.
Ao implementar o Nível 2, os processos de gestão de requisitos e controle de escopo, prazos e custos 
são estabelecidos, bem como as atividades de garantia da qualidade e o início do processo de medição 
que vai permitir a análise para a melhoria do processo.
Normalmente, o ciclo completo para implementação, treinamento e implantação desse nível dura de 
6 a 18 meses, dependendo do nível inicial da organização.
4.1.5.3 CMMI – Nível 3: definido
No nível de maturidade 3, uma organização atingiu todas as metas esperadas das áreas de 
processos definidas para o nível de maturidade 2. Os processos estão descritos em padrões, 
procedimentos, ferramentas e métodos de forma detalhada e são usados para estabelecer a 
consistência em toda a organização.
Para o Nível 3, são quatorze áreas de processo, número bem superior ao do Nível 2, pois a meta 
é ter toda a organização envolvida na melhoria da qualidade, bem como garantir a manutenção do 
processo por meio do treinamento de novos funcionários, do fortalecimento da gestão de projetos, 
da preocupação com a fase de arquitetura do software, da análise de riscos do projeto e das 
atividades gerais deste e da inclusão das atividades de verificação, validação e testes que serão 
vistas no tópico 5 deste livro.
69
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
Trata‑se do nível mais complexo e detalhado do modelo CMMI, que exige muito esforço da empresa 
na sua implementação e envolvimento de todas as áreas para se obter sucesso na sua avaliação. As áreas 
de processos que compõem o Nível 3 são:
• Foco no Processo Organizacional.
• Definição do Processo Organizacional.
• Treinamento Organizacional.
• Gerência Integrada de Projetos.
• Gerência de Riscos.
• Integração de Equipes.
• Gerência de Fornecedores Integrada.
• Desenvolvimento de Requisitos.
• Solução Técnica.
• Integração de Produtos.
• Verificação.
• Validação.
• Ambiente Organizacional para Integração.
• Análise de Decisões e Resoluções.
Normalmente, o ciclo completo para implementação, treinamento e implantação desse nível dura de 
18 a 36 meses, após a organização ter obtido o Nível 2 do modelo.
4.1.5.4 CMMI – Nível 4: quantitativo
No nível de maturidade 4 a qualidade e o desempenho do processo são avaliados e gerenciados no 
que se refere a métricas quantitativas realizadas durante todo o ciclo de desenvolvimento. Para isso, cada 
área de processo deve possuir métricas de avaliação e metas definidas de acordo com as necessidades 
dos clientes, dos usuários finais, da organização e dos responsáveis pela implementação dos processos.
Nesse nível, as métricas são coletadas e analisadas de forma quantitativa para avaliar o 
desempenho de processos. As variações identificadas têm suas causas analisadas e corrigidas 
70
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade II
para evitar novas ocorrências futuras, e ações corretivas são tomadas para cada desvio da meta 
definida pelo processo.
Para que a organização seja avaliada como de Nível 4, é necessário que tenha atingido com sucesso o 
Nível 3 de maturidade. Para a obtenção do Nível 4, o esforço é estimado em 24 meses, entre a definição do 
processo, a definição das medições que serão realizadas, a coleta da medições feitas, a avaliação das métricas 
e as ações corretivas para a geração de evidências suficientes para provar a realização das atividades.
As duas áreas de processos envolvidas nesse nível são:
• Desempenho do Processo Organizacional.
• Gerência Quantitativa.
4.1.5.5 CMMI – Nível 5: otimizado
No nível de maturidade 5 o foco está na melhoria contínua do desempenho de processos mediante 
melhorias tecnológicas incrementais e inovadoras.
As causas comuns de variações de processos são tratadas e melhoram de forma mensurável os 
processos da organização. As melhorias são selecionadas com base em um entendimento quantitativo 
de sua contribuição esperada para que a organização atinja seus objetivos de aperfeiçoamento de 
processos contra seu custo e seu impacto na organização. O desempenho dos processos da organização 
é continuamente melhorado.
Trata‑se de um processo contínuo que está sempre em evolução. A empresa aprende com os seus 
erros, documenta e melhora o processo para não tornar a repeti‑los. Ao mesmo tempo, pesquisa e 
procura por inovações que proporcionem cada vez mais qualidade ao processo e ao desenvolvimento 
organizacional. Basicamente, noNível 5, são duas áreas de processo:
• Análise de Causas e Resoluções.
• Inovação e Desenvolvimento Organizacional.
O modelo CMMI é muito exigente, demorado e custoso para as organizações, mas seus benefícios 
são compensatórios a longo prazo, e esse é um diferencial reconhecido internacionalmente. Não é fácil 
de ser implementado e, principalmente, de ser mantido ao longo do tempo sem perder as características 
de suas áreas de processo. Exige forte patrocínio da alta direção para se ter o sucesso esperado e um 
treinamento forte e rigoroso para os novos funcionários no que tange a utilizar os padrões, as técnicas 
e as ferramentas estabelecidas pelos processos.
Em função do seu alto custo para pequenas e médias empresas brasileiras, o governo criou o MPS.
BR a fim de incentivar essas organizações a ter níveis de qualidade avaliados e reconhecidos, porém esse 
modelo tem apenas alcance nacional. Esse assunto é tratado no próximo capítulo.
71
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
Exemplo de aplicação
Para exemplificar a avaliação de uma área de processo para o CMMI, é necessário saber que o modelo 
utiliza o método Standard CMMI Appraisal Method for Process Improvement (Scampi) para avaliação, cujo 
objetivo é determinar o nível de aderência de um processo ao conjunto de práticas definidas pelo modelo.
A avaliação do modelo CMMI é demorada e também consiste em duas etapas: o chamado Scampi B, 
que é uma avaliação preliminar, idêntica à avaliação final, com o objetivo de detectar falhas e adequá‑las 
para a avaliação final, chamada de Scampi A. Ambas as avaliações precisam de uma empresa certificada 
e com avaliadores certificados pelo SEI. O Scampi B difere do Scampi A em relação ao número de pessoas 
envolvidas (duas para o Scampi B e quatro a nove no Scampi A) e à menor exigência de evidências das 
práticas das áreas de processo.
Para a avaliação de cada requisito de uma área de processo, utiliza a mesma classificação do 
modelo ISO/IEC 15504, ou seja, N (Não atendido), P (Parcialmente atendido), L (Largamente atendido) 
e F (Totalmente atendido). Para ser considerada em um nível de maturidade, a nota mínima de uma 
prática‑chave tem de ser L ou F, e, obrigatoriamente, a nota tem de ser F nas práticas‑chaves anteriores.
Vamos considerar a avaliação de Scampi B para uma organização que deseja a avaliação do Nível 2 
do CMMI que envolve as seguintes áreas de processo:
• Gerência de Requisitos.
• Planejamento de Projeto.
• Monitoração e Controle de Projeto.
• Garantia da Qualidade do Processo e do Produto.
• Gerência de Acordo com Fornecedores.
• Gerência de Configuração.
• Medição e Análise.
Quadro 11 – Avaliação de Scampi B para o nível 2 do CMMI
Área de processo: Gerência de Requisitos
Idt Prática‑chave PRJ1 PRJ2 PRJ3 PRJ4 Avaliação
PG1
Requisitos são gerenciados 
e inconsistências com 
o plano do projeto e 
produtos de trabalho
‑ ‑ ‑ ‑ L
72
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade II
PE1
Desenvolver o 
entendimento e o 
significado dos requisitos
‑ ‑ ‑ ‑ L
1.1 Obter um entendimento 
dos requisitos E E E E ‑
1.2 Obter compromisso sobre 
os requisitos E E E E ‑
1.3 Gerenciar mudanças nos 
requisitos N E E E ‑
1.4 Manter a rastreabilidade 
bidirecional dos requisitos N N E E ‑
1.5
Identificar inconsistências 
entre o trabalho do projeto 
e os requisitos 
E E E E ‑
Para cada área de processo, o modelo CMMI estabelece práticas‑chaves genéricas (PG) e práticas 
específicas (PE). Cada PE possui subpráticas que detalham o que deve ser feito para atingir a PE. A 
descrição detalhada de todas as práticas‑chaves e subpráticas está disponível no site do SEI/CMU. A 
avaliação abrange as PEs e as subpráticas, e o resultado acumulado é transposto para a PG. Para cada 
PE, três valores são possíveis: I (inexistente), N (não evidenciado) e E (evidenciado).
Para a execução da avaliação precisam ser selecionados os projetos que fazem parte desta e são 
propostos pela organização a ser avaliada. No exemplo utilizado, tem‑se quatro projetos (PRJ) para 
avaliação, e é exemplificada a avaliação obtida para a área de processo Gerência de Requisitos.
No exemplo, a avaliação final da área de processo é L, ou seja, largamente utilizada, que é a 
classificação mínima para a avaliação ser dada como satisfatória. Esse processo é repetido para todas as 
demais áreas de processo, e, ao término, é elaborado o relatório final sobre as melhorias que devem ser 
aplicadas para que a avaliação do Scampi A seja um sucesso.
4.2 Melhoria de Processos do Software Brasileiro (MPS.BR)
O MPS.BR foi criado em 2003 pela Associação para Promoção da Excelência do Software Brasileiro 
(Softex), subordinada ao Ministério da Ciência, Tecnologia e Inovação, com o objetivo de incentivar as 
pequenas e médias empresas brasileiras de produção de software a implantar um modelo de qualidade 
de melhoria de processo com custos mais acessíveis à realidade brasileira.
Conforme a Figura 24, o modelo está alinhado aos padrões e normas internacionais, como CMMI, 
ISO/IEC 12207, ISO/IEC 15504 e ISO/IEC 25000, mas o seu reconhecimento como selo de qualidade de 
software está limitado ao território brasileiro, sendo, inclusive, requisito básico que as organizações 
possuam a avaliação MPS.BR para fornecer software para o governo federal e muitas empresas do setor 
privado, como equivalente ao modelo CMMI.
73
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
CMMI
MPS.BR ISO 12207ISO 15504
ISO 25000
Figura 24 – Alinhamento MPS.BR com os demais modelos de qualidade
O MPS.BR ajuda as organizações a compreenderem todos os componentes envolvidos no 
desenvolvimento e na aquisição do software, bem como a executarem projetos de forma mais eficiente.
 Saiba mais
A visão geral do modelo MPS.BR e os detalhes de implementação podem 
ser consultados em: .
4.2.1 Estrutura do modelo MPS.BR
O modelo está dividido em 4 componentes, 7 níveis de maturidade e 19 processos distribuídos nos 
níveis definidos.
Os componentes são modelos de referência para desenvolvimento, aquisição e avaliação do 
processo de software, os níveis de maturidade são a classificação que as organizações recebem 
de acordo com a avaliação e os processos são as atividades que as organizações precisam praticar 
para atingir os níveis de maturidade do modelo. Os componentes dos modelos de referência são 
descritos a seguir.
• Modelo de referência para software
Contém as definições dos níveis de maturidade, processos e atributos do processo para aquisição 
e implementação, em nível de boas práticas e sugestões de implementação.
74
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade II
• Modelo de referência para serviços
Contém as definições dos níveis de maturidade, processos e atributos do processo para a prestação 
de serviços de informática. Está em conformidade com os requisitos da norma ISO/IEC 15504‑2.
• Método de avaliação
Contém os requisitos para os avaliadores‑líderes, os avaliadores‑adjuntos e as Instituições 
Avaliadoras (IAs). Está em conformidade com os requisitos da norma ISO/IEC 15504‑2.
• Modelo de negócio
Descreve as regras de negócio para implementação dos modelos de referência de software e 
de serviços pelas instituições implementadoras e para o método de avaliação pelas instituições 
avaliadoras (IA).
4.2.2 Níveis de maturidade do modelo MPS.BR
Os níveis de maturidade estabelecem um indicador de evolução da qualidade, representando estágios 
de melhoria da implementação de processos na organização. O nível de maturidade em que se encontra 
uma organização permite definir quão maduro está seu modelo de qualidade.
São sete níveis de maturidade sequenciais e dependentes entre si, representados na Figura 25:
• Nível A: otimizado.
• Nível B: gerenciado quantitativamente.• Nível C: definido.
• Nível D: largamente definido.
• Nível E: parcialmente definido.
• Nível F: gerenciado.
• Nível G: parcialmente gerenciado.
75
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
G
Parcialmente 
gerenciado
F
Gerenciado
E
Parcialmente
definido
D
Largamente definido
C
Definido
A
Otimizado
B
Gerenciado 
quantitativamente
Figura 25 – Níveis de maturidade do MPS.BR
4.2.3 Processos do modelo
Para cada nível de maturidade são definidos processos que indicam as boas práticas que precisam 
ser implementadas pela organização a fim de que atinja as metas estabelecidas para cada estágio de 
evolução. Esses processos estão ilustrados no Quadro 12.
Quadro 12 – Processos do MPS.BR por nível de maturidade
Nível de maturidade Processos
A – Otimizado • Não há processos específicos
B – Gerenciado quantitativamente • Não há processos específicos
C – Definido
• Gerência de decisões
• Gerência de riscos
• Desenvolvimento para reutilização
76
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade II
D – Largamente definido
• Desenvolvimento de requisitos
• Projeto e construção do produto
• Integração do produto
• Verificação
• Validação
E – Parcialmente definido
• Definição do processo organizacional
• Avaliação e melhoria do processo organizacional
• Gerência para reutilização
• Gerência de recursos humanos
F – Gerenciado
• Garantia da qualidade
• Gerência da configuração
• Medição
• Aquisição
• Gerência de portfólio
G – Parcialmente gerenciado
• Gerência de projetos
• Gerência de requisitos
Fonte: MPS.BR (2006).
Observa‑se no Quadro 12 que não são apresentados processos para os níveis A e B, em virtude 
de ambos serem a evolução para uma gestão quantitativa e de melhoria contínua dos processos dos 
demais níveis.
No nível B, o foco está em criar métricas e indicadores para o processo de gerência de projetos que 
permitam a correta avaliação das melhorias obtidas. No nível A, a evolução é medida a partir da análise 
de defeitos, problemas, causas comuns de variação do desempenho da implementação do processo.
O modelo permite também a exclusão de processos em determinadas situações. O processo de 
aquisição e gerência de portfólio de projetos pode ser excluído, desde que não seja executado pela 
organização. O processo de desenvolvimento para reutilização também poderá ser removido se o 
objetivo da empresa não for relacionado à execução de projetos.
4.2.4 Atributos do processo
Os atributos dos processos descrevem o que deve ser realizado em cada nível e os resultados 
esperados para evidenciar que as metas foram atingidas. São utilizados para a implementação e para a 
avaliação do processo.
O modelo MPS.BR 2012 descreve esses atributos da seguinte forma:
• Atributo 1.1 – O processo é executado
Esse atributo evidencia quanto o processo é seguido.
77
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
• Atributo 2.1 – O processo é gerenciado
Esse atributo evidencia quanto a execução do processo é gerenciada.
Algumas perguntas que permitem a avaliação desse atributo:
— A execução do processo é planejada, monitorada, e ajustes são realizados?
— As medidas são planejadas e coletadas para monitoração da execução do processo, e ajustes 
são realizados?
— As informações e os recursos necessários para a execução do processo são identificados e 
disponibilizados?
— As responsabilidades e a autoridade para executar o processo são definidas, atribuídas e comunicadas?
— A comunicação entre as partes interessadas no processo é planejada e executada de forma que 
garanta o seu envolvimento?
• Atributo 2.2 – Os produtos de trabalho do processo são gerenciados
Esse atributo evidencia quanto os produtos de trabalho produzidos pelo processo são gerenciados 
apropriadamente.
Algumas perguntas que permitem a avaliação desse atributo:
— Os requisitos dos produtos de trabalho do processo são identificados?
— Requisitos para documentação e controle dos produtos de trabalho são estabelecidos?
— Os produtos de trabalho são avaliados objetivamente com relação aos padrões, procedimentos 
e requisitos aplicáveis, e são tratadas as não conformidades?
• Atributo 3.1 – O processo é definido
Esse atributo evidencia quanto um processo‑padrão é mantido para apoiar a implementação do 
processo definido.
Algumas perguntas que permitem a avaliação desse atributo:
— Um processo‑padrão é descrito, incluindo diretrizes para sua adaptação?
— Os papéis e competências requeridos para executar o processo são identificados como parte do 
processo‑padrão?
78
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade II
— A infraestrutura e o ambiente de trabalho requerido para executar o processo são identificados 
como parte do processo‑padrão?
• Atributo 3.2 – O processo está implementado
Quanto o processo‑padrão é efetivamente implementado como um processo definido para atingir 
seus resultados.
Algumas perguntas que permitem a avaliação desse atributo:
— Um processo definido é implementado com base nas diretrizes para seleção e/ou adaptação do 
processo‑padrão?
— A infraestrutura e o ambiente de trabalho requerido para executar o processo definido são 
disponibilizados, gerenciados e mantidos?
— Dados apropriados são coletados e analisados?
• Atributo 4.1 – O processo é medido
Quanto os resultados de medição são usados para assegurar que a execução do processo atinja 
os seus objetivos.
Algumas perguntas que permitem a avaliação desse atributo:
— Os objetivos quantitativos organizacionais de qualidade e de desempenho dos processos são 
definidos para apoiar os objetivos de negócio?
— Os processos que serão objeto de análise de desempenho são selecionados a partir do conjunto 
de processos‑padrão da organização e das necessidades de informação dos usuários dos 
processos?
— Medidas, bem como a frequência de realização de suas medições, são identificadas e definidas 
de acordo com os objetivos de medição do processo e os objetivos quantitativos de qualidade 
e de desempenho do processo?
— Os resultados das medições são coletados e analisados, utilizando técnicas estatísticas e outras 
técnicas quantitativas apropriadas, e são comunicados para monitorar o alcance dos objetivos 
quantitativos de qualidade e de desempenho do processo/subprocesso?
— Os resultados de medição são utilizados para caracterizar o desempenho do processo?
79
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
• Atributo 4.2 – O processo é controlado
Quanto o processo é controlado estatisticamente para permanecer estável, capaz e previsível, 
dentro de limites estabelecidos.
Algumas perguntas que permitem a avaliação desse atributo:
— Limites de controle de variação são estabelecidos para o desempenho normal do processo?
— Dados de medição são analisados com relação a causas especiais de variação?
— Ações corretivas e preventivas são realizadas para tratar causas especiais, ou de outros tipos, de 
variação?
• Atributo 5.1 – O processo é objeto de melhorias e inovações
Esse atributo evidencia quanto as mudanças no processo são identificadas a partir da análise de 
defeitos, problemas, causas comuns de variação do desempenho e da investigação de enfoques 
inovadores para a definição e a implementação do processo.
Algumas perguntas que permitem a avaliação desse atributo:
— Os objetivos de melhoria do processo são definidos com base no entendimento do desempenho 
do processo, de forma que verifique que os objetivos de negócio relevantes são atingíveis?
— Dados que influenciam o desempenho do processo são identificados, classificados e selecionados 
para análise de causas?
— Dados selecionados são analisados para identificar causas‑raiz e propor soluções aceitáveis 
para evitar ocorrências futuras dedo modelo CMMI ..................................................................................................... 63
4.1.4 Representação contínua ...................................................................................................................... 63
4.1.5 Representação por estágio ................................................................................................................. 65
4.2 Melhoria de Processos do Software Brasileiro (MPS.BR) ..................................................... 72
4.2.1 Estrutura do modelo MPS.BR ............................................................................................................ 73
4.2.2 Níveis de maturidade do modelo MPS.BR .................................................................................... 74
4.2.3 Processos do modelo ............................................................................................................................. 75
4.2.4 Atributos do processo ........................................................................................................................... 76
4.2.5 Comparativo do nível de maturidade entre o MPS.BR e o CMMI ...................................... 80
Unidade III
5 VERIFICAÇÃO E VALIDAÇÃO DE SOFTWARE ......................................................................................... 89
5.1 Definições de verificação e validação .......................................................................................... 89
5.1.1 Verificação ................................................................................................................................................. 90
5.1.2 Validação .................................................................................................................................................... 91
5.1.3 Técnicas de V&V...................................................................................................................................... 91
5.2 Revisões técnicas .................................................................................................................................. 92
5.2.1 O processo de revisão ............................................................................................................................ 93
5.2.2 Diretrizes básicas de uma RTF ............................................................................................................ 94
5.3 Passeio (walkthrough) ........................................................................................................................ 94
5.3.1 O processo de walkthrough ................................................................................................................ 95
5.3.2 Diretrizes básicas de um walkthrough ......................................................................................... 96
5.3.3 Revisões progressivas por pares ........................................................................................................ 96
5.4 Técnica de inspeção ............................................................................................................................. 96
5.4.1 Processo de inspeção ............................................................................................................................ 97
5.4.2 Papéis e responsabilidades .................................................................................................................. 99
5.4.3 Checklist de uma inspeção ...............................................................................................................100
5.5 Sala limpa (clean room) ...................................................................................................................101
5.5.1 Processo sala limpa ..............................................................................................................................101
5.5.2 Testes estatísticos .................................................................................................................................102
5.5.3 Certificação de qualidade ..................................................................................................................103
6 TESTES DE SOFTWARE..................................................................................................................................103
6.1 Fundamentos sobre testes de software.....................................................................................104
6.1.1 Conceitos de testes de software .....................................................................................................104
6.1.2 Conceituação de defeito, erro e falha ..........................................................................................105
6.1.3 Por que devemos testar um software? ........................................................................................107
6.2 Ciclo de vida de testes ......................................................................................................................107
6.2.1 O Modelo V ..............................................................................................................................................108
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
6.2.2 Testes na fase de manutenção do sistema ..................................................................................111
6.3 Tipos de testes .....................................................................................................................................112
6.3.1 Amplitude dos tipos de testes .........................................................................................................112
6.4 Técnicas de testes ...............................................................................................................................114
6.4.1 Técnica de testes funcionais ou caixa‑preta ............................................................................. 115
6.4.2 Técnicas de teste estrutural ou caixa‑branca ........................................................................... 115
6.4.3 Técnica de teste funcional ou caixa‑preta .................................................................................121
6.5 Testes em processos ágeis ...............................................................................................................128
6.5.1 Testes ágeis ............................................................................................................................................. 130
6.5.2 Roteiro de testes ágeis .......................................................................................................................131
6.5.3 Processo de testes ágeis .....................................................................................................................131
6.5.4 Conceitos sobre Test Driven Development (TDD) ................................................................... 134
6.5.5 Quando terminar os testes? ............................................................................................................ 135
Unidade IV
7 MANUTENÇÃO DE SOFTWARE .................................................................................................................141
7.1 Definição de manutenção de software .....................................................................................141
7.1.1 Conceituação sobre manutenção de software ........................................................................ 142
7.1.2 Tipos de manutenção ......................................................................................................................... 143
7.2 Técnicas e padrões de manutenção de software ..................................................................145
7.2.1 As atividades de manutenção.........................................................................................................resultados similares, ou incorporar melhores práticas ao 
processo?
— Oportunidades de melhoria derivadas de novas tecnologias e conceitos de processo são 
identificadas, avaliadas e selecionadas com base no impacto no alcance dos objetivos de 
negócio?
• Atributo 5.2 – O processo é otimizado continuamente
Esse atributo evidencia quanto as mudanças na definição, na gerência e no desempenho do 
processo têm impacto efetivo para o alcance dos objetivos relevantes de melhoria do processo.
Algumas perguntas que permitem a avaliação desse atributo:
80
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade II
— A implementação de todas as mudanças acordadas é gerenciada para assegurar que qualquer 
alteração no desempenho do processo seja entendida e que sejam realizadas as ações 
pertinentes?
— As ações implementadas para resolução de problemas e melhoria no processo são acompanhadas, 
com uso de técnicas estatísticas e outras técnicas quantitativas, para verificar se as mudanças 
no processo corrigiram o problema e melhoraram o seu desempenho?
— Dados da análise de causas e de resolução são armazenados para uso em situações similares?
A implementação desses atributos obedece a uma relação preestabelecida com os níveis de 
maturidade do modelo, conforme o Quadro 13.
Quadro 13 – Processos do MPS.BR por nível de maturidade
Nível de maturidade Atributos do processo
G 1.1 e 2.1
F 1.1, 2.1 e 2.2
E 1.1, 2.1, 2.2, 3.1 e 3.2
D 1.1, 2.1, 2.2, 3.1 e 3.2
C 1.1, 2.1, 2.2, 3.1 e 3.2
B 1.1, 2.1, 2.2, 3.1, 3.2, 4.1 e 4.2
A 1.1, 2.1, 2.2, 3.1, 3.2, 4.1, 4.2, 5.1 e 5.2
Fonte: MPS.BR (2006).
Os atributos de processo 4.1, 4.2, 5.1 e 5.2 devem ser implementados somente para os processos 
críticos da organização, identificados e selecionados antes do processo de avaliação, quando são 
selecionados para análise de desempenho, e para cada um deles são criadas as métricas e os indicadores 
que permitem a melhoria contínua dos atributos de processo.
4.2.5 Comparativo do nível de maturidade entre o MPS.BR e o CMMI
Como o modelo MPS.BR é baseado no modelo CMMI, existem muitas semelhanças entre ambos. 
A diferença mais relevante está no número de níveis de maturidade – que no CMMI são cinco, e no 
MPS.BR são 7 –, porém sem equivalência ao Nível 1 inicial do CMMI. Essa relação entre os níveis está 
representada na Figura 26.
81
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
 CMMI Nível 1
 CMMI Nível 4
 CMMI Nível 5
 CMMI Nível 2
 CMMI Nível 3
• Não há relação no MPS.BR
• MPS.BR nível B
• MPS.BR nível A
• MPS.BR nível G
• MPS.BR nível F
• MPS.BR nível E
• MPS.BR nível D
• MPS.BR nível C
Figura 26 – Comparativo de níveis de maturidade entre MPS.BR e CMMI
No comparativo entre os dois modelos, pode‑se destacar que o MPS.BR não possui as áreas de 
processo Análise de Causas e Resolução, do Nível 5 do CMMI, e Desempenho do Processo Organizacional, 
do Nível 4 do CMMI.
No MPS.BR, esses dois processos são atendidos por meio dos atributos de processo de números 4.1, 
4.2, 5.1 e 5.2. Nesse modelo, existem duas áreas que não são atendidas pelo modelo CMMI: Gestão de 
Portfólio e Desenvolvimento para Reutilização.
Além disso, é denominado de forma diferente o processo do CMMI de Treinamento, chamado de 
Gestão de Recursos Humanos no MPS.BR. O processo de Gestão de Projetos do CMMI é agrupado 
em uma única área de processo no MPS.BR, e a área de Solução Técnica é denominada de Projeto e 
Construção no MPS.BR. Em todas essas áreas, não há diferenças relevantes na implementação, e todas 
se mantêm no mesmo nível de maturidade.
Exemplo de aplicação
Para realizar a avaliação do modelo MPS.BR, é utilizada a mesma classificação do modelo ISO/IEC 
15504, ou seja, N (não atendido), P (parcialmente atendido), L (largamente atendido) e F (totalmente 
atendido). A nota mínima tem de ser L ou F. Também é necessário que a avaliação seja realizada por uma 
empresa certificada e com avaliadores certificados pela Softex.
No exemplo de aplicação é considerado que uma organização deseja ser avaliada no nível G do MPS.BR. 
O nível G é dito parcialmente gerenciado e é composto pelos processos de gerência de projetos e gerência 
82
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade II
de requisitos. Neste nível, a implementação dos processos deve satisfazer os atributos de processo 1.1 
e 2.1, como visto no Quadro 13.
O processo de gerência de projetos envolve atividades e recursos necessários para planejar e controlar 
o projeto, permitindo realizar ações para corrigir os desvios encontrados.
O processo de gerência de requisitos envolve atividades para identificar, controlar e aprovar os 
requisitos dos produtos do projeto.
Uma vez definida a equipe de avaliação e estabelecido o nível de maturidade que a organização 
deseja atingir, devem ser selecionados os projetos que vão participar da avaliação. Para cada processo 
existe um conjunto de práticas que são os resultados esperados para cada uma delas.
Como resultado da avaliação do processo de gerência de projeto no exemplo, temos:
Quadro 14
Processo: Gerência de Projetos L
Idt Prática‑chave PRJ1 PRJ2 PRJ3 PRJ4 Avaliação
1 O escopo do trabalho para o 
projeto é definido E E E E F
2
As tarefas e os produtos 
de trabalho do projeto são 
dimensionados utilizando 
métodos apropriados
E E E E F
3 O modelo e as fases do ciclo de 
vida do projeto são definidos E E E E F
4
O esforço e o custo para a 
execução das tarefas são 
estimados com base em dados 
históricos 
E E E E F
5
O orçamento e o cronograma 
do projeto, incluindo a 
definição de marcos e pontos 
de controle, são estabelecidos e 
mantidos 
N E E E L
6
Os riscos do projeto são 
identificados e o seu impacto, 
a sua probabilidade de 
ocorrência e a sua prioridade de 
tratamento são determinados e 
documentados 
N N E E L
7
Os recursos humanos para 
o projeto são planejados 
considerando o perfil e o 
conhecimento 
E E E E F
8
Os recursos e o ambiente 
de trabalho necessário 
para executar o projeto são 
planejados 
E E E E F
83
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
9 É estabelecido um processo de 
gerência da configuração E E E E F
10
A viabilidade de atingir 
as metas do projeto é 
explicitamente avaliada 
considerando as restrições 
E E E E F
11
O plano do projeto é revisado 
com todos os envolvidos e o 
compromisso é obtido 
E E E E F
12
O escopo, as tarefas, as 
estimativas, o orçamento e o 
cronograma do projeto são 
atingidos
N N E E L
13
Os recursos materiais e 
humanos, bem como os dados 
relevantes do projeto, são 
monitorados
E E E E F
14 Os riscos são monitorados em 
relação ao planejado N N E E L
15
O envolvimento das partes 
interessadas no projeto é 
planejado, monitorado e 
mantido 
N N E E L
16
Revisões são realizadas em 
marcos do projeto e conforme 
estabelecido no planejamento 
E E E E F
17
Registros de problemas 
identificados e o resultado da 
análise são tratados com as 
partes envolvidas 
N N E E L
18
Ações para corrigir desvios 
em relação ao planejado 
são implementadas e 
acompanhadas 
N N E E L
O resultado da avaliação do processo de gerência de requisitos é exposto a seguir.
Quadro 15 – Resultado da avaliação
Processo: Gerência de Requisitos F
Idt Prática‑chave PRJ1 PRJ2 PRJ3 PRJ4 Avaliação
1
O entendimento dos 
requisitos é obtido junto 
aos fornecedores de 
requisitos 
E E E E F
2
Os requisitos são 
avaliados com base em 
critérios objetivos, e um 
comprometimento da 
equipe técnica com esses 
requisitos é obtido 
E E E E F
84
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade II
3
A rastreabilidade 
bidirecional entre os 
requisitos e os produtos 
de trabalho é estabelecida 
e mantida 
E E E E F
4
Revisões em planose 
produtos de trabalho do 
projeto são realizadas 
visando identificar e 
corrigir inconsistências em 
relação aos requisitos 
E E E E F
5
Mudanças nos requisitos 
são gerenciadas ao longo 
do projeto 
E E E E F
No exemplo, a avaliação final da área de Processo de Gestão de Projetos é L e a de Gestão de 
Requisitos é F, ou seja, largamente utilizado e totalmente utilizado, respectivamente, o que estabelece 
a classificação de avaliação satisfatória para o nível G. Porém, para mudar para o nível F, a organização 
tem de estar com classificação F em todas as áreas do nível anterior, portanto precisa melhorar a área 
de gestão de projetos.
 Resumo
Nesta unidade foram apresentados os principais modelos da qualidade 
em uso no mercado para a implementação da melhoria de processos nas 
organizações. Essas normas têm como objetivo minimizar os problemas de 
qualidade das empresas quando da produção de um software, buscando 
fortalecer a atuação de todos os envolvidos na prevenção de problemas no 
software e satisfazer as necessidades dos usuários.
Abordamos que, uma vez definidas as principais características de 
qualidade de um produto de software, é necessário que uma organização 
esteja com os processos de desenvolvimento bem‑definidos, chamados de 
modelos de qualidade, cuja preocupação está em estabelecer, medir e avaliar 
a capacidade de realização de um projeto de software pelas organizações 
com qualidade, mediante processos que medem o grau de maturidade da 
empresa em desenvolver sistemas.
Vimos também que, no final dos anos 1990, a ISO/IEC 15504 – Spice – 
apresentou diversos conceitos sobre a melhoria do processo de software, 
definindo um conjunto de boas práticas de Engenharia de Software, gestão 
de projetos, qualidade, apoio e suporte que uma empresa deve aplicar para 
atingir a excelência na produção de uma aplicação.
85
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
A seguir, aprendemos que, de acordo com o estágio em que essas práticas 
são aplicadas, o modelo atribui um grau de capacidade à organização, que 
pode, por meio desses indicadores, traçar um plano de evolução de melhoria 
da qualidade. Esses estágios são classificados do Nível 0 até o Nível 5 de 
capacidade da empresa no processo de melhoria de software. No Nível 0, 
o processo é praticamente inexistente, ou geralmente falha; no Nível 1, 
os objetivos são atingidos, mas sem controle apropriado; no Nível 2, os 
objetivos são atingidos, mas com controle adequado; no Nível 3, o processo 
se encontra estabelecido; no Nível 4, o processo é totalmente controlado 
pela utilização de métricas; e o Nível 5 é a melhoria contínua do processo 
de forma disciplinada.
Vimos que cada nível de maturidade possui características básicas 
para avaliação de uma organização, que, por sua vez, tem um conjunto 
de atributos específicos que permitem medir a evolução da capacidade de 
cada atributo, com o objetivo de determinar se as condições mínimas para 
atingir o nível desejado foram alcançadas. Para que o processo possa fazer 
a avaliação de cada nível com base nessas características, são descritos 
atributos que permitem avaliá‑las de forma quantitativa.
Logo depois, abordamos o modelo CMMI, publicado no início dos anos 
2000 pelo SEI/CMU, que é o modelo de qualidade mais reconhecido e 
utilizado no mercado de Tecnologia da Informação em âmbito internacional. 
Também apresenta avaliação em níveis de capacidade na representação 
continuada e alinhada à norma ISO/IEC 15504.
Vimos que o CMMI é estruturado em níveis de um a cinco que 
representam o grau de maturidade da empresa no processo de software. 
Essa divisão o difere do modelo Spice, que tem níveis de zero a cinco. Cada 
nível de maturidade possui um conjunto de boas práticas, denominadas 
Áreas de Processo (APs), que precisam ser executadas durante o processo 
de desenvolvimento de software. Os níveis de maturidade podem ser 
representados de duas formas: contínua ou estagiada. A representação 
contínua permite que a organização evolua individualmente nas práticas 
preconizadas no processo de desenvolvimento, por exemplo, em gestão 
de requisitos, planejamento de projetos, dentre outras. A representação 
por estágio é mais utilizada e reconhecida no mercado de Tecnologia da 
Informação e exige a evolução conjunta das práticas do modelo.
Abordamos ainda que o CMMI é um modelo de implementação 
demorada e de alto custo financeiro, porém essencial para as 
organizações que desejam fornecer serviços de desenvolvimento de 
software para o exterior.
86
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade II
Vimos o modelo de qualidade MPS.BR, elaborado com base nas normas 
ISO/IEC 12207, ISO/IEC 15504, ISO/IEC 25000 e no modelo CMMI, publicado 
e utilizado no Brasil para atender às necessidades de um modelo mais 
acessível, em termos financeiros, às pequenas e médias empresas que 
produzem software no Brasil. Da mesma forma que os modelos anteriores, 
apresenta a evolução da maturidade da organização dividida em níveis, o que 
permite definir quão maduro está o modelo de qualidade na organização. 
São sete os níveis de maturidade, do nível A até o nível G, que devem ser 
implantados e avaliados de maneira sequencial, pois são dependentes entre 
si. O maior número de níveis permite às organizações evoluírem de forma 
mais lenta e consistente em maturidade do modelo, reduzindo seus custos 
de implantação do processo.
Abordamos ainda que o menor nível do MPS.BR é o G, dito parcialmente 
gerenciado, cujo foco está na gestão de requisitos e na gestão de projetos. 
No Nível F, dito gerenciado, as demais práticas de configuração, qualidade 
e medição são incluídas. No Nível E, parcialmente definido, começa a 
expansão da maturidade para a organização, e não somente no projeto. 
No Nível D, o processo é considerado largamente definido. No Nível C, é 
considerado definido. No Nível B, encontra‑se estabelecido um processo 
de medição para evolução da qualidade. O Nível A refere‑se à melhoria 
contínua do processo. Estabelecendo uma relação com o modelo do CMMI, 
o MPS.BR tem o Nível A equivalente ao Nível 5, o Nível B equivale ao Nível 
4, os Níveis C, D e E formam o Nível 3 do CMMI e os Níveis F e G equivalem 
ao Nível 2 do modelo internacional.
Finalmente, aprendemos que o MPS.BR é um modelo de implementação 
mais rápida e de custos mais baixos, porém tem seu reconhecimento limitado 
ao mercado brasileiro, em que é exigido para a prestação de serviços de 
desenvolvimento de software para o setor público e para algumas empresas 
do setor privado.
 Exercícios
Questão 1. Os modelos de qualidade voltados para a avaliação do processo de desenvolvimento 
auxiliam as empresas a construírem uma estrutura adequada e robusta para a produção do software, 
orientando como essas empresas podem evoluir e atingir graus de maturidade cada vez mais elevados. 
Um dos modelos citados a seguir se apresenta como o maior influenciador em gestão de processos de 
software. Qual seria esse modelo?
A) Modelo CMMI.
B) Modelo MPS‑Br.
87
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
C) Modelo ISO/IEC 15504‑2.
D) Modelo ISO/IEC 15504‑1.
E) Modelo ISO 9000.
Resposta correta: alternativa A.
Análise das alternativas
A) Alternativa correta.
Justificativa: o modelo CMMI é um modelo maduro de desenvolvimento de software, serve como 
referência para novos padrões e é adotado em todo o mundo. A utilização do CMMI traz um processo de 
desenvolvimento padronizado com alta qualidade, permitindo a utilização de indicadores de aumento 
de produtividade e satisfação do cliente.
B) Alternativa incorreta.
Justificativa: o modelo é restrito ao cenário brasileiro.
C) Alternativa incorreta.
Justificativa: não é um modelo, e sim uma parte normativa que corresponde à norma 15504. Nessa 
parte normativa descreve‑se o processo para arealização da capacidade de organização.
D) Alternativa incorreta.
Justificativa: não é um modelo, e sim uma parte informativa que corresponde à norma 15504. 
Nessa parte informativa descreve‑se uma série de conceitos que servem como guia na descrição dos 
procedimentos da norma.
E) Alternativa incorreta.
Justificativa: ISO 9000 não é um modelo, e sim um conjunto de normas de qualidade.
Questão 2. Os modelos de qualidade voltados para a avaliação do processo de desenvolvimento 
auxiliam as empresas a construírem uma estrutura adequada e robusta para a produção do software, 
orientando como essas empresas podem evoluir e atingir graus de maturidade cada vez mais elevados. A 
norma MPS.BR para melhoria de processos de software brasileiro ajuda as organizações a compreenderem 
todos os componentes envolvidos no desenvolvimento e aquisição do software, bem como a executarem 
projetos de forma mais eficiente. Considere as afirmativas a seguir acerca dos quatro componentes nos 
quais está dividida a estrutura do modelo MPS.BR. 
88
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade II
I – Contém as definições dos níveis de maturidade, processos e atributos do processo para aquisição 
e implementação, em nível de boas práticas e sugestões de implementação.
II – Contém as definições dos níveis de maturidade, processos e atributos do processo para a 
prestação de serviços de informática. Está em conformidade com os requisitos da norma ISO/IEC 15504‑
2.
III – Descreve as regras de negócio para implementação dos modelos de referência de software e de 
serviços pelas Instituições Implementadoras e para o método de avaliação pelas Instituições Avaliadoras 
(IAs).
IV – Estabelecem um indicador de evolução da qualidade, representando estágios de melhoria da 
implementação de processos na organização. O nível de maturidade em que se encontra uma organização 
permite definir o quão maduro está seu modelo de qualidade.
V – Contém os requisitos para os avaliadores líderes, avaliadores adjuntos e Instituições Avaliadoras 
(IAs). Está em conformidade com os requisitos da norma ISO/IEC 15504‑2.
É correto apenas o que se destaca em: 
A) I, II, III, V.
B) I, II, III.
C) II, III, IV.
D) IV.
E) I, II.
Resposta desta questão na plataforma.
89
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
Unidade III
5 VERIFICAÇÃO E VALIDAÇÃO DE SOFTWARE
5.1 Definições de verificação e validação
As técnicas de verificação e validação são essenciais para o processo de qualidade no desenvolvimento 
de software e são chamadas popularmente de técnicas de V&V. Existem diversas técnicas que serão 
apresentadas nos próximos capítulos descrevendo as várias formas de garantia e controle de qualidade 
dos produtos de construção da aplicação. Porém, antes de detalhar essas técnicas, são descritas algumas 
definições básicas de qualidade.
Como já visto, a garantia da qualidade é executada durante a construção do produto, e o controle 
da qualidade, após o produto ter sido construído.
As técnicas de V&V abrangem ambos os cenários, por meio de:
• aplicação de ferramentas que podem automatizar a revisão de determinados produtos; por 
exemplo, a simples revisão ortográfica do editor de texto é uma ferramenta automatizada de 
garantia da qualidade;
• utilização do processo de revisão de artefatos, como revisão por pares;
• adoção de normas e padrões, como um padrão de melhores práticas de codificação;
• controle sistemático e formal das mudanças de requisitos que podem ocorrer durante o ciclo de 
construção; por exemplo, a inclusão de uma nova funcionalidade no software deve ser avaliada e 
aprovada pelo cliente antes da sua incorporação ao projeto;
• manutenção de registros de todas as alterações realizadas nos artefatos, identificados, no mínimo, 
com o nome, a data da alteração e o motivo da alteração;
• o mais importante, que é o processo de medição para avaliar se a qualidade está se mantendo, 
melhorando ou piorando.
Uma das principais finalidades da V&V é garantir que o produto seja construído corretamente, ou seja, 
atuar de forma preventiva para que os esforços de correção de problemas causem o menor impacto possível.
Há diversas questões relacionadas à garantia da qualidade de que todo esse processo preventivo é 
muito caro, e não compensaria financeiramente a uma empresa de desenvolvimento de software aplicar 
90
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade III
tudo o que deveria. No entanto, essa equação não é difícil de resolver. Basta analisarmos se os custos 
para realizar as ações de garantia da qualidade (GQ1), somados aos custos para corrigir problemas não 
identificados pelo processo de garantia da qualidade (GQ2), são menores que os custos para corrigir os 
problemas em um cenário sem nenhuma ação de qualidade (NGQ).
GQ1 + GQ2e técnicas dinâmicas.
As técnicas estáticas são aquelas realizadas, de forma manual ou automática, sobre os artefatos 
de documentação e modelagem do sistema e não necessitam da execução do software. Por exemplo:
• avaliação de diagramas de casos de uso;
• avaliação de diagramas de classes;
• avaliação do modelo de dados;
• inspeções de código‑fonte.
92
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade III
As técnicas dinâmicas são aquelas realizadas, de forma manual ou automática, sobre o software 
construído e que necessitam de sua execução, por exemplo:
• execução de simulação;
• realização de testes.
Nos próximos tópicos são detalhadas as principais técnicas de verificação e de validação.
Requisitos do usuário
Especificação
Documento 
de projeto 
preliminar
Documento 
de projeto 
detalhado Código
Análise
...
Projeto 
preliminar Projeto 
detalhado
Codificação
Figura 28 – Atividades de validação da qualidade
5.2 Revisões técnicas
Segundo o SEI‑CMMI (2003), o processo de revisão é uma avaliação crítica de todos os artefatos 
produzidos durante o desenvolvimento de um software, não apenas sobre o código‑fonte, em pontos 
predefinidos do ciclo de vida com o objetivo de encontrar e corrigir eventuais erros inseridos durante o 
processo. O fato de encontrar esses erros mais cedo proporciona uma redução de custos no processo de 
desenvolvimento.
Pressman (2006, p. 585) destaca uma série de benefícios à qualidade do software que podem ser 
alcançados com a utilização do processo de revisão:
• verificação se o produto de trabalho está em conformidade com os padrões, as especificações e os 
requisitos definidos;
• identificação de melhorias necessárias em um produto de trabalho;
• documentação e geração de histórico de erros;
• consenso entre cliente e equipe sobre os produtos de trabalho;
93
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
• aumento do conhecimento da equipe;
• “via” gerencial para, formalmente, completar uma tarefa.
As revisões técnicas são atividades de garantia da qualidade realizadas durante o processo de 
desenvolvimento e são uma forma de envolver outros membros da equipe e/ou externos a esta, com 
o objetivo de chegar ao consenso de que o produto de software está de acordo com as expectativas. A 
partir da revisão, podem ser identificados desvios em relação ao padrão definido e realizadas correções 
e melhorias no produto.
O objetivo principal da revisão não é encontrar erros, mas sim permitir o alinhamento de conhecimento 
entre os envolvidos no processo e o atendimento às expectativas do cliente.
Uma revisão técnica pode ter características informais ou formais, dependendo das necessidades e/ou 
dos objetivos que se deseja atingir. São apresentadas neste tópico as características de uma Revisão 
Técnica Formal (RTF).
5.2.1 O processo de revisão
O processo de RTF, ilustrado na Figura 29, deve ser estruturado, conduzido em uma reunião e será 
tão bem‑sucedido quanto for planejado e controlado. Deve ser realizado sobre artefatos que tratem de 
assunto único ou correlato para permitir melhor avaliação e aumentar as probabilidades de sucesso.
Revisão
Preparação
• Definir equipe
• Definir artefato • Revisar artefato 
por partes
• Artefato revisado
• Registro histórico
Conclusão
Figura 29 – O processo de revisão técnica
Para a obtenção de melhores resultados durante uma sessão de RTF, os seguintes procedimentos 
devem ser observados, mas não se limitando a estes:
• a equipe de revisão deve ter de três a cinco pessoas internas e externas ao projeto;
• a equipe deve ser convidada e informada sobre o objetivo da revisão;
• o artefato a ser revisado deve ser enviado com antecedência para que todos leiam previamente;
• ter um checklist (lista de verificação) preparado;
94
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade III
• os papéis devem estar claramente definidos: moderador, autor e revisores;
• iniciar pela leitura do documento pelo autor, de acordo com a estrutura do documento;
• a cada parte do documento, a equipe de revisores faz os comentários;
• o líder faz a mediação em eventuais conflitos e discordâncias;
• todos os comentários devem ser registrados para histórico.
A reunião deve ter, no máximo, a duração de 2 horas.
5.2.2 Diretrizes básicas de uma RTF
Pressman (2006, p. 586) apresenta ainda um conjunto de diretrizes mínimas a serem seguidas 
durante uma RTF:
• fixe e mantenha uma agenda com os participantes;
• revise o produto, não o autor do artefato;
• faça anotações por escrito;
• enuncie os problemas, mas não tente resolver cada um deles;
• limite o debate;
• realize um treinamento sobre revisões para todos os revisores;
• reveja suas antigas revisões.
As revisões técnicas formais são procedimentos relativamente simples que produzem resultados 
significativos na garantia da qualidade de um produto de software. Planeje e utilize sempre a técnica 
de RTF.
5.3 Passeio (walkthrough)
Os walkthroughs são revisões técnicas informais de um artefato de software visando à garantia da 
qualidade. Normalmente são chamados de revisão por pares, mas podem ter até três participantes: 
autor, revisor e moderador. O revisor pode ser um técnico, um cliente ou uma pessoa externa ao projeto 
que domine o assunto em revisão. O moderador, preferencialmente, não deve ser do mesmo nível 
hierárquico do autor e do revisor.
95
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
Os passeios são bem mais simples que as RTFs, e seu alto grau de informalidade torna esta técnica 
muito aceita pela maioria das equipes de projeto e uma prática recomendada pelos métodos ágeis de 
desenvolvimento. Apoia a recomendação da qualidade a qual determina que tudo deve ser revisado 
antes de ser entregue ao cliente.
 Saiba mais
Métodos ágeis são processos de desenvolvimento que se caracterizam 
pela velocidade e pela simplicidade da construção de um software. Veja 
mais detalhes em: .
5.3.1 O processo de walkthrough
Por se tratar de reuniões informais para avaliação dos produtos, o processo é extremamente simples 
e não envolve agendamento, preparação ou planejamento. A Figura 30 ilustra esse processo.
Autor Revisor Artefato 
revisado+ =
Figura 30 – O processo de walkthrough
Possui basicamente as seguintes características:
• pouca ou nenhuma preparação requerida;
• objetivo de comunicar ou receber aprovação do artefato;
• papéis específicos não são estabelecidos;
• o autor guia os presentes pelo artefato;
• o revisor lê o documento e faz suas considerações;
• o autor nunca pode ser o leitor.
 Observação
Os walkthroughs são muito úteis, principalmente, para revisar artefatos 
de requisitos e de modelagem do software, como especificações de casos 
de uso, diagramas de classes, dentre outros.
96
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade III
5.3.2 Diretrizes básicas de um walkthrough
Algumas recomendações importantes que devem ser observadas e obedecidas durante uma sessão 
de walkthrough são apresentadas a seguir:
• o autor seleciona os revisores e convida‑os para a reunião;
• o autor entrega o artefato aos revisores na reunião;
• o foco deve ser o artefato, e não o autor;
• o autor deve apresentar o artefato durante a reunião;
• os revisores apresentam possíveis falhas, comentários e sugestões de melhoria;
• com base nas informações apresentadas, o autor faz as devidas correções.
5.3.3 Revisões progressivas por pares
As revisões progressivas por pares constituem uma variação do walkthrough e apresentam 
características deste e da RTF. Basicamente, o artefato é dividido em partes e distribuído aos revisores. O 
seguinte procedimento deve ser cumprido:
• o artefato deve ser separado, e suas partes, distribuídasaleatoriamente para os revisores (por 
exemplo, numa revisão de código, cada revisor pode ficar com um trecho de código);
• no procedimento de revisão, cada revisor faz a leitura do artefato, como em um walkthrough;
• todos os revisores fazem suas considerações, que são registradas;
• ao término de cada trecho revisado, o revisor passa a vez para o próximo, e assim sucessivamente, 
até que todo o material seja revisado;
• se possível, o autor já faz as alterações sugeridas para verificar a eficácia destas.
5.4 Técnica de inspeção
Trata‑se de uma técnica de verificação extremamente formal, em que os envolvidos examinam 
os artefatos produzidos contra uma especificação inicial com o objetivo de encontrar incoerências, 
inconsistências e erros.
As inspeções podem ser realizadas a qualquer momento dentro do ciclo de vida de um produto de 
software (análise, projeto, codificação e testes), não necessitando da execução do sistema para serem 
feitas. São efetivas para encontrar, documentar e corrigir erros em qualquer artefato produzido, pois 
97
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
devem envolver pessoas com conhecimento e domínio do assunto que está sendo inspecionado e possuir 
um checklist dos pontos que devem ser verificados no artefato.
Em um processo de inspeção, qualquer produto resultado do trabalho de desenvolvimento pode ser 
analisado, mas não se limitando a estes:
• documento de requisitos;
• especificação de casos de uso;
• diagrama de classes;
• protótipo de telas;
• especificações de telas;
• diagrama de arquitetura do sistema;
• modelo de dados;
• especificação de projeto;
• código‑fonte;
• casos de testes;
• roteiro de testes;
• plano de implantação.
5.4.1 Processo de inspeção
Segundo Pressman (2006), um processo de inspeção é composto de seis etapas, conforme ilustrado 
na Figura 31 e detalhado a seguir:
Planejamento
Apresentação Reunião de 
inspeção
Revisão
Preparação Correção
Figura 31 – O processo de inspeção
98
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade III
5.4.1.1 Planejamento
Fase inicial que compreende a previsão da inspeção dos artefatos no cronograma do processo de 
desenvolvimento de software, sem o qual a formalidade prevista não será atendida.
A seguir, o artefato a ser revisado, bem como todos os documentos de referência para a reunião de 
inspeção, são reunidos e apresentados, para que a equipe de inspeção seja dimensionada e o número de 
reuniões seja definido.
Os artefatos e demais subsídios são distribuídos à equipe de inspeção.
5.4.1.2 Apresentação
Trata‑se de uma etapa opcional diretamente ligada ao tamanho e à complexidade do artefato a ser 
inspecionado.
No caso de ocorrer, a equipe de inspeção é reunida, e o autor faz uma explicação sobre os pontos 
principais do artefato.
5.4.1.3 Preparação
Os inspetores devem fazer a leitura prévia de toda a documentação distribuída dentro do tempo 
planejado e fazer suas anotações de correções necessárias e eventuais melhorias identificadas. Devem ser 
treinados e capacitados no processo de inspeção e ter domínio do assunto a que o artefato inspecionado 
se refere.
5.4.1.4 Inspeção
Consiste na reunião propriamente dita. O leitor faz a apresentação do artefato por partes, para 
que os inspetores façam os questionamentos, que são respondidos pelos autores, e os apontamentos 
de correção, que são registrados pelo escritor. Os apontamentos devem ser classificados quanto a sua 
gravidade. O processo se repete até que todo o artefato seja inspecionado.
Ao final, a equipe faz as considerações de melhoria e decide se o artefato será aceito, aceito com 
ressalvas ou se necessita de nova inspeção.
5.4.1.5 Correção
As correções e melhorias apontadas durante a sessão de inspeção devem ser feitas pelos autores e 
registradas as respectivas soluções.
5.4.1.6 Revisão
Os autores fazem a apresentação das soluções aplicadas aos apontamentos, e o moderador deve dar 
o aceite a cada item registrado e determinar a situação final da inspeção. O coordenador de inspeções 
recebe o documento final da inspeção.
99
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
5.4.2 Papéis e responsabilidades
Por se tratar de um processo formal, uma inspeção define claramente quem são os integrantes da 
inspeção e quais são as responsabilidades de cada um deles, com o objetivo de melhorar a comunicação 
e evitar conflitos durante a sessão. A sessão deve, obrigatoriamente, envolver um usuário final do 
artefato inspecionado.
Autor Inspetor Leitor Escritor
Moderador
Coordenador
Figura 32 – Papéis em uma inspeção
Segundo Pressman (2006), os papéis mais comuns em uma sessão de inspeção, conforme a Figura 
32, são:
• Coordenador das inspeções: é o responsável pelo registro de toda a sessão, pela geração do 
relatório final da inspeção e pela documentação das métricas de erros e correções que precisam 
ser realizadas visando à melhoria contínua. Também faz a aceitação final do produto inspecionado.
• Moderador: é o responsável pelo planejamento, pela montagem da equipe de inspeção junto com 
o autor e pela condução da sessão a partir do checklist. Trata‑se do facilitador do processo.
• Autor: é o elaborador do artefato a ser inspecionado; distribui o documento aos participantes, 
monta a equipe junto com o moderador, tira dúvidas durante a sessão e faz as correções dos erros 
identificados.
• Leitor: faz a leitura gradual do artefato para que a equipe faça as observações, os questionamentos 
e o apontamento de incorreções.
• Inspetor: examina o artefato antes da reunião de inspeção, aponta erros e faz sugestões de 
melhoria. Todos os participantes da reunião de inspeção têm o papel de inspetor.
• Escritor: registra as incorreções apontadas pelos inspetores.
Esses são os papéis mínimos em uma inspeção, e não quer dizer que tenhamos apenas uma pessoa em 
cada papel. A cada inspeção, definem‑se os participantes de forma coerente com o que precisa ser verificado.
100
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade III
5.4.3 Checklist de uma inspeção
Os checklists são listas de verificação elaboradas previamente com base em informações históricas 
de outras inspeções, lições aprendidas, dados fornecidos por especialistas e itens retirados de padrões 
preexistentes contra os quais o artefato será avaliado. Um checklist é incrementado a cada inspeção 
realizada, registrando as informações para inspeções futuras, e deve ser único por artefato elaborado.
O Quadro 16 apresenta alguns exemplos de itens de verificação para alguns artefatos típicos do 
processo de desenvolvimento de software.
Quadro 16 – Exemplos de itens de checklists para artefatos de software
Artefato Itens de verificação
Especificação dos casos de uso
As precondições foram descritas?
A especificação está de acordo com a tela?
Os fluxos alternativos foram corretamente indicados?
As regras de negócio foram apontadas?
Na descrição dos casos de uso não há referências de navegação?
Os atributos de entrada e saída estão descritos?
As pós‑condições estão explícitas?
Diagrama de classes
As classes identificadas referem‑se a objetos reais do sistema?
Os relacionamentos de agregação e herança fazem sentido no contexto do sistema?
Métodos privados foram identificados?
As classes têm menos de vinte atributos?
O requisito de baixo acoplamento foi respeitado?
O requisito de alta coesão foi atendido?
Diagrama de dados
Todas as tabelas possuem chaves primárias?
A chave primária está correta?
Existem índices secundários criados?
As chaves secundárias estão corretamente relacionadas às tabelas?
Documento de arquitetura
Foram considerados os padrões do cliente?
Existe uma implementação do padrão definido para servir de referência?
Foram considerados os requisitos de segurança?
Foram consideradosos requisitos de desempenho?
Foram considerados os padrões de implementação da linguagem?
Codificação
As variáveis estão com nomes adequados?
Todas as variáveis são inicializadas?
Todas as variáveis são do tipo privado?
Os métodos estão com nomes adequados?
Todos os métodos retornam valores?
Condições e loops estão corretamente grafados?
Existem mais de duas condicionais aninhadas?
101
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
Uma inspeção é extremamente eficaz para a identificação de erros e a verificação de suas correções, 
tornando‑se uma das principais ferramentas para a garantia da qualidade de um produto de software. 
Por não necessitar de execução da aplicação, seu caráter preventivo e de completude a faz mais efetiva 
que os testes unitários e integrados realizados pelas equipes de desenvolvimento.
O planejamento e a realização de inspeções devem ser parte integrante do cronograma de 
desenvolvimento de um sistema por equipes maduras e experientes com foco na qualidade de seus 
produtos.
5.5 Sala limpa (clean room)
O nome é derivado do processo clean room, usado na fabricação de circuitos integrados e proposto 
para a engenharia de software em 1980 por Mill, Dyer e Linger. Essa técnica é baseada em especificações 
formais matemáticas e destinada ao desenvolvimento de software de alta confiabilidade como os 
utilizados no controle de usinas nucleares, na navegação de aviões, trens, metrôs e navios, dentre outros.
O foco da sala limpa é a realização de ações preventivas, e não a correção de erros. A verificação 
se dá por meio de inspeções rigorosas, provas matemáticas e testes estatísticos para determinar a 
confiabilidade do sistema, tornando‑a diferente de outras técnicas (SOMMERVILLE, 2013).
Embora esteja comprovado que os resultados da confiabilidade do software aumenta 
consideravelmente com o processo sala limpa, Pressman (2006) atribui três situações que fazem a 
técnica não ser largamente utilizada no mercado de desenvolvimento de software:
• a crença de que é uma metodologia muito teórica, matemática e radical para o desenvolvimento 
de software;
• a substituição de testes unitários por verificação de correção e controle estatístico de qualidade é 
muito diferente do método costumeiramente empregado pelos desenvolvedores de software;
• as empresas de desenvolvimento de software ainda não possuem nível de maturidade suficiente 
para aplicar o processo sala limpa.
Agrega‑se a essas três situações o fato de ser um processo muito mais custoso que os tradicionais, 
tanto na especificação como na verificação, além de exigir maior qualificação técnica e matemática 
dos profissionais envolvidos no processo e manutenção de treinamentos constantes das equipes para a 
garantia dos padrões exigidos e para o tratamento de mudanças nos membros das equipes.
5.5.1 Processo sala limpa
Segundo Sommerville (2013), o processo sala limpa é estruturado em quatro processos e suas 
respectivas atividades, ilustrados na Figura 33:
 
102
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade III
CR
CR
CR
TE
TE
TE
C
C
C
PT
PT
PT
EF
EF
EF
PF
PF
PF
VC
VC
VC
COD
COD
COD
IC
IC
IC
ES
Incremento 1
Incremento 2
Incremento 3
• COD (geração de código)
• IC (inspeção de código)
• TE (teste estatístico)
• C (certicação)
• PT (planejamento de teste)
• ES (engenharia de sistemas)
• CR (coleta de requisitos)
• EF (especificação formal)
• PF (projeto formal)
• VC (verificação de correção)
Figura 33 – O desenvolvimento com o processo sala limpa
• Processo de gerenciamento: define as atividades relacionadas à gestão do projeto com as ações 
de planejamento e de gestão das mudanças durante o processo.
• Processo de especificação: descreve as atividades de coleta de requisitos, a especificação formal 
dos requisitos, a especificação formal do projeto, a definição da arquitetura do sistema, o plano 
de desenvolvimento incremental do projeto e a verificação formal das especificações.
• Processo de desenvolvimento: define as atividades de engenharia relativas à codificação e à 
inspeção formal do código produzido.
• Processo de certificação: define o uso dos modelos de referência, os testes estatísticos formais, a 
execução da aplicação e a certificação da confiabilidade do software em desenvolvimento.
5.5.2 Testes estatísticos
São utilizados com o objetivo de avaliar as condições operacionais do software relacionadas à 
robustez, ao desempenho e à confiabilidade a partir de registros em arquivos em tempo de execução 
(logs) para gerar as ocorrências que possam ser avaliadas por meio de dados estatísticos e matemáticos, 
tais como: número de falhas observadas, tempos de resposta, tempos de execução, dentre outras. Com 
essas medidas estatísticas registradas, a confiabilidade é definida com base nos resultados dos testes 
realizados. Se uma longa sequência de testes for conduzida sem falha ou ocorrência de defeitos, o 
tempo médio de falhas – Mean Time to Failure (MTTF) será baixo, e a confiabilidade do produto de 
software poderá ser considerada alta.
103
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
Por exemplo, vamos supor que você tenha testado três sistemas exatamente iguais e de forma 
paralela, até que ocorresse uma falha ou um defeito em cada um deles. O primeiro sistema apresentou 
uma falha após 20 horas de execução, o segundo sistema falhou após 18 horas e o terceiro sistema 
falhou após 24 horas. Neste caso, o MTTF é igual à média aritmética dos três tempos registrados, ou seja, 
é calculado como (20 + 18 + 24)/3 que apresenta o resultado igual a 20,66.
 Observação
Logs são arquivos físicos ou tabelas que registram as diversas atividades 
realizadas pelo software durante a sua execução, mediante previsão de 
gravação dessas informações.
5.5.3 Certificação de qualidade
Para que a certificação de qualidade ocorra, os cenários de testes são criados e especificados, e 
os casos de testes são gerados e executados. O resultado dessa execução gera os dados das falhas 
que permitem o cálculo da confiabilidade, e, estando dentro da média esperada (MTTF), o software 
recebe a certificação.
 Observação
MTTF é um indicador de confiabilidade de software que mostra o tempo 
médio em que uma falha não recuperável acontece durante os testes de 
um software.
 Saiba mais
Para obter mais informações sobre confiabilidade de software e 
especificações formais, visite o site: .
6 TESTES DE SOFTWARE
A atividade de teste de software sempre foi considerada como um gasto de tempo desnecessário, uma 
atividade de segunda classe, uma vez que a programação é a atividade principal no desenvolvimento de 
software. Os testes tinham apenas o objetivo de mostrar que o sistema funcionava.
Somente a partir da década de 1980 começaram a ser elaborados métodos de testes que passaram 
a fazer parte do processo de desenvolvimento de software, de maneira formal e como uma atividade 
essencial ao processo de construção, que passou a ter o objetivo de garantir que o sistema atendesse 
aos requisitos especificados.
104
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade III
No final da década de 1990 começaram a ser criadas as funções de gerente de testes, analista de 
testes e operador de testes, que são especialistas no planejamento, na elaboração e na execução dos 
testes, tornando estes cada vez mais relevantes no ciclo de vida do software e assumindo um perfil de 
prevenção de problemas, e não apenas de localização de erros.
6.1 Fundamentos sobre testes de software
Atualmente, o grau de exigência dos usuários com a qualidade dos produtos de software está cada 
vez maior. A complexidade das aplicações em relação à granularidade, a segurança e a integração com 
outros sistemas e o aumento da concorrência no mercado desoftware tornam os testes uma atividade 
essencial e indispensável, com equipes exclusivas e dedicadas a essas ações, com o objetivo de garantir 
e controlar a qualidade do sistema.
Nos modelos de qualidade de processo de software, o processo de testes e as atividades de V&V 
aparecem apenas nos níveis de maturidade intermediários, como o Nível 3 para o CMMI e o Nível D do 
MPS.BR, conforme ilustrado na Figura 34.
Teste de 
software
CMMI 
nível 3
MPS.BR
nível D
+
Figura 34 – O processo de testes nos modelos de qualidade
6.1.1 Conceitos de testes de software
As definições sobre testes de software variam, mas todas convergem para os conceitos básicos de 
encontrar defeitos em um software que está sendo testado, conferir se está de acordo com os requisitos 
definidos pelo usuário e verificar se realiza o que deveria ser feito.
Segundo Myers (2004), testar um software é um processo de executar um programa ou sistema com 
a intenção de encontrar defeitos.
Para Dijkstra (1970), os testes podem mostrar a presença de falhas em um software, mas nunca a 
sua ausência.
Para Hetzel (1988), testes são uma atividade que, a partir da avaliação de um atributo ou capacidade 
de um programa, torna possível determinar se ele alcança os resultados esperados.
105
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
Para o Instituto de Engenheiros Eletricistas e Eletrônicos (IEEE), teste é um processo de execução de 
um sistema ou programa, sob condições específicas, para detectar diferenças entre os resultados obtidos 
e os esperados.
 Saiba mais
IEEE é uma entidade internacional que publica trabalhos sobre Tecnologia 
da Informação, dentre ouras áreas. Acesse o site: .
É importante ressaltar que muitos desenvolvedores ainda confundem o processo de testes com o 
processo de depuração de um programa, mas ambos são completamente diferentes, pois enquanto os 
testes são uma busca estruturada para encontrar erros em um programa pronto, a depuração, mais 
conhecida como debug, é um processo de busca de erros de forma não estruturada durante a execução 
de um programa, por meio de uma ferramenta de apoio ao desenvolvimento. Uma vez encontrado, o 
erro deve ser corrigido. A depuração, normalmente, ocorre durante a atividade de programação e antes 
da execução dos testes propriamente ditos.
Os testes devem ser realizados: pelos desenvolvedores, por meio dos testes unitários; pelos testadores, 
mediante os testes integrados guiados por roteiro de testes elaborados a partir da especificação inicial; 
e pelos usuários, por meio dos testes de aceitação, nos quais é verificado se o software atende às 
necessidades. Em outras palavras, testes de software são uma atividade de validação, de responsabilidade 
de todos os que participam do processo de desenvolvimento, para garantir a qualidade.
6.1.2 Conceituação de defeito, erro e falha
Constantemente há confusão entre o uso das palavras erro, defeito e falha pelos profissionais de 
Tecnologia da Informação, principalmente, pela tradução dos termos da língua inglesa. Para esclarecer 
esses conceitos, o IEEE, por meio da norma 610.12 (1990), definiu os seguintes fundamentos para esses 
três termos descritos no Quadro 17.
Quadro 17 – Definições de termos segundo o IEEE 610.12
Termo Termo em inglês Definição
Engano Mistake Ação humana que produz um resultado incorreto 
Falha Fault ou bug Manifestação, no software, de um engano cometido pelo desenvolvedor 
Erro Error Diferença entre o valor obtido e o valor esperado, ou seja, qualquer estado 
inesperado na execução do software 
Defeito Failure Incapacidade de o software fornecer o serviço conforme especificado 
Fonte: IEEE (1990).
106
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade III
Portanto, a partir das falhas inseridas no código pelos desenvolvedores, acontecem os erros e os 
defeitos do software, que são detectados pelo processo de testes. As principais falhas do software 
ocorrem em virtude dos enganos cometidos nas especificações iniciais da fase de requisitos, que 
mapeiam as necessidades dos usuários e que não são detectadas pelo processo de testes. Além dessa 
falha original, novos erros e defeitos são inseridos por meio de:
• alterações e mudanças constantes que afetam o software, tornando a manutenção cada vez mais 
difícil;
• tempo reduzido de implementação que pressiona o desenvolvedor a cometer mais erros;
• código mal‑escrito, fora de padrões estabelecidos;
• falta de documentação do software.
Segundo Rios e Moreira (2013), diversos tipos de defeitos podem ser encontrados em um software. 
Esses defeitos podem ser evitados, desde que sejam do conhecimento do desenvolvedor, e podem fazer 
parte de um checklist de boas práticas para serem tratados nas fases iniciais da codificação, juntamente 
com os padrões de código. Os principais defeitos que podem ocorrer em um software são apresentados 
no Quadro 18.
Quadro 18 – Principais tipos de defeitos de software
Tipo de defeito Definição
Funcionalidade Quando o software não faz o que o usuário espera que ele faça 
Usabilidade
Quando há dificuldade de navegação, a cor do texto está muito clara, 
dificultando a leitura, ou o conteúdo é muito extenso, obrigando o usuário a 
usar barra de rolagem constantemente 
Desempenho O software não atende com a rapidez necessária às solicitações do usuário, 
especialmente, no caso dos sistemas muito interativos 
Prevenção de defeitos
O programa não se protege das entradas de dados não previstas, que, 
posteriormente, são processadas de forma inadequada. O software pode, por 
exemplo, aceitar valores em branco em campos numéricos 
Detecção e recuperação de 
defeitos
O programa não trata as operações, como: overflow, flags de defeitos, ou trata 
de forma inadequada 
Limites O software não consegue tratar ou trata inadequadamente valores extremos (o 
maior, o menor, o primeiro, o último) ou fora dos limites 
Cálculo O software executa um cálculo e produz um resultado errado. Muitas vezes, por 
questões de aproximação, uma fórmula não produz os resultados esperados 
Inicialização ou fechamento
Alguns softwares ou rotinas devem ser inicializados quando usados pela 
primeira vez ou sempre que são chamados para execução. Exemplo de 
inicialização de programa: na primeira vez em que executa, o software deve 
criar um arquivo em disco. A ausência deste arquivo poderá causar problemas 
nas etapas seguintes do processamento 
Condições de disputa
Ocorre quando o software espera pela resposta dos eventos A e B, sendo 
suposto que A sempre termine primeiro. Se por algum problema B terminar 
primeiro, o software poderá não estar preparado para esta situação e 
apresentar resultados inesperados 
107
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
Carga
O software pode não suportar um pico de serviço em um determinado 
momento (estresse) ou uma carga alta de serviço por um tempo muito 
prolongado 
Hardware ou software Capacidade do equipamento ou do software básico de suportar as condições 
de operação da aplicação por tempo prolongado
Fonte: Rios; Moreira (2013).
6.1.3 Por que devemos testar um software?
Além do fator qualidade, que foi exposto até aqui, afeta a satisfação do cliente e é um dos principais 
indicadores de uma organização, o fator custo é um grande incentivador para que as organizações 
apliquem e utilizem o processo de testes no ciclo de desenvolvimento de software.
Segundo um dos maiores especialistas em desenvolvimento de software no mundo, Boehm (1976), 
quanto mais tarde um defeito for identificado, mais caro ficará para corrigi‑lo. Além disso, os custos 
para se identificar e corrigir os defeitos em um software aumentam exponencialmente na proporção em 
que o trabalho evolui em suas fases de desenvolvimento.
De acordo com Myers (2004), quanto mais cedo for descoberto e corrigido o defeito,menor será 
o seu custo para o projeto, pois esse custo cresce até dez vezes a cada fase para a qual o projeto do 
software avança. Essa afirmação é conhecida como a Regra 10 de Myers.
É do conhecimento do mercado de Tecnologia da Informação que as organizações chegam a gastar 
até 30% do esforço total do desenvolvimento de software realizando testes, e, no caso de construção 
de softwares críticos, como software de controle de voo, trens e navios, a fase de testes pode custar de 
três a cinco vezes mais que todas as demais fases de um projeto tradicional.
Garantir que o software esteja sem erros e defeitos é um dos desafios da Engenharia de Software, 
mas não é possível rever todas as combinações de testes que garantam a total cobertura de testes em 
uma aplicação. Portanto, sempre haverá algo a se fazer, seja testar, seja corrigir um defeito. Contudo, 
de todas as formas de verificação e validação da qualidade, o processo de testes é a forma mais eficaz 
de se aproximar do erro zero e, aliado ao trabalho de equipes de testes cada vez mais especializadas e 
independentes, os resultados tendem a ficar cada vez melhores, e os objetivos de aumento da qualidade 
e redução dos custos podem ser alcançados com esforços cada vez menores.
6.2 Ciclo de vida de testes
O ciclo de vida do processo de testes deve seguir rigorosamente o processo de desenvolvimento 
adotado para a construção do software.
O mais utilizado e conhecido processo de testes é o Modelo V, visto a seguir, o qual prevê que 
os testes devam começar o mais cedo possível, a partir de uma especificação inicial, devendo ser 
realizados durante todo o processo de construção. Porém, a falta dessa especificação ou a existência de 
especificações incompletas e ambíguas podem levar a resultados insatisfatórios nos testes e demonstrar 
108
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade III
falsas conclusões a respeito da qualidade do software. A definição de um oráculo correto e validado 
pelos usuários é essencial para o sucesso dos testes.
 Observação
Oráculo é uma referência que define os resultados esperados para serem 
comparados com os resultados reais durante os testes de um software.
Segundo Rios e Moreira (2013), para que o processo de testes seja eficiente, é necessário:
• entender o sistema em todos os seus detalhes;
• dominar as técnicas de testes;
• ter habilidade para aplicar essas técnicas.
6.2.1 O Modelo V
O Modelo V foi desenvolvido a partir do processo de desenvolvimento cascata, no início da década 
de 1980, para incluir o processo de testes no ciclo de desenvolvimento do software. O foco é desenvolver 
os testes desde o início do ciclo de vida do software, para permitir a identificação de defeitos o mais 
corretamente possível, por meio de atividades de verificação e validação e da criação de casos de testes 
e roteiro de testes. A Figura 35 ilustra o Modelo V de testes e de desenvolvimento.
Especificação 
requisitos
Testes de 
aceitação
Testes de 
sistema
Projeto 
arquitetual
Projeto 
detalhado
Testes 
integrados
Codificação
Testes unitários
Validação
Validação
Validação
Figura 35 – O Modelo V do processo de testes
109
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
Como dito anteriormente, o processo de testes deve acontecer em conjunto com o processo de 
desenvolvimento de software, seguindo suas fases e avaliando os produtos à medida que ficam prontos. 
Assim, mesmo que o Modelo V esteja desenhado a partir do processo cascata, todos os demais processos 
de desenvolvimento possuem em suas características pequenos ciclos desse processo denominados de 
minicascatas, seja o processo de desenvolvimento utilizado o espiral, o incremental ou o iterativo, por exemplo.
Após o levantamento de requisitos pela equipe de desenvolvimento, a equipe de testes entra no 
processo a fim de obter as necessidades do cliente e começar a identificar os casos de testes com base 
na especificação elaborada e no protótipo de telas produzido e validado pelo usuário. A identificação 
dos casos de testes deve ser feita pela equipe de testes e validada com os usuários. Essa lista de casos de 
testes deve ser acrescida das situações de testes fornecidas pelos usuários.
Uma vez que os casos de testes são avaliados e aprovados, inicia‑se a elaboração do roteiro de testes 
que descreve em detalhes o passo a passo para a realização dos testes, especificando o que deve ser feito 
e qual o resultado esperado. O nível de detalhe deve ser suficientemente claro para ser executado por 
pessoa externa ao processo. Esse roteiro deve ser submetido à inspeção e à aprovação do usuário antes 
de ser utilizado e deve cobrir todas as situações que os usuários utilizam na fase de aceite do sistema. 
Esse processo é ilustrado na Figura 36.
 • Regras de negócio
 • Protótipo de telas
 • Identificação dos cenários
 • validação com usuários
 • Descrição detalhada do caso de testes
 • Definição dos resultados esperados
Requisitos
Casos de 
teste
Reoteiro de 
testes
Figura 36 – Processo de criação de roteiro de testes
Durante a fase de codificação os desenvolvedores realizam testes unitários e integrados que devem 
garantir que os programas construídos funcionam corretamente. Os roteiros podem ser utilizados nessa fase.
Passado pelos testes iniciais, o software deve ser avaliado pela equipe de testes que, de posse do 
roteiro de testes, executa‑os para garantir que o software esteja de acordo com as especificações dos 
usuários. Nessa fase devem ser gerados os registros e as evidências de que os testes foram realizados 
com sucesso.
110
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade III
Na fase final, a homologação é feita pelos usuários que fazem os testes de aceitação, normalmente, 
sem utilizar o roteiro, para garantir que o software esteja de acordo com as necessidades e execute 
corretamente as funções que lhe são atribuídas.
O Quadro 19 apresenta a coerência entre as fases de desenvolvimento e a fase de testes, as atividades 
que são realizadas nesta fase, as ações de qualidade que devem ser executadas e os membros das 
equipes envolvidos em cada caso.
Quadro 19 – Atividades de testes dentro do ciclo de desenvolvimento
Fase de 
desenvolvimento Fase de testes Atividade Ações de 
qualidade Participantes
Especificação Planejamento
Estratégia e 
preparação do 
ambiente de testes
Revisão Equipe de testes
Projeto de arquitetura Análise Identificação dos 
casos de testes Revisão e inspeção Equipe de projeto e 
de testes
Projeto detalhado Especificação Elaboração do roteiro 
de testes Inspeção Equipe de testes e 
usuários
Construção Execução
Localização de 
defeitos e realização 
da correção
Testes unitários e 
integrados
Equipe de projeto e 
de testes
Implantação Homologação Correção de defeitos Testes de sistema e 
aceitação
Equipe de projeto, de 
testes e usuários
6.2.1.1 Níveis de testes do Modelo V
Os testes são divididos em níveis para facilitar o entendimento de sua abrangência e cobertura 
dentro do ciclo de vida de um software. Esses níveis são detalhados a seguir.
6.2.1.1.1 Testes de unidade ou testes unitários
São testes realizados pelos desenvolvedores de software com o objetivo de garantir o funcionamento 
adequado do programa, do módulo, da função ou da classe que foi construída. Podem ser automatizados 
ou realizados por meio de ferramentas. A Figura 37 ilustra as unidades de um teste.
Figura 37 – Representação de unidades de testes
111
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
6.2.1.1.2 Testes de integração
São testes realizados após o teste unitário para garantir que os elementos que compõem a aplicação 
funcionam de forma integrada com sucesso. Feitos pelos analistas de sistemas, envolvem testes de 
subsistemas ou incrementos do software. A Figura 38 ilustrao agrupamento dessas unidades.
Figura 38 – Representação da integração das unidades de testes
6.2.1.1.3 Testes de validação/sistemas
Realizados após os testes de integração, visam verificar se a aplicação desenvolvida está de acordo 
com a especificação inicial do sistema. São realizados pelos analistas de testes.
Para melhor avaliação dos testes de validação é necessário que o ambiente seja o mais semelhante 
possível ao ambiente de produção e que exista um roteiro de testes, a ser seguido pelos envolvidos no 
teste, a fim de que os resultados sejam avaliados, registrados e evidenciados pelo sistema de controle 
da qualidade.
6.2.1.1.4 Testes de aceitação
São testes realizados pelos usuários finais e analistas de testes que visam garantir que todos os 
requisitos solicitados foram incluídos e funcionam corretamente no produto entregue. São feitos 
utilizando os critérios estabelecidos pelos usuários e sem roteiro preestabelecido, pois o usuário testa 
como se estivesse utilizando o software no seu dia a dia. Sua duração está condicionada à aceitação, 
pelos usuários, dos defeitos e pendências encontrados durante os testes, bem como aos riscos associados 
à liberação do software.
6.2.2 Testes na fase de manutenção do sistema
O processo de testes também deve ser aplicado à fase de manutenção do software, que consiste na 
inclusão ou na retirada de alguma funcionalidade do sistema ou na alteração de alguma característica 
preexistente. A manutenção nos softwares ocorre com muito mais frequência do que o desenvolvimento 
de novos sistemas, portanto a importância da realização de testes é tão grande quanto em novos sistemas.
Os roteiros de testes elaborados para o desenvolvimento do software devem ser alterados para 
atender às novas necessidades incluídas ou excluídas pelo processo de manutenção do sistema. Porém, 
não basta executar a parte do sistema que sofreu alterações: toda a aplicação deve ser testada para 
garantir que nenhuma funcionalidade preexistente tenha sido afetada pela mudança. Esse processo é 
chamado de teste de regressão.
112
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade III
Segundo Rios e Moreira (2013), é evidente que, quanto melhores forem os testes feitos durante o 
desenvolvimento, menores serão os custos durante a fase de manutenção.
6.3 Tipos de testes
Normalmente, a preocupação dos desenvolvedores está em realizar testes que garantam que o 
software atende às necessidades dos usuários. Porém, os testes não se limitam aos requisitos funcionais.
Os requisitos funcionais envolvem o correto funcionamento do software, sua integração 
com outros sistemas, suas interfaces e a garantia de que qualquer alteração feita não afete a 
aplicação.
Os requisitos não funcionais surgem principalmente na fase de projeto arquitetural e/ou detalhado, 
estão ligados às características comportamentais do software e não são solicitados pelos usuários. Esses 
requisitos devem ser avaliados pela equipe de desenvolvimento, validados junto aos usuários e definidos 
aqueles que devem ser aplicados a cada tipo de sistema.
Neste tópico serão apresentados e descritos os diversos tipos de testes mais utilizados pelo mercado 
de Tecnologia da Informação, tanto para os requisitos funcionais quanto para os requisitos não 
funcionais, e que devem ser parte integrante do checklist de qualidade de desenvolvimento de software, 
principalmente, para a fase de projeto.
6.3.1 Amplitude dos tipos de testes
Existem diversos tipos de testes para serem realizados. Podem ter caráter funcional ou não funcional 
e, no desenvolvimento ou na manutenção de um sistema, podem ser total ou parcialmente executados, 
dependendo das características da aplicação e do ambiente em que serão executados. Esses tipos de 
testes são ilustrados na Figura 39.
Regressão
Interoperabilidade
Usabilidade
Alfa/beta
Carga ou stress
Desempenho
Segurança
Recuperação
Confiablidade
Portabilidade
Estáticos
Aderência ao código
Configuração
Navegação
Instalação
Testes funcionais Testes não funcionais Testes de ambiente
Figura 39 – Principais tipos de testes
113
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
6.3.1.1 Tipos de testes para requisitos funcionais
• Testes de regressão: têm como objetivo garantir que, mesmo após mudanças realizadas nas 
fases de desenvolvimento ou manutenção, a aplicação continue funcionando adequadamente e 
produzindo os resultados esperados.
• Testes de interoperabilidade: visam avaliar e garantir que a comunicação entre os sistemas envolvidos 
e entre os ambientes computacionais da aplicação estejam funcionando adequadamente. Por 
exemplo: ao acessar um sistema de validação de CEP, este retorna valores válidos.
• Testes alfa e beta: são testes executados após a aplicação estar pronta e feita pelos usuários finais 
da aplicação. Os roteiros de testes não são seguidos, e o objetivo é identificar o maior número de 
defeitos possível antes de liberar a aplicação para a produção.
• Testes de usabilidade: avaliam a facilidade de uso da aplicação quanto à visão dos dados na tela, 
às cores, à disposição dos componentes de interação dos usuários, à facilidade de interpretação 
das mensagens e ao conteúdo e à clareza das informações nas telas.
6.3.1.2 Tipos de testes para requisitos não funcionais
• Testes de carga ou stress: são testes que têm como objetivo avaliar o comportamento da aplicação 
sob condições extremas de acessos simultâneos ou de requisições ao servidor para verificar se suporta 
o volume esperado. Em razão do volume de requisições que precisam ser geradas, esses testes são 
realizados por ferramentas específicas para esse fim. Exemplo: a aplicação deve suportar até mil 
usuários realizando login ao mesmo tempo ou responder a até trezentas requisições por minuto.
• Testes de desempenho ou performance: têm por objetivo verificar se a aplicação responde às 
requisições dos usuários dentro do tempo esperado. Também são testes automatizados. Por 
exemplo: a cada solicitação do usuário, o sistema deve responder em, no máximo, 5 segundos.
 Saiba mais
Existem diversas ferramentas para testes de carga e testes de 
desempenho. Um dos mais utilizados é o JMeter, que pode encontrado no 
site: .
• Testes de segurança: verificam a capacidade da aplicação de lidar com as tentativas não autorizadas 
de acesso aos perfis dos usuários autorizados.
• Testes de recuperação ou disaster recovery: o objetivo desses testes é validar como a aplicação 
se comporta em situações extremas de falta de energia, queda da rede, falha de comunicação, 
dentre outras.
114
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade III
• Testes de portabilidade: visam avaliar a instalação e o funcionamento da aplicação em ambientes 
operacionais diferentes, previstos no planejamento.
• Testes de confiabilidade ou disponibilidade: visam avaliar o comportamento da aplicação quando 
submetida à falha de algum item do seu ambiente operacional, como servidor de aplicação, servidor 
de banco de dados, dentre outros. Nessa situação, o software deverá manter‑se funcionando 
parcialmente e/ou tratar as falhas adequadamente por meio de mensagens aos usuários.
6.3.1.3 Tipos de testes para ambiente
• Testes estáticos: validam se as especificações, os diagramas de casos de uso, o diagrama de classes, 
o modelo de dados, dentre outros estão coerentes com a aplicação desenvolvida. São realizados 
por meio de revisões técnicas formais ou inspeções.
• Testes de aderência de código: visam avaliar se o código‑fonte da aplicação está de acordo com 
os padrões e as melhores práticas previstas no processo de qualidade. São executados por meio 
de ferramentas ou de inspeções.
• Testes de configuração: avaliam se o software se comporta adequadamente de acordo com as 
especificações de hardware e software planejadas. Por exemplo:o software funciona nas versões 
x e y do browser Z?
• Testes de navegação: avaliam o comportamento da aplicação no que tange à navegação entre 
telas, aos links para outros sistemas, dentre outros.
• Testes de instalação: verificam se o plano de instalação do sistema está correto e se a aplicação 
funciona após a instalação em um novo ambiente.
6.4 Técnicas de testes
Como visto até aqui, os testes são essenciais no processo de desenvolvimento e devem ser aplicados 
nas várias fases do ciclo de vida do software. As técnicas de testes mais utilizadas no mercado definem 
basicamente duas estratégias: uma baseada na especificação funcional da aplicação e outra focada em 
avaliar a qualidade do código produzido. A primeira é mais direcionada aos testes de sistema e de aceite, 
enquanto a segunda é utilizada nos testes de unidade e de integração.
A definição de qual técnica deve ser utilizada depende de vários fatores, mas o mais determinante é 
o tempo disponível para a aplicação desses testes dentro do prazo do projeto.
Entrando em maiores detalhes, as principais técnicas de testes estão ilustradas na Figura 40.
115
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
Testes caixa-preta
Testes caixa-branca Análise de mutantes
Figura 40 – Principais tipos de testes
6.4.1 Técnica de testes funcionais ou caixa‑preta
Baseada na especificação inicial do sistema, elaborada na fase de levantamento de requisitos, como 
as especificações de casos de uso e o protótipo de telas, são extraídas as situações de sucesso e insucesso 
na execução de determinadas funcionalidades que são chamadas de casos de teste.
• Técnica de teste estrutural ou teste caixa‑branca: realizada sobre o código escrito pelos 
desenvolvedores para garantir a qualidade do código produzido.
• Técnica de teste baseada em erros: feita com base nos erros típicos cometidos durante o 
desenvolvimento de software. Fundamenta‑se em duas abordagens básicas. Uma delas é relativa 
à semeadura de defeitos, em que erros mais comuns de programação são inseridos no código, 
sem o conhecimento do testador, para que sejam encontrados. A outra abordagem é a chamada 
análise de mutantes, em que cópias do programa a ser testado são criadas e condições de erro são 
incluídas, para verificação. São mais utilizadas na fase de testes unitários e testes de integração, 
mas seu uso é bastante reduzido no mercado e não são detalhadas neste livro.
6.4.2 Técnicas de teste estrutural ou caixa‑branca
O teste estrutural ou caixa‑branca é focado em avaliar a qualidade do código produzido pelos 
desenvolvedores, garantindo que toda linha de código escrita seja executada pelo menos uma vez. 
Para isso, são identificadas todas as condições de controle do programa (if, while, repeat, case, switch, 
dentre outras) e gerada a massa de testes necessária para a verificação do código‑fonte em cada uma 
das situações mapeadas.
 Observação
Massa de testes refere‑se ao conjunto de dados de entrada em um 
teste que produz um resultado esperado pelo testador.
116
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade III
Como os testes estruturais são focados na codificação, sua aplicação pode fazer parte das inspeções 
de código, em que, além de verificar a aderência do código aos padrões e às boas práticas de programação, 
devem‑se avaliar as diversas condições previstas no programa.
Para auxiliar na identificação dos caminhos de programação exclusivos e necessários para testar 
cada linha de código, existe uma técnica de mapeamento chamada grafo de fluxo de controle.
6.4.2.1 Grafo de fluxo de controle
Trata‑se de uma representação gráfica que permite visualizar a complexidade dos caminhos de um 
programa, independentemente da linguagem de programação utilizada. O grafo é formado por nós 
que são ligados por arestas mediante setas que mostram sua direção. Os nós representam blocos de 
comandos. O bloco de comando é um conjunto de instruções no qual, ao executar o primeiro comando, 
todos os comandos seguintes também são executados. As arestas informam a direção e a sequência em 
que os nós são chamados.
Além das estruturas básicas de nós e arestas, o grafo de controle possui os chamados nós predicados, 
que são aqueles de onde partem pelo menos duas arestas.
6.4.2.2 Representação gráfica das estruturas básicas de controle
A seguir são apresentadas as estruturas básicas do grafo de controle.
• Sequência: são comandos procedurais. Representação gráfica na Figura 41.
Figura 41 – Grafo de controle: sequência
• Seleção: comandos if… then… else; case; switch. Representação gráfica na Figura 42.
If Case ou switch
Figura 42 – Grafo de controle: seleção
117
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
• Repetição: comandos while...; for…; do... until. Representação gráfica na Figura 43.
While Repeat
Figura 43 – Grafo de controle: repetição
Essas estruturas básicas de controle permitem a construção da lógica do programa que será avaliado 
nos testes de caixa‑branca.
No exemplo da Figura 44, tem‑se a representação de um grafo de controle para um programa com 
dois caminhos retirados a partir de um comando if. Cada número no programa representa um nó no 
grafo, e cada caminho possível é uma aresta.
início
 leia nro
 se nro > 0
 raiz = taiz‑quadrada(nro)
 escreva raiz
 senão
 escreva mensagem de erro
 fim‑se
fim
1
2
3
4
1
2 3
4
Figura 44 – Exemplo 1 de um grafo de controle
No exemplo da Figura 45, tem‑se um programa um pouco mais complexo que inclui, além do 
comando if, um comando while. No grafo, a bolha 1 representa um comando sequencial e as bolhas 2 e 
7 são da repetição, enquanto as bolhas 3, 4 e 5 e 6 representam o if.
118
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade III
início
 leio nro
 enquanto nro ≠ 0
 se nro > 0
 raiz = raiz‑quadrada(nro)
 escreva raiz
 senão
 escreva mensagem de erro
 fim‑se
 leia nro
 fim‑enquanto
fim
1
4
5
6
2
7
3
3
4 5
6
1
2
7
Figura 45 – Exemplo 2 de um grafo de controle
6.4.2.3 Testes de caminhos independentes
Com a construção do grafo de controle é possível determinar os caminhos de testes básicos do 
programa, chamados de caminhos independentes.
Caminho independente é aquele que contém pelo menos uma nova aresta no grafo de controle 
e garante que todo comando será executado pelo menos uma vez. No exemplo da Figura 46, cada 
caminho possui ao menos um nó exclusivo.
Caminhos independentes
1‑2‑7
1‑2‑3‑4‑6‑2
1‑2‑3‑5‑6‑2
3
4 5
6
1
2
7
Figura 46 – Identificação de caminhos independentes
119
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
6.4.2.4 Complexidade ciclomática – V(G)
Desenvolvida por Tom McCabe em 1976, baseada no grafo de controle, tem como objetivo medir 
quantitativamente a complexidade lógica de um programa e fornecer o limite superior para o número 
de caminhos independentes, que determina a quantidade de testes necessários para garantir que todas 
as linhas de código sejam executadas pelo menos uma vez.
Existem duas formas para se calcular a complexidade ciclomática:
• V(G) = (E – N)+2, onde:
E é o número de arestas.
N é o número de nós do grafo.
• V(G) = P + 1, onde:
P é o número de nós predicados do grafo.
Para o grafo de controle ilustrado na Figura 47, existem sete nós, oito arestas e dois nós predicados, 
que são os nós 2 e 3, de onde sai mais de uma aresta. Nesse caso, tem‑se a determinação de três 
caminhos independentes para testar, conforme apresentado na Figura 46.
Ainda segundo McCabe (1976), a partir do cálculo da complexidade ciclomática, é possível determinar 
o grau de risco de se testar um programa, ou seja, se o código ultrapassar a V(G) de 20, significará que 
existe um alto grau de chance de que não seja possível testá‑lo adequadamente146
7.2.2 Papéis e responsabilidades na manutenção ............................................................................. 146
7.2.3 Manutenção de sistemas legados ................................................................................................. 147
7.2.4 Engenharia reversa .............................................................................................................................. 147
7.2.5 Técnicas de manutenção .................................................................................................................. 147
7.2.6 Custos de manutenção ...................................................................................................................... 148
7.3 Processos de manutenção ..............................................................................................................148
7.3.1 Definição do processo de manutenção ...................................................................................... 149
7.3.2 Análise das mudanças ........................................................................................................................ 150
7.3.3 Aceitação e revisão da mudança ....................................................................................................151
7.3.4 Migração ...................................................................................................................................................151
7.3.5 Retirada de produção ......................................................................................................................... 152
7.4 Impactos na manutenção ...............................................................................................................152
7.4.1 Desenvolvimento orientado a objetos ........................................................................................ 153
7.4.2 Desenvolvimento baseado em componentes ........................................................................... 154
7.4.3 Desenvolvimento ágil ......................................................................................................................... 155
8 GESTÃO DA CONFIGURAÇÃO ...................................................................................................................155
8.1 Conceitos de gestão da configuração........................................................................................156
8.1.1 Problemas mais comuns ................................................................................................................... 156
8.1.2 Conceitos de gestão da configuração ......................................................................................... 159
8.2 Processo de gestão da configuração ..........................................................................................160
8.2.1 Identificação dos itens de configuração .....................................................................................161
8.2.2 Controle de versões ............................................................................................................................. 162
8.2.3 Controle de mudanças ....................................................................................................................... 164
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
8.2.4 Auditoria de configuração ............................................................................................................... 165
8.2.5 Registro do status ................................................................................................................................ 166
8.3 Padrões de gestão da configuração ............................................................................................166
8.3.1 Padrão de gestão de configuração – CMMI.............................................................................. 166
8.3.2 Padrão de gestão de configuração – ISO/IEC 12207 ..............................................................170
8.3.3 Padrão de gestão de configuração – ISO/IEC 9000‑3 ...........................................................171
8.3.4 Padrão de gestão de configuração – ISO/IEC 15504 (Spice) .............................................. 173
8.4 Application Lifecycle Management (ALM) ...............................................................................175
8.4.1 Gerenciamento de requisitos .......................................................................................................... 176
8.4.2 Gerenciamento da configuração ................................................................................................... 176
8.4.3 Gestão de mudança ............................................................................................................................ 176
8.4.4 Versionamento e integração ........................................................................................................... 176
8.4.5 Distribuição do software ................................................................................................................... 177
9
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
APRESENTAÇÃO
O objetivo da disciplina Engenharia de Software II é apresentar a você características importantes no 
desenvolvimento de um software que, normalmente, são esquecidas e/ou abandonadas pela incontrolável 
vontade de programar inerente aos profissionais ligados á área de Tecnologia da Informação. Nessa 
disciplina são descritos os requisitos de qualidade indispensáveis a um bom software, como devem 
estar inseridos no ciclo de desenvolvimento, a importância das atividades de testes, como controlar os 
diversos artefatos e o código do software e suas consequências na manutenção de software produzido.
O livro‑texto está dividido em quatro unidades, em que são apresentados os principais conceitos 
e modelos de qualidade para o desenvolvimento de software, as principais técnicas para garantir e 
controlar a qualidade, as características do processo de manutenção do software e como controlar tudo 
o que é produzido durante a construção de um sistema.
Na unidade I, são apresentados os principais conceitos sobre qualidade de software; o Sistema de 
Gestão da Qualidade (SGQ) baseado na norma ISO9000, pioneiro na questão de qualidade; e as principais 
normas para avaliação da qualidade do produto de software.
Na unidade II, são apresentadas as principais normas de padronização para avaliação da qualidade 
e os modelos de qualidade reconhecidos e praticados pelo mercado de Tecnologia da Informação para 
melhoria dos processos de desenvolvimento.
Na unidade III, são descritas a principais técnicas e ferramentas de verificação e validação que 
podem ser utilizadas pelas equipes durante o desenvolvimento do software para garantir e controlar a 
qualidade daquilo que é produzido e o processo de testes de software.
Na unidade IV, são discutidos os impactos de tempo e custo na manutenção de softwares desenvolvidos 
com e sem qualidade, mostrando claramente as vantagens de construir sistemas fundamentados 
em qualidade. Também são apresentadas técnicas para gerenciar e controlar os artefatos e códigos 
produzidos durante o ciclo de vida, visando garantir a integridade das informações por meio da gestão 
da configuração.
O objetivo é mostrar que é possível produzir um software com qualidade, em detrimento do processo 
de “fazer para entregar no prazo”, tornando o desenvolvimento claro, com o menor retrabalho possível 
e a garantia da satisfação da equipe e do cliente com o produto final.
Divirtam‑se!
INTRODUÇÃO
Quando se fala em qualidade de software, a primeira ideia que vem à cabeça é: “Que coisa chata”, ou 
“Isso não adianta nada”. Em parte, isso é verdade, pois produzir qualquer coisa com qualidade demanda 
mais cuidado, mais esmero, mais atenção e mais disciplina, logo, não é uma atividade corriqueira que 
traz prazere de que ele venha a 
falhar em determinado momento.
Complexidade ciclomática
V(G) = (E – N) + 2
V(G) = (8 – 7) + 2 => V(G) = 3
Ou
V(G) = P + 1
V(G) = 2 + 1 => V(G) = 3
3
4 5
6
1
2
7
Figura 47 – Cálculo da complexidade ciclomática
Atualmente, com a programação orientada a objetos, os programas estão muito reduzidos 
em linhas de código, limitando‑se a métodos de uma classe. Com esse conceito, a complexidade 
120
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade III
ciclomática tende a ser baixa, facilitando os testes caixa‑branca, mas aumentando a complexidade 
dos testes caixa‑preta.
A Tabela 6 mostra a classificação de riscos de acordo com a complexidade ciclomática de um 
programa.
Tabela 6 – Classificação de riscos de acordo com a V(G)
Complexidade Avaliação de risco
1 – 10 Programa simples, sem risco 
11 – 20 Programa médio, risco moderado 
21 – 50 Programa complexo, alto risco 
> 50 Programa não testável 
Fonte: McCabe (1976).
6.4.2.5 Definindo os casos de testes caixa‑branca
Elaborado o grafo de controle e calculados a V(G) e o número de caminhos independentes, resta 
determinar os casos de testes necessários para verificar o código do programa em questão. Para isso, 
seguem‑se os quatro passos básicos:
1. Desenhar o grafo de fluxo correspondente ao programa (Figura 48).
início
 leio nro
 enquanto nro ≠ 0
 se nro > 0
 raiz = raiz‑quadrada(nro)
 escreva raiz
 senão
 escreva mensagem de erro
 fim‑se
 leia nro
 fim‑enquanto
fim
1
4
5
6
2
7
3
3
4 5
6
1
2
7
Figura 48 – Passo 1: desenhar o grafo de controle
121
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
2. Determinar a V(G) do grafo de fluxo correspondente:
V(G) = (E – N) + 2 ou V(G) = P + 1
V(G) = (8 – 7) + 2 => V(G) = 3 V(G) = 2 + 1 => V(G) = 3
3. Determinar os caminhos independentes. São eles:
1‑2‑7
1‑2‑3‑4‑6‑2
1‑2‑3‑5‑6‑2
4. Preparar os casos de teste para executar cada caminho:
Tabela 7 – Preparação dos casos de teste
Caminho Dado de entrada Resultado esperado
1‑2‑7 Zero Sai do programa sem executar nada 
1‑2‑3‑4‑6‑2 2 e 4 Calcula a raiz quadrada de 2 e depois de 4 
1‑2‑3‑5‑6‑2 4 e–20 Calcula a raiz quadrada de 4 e escreve mensagem de erro para–20 
O teste estrutural conforme apresentado aqui é pouco utilizado no mercado, em função da falta de 
conhecimento da técnica pela maioria dos desenvolvedores e, principalmente, pela falta de processo de 
qualidade voltado para o código produzido.
6.4.3 Técnica de teste funcional ou caixa‑preta
Os testes funcionais são os mais amplamente utilizados no desenvolvimento de software. Focadas 
nas necessidades ditadas pelos usuários e transformadas em requisitos pelos analistas de sistemas, as 
situações de testes criadas devem atestar que o software faz exatamente o que foi solicitado e que 
funciona corretamente.
A única desvantagem para os testes funcionais é que não é possível garantir que a especificação 
esteja 100% correta, mesmo com as validações dos usuários. Quando isso ocorre, podem aparecer 
surpresas durante os testes de aceite realizados pelos usuários, em que surgem novos comportamentos 
esperados ou novas funcionalidades não previstas pela aplicação e que são necessárias para esta. Em tal 
situação, essas novas necessidades também não são mapeadas pelos testes funcionais.
Para garantir a elaboração de bons testes funcionais, devem ser obtidos, no mínimo, os seguintes 
artefatos validados pelos usuários:
122
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade III
• a especificação dos requisitos, como uma especificação de casos de uso ou um documento de 
requisitos;
• um protótipo de telas visual com as respectivas especificações detalhadas de seu comportamento.
De posse desses artefatos, a equipe de testes pode iniciar suas atividades de planejamento, preparação 
e execução dos testes e definir o oráculo de testes, ou seja, constituir a referência para dizer se os 
resultados produzidos pela aplicação estão corretos ou não. A Figura 49 apresenta um processo de 
elaboração dos testes funcionais.
 Planejamento
 – Determinar o que será testado
Projeto
– Identicar os casos de teste
Implementação
– Elaborar o roteiro de testes
Execução
– Executar o roteiro de testes
Verificação
– Gerar as evidências de testes
Figura 49 – Passos para a elaboração dos testes funcionais
Para a elaboração dos testes funcionais, duas atividades devem ser desenvolvidas e devidamente 
validadas com os usuários do sistema:
• especificar os casos de testes ou cenários de testes;
• elaborar o roteiro de testes.
6.4.3.1 Casos de testes ou cenários de testes
Um caso de teste ou um cenário de teste é uma situação que o sistema apresenta para a qual, dada 
uma informação de entrada, será gerada uma saída esperada pelo usuário. Por exemplo, você quer testar 
um software para uma calculadora simples com quatro operações. Todas as operações precisam ser 
testadas, e, para cada uma, um conjunto de valores precisa ser verificado para constatar se está fazendo 
o cálculo correto. Nessa situação, os casos de testes para operação de soma seriam:
123
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
• 2 + 2 = 4 – soma de dois números inteiros positivos.
• ‑2 + 2 = 0 – soma de número inteiro positivo e negativo.
• ‑2 – 2 =–4 – soma de dois números.
• 2 + 0,5 = 2,5 – soma de um número inteiro com decimal positivo.
• 2 +–0,5 = 1,5 – soma de número inteiro com decimal negativo.
• ‑ 2 +–0,5 =–2,5 – soma de número inteiro negativo com decimal positivo.
E assim sucessivamente até que todas as situações possíveis possam ser verificadas e validadas com 
as combinações envolvendo dois números e com aquelas envolvendo três números, quando todas as 
possíveis operações estiverem dentro da chamada cobertura dos testes. Quanto maior a cobertura dos 
testes, melhores os resultados da qualidade.
Outro exemplo, agora relacionado a uma aplicação transacional: imagine que você queira testar o 
cadastro de um cliente para uma locadora de games (o sistema deve incluir, alterar, excluir e consultar 
clientes). As regras informadas pelos usuários dizem que o CPF deve ser válido, o endereço deve ser 
obtido por meio do CEP e o cliente não pode possuir pendências de dívidas no órgão XPTO. Para a 
situação descrita, os seguintes casos de testes devem ser identificados:
• incluir cliente com sucesso;
• alterar cliente com sucesso;
• excluir cliente com sucesso;
• consultar cliente com sucesso;
• consultar cliente por CPF inexistente;
• incluir cliente com CPF inválido;
• alterar cliente com CPF inválido;
• incluir cliente com CEP inválido;
• alterar cliente com CEP inválido;
• incluir cliente com pendência no órgão XPTO.
124
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade III
Contudo, de onde vamos obter as informações para criar esses casos de testes? Normalmente, 
usam‑se a história do cenário, como descrito nos exemplos, a especificação de requisitos do sistema, 
a especificação de casos de uso e o protótipo de telas. A partir desses artefatos, identificam‑se os 
cenários de sucesso, o que significa realizar os testes sem erros, e as diversas situações de exceção que 
podem ocorrer durante o uso da aplicação, conforme o exemplo do cadastro de cliente e os cenários 
de CPF inválido, CEP inválido e pendência no órgão. Vale ressaltar que o objetivo dos casos de testes é 
identificar e criar cenários de teste relacionados às regras de negócio da aplicação.
 Lembrete
Se utilizar a especificação de casos de uso para criação dos casos de 
testes, o cenário de sucesso será o fluxo básico, e os cenários de insucesso 
serão os fluxos alternativos. Além disso, criar casos de testes para validar as 
precondições de cada caso de uso.
A elaboração dos casos de testespode ser feita pela equipe de testes de forma independente, e esses 
devem ser claros e objetivos. Após a elaboração da lista de casos de testes, essa precisa ser avaliada e 
validada pelos usuários do sistema para se ter a maior cobertura possível das situações de testes.
Com esses casos de testes prontos, pode‑se avançar para a elaboração do roteiro de testes.
6.4.3.2 Roteiro de testes
O roteiro de testes é uma descrição detalhada do passo a passo para a execução do sistema, a fim de 
verificar cada caso de teste identificado na fase anterior. Para cada caso de teste deve haver um roteiro 
contendo as seguintes informações:
• nome do caso de testes;
• procedimento inicial para determinar onde começa o teste;
• descrição detalhada contendo:
— passos para a execução;
— dados de entrada;
— resultado esperado;
— situação (sucesso ou não);
— data da realização;
125
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
— usuário que realizou o teste.
• evidência de realização do teste.
Observe que nos dois exemplos são informados os dados de entrada para que a operação seja 
verificada por meio do dado de saída. O que são esses dados de entrada e o resultado esperado?
• Procedimento inicial: descreve detalhadamente as atividades que precisam ser feitas antes de 
iniciar a execução dos testes.
• Dado de entrada: é a informação que deve ser inserida no sistema para satisfazer o passo descrito 
e gerar a saída esperada.
• Resultado esperado: é o dado de saída gerado pelo sistema após a execução do passo e que serve 
de avaliação para indicar o sucesso da realização do passo.
• Evidência de teste: é a informação que pode mostrar ao usuário que o caso de teste foi realmente 
executado. Pode ser uma “foto” da tela, um arquivo, dentre outros.
Ao elaborar o roteiro de testes, deve‑se observar a integração do roteiro com a tela associada à 
funcionalidade e ao uso cotidiano pelos usuários para que sua execução seja intuitiva e objetiva. Os 
passos devem ser descritos com detalhes suficientes para que não causem dúvidas ao testador e este 
possa fazer a análise correta do resultado do teste. Além disso, é importante que os casos de testes 
tenham poucos passos, para serem de fácil compreensão.
O roteiro, assim como as especificações, não é um documento estático do projeto. As evoluções 
e mudanças que ocorrem durante o desenvolvimento devem ser informadas à equipe de testes para 
a manutenção dos roteiros de testes alinhados com as especificações de requisitos e para evitar 
divergências e conflitos internos.
As informações descritas sobre a situação em que o passo se encontra (sucesso ou insucesso), a data 
do teste, o usuário que o realizou e a evidência de testes são atualizados quando da execução efetiva do 
roteiro de teste, não fazendo parte da elaboração desse roteiro.
A Tabela 8 ilustra o plano de um roteiro de testes para o caso de teste Consultar cliente com sucesso 
descrito no exemplo.
126
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade III
Tabela 8 – Exemplo de um roteiro de testes
Caso de teste: consultar cliente com sucesso 
Procedimento inicial: acessar a URL como usuário administrador, acessar o menu Cadastros, 
acessar a opção Cliente e clicar em Consultar 
ID Passo para execução Dado de entrada Resultado esperado
1 Sistema exibe tela para pesquisa 
por nome ou CPF – Dados exibidos: campos, nome e CPF
2 Usuário informa CPF válido e clica 
em Buscar 111.111.111‑11
Sistema exibe dados do cliente: nome: xxxx, 
endereço: xxxxx, cidade: xxxx, estado: xx e país: 
xxxxx 
3 Usuário clica em Nova Busca – Tela é limpa, e retorna a tela de pesquisa
Durante a execução do roteiro de testes, os defeitos podem e devem ser encontrados na aplicação. 
Esses defeitos precisam ser registrados e controlados pela equipe de testes e, após o término do ciclo 
de testes, a equipe de desenvolvimento analisa e verifica se os apontamentos são procedentes. Em caso 
afirmativo, faz as correções e encaminha a aplicação para novo ciclo de testes. Esse ciclo se repete até 
que o roteiro de testes esteja 100% executado, e os resultados, corretos.
 Saiba mais
São boas ferramentas para gerenciamento dos defeitos encontrados 
durante os testes funcionais, o Mantis – e o 
Jira – .
6.4.3.3 Testes funcionais de interface
Além dos casos de testes relacionados às regras de negócio abordadas até aqui, existem os casos de 
testes relativos ao comportamento técnico das telas ou interfaces. Esses casos de testes são importantes 
para garantir que a interface faça as verificações necessárias para tornar o software mais robusto e 
confiável com os dados de entrada.
Esses casos de testes devem ser identificados a partir da própria interface ou da especificação 
de interface gerada para a aplicação e devem ser executados desde a fase dos testes de unidade até 
os testes de sistema. A participação dos usuários na definição desses testes é essencial para evitar 
solicitações de mudanças na interface no momento dos testes de aceite, e a realização desses testes 
pelos desenvolvedores reduz substancialmente os apontamentos de defeitos nos testes de sistema.
Os principais casos de testes de interface estão relacionados a:
• reconhecer os atributos de cada campo;
• identificar e obter as regras de validação de cada campo;
127
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
• validar a navegação;
• validar as mensagens que serão exibidas.
Para criar os casos de testes de interface, obedeça aos seguintes passos:
• identifique os campos e componentes da interface;
• para cada campo identificado:
— coloque o nome, o tipo do campo, o tamanho, o formato, as validações e se é obrigatório ou 
não.
• identifique os eventos que podem ser disparados pelos componentes (links, botões, caixas de 
texto, listas, dentre outros);
• valide as ações que serão realizadas para cada evento;
• defina e valide as mensagens de advertência criadas.
Por exemplo, para o cenário de testes de Consultar cliente com sucesso exposto anteriormente, 
temos a seguinte especificação da interface:
Tabela 9 – Especificações da interface
Elemento Descrição Tipo/tamanho Formato Validação
Campo Nome Alfa (40) Alinhado à esquerda Pode estar em branco
Campo CPF Numérico (9) 111.111.111‑11 CPF deve ser válido
Campo Endereço Alfa (40) Alinhado à esquerda –
Campo Cidade Alfa (20) Alinhado à esquerda –
Campo Estado Alfa (2) – UFs válidas do Brasil
Campo País Alfa (10) Fixo “Brasil”
Botão Buscar ‑ – Obter dados
Botão Nova Busca – – Limpa tela
Botão Voltar – – Retorna ao menu
Temos também a seguinte especificação de mensagem:
Quadro 20 – Especificações da mensagem a ser exibida
Elemento Descrição Situação Mensagem a ser exibida
Botão Buscar Cliente não encontrado “Cliente não encontrado”
128
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade III
Com essa especificação criada para cada interface do software em desenvolvimento, os testes 
funcionais devem ser realizados seguindo as abordagens de testes a seguir:
• ortografia: verificar a escrita correta de todo o texto da tela, inclusive das mensagens;
• tamanho dos campos: verificar se os campos permitem a entrada da quantidade de dados até o 
limite especificado;
• formato: validar se a máscara do campo corresponde ao formato da especificação, por exemplo, o 
campo valor dever ser apresentado na forma 9,999,999.99, ou o CPF, no formato 111.111.111‑11;
• campos obrigatórios: validar se os campos com indicação de obrigatoriedade estão sendo 
bloqueados;
• caracteres especiais: testar se a aplicação permite o preenchimento dos campos com &, *,%, @, 
:, ;, dentre outros;
• valores de domínio: testar se as regras de validação estão funcionando conforme especificado e 
se os valoresmínimo e máximo de cada campo estão sendo respeitados;
• ordem alfabética: testar se os objetos do tipo lista e as caixas de texto estão em ordem alfabética;
• navegação: acionar todos os links e botões para verificar o correto funcionamento, de acordo com 
a especificação;
• massa de dados: testar a aplicação em relação à massa de dados para verificar o comportamento 
do software quanto a tabela vazia, tabela indisponível, falha de comunicação com o banco de 
dados, tabela carregada com volume similar à produção, consultas que não retornam dados, 
dentre outras.
Podemos observar neste tópico que os testes funcionais são variados e amplos e não são executados 
de forma trivial e não planejada. Sem dúvida alguma, a correta execução dos testes funcionais garante 
a qualidade do software, mas exige esforço, dedicação e comprometimento de todos os envolvidos e 
não apenas da equipe de testes.
6.5 Testes em processos ágeis
Antes de abordar os testes em processos ágeis, é importante entender quando surgiu e o que é um 
processo ágil. É importante salientar que ágil não quer dizer “desenvolver rápido e de qualquer jeito”, 
mas sim desenvolver um software com foco no produto, criando o que é estritamente necessário para o 
entendimento da equipe e do usuário e utilizando técnicas e ferramentas para auxiliar nesse processo.
Os processos ágeis começaram a tomar forma a partir de 2001, quando Kent Beck e outros 
pesquisadores do desenvolvimento de software se reuniram para discutir alternativas aos problemas 
129
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
mais comuns em um processo de desenvolvimento tradicional e propuseram quatro pilares básicos para 
o desenvolvimento ágil:
• foco nas pessoas e não em processos;
• software funcionando, em vez de documentação abrangente;
• colaboração do cliente, em vez de negociação de contratos;
• resposta às modificações, em vez de seguir um plano.
À primeira vista, esses pilares parecem direcionar para o caos, e parece que tudo o que foi pesquisado 
até à época não tem fundamento, mas não é bem assim.
O que esses pilares querem dizer é que a equipe de projeto é uma só; gerente, desenvolvedores, 
clientes, usuários, todos estão juntos para atingir um objetivo comum, que é o software funcionando. De 
nada adianta criar documentos infinitos que não são utilizados agora nem depois do software pronto. 
Cria‑se o que é necessário para o entendimento e a comunicação da equipe, e as temidas mudanças de 
escopo existem e são bem‑vindas; não haverá por que bloqueá‑las ou deixá‑las para depois, se forem 
essenciais para o cliente. Em outras palavras, para manter tudo isso orquestrado, um processo ágil é até 
mais organizado do que um processo tradicional.
Nessa mesma época, além desses pilares, foi criado e assinado pela equipe reunida e por Kent Beck 
o chamado Manifesto Ágil, o qual descreve doze princípios que, se seguidos, tornam o desenvolvimento 
do software mais rápido que a forma tradicional, com mais qualidade e satisfazendo às necessidades dos 
usuários. Esses doze princípios estão listados a seguir, em ordem de importância para o processo ágil:
• clientes, usuários e desenvolvedores trabalham juntos;
• O levantamento e a validação dos requisitos são feitos face a face;
• entregas contínuas de software funcionando, não só ao final;
• satisfação do cliente por meio das entregas contínuas;
• a evolução do projeto é feita por meio de funcionalidades entregues;
• mudanças de requisitos são bem‑vindas;
• equipes autogerenciadas: todos sabem o que fazer;
• equipes multidisciplinares e capacitadas tecnicamente;
• faça o essencial, a simplicidade é o caminho;
130
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade III
• equipe motivada e comprometida com o processo e o produto;
• ritmo constante de desenvolvimento, não “picos” de entrega;
• a equipe busca tornar‑se mais efetiva sempre; melhoria contínua.
Embora sejam princípios de um processo ágil, nada impede que esses fundamentos sejam utilizados 
como parte de qualquer processo de desenvolvimento tradicional, com o objetivo de melhorar os 
resultados e aumentar a qualidade do software.
 Saiba mais
Mais conceitos e informações sobre os doze princípios ágeis podem ser 
encontrados em: .
6.5.1 Testes ágeis
Contudo, o que tudo isso tem a ver com o processo de testes ágeis? A relação está no fato de que 
muda radicalmente a forma de atuação e interação do pessoal de testes com os desenvolvedores e com 
os usuários. Como visto no tópico anterior, o pessoal de testes, no processo tradicional, é separado da 
equipe de desenvolvimento do software; as interações ocorrem de forma pontual no ciclo de vida e em 
maior grau quando a aplicação está pronta e precisa ser realizado o teste de sistema, com o objetivo de 
encontrar e corrigir erros.
No processo ágil, o teste é um compromisso e uma responsabilidade de toda a equipe. Todos devem 
possuir habilidade para testar e todos trabalham em conjunto, com interação constante durante todo 
o ciclo de desenvolvimento do software. Os testadores atuam de forma que entendam o processo de 
negócio, criando os casos de testes e participando efetivamente do projeto desde a fase de requisitos, 
passando pelos testes de unidade, testes integrados, testes de sistema e testes de aceitação. O objetivo nos 
testes ágeis é colaborar com a solução dos defeitos e não apenas apontá‑los, por meio da identificação 
das causas desses defeitos, para que não voltem a acontecer.
No processo ágil, não há uma fase de testes específica. Os testes são realizados à medida que a 
codificação termina, e o feedback é imediato, ou seja, o defeito é apontado e corrigido na hora. Além 
disso, os testadores devem acompanhar a evolução das entregas de software com foco na qualidade e 
automatizar os testes, sempre que possível.
Em alguns casos, as equipes de testes podem atuar de forma separada das equipes de projeto que 
utilizam um processo ágil. Essas situações podem estar relacionadas ao desenvolvimento de sistemas 
grandes e complexos, para aumentar a automação de testes, pela necessidade de fazer testes finais de 
uma versão antes de entrar em produção ou para que a equipe de testes possa ser utilizada em mais de 
um projeto.
131
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
6.5.2 Roteiro de testes ágeis
A elaboração do roteiro de testes para processos ágeis começa pela definição de quais tipos de testes 
devem ser executados, se devem ser automatizados ou manuais e os responsáveis por cada um. Para os 
testes automatizados, são definidas as ferramentas que devem ser utilizadas.
Definido o conjunto de testes necessários, a equipe elabora, a partir das histórias e do protótipo, 
os casos para os testes funcionais e para os requisitos não funcionais. A identificação dos casos de 
testes, obrigatoriamente, deve ser realizada pela equipe e pelos usuários, para obter a maior cobertura 
possível, não sendo necessária a elaboração do roteiro com o passo a passo, em razão de os testes serem 
realizados pela própria equipe envolvida no projeto.
Com o roteiro elaborado, os testes são executados com uma visão colaborativa entre desenvolvedores 
e usuários até que a aplicação esteja pronta, ou seja, até que os defeitos tenham sido removidos e a 
aplicação funcione de acordo com as expectativas dos usuários.
6.5.3 Processo de testes ágeis
O principal processo de testes ágil está baseado nos quadrantes de testes definidos por Crispin e 
Gregory (2009), que agrupam os testes em visões e auxiliam na definição do que deve ser feito em cada 
nível de testes dentro do ciclo de desenvolvimento de software.
A Figura 50 apresenta esses quadrantes, cujas características são descritas a seguir.
Testes integrados
Testes funcionais
Protótipos
Simulação
Testes de unidade
Testes de componentesTestes de sistema
Testes de aceitação
Usabilidade
Testes de desempenho
Testes de carga
Testes de segurança
Testes ágeis
Foco no negócio
Suporte à equipe
Foco no produto
Foco técnico
Figura 50 – Quadrantes de testes ágeis
6.5.3.1 Quadrante 1
São os testes focados no código produzido. Devem verificar a aderência aos padrões de codificação, 
bem como as boas práticas de programação e as de testes caixa‑branca. O papel dos testes nesse 
132
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade III
quadrante é apoiar os desenvolvedores para encontrar e corrigir os defeitos. Os testes de unidade e de 
componente são a menor unidade testável do software e devem abranger toda a ligação da arquitetura 
da aplicação, como camada visual, camada de negócio, acesso ao banco de dados, integração com 
outros sistemas, comunicação, dentre outros. Quanto mais automatizados, mas rápidos e efetivos. 
Podem utilizar o Test Driven Development (TDD) para auxiliar na elaboração.
6.5.3.2 Quadrante 2
São os testes focados no negócio. O objetivo é garantir que as regras de negócio especificadas tenham 
sido construídas e funcionem corretamente. Envolve os testes de integração, em que essas regras são 
verificadas por meio dos casos de testes criados, e os testes são executados pelo desenvolvedor, pelo 
testador e pelos usuários. O papel dos testes nesse quadrante é melhorar o alinhamento a respeito 
do negócio entre os desenvolvedores e os usuários, por meio de testes simulando situações reais de 
utilização da aplicação. Aqui os testes podem ser parcialmente automatizados, mas a maior parte é 
manual. Também podem utilizar o Behavior Driven Development (BDD) para auxiliar na elaboração dos 
testes seguintes, uma estrutura de linguagem natural que facilita o entendimento de todos e funciona 
como um caso de teste dentro do processo ágil de desenvolvimento.
Para elaborar um bom BDD, o testador do processo ágil deve seguir esta estrutura básica para cada 
história descrita no cenário de testes considerado:
• Teste a ser executado:
— funcionalidade: ;
— como um ;
— eu quero ;
— de modo que .
• Caso de teste:
— cenário: ;
— dado ;
— quando ;
— então .
Por exemplo, para o cenário de testes do cadastro de clientes relativo à consulta de cliente com 
sucesso por CPF:
133
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
• Teste a ser executado:
— funcionalidade: consultar clientes;
— como um funcionário;
— eu quero consultar um cliente cadastrado com sucesso por CPF;
— de modo que eu possa garantir que a consulta está correta.
• Caso de teste:
— cenário: consultar cliente com sucesso por CPF;
— dado: ao selecionar a opção Buscar;
— quando: digitado o CPF 111.111.111‑11;
— então: deve listar nome, CPF e data de nascimento do cliente.
6.5.3.3 Quadrante 3
São os testes com foco no produto final da aplicação, os mais próximos dos testes realizados no 
processo tradicional. A ideia é criar situações nos produtos para permitir os testes de sistema e os 
testes de aceitação. Também são apoiados pelos casos de testes do roteiro elaborado, mas podem ser 
aleatórios. Esses testes simulam a visão do usuário final e são realizados após uma versão estar fechada 
para ser entregue ao usuário. Os testes desse quadrante devem ser executados em todo o sistema, 
principalmente, nas áreas mais cruciais para o negócio. Devem‑se avaliar a usabilidade do software e os 
testes de navegação para garantir que tudo esteja funcionando adequadamente, conforme o esperado 
pelos usuários.
O papel dos testes nessa etapa é ganhar a confiança do cliente e envolvê‑lo na entrega, conseguindo 
a sua avaliação prévia e conjunta a respeito da qualidade do software e, principalmente, corrigir defeitos 
que possam causar danos ao usuário quando em produção. Esses testes são manuais e devem ser 
realizados por pessoal experiente e com conhecimento do negócio.
6.5.3.4 Quadrante 4
São os testes com foco nos requisitos técnicos, ditos requisitos não funcionais. Abrangem os 
testes de carga, segurança, desempenho, recuperação, confiabilidade, dentre outros. Os padrões de 
qualidade esperados para esses testes precisam ser levantados, e sua execução é dependente do uso 
de ferramentas, pois não são executados de forma manual. O papel dos testes é apontar deficiências 
técnicas do produto, e requerem especialistas para sua execução. Para obter melhores resultados com 
esses testes, é preciso definir claramente a necessidade do tipo de teste, montar o ambiente adequado 
134
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade III
para simular as situações necessárias, criar a massa de testes para a replicação e definir as ferramentas 
que devem ser utilizadas.
6.5.4 Conceitos sobre Test Driven Development (TDD)
O TDD é uma técnica utilizada para a realização de testes unitários e de integração que começa pela 
identificação dos casos de teste. Em seguida, faz‑se a escrita do código necessário para atender ao caso 
de testes, e, se necessário, a refatoração do código para acomodar eventuais mudanças que possam 
ocorrer. É um método para construir software direcionado ao programador, com o objetivo de melhorar 
a qualidade do código produzido. Vem do conceito ágil da Extreme Programming de “testar primeiro que 
programar”. Basicamente, o processo TDD funciona como ilustrado na Figura 51.
Escreva um teste 
que vai falhar
Execute o
teste
Escreva 
o código para 
tratar a falha
Elimine 
redundâncias 
no código
Figura 51 – Processo TDD
Os principais benefícios que podemos obter com a utilização do TDD no processo de 
desenvolvimento são:
• melhorar a qualidade do código;
• garantir a criação dos testes unitários;
• permitir testes contínuos sempre que o programa for alterado.
135
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
 Saiba mais
Mais detalhes de como utilizar o TDD podem ser encontrados no livro:
BECK, K. TDD: desenvolvimento guiado por testes. São Paulo: 
Bookman, 2010.
6.5.5 Quando terminar os testes?
Um dos principais desafios é determinar quando os testes são suficientes para garantir que o software 
atende às necessidades dos usuários. A maior parte dos testes termina em virtude da pressão de tempo 
que os usuários impõem à equipe de desenvolvimento, muitas vezes, causando entregas desastrosas, em 
razão da falta de qualidade do produto final e também em virtude dos custos da realização de todos os 
testes necessários para garantir a qualidade. Como visto anteriormente, não são poucos e demandam 
tempo, dinheiro e especialistas no assunto.
Considerando um cenário em que essas duas variáveis não afetem o término dos testes, pode‑se 
dizer que os testes terminam quando:
• o número de defeitos está dentro de uma margem aceitável;
• a frequência em que os defeitos são encontrados é pequena;
• houver a garantia de que os testes‑caixa foram realizados;
• todos os casos de testes tiverem sido realizados com sucesso.
Enfim, determinar o fim dos testes não é uma tarefa isolada da equipe de desenvolvimento. Cabe 
uma decisão conjunta entre a equipe e o cliente para determinar se as condições atuais do software são 
aceitáveis e os riscos desse aceite para a operação.
 Resumo
Nesta unidade foram abordadas as principais técnicas de verificação e 
validação de um produto de software, com o objetivo de garantir e melhorar 
a qualidade do software em desenvolvimento.
Abordamos que as técnicas de verificação têm por objetivo avaliar 
os artefatos produzidos à medida que são construídos, visando reduzir o 
retrabalho em caso de ajustes e reduzir o impacto de corrigir o que já está 
pronto. Vimos que as atividadesde verificação podem ser reuniões técnicas 
136
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade III
formais ou não, revisão por pares ou inspeções e são essenciais para a 
garantia da qualidade de todos os artefatos produzidos durante o ciclo de 
desenvolvimento e não só ao seu final.
Aprendemos ainda que as técnicas de validação visam avaliar os 
artefatos produzidos contra uma especificação inicial que serve de 
referência para validar se o que foi produzido atende àquelas necessidades 
especificadas. Normalmente são utilizados quando o produto de software 
está pronto. As atividades de validação podem ser inspeções, sala limpa, 
testes caixa‑branca e testes caixa‑preta. Lembrando que a especificação 
inicial deve ser validada pelo usuário antes da utilização pela equipe do 
projeto, caso contrário poderá tornar‑se uma referência incorreta e não 
aceita pelos usuários, causando erros no processo de validação.
Vimos também que as revisões por pares ou passeios (walkthroughs) são 
a técnica mais simples para verificar a qualidade de um produto. Trata‑se 
de uma técnica essencial para atender a um princípio básico da qualidade, 
que é: “Quem faz não revisa”. Com a revisão por pares, os artefatos sofrem 
críticas em tempo de construção, permitindo a rápida correção de eventuais 
desvios encontrados. A revisão por pares pode ser formal ou informal, sendo 
esta última a mais utilizada pelas equipes de desenvolvimento. O objetivo é 
encontrar erros e defeitos nos artefatos.
Em seguida, abordamos que as revisões técnicas formais também são 
técnicas de verificação e envolvem cenários de planejamento e preparação 
antes de uma sessão de revisão. Envolvem pelo menos três participantes 
(autor, revisor e mediador), com o objetivo de avaliar os artefatos quanto 
ao formato (capítulo, título, subtítulo, ortografia etc.) e quanto ao 
conteúdo técnico do documento. Devem ser planejadas e organizadas com 
antecedência e não devem durar mais de duas horas.
Vimos também que a inspeção é uma técnica que pode ser usada tanto 
para a verificação como para a validação. Esta é a mais formal das reuniões 
de avaliação dos artefatos e envolve, pelo menos, cinco participantes: o 
autor, o inspetor, o leitor, o escritor e o moderador. Os artefatos que são 
objeto da inspeção e a especificação de referência devem ser enviados 
aos inspetores com antecedência, para a preparação da reunião. Todos os 
participantes têm o papel de inspetor e devem ser treinados e capacitados 
tecnicamente no assunto envolvido na inspeção. O processo de inspeção 
é iniciado pelo leitor, que faz a leitura do artefato por partes, para que os 
inspetores façam os questionamentos e apontamentos. O autor responde 
às questões, e o escritor registra as informações da inspeção. O moderador 
tem o papel de resolver conflitos entres as partes, e o checklist é um 
excelente apoio durante a sessão.
137
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
Abordamos que a técnica sala limpa tem origem no processo de 
produção de componentes eletrônicos, e sua fundamentação é matemática 
e estatística. O processo sala limpa é indicado para sistemas que podem 
trazer riscos a vidas humanas, como controle de aviões, trens, usinas, 
dentre outros, e sua especificação deve ser precisa e sem ambiguidades, 
com formato matemático.
Aprendemos que a verificação se dá por meio de inspeções rigorosas, 
provas matemáticas e testes estatísticos para determinar a confiabilidade 
do sistema e que isso a torna diferente de outras técnicas. Porém, seu uso 
é bastante limitado, em razão dos custos, da capacitação técnica exigida, 
do fundamento matemático, que afasta os desenvolvedores, e da falta 
de maturidade das empresas de desenvolvimento de software para uma 
utilização efetiva.
Vimos ainda que, das técnicas de validação, a mais amplamente 
utilizada são os testes de software que envolvem a execução do código 
da aplicação para que possam ser realizados. A execução desses testes tem 
o mesmo fundamento: encontrar defeitos no código quando comparado 
com a especificação de referência.
Abordamos que existem diversos tipos de testes, com abordagem 
funcional (usabilidade, caixa‑preta, dentre outros) e não funcional 
(desempenho, segurança, carga, configuração, confiabilidade, dentre outros), 
e ambos devem ser executados durante o processo de desenvolvimento do 
software. Além disso, existem os níveis de testes que começam com os 
testes unitários, com foco no código e realizados pelos desenvolvedores; os 
testes de integração, também realizados pelos desenvolvedores, mas com 
foco na verificação das regras de negócio; os testes de sistema, realizados 
pelos testadores e focados em validar o produto de software; e os testes 
de aceitação, realizados pelos usuários do sistema e acompanhados pelos 
testadores, com o objetivo de dar o aceite final ao software construído.
Vimos que o processo de testes mais conhecido no mercado é o Modelo 
V, baseado no processo de desenvolvimento, desde o seu início até a 
entrega final ao usuário. Este considera a equipe de testes separada do time 
de construção. Preconiza que a atividade de testes deva começar junto 
com a fase de levantamento de requisitos, para que os analistas de testes 
tenham conhecimento do negócio e possam gerar bons casos de testes, 
a partir das especificações e do protótipo de telas. A partir dos casos de 
teste são elaborados os roteiros de testes, que devem ser executados pelas 
equipes de testes durante os testes de sistema e de aceitação. Esses testes 
são chamados funcionais ou caixa‑preta.
138
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade III
Aprendemos ainda que os testes estruturais ou caixa‑branca são 
aqueles focados no código‑fonte produzido e têm por objetivo garantir 
que todas as linhas de código sejam executadas pelo menos uma vez. 
Requerem que o código esteja pronto para serem executados. Utilizam uma 
técnica chamada de grafos de controle, que identifica os diversos caminhos 
independentes que o programa pode percorrer e, de posse desses caminhos, 
cria as massas de testes necessárias para garantir a aderência do código 
às situações previstas nos caminhos mapeados. São chamados de testes 
unitários e de testes de integração, caracterizando o ponto de partida para 
a qualidade de um software. Porém, são muito pouco utilizados, em razão 
das constantes pressões de prazos nos projetos e da resistência natural dos 
desenvolvedores a executar testes mais estruturados nessa fase.
Vimos também os testes utilizados em processos ágeis, cujo objetivo 
principal é fazer mais rápido e com alta qualidade, com a participação de 
todos: desenvolvedores, usuários e clientes, para a entrega de um software 
que atenda às expectativas de todos. Os testes ágeis têm os mesmos níveis 
daqueles do processo tradicional e são divididos em quatro quadrantes: 
testes para suporte ao desenvolvedor, testes com foco no negócio, testes 
com foco no produto e testes com foco na tecnologia. Porém, diferem 
daqueles do processo tradicional pela participação efetiva do usuário na 
criação e na validação dos testes, utilizando o conceito “meu sucesso, 
seu sucesso”, e na automação dos testes de unidade e de integração que 
proporciona excelentes resultados na qualidade final do produto.
Aprendemos que no processo ágil não há uma fase de testes específica, 
e a equipe não é separada do time de desenvolvimento. Os testes são 
realizados à medida que a codificação termina, e o feedback é imediato, 
ou seja, o defeito é apontado e corrigido na hora. Além disso, os testadores 
devem acompanhar a evolução das entregas de software, realizar os testes 
de aceitação junto com os usuários e garantir a qualidade dos testes 
técnicos, tais como os de carga, desempenho, segurança, dentre outros.
Abordamos as principais técnicas de testes ágeis. Um deles é o TestDriven 
Development (TDD), cujo objetivo é apoiar os testes unitários do desenvolvedor 
e facilitar a automação desses testes para facilitar mudanças posteriores. Sua 
estrutura básica é especificar um teste, construir o código, executar o teste 
e melhorar o código por meio de refactoring. O outro teste é o Behavior 
Driven Development (BDD), cujo objetivo é apoiar o desenvolvedor nos testes 
integrados com foco nas regras de negócio por meio da elaboração de casos de 
testes, que podem ser executados na fase de testes de sistema.
Finalmente, aprendemos que o processo de teste é a técnica mais utilizada 
no mercado para verificação e validação da qualidade, porém é sabido que não 
139
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
podemos identificar todos os defeitos existentes somente com a realização de 
testes. É necessário um processo preventivo de revisão, inspeção, execução de 
checklists e definição de padrões e boas práticas de programação para que a 
qualidade seja parte integrante do processo de desenvolvimento do software 
e não requerer que, com a realização dos testes, se atinja a qualidade esperada 
somente ao final do processo de desenvolvimento.
 Exercícios
Questão 1. As técnicas de verificação e validação são essenciais para manter a qualidade no processo 
de desenvolvimento de software e são chamadas popularmente de técnicas de V&V. Existem diversas 
técnicas, no entanto, das estudadas apenas uma utiliza como metodologia a revisão técnica informal 
denominada revisão por pares. O revisor pode ser um técnico, um cliente ou uma pessoa externa ao 
projeto, porém com amplo domínio no assunto. 
Das alternativas apresentadas a seguir, assinale qual é a técnica informal que se ajusta à metodologia 
de revisão por pares.
A) Passeio (walkthrough).
B) Inspeção.
C) Sala limpa.
D) Processo de especificação.
E) RTF.
Resposta correta: alternativa A.
Análise das alternativas
A) Alternativa correta.
Justificativa: é uma técnica informal que utiliza revisão por pares, mas é possível ter até três 
participantes: autor, revisor e moderador. É uma técnica muito mais simples de executar quando 
comparada ao RTF. O alto grau de informalidade faz com que seja uma técnica bastante aplicada e 
facilmente aceita pela maioria das equipes de projeto.
B) Alternativa incorreta.
Justificativa: não é uma técnica informal, e sim formal, por meio da qual os envolvidos examinam 
os artefatos produzidos e os confrontam com uma especificação inicial com o objetivo de encontrar 
incoerências, inconsistências e possíveis erros.
140
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade III
C) Alternativa incorreta. 
Justificativa: a técnica de sala limpa é baseada em especificações formais matemáticas e destinada 
ao desenvolvimento de software com alto nível de confiabilidade.
D) Alternativa incorreta. 
Justificativa: não é uma técnica informal ou formal, é apenas um dos quatro processos nos quais 
está estruturada a técnica de sala limpa.
E) Alternativa incorreta.
Justificativa: não é uma técnica informal. O RTF é uma técnica de verificação formal.
Questão 2. A atividade de teste de software sempre foi considerada como um gasto de tempo 
desnecessário, uma atividade de segunda classe, uma vez que a programação é a atividade principal no 
desenvolvimento de software. Atualmente são muitos os desenvolvedores que ainda confundem o processo 
de testes com o processo de depuração de um programa. Considerando o exposto, leia as afirmativas a seguir:
I – Os testes são processos de depuração, mais conhecida como debug. Trata‑se de um processo 
de busca de erros de forma não estruturada durante a execução de um programa, através de uma 
ferramenta de apoio ao desenvolvimento: uma vez encontrado, o erro deve ser corrigido.
II – Os testes são um processo que ocorre normalmente durante a atividade de programação e antes 
da execução da segunda etapa de testes propriamente dita.
III – A execução de testes é uma busca estruturada para encontrar erros em um programa pronto.
IV – Os testes devem ser realizados pelos desenvolvedores – por meio dos testes unitários; pelos 
testadores – por meio dos testes integrados guiados por roteiro de testes elaborados a partir da 
especificação inicial; e pelos usuários – por meio dos testes de aceitação, que verificam se o software 
atende às suas necessidades.
É correto apenas o que se destaca em:
A) I, II.
B) I, II, III, IV.
C) I, III.
D) III, IV.
E) I, IV.
Resposta desta questão na plataforma.
141
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
Unidade IV
7 MANUTENÇÃO DE SOFTWARE
7.1 Definição de manutenção de software
As manutenções de software são correções, evoluções ou adaptações técnicas que são realizadas no 
software já construído e em produção, para adequá‑lo às mudanças de requisitos dos usuários, às novas 
funcionalidades solicitadas, para a atualização de regras de negócio e para a adaptação do software ao 
mercado ou às necessidades de atualizações tecnológicas que são demandadas durante o ciclo de vida 
de um software. Este é uma entidade viva, ou seja, precisa sofrer alterações e evoluções para continuar 
a ser utilizado de maneira adequada pelos usuários.
As manutenções de software ocorrem não apenas para corrigir defeitos em um software; são bem 
mais amplas que isso. Surgem em razão de diversos fatores, mas se destacam pelas mudanças e alterações 
relacionadas a:
• nova ordem estratégica na organização;
• demandas para acompanhar os concorrentes;
• adequação para atender a novas leis e regras;
• novas características sugeridas por clientes;
• evoluções da tecnologia.
142
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade IV
Conceitos 
gerais sobre 
manutenção 
de software 
para alinhar 
nomenclatura
Plano de 
manutenção
Análise de 
recursos
Processo de 
execução
(ISO/IEC 12207)
Medições e 
métricas
Documentação 
e registro
Definição do 
processo
Análise da 
mudança
Implementação 
da mudança
Aceite e revisão 
da mudança
Migração
Retirada da 
produção
Conceitos de 
manutenção
Processos de 
manutenção
Execução da 
manutenção
Estratégia de 
manutenção
Figura 52 – Estrutura da norma ISO/IEC 14764
Segundo Boehm (1988), a fase de manutenção é a mais problemática do ciclo de vida de um software 
e representa mais de 60% de todo o esforço em Tecnologia da Informação para uma organização. A 
maioria desses problemas está relacionada à maneira pela qual o software foi construído, normalmente, 
sem documentação ou documentação desatualizada, sem padrões de codificação, sem boas práticas 
de programação e, muitas vezes, sem controle adequado das evoluções, gerando um grande esforço 
das equipes para encontrar e corrigir defeitos ou para criar novas funcionalidades, fazendo a atividade 
de manutenção ser evitada pela maioria dos desenvolvedores. Com isso, acaba ficando nas mãos de 
desenvolvedores menos experientes, agravando o problema.
A Norma ISO/IEC 12207, vista na unidade I, descreve um conjunto de atividades para a realização 
da manutenção de um software, apresentadas como um processo fundamental da área de Engenharia, 
mas a norma ISO/IEC 14764 (2006), que é apresentada neste tópico e cuja estrutura está representada 
na Figura 52, é específica para descrever o ciclo de manutenção do software, definindo os conceitos 
envolvidos em manutenção e estabelecendo um processo claro para tratar e apoiar os desenvolvedores 
nessa complexa etapa do ciclo de um software.
 Saiba mais
Detalhes sobre a norma ISO/IEC 14764 podem ser obtidos em: .
7.1.1 Conceituação sobre manutenção de software
A Norma ISO/IEC 14764 (2006) considera as seguintes definições para a unificação da terminologia 
utilizada no contexto de manutenção de software:
143
Re
vi
sã
o:
 Ju
lia
na
 -D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
• manutenção: modificação de um produto de software após a entrega para corrigir defeitos, 
melhorar o desempenho ou outros atributos, para adaptar o produto a um ambiente de mudança, 
incluir novas funcionalidades ou recursos não previstos anteriormente;
• evolução: a evolução de software que gera uma nova versão do produto com um conjunto 
relevante de alterações solicitadas após a colocação do software em produção;
• alteração: mudanças realizadas no código do software; engloba as correções de defeitos e os 
novos requisitos propostos pelo usuário;
• melhoramento: mudança realizada no software com o objetivo de melhorar o desempenho, a 
segurança ou adaptá‑lo a novos ambientes;
• linha de base: uma versão aprovada formalmente pelo cliente em um determinado momento do 
ciclo de vida do software;
• pedido de mudança: termo utilizado para caracterizar a solicitação de uma mudança; após a 
correção, pode ser classificado como uma correção ou uma melhoria, conforme ilustrado na 
Figura 53;
• plano de manutenção: documento que descreve as práticas específicas, os recursos e as atividades 
relevantes para a manutenção; esse documento é elaborado pelo responsável pela manutenção;
• processo de manutenção: contém um conjunto de tarefas para a realização da manutenção; é 
disparado quando há um pedido de mudança para um produto de software.
7.1.2 Tipos de manutenção
Ainda segundo a norma ISO/IEC 14764, as manutenções são classificadas em quatro tipos distintos 
e ilustradas na Figura 53:
Pedido de 
mudança
Correção Melhoria
Manutenção 
adaptativa
Manutenção 
preventiva
Manutenção 
perfectiva
Manutenção 
corretiva
Figura 53 – Classificação de um pedido de mudança
• Manutenção corretiva: são as ações efetuadas para corrigir defeitos encontrados em um software 
em produção normalmente identificados pelos usuários finais. Na maioria dos casos, essas 
144
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade IV
manutenções possuem equipe dedicada, são atividades rotineiras para a solução de defeitos e a 
atuação é reativa e emergencial. Esse tipo de manutenção tem características de proatividade e é 
planejado.
• Manutenção perfectiva: são as ações de manutenção para incluir novas funcionalidades ou 
alterações que têm por objetivo satisfazer novas necessidades dos usuários. Surgem principalmente 
a partir da evolução do processo de negócio e para igualar ou superar concorrentes no mercado.
• Manutenção adaptativa: são manutenções feitas para adequar o software a novas tecnologias, 
metodologias, modelos de gestão ou à nova legislação. Muitas vezes são tratadas de forma não 
planejada e reativa.
• Manutenção preventiva: são manutenções proativas e planejadas para melhorar algum aspecto 
deficiente no software, como desempenho, segurança, defeitos ainda não identificados pelos 
usuários, usabilidade, dentre outros.
 Lembrete
A manutenção perfectiva é mais conhecida no mercado como 
manutenção evolutiva.
A classificação da manutenção em tipos permite o melhor direcionamento dos esforços e a alocação 
dos recursos humanos necessários para realizar as atividades de acordo com a demanda. De posse dessas 
informações, o plano de manutenção pode ser elaborado e aprovado pelos envolvidos, formalizando o 
processo de manutenção. Como pode ser observado na Figura 54, que apresenta a distribuição média 
dos esforços gastos por uma organização por tipo de manutenção, os esforços com as manutenções 
perfectivas ou evolutivas é bastante superior às manutenções corretivas e adaptativas.
 Observação
As manutenções perfectivas e adaptativas, normalmente, são tratadas 
como um projeto de software, e não como atividade rotineira.
145
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
Novas necessidades 
ou mudanças: 65%
Correção de 
defeitos: 17%
Adaptação à 
tecnologia: 
18%
Figura 54 – Distribuição de esforço por tipo de manutenção
7.2 Técnicas e padrões de manutenção de software
Um dos principais requisitos, já destacados por McCall, Richards e Walters (1977), para a manutenção 
de um software é a preocupação constante com a manutenibilidade deste, desde a sua concepção e 
durante todo o seu ciclo de vida.
A manutenibilidade indica quão fácil é fazer uma alteração, uma correção ou uma melhoria em um 
determinado software e é qualificada em função da preocupação com a clareza e as boas práticas da 
codificação, o uso de padrões no projeto e a boa documentação elaborada durante o desenvolvimento.
Embora o grau de manutenibilidade seja qualitativo, algumas métricas podem ser utilizadas pelas 
organizações visando avaliar a facilidade de manutenção e criar mecanismos para correção, tais como:
• Em quanto tempo um defeito é encontrado?
• Quanto tempo leva para corrigir o defeito?
• Quanto tempo é necessário para validar a correção do defeito?
• Quanto tempo decorre entre a identificação do defeito e a implantação da correção?
 Lembrete
Métricas quantitativas são criadas para que, a partir de uma avaliação 
inicial, sejam feitas medidas constantes a fim de que o processo possa ser 
melhorado dentro de um período de tempo.
146
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade IV
7.2.1 As atividades de manutenção
A execução da atividade de manutenção é iniciada por uma solicitação de mudança de um usuário 
do sistema e submetida à avaliação de um grupo responsável por aprovar a mudança. Uma vez aprovada, 
esta é encaminhada à gerência da manutenção, que irá classificar e priorizar o seu desenvolvimento, 
e, após isso, a mudança será construída. O ciclo de desenvolvimento de uma manutenção segue os 
mesmos passos que o da construção de sistema novo.
Análise do pedido 
de mudança
Cçassificação e 
priorização
Realização da 
manutenção
Figura 55 – Atividades para a realização de uma manutenção
Porém, existem exceções para aquelas manutenções chamadas de emergenciais, como correção de 
defeitos em produção, alterações críticas no ambiente ou regras de negócio essenciais para o bom 
funcionamento da aplicação. Esse fluxo é apresentado na Figura 55.
7.2.2 Papéis e responsabilidades na manutenção
Em uma manutenção, a determinação de papéis e responsabilidades claros permite a execução 
de um fluxo de trabalho estruturado, reduz substancialmente os conflitos e melhora o processo de 
comunicação. Os principais papéis em uma manutenção estão expostos a seguir.
Equipe de 
manutenção
Gerência de 
manutenção
Gerência de 
de TI
Usuários 
finais
Responsáveis 
pelo produto
Figura 56 – Atividades para a realização de uma manutenção
• Usuários: são os usuários finais do produto de software. Normalmente, são eles que identificam os 
defeitos que exigem correções imediatas ou apontamento de melhorias necessárias na aplicação. 
Também são responsáveis pelo aceite final das alterações executadas.
147
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
• Responsáveis pelo produto: são aqueles que solicitaram o software original. São responsáveis pela 
evolução de negócio da aplicação tratada pelas manutenções evolutivas e por prover os recursos 
financeiros para a realização das manutenções do sistema. Também devem dar o aceite nas 
melhorias e participar do processo de análise da mudança, podendo acatar ou não as solicitações 
feitas pelos usuários.
• Gerência de TI: são aqueles que cuidam da aplicação e são responsáveis pelo ambiente técnico 
e pela evolução tecnológica do software (manutenções adaptativas). Devem sugerir melhorias 
técnicas aos responsáveis pelo produto, manter o software operando de maneira adequada e 
participar da análise dos pedidos de mudança.
• Gerência de manutenção: é o responsável técnico por cuidar das manutenções aprovadas. 
Analisa, classifica e prioriza as manutençõesem conjunto com o responsável pelo produto a fim 
de determinar o que e quando as solicitações de mudança serão atendidas.
• Equipe de manutenção: realiza as mudanças aprovadas e priorizadas pela gerência. Normalmente 
atendem as solicitações de alteração emergenciais e pequenas melhorias. As mudanças maiores, 
na maioria das vezes, são tratadas como um projeto à parte.
7.2.3 Manutenção de sistemas legados
Um software legado é uma aplicação desenvolvida no passado e que ainda está em uso numa 
organização. Trata‑se de aplicações que sofreram muitas mudanças e adaptações, possuem tecnologia 
obsoleta, cuja documentação é praticamente inexistente e não há mais pessoas que participaram do 
desenvolvimento original. Em razão dessas características, tais softwares são bastante sensíveis a novas 
mudanças e se gasta mais tempo e dinheiro para executar as alterações. Portanto, qualquer mudança 
deve ser cuidadosamente analisada, e testes rigorosos devem ser realizados para evitar surpresas 
desagradáveis durante o desenvolvimento ou na fase de aceite pelos usuários.
7.2.4 Engenharia reversa
Segundo Chikofsky e Cross II (1990), engenharia reversa é um processo de análise e entendimento 
de um produto de software, com o objetivo de recapturar e decifrar os seus requisitos a partir da sua 
codificação existente para melhorar a qualidade do produto, reduzir custos de manutenção e atualizar 
tecnicamente o software.
A engenharia reversa é uma forma de manutenção muito utilizada para criar novos produtos de 
software a fim de substituir os sistemas legados, em razão das dificuldades que as organizações têm 
para manter esses sistemas legados funcionando adequadamente.
7.2.5 Técnicas de manutenção
As manutenções em um software podem ser classificadas em dois tipos básicos: a manutenção não 
estruturada e a manutenção estruturada.
148
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade IV
A manutenção não estruturada é aquela na qual a análise de um pedido de manutenção é feita por 
uma verificação direta no código‑fonte, uma vez que este é a única documentação disponível no produto 
existente. Trata‑se de uma atividade demorada, delicada e não é possível verificar os requisitos não 
funcionais da aplicação. Cada correção de defeito é um desafio. Na maioria das vezes, essa manutenção 
é executada por pessoal com pouca experiência e com pouco conhecimento do software, o que gera 
desmotivação e insatisfação da equipe e dos usuários.
A manutenção estruturada é aquela que é executada em um software que tem uma estrutura 
documentada e que foi construído seguindo as melhores práticas de desenvolvimento de software. 
Nesse tipo de manutenção, a análise e a correção de defeito são mais rápidas e menos custosas para 
desenvolvedores e usuários, tornando os resultados melhores e com maior qualidade.
7.2.6 Custos de manutenção
Os custos com a manutenção de uma aplicação são bem superiores aos custos de desenvolvimento 
de um software novo, pois o tempo de vida do software em manutenção é bem maior do que o tempo 
de criação. Além disso, à medida que o software vai sofrendo modificações por diversas pessoas ao 
longo da sua vida útil, as alterações vão se tornando cada vez mais complexas e demoradas. Como 
exemplo, podemos citar os sistemas legados, vistos anteriormente.
De acordo com Chikofsky (1990), os seguintes fatores são relevantes e afetam diretamente os custos 
de manutenção de um produto de software durante o processo de manutenção:
• Estabilidade da equipe: se a equipe de manutenção for fixa e tiver baixa rotatividade, os custos 
com a manutenção serão menores e a produtividade será maior que numa situação de trocas 
constantes.
• Responsabilidade contratual: um software novo é desenvolvido por uma equipe por meio de um 
projeto. Não há garantia, para essa equipe, de que a manutenção será de sua responsabilidade, 
portanto não há motivação para criar um software de fácil manutenção. A saída é fazer a revisão 
e a inspeção do software enquanto é produzido.
• Habilidade da equipe: as atividades de manutenção não são consideradas nobres pelos 
desenvolvedores, e a equipe designada, com frequência, tem menos experiência e pouco 
conhecimento do negócio.
7.3 Processos de manutenção
Um processo de manutenção define o conjunto de atividades necessárias para a realização de uma 
modificação em um produto de software para que este atenda as necessidades dos usuários.
A Norma ISO/IEC 14764 (2006) define um processo de manutenção que descreve as tarefas e 
atividades necessárias para modificar um produto de software, mantendo sua integridade. Vale lembrar 
que o processo de manutenção não determina como fazer o desenvolvimento da manutenção, mas 
149
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
descreve as atividades de identificação da mudança, análise e aceitação das mudanças, eventual 
migração ou retirada do software de produção.
As atividades que compõem o processo de desenvolvimento são:
• definição do processo de manutenção;
• análise das mudanças;
• desenvolvimento da mudança;
• aceitação e revisão da mudança;
• migração;
• retirada do software de produção.
Essas atividades são apresentadas na Figura 57, exceto a atividade de desenvolvimento da mudança, 
que trata do processo de desenvolvimento de software que é direcionado para a norma ISO/IEC 12207. 
Na prática, significa que a organização pode utilizar a sua própria metodologia para implementar as 
manutenções identificadas.
Definição do processo 
de manutenção
Migração Retirada de
produção
Análise das
mudanças
Aceitação/revisão 
da mudança
Figura 57 – Atividades para a realização de uma manutenção
7.3.1 Definição do processo de manutenção
A definição do processo de manutenção envolve a criação do procedimento a ser adotado pela 
equipe de desenvolvimento para a execução de uma manutenção. O procedimento deve descrever o que 
deve ser feito desde o pedido de manutenção até o seu aceite por parte dos usuários envolvidos. Além 
disso, deve determinar os papéis e as responsabilidades dos envolvidos no processo de manutenção.
Conforme ilustrado na Figura 58, a partir de um pedido de mudança, a equipe de manutenção deve 
identificar o tipo de manutenção, por exemplo: uma correção ou uma nova funcionalidade. Se for uma 
nova funcionalidade, a equipe de manutenção deverá fazer a análise, a classificação e a priorização da 
mudança. Se for uma correção de defeito, deverá primeiro avaliar a gravidade. Se for uma ocorrência 
150
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade IV
em produção, a mudança deverá ser executada imediatamente, caso contrário passará pelo processo 
de avaliação. Porém, esse procedimento é apenas um exemplo, podendo a organização estabelecer o 
processo que melhor se adapta a sua situação cotidiana.
7.3.2 Análise das mudanças
A análise de mudanças envolve o conjunto de atividades para entender o que precisa ser realizado, 
classificar o tipo de manutenção envolvida e o tempo necessário para a implementação da mudança. 
Deve ser realizado por um grupo de manutenção que envolva o pessoal de desenvolvimento e os 
usuários, a fim de determinar corretamente o tipo e a prioridade da alteração solicitada.
Essas atividades envolvem:
• analisar o pedido de mudança, identificar o seu tipo e definir claramente os requisitos da 
manutenção;
• identificar o que precisa ser realizado no código e realizar a documentação do sistema;
• criar as opções de alterações possíveis e estimar pessoal e tempo de alteração necessário para a 
opção escolhida;
• submeter a solução à aprovação dos usuários.
A análise da mudança é diretamente afetada pelo fato de a classificação da manutenção ser 
estruturada ou não estruturada. Como visto anteriormente, as manutenções não estruturadas trazem 
complicações à análise e maiores riscos à mudança que precisa ser realizada.Detalhamento 
da mudança
Detalhamento da 
mudança
Análise da 
mudança
Documentação e 
encerramento
Pedido de 
mudança
Classificação da 
mudança
Implementação 
imediata
Classificação e 
priorização da 
mudança
Baixa gravidade
Urgente
AprovaAprova
Não aprova Não aprova
DefeitoNova
Figura 58 – Exemplo de um fluxo de processo de manutenção
151
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
7.3.3 Aceitação e revisão da mudança
Envolvem as atividades para garantir que a mudança esteja corretamente implementada e atenda 
aos requisitos solicitados. Além de incluir as atividades de garantia da qualidade, deve prever o aceite da 
mudança efetuada pelo usuário. Algumas atividades envolvidas são:
• revisões;
• inspeções;
• testes;
• testes de regressão;
• processo de aceitação.
Após o aceite da manutenção, a documentação deve ser atualizada e arquivada, além de ser 
necessária a geração da nova linha de base da aplicação.
 Observação
No caso de não existir um roteiro de testes da aplicação, a equipe de 
manutenção deve criar um roteiro específico para a mudança que está em 
desenvolvimento.
7.3.4 Migração
No ciclo de vida de um software podem ocorrem mudanças que exijam migrar os dados de um 
ambiente para outro. Normalmente, ocorrem em função de uma mudança adaptativa ou da realização 
da engenharia reversa em alguma aplicação.
A migração dos dados é uma tarefa delicada e exige a elaboração de um plano de migração para a 
garantia da integridade das informações. Esse plano de migração deve conter:
• análise dos requisitos e definição da migração;
• criação do processo de de‑para da migração;
• definição de conversões de dados necessárias;
• identificação dos riscos da migração;
• execução do processo de migração;
152
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade IV
• verificação dos resultados da migração;
• definição do processo de validação dos usuários;
• criação de um processo de retorno, em caso de insucesso da migração;
• atualização da documentação.
Uma vez elaborado o plano de migração, a equipe de manutenção deve apresentá‑lo aos usuários 
para que seja avaliado em conjunto e aprovado por todos os envolvidos no processo. Além disso, deve 
descrever e apresentar aos usuários as necessidades relacionadas às pessoas e ao tempo de dedicação 
necessário para a execução das atividades de migração.
 Observação
O termo de‑para significa que o desenvolvedor deve identificar, para 
cada campo da tabela de dados Origem, qual o seu equivalente na tabela 
de dados Destino.
7.3.5 Retirada de produção
Consiste em uma análise técnica ou econômica para determinar se o software deve permanecer em 
produção ou ser descontinuado. Essa decisão deve ser conjunta, entre a equipe de desenvolvimento e os 
usuários, a fim de garantir o investimento necessário para a manutenção do software existente ou para 
a aquisição ou o desenvolvimento de um novo produto.
Após a decisão pela descontinuidade, é elaborado o plano de retirada de produção envolvendo o tempo 
em que a manutenção deve permanecer em operação até a desativação do sistema, o tempo de transição 
(paralelismo) entre o novo sistema e o sistema atual, a obtenção e a documentação dos requisitos do 
sistema a ser descontinuado, o plano de migração de dados e o registro e o arquivamento da documentação.
 Lembrete
A descontinuidade de um software não tem prazo determinado. Tudo 
depende de como foi construído, de como atende aos usuários atualmente 
e dos custos para mantê‑lo funcionando.
7.4 Impactos na manutenção
Como visto até aqui, a manutenção é diretamente afetada pela forma que o software foi construído, 
a qual pode gerar maior ou menor esforço e mais ou menos custos durante o ciclo de manutenção, 
causando impactos diversos no processo.
153
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
Destacam‑se os impactos gerados pelas práticas mais comuns no mercado de Tecnologia da 
Informação: o desenvolvimento orientado a objetos, o desenvolvimento baseado em componentes e os 
processos de desenvolvimento ágeis, que são abordados a seguir e ilustrados na Figura 59.
Desenvolvimento 
orientado a objetos
Desenvolvimento 
baseado em 
componentes
Impactos de 
manutenção
Processos ágeis
Figura 59 – Impactos na manutenção de software baseado em métodos ágeis
7.4.1 Desenvolvimento orientado a objetos
O desenvolvimento orientado a objetos se baseia em objetos do mundo real que interagem entre 
si e são acionados por pessoas do mundo real chamadas de atores. Um projeto orientado a objetos 
é composto de classes que são a representação de um objeto de negócio do mundo real com suas 
próprias características (atributos) e seus próprios comportamentos (métodos) que executam as 
ações necessárias para o negócio. Sua implementação garante códigos reduzidos nos métodos e 
responsabilidade dos objetos, permitindo a extensão desses comportamentos. A codificação se dá pela 
interação desses objetos, permitindo a separação clara das responsabilidades e ações de cada classe. Os 
conceitos de herança e agregação aumentam a capacidade de adaptação de um software desenvolvido 
com orientação a objetos.
A concepção do projeto normalmente é no padrão Model View Controller (MVC), em que 
cada camada view é responsável pela interface com o usuário, a camada model, pela construção 
das regras de negócio, e a controller, pela ligação entre as camadas view e model. A construção 
orientada a objetos associada ao padrão MVC permite o perfeito isolamento das funções e a 
evolução da aplicação. Por exemplo, um software orientado a objetos no padrão MVC viabiliza a 
existência de aplicações para qualquer mídia na camada visual, e a camada de negócio permanece 
sem alterações.
Seguindo os princípios básicos da orientação a objetos e do padrão de arquitetura MVC na construção 
de um software, vários impactos podem ser destacados na manutenção de uma aplicação. Destacam‑se 
os seguintes durante o processo de manutenção, ilustrados no Quadro 21:
154
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade IV
Quadro 21 – Impacto na manutenção de software desenvolvido com orientação a objetos
Tipo Impacto Observações
Corretiva Ajuste pontual nas classes envolvidas 
Testes devem ser realizados em todas as funcionalidades 
que utilizam as classes alteradas. Teste de regressão é 
recomendado 
Perfectiva
O modelo objeto permite a extensão 
das classes existentes e a criação de 
novas classes sem afetar a aplicação 
existente 
Depende da correta modelagem dos objetos para garantir 
que as classes existentes tenham apenas extensões e não 
se modifique o que já está funcionando
Os testes devem envolver o que foi criado de novo e os 
testes de regressão das demais funcionalidades 
Adaptativa
Pela estrutura de objetos, deverá gerar 
alterações nas classes envolvidas e 
nas camadas que incluírem novos 
comportamentos 
Demandam a realização de testes completos do sistema 
Preventiva Dependerá da alteração que for gerada 
pelo processo 
A alteração pode gerar uma manutenção corretiva, 
perfectiva ou adaptativa 
7.4.2 Desenvolvimento baseado em componentes
O desenvolvimento baseado em componentes tem como objetivo criar estruturas de código que 
possibilitem a sua utilização em mais de um sistema. Esse conceito é conhecido como reúso e tem se 
tornado uma abordagem comum no mercado de Tecnologia da Informação. A ideia é criar componentes 
que não sejam específicos para um determinado sistema, mas com uma visão de uso genérico para 
atender a todos os sistemas. Por exemplo, ao criar uma classe‑cliente para um sistema de vendas, o 
projetista deve pensar que essa classe pode ser usada no sistema de cobrança, no de faturamento, 
dentre outros. Os benefícios fornecidos por uma abordagem baseada em componentes são: criar uma 
estrutura de código que aumenta a velocidade de desenvolvimento dos sistemas e atender à demanda 
dos sistemas atuais, que se tornam cada vez maiores e mais complexos.
Na visão da manutenção para sistemas baseados em componentes, podemos analisar os impactos 
a partir das alterações nos componentes construídos e submetidos a mudanças pelos processos de 
manutenção, ilustrados no Quadro 22:
Quadro 22 – Impacto na manutenção de software desenvolvido com base em componentes
Tipo Impacto Observações
Corretiva
As correções nos componentes são mais delicadas, 
em razão do uso genérico. As correções devem ser 
publicadas para todos os que utilizam o componente 
Necessários testes rigorosos com o 
componente e as partes dos sistemas que o 
utilizam, antes de colocar em produção 
Perfectiva
Alterações evolutivas nos componentes devem 
manter a compatibilidade com as versões anteriores. 
Os componentes não podem ser simplesmente 
alterados e devem manter o legado estável 
Necessários testes com as novas funções do 
componente e dos sistemas que o utilizam
Adaptativa Evoluções tecnológicas devem gerar novas versões 
dos componentes. Não alterar os existentes 
Testes rigorosos com os novos componentes 
como se fossem criados no momento 
Preventiva Depende da alteração que for gerada pelo processo A alteração pode gerar uma manutenção 
corretiva, perfectiva ou adaptativa 
155
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
 Saiba mais
Para mais informações sobre o desenvolvimento baseado em 
componentes e orientado a objetos, consulte o livro:
SOMMERVILLE, I. Engenharia de software. São Paulo: Pearson, 2013.
7.4.3 Desenvolvimento ágil
O desenvolvimento ágil é um processo de desenvolvimento de software, e não uma estrutura para 
construir um software. Suas características estão relacionadas à rapidez, à integração cliente‑equipe 
e à alta qualidade durante o ciclo de construção, podendo utilizar uma estrutura orientada a objetos 
ou baseada em componentes. Portanto, a manutenção é afetada pelas características do processo ágil 
que alteram profundamente a relação cliente‑desenvolvedor, e não pela estrutura de construção da 
aplicação. O desenvolvimento pode utilizar tanto a orientação a objetos quanto o desenvolvimento 
baseado em componentes. Olhando sob o aspecto dos processos ágeis, podemos analisar os impactos da 
manutenção da seguinte forma, no Quadro 23:
Quadro 23 – Impacto na manutenção de software baseado em métodos ágeis
Tipo Impacto Observações
Corretiva
No processo ágil, a correção é realizada 
de forma interativa para atender 
rapidamente ao usuário 
Validações são realizadas ao fim da 
codificação 
Perfectiva Novas funcionalidades são tratadas como 
mudanças no software 
O uso de métodos ágeis na manutenção 
implica a existência de equipe treinada e 
que entenda do negócio em evolução 
Adaptativa Tratadas como um novo projeto de 
acordo com o método ágil 
Deve seguir o padrão de desenvolvimento 
ágil utilizado 
Preventiva Dependerá da alteração que for gerada 
pelo processo 
A alteração pode gerar uma manutenção 
corretiva, perfectiva ou adaptativa 
É importante salientar que, independentemente do processo de desenvolvimento ou da arquitetura utilizada 
para a criação do software, a manutenção sempre apresentará alto grau de dificuldade no gerenciamento e 
no controle das alterações, pois sempre impactará diretamente os usuários finais que já utilizarem o software 
em produção, podendo trazer impactos à imagem da empresa e também à parte financeira.
8 GESTÃO DA CONFIGURAÇÃO
O Gerenciamento de Configuração de Software (GCS), também conhecido como Software 
Configuration Management (SCM), é um processo da engenharia de software que tem por objetivo 
estabelecer as condições para a organização dos artefatos de software, controlar suas versões e suas 
alterações, manter a integridade de tudo o que foi produzido durante o ciclo de vida de um projeto de 
software e garantir seu armazenamento adequado. Esses conceitos são ilustrados na Figura 60.
156
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade IV
8.1 Conceitos de gestão da configuração
Segundo o SEI (2006), a gestão de configuração envolve identificar o que deve ser controlado, 
gerenciar suas alterações e manter a integridade e a rastreabilidade dos artefatos de um software.
Os objetivos essenciais da GCS são: aumentar a produtividade do time, diminuir o esforço manual de 
controle e reduzir os erros causados pela falta de controle dos artefatos de projeto.
Já que uma mudança pode ocorrer a qualquer tempo, as atividades de GCS são desenvolvidas para:
Relatar a 
mudança
Controlar a 
mudança
Garantir sua 
implementação
Identificar a 
mudança
Definição
Todo o processo
Figura 60 – Conceitos de gestão da configuração de software
 Lembrete
Manter a integridade dos artefatos significa garantir que, dado 
um artefato, somente pessoas autorizadas podem alterá‑lo, e todas as 
alterações serão registradas.
8.1.1 Problemas mais comuns
Durante o ciclo de desenvolvimento de um software são produzidos vários artefatos solicitados 
pelo cliente, pela metodologia e pelos usuários, bem como diversos arquivos de código‑fonte. Manter 
esse conjunto de artefatos organizado e controlado não é uma tarefa trivial, principalmente, quando o 
número de desenvolvedores é muito grande, trabalhando em locais físicos diferentes e compartilhando 
esses artefatos com outras equipes e com o próprio cliente. As seguintes frases são muito ouvidas 
em cenários de desenvolvimento de software: “Qual versão do documento de requisitos enviamos ao 
cliente, mesmo?”, “Quem enviou?”, “Procure no e‑mail...”. São comentários assustadores em qualquer 
ambiente de projeto de software.
157
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
São apresentadas, a seguir, situações corriqueiras que envolvem essa concorrência pela informação, 
compartilhamento de arquivos e o controle sistemático desses artefatos produzidos.
 Observação
Para fins conceituais, artefato é todo e qualquer documento produzido 
durante o projeto, inclusive o código‑fonte.
8.1.1.1 Problema 1 – Relacionado a desenvolvedor com os artefatos isolados
Embora o projeto tenha vários desenvolvedores, um desenvolvedor trabalha na sua própria máquina, 
mantendo os arquivos sob seu domínio e, eventualmente, coloca‑os no servidor, mas continua alterando 
a versão na sua própria máquina, como na Figura 61.
Figura 61 – Exemplo de desenvolvimento isolado
Nesse cenário, quando outro desenvolvedor precisar modificar o artefato, ele irá buscar no servidor, 
e a versão poderá estar desatualizada, ou nem estar disponível.
8.1.1.2 Problema 2 – Relacionado a artefatos compartilhados
Esse problema ocorre quando dois ou mais desenvolvedores estão fazendo alterações no mesmo 
artefato. Nessa situação, o desenvolvedor A modifica o artefato, e, mais tarde, o desenvolvedor B 
também faz alterações no mesmo artefato, sem saber que ele já foi alterado pelo desenvolvedor A, 
conforme ilustrado na Figura 62.
Versão 1 Versão 2
Figura 62 – Exemplo de artefatos compartilhados
158
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade IV
Como consequência, quando o desenvolvedor A tentar compilar o artefato, serão apontados erros, 
mas nenhum deles causado pelas alterações que ele fez.
8.1.1.3 Problema 3 – Relacionado a manutenção simultânea
Ocorre quando cada desenvolvedor trabalha com uma cópia local do artefato, gerando dificuldades 
para identificar o que já foi realizado e para saber que defeitos foram corrigidos, conforme a Figura 63.
Artefato A Artefato B
Desenvolvedor BDesenvolvedor A
Figura 63 – Exemplo de manutenção simultânea
Nesse cenário, há grande dificuldade para identificar qual é a versão correta a ser utilizada no 
software.
8.1.1.4 Problema 4 – Relacionadoao ser executada. O prazer vem ao final, quando o cliente recebe o produto de software 
10
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
com poucos erros, o programador faz poucas alterações no código que produziu e alguém, ao efetuar a 
manutenção desse software, diz: “Nossa! Como está fácil fazer essa alteração!”. Enfim, nem sempre você 
poderá presenciar esses resultados, mas saberá que fez o seu melhor, e isso é o mais importante.
A partir desse cenário, ao conhecer as características que traduzem um software de qualidade, saber 
quais são os processos e modelos de qualidade mais utilizados e praticados no mercado de trabalho torna 
você um profissional diferenciado, uma vez que a maioria dos profissionais está apenas preocupada com 
a programação dos computadores e se esquece de que esta é somente a atividade‑fim de um processo 
de construção.
Dominando esses requisitos básicos do que é produzir um software de qualidade, passamos a 
explanar e conhecer as técnicas e ferramentas que permitem definir o como fazer, que irá direcionar 
as atividades de qualidade durante todo o processo de desenvolvimento, desde o levantamento de 
requisitos até a programação, para que os resultados sejam avaliados constantemente durante o ciclo 
de vida, e não apenas ao seu final, como é feito na maioria das empresas.
Como resultado dessa preocupação com a qualidade do que é produzido, as manutenções 
preventivas e evolutivas do sistema tornam‑se mais fáceis e rápidas, gerando satisfação a todos os 
envolvidos no trabalho.
Para dar suporte a esse processo de construção de um software de qualidade e com facilidade de 
manutenção, faz‑se necessário um processo bem‑definido para controlar todos os artefatos e códigos 
produzidos, a fim de que não se percam versões, documentos e outros elementos essenciais para manter 
a integridade e a confiança no produto e permitir que apenas pessoas autorizadas façam modificações 
no software final.
Enfim, dominando esses assuntos e aplicando as técnicas apresentadas, você terá um grande 
diferencial em relação aos outros profissionais: saberá produzir software com qualidade.
11
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
Unidade I
1 CONCEITOS SOBRE QUALIDADE DE SOFTWARE
Na Engenharia de Software, a área de qualidade tem como objetivo garantir que, ao final, o software 
esteja de acordo com as características definidas pelos usuários no início e no decorrer do processo de 
desenvolvimento da aplicação.
Segundo a norma NBR ISO (2000a), qualidade de software é definida como um conjunto de 
características que devem ser alcançadas em um determinado grau para que o produto atenda às 
necessidades de seus usuários. A totalidade de características de uma entidade que lhe confere a 
capacidade de satisfazer a necessidades explícitas e implícitas.
Há um consenso entre os diversos autores da área de qualidade de que o objetivo principal da qualidade 
é proporcionar a satisfação dos clientes por meio do atendimento das necessidades especificadas e 
também dos requisitos implícitos do software.
Conforme ilustrado na Figura 1, para Crosby (1990), existem cinco princípios básicos da qualidade 
que, se seguidos, produzirão melhores resultados:
1) Fazer certo da primeira vez economiza tempo e dinheiro.
Ao se preocupar em produzir com qualidade desde o primeiro momento, as atividades de correção 
de erros diminuirão e, por consequência, haverá redução dos custos e cumprimento dos prazos 
estabelecidos.
2) Qualidade é um processo preventivo.
A qualidade deve ser aplicada desde o primeiro momento, e não só após o produto estar pronto.
3) Qualidade é incorporada ao produto como resultado da atenção dedicada às necessidades 
dos clientes.
Logo no início do processo de desenvolvimento, devem‑se identificar e definir os padrões de 
qualidade esperados pelos clientes, a fim de construir o software alinhado a essa expectativa.
4) Qualidade é responsabilidade de todos os envolvidos.
Não basta que a gerência esteja preocupada com a qualidade. Cada membro da equipe deve ter 
a consciência de que deve fazer o melhor possível sempre, bem como assumir a responsabilidade 
por isso.
12
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade I
5) Qualidade é um processo de melhoria contínua.
Em todos os processos, sempre há o que pode ser melhorado. A qualidade não foge à regra. Cada 
vez que produzimos algo, aprendemos e aperfeiçoamos, sempre em busca de fazer melhor da 
próxima vez.
Fazer certo na 
primeira vez
Processo 
preventivo
Responsabilidade 
de todos
Melhoria 
contínua
Atenção às necessidades 
dos usuários
Figura 1 – Princípios básicos da qualidade
 Observação
Envolvidos no projeto são todos aqueles que participam do projeto de 
software direta ou indiretamente. Esses envolvidos também são chamados 
de interessados ou stakeholders.
1.1 Benefícios da qualidade
Embora existam várias iniciativas sobre a qualidade de software, muitas empresas de Tecnologia da 
Informação ainda permanecem na situação denominada caos, significando que o software é produzido com 
base em pessoas, e não em processos. A partir da conscientização de todos de que a qualidade pode transformar 
o cenário atual, processos e métodos são introduzidos gradativamente para alcançar o grau de organização 
necessário para que a empresa usufrua dos benefícios da qualidade, conforme ilustrado na Figura 2.
 Observação
OS envolvidos devem ser identificados logo nas fases iniciais do 
projeto. Os principais são: o patrocinador, os clientes, os usuários finais e 
os fornecedores.
Alguns benefícios podem ser observados como resultado direto da produção de um software com qualidade:
• aumento da produtividade;
• redução de defeitos no produto;
• aumento da confiabilidade do produto;
13
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
• menos retrabalho;
• menos horas extras de trabalho;
• maior satisfação dos clientes.
Caos Qualidade Organização
Figura 2 – Evolução com a conscientização sobre a qualidade
1.2 Obstáculos da qualidade
Fazer software com qualidade, porém, não é uma tarefa fácil. Há sempre um conjunto de fatores 
internos e externos que são opostos às boas práticas e que acabam por criar dificuldades à implementação 
do processo de qualidade em uma empresa e até mesmo a ações individuais de melhoria. Alguns desses 
fatores são descritos na Figura 3.
Cultura da 
organização
Cultura da 
organização
Custo e prazo
maldefinidos
Envolvidos não
identificados
Figura 3 – Obstáculos à qualidade de software
 Lembrete
A cultura da organização é um dos principais obstáculos à qualidade. 
O conceito “Se está dando certo, por que mudar?” contribui para uma 
resistência ainda maior da equipe de desenvolvimento.
As aplicações de software estão a cada dia mais complexas para construir, testar e navegar, em 
virtude da evolução de tecnologias como tablets, smartphones, dentre outros, bem como das interfaces 
para a internet que são cada vez mais interativas com o usuário, o que aumenta o grau de dificuldades 
das aplicações.
14
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade I
Custos e prazos maldefinidos são uma constante em virtude da pressão, do mercado e da própria 
concorrência que os clientes vêm sofrendo para o lançamento de novos produtos. Esses dois fatores 
levam as equipes a abandonarem os processos de qualidade para atender ao tempo e aos custos do 
projeto que são prioridades para a direção da empresa.
Por último, um novo produto de software é iniciado sem o correto esclarecimento a todos os 
envolvidos, e, muitas vezes, estes não são nem notificados sobre esses produtos, o que causa surpresas 
e problemas no atendimento às necessidades desses envolvidos.
1.3 Visões da qualidade
Como mencionado nos obstáculoscom atualizações simultâneas
Essa situação ocorre quando um desenvolvedor A corrige um problema em sua versão de artefato e 
armazena‑o num repositório central. O desenvolvedor B corrige outro problema no mesmo artefato e 
também o armazena no repositório central, ilustrado na Figura 64.
Versão A Versão B
Desenvolvedor BDesenvolvedor A
Figura 64 – Exemplo de atualização simultânea
159
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
No cenário descrito, os desenvolvedores não se preocupam com quem atualizou o quê, gerando 
retrabalho para todos.
A gestão da configuração existe para solucionar esses problemas e outros que surgem em relação à 
efetiva organização dos artefatos, permitindo à equipe de projeto ter mais rapidez na identificação e na 
solução de problemas, identificar quem fez as mudanças ao longo do tempo, controlar as versões desses 
artefatos e estabelecer padrões para toda a equipe.
8.1.2 Conceitos de gestão da configuração
Os profissionais de Tecnologia da Informação costumam confundir o termo manutenção com 
configuração, e o termo configuração com controle de versões, dentre outros. Visando ao melhor 
alinhamento do vocabulário, esses conceitos diferentes são vistos a seguir:
• Manutenção: mudanças e/ou alterações que são realizadas no software após sua conclusão e 
entrada em produção. Necessariamente, envolve alterações no código‑fonte ou no ambiente da 
aplicação.
• Configuração: atividades de gerenciamento de todo o fluxo dos artefatos produzidos em um 
software, desde seu início até sua descontinuidade. Para isso, envolve o uso de ferramentas e não 
altera código de programas.
• Controle de versões: uma das atividades da GCS. Envolve o uso de uma ferramenta que controla 
o armazenamento dos artefatos e gerencia todas as alterações que esse artefato possa sofrer 
durante seu ciclo de vida.
• Itens de configuração: artefatos criados como parte do processo de desenvolvimento de um 
software. Uma vez identificados e determinados como controlados, esses itens de configuração 
vão estar sob a gestão da configuração.
• Baseline: fotografia do momento de um artefato, quando este é aprovado pelo cliente. Após 
a criação desta baseline, esse artefato só poderá sofrer alterações mediante autorização e 
aprovação formal do cliente, o que gera uma nova baseline. Trata‑se de um ponto de controle 
no desenvolvimento de software, caracterizado pela entrega de um item de configuração para 
aprovação formal, por meio de uma RTF, por exemplo. Os artefatos que necessitam de criação de 
baselines são definidos pelos desenvolvedores e pelo cliente nas fases iniciais do projeto, e alguns 
exemplos por fase de desenvolvimento são ilustrados na Figura 65.
160
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade IV
Engenharia de sistema
Especificação de sistema
Especificação de requisitos
Especificação de projeto
Código‑fonte
Planos de testes
Análise de requisitos
Projeto de software
Codificação
Testes
Figura 65 – Exemplo de artefatos que precisam de baseline
8.2 Processo de gestão da configuração
Antes de descrever as tarefas, é preciso definir a estrutura de armazenamento dos artefatos, a 
nomenclatura de cada um dos artefatos envolvidos no processo de gestão da configuração e quem 
pode fazer o quê com os artefatos.
Inicialmente é necessário identificar como os nomes dos artefatos são descritos. O nome deve conter 
um conjunto de caracteres que defina o artefato em si de modo único e contenha o nome do projeto 
e a versão a que se refere. Essa denominação é predefinida pela equipe de gestão de configuração da 
organização para atender todo o processo de desenvolvimento de software. Por exemplo, para denominar 
os artefatos para o projeto XPT001 que tem os seguintes itens de configuração:
Tabela 10 – Artefatos e respectivas nomenclaturas
Artefato Nomenclatura
Documento de requisitos XPT001_DOCREQ_V1.0.
Especificação de casos de uso XPT001_ESPEC_UC_V1.0
Modelo de dados XPT001_MER_V1.0.
Uma vez definida a nomenclatura dos artefatos, é preciso ter também a estrutura de armazenamento, 
que corresponde à árvore de diretórios nas quais os artefatos são distribuídos no projeto. Também são 
predefinidos pela equipe de gestão da configuração. Um exemplo dessa estrutura para o projeto XPT001 
é apresentado a seguir.
/XPT001
 /versao1.0
 /Analise
 /Projeto
 /Codificação
 /Testes
 /versao1.1
 /Analise
 /Projeto
 /Codificação
161
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
Definidos a árvore de diretórios e os artefatos que fazem parte do GCS, o controle de acesso 
de segurança para eles também terá de ser definido. O controle de acesso é realizado com 
base na equipe do projeto fornecida e com as permissões atribuídas pelo gerente. Por exemplo, 
programadores têm acesso a leitura e gravação na pasta Codificação, mas apenas de leitura nas 
pastas Análise e Projetos.
Uma vez definida a nomenclatura, o controle de acesso à informação e a estrutura de organização 
dos artefatos, é necessária a definição do processo de gestão da configuração, que é dividido em cinco 
tarefas básicas:
• identificação dos itens de configuração;
• controle de versão;
• controle de mudanças;
• auditoria na configuração de software;
• registro do status.
8.2.1 Identificação dos itens de configuração
Um item de configuração é a menor unidade produzida em um projeto passível de controle. Esse 
item pode ser qualquer artefato produzido durante o ciclo de vida do projeto que precise ser controlado 
em suas diversas versões e aprovações pelo cliente.
O projeto pode produzir diversos artefatos, mas nem todos estão sob a gestão da configuração. A 
Tabela 11 apresenta uma lista dos artefatos mais comuns gerados durante o ciclo de desenvolvimento 
de um software.
Tabela 11 – Lista de artefatos de um projeto de software
ID Artefato ID Artefato
1 Documento de requisitos 2 Cronograma
3 Plano de riscos 4 Protótipo de telas
5 Especificação caso‑uso 6 Diagrama de casos de uso
7 Diagrama de classes 8 Documento de arquitetura
9 Diagramas de sequência 10 Diagramas de estados
11 Códigos‑fonte 12 Casos de teste
13 Roteiro de testes 14 Plano de implantação
15 Manual de usuário 16 Modelo de dados
17 Plano de instalação 18 Pedidos de mudança
162
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade IV
Essa lista traz exemplos de artefatos, que não se limitam a esses itens. Cada projeto tem o seu conjunto 
de artefatos definidos pela metodologia ou pelo cliente, e sobre esses artefatos deve ser gerada a lista 
de itens de configuração do projeto. Como informação complementar, em alguns projetos e clientes, as 
atas de reunião e os e‑mails trocados durante o projeto são considerados itens de configuração.
Outros artefatos de software, como os programas executáveis, não são controlados pela configuração, 
mas o código‑fonte a partir do qual é gerado tem de ser controlado. Outros itens precisam ser controlados 
para garantir a integridade do projeto, como versões de editores, compiladores e de frameworks, por 
exemplo, JVM 5.0, Struts 2.0, JSF 2, EJB 3.2, dentre outros.
8.2.2 Controle de versões
Combina procedimentos e ferramentas para gerenciar diferentes versões de itens de configuração 
criadas durante o processo de desenvolvimento de software. Permite conhecer e controlar a evolução 
dos artefatos por meio desses procedimentos, como ilustrado na Figura 66.
Algumas ferramentas mais utilizadas e conhecidas para o controle de versões são Visual Source Safe, 
PVCS, CVS, SubVersion, dentre outras.
1.0 1.1 1.2
1.3
2.0
1.1.1
1.4
2.1
1.1.2
Figura 66 – Exemplo de evolução de versão de um artefato
Os procedimentos de controle de versões devem possuir um servidor próprio para ser o repositório dos 
arquivos controlados e não existem apenas para os desenvolvedores,mas sim para todos os envolvidos no 
projeto de software, como ferramenta central para a obtenção de qualquer informação sobre o software.
Alguns motivos para uso do controle de versões são:
• efetuar o registro histórico dos artefatos do projeto ao longo do tempo;
• permitir que desenvolvedores trabalhem juntos, sem que um atrapalhe o outro;
• promover segurança na manipulação e na alteração do código‑fonte.
163
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
Com a utilização efetiva do controle de versões, basta acessar a ferramenta para saber da informação 
necessária. O controle de versões ainda permite o compartilhamento de todos os arquivos de forma 
segura e organizada, a recuperação fácil de qualquer artefato e a consulta de qualquer versão. Além 
disso, funciona como um backup de todas as informações do projeto.
 Observação
Backup é uma cópia de segurança de tudo o que é produzido, realizada 
pela ferramenta de controle de versões de forma automática.
Para fazer funcionar um controle de versões, diversas operações são realizadas, independentemente 
da ferramenta utilizada. O procedimento básico do trabalho de controle de versões é:
• retirar uma cópia do artefato para alteração do repositório;
• fazer as alterações na cópia realizada;
• validar as alterações;
• gravar as alterações no repositório.
Vamos conhecer algumas operações importantes no controle de versões e alinhar a terminologia 
utilizada nessa tarefa:
• Check out: ação para retirar o artefato do repositório e copiar para o seu ambiente para poder 
fazer alterações. Ao realizar essa ação, você também pode bloquear o artefato para não permitir 
que ele seja alterado até você liberar o check‑in.
• Check‑in: ação de devolver o artefato retirado para alteração para o repositório central com as 
modificações realizadas. Se for código‑fonte, somente faça se o programa estiver compilando sem 
erros. Também chamado de commit. Às vezes, é necessário realizar uma combinação de possíveis 
outras alterações feitas por outros usuários, chamada de merge.
• Diff: ação que compara a versão que está no repositório com a versão que você está alterando, ou 
compara duas versões que estão no repositório. São exibidas as diferenças entre os dois artefatos.
• Merge: atividade realizada antes de um check out, e depois de um diff, com o objetivo de verificar 
as diferenças entre duas versões de um artefato e garantir a integridade das alterações.
• Tag ou label: são rótulos atribuídos a um artefato para identificar o projeto e as versões aos quais 
ele pertence. Constituem uma das principais operações para o controle de versões. Todo artefato 
precisa de uma tag. Esta pode ser usada quando uma versão é criada, antes de se fazer uma 
alteração que envolva muitos artefatos ou numa situação julgada relevante para “marcar” a tag.
164
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade IV
• Branch: são usados branches quando é preciso trabalhar em duas versões distintas de um projeto 
ao mesmo tempo. Por exemplo, após colocar a versão 1.0 de seu software em produção, você 
precisa continuar o desenvolvimento da versão 2.0. Nesse caso, caso ocorra um problema na 
versão 1.0, há como identificar tudo o que faz parte dessa versão para gerar uma nova build.
• Build: uma versão do software produzida para ser utilizada em testes, aceitação ou em produção. 
Podem ser manual ou automaticamente gerada por uma ferramenta específica.
8.2.3 Controle de mudanças
O controle de mudanças estabelece um processo para identificar e analisar as mudanças, aprovar e 
controlar sua implementação, garantir sua correção e publicar as mudanças de um item de configuração. 
É recomendado haver um comitê para o controle de mudanças, mas não é obrigatório. Essas atividades 
estão ilustradas na Figura 67.
Identificar e analisar a 
mudança
Garantir sua correta
construção
Aprovar e controlar a 
mudança
Públicar a mudança para 
outros stakeholders
Figura 67 – Atividades de um controle de mudança
Caso exista o comitê de gestão de mudança, ele é responsável pela análise, pela aprovação ou não 
da mudança, pela priorização da implementação e pelo controle do escopo da alteração. Caso não exista 
um comitê, deve haver um representante do usuário e outro representante da construção para realizar 
esse papel.
A mudança ocorre a partir da identificação de uma necessidade pelos usuários ou por qualquer 
outro envolvido no projeto.
Essa solicitação é conhecida como pedido de mudança ou change request.
165
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
Solicitar 
alteração
Libearar para 
alteração
Liberar alteração 
para testes
Aprovar 
alteração
Checkin do item 
de configuração
Check out 
do item de 
configuração
Implementação 
da alteração
Alterar 
baseline
Validar 
alteração
Avaliar 
alteração Alteração 
reprovada
Baseline
Figura 68 – Atividades de mudança dentro do GCS
Conforme apresentado na Figura 68, ao ser recebida, a mudança precisa ser avaliada quanto à sua 
necessidade. Caso aprovada, o item de configuração é retirado da baseline por meio de uma ação de 
check out, a qual permite que o item seja modificado pelo desenvolvedor. Após a alteração do artefato, é 
feito o registro com a descrição da modificação, quem alterou e quando alterou, e é realizado o ckeck‑in 
do item. Este item é submetido à validação do solicitante do pedido de alteração. Uma vez validado, uma 
nova tag (label) e uma nova baseline são geradas para o item de configuração.
Todo o pessoal envolvido no projeto ou na manutenção dos itens sob gerência da configuração deve 
ser treinado no processo e nas ferramentas, a fim de garantir sua correta utilização.
8.2.4 Auditoria de configuração
A auditoria de configuração tem como objetivo garantir que a mudança esteja correta, que o 
processo de gestão da configuração esteja sendo seguido corretamente e que o uso da ferramenta 
também esteja correto.
As auditorias devem ser parte do processo de gestão da configuração e ser realizadas por pessoal 
externo ao projeto, com o objetivo de garantir a isenção dos apontamentos realizados. A verificação de 
que a mudança está correta é feita em RTF. Esta tem foco na correção técnica do item de configuração 
e deve ser realizada antes da atividade de validação da mudança pelos envolvidos.
A auditoria tem foco na verificação de que os procedimentos descritos no processo de gestão de 
configuração estejam sendo realizados por todos os envolvidos no trabalho. Os seguintes questionamentos 
precisam ser respondidos em uma auditoria da configuração:
166
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade IV
• Os itens de configuração estão nomeados de acordo com o padrão definido?
• A estrutura de diretórios está de acordo com o padrão?
• Os itens de configuração estão colocados corretamente em suas pastas de armazenamento?
• O controle de acesso aos artefatos está implementado?
• Existe um registro de revisão da mudança?
• Histórico e comentários da mudança, autor e data estão registrados?
8.2.5 Registro do status
O registro de status consiste em registrar nos itens de configuração as informações relacionadas à 
mudança efetuada, quem a fez, a data da mudança e a informação de outros itens de configuração que 
podem ser afetados.
8.3 Padrões de gestão da configuração
Existem diversos padrões de gestão de configuração já definidos por modelos de qualidade e 
processos ISO para que uma organização possa escolher, de acordo com as suas próprias necessidades 
ou com o modelo de qualidade que utiliza. Os principais padrões de gestão da configuração sugeridos 
são os propostos pelo CMMI, pela ISO/IEC 12207, pela ISO/IEC 9000‑3 e pela ISO/IEC 15504, 
apresentados na Figura 69.
CMMI ISO/IEC 12207 ISO/IEC 9000‑3
ISO/IEC 15504
Figura 69 – Modelos e processosque definem padrões de GCS
8.3.1 Padrão de gestão de configuração – CMMI
A gestão da configuração no modelo de qualidade CMMI está previsto no Nível 2 – Gerenciado e é 
parte dos requisitos básicos de maturidade no desenvolvimento de software.
167
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
Segundo o CMMI (SEI, 2006), o objetivo do gerenciamento de configuração é manter a integridade 
dos produtos de trabalho, utilizando a identificação, o controle, a comunicação do status e auditorias 
das configurações, de acordo com a Figura 70.
Estabelecer 
baselines
Rastrear e 
controlar 
mudanças
Estabelecer 
integridade
Auditar as 
configuranças
Figura 70 – Gestão de configuração segundo o CMMI
Essa área de processo envolve as seguintes atividades:
• selecionar os artefatos que compõem a configuração e as baselines do software;
• controlar as mudanças nos itens de configuração;
• manter a integridade das baselines;
• fornecer a situação precisa dos itens de configurações para desenvolvedores, usuários finais e 
clientes.
O CMMI descreve a área de processo da gerência da configuração em metas genéricas e específicas, 
de acordo com a Tabela 12.
Tabela 12 – Práticas do Modelo CMMI para a GCS
Práticas genéricas Práticas específicas
Estabelecer as baselines
• Identificar os itens de configuração
• Estabelecer um sistema de gestão de configuração
• Criar ou liberar as baselines 
Rastrear e controlar as mudanças
• Rastrear as solicitações de mudança
• Controlar os itens de configuração 
Estabelecer a integridade
• Estabelecer registros de configuração
• Rastrear as solicitações de mudança
• Executar auditorias da configuração 
Fonte: CMMI (2014).
As práticas genéricas compõem as atividades de estabelecer baselines, rastrear as mudanças e 
estabelecer a integridade dos itens de configuração.
As práticas específicas descrevem as tarefas que definem o que precisa ser realizado para que as 
práticas genéricas atinjam a meta.
168
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade IV
Para cada prática específica há um conjunto de atividades detalhadas denominadas de subpráticas, 
que têm o objetivo de atingir as metas específicas, com sugestão de produtos de trabalho e descrição de 
processos. Lembrando que o CMMI não define como você deve realizar a gestão de configuração. São 
descritas as atividades necessárias para definir o que deve ser feito para se atingir o nível de maturidade 
esperado pela equipe e pela organização envolvida.
8.3.1.1 Estabelecer baselines
Consiste no conjunto de tarefas para determinar quais são os itens de configuração que devem ser 
controlados. Envolve as seguintes atividades:
• Identificar itens de configurações
— selecionar os itens de configurações a partir dos artefatos previstos no projeto;
— atribuir identificadores únicos para os itens de configurações;
— especificar quando cada item de configuração será colocado sob GCS;
— identificar o proprietário responsável por cada item de configuração.
• Estabelecer um sistema de gerenciamento de configurações
— estabelecer um mecanismo para armazenar e recuperar itens de configurações no sistema de 
gerenciamento de configurações;
— armazenar e recuperar versões arquivadas de itens de configurações;
— armazenar, atualizar e recuperar registros de gerenciamento de configurações;
— criar relatórios de gerenciamento de configurações a partir do sistema de gerenciamento de 
configurações.
• Criar ou liberar baselines
— obter autorização do comitê ou do cliente antes de criar ou liberar baselines de um item de 
configuração;
— somente utilizar artefatos recuperados do sistema de gerenciamento de configurações;
— manter os itens de configuração disponíveis.
169
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
8.3.1.2 Rastrear e controlar mudanças
Consiste no conjunto de tarefas para controlar e rastrear mudanças nos itens de configuração 
definidos. Envolve as seguintes atividades:
• Rastrear solicitações de mudanças
— iniciar e registrar as solicitações de mudanças;
— analisar o impacto das mudanças e as correções propostas nas solicitações de mudanças;
— revisar as solicitações de mudanças que serão tratadas na próxima baseline com os que serão 
afetados pelas mudanças e obter a sua concordância;
— rastrear os status das solicitações de mudanças até o encerramento.
• Controlar itens de configurações
— controlar mudanças nos itens de configuração durante toda a vida do produto;
— obter a autorização apropriada antes que os itens de configurações modificados entrem no 
sistema de gerenciamento de configurações;
— executar o check‑in e o check out dos itens de configurações de uma maneira que mantenha 
a correção e a integridade dos itens de configuração;
— registrar as mudanças nos itens de configurações e os motivos das mudanças.
8.3.1.3 Estabelecer a integridade
Consiste no conjunto de tarefas para controlar e rastrear mudanças nos itens de configuração 
definidos. Envolve as seguintes atividades:
• Estabelecer registros de gerenciamento de configurações
— registrar com detalhes o status de cada item de configuração, de forma que cada um seja 
conhecido e versões anteriores possam ser recuperadas;
— assegurar que todos os envolvidos tenham acesso ao status dos itens de configuração e 
conhecimento destes;
— especificar e identificar a versão mais atual das baselines.
170
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade IV
• Executar auditorias de configurações
— analisar a integridade das baselines;
— confirmar que os registros de configurações identificam corretamente a configuração dos itens 
de configuração;
— confirmar a conformidade com os padrões e procedimentos de gerenciamento de configurações 
aplicáveis;
— rastrear os itens de ação da auditoria até o encerramento.
8.3.2 Padrão de gestão de configuração – ISO/IEC 12207
A norma ISO/IEC 12207 descreve o processo de gestão da configuração na parte referente aos 
processos de apoio e se baseia na aplicação de tarefas no ciclo de desenvolvimento de software para 
identificar e definir os itens de configuração, estabelecer suas baselines, controlar as mudanças e 
registrar a situação dos itens durante o processo. Resumindo, a ISO/IEC 12207 descreve os seguintes 
processos para a gerência de configuração, ilustrados na Figura 71:
• implementação do processo;
• identificação da configuração;
• controle da configuração;
• relato da situação da configuração;
• avaliação da configuração;
• gerência de liberação e distribuição.
Implementação 
do processo
Identificação 
dos itens de 
configuração
Controle da 
configuração
Relato da 
situação
Avaliação da 
configuração
Gerência da 
liberação
Figura 71 – Gestão de configuração segundo o ISO/IEC 12207
8.3.2.1 Implementação do processo
Descreve as atividades que são realizadas durante o gerenciamento da configuração, formando o 
plano de gerenciamento de configuração, cujo objetivo é padronizar os procedimentos e as ferramentas 
para todas as equipes de desenvolvimento da organização.
171
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
O plano de GCS também inclui o seu relacionamento com o plano de desenvolvimento de software 
e o plano de manutenção do software.
8.3.2.2 Identificação da configuração
A partir dos artefatos previstos no plano de desenvolvimento do software, os itens que têm de estar 
sob a gestão da configuração devem ser selecionados e nomeados, bem como estabelecidas versões para 
o controle das baselines de configuração.
A lista de itens sob a gestão da configuração deve ser aprovada pelos envolvidos no projeto.
8.3.2.3 Controle da configuração
Detalha o conjunto de atividades para identificação e registro dos pedidos de mudanças, 
implementação,verificação e liberação do item de software modificado. Nessa tarefa, são realizadas 
análise, classificação, priorização e avaliação das mudanças, além de aprovação ou rejeição do pedido 
de mudança e controle de acesso aos itens de configuração.
Devem existir registros de todas as alterações executadas para permitir uma eventual necessidade 
de rastreabilidade.
8.3.2.4 Avaliação da configuração
Descreve um conjunto de procedimentos para garantir que a implementação das mudanças esteja 
de acordo com as especificações e que os itens de configuração estejam adequadamente atualizados.
8.3.2.5 Relato da situação da configuração
Processo que prepara e exibe os registros da situação atual e do histórico dos itens de configuração 
do software. Os relatórios de situação podem conter, para cada item, suas últimas versões, o número de 
alterações, identificadores de liberação, a quantidade de liberações, dentre outros.
8.3.2.6 Gerência de liberação e distribuição
Na liberação e na distribuição dos itens de configuração, a documentação deve estar atualizada. 
O código e a documentação devem estar armazenados, empacotados e distribuídos de acordo com os 
procedimentos estabelecidos no plano de gerenciamento da configuração.
8.3.3 Padrão de gestão de configuração – ISO/IEC 9000‑3
A ISO/IEC 9000‑3 é a norma específica de organizações de desenvolvimento de software e a 
mais utilizada na implantação do SGQ. Segundo a descrição da norma, a gestão da configuração 
é aplicada durante o ciclo de vida de um produto, a fim de fornecer visibilidade e controle de suas 
funcionalidades e características físicas. Na norma ISO/IEC 9000‑3, o gerenciamento de configuração 
172
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade IV
está descrito em três partes: identificação, controle e situação dos itens sob a gestão de configuração, 
ilustradas na Figura 72.
Identificação e 
rastreabilidade
Controle de 
alterações
Relatório da 
situação da 
configuração
Figura 72 – Gestão de configuração segundo o ISO/IEC 9000‑3
 Saiba mais
Uma norma específica para o gerenciamento da configuração foi criada 
pela ISO: é a norma ISO/IEC 10007:95, que fornece diretrizes para gestão da 
configuração e pode ser acessada em .
Segundo o modelo, a organização que produz o software deve desenvolver e criar um plano de 
gestão que inclua as atividades de gestão de configuração, ferramentas, técnicas, metodologias usadas 
e o estado no qual os itens de configuração devem ser submetidos ao controle da configuração.
8.3.3.1 Identificação e rastreabilidade de configuração
A organização deve manter procedimentos para identificar os artefatos de software, durante todas 
as fases do ciclo de vida, nos quais devem ser aplicadas atividades para assegurar que cada item seja 
identificado, incluindo: especificações funcionais e técnicas, ferramentas de desenvolvimento usadas no 
projeto, todas as interfaces com outros itens de software e hardware e todos os documentos produzidos 
durante o processo de desenvolvimento do software.
8.3.3.2 Controle de alterações
A organização deve estabelecer e manter procedimentos para identificar, documentar, 
analisar criticamente e autorizar quaisquer alterações em itens de configuração. Para isso, antes 
da aceitação de uma alteração, uma análise de impacto da alteração verifica sua validade e os 
possíveis efeitos causados sobre outros itens de configuração. Durante o controle de alterações, a 
atividade de comunicação aos envolvidos quanto às alterações e para demonstrar a rastreabilidade 
das alterações precisa ser mantida.
8.3.3.3 Relatório de situação da configuração
A organização estabelece e mantém procedimentos para registrar, administrar e relatar a situação 
de itens de configuração, quanto a alterações, versões, requisições e implementação das alterações 
aprovadas.
173
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
8.3.4 Padrão de gestão de configuração – ISO/IEC 15504 (Spice)
Na norma ISO/IEC 15504, o processo de gerenciamento da configuração está no Nível 2, como no 
CMMI, e é considerado uma atividade de suporte aos demais processos do modelo de qualidade.
Estabelecer 
sistema 
biblioteca
Manter 
descrição dos 
itens
Identificar itens 
de configuração
Administrar 
e controlar 
mudanças
Manter e 
relatar histórico
Figura 73 – Gestão de configuração segundo o ISO/IEC 15504
A norma estabelece que o processo de gerência da configuração tem como objetivo criar e manter 
a integridade de todos os produtos que são elaborados e resultam do ciclo de vida de desenvolvimento 
do software. Como nos demais padrões, nem todos os produtos são controlados, sendo necessário que 
o conjunto de artefatos que precisam ter o controle do sistema de gerenciamento da configuração seja 
definido pela equipe do projeto e pelo cliente.
8.3.4.1 Estabelecer a biblioteca de gestão da configuração
Criar um repositório de software com controle de acesso para o armazenamento e a recuperação 
de itens sob a gestão da configuração, bem como para o compartilhamento dos itens entre as diversas 
equipes envolvidas no processo.
8.3.4.2 Identificar itens da configuração
Identificar cada artefato produzido no projeto de software e selecionar aqueles que ficarão sob a 
gerência da configuração.
8.3.4.3 Manter descrições dos itens da configuração
Fornecer e manter descrições para cada item de configuração, identificando‑o com sua descrição de 
função, o responsável pelo item e a partir de quando está sob o processo de gerência da configuração.
8.3.4.4 Administrar pedidos de mudança
Gravar, revisar, aprovar e rastrear todas as requisições de mudanças e todos os relatórios de problemas 
para todos os itens da configuração e suas versões.
8.3.4.5 Controlar as mudanças
Estabelecer um controle de acesso para manter a clareza e a integridade dos itens da configuração 
gerenciados pela biblioteca de configuração.
174
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade IV
8.3.4.6 Construir versões do produto
As versões dos itens de configuração (baselines) somente podem ser geradas a partir da biblioteca de 
configuração e depois de formalmente autorizado.
8.3.4.7 Manter históricos dos itens da configuração
Manter um histórico de cada item da configuração e das ações realizadas em um nível de detalhe 
suficiente para permitir que possam ser feitas recuperações de versões anteriores.
8.3.4.8 Relatar o estado da configuração
Reportar os resultados das atividades realizadas em cada item da configuração. Genericamente, os 
padrões descrevem um núcleo comum para a gestão da configuração relacionado a identificação, controle 
de versões e mudanças dos itens sob gerência da configuração. Exceção feita aos processos de segurança e 
auditoria não abrangidos por todos os padrões. O Quadro 24 apresenta um resumo dos padrões descritos.
Quadro 24 – Comparativo entre os padrões de gestão de configuração
Atividade de GCS CMMI ISO/IEC 12207 ISO/IEC 9000‑3 ISO/IEC 15504
Identificar item de 
configuração
A identificação dos 
artefatos de software que 
devem ser controlados, 
a partir da relação 
produzida no projeto 
Além da identificação 
do item, descreve a 
criação do processo de 
GCS 
Identifica os 
artefatos que devem 
ser controlados pelo 
GCS 
Além da identificação 
dos itens, descreve a 
criação da biblioteca 
para o repositório da 
GCS 
Controlar as versões
Os itens de configuração 
devem ser descritos, e 
suas baselines, mantidas 
mediante aprovação 
Não descrito 
explicitamente na 
norma 
Não descrito 
explicitamente na 
norma 
Construir versões dos 
itens de configuração 
apenas a partir da 
biblioteca de itens 
Gerenciar mudanças
Criar um processo formal 
para analisar, classificar 
e aprovar as mudanças 
identificadas nos itens 
de configuração 
Identificar os registros 
dos pedidos de 
mudanças, análise, 
classificação,priorização e avaliação 
das mudanças, além da 
aprovação ou rejeição 
do pedido de mudança
Fazer uma análise 
de impacto da 
alteração para 
verificar sua validade 
e os possíveis efeitos 
causados sobre 
outros itens de 
configuração
Gravar, revisar, 
aprovar e rastrear as 
mudanças e garantir 
que estas sejam feitas 
por pessoal autorizado 
e aprovadas ao seu 
final 
Auditoria de 
configuração
São realizadas 
regularmente para 
verificar aderência ao 
processo de GCS 
Não estão descritas no 
processo 
Não estão descritas 
no processo 
Não estão descritas no 
processo 
Registro de status da 
configuração
Todas as mudanças 
devem ter suas 
informações de 
descrição, de quem 
alterou e quando 
mantidas em histórico 
Descrever a situação de 
cada item contendo: o 
número de alterações, 
identificadores de 
liberação, a quantidade 
de liberações, dentre 
outras
Relatar a situação 
dos itens quanto às 
alterações, versões, 
requisições e à 
implementação das 
alterações aprovadas
Manter um histórico 
dos itens com um 
nível de detalhe 
suficiente para 
permitir a recuperação 
de versões anteriores 
A gestão da configuração é um processo essencial para uma gestão controlada e madura dos 
artefatos produzidos durante o ciclo de desenvolvimento de um software. As organizações de 
175
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
Tecnologia da Informação devem possuir esse processo implantado para iniciar qualquer modelo de 
qualidade de software.
O processo de GCS é simples e barato, pois as ferramentas não possuem custos de aquisição de 
licença. A definição do processo e o treinamento das equipes constituem a parte mais demorada do 
gerenciamento da configuração.
Alguns benefícios que uma organização pode alcançar com a implantação do GCS são:
• ganhos em maturidade no desenvolvimento de software;
• maior capacidade de executar projetos mais complexos;
• capacidade de retornar a versões anteriores do software;
• melhoria da comunicação dos desenvolvedores;
• melhoria da competitividade;
• aumento da qualidade.
 Saiba mais
O IEEE também possui um padrão para gestão de configuração disponível 
em , descritos nas normas IEEE 1042/1987 e IEEE 828/1998.
8.4 Application Lifecycle Management (ALM)
O contexto abordado até o momento sobre gestão de mudanças e gestão da configuração tem 
ligação direta com o conceito de gerência do ciclo de vida das aplicações, ou Application Lifecycle 
Management (ALM).
ALM é a gestão integrada entre as necessidades de atender ao negócio e aos processos de Engenharia 
de Software, por meio da criação de procedimentos e do suporte de ferramentas que fazem a automação 
dos processos. Permite o gerenciamento contínuo do processo de desenvolvimento de software, 
deixando clara a interligação de requisitos, manutenção, mudança, configuração e distribuição. Para 
isso, compõe‑se de cinco processos:
• gerenciamento de requisitos;
• gerenciamento de configuração;
• gestão de mudança;
176
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade IV
• versionamento e integração;
• distribuição de software.
8.4.1 Gerenciamento de requisitos
Os requisitos de um software são as necessidades dos usuários que têm de ser atendidas por um novo 
software ou um pedido de mudança para ser incluída em uma aplicação já existente. O gerenciamento 
de requisitos é composto por um conjunto de atividades para levantar as necessidades dos usuários, 
entender essas necessidades, documentá‑las, validar com os usuários e conseguir rastrear todo e 
qualquer requisito ao longo do ciclo de vida do software. As principais atividades envolvidas na gestão 
de requisitos são:
• documentar os requisitos funcionais e os não funcionais;
• identificar, analisar e selecionar as necessidades de negócio;
• priorizar o que deve ser feito;
• analisar a interdependência dos requisitos;
• relacionar com os requisitos de arquitetura;
• validar os requisitos com os usuários.
8.4.2 Gerenciamento da configuração
O processo de construção de uma aplicação envolve o controle de diversos artefatos de software, os 
quais podem sofrer diversas modificações durante seu ciclo de vida. Como vimos, o GCS é responsável 
por manter e gerenciar esses artefatos e por manter a rastreabilidade e o versionamento desses itens. 
Muitas pessoas confundem ALM com gerenciamento da configuração, mas o GCS isolado no contexto 
de desenvolvimento de software não garante o processo de ALM completo.
8.4.3 Gestão de mudança
Processo para avaliar, coordenar e decidir sobre a realização de mudanças em itens de configuração. 
Possui relacionamento direto com o gerenciamento da configuração. As mudanças aprovadas são 
implementadas em todos os artefatos relacionados.
8.4.4 Versionamento e integração
Consiste nas atividades de reunir os diversos elementos que compõem uma versão de software e 
agrupá‑las em um único pacote, a fim de ser testado e distribuído dentro do ambiente do projeto. Para 
esse processo, temos:
177
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
• recuperar todos os artefatos do repositório de código;
• mapear os artefatos com a nova versão da aplicação;
• compilar o código;
• organizar a aplicação, conforme definido;
• criar um pacote de instalação.
8.4.5 Distribuição do software
Tem como objetivo garantir a consistência das diversas versões de uma aplicação, pois há várias 
versões durante o ciclo de vida de um software. Sem um processo de GCS adequado, corre‑se alto risco 
com a perda da integridade da aplicação, gerando grande retrabalho e gastos para a correta distribuição. 
Para o correto funcionamento da distribuição do software, é essencial um processo de GCS consistente 
e maduro. Algumas atividades de distribuição:
• identificar o pacote correto de versionamento;
• documentar as dependências entre as versões;
• automatizar a distribuição das versões ou correções;
• distribuir os pacotes de software para validação, testes e produção.
 Resumo
Nesta unidade, abordamos que a manutenção de software é uma atividade 
essencial para que a aplicação desenvolvida tenha um longo ciclo de vida. 
No entanto, a manutenção depende da estrutura da aplicação desenvolvida, 
ou seja, documentação, padrão de codificação e foco em criar um software 
modularizado para facilitar o processo de desenvolvimento futuro e reduzir os 
custos das mudanças que podem atingir até 60% do custo original.
Vimos que essas manutenções surgem a partir da evolução das 
necessidades de negócio para atender à evolução das regras ou para alinhar 
a competição no mercado, de ser uma demanda baseada na exigência da 
lei ou da necessidade de atender a uma norma solicitada pelo cliente, para 
corrigir defeitos que surgem ao longo da vida útil de um sistema e para 
atender à evolução tecnológica de hardware e software.
Aprendemos também que a norma ISO/IEC 12207 descreve um 
procedimento para manutenção na engenharia dos seus processos 
fundamentais, porém a norma ISO/IEC 14764 (2006) é específica para 
178
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade IV
manutenção e descreve conceitos e um processo a ser aplicado para os 
diversos tipos de manutenção. Esses tipos podem ser: manutenções 
corretivas, que se referem à correção de defeitos que ocorrem após o 
software entrar em produção; manutenções perfectivas, relacionadas às 
novas funcionalidades solicitadas pelos usuários e também denominadas 
de evolutivas ou de melhoria; manutenções adaptativas, voltadas para 
atender as demandas técnicas da evolução do software no ambiente 
computacional; e manutenções preventivas, que são análises prévias para 
tentar identificar defeitos antes que ocorram em produção.
Vimos diversos conceitos intrínsecos ao processo de manutenção, como: 
evolução, referente a mudanças que incluemcomportamentos na aplicação; 
alteração, que modifica algo já existente; correção, para tratar defeitos; 
melhoramento, referente a melhorias técnicas; e manutenibilidade, que é 
um requisito não funcional referente à facilidade com a qual um software 
pode sofrer uma mudança.
Abordamos que, além dos tipos de manutenção apresentados, a própria 
engenharia reversa também pode ser tratada como tal, uma vez que sua 
função é criar uma nova aplicação a partir de uma existente, utilizando o 
código‑fonte como a principal referência de requisitos. Ocorre quando a 
manutenção de um sistema começa a se tornar inviável em termos técnicos 
(sistema obsoleto) ou financeiros (manutenções demoradas e difíceis, e 
recursos especializados escassos).
Vimos ainda outro tipo de manutenção que onera bastante os custos: 
a manutenção de sistemas legados, que são aplicações muito antigas, das 
quais não há documentação, nem pessoas que conheçam o código. Aliada a 
isso, há a resistência dos desenvolvedores mais experientes em manter esses 
softwares, que acabam nas mãos de desenvolvedores menos experientes 
e tornam‑se um fator de desmotivação, constituindo um desafio para as 
equipes de manutenção.
Abordamos que, em relação à equipe de manutenção, é importante que 
se tenha os papéis claramente definidos quanto às suas responsabilidades, 
para que o processo de manutenção sofra menos impacto e conflitos sejam 
evitados. Os principais envolvidos são: os usuários finais, que são aqueles 
responsáveis pelas solicitações de correções ou de melhoria e que também 
vão dar o aceite nas mudanças; os responsáveis pelo produto, aqueles 
que dão suporte financeiro para que a aplicação sofra as mudanças; a 
gerência de Tecnologia da Informação, que cuida de receber as solicitações 
dos usuários e gerar a demanda para a gerência de manutenção, que é 
responsável por realizar análise, classificação, priorização e implementação 
das mudanças junto com a equipe de manutenção.
179
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
Estudamos também que outro fator que afeta os custos das 
manutenções são as condições iniciais do processo, podendo‑se classificar 
as manutenções em estruturada e não estruturada. As manutenções não 
estruturadas se referem àquelas aplicações cuja única documentação é o 
código‑fonte, tornando o esforço maior, de alto risco e alta complexidade. 
As manutenções estruturadas se dão em softwares desenvolvidos com 
documentação, padrões e preocupação com a qualidade, conferindo‑lhes 
um alto grau de manutenibilidade.
Vimos que a norma ISO/IEC 14764 (2006) define cinco atividades básicas 
para um processo de manutenção: a definição do processo, a análise da 
mudança, a implementação da mudança, o aceite e a revisão da alteração, 
e o processo de migração e de retirada do software de produção.
Abordamos ainda que a definição do processo, junto com a definição dos 
papéis e das responsabilidades, estabelece qual é o fluxo de um pedido de 
mudança realizado por um usuário. Basicamente define que, após receber o 
pedido de mudança, este seja avaliado quanto a novas funções ou correção. 
Em se tratando de correção, deve‑se avaliar a gravidade. Se for grave, implementar 
imediatamente; caso contrário, fazer a avaliação e a classificação da mudança 
como para as solicitações de novas funcionalidades. Após isso, obtém‑se a 
aprovação dos usuários e priorizados na fila de manutenção. As mudanças não 
aprovadas devem ser documentadas e armazenadas.
Vimos que a análise da mudança consiste na avaliação profunda da 
solicitação, bem como de seus riscos e seus impactos na aplicação existente. 
Avaliam‑se prazo e custos e submete‑se à aprovação dos usuários. O 
processo de implementação da mudança deve seguir os procedimentos de 
desenvolvimento utilizados pela organização.
Abordamos também que, após a codificação e os testes das mudanças, 
estas deverão ser submetidas à aceitação dos usuários quanto à qualidade 
e ao preenchimento dos requisitos solicitados. Envolvem também as ações 
de garantia da qualidade, como revisões, inspeções e testes.
Vimos ainda que o processo de migração refere‑se à elaboração de 
um procedimento para que os dados de um software em produção sejam 
levados para outro ambiente ou para serem utilizados em outra aplicação. 
Esse processo deve ser formalizado por meio de um plano de migração que 
descreva detalhadamente o que será migrado, o de‑para dos campos e as 
regras de conversão, que precisam do aceite dos usuários.
Abordamos também que o processo de retirada de produção está 
relacionado à descontinuidade da aplicação por alcançar o fim do seu 
180
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade IV
ciclo de vida, seja pela inviabilidade técnica ou econômica, seja pela sua 
substituição por um novo software. Também exige um plano formal 
validado pelos usuários descrevendo o que e como o processo será realizado, 
principalmente, o paralelismo e a transição das aplicações.
Como visto, as manutenções são diretamente afetadas pela forma que 
foram desenvolvidas. Os desenvolvimentos orientados a objetos e baseados 
em componentes são os que causam menos impactos, mas não estão livres de 
problemas. Ambos se baseiam na característica de reúso de código, que minimiza 
os testes, mas, em caso de modificação, geram um esforço maior para garantir 
que tudo o que os utiliza continue funcionando adequadamente.
Vimos também que outro impacto a analisar é o relacionado ao processo de 
desenvolvimento ágil que, em razão das suas características, facilita a interação 
de usuário e desenvolvedor durante o ciclo de manutenção. Porém, as vantagens 
e desvantagens são as mesmas do processo de desenvolvimento utilizado, seja 
este orientado a objetos ou baseado em componentes.
Aprendemos que o Gerenciamento de Configuração de Software (GCS), 
também conhecido como Software Configuration Management (SCM), é 
um processo da engenharia de software que tem por objetivo estabelecer 
as condições para a organização dos artefatos de software, controlar suas 
versões, controlar as suas alterações e manter a integridade de tudo o que 
foi produzido durante o ciclo de vida de um projeto de software, bem como 
garantir seu armazenamento adequado.
Estudamos que, para realizar um processo de GCS eficiente, é 
preciso definir um repositório para o armazenamento dos artefatos, 
a estrutura de diretórios, a nomenclatura de cada um dos artefatos 
envolvidos no processo de gestão da configuração e o controle de 
acesso aos artefatos. O próximo passo consiste em identificar, a partir 
do conjunto de artefatos, quais devem ter o controle, além de serem 
definidos como itens de configuração. Esses itens estão submetidos 
a um controle rigoroso das versões relacionadas às mudanças que 
podem sofrer ao longo do ciclo de vida, mediante um processo de 
análise, classificação, priorização e validação das alterações. Todas 
essas mudanças devem ser rastreadas a qualquer momento para 
exibir a situação do artefato. Um processo de auditoria dos itens de 
configuração deve estar estabelecido para a verificação e a garantia 
de aderência aos padrões de GCS.
Vimos que esse é o processo básico da GCS, mas existem padrões que 
descrevem detalhadamente o processo de gestão da configuração, como 
o do modelo CMMI, a ISO/IEC 12207, a ISO/IEC 9000‑3 e a ISO/IEC 15504.
181
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
 Exercícios
Questão 1. Segundo Boehm (1988), no ciclo de vida de um software a fase de manutenção é a mais 
problemática e representa mais de 60% de todo o esforço de TI de uma organização. A norma ISO/IEC 
14764 (2006) é específica para descrever o ciclo de manutenção do software, definindo os conceitos 
envolvidos e estabelecendo um processo claro para tratar e apoiar os desenvolvedores nessa complexa 
etapa. A norma citada especificaquatro tipos distintos de manutenção e em apenas uma descreve 
como corrigir defeitos encontrados em um software em produção, defeitos normalmente identificados 
pelos usuários finais. Qual seria esse tipo de manutenção, descrito na norma ISO/IEC 14764? Assinale a 
alternativa correta.
A) Manutenção perfectiva.
B) Manutenção adaptativa.
C) Manutenção corretiva.
D) Manutenção preventiva.
E) Manutenção perfectiva e adaptativa.
Resposta correta: alternativa C.
Análise das alternativas
A) Alternativa incorreta.
Justificativa: não corrige defeitos de software em produção. A manutenção perfectiva realiza 
ações para incluir novas funcionalidade ou realizar alterações cujos objetivos sejam satisfazer novas 
necessidades dos usuários.
B) Alternativa incorreta.
Justificativa: não corrige defeitos de software em produção, muito menos defeitos encontrados pelo 
usuário final. A manutenção adaptativa realiza processos para adequar o software a novas tecnologias, 
modelos de gestão etc., isto é, de uma nova legislação.
C) Alternativa correta. 
Justificativa: a manutenção corretiva executa ações para corrigir defeitos encontrados em 
um software em produção, normalmente observados pelo usuário final. Na maioria dos casos, 
essas manutenções possuem uma equipe dedicada que realiza atividades rotineiras para a 
solução de defeitos.
182
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade IV
D) Alternativa incorreta. 
Justificativa: não corrige defeitos de software em produção. A manutenção preventiva é proativa e 
planejada, realiza processos para melhorar algum aspecto deficiente no software, como desempenho, 
segurança, defeitos ainda não identificados pelos usuários, usabilidade etc.
E) Alternativa incorreta. 
Justificativa: tanto em conjunto como individualmente, essas manutenções não corrigem defeitos 
de software em produção. Quando necessário os tipos de manutenção podem ser aplicados de forma 
sequencial, e não de forma simultânea.
Questão 2. A norma ISO/IEC 14764 (2006) define cinco atividades básicas para um processo de 
manutenção: a definição do processo, a análise da mudança, a implementação da mudança, o aceite 
e revisão da alteração, o processo de migração e de retirada de produção do software. Em relação ao 
processo de migração, assinale a alternativa correta.
I – Procedimento elaborado para avaliação profunda da solicitação, seus riscos e seus impactos na 
aplicação existente.
II – Procedimento elaborado para que os dados de um software em produção sejam levados para 
outro ambiente.
III – Procedimento realizado para que os dados de um software em produção sejam utilizados em 
outra aplicação. Esse procedimento deve ser formalizado através de um detalhamento do que será 
migrado.
IV – Procedimento que está relacionado à descontinuidade da aplicação por alcançar o fim do seu 
ciclo de vida, seja pela inviabilidade técnica ou econômica, seja pela sua substituição por um novo 
software.
É correto apenas o que se destaca em:
A) I, II.
B) I, II, III, IV.
C) II, III.
D) III.
E) II.
Resposta desta questão na plataforma.
183
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
FIGURAS E ILUSTRAÇÕES
Figura 5
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS (ABNT). NBR ISO 9001: Sistemas de gestão da 
qualidade – Requisitos. Rio de Janeiro, 2000b. p. 2.
Figura 9
McCALL, J.; RICHARDS, P. K.; WALTERS, G. F. Factors in Software Quality: Concept and Definitions of 
Software Quality. RADC_TR‑77‑369, v. 1, Nov. 1977. Final Technical Report. Adaptado.
Figura 10
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). ISO/IEC 9126‑1: International Standard. 
Information Technology – Software engineering – Product quality – Part 1: Quality model. Genebra, 
2001. p. 7.
Figura 11
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). ISO/IEC 9126‑1: International Standard. 
Information Technology – Software engineering – Product quality – Part 1: Quality model. Genebra, 
2001. p. 1. Adaptado.
Figura 17
COUTO, A. B. CMMI: integração dos modelos de capacitação e maturidade de sistemas. Rio de Janeiro: 
Ciência Moderna, 2007. P. 47. Adaptado.
Figura 50
CRISPIN, L; GREGORY, J. Agile Testing: A Practical Guide for Testers and Agile Teams. New York: 
Addison Wesley, 2009. Adaptado.
Figura 51
BECK, K. TDD: desenvolvimento guiado por testes. São Paulo: Bookman, 2010. Adaptado.
REFERÊNCIAS
ANTONIONI, J. A. Qualidade em software: manual de aplicação da ISO‑9000. São Paulo: Makron 
Books, 1995.
184
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS (ABNT). NBR ISO 9000: Sistemas de gestão da 
qualidade – Fundamentos e vocabulário. Rio de Janeiro, 2000a.
___. NBR ISO 9001: Sistemas de gestão da qualidade – Requisitos. Rio de Janeiro, 2000b.
ASSOCIAÇÃO BRASILEIRA PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO (SOFTEX). 
MPS.BR – Melhoria de processo do software brasileiro: guia geral – Versão 1.1. 2006.
BECK, K. TDD: desenvolvimento guiado por testes. São Paulo: Bookman, 2010.
BOEHM, B. Software Engineering. IEEE Trans Computers, Dec. 1976, p. 1226‑41.
___. A Spiral Model of Software. Development and Enhancement, IEEE Computer, 1988.
CHIKOFSKY, E. J.; CROSS II, J. H. Reverse Engineering and Design Recovery: A Taxonomy. IEEE Software, 
v. 7, n. 1, p. 13‑7, 1990.
CORTÊS, M. et al. Modelos de qualidade de software. Campinas: Unicamp, 2001.
COUTO, A. B. CMMI: integração dos modelos de capacitação e maturidade de sistemas. Rio de Janeiro: 
Ciência Moderna, 2007.
CRISPIN, L.; GREGORY, J. Agile Testing: A Practical Guide for Testers and Agile Teams. New York: 
Addison Wesley, 2009.
CROSBY, P. B. Qualidade, falando sério. São Paulo: McGraw‑Hill, 1990.
DIJKSTRA, E. W. Notes on Structured Programming. Circulated privately, Apr. 1970.
GUERRA A. C.; COLOMBO, R. M. T. Tecnologia da informação: qualidade de produto de software. 
Brasília: PBQP Software, 2009.
HETZEL, W.C. The Growth of Software Testing. Englewood: Prentice‑Hall, 1988.
HUMPHREY, W. Managing the Software Process. New York: Addison Wesley, 1989.
lEEE. IEEE Std 610.12 – Glossário de padrão de engenharia de software. 1990.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). ISO 10007: Quality management– 
Guidelines for configuration management. Genebra, 1995.
___. ISO/IEC 9000‑3: International Standard. Information Technology – Guidelines for the application 
of ISO 9001:2000 to computer software. Genebra, 2004.
185
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
___. ISO/IEC 9126‑1: International Standard. Information Technology – Software engineering – 
Product quality – Part 1: Quality model. Genebra, 2001.
___. ISO/IEC 9126‑2: International Standard. Information Technology – Software engineering – 
Product quality – Part 2: External metrics. Genebra, 2003a.
___. ISO/IEC 9126‑3: International Standard. Information Technology – Software engineering – 
Product quality – Part 3: Internal metrics. Genebra, 2003b.
___. ISO/IEC 9126‑4: International Standard. Information Technology – Software engineering – 
Product quality – Part 4: Quality in use metrics. Genebra, 2004.
___. ISO/IEC 12207: International Standard. Information Technology – Systems and software 
engineering – Software life cycle processes. Genebra, 2008.
___. ISO/IEC 14598‑1: International Standard. Information Technology – Software Product Evaluation 
– Part 1: General Overview. Genebra, 1999a.
___. ISO/IEC 14598‑2: International Standard. Information Technology – Software Product Evaluation 
– Part 2: Planning and Management. Genebra, 2000.
___. ISO/IEC 14598‑3: International Standard. Information Technology – Software Product Evaluation 
– Part 3: Process for Developers. Genebra, 2000.
___. ISO/IEC 14598‑4: International Standard. Information Technology – Software Product Evaluation 
– Part 4: Process for Acquirers. Genebra, 1999b.
___. ISO/IEC14598‑5: International Standard. Information Technology – Software Product Evaluation 
– Part 5: Process for Evaluators. Genebra, 1998.
___. ISO/IEC 14598‑6: International Standard. Information Technology – Software Product Evaluation 
– Part 6: Evaluation Modules. Genebra, 2001.
___. ISO/IEC 14764: Software Engineering – Software Life Cycle Processes — Maintenance. 2. ed. 
Genebra, 2006.
___. ISO/IEC 15504‑1 (Spice): International Standard. Information Technology – Process assessment – 
Part 1: Concepts and vocabulary. Genebra, 2004.
___. ISO/IEC 15504‑2 (Spice): International Standard. Information Technology – Process assessment – 
Part 2: Performing an assessment. Genebra, 2003c.
___. ISO/IEC 15504‑3 (Spice): International Standard. Information Technology – Process assessment – 
Part 3: Guidance on performing an assessment. Genebra, 2004.
186
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
___. ISO/IEC 15504‑4 (Spice): International Standard. Information Technology – Process assessment – 
Part 4: Guidance on use for process improvement and process capability determination. Genebra, 2004.
___. ISO/IEC 15504‑5 (Spice): International Standard. Information Technology – Process assessment – 
Part 5: An exemplar software life cycle process assessment model. Genebra, 2012.
___. ISO/IEC 15504‑6 (Spice): International Standard. Information Technology – Process assessment – 
Part 6: An exemplar system life cycle process assessment model. Genebra, 2013.
___. ISO/IEC 15504‑7 (Spice): International Standard. Information Technology – Process assessment – 
Part 7: Assessment of organizational maturity. Genebra, 2008.
___. ISO/IEC 15504‑8 (Spice): International Standard. Information Technology – Process assessment – 
Part 8: An exemplar process assessment model for IT service management. Genebra, 2012.
___. ISO/IEC 15504‑9 (Spice): International Standard. Information Technology – Process assessment – 
Part 9: Target process profiles. Genebra, 2011.
___. ISO/IEC 25000: International Standard. Information Technology – Systems and software 
engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – Guide to 
SQuaRE. Genebra, 2014.
KOSCIANSKI, A.; SOARES, M. S. Qualidade de software. Rio de Janeiro: Novatec, 2010.
McCABE, T. A Complexity Measure. IEEE Transactions on Software Engineering, p. 308‑20, 1976.
McCALL, J.; RICHARDS, P. K.; WALTERS, G. F. Factors in Software Quality: Concept and Definitions of 
Software Quality. RADC_TR‑77‑369, v. 1, Nov. 1977. Final Technical Report.
MYERS, G. The Art of Software Testing. 2. ed. New Jersey: John Wiley and Sons, 2004.
PAULA FILHO, W. Engenharia de software: fundamentos, métodos e padrões. Rio de Janeiro: LTC, 2011.
PEZZÉ, M.; YOUNG, M. Teste e análise de software: processo, princípios e técnicas. Porto Alegre: 
Bookman, 2008.
PFLEEGER, S. L. Engenharia de software: teoria e prática. 2. ed. São Paulo: Prentice Hall Brasil, 2007.
PRESSMAN, R. S. Engenharia de software. São Paulo: McGraw‑Hill, 2006.
RAKITIN, S. R. Software Verification and Validation: a Practitioner’s Guide. London: Artech House, 1997.
RAPCHAN, F. A Norma ISO 9000‑3. Vitória: Ufes, 2005. Disponível em: . Acesso em: 20 jul. 2014.
187
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
RIOS, E.; MOREIRA, T. Testes de software. 3. ed. São Paulo: Alta Books, 2013.
ROCHA, A. R. C. et al. Qualidade de software: teoria e prática. São Paulo: Prentice Hall, 2001.
SCHULMEYER, G. Handbook of Software Quality Assurance. New York: Prentice Hall, 1999.
SOFTWARE ENGINEERING INSTITUTE (SEI). Standard CMMI Appraisal Method for Process Improvement 
(SCAMPISM) A, Version 1.2: Method Definition Document. 2006. Disponível em: . Acesso em: 20 jul. 2014.
SOMMERVILLE, I. Engenharia de software. São Paulo: Pearson, 2013.
TELES, F. S. Um processo para análise de desempenho de produtos de software. Pernambuco: UFPE, 2005.
VILAS BOAS, A. L. C. Qualidade e avaliação de produto de software. Lavras: Ufla/Faepe. 2004.
Sites
.
.
.
.
.
.
.
.
.
.
188
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Informações:
www.sepi.unip.br ou 0800 010 9000
 
 
 
A IMPORTÂNCIA DA ATIVIDADE DE 
TESTE NO DESENVOLVIMENTO DE 
SOFTWARE 
 
Karla Pires de Souza (FPM ) 
karlapsouza@hotmail.com 
Angelita Moutin Segoria Gasparotto (FPM ) 
angelita@usp.br 
 
 
 
A atividade de teste de software tem um objetivo de encontrar defeitos 
inseridos no decorrer do processo de desenvolvimento. Estima-se que o 
custo com correção de falhas aumenta com o avanço das fases, mesmo 
assim, em algumas empresas a fasse de teste ainda não é executada 
com tempo hábil para atividade ou os testes são efetuados pelos 
próprios desenvolvedores dos sistemas. Este artigo tem o objetivo de 
apresentar conceitos de teste de software, assim como um estudo de 
caso realizado em um centro de desenvolvimento de software, onde se 
pode constatar a importância da execução dos testes por uma equipe 
qualificada e estruturada, tal resultado foi levantado a partir da 
análise de defeitos e horas trabalhados de três projetos da empresa. 
 
Palavras-chaves: Teste de software; Qualidade; Desenvolvimento de 
software. 
XXXIII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO 
A Gestão dos Processos de Produção e as Parcerias Globais para o Desenvolvimento Sustentável dos Sistemas Produtivos 
Salvador, BA, Brasil, 08 a 11 de outubro de 2013. 
 
 
 
XXXIII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO 
A Gestão dos Processos de Produção e as Parcerias Globais para o Desenvolvimento Sustentável dos Sistemas Produtivos 
Salvador, BA, Brasil, 08 a 11 de outubro de 2013. 
 
 
 
 
 
 
2 
 
1. Introdução 
A atividade de teste em várias empresas é executada pela equipe de desenvolvimento de 
software, que muitas vezes não possui a qualificação adequada para exercer tal tarefa. Isto 
ocorre, pois a atividade não é considerada tão importante no processo de construção do 
software. Devido à sobrecarga de trabalho e aos curtos prazos a atividade de teste é afetada e 
como resultado é gerado um sistema com grande quantidade de defeitos. 
Estima-se que o custo com correção de falhas avança com o passar das fases de 
desenvolvimento de software, entretanto, mesmo com este aumento de custo, muitas empresas 
ainda negligenciam a fase de teste. 
Este artigo tem a finalidade de listar a importância da atividade do teste no desenvolvimento 
de software, assim como mostrar os benefícios obtidos com a execução dos testes e apresentar 
alguns tipos de teste existentes. Por fim será evidenciada, através de um estudo de caso, a 
quantidade de defeitos evitados/corrigidos após execução dos testes. 
 
2. Teste de software 
A atividade de teste é uma das etapas do ciclo de desenvolvimento de software e tem o 
objetivo de relatar possíveis defeitos existentes no sistema para que estes sejam solucionados. 
Nesta fase verifica-se se o comportamento do sistema está de acordo com o especificado nos 
requisitos levantados junto ao cliente. A partir desta atividade pode-se diagnosticar o grau de 
qualidade do sistema. O principal objetivo da realização do teste de software é reduzir a 
probabilidade de ocorrência de erros quando o sistema estiver em produção (MOLINARI, 
2012). 
Na década de 70 a execução do teste nos softwares era feita pelos próprios desenvolvedores 
dos sistemas, a atividade era vista como uma tarefa secundária, sem muita importância, feita 
apenas se o prazo de entrega e custo doproduto permitisse. Com o passar do tempo, devido à 
concorrência existente no mercado e ao aumento da complexidade dos sistemas, o nível de 
exigência por qualidade aumentou e com isso a necessidade de testes mais eficazes. 
 
XXXIII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO 
A Gestão dos Processos de Produção e as Parcerias Globais para o Desenvolvimento Sustentável dos Sistemas Produtivos 
Salvador, BA, Brasil, 08 a 11 de outubro de 2013. 
 
 
 
 
 
 
3 
Para Pressman (2002), "teste de software é um elemento crítico da garantia de qualidade de 
software e representa a revisão final da especificação, projeto e geração de código". Por ser a 
última etapa, antes da entrega ao cliente, à fase de teste tem a responsabilidade de encontrar as 
falhas inseridas no decorrer do projeto. 
Pressman (2002) define qualidade como a satisfação de requisitos funcionais e de 
desempenho explicitamente declarados, normas de desenvolvimento explicitamente 
documentadas e características implícitas que são esperadas em todo software desenvolvido 
profissionalmente. O conceito de qualidade é variável, para a equipe de desenvolvimento de 
software um produto possui qualidade quando se comporta conforme está descrito nos 
requisitos, já para o cliente um produto terá qualidade quando este atender suas necessidades. 
Devido ao aumento da exigência por qualidade, várias normas, metodologias ou modelos (ágil 
e RUP, por exemplo) e órgão reguladores como CMMI, MPS.Br e ISO foram criados. 
 
3. Custo da não qualidade 
Além de colaborar para obtenção de um produto com qualidade, a atividade de teste tem o 
papel fundamental na redução de custos com possíveis reparos ao sistema. Em 1979 Myers 
apresentou em seu livro “The Art of Software Testing” (A arte de teste de software) a Regra 
de 10, que constatava que quanto mais cedo descoberto e corrigido um erro, menor é o seu 
custo para o projeto. De acordo com (MYERS, 1979) o custo em correção cresce 
exponencialmente 10 vezes para cada estágio que o projeto avança, conforme apresentado no 
gráfico abaixo (Figura1), ou seja, defeitos encontrados nas fases iniciais do desenvolvimento 
do software são mais baratos de serem corrigidos do que aqueles encontrados quando o 
software já está em produção. 
Figura 1 - Custo dos defeitos com passar das fases do projeto 
 
XXXIII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO 
A Gestão dos Processos de Produção e as Parcerias Globais para o Desenvolvimento Sustentável dos Sistemas Produtivos 
Salvador, BA, Brasil, 08 a 11 de outubro de 2013. 
 
 
 
 
 
 
4 
 
Fonte: (BASTOS; RIOS; CRISTALLI; MOREIRA, 2007) 
 
O teste de software não é uma atividade barata e fácil, normalmente o valor gasto com teste 
varia de 30% a 40% do valor total do projeto, dependendo das técnicas de teste que foram 
utilizadas e da tolerância a falhas exigidas pelo projeto (BASTOS; RIOS; CRISTALLI; 
MOREIRA, 2007). Como é possível verificar na imagem abaixo (Figura2) o custo com falhas 
é muito maior do que custo gasto com atividades de prevenção como revisões e inspeções em 
artefatos e código-fonte. 
Figura 2 - Categoria dos custos com falhas 
 
Fonte: (FROTA, 1999) 
 
Atualmente ainda existem empresas que negligenciam a atividade de teste devido ao 
custo e tempo exigidos pela fase. Muitas vezes os testes ainda são executados por 
desenvolvedores ou outro profissional que tenha conhecimento das regras de negócio do 
sistema. Também é comum que a fase de teste seja abreviada para que o prazo e custo 
do projeto sejam alcançados, consequentemente, é comum entregar ao cliente um 
 
XXXIII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO 
A Gestão dos Processos de Produção e as Parcerias Globais para o Desenvolvimento Sustentável dos Sistemas Produtivos 
Salvador, BA, Brasil, 08 a 11 de outubro de 2013. 
 
 
 
 
 
 
5 
software com defeitos não revelados (MOLINARI, 2012). Tal atitude pode acarretar um 
alto custo à empresa para solucionar os defeitos encontrados após a entrega, assim como 
a queda de credibilidade e satisfação do cliente. 
 
4. Verificação e validação 
Para que os possíveis defeitos inseridos durante o andamento do projeto sejam encontrados o 
quanto antes, é importante que atividades de verificação e validação sejam executadas. O 
objetivo da verificação é garantir que sistema está sendo desenvolvido da maneira correta, 
dentro das normas e metodologia adotadas para o projeto, nesta atividade normalmente são 
realizadas revisões e inspeções dos artefatos e código-fonte, ou seja, uma verificação estática 
(SILVA, 2013). 
Na validação é verificado se o sistema foi construído conforme descrito nos requisitos, esta é 
uma verificação dinâmica, pois é necessário navegar pelo sistema para detectar possíveis 
diferenças entre o sistema e os artefatos do cliente. 
O modelo em V é um dos mais aceitos atualmente, ele enfatiza as atividades de verificação e 
validação com o objetivo de encontrar defeitos gerados durante o desenvolvimento do 
software e minimizar os riscos do projeto. Este modelo reforça o entendimento de que a 
atividade de teste não deve ser efetuada apenas no fim do projeto e sim em todo o 
desenvolvimento do sistema. Na Figura acima (Figura3) é possível verificar o paralelismo 
entre as atividades de teste (à direita) e desenvolvimento (à esquerda). 
 
Figura 3 - Modelo em V 
 
XXXIII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO 
A Gestão dos Processos de Produção e as Parcerias Globais para o Desenvolvimento Sustentável dos Sistemas Produtivos 
Salvador, BA, Brasil, 08 a 11 de outubro de 2013. 
 
 
 
 
 
 
6 
 
Fonte: (SILVA, 2013) 
4.1. Níveis ou estágios de teste 
Os testes podem ser divididos em quatro níveis conforme exibido na Figura 3, estes níveis 
definem basicamente a fase em que estes serão executados, ou seja, qual o melhor momento 
de executar determinado teste (BASTOS; RIOS; CRISTALLI; MOREIRA, 2007). 
a) O Teste Unitário valida a menor parte do código-fonte, neste nível de teste é 
verificado, por exemplo, o método de uma classe. 
b) No Teste de Integração é validado se a integração entre sistemas, componentes ou 
outras funcionalidades foi feita corretamente. 
c) Na fase do Teste de Sistema o software é exercitado como um todo afim de encontrar 
discrepâncias entre os funcionamento especificado nos requisitos e o construído. 
d) O Teste de Aceitação é realizado pelo cliente no momento da entrega do sistema, ou 
de parte dele, este teste é executado para validar se o sistema realiza o que solicitado. 
 
4.2. Técnicas de teste 
Atualmente existem várias formas de testar um software. Técnicas utilizadas antigamente 
ainda são de grande valia apesar da mudança de tecnologia e linguagem de programação, 
apesar destas mudanças o objetivo continua o mesmo: encontrar o maior número de defeitos 
antes da entrega ao cliente. 
 
XXXIII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO 
A Gestão dos Processos de Produção e as Parcerias Globais para o Desenvolvimento Sustentável dos Sistemas Produtivos 
Salvador, BA, Brasil, 08 a 11 de outubro de 2013. 
 
 
 
 
 
 
7 
As técnicas são classificadas com base na origem das informações utilizadas para teste 
(código-fonte ou informações das funcionalidades do sistema). Estas técnicas abordam 
perspectivas diferentes do software e podem ser classificadas como: Funcional e Estrutural 
(NETO, 2013). 
 
4.2.1 Técnica estrutural ou Teste de caixa branca: Nesta técnica é avaliado o 
comportamento interno do sistema, ou seja, o código-fonte. Esta técnica é 
recomendada nos níveis de Teste de Unidade e Teste de Integração, testes que 
normalmente ficam a cargo dos desenvolvedores do código-fonte, que possuem maior 
conhecimento no código-fonte. O objetivo desta é auxiliar na redução de possíveis 
problemas existentes nas funções ou unidades que compõem um software. 
 
4.2.2 Técnica funcional ou Teste de caixa preta: A técnica é chamada de caixa preta, poisa estrutura interna do sistema não é considerada durante a execução destes testes. Esta 
técnica pode ser aplicada em todos os níveis de teste. 
Dados de entrada são fornecidos, o teste é executado e 
o resultado obtido é comparado a um resultado 
esperado previamente conhecido. Haverá sucesso no 
teste se o resultado obtido for igual ao resultado 
esperado. O componente de software a ser testado pode 
ser um método, uma função interna, um programa, um 
componente, um conjunto de programas e/ou 
componentes ou mesmo uma funcionalidade (NETO, 
2013). 
 
Existem outras técnicas de teste como, por exemplo, o Teste de caixa cinza, que se trata de 
uma junção das técnicas de caixa preta e branca, que não serão apresentadas neste artigo. 
4.3. Tipos de teste 
Os tipos de teste que serão executados são definidos na fase de planejamento. Para realizar tal 
definição devem-se analisar vários fatores como: o público que utilizará o sistema, se este 
ficará disponível na internet, se fará integração com outros sistemas, se será acessível a 
deficientes visuais, se trabalhará com muitos registros cadastrados, se poderá ser acessado por 
vários usuários simultaneamente, entre outras informações, ou seja, devem-se verificar os 
 
XXXIII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO 
A Gestão dos Processos de Produção e as Parcerias Globais para o Desenvolvimento Sustentável dos Sistemas Produtivos 
Salvador, BA, Brasil, 08 a 11 de outubro de 2013. 
 
 
 
 
 
 
8 
riscos do projeto, seu nível de tolerância a erros (BASTOS; RIOS; CRISTALLI; MOREIRA, 
2007). 
A figura abaixo apresenta os métodos, os estágios de cada método e os tipos de teste divididos 
por categorias: 
Os tipos de teste apresentados na Figura 4, destacados em azul, são executados no nível do 
teste de sistema. 
Figura 4 - Distribuição dos tipos de teste por categorias 
 
Fonte: Adaptado de (DATASUS, 2013) 
 
Na tabela abaixo (Quadro1) são descriminados alguns dos tipos de teste existentes e sua 
descrição. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 5 - Tipos de teste 
 
XXXIII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO 
A Gestão dos Processos de Produção e as Parcerias Globais para o Desenvolvimento Sustentável dos Sistemas Produtivos 
Salvador, BA, Brasil, 08 a 11 de outubro de 2013. 
 
 
 
 
 
 
9 
 
Fonte: Adaptado de (BARBOSA, 2011) 
 
No Quadro 2, para melhor entendimento das atividades de teste, foram listados alguns dos 
possíveis cenários executados em uma funcionalidade de saque em conta corrente e conta 
poupança. Na coluna “Exemplos de cenários de teste” são listados todos os cenários que serão 
verificados e então estes cenários foram divididos em Tipos de teste, ou seja, a qual tipo de 
teste o cenário a ser testado se enquadra. 
 
 
 
 
 
 
 
 
 
 
 
XXXIII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO 
A Gestão dos Processos de Produção e as Parcerias Globais para o Desenvolvimento Sustentável dos Sistemas Produtivos 
Salvador, BA, Brasil, 08 a 11 de outubro de 2013. 
 
 
 
 
 
 
10 
 
 
Figura 6 - Cenários de teste para realização de saque 
 
Fonte: Adaptado de (BARTIE, 2005) 
 
4.4. Estratégia de teste 
Para elaboração de uma estratégia de teste são analisados quais os métodos, níveis e tipos de 
teste de serão adotados. 
 
XXXIII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO 
A Gestão dos Processos de Produção e as Parcerias Globais para o Desenvolvimento Sustentável dos Sistemas Produtivos 
Salvador, BA, Brasil, 08 a 11 de outubro de 2013. 
 
 
 
 
 
 
11 
Na construção da estratégia de teste devem ser considerados diversos fatores como: o porte e 
importância do software, os requisitos, os prazos assumidos, os riscos do projeto, entre outros 
fatores (RIOS; MOREIRA, 2006). 
A Figura 5 demonstra a relação existente entre as técnicas, níveis e tipos de teste. 
 
Figura 7 - Estratégia de teste 
 
Fonte: (SILVA, 2013) 
 
 
5. Ciclo de vida de teste 
A Figura 6 apresenta o ciclo de vida da fase de teste. As atividades de teste serão melhor 
detalhados no estudo de caso. 
Figura 8 - Ciclo de vida do teste de software 
 
Fonte: (RIOS, 2013) 
 
Na fase de iniciação (Procedimento inicial) é feita a investigação do contexto e escopo do 
projeto com intuito de criar estratégias e diretrizes. 
 
XXXIII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO 
A Gestão dos Processos de Produção e as Parcerias Globais para o Desenvolvimento Sustentável dos Sistemas Produtivos 
Salvador, BA, Brasil, 08 a 11 de outubro de 2013. 
 
 
 
 
 
 
12 
A próxima fase é a de Planejamento (Planejar Testes), neste momento são analisados os 
objetivos das atividades de teste. A documentação do projeto é analisada para obtenção de 
informações como os riscos e nível de importância do projeto para que então sejam definidos 
quais técnicas e tipos de testes melhor se adéquam. Cada tipo de aplicação possui 
características especificas que devem ser consideradas no momento do planejamento e 
realização dos testes. 
O passo seguinte é a elaboração dos casos de teste (Projetar testes) e preparação do ambiente. 
Após elaboração dos artefatos da fase de teste tem início a execução dos testes definidos no 
Plano de teste. São executados primeiro e segundo ciclo de teste (Teste e Reteste, 
respectivamente) e gestão e monitoramento dos defeitos registrados durante o andamento dos 
testes. 
Por fim, ao término dos testes e correção dos defeitos é feito o levantamento das ocorrências 
abertas e feita a liberação do sistema ou parte dele ao cliente. 
 
6. Estudo de caso 
6.1. Informações da empresa 
A empresa analisada para o estudo de caso será identificada como empresa Alfa. Esta atua no 
mercado de desenvolvimento de software há 23 anos. Possui filiais em vários pontos do Brasil 
e algumas no exterior. A Alfa tem aproximadamente 1.800 colaboradores e conquistou no 
decorrer destes anos as certificações ISO9001:2008, CMMI nível 3 e MPS.Br nível C. 
A norma ISO-9001:2008 especifica os requisitos para 
um sistema de gestão da qualidade, voltado para 
organizações que necessitam demonstrar sua habilidade 
de fornecer produtos que satisfaçam os requisitos dos 
seus clientes, requisitos estatutários e da legislação 
aplicável de forma consistente e que buscam aumentar 
a satisfação dos seus clientes através da aplicação 
efetiva do sistema, incluindo processos para a sua 
melhoria contínua e para a garantia da conformidade 
com estes requisitos (CEDET, 2009). 
 
6.2. Fase de teste 
 
XXXIII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO 
A Gestão dos Processos de Produção e as Parcerias Globais para o Desenvolvimento Sustentável dos Sistemas Produtivos 
Salvador, BA, Brasil, 08 a 11 de outubro de 2013. 
 
 
 
 
 
 
13 
A execução dos testes tem início após construção e liberação do código-fonte, entretanto antes 
de exercitar o sistema é necessária a elaboração de alguns artefatos. 
O primeiro artefato da fase de teste a ser elaborado é o Plano de teste, que como próprio nome 
sugere, é o documento que conterá todo o planejamento realizado para a execução dos testes, 
nele terão informações como as funcionalidades que deverão ser testadas, quais métodos e 
tipos de teste serão executados, as ferramentas necessárias, configuração do ambiente de teste, 
entre outras informações. 
O caso de teste também é um dos documentos construídos antes da execução dos testes. Nele 
são descritos os passos a passos que devem ser executados durante a verificação do sistema. 
Normalmente é descrita a ação do ator e a resposta do sistema para determinado cenário. Na 
ilustração abaixo (Figura 7) é possível verificar com mais detalhes como são elaborados os 
casos de teste. Na primeira coluna há uma breve descrição do cenário que será verificado, na 
segunda coluna são descritos os passos que o ator (usuário do sistema) deve executar e na 
terceira coluna é informado o resultado esperado do sistemaà qualidade, entender a forma pela qual cada envolvido percebe 
a qualidade de um produto de software é muito importante, pois há interesses que não convergem e 
causam uma série de conflitos durante o desenvolvimento do software, seja por questões de dinheiro e 
prazo, seja para ver o software funcionando corretamente.
As visões no desenvolvimento de um software envolvem os gerentes, os desenvolvedores, os clientes 
e os usuários, e esses interesses são ilustrados na Figura 4.
Cliente
Baixo custo
Atende ao negócio
Desenvolvedor
Com código
Fácil de corrigir
Usuário
Fácil de usar
Funcionalidades
Gerente
Prazo e custos dentro das 
estimativas
Confiável
Sem erros
Figura 4 – Visões da qualidade de software
1.4 Importância da qualidade
A importância de se produzir software com qualidade é inegável, mas na área de Tecnologia da 
Informação esse aspecto não vem recebendo a atenção devida. Exceção feita aos softwares que podem 
causar a perda de vidas humanas, que recebem a atenção e a preocupação que deve ser uma constante 
na cabeça dos desenvolvedores.
15
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
Hoje, os sistemas computacionais são a base de controle de todas as empresas. A dependência da 
tecnologia é visível a todos: usuários e empresas. Imagine o que o mau funcionamento de um software 
pode causar:
• bancos perdem milhões;
• clientes veem saldos sumirem de suas contas de repente;
• os telefones param de funcionar;
• aviões têm rotas desviadas;
• trens de metrô são colocados no mesmo trilho.
Imagine o caos nas empresas. Contudo, isto não são previsões. Já está ocorrendo em diversas 
situações do mundo atual e que realmente fazem refletir sobre qualidade na produção de software, 
independentemente do fato de causar perda de vidas humanas, ou não. Veja alguns exemplos de bugs 
de software famosos:
• Derrubada do Airbus A320, 1988
— Ocorrência: o navio da Marinha americana USS Vincennes derrubou um Airbus A320, que foi 
confundido com um F‑14. Morreram 290 pessoas.
— Motivo: o software do radar não diferenciou um avião de passageiros de um caça inimigo de 
ataque.
• Pentium Floating-Point, 1994
— Ocorrência: em 1994 a Intel apresentou ao mercado a primeira versão do processador Pentium, 
o qual possuía uma unidade de processamento de ponto flutuante bastante rápida, mas que 
fazia cálculos errados. Exemplo: 4,195,835 – (4,195,835/3,135,727) * 3,135,727 era igual a zero 
no processador 486, mas igual a 256 no Pentium.
— Motivo: o bug foi causado por um erro na tabela que era utilizada para acelerar o algoritmo de 
processamento de multiplicação de ponto flutuante. A Intel afirmou que um usuário típico do 
Pentium somente perceberia o problema uma vez em 27 mil anos. Ao final, a Intel foi forçada a 
vir a público e anunciar um programa de troca de chips, o qual teve um custo de cerca de US$ 
475 milhões.
• Recall de veículos, 2003
— Ocorrência: uma fabricante de caminhões e tratores americana anunciou um grande programa 
de recall dos seus veículos no inverno de 2003.
16
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade I
— Motivo: a fabricante de veículos detectou pelo seu controle de qualidade e informou a existência 
de um problema de software que poderia causar instabilidade nos veículos em determinadas 
circunstâncias.
 Saiba mais
Para ver mais exemplos de bugs famosos de software, visite o site: 
. Acesso em: 9 dez. 2014.
No processo de qualidade existem dois conceitos que sempre causam confusão em relação à sua 
definição e à sua finalidade. São estes: a garantia da qualidade e o controle da qualidade. Vejamos a 
diferença.
1.5 Garantia da qualidade
São ações planejadas e sistemáticas de qualidade realizadas durante o processo de desenvolvimento 
cujo objetivo é atuar de forma preventiva para se atingir a qualidade do produto de software. A garantia 
da qualidade avalia se as características do produto estão de acordo com os padrões estabelecidos e 
se as atividades estão ocorrendo conforme o planejado. Algumas atividades de garantia da qualidade 
devem envolver:
• uso, pelos desenvolvedores, de métodos e ferramentas que ajudem a conseguir especificações, 
projeto e codificação de maior qualidade;
• estabelecimento de padrões para documentos, código e estilo de codificação (como usar linguagem 
de programação); esses padrões podem ser determinados pelo cliente, por normas internacionais 
ou pela empresa de desenvolvimento;
• realização das atividades de verificação e validação, como revisões, inspeções, dentre outras.
 Observação
Segundo a NBR ISO 9000:2005 (Sistemas de Gestão da Qualidade – 
Fundamentos e Vocabulário), não conformidade é o não atendimento a um 
requisito de qualidade (necessidade ou expectativa implícita ou obrigatória).
1.6 Controle da qualidade
São atividades de qualidade realizadas após o produto de software estar pronto. O objetivo do 
controle da qualidade é permitir o aceite do produto, uma vez que se caracteriza por um “selo” atestando 
que a aplicação está de acordo com as especificações. Por meio do controle da qualidade, evita‑se que 
17
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
produtos defeituosos sejam entregues aos clientes. A principal atividade de controle da qualidade são 
os testes funcionais do software.
No controle da qualidade, uma atividade deve ser executada visando avaliar se as ações de 
qualidade planejadas estão sendo executadas de acordo com o processo estabelecido. Essa atividade 
chama‑se auditoria.
Tais auditorias podem geram ações corretivas, no caso de encontrar não conformidades, e podem 
ser classificadas em três tipos:
• auditorias de produto: foco em verificar a conformidade de produtos com os padrões estabelecidos;
• auditorias de processo: verificam se as ações de qualidade planejadas estão sendo executadas;
• auditorias de sistemas de qualidade: avaliam a eficácia da implementação desse sistema e 
determinam o grau em que os objetivos do sistema estão sendo atingidos.
 Lembrete
A garantia da qualidade é feita durante o desenvolvimento do software, 
e o controle da qualidade é realizado após o produto estar pronto.
Alinhados os conceitos iniciais de qualidade de software, veremos no próximo tópico os 
sistemas de gestão da qualidade que orientam e definem os procedimentos de qualidade nas 
diversas organizações.
 Saiba mais
Informações detalhadas sobre qualidade de software podem ser obtidas 
no livro:
GUERRA, A. C.; COLOMBO, R. M. Tecnologia da Informação: qualidade 
de produto de software. Brasília: PBQP Software, 2009.
1.7 Sistemas de Gestão da Qualidade (SGQ)
Um SGQ tem como objetivo padronizar os processos de uma empresa para a criação de seu 
produto final, proporcionando a satisfação de seus clientes e a melhoria contínua dos seus processos 
(ANTONIONI, 1995).
18
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade I
Melhoria contínua do 
Sistema de Gestão da Qualidade
Realização do 
serviço Serviço
Responsabilidade 
de administração
Medição, análise, 
melhoria
Gestão dos 
Recursos
R
e
q
u
i
s
i
t
o
s
C
l
i
e
n
t
e
C
l
i
e
n
t
e
S
a
t
i
s
f
a
ç
ã
o
Entrada Saída
Figura 5 – Melhoria contínua do SGQ (ISO)
ABNT (2000b, p. 2)
Conforme ilustrado na Figura 5, o SGQ se inicia com os requisitos do cliente, a partir dos quais 
o produto é construído, passando pelo processo de medição e análise dos padrões definidos para a 
garantia da qualidade. Nesse momento, são tomadas as ações corretivas para melhoria do processo. Em 
todo o processo, a alta administração e a gerência são responsáveis pelo patrocínio do SGQ, pela gestão 
dos recursos necessários e pela comunicação com o cliente.
O objetivo final do SGQ é proporcionar a satisfação do cliente.
1.7.1 Fatores para implantação de um SGQ
Conformepara a ação executada. A quarta 
coluna indicará a situação do cenário, se o sistema se comportou conforme o indicado nos 
requisitos. 
Figura 9 - Exemplo de caso de teste 
 
Fonte: Elaborado pelo autor 
 
Após a elaboração dos artefatos e liberação do caso de uso para teste inicia-se a primeira 
bateria de testes, neste momento são exercitados os tipos de teste definidos na fase de 
planejamento. A equipe de teste percorre os cenários descritos nos casos de teste e caso 
encontre algum defeito o registra em uma ferramenta de gestão de ocorrência. 
 
XXXIII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO 
A Gestão dos Processos de Produção e as Parcerias Globais para o Desenvolvimento Sustentável dos Sistemas Produtivos 
Salvador, BA, Brasil, 08 a 11 de outubro de 2013. 
 
 
 
 
 
 
14 
Os defeitos são abertos para o desenvolvedor do caso de uso. Este verifica se o defeito 
realmente ocorre e em caso positivo realiza a correção do código-fonte. Após correção o 
desenvolvedor libera a modificação para uma nova validação. 
Neste momento o testador que cadastrou a ocorrência verifica se o defeito foi eliminado e 
caso esteja correto a ocorrência é fechada. 
Após execução da primeira bateria de testes é iniciado o reteste, onde ocorre uma nova 
validação da funcionalidade ou caso de uso por outro testador. A execução de duas baterias de 
teste por recursos diferente é importante, pois permite que o sistema seja analisado por 
pessoas com experiências profissionais, conhecimentos e características diferentes. Na etapa 
de reteste os defeitos encontrados são registrados e corrigidos assim como ocorrido na 
primeira etapa do teste. 
Após execução do Teste e Reteste é iniciado o Teste Regressivo. Nesta etapa o intuito é 
encontrar possíveis defeitos que foram gerados devido às correções. Neste momento a 
quantidade de defeitos encontrada normalmente é baixa e o sistema é totalmente percorrido, 
ou seja, caso o sistema tenha casos de uso que já foram entregues, no Teste Regressivo serão 
verificados os casos de uso que serão e os que já foram entregues. 
Com o término dos testes, nos projetos tradicionais, ou seja, os que não usam a metodologia 
ágil, é elaborado o Sumário de Avaliação de Teste. Neste artefato é listada a quantidade de 
defeitos por caso de uso, a quantidade de cenários por caso de teste, os defeitos abertos, os 
fechados, os defeitos satisfatórios (que realmente ocorriam) e os insatisfatórios (abertos 
indevidamente, por algum engano do testador) e os responsáveis pela execução dos testes. 
Ao finalizar os três ciclos de teste e correção de todos os defeitos encontrados o sistema é 
disponibilizado ao cliente, para o teste de aceitação. 
Para evidenciar os impactos gerados no sistema após a fase teste foram analisados 3 projetos, 
conforme demonstrado na tabela abaixo. 
Tabela 1. Horas de teste e defeitos por projeto 
 
XXXIII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO 
A Gestão dos Processos de Produção e as Parcerias Globais para o Desenvolvimento Sustentável dos Sistemas Produtivos 
Salvador, BA, Brasil, 08 a 11 de outubro de 2013. 
 
 
 
 
 
 
15 
 
*Quantidade de dias calculada com 8 horas diárias de trabalho de um profissional 
Fonte: Elaborado pelo autor 
 
 
 
 
Tabela 2. Quantidade de defeitos por projeto. 
 
Fonte: Elaborado pelo autor 
 
Foram coletadas informações como: Quantidade total de horas gastas no projeto, Quantidade 
de horas gastas com teste e Quantidade de defeitos de cada projeto. 
Com base nos dados coletados e apresentados na Tabela1 é possível verificar que os Projetos 
2 e 3, que são projetos que seguem a processo tradicional, qual é baseado na metodologia 
 
XXXIII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO 
A Gestão dos Processos de Produção e as Parcerias Globais para o Desenvolvimento Sustentável dos Sistemas Produtivos 
Salvador, BA, Brasil, 08 a 11 de outubro de 2013. 
 
 
 
 
 
 
16 
RUP, o tempo gasto com teste são inferiores a 20% do projeto. Para o Projeto 1 foi adotado a 
metodologia ágil, deste modo, devido a menor necessidade de tempo gasto com elaboração de 
artefatos, torna-se possível destinar mais horas a atividade de teste. 
Na Tabela 2 pode-se perceber que sem a execução dos testes o sistema seria entregue com 
grande quantidade de defeitos nos três projetos analisados. O projeto 1, onde foi possível 
destinar quantidade maior de tempo para as atividades de teste a quantidade de defeitos 
externos, ou seja, abertos pelo cliente, foi zero. 
 
7. Considerações Finais 
O teste de software é uma das atividades mais custosas do processo de desenvolvimento de 
software, pois pode envolver uma quantidade significativa dos recursos de um projeto. O rigor 
e o custo associado a esta atividade dependem principalmente da criticidade da aplicação a ser 
desenvolvida. Diferentes categorias de aplicações requerem uma preocupação diferenciada 
com as atividades de teste. 
Realizar testes não consiste simplesmente na geração e execução de casos de teste, mas 
envolvem também questões de planejamento, gerenciamento e análise de resultados. 
Neste artigo foram apresentados alguns conceitos sobre teste de software e o objetivo 
principal foi apresentar a importância da fase de teste para a entrega de um produto com 
maior qualidade. Entretanto, para a entrega ocorra conforme o esperado é necessário 
planejamento, o envolvimento de profissionais capacitados e tempo hábil para execução dos 
testes. Também é importante destacar que a execução dos testes deve ocorrer em todo o 
processo de desenvolvimento do sistema. 
 
REFERÊNCIAS 
BARBOSA, Filipe B.; TORRES, Isabelle V. O Teste de Software no Mercado de Trabalho, 2011. Disponível 
em: . Acessado em: 
09 mar. 2013. 
 
BARTIE, Alexandre. Categorias de Teste de Software, 2005. Disponível em: 
. Acessado em: 09 mar. 2013. 
 
BASTOS Aderson; RIOS Emerson; CRISTALLI Ricardo; MOREIRA Trayahú. Base de conhecimento em 
teste de software. 2.ed. São Paulo: Martins, 2007, 263 p. 
 
http://revista.faculdadeprojecao.edu.br/revista/index.php/projecao2/article/viewFile/82/70
http://imasters.com.br/artigo/3648/software/categorias-de-testes-de-software/
 
XXXIII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO 
A Gestão dos Processos de Produção e as Parcerias Globais para o Desenvolvimento Sustentável dos Sistemas Produtivos 
Salvador, BA, Brasil, 08 a 11 de outubro de 2013. 
 
 
 
 
 
 
17 
CEDET – Centro de Desenvolvimento Profissional e Tecnológico, 2009. Disponível em: 
. Acessado em: 23 fev. 
2013. 
 
DATASUS, 2013. Disponível em: . Acessado em: 09 
mar. 2013. 
FROTA, Álvaro. O Barato Sai Caro! Como reduzir custos através da qualidade. São Paulo: Qualitymark, 1999, 
166 p. 
 
MOLINARI Leonardo. Teste de Software – Produzindo sistema melhores e mais confiáveis. 4 ed. São Paulo: 
Editora Érica Ltda, 2012, 228 p. 
MYERS, Glenford J. The art of software testing. New York: John Wiley & Sons, 1979, 177p. 
 
NETO, Arilo C. D, 2013. Revista Engenharia de Software. Disponível em: 
. Acessado 
em: 04 mar. 2013. 
PRESSMAN, R. S. Engenharia de Software. 5. ed. Rio de Janeiro: McGraw-Hill, 2002, 843 p. 
 
RIOS, Emerson, 2013. Fundamentos de teste de software. Disponível em: 
. Acessado em: 09 mar. 2013. 
RIOS, Emerson; MOREIRA, Trayahú. Teste de Software. 2.ed. São Paulo: Alta Book, 2006, 232 p. 
 
SILVA, Fernando R, 2013. Revista Engenharia de Software. Disponível em: 
. Acessadoa Figura 6, diversos fatores podem motivar uma empresa a implantar um SGQ. Dentre 
estes, podem‑se destacar:
• Conscientização da alta administração: a alta direção reconhece que a qualidade é um diferencial 
e patrocina o processo. É o fator mais eficaz.
• Razões contratuais: a fim de manter ou iniciar o fornecimento de produtos ou serviços para 
outros países, para o governo e para algumas organizações da iniciativa privada. O tempo para 
alcançar a maturidade é maior, mas normalmente se alcança a conscientização.
• Competitividade: necessária para manter a empresa concorrendo no mercado.
• Modismo: fazer porque estão todos fazendo. Bastante ineficaz, normalmente, não atinge a 
conscientização da alta administração e, com isso, o processo é abandonado no meio do caminho.
19
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
Conscientização 
da alta 
administração
Razões 
contratuais Competitividade Modismo
Figura 6 – Fatores motivacionais para a implantação do SGQ
1.7.2 A NBR ISO 9000 – norma‑padrão
O SGQ mais comum e conhecido no mercado é a NBR ISO 9000 – Normas de Gestão da Qualidade e 
Garantia da Qualidade –, lançada no fim da década de 1980. Serve como arcabouço‑padrão para definir 
como as demais normas específicas devem ser utilizadas.
A NBR ISO 9000 auxilia a empresa na seleção da norma mais apropriada para o seu negócio e na sua 
utilização. Trata‑se de um documento não normativo (ABNT, 2000a).
 Observação
A International Organization for Standardization (ISO) é um órgão da ONU 
e tem o objetivo de fixar normas técnicas essenciais, de âmbito internacional.
NBR ISO 9000 é o nome genérico que se dá às diversas normas que abrangem o assunto. As normas 
básicas para garantia da qualidade são as contratuais – ISO 9001, ISO 9002 e ISO 9003 – e as organizações 
só podem ser certificadas em relação a essas normas.
 Observação
O representante brasileiro da ISO no Brasil é a Associação Brasileira 
de Normas Técnicas (ABNT), e as normas são descritas como Normas 
Brasileiras (NBRs).
1.7.2.1 Descrição básica das normas
Para o estudo relacionado à qualidade de software, são relevantes as seguintes normas relacionadas 
à ISO 9000 e apresentadas na Figura 7:
20
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade I
• ISO 9000 – Normas de Gestão da Qualidade e Garantia da Qualidade: um guia de como as demais 
normas devem ser usadas.
• ISO 9001 – Sistemas da Qualidade – Modelo para Garantia da Qualidade em Projeto, 
Desenvolvimento, Produção, Instalação e Assistência Técnica: para uso quando a conformidade 
com os requisitos especificados tiver de ser garantida pelo fornecedor desde o projeto até a 
manutenção.
• ISO 9000‑1 – Normas de Gestão da Qualidade e Garantia da Qualidade – Parte 1: estabelece os 
princípios gerenciais que permeiam toda a série de normas.
• ISO 9000‑3 – Normas de Gestão da Qualidade e Garantia da Qualidade – Parte 3: esta norma 
define diretrizes para facilitar a aplicação da norma ISO 9001 a organizações que desenvolvem, 
fornecem e mantêm software. Destina‑se a fornecer orientação quando um contrato entre duas 
partes exigir a demonstração da capacidade do fornecedor em desenvolver, fornecer e realizar 
manutenção em produtos de software.
ISO
9000
ISO
9001
ISO
9000‑1
ISO
9000‑3
Figura 7 – Normas ISO relacionadas a organizações que produzem software
1.7.3 NBR ISO 9000‑3 – Norma para empresas de desenvolvimento de software
Em junho de 1993 foi criado o guia ISO 9000‑3, com diretrizes para a aplicação da ISO 9001 ao 
desenvolvimento, ao fornecimento e à manutenção de software.
Para cada item da NBR ISO 9001 existe um correspondente na NBR ISO 9000‑3 que a detalha e a 
adequa às empresas de software.
 Lembrete
A NBR ISO 9000‑3 é a norma da qualidade do SGQ aplicada às empresas 
de desenvolvimento de software.
21
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
A NBR ISO 9000‑3 abrange questões relacionadas ao entendimento dos requisitos funcionais, ao 
uso de metodologias consistentes para desenvolvimento de software e ao gerenciamento do projeto 
desde a concepção até a manutenção. Uma das principais limitações da NBR ISO 9000‑3 é não abordar 
os aspectos relacionados à melhoria contínua do processo de software que são tratados pelo modelo 
Capability Maturity Model Integration (CMMI) e pela NBR ISO IEC 15504 – Spice (Software Process 
Improvement and Capability Determination – Melhoria do Processo de Software e Determinação da 
Capacidade). Portanto, o objetivo da NBR ISO 9000‑3 é trazer quais processos a organização deve ter e 
manter para o desenvolvimento do software (RAPCHAN, 2005).
 Observação
O Modelo CMMI e a norma ISO/IEC 15504 serão detalhados no tópico 4.
1.7.3.1 A estrutura da NBR ISO 9000‑3
A NBR ISO 9001 baseia‑se em vinte diretrizes que englobam vários aspectos da garantia da qualidade. 
A NBR ISO 9000‑3 exige que 18 critérios estejam presentes no sistema da qualidade e agrupa essas 
diretrizes em três partes principais, que são apresentadas na Figura 8:
• estrutura: aspectos organizacionais, relacionados ao SGQ;
• ciclo de vida: descreve as atividades de desenvolvimento de software;
• suporte: descreve operações que apoiam as atividades do ciclo de vida.
1.7.3.2 O processo de certificação da NBR ISO série 9000
A certificação ISO 9000 é reconhecida no mercado por muitas organizações e traz uma série de 
benefícios às empresas que adotam o sistema. Dentre estes, podemos destacar:
• abertura de novos mercados;
• maior conformidade e atendimento às exigências dos clientes;
• maior integração entre os setores da organização;
• melhores condições para acompanhar e controlar os processos;
• diminuição dos custos de desenvolvimento.
O primeiro passo para realizar o processo de certificação é selecionar, do modelo ISO 9000, a norma 
mais adequada aos propósitos da organização (ISO 9001, ISO 9002 ou ISO 9003). Para empresas de 
desenvolvimento de software, é a norma NBR ISO 9000‑1.
22
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade I
Após a escolha, a empresa deverá analisar o seu processo e treinar os funcionários para a 
conscientização sobre a necessidade da qualidade. Na sequência, deverá desenvolver e implementar os 
procedimentos necessários ao sistema da qualidade, selecionar um órgão certificador que irá avaliar se 
o sistema está de acordo com a norma, fazer pré‑auditorias e realizar a auditoria final de aderência ao 
SGQ para a certificação.
Durante a definição do processo, deve‑se tomar cuidado para que este não se torne burocrático. Ele 
deve adaptar‑se ao dia a dia da empresa, e não o contrário. Além disso, a organização será reavaliada 
a cada dois anos e deverá cuidar para não perder o certificado, pois isso pode ser muito custoso em 
termos financeiros e de imagem no mercado.
NBR/ISO 9000-3
Atividades de estrutura
Responsabilidade da 
administração
Análise crítica do 
contrato
Projeto e 
implementação
Técnicas e 
ferramentas
Gestão de 
configuração
Auditorias 
internas
Planejamento da 
qualidade
Entrega e 
instalação
Registro da 
qualidade
Sistema de 
qualidade
Especificação dos 
requisitos
Validação e 
aceitação Treinamentos
Controle de 
documentos
Ações 
corretivas
Planejamento do 
desenvolvimento
Atividades de 
manutenção
Medição e 
análise
Atividades do ciclo de vida Atividades de suporte
Figura 8 – Melhoria contínua do SGQ
O processo de certificação pode se estender de alguns meses a dois anos, dependendo do nível de 
maturidade da qualidade em que a organização se encontra.
1.7.3.3 Custo da certificação da NBR ISO série 9000
Pesquisa realizada pelo National ISO 9000 Support Group nos Estados Unidos e pelo seu correlato no 
Brasil (ABNT, 2000a) avaliou que os valores para obter a certificação ficam numa faixa de US$ 6.500,00 
a US$ 30.000,00, dependendodo grau inicial em que a empresa se encontra.
 Saiba mais
Mais detalhes sobre as NBRs ISO da série 9000 podem ser obtidas nos 
sites oficiais: ou .
23
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
2 GESTÃO DA QUALIDADE DO PRODUTO DE SOFTWARE
A partir da padronização de processos por meio das normas ISO, foram criadas normas específicas 
para o desenvolvimento de software, com o objetivo de garantir a aderência dos produtos de software 
a padrões preestabelecidos, e outras para avaliação desses produtos.
Embora existam diversas normas relacionadas a esse assunto, aqui são selecionadas as normas mais 
utilizadas pelo mercado de Tecnologia da Informação, mais o Modelo de McCall, que foi o primeiro a 
abordar os assuntos relacionados à qualidade de um produto de software.
Essas normas principais são: ISO/IEC 9126, ISO/IEC 12207, ISO/IEC 14598 e ISO/IEC 25000.
Apresentamos no Quadro 1 uma relação das normas que são abordadas neste tópico.
Quadro 1 – Normas e modelo de qualidade para produtos de software
Norma Objetivo
Modelo de McCall Define fatores e critérios de qualidade para o produto de software 
ISO/IEC 9126 ou NBR 13596 Define as características da qualidade que devem estar presentes em um produto de software 
ISO/IEC 12207 Define as tarefas para o ciclo de vida do software 
ISO/IEC 14598 Estabelece um plano para avaliação do produto de software 
ISO/IEC 25000
Define uma especificação e uma avaliação da qualidade do produto de software
É a nova geração das séries ISO/IEC 9126 e ISO/IEC14598 
2.1 Modelo de McCall
Em 1977, Jim McCall desenvolveu um modelo de qualidade para o Departamento de Defesa 
Americano em que a qualidade é definida por um conjunto de características internas e externas de um 
software, tornando‑se o primeiro modelo de qualidade a ser amplamente divulgado e utilizado.
Essas características estão divididas em fatores de qualidade que definem os atributos externos e 
que só podem ser medidos indiretamente e critérios de qualidade que são os atributos internos e que 
podem ser medidos diretamente. A combinação de ambos permite chegar a um fator quantitativo de 
qualidade que um software apresenta.
 Observação
McCall definiu 11 fatores de qualidade e 23 critérios que, inter‑relacionados, 
permitem a avaliação da qualidade de um produto de software.
O Modelo de McCall define claramente quais são esses fatores de qualidade que podem ser avaliados 
e os dividiu em três visões, conforme ilustrado na Figura 9.
24
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade I
Essas três visões são: a visão de revisão, que avalia a capacidade de sofrer manutenção; a visão de 
operação, a qual verifica as condições de utilização do software; e a visão de transição, cujo foco está 
na avaliação da capacidade do software de adaptar‑se a outros ambientes.
A seguir são descritos os conceitos fundamentais dos 11 fatores do modelo (McCALL; RICHARDS; 
WALTERS, 1977):
Revisão
Operação
Transição
– Correção
– Confiabilidade
– Integridade
– Eficiência
– Manutenção
– Flexibilidade
– Testabilidade
– Portabilidade
– Reuso
– Interoperabilidade
Figura 9 – Fatores de qualidade de McCall
2.1.1 Visão de operação
• Correção: quanto o sistema satisfaz a sua especificação e cumpre os objetivos esperados pelo 
cliente. Faz‑se a pergunta: “O software faz o que queremos?”.
• Confiabilidade: quanto o sistema executa sua função com a precisão exigida. Faz‑se a pergunta: 
“O software é estável?”.
• Eficiência: quanto o sistema usa os recursos computacionais. Faz‑se a pergunta: “O software usa 
o hardware de maneira adequada?”.
• Integridade: quanto o acesso ao software ou aos dados por pessoas não autorizadas pode ser 
controlado. Faz‑se a pergunta: “O software é seguro?”.
• Usabilidade: quanto de esforço é necessário para aprender e usar o sistema. Faz‑se a pergunta: “O 
software é fácil de usar?”.
25
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
2.1.2 Visão de revisão
• Manutenibilidade: quanto de esforço é necessário para localizar e eliminar erros no sistema. 
Faz‑se a pergunta: “O software é fácil de corrigir?”.
• Flexibilidade: quanto de esforço é necessário para modificar um programa. Faz‑se a pergunta: “É 
fácil incluir novas funcionalidades?”.
• Testabilidade: quanto de esforço é necessário para testar um programa a fim de garantir que ele 
atenda às necessidades. Faz‑se a pergunta: “É fácil testar o sistema?”.
2.1.3 Visão de transição
• Portabilidade: quanto de esforço é necessário para transferir um sistema de uma plataforma 
de hardware ou software para outra. Faz‑se a pergunta: “O software pode ser usado em outra 
máquina?”.
• Reusabilidade: quanto de um sistema pode ser reutilizado por outros sistemas. Faz‑se a pergunta: 
“Alguma parte pode ser reutilizada?”.
• Interoperabilidade: quanto de esforço é necessário para estabelecer conectividade entre o sistema 
e os outros sistemas. Faz‑se a pergunta: “O software está apto para fazer interface com outros 
sistemas?”.
McCall, Richards e Walters (1977) também definiram 23 critérios. Atribuindo peso a cada um deles 
e combinando‑os com os fatores de qualidade, chegaram a uma classificação quantitativa para a 
verificação da aderência do software aos padrões de qualidade esperados.
A atribuição de pesos aos fatores e critérios de qualidade decorre do fato de que cada tipo de software 
possui suas próprias características e seus próprios requisitos de qualidade. Portanto, a importância de 
cada fator e cada critério de qualidade varia conforme o tipo do software.
Por exemplo, para um software de locação de games, os fatores de integridade, confiabilidade, 
usabilidade e facilidade de manutenção são essenciais. Porém, para um software embarcado para um 
automóvel, a eficiência, a correção e a confiabilidade são os fatores mais importantes. Nesses dois 
cenários, cada fator receberá seu peso equivalente à importância estabelecida.
Cada critério de qualidade está associado a um ou mais fatores de qualidade que permitem a correta 
avaliação de cada fator para cada tipo de software, conforme ilustrado no Quadro 2.
26
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade I
Quadro 2 – Correlação entre fatores e critérios de qualidade de McCall
Co
rr
eç
ão
Co
nfi
ab
ili
da
de
Efi
ci
ên
ci
a
In
te
gr
id
ad
e
Us
ab
ili
da
de
M
an
ut
en
ib
ili
da
de
Te
st
ab
ili
da
de
Fl
ex
ib
ili
da
de
Po
rt
ab
ili
da
de
Re
us
ab
ili
da
de
In
te
ro
pe
ra
bi
lid
ad
e
Acesso a auditoria X
Controle de acesso X
Acurácia X
Conectividade X
Completude X
Comunicabilidade X
Clareza e concisão X
Consistência X X X
Compartilhamento de dados X
Tolerância a erros X
Eficiência na execução X
Capacidade de expansão X
Generalista X
Independência de hardware X
Facilidade de manipulação X X X
Modularidade X X X X X X
Operabilidade X
Autodocumentação X X X X X
Simplicidade X X X
Independência de software X X
Eficiência de armazenamento X
Rastreabilidade X
Treinamento X
Adaptado de: McCall; Richards; Walters (1977).
 Observação
Os critérios de qualidade são denominados de requisitos não funcionais 
e estão presentes em qualquer tipo de software.
Exemplo de aplicação
Vamos considerar a relação entre os fatores e os critérios de qualidade apresentados no 
Quadro 2 para simularmos a avaliação de um software de biblioteca que atende aos alunos de 
27
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
uma universidade pela internet e controla os empréstimos e as devoluções dos livros. A avaliação 
mínima deve ser 7,0.
Em primeiro lugar, vamos identificar os fatores que precisam ser avaliados para esse tipo de 
software. Dos 11 fatores disponíveis, vamos selecionar e atribuir um pesode 0 a 5 para sua importância 
no contexto:
Tabela 1 – Exemplo 1
Fator Peso 
• Correção 4
• Confiabilidade 5
• Eficiência 5
• Integridade 3
• Usabilidade 5
• Manutenibilidade 3
• Testabilidade 3
 Os pesos estão relacionados ao grau de importância do fator: zero significa nenhuma importância, 
e cinco, importância muito alta.
Agora, vamos selecionar os critérios relevantes dentro de cada fator de qualidade e distribuir o 
peso atribuído ao fator entre os critérios. Não é necessário que os fatores contenham todos os critérios 
previstos no Quadro 2.
Tabela 2 – Exemplo 2
Fator Peso 
• Correção
— Completude
— Rastreabilidade
4
2
2
• Confiabilidade 
— Tolerância a erros
— Simplicidade
5
3
2
• Eficiência
— Na execução
— No armazenamento
5
3
2
• Integridade
— Controle de acesso
3
3
• Usabilidade
— Comunicabilidade
— Treinamento
5
4
1
28
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade I
• Manutenibilidade
— Modularidade
— Documentação
3
2
1
• Testabilidade
— Facilidade de manipulação 
3
3
Temos todos os fatores e critérios selecionados para o tipo de software que vamos avaliar. O passo 
seguinte é fazer uma avaliação de 0 a 10 para cada critério de qualidade. Para atribuir essa nota, 
podem‑se usar critérios subjetivos do próprio avaliador ou criar um checklist com os itens que são 
considerados na atribuição da nota para cada um dos critérios listados para a aplicação. No exemplo, 
para fins didáticos, são utilizados os critérios subjetivos.
Geradas as notas individuais para cada critério, calculamos a nota final do fator pelo somatório 
dessas. Após isso, calculamos a nota final da aplicação somando as notas dos fatores de qualidade do 
mapa que elaboramos.
Vejamos o exemplo:
Tabela 3 – Exemplo 3
Fator Peso Nota Cálculo
• Correção
— Completude
— Rastreabilidade
4
2
2
2,5
7,5
5
25/10
7,5*2
5*2
• Confiabilidade 
— Tolerância a erros
— Simplicidade
5
3
2
4,5
10
7,5
45/10
10*3
2*7,5
• Eficiência
— Na execução
— No armazenamento
5
3
2
4,4
8
10
44/10
8*3
10*2
• Integridade
̶ Controle de acesso
3
3
3
10
30/10
10*3
• Usabilidade
— Comunicabilidade
— Treinamento
5
4
1
4,0
7,5
10
40/10
7,5*4
1*10
• Manutenibilidade
— Modularidade
— Documentação
3
2
1
1,9
7
5
19/10
7*2
5*1
• Testabilidade
— Facilidade de manipulação
3
3
1,8
6
18/10
6*3
O próximo passo é calcular a média ponderada da matriz de acordo com as notas de cada fator:
29
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
Tabela 4 – Exemplo 4
Fator Peso Nota Final 
• Correção 4 2,5 10
• Confiabilidade 5 4,5 22,5
• Eficiência 5 4,4 22
• Integridade 4 3 12
• Usabilidade 5 4 20
• Manutenibilidade 3 1,9 5,7
• Testabilidade 3 1,8 5,4
• Soma total 28 22,1 97,6
Calculando a nota final da aplicação, temos: 97,6 dividido por 28, que resulta em uma nota final de 
3,48 de um total de 5, significando que a aplicação tem uma nota final de 6,96.
Sem o critério estabelecido para a escolha da aplicação de biblioteca, nesse cenário apresentado no exemplo, 
essa aplicação estaria fora do processo de seleção por não atender as condições mínimas de aceitação.
O importante nessa avaliação é estabelecer critérios claros por meio de um checklist para a atribuição 
correta das notas, a fim de que não gere dúvidas se a nota é justa ou não e permita uma conclusão 
imparcial da aplicação.
2.2 ISO/IEC 9126 – Características de qualidade do produto de software
A norma ISO/IEC 9126 é uma referência técnica mundial para a qualidade de um produto de software 
elaborada pela ISO e pelo IEC em 1991 e publicada no Brasil em 1996 como NBR/13596. Fornece um 
modelo geral que define seis categorias de características de qualidade do produto de software divididas 
em subcaracterísticas. Estas podem ser avaliadas por meio de métricas quantitativas. Tal conjunto 
permite dizer se o software satisfaz as necessidades e os padrões estabelecidos pelos desenvolvedores e 
pelos usuários (ISO, 2001).
 Observação
IEC significa International Electrotechnical Commission e é uma 
organização internacional sem fins lucrativos que desenvolve padrões 
sobre tecnologias elétricas e eletrônicas, inclusive sobre software, presente 
em mais de 150 países.
De acordo com a norma ISO/IEC 9126, o documento propõe um conjunto de atributos de qualidade, 
distribuídos em seis características, que, por sua vez, são divididas em subcaracterísticas, chamado de 
modelo de referência e ilustrado na Figura 10.
30
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade I
Os conceitos e detalhes de cada característica e sua composição são descritos a seguir (ISO, 2001):
• Funcionalidade: descreve o que o software faz. Pergunta‑se: “Satisfaz as necessidades dos 
usuários?”.
— Subcaracterísticas:
— Adequação: todas as funções especificadas estão construídas?
— Acurácia: o produto gera resultados precisos ou dentro do esperado?
— Interoperabilidade: interage com outros sistemas?
— Segurança de acesso: previne acesso não autorizado ao sistema?
— Conformidade: está de acordo com padrões, convenções ou regras?
• Confiabilidade: descreve a capacidade do software de realizar suas funções sem falhas. Pergunta‑se: 
“O software é tolerante a falhas?”.
— Subcaracterísticas:
— Maturidade: qual a frequência em que falhas ocorrem?
— Tolerância a falhas: como o sistema se comporta na presença de problemas?
— Recuperabilidade: é capaz de se restabelecer em caso de ocorrência de falha?
• Usabilidade: descreve quão fácil um sistema é de ser utilizado. Pergunta‑se: “O software é fácil de 
usar?”.
— Subcaracterísticas:
— Inteligibilidade: o software é de fácil entendimento para o uso?
— Apreensibilidade: o sistema é fácil de aprender a usar?
— Operacionalidade: é fácil de utilizar?
— Atratividade: quão agradáveis são a navegação e o uso do software?
31
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
• Eficiência: descreve qual é a relação entre o desempenho e os recursos utilizados. Pergunta‑se: “O 
software é fácil de usar?”.
— Subcaracterísticas:
— Comportamento em relação ao tempo de resposta: o tempo de resposta do sistema está de 
acordo com as expectativas?
— Utilização de recursos: quanto tempo o sistema utiliza dos recursos computacionais (CPU, 
disco e memória)?
• Manutenibilidade: descreve qual é a facilidade de fazer as alterações. Pergunta‑se: “O software é 
fácil de alterar?”.
— Subcaracterísticas:
— Analisabilidade: qual o esforço para identificar as causas de falhas?
— Modificabilidade: qual o esforço para realizar as alterações a eventuais mudanças no 
sistema?
— Estabilidade: qual o risco de efeitos inesperados de alterações?
— Testabilidade: qual o esforço para testar o software alterado?
Qualidade interna 
e externa
Funcionalidade
Adequação 
Acurácia
Interoperabilidade
Segurança e acesso
Conformidade
Confiabilidade
Maturidade
Tolerância a falhas
Recuperabilidade
Conformidade
Usabilidade
Inteligibilidade
Apreensibilidade
Operacionalidade
Atratividade
Conformidade
Eficiência
Comportamento em 
relação ao tempo
Utilização dos 
recursos
Conformidade
Manutenbilidade
Analisabilidade
Modificabilidade
Estabilidade
Testabilidade
Conformidade
portabilidade
Adaptabilidade
Capacidade para ser 
instalado
Coexistência
Capacidade de 
substituir
Conformidade
Figura 10 – Modelo de referência da norma ISO/9126
32
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade I
• Portabilidade: descreve qual é a facilidade de transferir a aplicação para outro ambiente. 
Pergunta‑se: “O software é utilizável em outro ambiente?”.
— Subcaracterísticas:
— Adaptabilidade: qual a facilidade de se adaptar o produto para funcionar em outros 
ambientes operacionais?
— Capacidade paraser instalado: qual o esforço para instalar o software em outros ambientes?
— Coexistência: o software está de acordo com padrões referentes à portabilidade?
— Capacidade de substituir: qual o esforço de utilizar o software em substituição a outro?
2.2.1 Métricas de qualidade
A norma ISO/IEC 9126 não define métricas para utilização nas características propostas, mas 
define três classes de aplicação de métricas que auxiliam as empresas na criação de suas próprias 
métricas.
Com base na estrutura apresentada na Figura 11, tem‑se as classes de métricas externas, de métricas 
internas e a qualidade em uso definidas pela norma.
As métricas externas definem indicadores para avaliar um software por meio da medição do 
comportamento do sistema quando da sua execução. O objetivo das métricas externas é medir se o 
software satisfaz as necessidades de operação do sistema pelos usuários. Por exemplo: avaliando a 
característica de eficiência e a subcaracterística de tempo de resposta, cria‑se a métrica X para medir o 
tempo que a aplicação leva desde o acesso até a abertura da página inicial. Com essa métrica é possível 
avaliar se a aplicação atende aos requisitos de desempenho esperados.
9126-1
Modelo qualidade
9126-3
Métricas internas
9126-2
Métricas externas
9126-4
Qualidade em uso
Figura 11 – Estrutura da série de normas da ISO/9126
As métricas internas são aplicáveis para avaliar o software durante sua construção, ou seja, para 
a garantia da qualidade. Por meio das métricas internas é possível medir a qualidade de produtos 
33
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
intermediários produzidos e predizer a qualidade final do software. Por exemplo: avaliar o número de 
erros encontrados em revisões.
A qualidade em uso avalia a qualidade do software na perspectiva do uso cotidiano pelos usuários. 
Nesse cenário, são avaliadas a efetividade, a produtividade, a segurança e a satisfação do usuário com 
o software.
A norma ISO/IEC 9126 pode ser utilizada para definir os padrões de qualidade esperados pelos 
usuários e para a avaliação da garantia da qualidade durante a construção do software, bem como para 
o controle de qualidade por meio da verificação antes da entrega ao usuário final.
Sua aplicação é idêntica aos requisitos de McCall, porém com mais características que devem 
ser avaliadas. O exemplo de aplicação demonstrado no tópico referente ao Modelo de McCall 
serve de referência para a aplicação da norma ISO/IEC 9126, utilizando o mesmo princípio de 
adaptação ao tipo de software e posteriores pontuação e avaliação da qualidade do produto de 
software.
 Lembrete
A norma ISSO/IEC 9126 pode ser utilizada como checklist para definir 
os requisitos não funcionais e para avaliar se estes estão atendidos ao final 
da construção do software.
2.3 Norma ISO/IEC 12207 – Ciclo de vida do software
A norma ISO/IEC 12207 descreve os processos de ciclo de vida de um produto de software e 
foi publicada em 1995. A norma define um conjunto de processos que padroniza as atividades 
e orienta o desenvolvimento, a manutenção e a aquisição para as empresas de desenvolvimento 
de software.
 Observação
Ciclo de vida é uma estrutura que contém atividades aplicadas ao 
desenvolvimento, à operação e à manutenção de software, desde a 
definição de requisitos até o término de seu uso (ISO, 2008).
A norma ISO/IEC 12207 está estruturada em três grupos de processo: os processos fundamentais, 
que abrangem a execução do desenvolvimento do software; os processos de apoio, que são 
as atividades de suporte e qualidade do software; e os processos organizacionais, que são as 
atividades que permitem a manutenção e a melhoria dos processos. A organização desses processos 
é apresentada na Figura 12.
34
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade I
Processos fundamentais
Aquisição
Fornecimento
Desenvolvimento
Operação
Manutenção
Processos de apoio
Documentação
Gerência de configuração
Garantia da qualidade
Verificação
Validação
Revisão
Auditoria
Resolução de problemas
Adaptação
Processos Organizacionais
Gerência
Melhoria
Infraestrutura
Treinamento
Figura 12 – Estrutura da norma ISO/IEC 12207, publicada em 1995
2.3.1 Processos fundamentais
Execução do desenvolvimento, da operação e da manutenção do software durante o seu ciclo de 
vida.
• Aquisição
Define as tarefas do adquirente de software. Inclui as atividades de definição das necessidades 
de adquirir um software, pedido de proposta, seleção de fornecedores, gerência da aquisição e 
aceitação do software.
• Fornecimento
Define as tarefas do fornecedor ou da organização que provê o software. Abrange as atividades 
de preparação da proposta, assinatura de contrato, determinação dos recursos necessários, 
planejamento do projeto e entrega do software.
• Desenvolvimento
Define as tarefas do desenvolvedor ou da organização que desenvolve o software. Inclui as 
atividades de definição de requisitos, análise, projeto, codificação, integração, testes, instalação e 
aceitação do software.
• Operação
Define as tarefas a serem executadas pelo operador ou pela organização que presta serviço de 
manutenção do seu ambiente computacional para seus usuários.
• Manutenção
Define as tarefas a serem realizadas por quem presta serviços de manutenção do software. Inclui 
as atividades de gerenciamento das alterações, migração e descontinuação do software. Esses 
tópicos são detalhados no tópico 8.
35
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
ENGENHARIA DE SOFTWARE II
2.3.2 Processos de apoio
Definem as tarefas que auxiliam outros processos, principalmente, as relacionadas à qualidade do 
software.
• Documentação
Define as tarefas para registrar as informações produzidas por um processo. Inclui as atividades 
de produção, edição, distribuição e manutenção dos documentos necessários a gerentes, 
desenvolvedores e usuários do software.
• Configuração
Define as tarefas de identificação e controle dos artefatos produzidos no desenvolvimento do 
software. Engloba as atividades de identificação, controle, armazenamento, liberação, manipulação, 
distribuição e modificação dos artefatos que compõem o software.
• Garantia da qualidade
Define as tarefas para garantir que o software esteja seguindo os padrões de qualidade 
estabelecidos. Técnicas de revisão, auditoria, verificação e validação podem ser utilizadas.
• Verificação
Define as tarefas para verificar se os artefatos de software atendem aos requisitos estabelecidos.
• Validação
Define as tarefas para validação dos requisitos e do software final e se estão de acordo com a 
proposição inicial.
• Revisão
Define as tarefas para avaliação da situação e dos produtos de uma atividade. Atividade essencial 
para a garantia da qualidade.
• Auditoria
Define as tarefas para determinar a conformidade de requisitos, planos e contrato aos padrões 
estabelecidos.
• Resolução de problemas
Define as tarefas para análise e eliminação dos problemas identificados durante a execução dos 
processos de desenvolvimento, de operação e de manutenção do software.
2.3.3 Processos organizacionais
Definem as tarefas que permitem a manutenção ou a melhoria contínua dos processos.
• Gerência
Define as tarefas de gerenciamento do projeto durante o ciclo de vida.
36
Re
vi
sã
o:
 Ju
lia
na
 -
 D
ia
gr
am
aç
ão
: J
ef
fe
rs
on
- 
29
/1
2/
14
Unidade I
• Infraestrutura
Define as tarefas de fornecimento de recursos para outros processos, tais como hardware, software, 
ferramentas e técnicas.
• Melhoria
Estabelece as tarefas que visam medir, controlar e melhorar o seu ciclo de vida.
• Treinamento
Estabelece as tarefas necessárias para manter o pessoal treinado e o treinamento dos novos 
funcionários.
2.3.4 Processos de adaptação
Camada que proporciona a flexibilidade necessária a todo processo. Estão definidas as tarefas para 
adequar