Unidade II - Engenharia e Qualidade de Software

Prévia do material em texto

1 
 
 
 
 
 
 
 
ENGENHARIA E QUALIDADE DE SOFTWARE 
 
 
Unidade II 
Qualidade, Testes e Manutenção do Software 
 
 
 
 
Prof. Me. Edson Quedas Moreno 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
MORENO, Edson Quedas 
 
 
 Engenharia e Qualidade de Software (livro-texto I) / Edson 
Quedas Moreno. São Paulo: Pós-Graduação Lato Sensu UNIP, 
2019. 
 
 44 p. : il. 
 
 1. Qualidade e produtividade de software. 2. Testes de 
software. 3. Manutenção do software. I. MORENO, Edson 
Quedas. II. Pós-Graduação Lato Sensu UNIP. III. Título. 
 
 
 
APRESENTAÇÃO DO PROFESSOR-AUTOR 
 
Possui mestrado em Engenharia de Produção pela 
Universidade Paulista (UNIP), ênfase em Sistemas de 
Informação (2002), graduação em Engenharia Eletrônica pela 
Faculdade de Engenharia Industrial (FEI, 1983), ênfase em 
Computação e pós-graduação lato sensu em Novas Tecnologias 
de Ensino-Aprendizagem pela UniÍtalo (2011). Atuou na 
coordenação de cursos de 1989 até 2016, pelas instituições 
UniÍtalo e Kroton/Anhanguera. É atualmente professor e 
conteudista de cursos de graduação e pós-graduação, na área de 
negócios, computação e informação pelas instituições UNIP e UniÍtalo. Exerceu 
atividades de professor, tutor e conteudista, desde 1989, pelas instituições Senac, 
Kroton/Anhanguera, FECAP. MBA em Engenharia de Software e da Informação pela 
UNINOVE. Na parte corporativa: desde 2002, é diretor da empresa ASSERTI, de 2009 
até 2012, sócio das empresas Consultoria EaD e ITGVBR, de 1994 até 2000 gerente 
de sistemas na Panrotas Editora, de 1985 até 1994, analista de sistemas pela 
Sistemas e Computadores (SISCO) e, de 1983 até 1985, Programador pela 
Digilab/Bradesco. Áreas de conhecimento: computação e informação – ênfase em 
engenharia de software, projetos de software e de sistemas e tecnologias de ensino a 
distância; e em engenharia de produção – com ênfase em administração, projetos, 
logística e produção. Em aspectos comunitários: de 2005 a 2006 foi gerente do 
Departamento de Extensões de Assuntos Comunitários pela UniÍtalo (DEAC), em 
2006 projetou e efetivou o Projeto Farol Verde (educação para crianças carentes) com 
apoio do Centro Universitário Ítalo Brasileiro, Prefeitura de São Paulo, em parceria 
com o 12º BPM/M SP, e, em 2015, projetou e efetivou um Hackathon (maratona de 
programação de software por 30 horas contínuas com a participação de 200 alunos), 
com apoio da Kroton / Anhanguera e Microsoft, promovido pela Secretaria Municipal 
de Promoção da Igualdade Racial da Prefeitura de São Paulo (SMPIR), em conjunto 
com o Banco Interamericano de Desenvolvimento (BID). 
 
 
SUMÁRIO 
 
INTRODUÇÃO .............................................................................................................................. 6 
3. QUALIDADE E PRODUTIVIDADE DE SOFTWARE ....................................................... 7 
3.1. Qualidade: uma abordagem da engenharia de software ................................................. 7 
3.2. Fatores da qualidade de software .................................................................................... 7 
3.2.1 Processo de controle da qualidade do software .............................................................. 8 
3.2.2 Garantia de Qualidade de Software (GQS) – Software Quality Assurance (SQA) .......... 8 
3.2.3 Custo da qualidade ........................................................................................................... 9 
3.2.4 Fatores e Métricas da qualidade do software ................................................................ 10 
3.2.5 Principais métricas de qualidade do software ................................................................ 11 
3.3 Qualidade do produto da engenharia de software: ISO/IEC 9126 e ISO 25000 (NBR 9126-1 
ABNT, 2003) 13 
3.3.1 Objetivo ........................................................................................................................... 14 
3.3.2 Estrutura do modelo de qualidade ................................................................................. 14 
3.3.3 Modelo de qualidade para qualidade externa e interna ................................................. 15 
3.3.4 Modelo de qualidade para qualidade em uso ................................................................ 16 
3.3.5 Norma Square ISO/IEC 25000 – Software Product Quality Requirements and Evaluation
 17 
3.4 Sistemas da qualidade: ISO 9001 e ISO 90003............................................................. 18 
3.4.1 A série ISO 9000 ............................................................................................................ 18 
3.4.2 Descrição da série ISO 9000 e outros relacionados ...................................................... 18 
3.4.3 ISO 9001 ......................................................................................................................... 19 
3.4.4 ISO 90003 ....................................................................................................................... 20 
3.5 ISO 12207 – Processos do ciclo de vida do software .................................................... 21 
3.6 Modelo de qualidade de software: Capability Maturity Model Integration (CMMI) ......... 23 
3.6.1 Os cinco níveis de maturidade ....................................................................................... 24 
Fonte: CMMI Product Development Team – SEI (2000) ............................................................ 24 
3.6.2 Áreas Chave de Processo (ACP) (Key Process Area – KPA) ....................................... 25 
3.7 Modelo de qualidade de software: SPICE – ISO 15504 ................................................ 25 
3.7.1 Elementos normativos da ISO 15504 ............................................................................. 26 
3.7.2 Dimensão dos processos da ISO 15504 ........................................................................ 27 
3.8 Exercício discursivo comentado ..................................................................................... 28 
4. TESTES De SOFTWARE ............................................................................................... 30 
4.1 Fundamentos dos testes de software ............................................................................ 30 
4.2 Verificação e Validação (V&V) ....................................................................................... 30 
4.2.1 Atividade de verificação .................................................................................................. 31 
4.2.2 Atividade de verificação e depuração de falhas (debug) do código fonte ..................... 31 
4.2.3 Engenharia de requisitos e a atividade de validação ..................................................... 32 
 
 
4.2.4 Critérios de validação ..................................................................................................... 33 
4.3 Técnicas de testes de software ...................................................................................... 33 
4.3.1 Abordagens top-down e bottom-up ................................................................................ 33 
4.3.2 Testes Alfa e Beta .......................................................................................................... 34 
4.3.3 Testes Caixa-Branca e Caixa-Preta ............................................................................... 35 
4.4 Exercício discursivo comentado ..................................................................................... 36 
5 MANUTENÇÃO DO SOFTWARE .................................................................................. 38 
5.1 Fundamentos da manutenção ........................................................................................ 38 
5.2 Tipos de manutenção .....................................................................................................38 
5.3 Procedimentos de manutenção ...................................................................................... 39 
5.4 Gerenciamento de mudanças ........................................................................................ 39 
5.5 Gerenciamento de versões e releases ........................................................................... 40 
5.6 Exercício discursivo comentado ..................................................................................... 41 
REFERÊNCIAS ........................................................................................................................... 43 
BIBLIOGRAFIA............................................................................................................................ 43 
 
6 
 
INTRODUÇÃO 
 
A qualidade do software norteia todos os avanços da engenharia nesta área. O 
cliente atual é o foco das atenções no avanço da tecnologia. O cliente não quer mais 
só o software. Ele busca tecnologias atuais com qualidade, a custo baixo e entrega 
dentro do prazo. A demanda de software aumenta sempre e os produtores de software 
tem que acompanhar tais mudanças para se manterem no mercado. 
Consequentemente as empresas competem em inovações, melhorias e suporte ao 
cliente. Manter o software e adaptá-lo a novas tendências faz desta área uma das 
mais criativas. A elaboração do software é uma atividade de engenharia, que vai 
desde a sua concepção, seu desenvolvimento, a entrega e suporte ao cliente. A 
engenharia de software é apoiada pela qualidade, que se manifesta em todas as fases 
de seu ciclo de vida. Qualidade para iniciar, desenvolver, testar, implantar e manter o 
software ativo, atualizado e com bom desempenho. Esta área lida quase que 
totalmente com o intelecto humano. Novos métodos, ferramentas e técnicas são 
criados dia a dia, para aumentar a eficiência dos testes e da manutenção. Estes 
capítulos lidam com a melhoria do produto software, testes, diagnósticos, manutenção 
e controle das mudanças. Serão abordados os principais modelos da qualidade e suas 
práticas, métodos avançados de testes, o serviço de manutenção e evolução do 
software ao longo de seu ciclo de vida. 
 
Prof. Me. Edson Quedas Moreno 
 
 
7 
3. QUALIDADE E PRODUTIVIDADE DE SOFTWARE 
 
3.1. Qualidade: uma abordagem da engenharia de software 
 
A abordagem da Engenharia de Software trabalha buscando uma única meta: 
produzir software de alta qualidade. 
A qualidade é importante, mas se o usuário não está satisfeito, nada mais 
realmente importa. 
 
 
 
 
Principais objetivos da qualidade: 
 Reunir um conjunto de características, regras e procedimentos de modo que o 
software satisfaça às necessidades de seus usuários; 
 Levar menos tempo para fazer uma coisa correta, do que explicar o porquê foi 
feito errado; 
 Garantir a qualidade mesmo depois de estar pronto o produto; 
 Estabelecer cronogramas e custos reais. 
 
Orientação e estratégia do Programa Brasileiro da Qualidade e Produtividade 
(PBQP) 
 Avaliação e revisão dos indicadores e métodos de medição da qualidade e 
produtividade; 
 Desenvolvimento da infraestrutura de serviços tecnológicos; 
 Ampliação e consolidação da qualidade e produtividade na indústria; 
 Melhoria da qualidade e produtividade no comércio; 
 Melhoria da qualidade e produtividade em serviços; 
 Qualidade e produtividade nas micros e pequenas empresas. 
 
3.2. Fatores da qualidade de software 
 
Os principais fatores da qualidade de software são: 
 Controle da qualidade; 
 Garantia da qualidade; e 
 Custo da qualidade. 
Satisfação do usuário = produto adequado 
 + máxima qualidade 
 + entrega dentro do orçamento e do cronograma 
anaps
Realce
anaps
Realce
anaps
Realce
anaps
Realce
anaps
Realce
 
8 
 
 Processo de controle da qualidade do software 
 
O controle de qualidade é um termo usado amplamente na indústria e se refere 
à definição de processos e padrões a serem estabelecidos na produção. O objetivo é 
aplicar os processos e padrões, e consequentemente eliminar produtos, que não 
atingiram o nível de qualidade exigida. A figura 1 mostra como é aplicado o controle da 
qualidade do software. 
 
Figura 1 – Processo de controle da qualidade do software 
 
Fonte: elaborado pelo autor, 2019. 
 
 
 Garantia de Qualidade de Software (GQS) – Software Quality 
Assurance (SQA) 
 
O propósito da garantia de qualidade de software é fornecer à gerência a 
visibilidade da eficácia (aquilo que dá bom resultado): 
 Examinar minuciosamente um artefato de software ou estado do projeto com a 
finalidade de determinar se há algum desvio com relação aos padrões, 
diretrizes, especificações, procedimentos e planos aprovados; 
 As revisões devem ser aplicadas em vários pontos de função durante o 
desenvolvimento e servem para descobrir defeitos enquanto estes ainda são 
relativamente baratos para serem tratados. 
 
anaps
Realce
anaps
Realce
anaps
Realce
anaps
Realce
anaps
Realce
 
9 
 Custo da qualidade 
 
O custo da qualidade pode ser entendido como o preço justo, que o cliente esteja 
disposto a pagar. Estes custos podem ser divididos em: 
 Custos de prevenção – Planejamento; Revisões; Ferramentas de diagnósticos 
e testes; e Treinamento. 
 Custos de avaliação – Inspeção infra e inter processos; Precisão e manutenção 
dos equipamentos. 
 Custos de falha interna – Refazer; Reparar; e Análise do modo como a falha 
ocorreu. 
 Custos de falha externa – Solução das queixas; Devolução e substituição do 
produto; Manutenção da linha de suporte; e Trabalho de garantia. 
 
Figura 2 – Estudo de Caso sobre a IBM, realizado por Boehm, referente a resultados do controle de 
Qualidade 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Fonte: BOEHM, B. W. IEEE Computer1. (Gráfico adaptado) 
 
1 Disponível em: https://www.computer.org/profiles/barry-boehm. Acesso em: nov. 2002. 
Estudo de Caso: “Os dados relatados por Kaplan, Clark e Tang em 1995, são 
baseados em trabalhos da instalação de desenvolvimento de software da IBM” 
 7.053h. foram gastas para inspecionar 200.000 linhas de código, resultando 3.112 
defeitos em potencial. Se considerar o custo de programador equivalente a US$ 
40,00 por hora, temos que o custo total para prevenir defeitos é igual a US$ 
282.120,00, ou seja, aproximadamente US$ 91,00 por defeito; 
 Sem inspeções, mas com programadores supercuidadosos, foram registrados 1 
defeito por 1.000 linhas de código. O que significa que 200 defeitos foram corrigidos 
em campo a um custo de US$ 25.000,00 por defeito. O que reflete um gasto de US$ 
5.000.000,00, 18 vezes mais caro do que o custo da prevenção. 
Os dados relatados por Kaplan, Clark e Tang (1995) são a confirmação do gráfico 
apresentado pela pesquisa de Boehm (1981), que mostra como o custo da falha aumenta 
se migrarmos do custo da prevenção até os custos de falhas externas. 
 
 
anaps
Realce
anaps
Realce
anaps
Realce
anaps
Realce
 
10 
 
 Fatores e Métricas da qualidade do software 
 
“Qualidade de software é uma mistura complexa de fatores que vão variar com 
cada aplicação diferente e com os clientes que as encomendam” (PRESSMAN, 2002). 
Os fatores de qualidade do software caracterizam um conjunto de métricas 
da qualidade (forma de medição) e que podem ser divididos em dois grupos: 
1. Fatores que podem ser medidos diretamente. 
Exemplo: defeitos por ponto de função; 
2. Fatores que podem ser medidos indiretamente. 
Exemplo: usabilidade ou mantenabilidade (ou manutenibilidade). 
As métricas de qualidade do software são medidas quantitativas que 
permitem aos desenvolvedores do software ter ideia da eficácia do processo de 
software e dos produtos que são conduzidos usando o processo como arcabouço. As 
métricas de qualidade também são usadas para detectar áreas de problemas de 
maneira que soluções possam ser apresentadas, e que o processode software possa 
ser melhorado. 
São coletados dados básicos de produtividade e qualidade pelos engenheiros 
de software, esses dados são analisados, comparados com médias anteriores e 
avaliados para verificar se ocorreu melhoria ou não pelos gerentes de software. 
 
Exemplo de análise: Fatores X Métricas da qualidade do software (PRESSMAN, 
2007; SOMMERVILLE, 2011; PAULA FILHO, 2012). 
MÉTRICA DE 
 QUALIDADE 
FATORES DE 
QUALIDADE 
Confiabilidade Eficiência Mantenabilidade Utilização 
Autodocumentação X 
Complexidade X 
Concisão X X 
Consistência X X 
Eficiência de execução X 
Instrumentação X 
Modularidade X X 
Operabilidade X X 
Precisão X 
Simplicidade X X 
Tolerância a erro X 
anaps
Realce
 
11 
Treinamento X 
 
 
 Principais métricas de qualidade do software 
 
MÉTRICA DEFINIÇÃO 
Acurácia 
Capacidade de o produto de software prover, com o grau de precisão 
necessário, resultados ou efeitos corretos ou conforme acordados. 
Adaptabilidade 
Capacidade de o produto de software ser adaptado para diferentes 
ambientes especificados, sem necessidade de aplicação de outras ações 
ou meios além daqueles fornecidos para essa finalidade pelo software 
considerado. 
Adequação 
Capacidade de o produto de software prover um conjunto apropriado de 
funções para tarefas e objetivos do usuário especificados. 
Analisabilidade 
Capacidade de o produto de software permitir o diagnóstico de deficiências 
ou causas de falhas no software, ou a identificação de partes a serem 
modificadas. 
Apreensibilidade 
Capacidade de o produto de software possibilitar ao usuário aprender sua 
aplicação. 
Atratividade Capacidade de o produto de software ser atraente ao usuário. 
Auditabilidade Facilidade no atendimento às normas que pode ser verificado. 
Auto documentação Nível em que o código-fonte fornece documentação significativa. 
Capacidade 
Capacidade de o produto de software ser instalado em ambiente 
especificado e atender aos requisitos de funcionamento. 
Coexistência 
Capacidade de o produto de software coexistir com outros produtos de 
software independentes, em um ambiente comum, compartilhando 
recursos comuns. 
Corretitude 
Satisfação da especificação e cumprimento dos objetivos da missão do 
cliente. 
Confiabilidade 
A efetiva realização das funções de um programa um nível de desempenho 
e precisão especificadas. 
Conformidade 
Capacidade de o produto de software estar de acordo com normas, 
convenções ou regulamentações previstas em leis e prescrições similares 
relacionadas ao atributo do software. 
 
12 
Estabilidade 
Capacidade de o produto de software evitar efeitos inesperados 
decorrentes de modificações no software. 
Eficácia 
Capacidade de o produto de software permitir que usuários atinjam metas 
especificadas com acurácia e completitude, em um contexto de uso 
especificado. 
Eficiência 
Quantidade de recursos e códigos de computação para realização da 
função. Quanto menor a quantidade, maior será o desempenho do 
software. 
Expansibilidade 
Nível em que o projeto arquitetural de dados ou procedimental pode ser 
estendido. 
Flexibilidade Esforço necessário para modificar um programa operacional. 
Funcionalidade 
Capacidade de o produto de software prover funções que atendam às 
necessidades explícitas e implícitas, quando o software estiver sendo 
utilizado sob condições especificadas. 
Generalidade Âmbito da aplicação potencial dos componentes do programa. 
Integridade 
Diz respeito ao acesso do software ou dados por pessoas não autorizadas 
e que pode ser controlado. 
Modificabilidade 
Capacidade de o produto de software permitir que uma modificação 
especificada seja implementada. 
Interoperabilidade 
Capacidade de o produto de software interagir com um ou mais sistemas 
especificados. 
Integridade Controle do acesso aos dados de pessoas não autorizadas. 
Mantenabilidade Esforço necessário para localizar e corrigir erros num programa. 
Manutenibilidade 
Capacidade de o produto de software ser modificado. As modificações 
podem incluir correções, melhorias ou adaptações do software devido a 
mudanças no ambiente e nos seus requisitos ou especificações funcionais. 
Maturidade 
Capacidade de o produto de software evitar falhas decorrentes de defeitos no 
software. 
Modularidade Diz respeito à independência funcional dos componentes do programa. 
Precisão Nível de precisão dos cálculos e do controle que pode ser verificado. 
Operacionalidade 
Capacidade de o produto de software possibilitar ao usuário operá-lo e 
controlá-lo. 
 
13 
Produtividade 
Capacidade de o produto de software permitir que seus usuários 
empreguem quantidade apropriada de recursos em relação à eficácia 
obtida, em um contexto de uso especificado. 
Segurança 
Capacidade de o produto de software apresentar níveis aceitáveis de riscos 
de danos às pessoas, aos negócios, da propriedade, do ambiente, de 
proteger informações e dados, de forma que pessoas ou sistemas não 
autorizados não possam lê-los nem modificá-los e que não seja negado o 
acesso às pessoas ou sistemas autorizados. 
Testabilidade 
Necessário o teste de um programa para validação, quando criado ou 
modificado, a fim de garantir que realize a função esperada. 
Portabilidade 
Capacidade de o produto de software ser transferido de um ambiente 
operacional para outro. 
Rastreabilidade 
Diz respeito à habilidade de rastrear uma representação de projeto ou 
componente real do programa. 
Recuperabilidade 
Capacidade de o produto de software restabelecer seu nível de 
desempenho especificado e recuperar os dados diretamente afetados no 
caso de uma falha. 
Reutilização Quanto um programa ou parte dele pode ser reusado em outras aplicações. 
Satisfação 
Capacidade de o produto de software satisfazer usuários, em um contexto 
de uso especificado. 
NOTA – Satisfação é a resposta do usuário à interação com o produto e 
inclui atitudes relacionadas ao uso do produto. 
Usabilidade 
Capacidade de o produto de software ser compreendido, aprendido, 
operado e atraente ao usuário, quando usado sob condições especificadas. 
Utilização 
Esforço necessário para aprender, operar, preparar entradas e interpretar 
saídas de um programa. 
Fonte: Pressman, 2007; NBR 9126; NBR 12207. 
 
3.3 Qualidade do produto da engenharia de software: ISO/IEC 9126 e ISO 
25000 (NBR 9126-1 ABNT, 2003) 
 
Figura 3: Marca da NBR ISSO/IEC 9126-1 
 
14 
 
Fonte: NBR 9126-1 ABNT (2003). 
 
 Objetivo 
 
Esta parte da NBR ISO/IEC 9126 descreve um modelo de qualidade do 
produto de software, composto de duas partes: 
a) qualidade interna e qualidade externa; e 
b) qualidade em uso. 
A primeira parte do modelo (figura 4) especifica seis características para 
qualidade interna e externa, as quais são por sua vez subdivididas em 
subcaracterísticas. Essas subcaracterísticas são manifestadas externamente, quando 
o software é utilizado como parte de um sistema computacional, e são resultantes de 
atributos internos do software. 
Exemplos de usos da NBR ISO/IEC 9126: 
 Validar a completitude de uma definição de requisitos; 
 Identificar requisitos de software; 
 Identificar objetivos de projeto de software; 
 Identificar objetivos para teste de software; 
 Identificar critérios para garantia de qualidade; 
 Identificar critérios de aceitação para produtos finais de software. 
 
 Estrutura do modelo de qualidade 
 
Abordagens para qualidade: 
Figura 4 – Processo de controle da qualidade no ciclo de vida do software 
 
15 
 
Fonte: NBR 9126-1 ABNT (2003). 
 
 Modelo de qualidade para qualidade externa e interna 
 
O modelo de qualidade externa e interna mostrado na figura 5 categoriza os 
atributos de qualidade de software em seis características: 
 Funcionalidade; 
 Confiabilidade; 
 Usabilidade; 
 Eficiência; 
 Manutenibilidade; e 
 Portabilidade. 
 
As quais são subdivididas em subcaracterísticas (figura 5) que podem ser 
medidas por meiode suas respectivas métricas para qualidade externa e interna. 
 
 
 
16 
Figura 5 – Modelo de qualidade para qualidade externa e interna. Subcaracterísticas e métricas da ISO 9126 
 
Fonte: NBR 9126-1 ABNT (2003). 
 
 Modelo de qualidade para qualidade em uso 
 
Os atributos de qualidade em uso são categorizados em quatro 
características mostradas na figura 6. 
 Eficácia; 
 Produtividade; 
 Segurança; e 
 Satisfação. 
 
 
 
17 
Figura 6 – Modelo de qualidade para qualidade em uso da ISO 9126 
 
Fonte: NBR 9126-1 ABNT (2003). 
 
 Norma Square ISO/IEC 25000 – Software Product Quality 
Requirements and Evaluation 
 
Esta norma diz respeito à descaracterização e medição de qualidade de 
produto de software. A ISO 25000 é uma evolução das séries de normas ISO/IEC 
9126 e ISO/IEC14598. Square significa Software Product Quality Requirements and 
Evaluation (Requisitos de Qualidade e Avaliação de Produtos de Software). 
A norma ISO/IEC 25000 é composta por dez documentos: 
 
NORMA CONTEÚDO 
9126-1 Modelo de qualidade de software. 
9126-2 Métricas externas. 
9126-3 Métricas internas. 
9126-4 Métricas para qualidade em uso. 
14598-1 Guia de avaliação – visão geral. 
14598-2 Planejamento e gerenciamento de avaliações. 
14598-3 Processo de avaliação para desenvolvedores. 
14598-4 Processo de avaliação para adquirentes. 
14598-5 Processo de avaliação para avaliadores. 
14589-6 Documentação de módulos de avaliação. 
 
 
18 
A reorganização da Norma ISO/IEC 25000 gera uma nova divisão de assuntos 
em cinco tópicos, sendo que cada divisão é composta por um conjunto de documentos 
e trata de um assunto em particular: 
 
Requisitos de 
Qualidade 
Modelo de Qualidade 
Avaliação Gerenciamento de qualidade 
Medições 
 
3.4 Sistemas da qualidade: ISO 9001 e ISO 90003 
 
 A série ISO 9000 
 
A série ISO 9000, é uma parte dos diversos padrões emitidos pela ISO, a qual 
é definida como “Padrões para a Gerência da Qualidade e Garantia de Qualidade. 
Diretrizes para a Seleção e Uso”. 
Esta série descreve e explica os requisitos de um sistema de qualidade. No 
entanto, ISO-9000 não prescreve algum modelo específico para um Sistema de 
Qualidade. Para obtê-lo as organizações necessitam desenhar seus próprios 
sistemas de qualidade. 
Seu maior objetivo é certificar organizações no que concerne a Padrões de 
Qualidade, em uma determinada área da indústria. A norma ISO 9000 não foi 
desenvolvida especialmente para organizações que desenvolvem software, 
apesar de que foi emitido um adendo para adequar o padrão a empresas de software. 
A série ISO 9000 foi criada sob a premissa de que: “se a produção e a 
administração do sistema de qualidade são corretas, o produto ou serviço que 
é produzido também será correto”. 
 
 Descrição da série ISO 9000 e outros relacionados 
 
A série ISO-9000, provê diretrizes e modelos para orientar a implementação de 
um sistema de Qualidade. Seu primeiro conjunto de normas é o ISO 9000 e está 
dividida em quatro partes, nas quais se esclarecem as diferenças entre os principais 
conceitos de qualidade, e provê diretrizes para a seleção e uso: 
 ISO 9000: Gestão e Garantia da Qualidade: diretriz para a seleção e uso das 
partes: 
o ISO 9000-1: Seleção e uso. 
o ISO 9000-2: Diretrizes genéricas para a aplicação da ISO 9001, ISO 9002 e 
ISO 9003. 
 
19 
o ISO 9000-3: Diretrizes para a aplicação da ISO-9001 em desenvolvimento, 
fornecimento e manutenção de software. 
o ISO 9000-4: Aplicações da gestão de dependência. 
 
A seguir são as normas da ISO 9001 a ISO 9003, nas quais se especificam 
os requisitos do Sistema de Qualidade. A mesma deve ser usada quando existe 
um contrato entre duas partes, o qual requeira a demonstração da capacidade de um 
fornecedor em desenvolver e fornecer um produto, software em nosso caso, com uma 
qualidade garantida. 
 ISO 9001: Modelo de Garantia de Qualidade em projeto, instalação, 
desenvolvimento, produção, arquitetura e serviço. 
 ISO 9002: Modelo de Qualidade em produção, ensaios e instalação. 
 ISO 9003: Modelo de Garantia de Qualidade em inspeção e ensaios finais 
(testes). 
 ISO 9004: Gestão da Qualidade e elementos do sistema da qualidade. 
 
 ISO 9001 
 
A ISO 9001 é usada para demonstrar capacidade de atender aos requisitos 
do cliente, os regulamentares e os da própria organização. Define um conjunto de 
requisitos para o Sistema de Gestão da Qualidade (SGQ) com base nas seguintes 
cláusulas: 
 Responsabilidade gerencial. 
 Sistema de qualidade. 
 Análise crítica de contratos. 
 Controle de projetos. 
 Controle de dados e documentos. 
 Controle de produtos fornecidos pelo cliente. 
 Identificação de produtos e rastreabilidade. 
 Controle do processo. 
 Teste e Inspeção. 
 Controle de equipamentos de testes, medições e inspeções. 
 Situação de testes e inspeções. 
 Controle de produto sem conformidade. 
 Ação corretiva e preventiva. 
 Manuseio, armazenamento, empacotamento, proteção e entrega. 
 Controle de registros de qualidade. 
 
20 
 Auditorias internas de qualidade. 
 Treinamento. 
 Assistência técnica. 
 Técnicas estatísticas. 
 
 ISO 90003 
 
A ISO 90003 é uma evolução da norma ISO 9000-3:2000, que descreve as 
Diretrizes para à aplicação da ISO 9001. Na ISO 90003:2004 os principais pontos 
são: 
 
 Planejamento da realização do Produto: 
 Ciclo de Vida – Deve conter as etapas de teste, verificação, acompanhamento 
(análise crítica) e validação. 
 Plano de Qualidade – Para um projeto específico, requisitos específicos e 
definição das alterações em vigor do SGQ. 
 Requisitos da qualidade (produto e processo). 
 
 Processos relacionados ao cliente: 
 Determinação dos Requisitos do Produto – Elicitação dos requisitos, 
aprovação pelo cliente, requisitos implícitos, requisitos legais, normativos ou do 
próprio fornecedor. 
 Análise crítica dos requisitos – Edital, proposta, contrato, capacidade para 
atender, orientações específicas do software, padrões, plataformas, ambientes, 
ferramentas, ciclo de vida e risco. 
 Comunicação com o cliente – Suporte, manutenção e helpdesk. 
 
 Projeto de Desenvolvimento: 
 Planejamento – Work Breakdown Structure – WBS (Estrutura Analítica do 
Projeto), cronograma, etapas, responsabilidades, atividades de controle, 
interfaces, recursos e ambiente. 
 Entradas – Elementos necessários para compor a WBS. 
 Saídas – Saídas das fases, produto final, código fonte e objeto, manuais, 
documentação e relatórios de testes. 
 Análise crítica de projeto – Design review e tomada de decisão. 
 Verificação – Simulações, walkthrough, inspeções, demonstrações com 
protótipo. 
 Validação – Atendimento aos requisitos no ambiente de uso pretendido; teste 
unitário, integração, sistema, regressão e aceitação. 
 Alteração de projeto – Havendo alterações, deve retornar ao planejamento. 
 
21 
 
 Aquisição: 
 Aquisição de insumos (ferramentas e hardware). 
 Subcontratações ou aquisição de partes das funções do software. 
 Inspeção e recebimento – Verificação, validação, aceitação e testes. 
 
 Produção e Fornecimento de serviço: 
 Controle de produção – Release, entrega, instalação, operação e 
manutenção. 
 Identificação e Rastreabilidade – Gestão de configuração. 
 Propriedade do cliente – Componentes, ferramentas, ambiente operacional e 
de testes, e propriedade intelectual. 
 Preservação do produto – Armazenamento, acesso, proteção contra vírus ou 
deterioração. 
 
 Medição, Análise e Melhoria. 
 
3.5 ISO 12207 – Processos do ciclo de vida do software 
 
Quando o processo envolve a elaboração de um produto, algumas vezes nos 
referimos a ele como ciclo de vida. Assim o processo de desenvolvimento 
de software pode ser chamado de ciclo de vida do software, pois ele 
descreve a ‘vida’ do produto de software desde a concepção até a 
implementação, entrega, utilização e manutenção (PFLEEGER, 2004). 
 
A Norma NBR ISO/IEC 12207– Processos do ciclo de vida do software foi 
criada em 1995 com o objetivo de fornecer uma estrutura comum para que o 
adquirente, fornecedor, desenvolvedor, mantenedor, operador, gerentes e técnicos 
envolvidos com o desenvolvimento de software utilizem uma linguagem comum. Essa 
linguagem comum é estabelecida na forma de processos bem definidos. Esses 
processos são classificados em três tipos: fundamentais, de apoio e organizacionais, 
representados na figura 7 (NBR 12207 ABNT, 1998). 
 
 
 
22 
Figura 7 – NBR ISO/IEC 12207 – Processos do ciclo de vida do software 
 
Fonte: NBR 12207 ABNT (1998). 
 
 
De acordo com Pfleeger (2004), no ciclo de vida do software os estágios do 
desenvolvimento do software são: 
 Análise e definição de requisitos; 
 Projeto do sistema; 
 Projeto do programa; 
 Programação; 
 Teste de unidades; 
 Teste de integração; 
 Teste do sistema; 
 Entrega do sistema; e 
 Manutenção. 
 
23 
Cada estágio pode ser interpretado como um processo (ou coleção de 
processos) e cada processo pode ser descrito de várias maneiras. A modelagem do 
processo inclui diversos e diferentes modelos de conduzir o ciclo de vida do software. 
O arcabouço de processo genérico e o modelo de ciclo de vida clássico do 
software são usados como base para a descrição dos modelos de processo nos 
tópicos a seguir, aplicável à grande maioria dos projetos de software 
(PRESSMAN, 2007. Adaptado): 
 Comunicação: envolve alta comunicação e colaboração com o cliente, 
abrange o levantamento de requisitos e outras atividades. 
 Planejamento: esta atividade estabelece um plano de trabalho de engenharia 
de software. São descritos: técnicas, riscos, recursos, produtos de trabalho e 
cronograma de trabalho. 
 Modelagem: inclui a criação de modelos que permitam ao desenvolvedor e 
cliente, entender melhor os requisitos e o projeto do software. 
 Construção: combina a geração de código e testes necessários. 
 Implantação: o software é entregue ao cliente, que avalia o produto e fornece 
feedback. 
 
3.6 Modelo de qualidade de software: Capability Maturity Model Integration 
(CMMI) 
 
Originalmente definido na v 1.1 em 1993 por Paulk, o Modelo de Maturidade 
e Capacidade para Software (CMM – Capability Maturity Model for Software) foi 
baseado em seis anos de experiência com melhoria de processo de software e a 
contribuição de centenas de revisores. 
O CMM descreve a criação de software, baseadas em práticas administrativas, 
caracterizadas pelas organizações das formas de como elas amadureceram os 
processos para desenvolver e manter software. O CMM acentua a necessidade da 
armação de maturidade do processo, priorizando ações de melhoria, descreve a 
estrutura de maturidade do processo em cinco níveis e os componentes estruturais 
associados. 
O CMM determina práticas recomendadas em certo número de Áreas-Chave de 
Processo (KPA – Key Process Area), que provê a organização do desenvolvimento 
de software, baseada nas melhores estratégias para controlar, manter e evoluir os 
processos administrativos do desenvolvimento de software. 
O CMMI é o modelo de maturidade sugerido recentemente com o fim de unificar 
e agrupar as diferentes usabilidades do CMM e de outros modelos de processos de 
melhoria corporativo, tais como o ISO 9001. São raras as empresas no mundo que 
conseguem atingir o nível 5, a grande maioria fica nos estágios iniciais. No Brasil, até o 
ano (2007), existiam somente 4 empresas que tinham alcançado o nível 5 do CMMI. 
Fases do processo de maturidade: 
 Capacidade do processo de software – É uma descrição de resultados 
previstos e resultados que podem ser arquivados para alcançar os objetivos do 
projeto, que devem ser arquivados para serem utilizados em futuros projetos. 
 
24 
 Desempenho do processo de software – Representa o resultado atual 
comparado com o resultado previsto. Quanto mais o resultado atual se aproximar 
do resultado previsto, melhor é o desempenho do processo de software. 
 Maturidade do processo de software – Indica o quanto o processo de software 
está explicitamente definido. A maturidade mede a consistência entre os 
resultados previstos antes de se começar o processo com aqueles obtidos após 
o fechamento do processo. Deve prover ferramentas administrativas que 
garantem a medição, o controle e a efetivação do processo. 
 
 Os cinco níveis de maturidade 
 
Os níveis de maturidade estão baseados em pequenas etapas no lugar de 
inovações revolucionárias. Esses níveis estão organizados de forma que garantem a 
melhoria contínua do processo. 
Cada nível de maturidade constitui em um conjunto de metas que quando 
satisfeita estabilizam um componente importante do processo. 
 
Figura 8 – Os cinco níveis de maturidade do processo do CMMI 
 
Fonte: CMMI Product Development Team – SEI (2000) 
 
 
25 
 Áreas Chave de Processo (ACP) (Key Process Area – KPA) 
Gerencial 
Planejamento de projeto de 
software e gerência 
Organizacional 
Revisão e controle pela 
gerencia sênior 
Engenharia de software, 
Especificação, design, 
codificação e controle de 
qualidade 
Nível 1 – Inicial (Processo Caótico – indica a fase de iniciação da implementação dos processos) 
Nível 2 – Repetitivo (Processo Disciplinado) 
 Acompanhamento e Controle 
de Projeto 
 Gerência de Configuração 
 Gerência de Requisitos 
 Gerência de Subcontratação 
 Medição e Análise 
 Planejamento do Projeto 
 Garantia de Qualidade de 
Processo e Produto 
 
Nível 3 – Definido (Processo Padronizado e Consistente) 
 Análise de Decisão e 
Resolução 
 Gerência de software 
Integrada 
 Definição do Processo da 
Organização 
 Foco no Processo da 
Organização 
 Programa de Treinamento 
 Validação 
 Desenvolvimento de 
requisitos 
 Gerenciamento de Risco 
 Integração do produto 
 Solução técnica dos 
requisitos 
 Verificação 
Nível 4 – Gerenciado (Processo Previsível) 
 Gerenciamento Quantitativo 
de Processos 
 Desempenho do processo 
organizacional 
 
Nível 5 – Otimização (Melhoria Contínua) 
 
 Gestão do processo 
organizacional 
 Análise e Resolução de 
Causas 
 
 
3.7 Modelo de qualidade de software: SPICE – ISO 15504 
 
A ISO/IEC 15504, também conhecida como SPICE que significa Software Process 
Improvement & Capability dEtermination (Melhoria do Processo de Software e 
Determinação da Capacidade) é a norma que define uma série de atividades para 
manter a qualidade de software, foi publicada em outubro de 2003, mas seu projeto 
começou em 1993 pela ISO com base nos modelos já existentes como ISO 9000 e 
CMMI. Ela é uma “evolução” da ISO/IEC 12207, que possui níveis de capacidade para 
cada processo. 
 
26 
O framework inclui um modelo de referência, que serve de base para o processo 
de avaliação. Um conjunto processos fundamentais que orientam para uma boa 
engenharia de software, e estabelece duas dimensões: 
1. Dimensão de processo; e 
2. Dimensão de capacidade. 
Na dimensão de processo o modelo é dividido em cinco grandes categorias 
de processo: 
 Cliente-Fornecedor; 
 Engenharia; 
 Suporte; 
 Gerência; e 
 Organização. 
Na dimensão de capacidade o objetivo é avaliar a capacitação da organização 
em cada processo e permitir a sua melhoria. O modelo de referência do SPICE 
inclui seis níveis de capacitação dos processos: 
 Incompleto; 
 Realizado; 
 Gerenciado; 
 Estabelecido; 
 Previsível; ou 
 Otimizado. 
 
 Elementos normativos da ISO 15504 
 
Os elementos normativos da ISO 15504 – SPICE, apresentado na figura 9, 
estabelecem um plano de análise e desenvolvimento para efetivar o processo de 
avaliação. 
 
 
 
27 
Figura 9 – Elementos normativos da ISO 15504 – SPICE 
 
Fonte: CÔRTES (2017) 
 
 Dimensão dos processos da ISO 15504 
 
Observe a figura 10, similar a ISO 12207 em que estabelece as áreas de 
processos: Primários, Organizacionais e de Apoio. Na dimensão dos processos da 
ISO 15504 apresenta os subprocessos erespectivas atividades. 
 
 
 
28 
Figura 10 – Dimensão dos processos da ISO 15504 – SPICE 
 
Fonte: CÔRTES (2017) 
 
3.8 Exercício discursivo comentado 
 
O Capability Maturity Model Integration (CMMI) é um programa e serviço de 
treinamento e certificação para aprimoramento de processos administrados e 
comercializados, exigidos por muitos programas do Departament of Defense USA 
(DOD) e do governo para contratos governamentais, especialmente desenvolvimento 
de software. A Universidade Carnegie Mellon afirma que o CMMI pode ser usado para 
orientar a melhoria de processos em um projeto, divisão ou a organização inteira do 
desenvolvimento do software. Para avaliar nas organizações o estado de maturidade 
de um software a SEI utiliza o CMMI, que define em média dezenove Áreas-Chave de 
Processo (KPA) das atividades requeridas em cinco níveis de maturidade dos 
processos. Explique os cinco níveis de maturidade e cite algumas de suas KPA. 
 
 
 
29 
Resposta: 
Nível 1: Inicial – O processo encontra-se em um estado caótico. Poucos processos 
estão definidos e o sucesso depende do esforço individual. 
Nível 2: Repetitivo – O processo básico de gerenciamento do projeto está feito e está 
estabelecido às tarefas, custos, tempo e funcionamento. É necessário 
disciplinar o processo e estabelecer as tarefas: 
 Acompanhamento e Controle de Projeto; 
 Configuração do software gerenciável; 
 Garantia da qualidade do software; 
 Subcontratos de software gerenciável; 
 Tarefas e omissões do projeto de software; 
 Planejamento do projeto de software; e 
 Gestão dos requisitos. 
Nível 3: Definido – As atividades do processo de software para a gerência e 
engenharia estão documentadas, iniciadas e integradas dentro da 
organização. Deve-se estabelecer as tarefas: 
 Revisões minuciosas; 
 Coordenação intergrupos; 
 Prática da engenharia no produto de software; 
 Gestão da integração do software; 
 Programa de treinamento; 
 Definição do processo organizacional; e 
 Foco organizacional no processo. 
Nível 4: Gerenciável – São colhidos detalhes mensuráveis sobre o processo e o 
produto de software. Deve-se estabelecer: 
 Gestão da qualidade no software; e 
 Gestão do processo de quantificação. 
Nível 5: Otimizado – A melhoria contínua do processo está habilitada pelo retorno da 
quantificação do processo, testes inovativos de ideias e tecnologia. Deve-se 
estabelecer: 
 Gestão de mudanças do processo; 
 Gestão de mudanças de tecnologia; e 
 Prevenção de defeitos. 
 
 
 
 
30 
4. TESTES DE SOFTWARE 
 
4.1 Fundamentos dos testes de software 
 
O teste do software é destinado a mostrar que um programa faz o que é 
proposto a fazer e para descobrir os defeitos do programa antes do uso. Quando se 
testa o software, o programa é executado usando dados fictícios. Os resultados do 
teste são verificados à procura de erros, anomalias ou informações sobre os atributos 
não funcionais do programa (SOMMERVILLE, 2011). 
O teste muitas vezes requer mais trabalho de projeto do que qualquer outra 
ação da engenharia de software (PRESSMAN, 2011). 
De acordo com Pressman (2011), “o software é testado para revelar erros 
cometidos inadvertidamente quando projetado e construído”. A principal métrica do 
teste de software é a testabilidade, que é necessária para validar o software, quando 
criado ou modificado, de forma a garantir que realiza a função esperada. A 
testabilidade examina as diferentes probabilidades e características comportamentais 
que levam o código a falhar se alguma coisa estiver incorreta. Um índice alto de 
testabilidade indica a facilidade do software de expor as falhas que geram defeitos. 
Um índice baixo de testabilidade indica a dificuldade de identificar falhas que geram 
defeitos. 
Definido por Barry Boehm em 1979 (apud PRESSMAN, 2011 e 
SOMMERVILLE, 2011) O teste é uma parte ampla da engenharia de software e faz 
parte dos processos de validação e verificação (V&V). 
 
4.2 Verificação e Validação (V&V) 
 
A verificação é a ação de verificar ou inspecionar o produto, por meio da 
análise, testes, diagnósticos e simulações, para assegurar que o que foi construído, 
foi construído da forma correta de acordo com as exigências. 
A validação demonstra conveniência satisfatória das partes interessadas no 
uso do produto, no ambiente operacional planejado. O objetivo da validação é 
demonstrar que um produto criado, ou seus componentes satisfaçam o objetivo 
quando é colocado ou testado no ambiente de trabalho, ou seja, no cliente final. A 
validação pode ser solicitada durante o processo de desenvolvimento do produto e 
não somente no produto final. 
 
 
 
A validação vai demonstrar quão o produto pronto na verdade vai operar 
corretamente no usuário, para isso as atividades de validação usam aproximações 
semelhantes ao da verificação. Frequentemente as atividades de validação e de 
verificação trabalham simultaneamente e podem usar porções do mesmo 
ambiente. 
 A verificação assegura você construiu direito; e 
 A validação assegura que você construiu a coisa certa. 
 
31 
 
 Atividade de verificação 
 
No processo de software a engenharia de sistemas define o papel do software, 
que inicialmente passa para a análise dos requisitos de software. A atividade de 
verificação consiste em confrontar o que foi especificado como requisito do software, 
com o resultado obtido pelo software, para garantir que o que foi projetado, foi 
construído de acordo. Nesta fase alguns outros problemas podem ser identificados, 
não somente como um erro ou uma falha, mas também inconsistências com os 
requisitos ou alinhamento da configuração do sistema com o software em produção. 
A atividade de verificação inicia pelo código fonte, no qual vários testes são 
realizados de forma a garantir que lógica de construção do algoritmo está correta, 
posteriormente são realizados testes da estrutura e formato da informação e 
finalmente testes de integração do sistema. Tudo inicia pelo teste da lógica do 
processamento e o ponto chave desta atividade está na verificação do código fonte. 
 
 Atividade de verificação e depuração de falhas (debug) do 
código fonte 
 
Na verificação do código fonte faz-se o que é chamado de depuração. Do 
dicionário da língua portuguesa, depuração é a atividade de limpeza ou exclusão 
de partes indesejáveis. No desenvolvimento do software erros ocorrem, seja por uma 
“trava” do programa ou algum comportamento inesperado. No processo de 
desenvolvimento do software, depuração é a atividade de rastreamento do código 
fonte, com objetivo de corrigir e reduzir falhas no programa de computador. 
Para depurar falhas no software (debug) é necessário fazer o rastreamento 
do código no tempo de execução do programa, de onde vem à palavra Trace 
(rastrear). O rastreamento de um bug inicia com testes para reproduzir o problema e 
buscar o ponto de erro. Ao encontrar o erro faz-se um diagnóstico, que pode ser 
informal ou quando houver necessidade um relatório formal de registro do erro. No 
diagnóstico deve constar o erro identificado e possíveis soluções para o problema. 
A atividade da depuração de falhas (debugging) mostrada na figura 11 
consiste de 4 tarefas: 
1. Reprodução (Reproduce): consiste em rastrear o erro com objetivo de 
identificar a causa de um determinado problema. Neste caso usar breakpoints 
(pontos de parada no software). 
2. Diagnóstico (Diagnose): avaliar o ponto do erro, sua causa, gravidade, grau 
de prioridade, riscos e impactos no comportamento do software (no programa em 
análise e em outros programas). 
3. Corrigir (Fix): Implementação e testes para as correções necessárias. 
4. Refletir (Reflect): aplicação das medidas corretivas de forma a garantir 
solução para o problema, analisar se a mudança não impacta em outras 
características do sistema, validações das entradas/saídas, otimização do código e 
garantia de encapsulamento. 
 
32 
 
Figura 11 – Atividades da Depuração,Testes e Diagnósticos 
 
Fonte: elaborado pelo autor, 2019. 
 
 Engenharia de requisitos e a atividade de validação 
 
Veja a figura 12. A atividade de validação é a última fase do processo da 
engenharia de requisitos, responsável por autorizar o desenvolvimento do sistema / 
software. É a tarefa de apresentar o documento de requisitos em reunião com a 
participação do grupo formado pelos interessados no sistema. O objetivo é aprimorar, 
incluir mudanças propostas e aprovar o início do projeto e desenvolvimento do 
software/sistema. 
 
Figura 12 – Modelo do Processo da Engenharia de Requisitos do software / sistema: 
Estudo da Viabilidade 
do sistema
Especificação, 
Modelagem e 
Documentação
Elicitação e Análise de 
requisitos
Validação
Nova Iteração
Início
Desenvolvimento do 
Sistema
 
Fonte: elaborado pelo autor, 2019. 
 
O documento a ser validado pode ser elaborado para um único sistema, parte 
do sistema ou para cada funcionalidade do sistema. Vale o bom senso, a análise 
decisiva deve ter base no tamanho, complexidade ou qualidade exigida, do sistema 
 
33 
ou da funcionalidade, associada ao seu prazo e custo. Este documento pode ser 
interpretado como o “Aceite do cliente”. 
 
 Critérios de validação 
 
Critérios de validação são especificações para demonstrar o entendimento e 
viabilizar uma implementação de software bem-sucedida, logo que informações 
básicas, funções, desempenho, comportamento e interfaces forem descritos. Esses 
critérios servem de base para as atividades de teste que ocorrerão posteriormente no 
processo de engenharia de software. 
Um Manual do Usuário preliminar pode ser rascunhado para casos em que 
um protótipo não tenha sido desenvolvido. O manual estimula o usuário / cliente a 
revisar o software a partir de uma perspectiva de engenharia humana: 
Exemplo: Comentário do usuário: “A ideia é boa, mas não é desse jeito que eu 
pretendia fazer isso…”.  Esses tipos de comentários devem ser feitos o quanto antes 
no processo revisional. Auxilia a melhoria ou entendimento do produto. O processo 
revisional antes de finalizado, normalmente resulta em modificações na função, 
desempenho, representações da informação, restrições ou critérios da validação. 
 
4.3 Técnicas de testes de software 
 
Um princípio básico na realização de Testes de Software (principalmente em 
Sistemas de média complexidade para cima) é diferenciar a equipe puramente de 
desenvolvimento, da equipe especificamente de testes. 
 
 
O processo V&V inclui inspeção e revisão. São verificados os requisitos do 
sistema, modelos de projeto, o código fonte e outros testes propostos, em diferentes 
situações do processo de software. 
O nível alto de testes do software baseia-se nas opiniões do usuário em obter 
resultados que atendam as suas expectativas, bem como falhas ou omissões de 
requisitos. O nível baixo de testes do software está fundamentado na codificação 
da lógica de processamento, que fornece o resultado desejado pelo algoritmo 
construído. Nesse contexto e de uma forma genérica a visão do desenvolvedor 
baseia-se nas abordagens top-down e bottom-up, veja a figura 13. 
 
 Abordagens top-down e bottom-up 
 
As técnicas top-down são dedutivas, partem do problema destacado pelo 
usuário e procede por parte do usuário e desenvolvedores à análise das questões que 
possam ter gerado o problema. As técnicas bottom-up são indutivas, os 
 Quem desenvolve não testa e quem testa não desenvolve. 
 
34 
desenvolvedores partem de uma determinada situação, possível de gerar algum 
problema ou risco. 
A abordagem top-down (figura 13), verifica a integração dos componentes de 
um sistema começando pelos níveis superiores (operações e interface com o usuário) 
e pode caminhar para os níveis inferiores incluindo testes do código. Em sistemas, o 
foco principal desse teste é caminhar da informação ou resultado, até os dados que a 
geraram. 
A abordagem bottom-up (figura 13), começa pelos níveis inferiores 
(algoritmos, interface com usuário, interface com o hardware, drivers e instalação) e 
caminha para os níveis superiores. A abordagem bottom-up, normalmente é usada 
em instantes do desenvolvimento do software. 
 
Figura 13 – Níveis de abordagens top-down e bottom-up 
 
 
 
 
 
 
 
 
 
 
 
 
Fonte: elaborado pelo autor, 2019. F 
 
 Testes Alfa e Beta 
 
No processo V&V quando um software é construído especificamente para um 
cliente, é normal que ele passe por um Teste de Aceitação por parte do usuário. 
Esse teste por ser conduzido pelo próprio usuário pode passar por uma bateria de 
testes levando às vezes semanas, ou mesmo meses, para ser finalizado. No entanto, 
se o software for feito para vários clientes ou usuários, pela sua amplitude o Teste de 
Aceitação não é viável para ser realizado por cada usuário em potencial. Por isso, a 
melhor estratégia a ser aplicada são as dos Testes Alfa e Beta, destinados a 
validar o software em ambientes amplos de aplicação. 
Para a realização do Teste Alfa existe a necessidade de um ambiente 
controlado. Os usuários são levados a testar o software desde seus estágios iniciais 
de instalação, até a sua operação completa. Tudo realizado num ambiente especial, 
onde ficam registradas todas as impressões dos usuários, suas reações às interfaces 
homem-máquina, erros, operações, e demais problemas de uso. 
top-down 
bottom-up 
Software / Sistema 
Funcionalidade 1 Funcionalidade 2 n Funcionalidades 
Função 1 Função 2 n Funções 
Código 
(software) 
Interface 
(usuário) 
Interface 
(hardware) 
Desempenho e 
Segurança 
 
35 
O Teste Beta é normalmente acompanhado da disponibilização de um release, 
é realizado exclusivamente no habitat do usuário em ambiente descontrolado. 
Tipicamente sem a presença do desenvolvedor, porém monitorados por estes, ao 
contrário do Teste Alfa. Os usuários envolvidos no teste normalmente possuem um 
perfil crítico e colaborador. Em alguns casos, o software é fornecido a usuários de 
forma que os desenvolvedores consigam do próprio usuário suas observações, 
questionamentos e sugestões, registros minuciosos com riqueza de detalhes ou 
registros curtos para quantificar observações. 
 
 Testes Caixa-Branca e Caixa-Preta 
 
Para um sistema encomendado ou configurado especificamente para um 
determinado negócio, o processo de V&V tem como objetivo demonstrar que um 
software atende aos requisitos especificados (verificação) e que realmente atendam 
as expectativas dos stakeholders (validação). Os testes Caixa-Branca e Caixa-Preta 
são guiados pelo código-fonte, respectivas métricas de software aplicáveis e se 
realmente estão atendendo aos requisitos com um bom desempenho e segurança. 
O Teste Caixa-Branca também chamado de Teste Estrutural, é focado nos 
possíveis erros internos de estrutura dos componentes do software ou sistema. 
O Teste Caixa-Preta também chamado de Teste Comportamental visa 
identificar as falhas em seu comportamento externo, com foco nos requisitos 
funcionais e conduzidos na interface de software com o usuário e com o hardware. 
Uma das técnicas de maior aplicação no Teste Caixa-Branca é chamada de 
Teste do Caminho Básico. Esse teste tem como objetivo derivar casos de testes, 
orientados por meio do caminho de execução do programa. Para isso é usado o Grafo 
de Fluxo. O grafo de fluxo pode ser construído com base em um fluxograma ou 
diagrama de atividades. Uma das notações de grafo de fluxo, sugeridas por Pressman 
(2007) é para acompanhamento da codificação como é mostrado de forma adaptada 
na figura 14. 
 
Figura 14 – Simbologia de comandos estruturados para o grafo de fluxo 
 
 
 
 
 
 
 
 
Fonte: adaptado de PRESSMAN, 2007. 
 
Sequência 
Enquanto 
(while) 
Repete … até 
(repeat … until) 
(do … while) 
 
1 
3 2 
4 
Se … então … se não 
(if … then … else) 
1 
2 
2 2 
3 3 
1 1 
 
36 
O Teste Caixa-Preta não é uma alternativa em relação ao Teste Caixa-Branca. 
É um complemento. 
O principalobjetivo do Teste Caixa-Preta é testar as operações ligadas aos 
requisitos funcionais. 
De acordo com Pressman (2011), o Teste Caixa-Preta tenta encontrar erros 
nas seguintes categorias: 
 Funções incorretas ou omitidas; 
 Erros de interface; 
 Erros de estrutura de dados ou de acesso à base de dados pelo usuário; 
 Erros de comportamento ou desempenho; e 
 Erros de iniciação e finalização do software. 
 
Principais técnicas utilizadas nos Testes de Caixa-Preta: 
 Métodos de teste baseados em grafo de fluxo: 
o Modelagem de fluxo de transação – sequência de passos de uma 
determinada transação. 
o Modelagem de estado finito – situação final das operações e das estruturas 
de dados, com objetivo de reduzir redundâncias de códigos e dados. 
o Modelagem do fluxo de dados – modela a sequência de tratamento dos 
dados entre um objeto e outro. 
o Modelagem no tempo – especificação de tempos na execução de 
programas. 
 Particionamento de equivalência – método que divide o domínio de entrada de 
um programa em classes de dados. 
 Análise de valor-limite – avaliação dos limites dos campos de entradas de 
dados. 
 Teste de Matriz Ortogonal – refere-se ao número de parâmetros de entrada em 
relação ao número de ligações às funções operacionais. 
 
4.4 Exercício discursivo comentado 
 
A Assessoria e Serviços em Tecnologia da Informação (ASSERTI) é uma 
empresa que fornece serviços de consultoria na depuração do software, usando a 
engenharia reversa, ou seja, inicia pelas operações do usuário que geraram uma 
determinada informação. O código é rastreado desde a informação gerada até os 
algoritmos que coletaram os dados e que foram responsáveis por gerar a informação. 
Deste serviço é feito um projeto que serve para validação do código. Um de seus 
principais clientes é a auditoria da receita federal, que usa este processo de depuração 
em empresas que possuem sistemas de informação do tipo ERP. 
A atividade de depuração de falhas (debugging) consiste de 4 tarefas. Explique 
cada uma delas: 
 
37 
 
Resposta: 
Reprodução (Reproduce): consiste em rastrear o erro com objetivo de identificar a 
causa de um determinado problema. Neste caso usar breakpoints (pontos de parada 
no software). 
Diagnóstico (Diagnose): avaliar o ponto do erro, sua causa, gravidade, grau de 
prioridade, riscos e impactos no comportamento do software (no programa em análise 
e em outros programas). 
Corrigir (Fix): Implementação e testes para as correções necessárias. 
Refletir (Reflect): aplicação das medidas corretivas de forma a garantir solução para 
o problema, analisar se a mudança não impacta em outras características do sistema, 
validações das entradas/saídas, otimização do código e garantia de encapsulamento. 
 
 
 
38 
5 MANUTENÇÃO DO SOFTWARE 
 
5.1 Fundamentos da manutenção 
 
O processo de mudança do software ocorre em todo o seu ciclo de vida. Várias 
mudanças são feitas: adaptações a novos ambientes operacionais, customização do 
software com base nas mudanças de requisitos, erros de codificação, adaptação de 
novas interfaces, enfim tudo o que é necessário para manter o software operacional e 
adaptado a novas tecnologias. 
 
 
 
 
 
 
 
 
 
 
5.2 Tipos de manutenção 
 
Extraído e adaptado do modelo de Sommerville (2003), a manutenção será 
necessária durante todo o ciclo de vida útil do software, e pode ocorrer motivada por 
três tipos fundamentais: 
TIPOS DE 
MANUTENÇÃO 
DESCRIÇÃO 
Manutenção para 
reparar defeitos no 
software 
A correção de erros de codificação é um processo 
relativamente barato comparado com os erros de 
projeto. Os maiores custos estão nos erros de 
requisitos, pois irá implicar num reprojeto. 
Manutenção para 
adaptar o software a 
um ambiente 
operacional diferente 
É a típica manutenção de adaptação devido a alguma 
alteração na infraestrutura da tecnologia, tal como: 
mudança ou atualização do Sistema Operacional, 
estrutura do Banco de Dados modificada, ou até mesmo 
mudanças de hardware. 
Manutenção para fazer 
acréscimos à 
funcionalidade do 
sistema ou modificá-la. 
Se refere a mudanças organizacionais ou mudança das 
regras do negócio. Consequentemente levando às 
alterações dos requisitos. É a manutenção mais comum 
entre todas as outras. 
 
 Estudo de caso: Leis de Lehman de 1985 (apud PRESSMAN, 2011) 
As leis de Lehman foram produzidas com base no estudo da mudança em sistemas. Foram 
examinados o crescimento e a evolução de uma série de grandes sistemas e software para 
chegar nessas leis. Duas destas leis se destacam: 
 Mudança Contínua: a qual afirma que um programa utilizado em um ambiente do 
mundo real necessariamente tem de ser modificado ou se tornará de maneira 
progressiva menos útil nesse ambiente; 
 Aumento da Complexidade: à medida que um programa em evolução se modifica, 
sua estrutura tende a se tornar mais complexa. Recursos extras precisam ser 
dedicados para preservar e simplificar a estrutura. 
 
 
 
39 
5.3 Procedimentos de manutenção 
 
O Processo de Manutenção é normalmente iniciado pelos pedidos de mudança 
por parte dos vários usuários que utilizam o sistema. Isso pode ser de maneira informal, 
ou preferencialmente formalizado, com uma documentação estruturada. Em seguida é 
verificado o custo e o impacto das mudanças sugeridas com as mudanças aprovadas, 
um novo release do sistema é planejado. 
Observe a figura 15. Uma vez bem estruturado, o Sistema 1 que embora tenha 
custos maiores de planejamento, exigiu no período de manutenção um menor custo e 
tempo. O Sistema 2 foi planejado mais rapidamente com custo e tempo inferiores ao 
do Sistema 1, porém exigiu no período de manutenção um maior custo e tempo. O 
resultado final é que no ciclo de vida o Sistema 1 obteve sobre o Sistema 2 um menor 
custo global em menor tempo. 
 
Figura 15 – Gráfico de custo e tempo do desenvolvimento e manutenção do software 
 
 
 
 
Fonte: elaborado pelo autor, 2019. 
 
Existem equipes de manutenção especializadas que atuam somente em 
Manutenção Corretiva, ou seja, somente quando existir um pedido dos usuários é 
que se atua no problema. No entanto, a melhor estratégia é a Manutenção 
Preventiva que é na qual se detectam possíveis falhas e previnem-se erros. E com 
um bom acompanhamento da equipe técnica, tais erros são registrados para que 
possa realizar uma força tarefa para correção de tais erros. 
 
5.4 Gerenciamento de mudanças 
 
Durante os testes de sistemas, ou ainda depois da entrega do software ao 
cliente, os procedimentos de Gerenciamento de Mudanças devem ser aplicados. O 
principal passo desse processo é a utilização de um formulário intitulado de 
“Requisição de Mudança”. Veja o modelo da figura 16. Posteriormente ocorre o 
procedimento de manutenção do software. 
 
Modelo de formulário de requisição de mudança 
Formulário de Requisição de Mudança 
Projeto: SuperBlue Código da mudança: 190729 2106 
Requisitor da Mudança: Edson Moreno Data: 29/07/2019 
Custo ($) e 
Tempo (t) 
PLANEJAMENTO 
PLANEJAMENTO 
 
MANUTENÇÃO 
MANUTENÇÃO Sistema 1 
 
Sistema 2 
 
40 
 
Requisito de mudança: 
Quando é removido um valor na tabela de custos fixos o valor do custo total não é alterado. 
Análise da mudança: 
Analista: Milton del Rio Blas Data: 29/07/2019 
Componente afetado: Algoritmo de cáculo do custo total. 
 
Avaliação: 
Haverá necessidade de mudança no código de cálculo do custo total na lista de custo fixo. 
 
Prioridade: Alta Prazo estimado de entrega: 3 dias 
 
 
 
Autorizada mudança: SIM ( X ); NÃO ( ); Aguardar para o dia ____ / ____ / ________. 
 
 Gerente Responsável: ____________________________ 
 
Fonte: elaborado pelo autor, 2019. 
 
Um formulário de Requisição de Mudança pode conter as seguintes 
informações: registro da solicitação da mudança, recomendações, custos, datas de 
solicitação, aprovação, implementaçãoe validação da mudança. É sugerido também 
existir um espaço para um esboço, mostrando como a mudança deverá ser 
implementada. 
 
5.5 Gerenciamento de versões e releases 
 
Como dito anteriormente, as mudanças ocorrem em todo o ciclo de vida do 
software, quando aumentam o nível de complexidade e confusão compromete o 
controle na entrega do produto ou subproduto do software. O Gerenciamento de 
Versões e Releases acompanha e identifica o desenvolvimento das diferentes versões 
e releases de um sistema. Este processo é chamado de versionamento. 
O release é a versão do software ou do sistema produzido que é autorizada 
para distribuir ao cliente. Sempre existem muitas versões de um sistema, mais do que 
releases, porque as versões são criadas para testes ou desenvolvimento interno e 
não são liberadas para os clientes. 
Para a devida identificação de componentes existem três técnicas básicas: 
 
 
41 
TÉCNICAS BÁSICAS DESCRIÇÃO 
Numeração de versões 
É o esquema de identificação mais comum. Atribui-se um 
número, explícito e único, de versão ao componente. Um 
acompanhamento para este controle é apresentado na figura 
17. 
Identificação baseada 
em atributos 
Cada componente recebe um nome e um conjunto de 
atributos, que não é único em todas as versões. 
Identificação orientada a 
mudanças 
Além do anterior é associado uma ou mais solicitações de 
mudança. 
 
Figura 17 – Modelo de grafo de controle aplicado na numeração de versões 
 
 
 
 
 
 
 
Fonte: elaborado pelo autor, 2019. 
 
Observe a figura 17. As versões (V 1.0, V 1.1 e assim por diante) acompanham as 
mudanças realizadas pelos desenvolvedores e os releases (Rel 1.0 e Rel 1.1) correspondem 
às versões aprovadas para distribuição ao usuário. A numeração do release independe da 
numeração da versão, porém neste caso pode se considerar o primeiro dígito como uma 
mudança de estrutura. Observe o exemplo abaixo. 
 
 
 
 
 
 
 
 
 
5.6 Exercício discursivo comentado 
 
(ENADE 2011 – Tecnologia em Análise e Desenvolvimento de Sistemas. 
Adaptado) – A norma ISO/IEC FDIS 14764 (2006) estabelece definições de vários 
tipos de manutenção e fornece um guia para gerenciar o processo de manutenção, 
que pode ser aplicado no planejamento, execução e controle, revisão e avaliação, e 
fechamento do processo de manutenção. Segundo essa norma, solicitações de 
Exemplo: Nomenclatura dos atributos de versionamento. 
Padrão de numeração de versão: X.YZ, onde: 
 X – corresponde a uma mudança de estrutura do software. 
 Y – inserção ou adaptação de novas funções ou funcionalidade. 
 Z – correções ou implementações no código fonte. 
 
V 1.0 V 1.1 V 1.1a 
V 1.1b 
V 1.2 V 1.3 V 1.31 
Rel 1.0 Rel 1.1 
 
42 
modificação são classificadas como corretiva, preventiva, adaptativa ou perfectiva. Os 
detalhes de como implementar ou realizar as atividades e tarefas de manutenção não 
são especificadas pela norma, sendo de responsabilidade do mantenedor. 
(ISO/IEC FDIS 14764. Software Engineering – Software Life Cycle Processes – 
Maintenance. 2006.) 
Considerando os tipos de manutenção e as atividades de implementação do 
processo, avalie as afirmações a seguir: 
I. O mantenedor deve desenvolver, documentar e executar planos e 
procedimentos para realizar as atividades e tarefas do processo de 
manutenção. 
II. O mantenedor deve alterar a configuração do sistema para corrigir erros 
identificados pelos usuários usando a manutenção perfectiva. 
III. O mantenedor deve estabelecer procedimentos para receber, registrar e 
rastrear solicitações de modificação/registro de problemas dos usuários, e 
também prover realimentação para os usuários. 
IV. O mantenedor deve documentar a estratégia a ser usada para melhorar a 
manutenibilidade futura do sistema, usando a manutenção corretiva. 
 
Com base nas solicitações de modificações, avalie as afirmativas acima como 
V (Verdadeira) e F (Falsa) e justifique sua decisão. 
 
Resposta 
I. Verdadeira. As atividades de manutenção devem estar documentadas com 
procedimentos, tipo de testes, diagnósticos e mudanças a serem feitas, para não 
implicar em retrabalho. 
II. Falsa. A configuração não deve ser alterada até que haja a identificação do erro 
por parte do desenvolvedor. 
III. Verdadeira. O feedback para o usuário de todas as tarefas de manutenção é 
essencial, porque permite que o usuário reflita e diagnostique a solução do erro, 
promovendo também um feedback para o desenvolvedor. 
IV. Falsa. A manutenção corretiva corrige falhas e erros ocorridos após a liberação 
do software para o usuário. Para melhorar a manutenibilidade deve-se praticar a 
manutenção perfectiva. 
 
 
43 
REFERÊNCIAS 
 
CMMI Product Development Team. CMMI for Systems Engineering / Software 
engineering, Version 1.02. Staged Representation. Pittsburgh, USA: Carnegie 
Mellon, SEI, 2000. 
FIORINI, Soeli; STAA, Arndtvon; e BAPTISTA, Renam Martins. Engenharia de 
software com CMM. Rio de Janeiro Brasport, 1998. 
NBR 9126-1 ABNT. NBR ISO/IEC 9126-1 – Engenharia de software – Qualidade de 
produto. Rio de Janeiro: ABNT – Associação Brasileira de Normas Técnicas, 2003. 
NBR 9126/14598 ABNT – Associação Brasileira de Normas Técnicas. Guia para 
utilização das normas sobre avaliação de qualidade de produto de software – 
NBR ISO/IEC 9126 e NBR ISO/IEC 14598. Curitiba: ABNT, Maio de 1999. 
NBR 12207 ABNT – Associação Brasileira de Normas Técnicas. NBR ISO/IEC 12207 
– Tecnologia de informação – Processos de ciclo de vida de software. Rio de 
Janeiro: ABNT, 1998. 
PAULA FILHO, W. de P . Engenharia de software: fundamentos, métodos e padrões. 
3. ed. Rio de Janeiro: LTC, 2012. 
PFLEEGER, Shari Lawrence. Engenharia de software. 2. ed. São Paulo: Prentice 
Hall, 2004. 
PRESSMAN, Ph.D. Roger S. Engenharia de software: Uma Abordagem Profissional. 
7. ed. Rio de Janeiro: McGraw-Hill, 2011. 
PRESSMAN, Ph.D. Roger S. Engenharia de software. 6. ed. Rio de Janeiro: 
McGraw-Hill, 2007. 
SALVIANO, Clenio F. Introdução aos modelos de Processo de Software: ISO/IEC 
15504 (SPICE), CMM e CMMI. São Paulo: Simpósio, ITI – Instituto nacional de Tecnologia 
da Informação, 2001. 
SOMMERVILLE, Ian. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice 
Hall, 2011. 
 
BIBLIOGRAFIA 
CÔRTES, Mario L. Modelos de Qualidade de Software: ISO 15504. São Paulo, IC-
UNICAMP, 2017 (Artigo). 
FALBO, Ricardo de Almeida. Qualidade de Processo. A Série ISO 9000. LabES – 
Departamento de Informática – Universidade Federal do Espírito Santo, 2007 (Artigo). 
FOURNIER, Roger. Desenvolvimento e manutenção de sistemas estruturados. 
São Paulo: MAKRON Books, 1994. 
PINTO, Marisa. Introdução ao debugging de software. PPLWARE no comments. 
Disponível em: https://pplware.sapo.pt/software/introducao-ao-debugging-de-software/. 
Acesso em: set. 2016. 
 
44 
PAULK, Mark C.; CURTIS, Bill; CHRISSIS, Mary Beth; WEBER, Charles V. The 
Capability Maturity Model for Software v1.1. Pittsburgh – USA: SEI – Software 
Engineering Institute Customer Relations, 1993. 
PRESSMAN, Ph.D. Roger S. Engenharia de Software. 6a ed. Rio de Janeiro: McGraw-Hill, 2007. 
PRESSMAN, Ph.D. Roger S. Engenharia de Software. 5a ed. Rio de Janeiro: McGraw-Hill, 2002. 
MCT. Qualidade e Produtividade no Setor de Software Brasileiro N.4 (2002). 
Brasília: Ministério da Ciência e Tecnologia / Secretaria de Política de Informática, 
2002. 
PMBOK, Project Management Institute. Project Management Body of Knowledge. 
Pennsylvania, USA: PMBOK Guide. 2000. 
PMBOK, Project Management Body of Knowledge. Um guia do conhecimento em 
gerenciamento de projetos (Guia PMBOK). 4a ed. Atlanta, USA: Project 
Management Institute, Inc. 2010. 
SHEPHERD, George. Microsoft ASP.NET 3.5: passo a passo. – Porto Alegre: 
Bookman, 2009. 
SOMMERVILLE, Ian. Engenharia de software. São Paulo: Pearson Addison Wesley, 
2003.