Engenharia de Software
Prof. Wilkerson de L. Andrade
Versão resumida e traduzida dos slides originais produzidos por Ian Sommerville, Software Engineering, 7th edition. Chapter 22.
Estes slides foram adaptados dos slides gentilmente cedidos pela professora Patrícia D. L. Machado (DSC/UFCG).
Verificação versus Validação
• Verificação:
▫ “Estamos construindo o software de forma correta?”
Software deve estar em conformidade com sua especificação.
• Validação:
▫ “Estamos construindo o produto certo?”
O software deve fazer exatamente o que o usuário requer.
O Processo de V & V
• Trata-se um processo que abrange todo o
ciclo de vida – V & V devem ser aplicados em cada etapa do processo de software.
• Tem dois objetivos principais:
▫ Descoberta de defeitos em um sistema;
▫ Avaliação do sistema quanto a sua utilidade e usabilidade quando em operação.
Metas de V & V
• V & V devem estabelecer confiabilidade de
que o software é adequado ao seu propósito.
• Isto não implica que o software é
completamente livre de defeitos.
• O software precisa ser bom o suficiente para
o seu propósito e o tipo de uso determina o grau de confiabilidade que é necessário.
V & V e Confidência Esperada
para um Software
• Depende do objetivo do sistema,
expectativas do usuário e mercado.
▫ Objetivo do Software
O nível de confidência depende do quão um sistema é crítico para uma organização.
▫ Expectativas do Usuário
Usuários podem ter baixas expectativas com relação a certos tipos de software.
▫ Mercado
Lançar um produto no mercado mais cedo pode ser mais importante do que encontrar defeitos.
Verificação Estática e Dinâmica
• Inspeção de Software. Análise estática do
sistema para a descoberta de problemas (verificação estática)
▫ Pode ser complementada por análise automática
de código e documentação.
• Teste de Software. Exercitar e observar o
comportamento de um produto (verificação dinâmica)
▫ O sistema é executado com dados de teste e seu comportamento operacional é observado.
V & V Estática e Dinâmica
Especificação formal Projeto de alto nível Especificação de requisitos Projeto detalhado Programa Protótipo Teste de programa Inspeções de softwareTeste de Software
• Pode revelar a presença de defeitos, mas
nunca a sua ausência.
• Única técnica de validação para requisitos
não funcionais, visto que o software precisa ser executado para tal.
• Deve ser usado em conjunto com verificação
estática a fim de se atingir uma cobertura completa de V & V.
Tipos de Teste
• Teste de Defeitos
▫ Testes projetados para a descoberta de defeitos.
▫ Um teste com sucesso é aquele que revela a presença de defeitos em um sistema, caso existam (Capítulo 23).
• Teste de Validação
▫ Voltado a demonstrar que o software atende aos seus requisitos.
▫ Um teste com sucesso é aquele que mostra que
requisitos foram implementados de forma adequada.
Teste e Depuração
• Teste de defeito e depuração são duas
atividades distintas.
• Verificação e Validação são voltadas a
detectar defeitos existentes em um software.
• Depuração é voltada a localizar e corrigir
estes defeitos.
• Depuração envolve a formulação de
hipóteses sobre o comportamento do programa que são então testadas para encontrar o(s) defeito(s).
O Processo de Depuração
Localizar erros Projetar reparo de erros Repararerros Testar programanovamente Resultados
dos testes Especificação
Casos de teste
Planejamento de V & V
• Planejamento rigoroso é necessário para
que se possa tirar o maior proveito possível de processos de teste e inspeção.
• Planejamento deve ter ser feito no início do
processo de desenvolvimento.
• O plano deve identificar o balanceamento
entre verificação e teste.
• Planejamento de teste é mais voltado para a
definição de padrões para processos de teste do que da descrição de produtos de teste.
O Modelo V de Desenvolvimento
Especificação de sistema Projeto de sistema Projeto detalhado Código unitário e de módulo, e teste Plano de teste de integração de subsistemas Plano de teste de integração do sistema Plano de teste de aceitação Serviço Teste deaceitação Teste de integraçãode sistemas Teste de integração de subsistemas Especificação
Estrutura de um Plano de Teste
Processo de teste. Descrição das fases principais do processo de teste. Essas fases podem ser como as descritas anteriormente neste capítulo.
Rastreabilidade de requisitos. Os usuários são os mais interessados em que o sistema atenda a seus requisitos e em que os testes sejam planejados de maneira que todos os requisitos sejam individualmente testados.
Itens testados. Os produtos do processo de software a serem testados devem ser especificados.
Cronograma de testes. Um cronograma global de testes e alocação de recursos para esse cronograma está, obviamente, vinculado ao cronograma mais geral de desenvolvimento de projeto.
Procedimentos de registro de testes. Não é suficiente realizar simplesmente os testes; os resultados dos testes devem ser sistematicamente registrados. Deve ser possível auditar o processo de teste para verificar que foi conduzido corretamente. Requisitos de hardware e software. Esta seção deve estabelecer as ferramentas de software necessárias e a utilização estimada de hardware.
Restrições. As restrições que afetam o processo de teste, como falta de pessoal, devem ser antecipadas nesta seção.
Inspeções de Software
• Envolve pessoas examinando uma
representação do software com o objetivo de descobrir anomalias e defeitos.
• Inspeções não requerem a execução do sistema, assim podem ser usadas antes da implementação.
• Pode ser aplicada a qualquer representação do sistema (requisitos, projeto, dados de teste,
etc.)
• Técnica muito eficaz para a descoberta de erros.
Sucessos da Inspeção
• Muitos defeitos diferentes podem ser
descobertos em uma única inspeção. No teste, um defeito pode mascarar outros, assim várias execuções são necessárias.
• O conhecimento do domínio e da linguagem
de programação pode ser reusado de tal
forma que os revisores já conhecem os tipos de erros que ocorrem com mais freqüência.
Inspeções e Testes
• Inspeções e testes são técnicas de verificação complementares.
• Ambas devem ser utilizadas no processo de V & V.
• Inspeções podem verificar a conformidade com uma especificação mas não a conformidade
com os requisitos reais do usuário. • Inspeções não podem verificar as
características não funcionais tais como desempenho, usabilidade, etc.
Inspeções de Programa
• Abordagem formalizada para revisar, linha
por linha, o código fonte do programa.
• Objetivo é a detecção de defeitos (não
correção).
• Defeitos podem ser erros lógicos, anomalias
no código que podem indicar uma condição errônea (por ex. uma variável não
inicializada) ou a não conformidade com padrões organizacionais.
Pré-condições para a Inspeção de
Programa
• Uma especificação precisa deve estar disponível.
• Os membros da equipe de inspeção devem estar familiarizados com os padrões organizacionais.
• Código sintaticamente correto ou outra
representação do sistema deve estar disponível.
• Uma lista de erros deve ser preparada.
• O gerente deve aceitar que a inspeção aumentará os custos no começo do processo de software.
• O gerente não deve utilizar inspeções para avaliação de pessoal, isto é, encontrar quem errou.
O Processo de Inspeção
Planejamento Visão geral Preparação individual Reunião de inspeção Retrabalho AcompanhamentoProcedimento de Inspeção
• Uma visão geral do sistema é apresentada
para o time de inspeção.
• O código e os documentos associados são
distribuídos para o time de inspeção com antecedência.
• A inspeção é realizada e os defeitos
descobertos são anotados.
• Modificações são realizadas para corrigir os
defeitos encontrados.
• Uma re-inspeção pode ou não ser
Papeis na Inspeção
Papel Descrição
Autor e proprietário
O programador ou projetista responsável por produzir o programa ou documento. Ele é responsável pela correção de defeitos
descobertos durante o processo de inspeção.
Inspetor Encontra erros, omissões e inconsistências nos programa e
documentos. Pode também identificar questões mais amplas fora do escopo da equipe de inspeção.
Leitor Apresenta o código ou documento em uma reunião de inspeção. Relator Registra os reunião da reunião de inspeção.
Presidente ou moderador
Gerencia o processo e facilita a inspeção. Relata os resultados do processo ao moderador-chefe.
Moderador-chefe
Responsável pelo aprimoramento do processo de inspeção, pela atualização da lista de verificação, pelo desenvolvimento de
Checklists da Inspeção
• Uma lista de erros comuns deve ser usada para dirigir a inspeção.
• Listas de erros são dependentes da linguagem de programação e refletem os erros
característicos que provavelmente surgirão com o uso daquela linguagem.
• Quanto mais “fraca” é a checagem de tipos da linguagem, maior é a lista de erros mais
comuns.
• Exemplos: inicialização, nomeação de
constantes, término de laços, limites de arrays, etc.
Verificações da Inspeção (1)
Papel Descrição
Defeitos em dados
Todas as variáveis de programa são iniciadas antes que seus valores sejam usados?
Todas as constantes foram denominadas?
O limite superior de vetores deve ser igual ao tamanho do vetor ou Tamanho - 1?
Se são usados strings de caracteres, um delimitador é explicitamente atribuído?
Existe alguma possibilidade de overflow de buffer? Defeitos de
controle
Para cada declaração condicional, a condição está correta? Cada loop está terminando corretamente?
As declarações compostas estão corretamente delimitas entre parênteses?
Em declarações „case‟, todos os casos possíveis são levados em conta?
Se um comando „break‟ é necessário após cada caso nas declarações „case‟, ele foi incluído?
Verificações da Inspeção (2)
Papel Descrição
Defeitos de entrada/saída
Todas as variáveis de entrada são usadas?
Todas as variáveis de saída têm valor atribuído antes de sua saída?
Entradas inesperadas podem fazer com que os dados sejam corrompidos? Defeitos de
interface
Todas as chamadas de funções e de métodos têm o número correto de parâmetros?
Tipos de parâmetros reais e formais se combinam? Os parâmetros estão na ordem correta?
Se os componentes acessam memória compartilhada, ele têm o mesmo modelo de estrutura de memória compartilhada?
Defeitos de gerenciamento de
armazenamento
Se uma estrutura ligada é modificada, todas as ligações foram corretamente reatribuídas?
Se o armazenamento dinâmico foi usado, o espaço foi corretamente alocado?
O espaço de memória é liberado depois de não ser mais necessário? Defeitos de
gerenciamento de exceções
Custo de Inspeção
• 500 declarações/hora durante a revisão
geral.
• 125 declarações/hora durante a preparação
individual.
• 90-125 declarações/hora podem ser
inspecionadas durante a reunião.
• Inspeção é portanto um processo caro.
• A inspeção de 500 linhas de código requer
um esforço de cerca de 40 homens/hora – equivalente a £2800 no Reino Unido.
Análise Estática Automatizada
• Analisadores estáticos são ferramentas de
software para o processamento do código fonte.
• Percorrem o texto do programa e tentam
descobrir potenciais condições de erro e chamar a atenção da equipe de V & V.
• É bastante eficaz como um auxílio às
inspeções de programas. É um
complemento, porém não substitui as inspeções.
Verificação e Métodos Formais
• Métodos formais podem ser aplicados
quando uma especificação matemática do sistema é produzida.
• Pode ser considerado como a última técnica
de verificação estática.
• Envolve uma análise matemática detalhada
da especificação e pode produzir
argumentos formais de que um programa está em conformidade com sua
Argumentos a favor do uso de
Métodos Formais
• A produção de uma especificação
matemática requer uma análise detalhada dos requisitos podendo revelar
inconsistências ou omissões.
• Pode detectar erros de implementação antes
da execução dos testes no momento em que o programa é analisado com relação a sua especificação.
Argumentos contra o uso de
Métodos Formais
• Requer a utilização de notações especializadas que podem não ser compreendidas pelos
especialistas do domínio do probema.
• O desenvolvimento de uma especificação é muito caro e o processo de verificar se um programa está de acordo com sua
especificação é mais caro ainda.
• Talvez seja possível alcançar o mesmo nível de confiança em um programa com um custo
Desenvolvimento de Software
Cleanroom
• O nome é derivado do processo “Cleanroom” na fabricação de semicondutores.
• Filosofia de desenvolvimento que tem como base evitar defeitos pelo uso de um rigoroso processo de inspeção.
• Processo de desenvolvimento baseado em:
▫ Desenvolvimento incremental; ▫ Especificação formal;
▫ Programação estruturada;
▫ Verificação estática através de rigorosas inspeções; ▫ Testes estatísticos para determinar a confiabilidade
O Processo Cleanroom
Construir programa estruturado Definir incrementos de software Verificar código formalmente Integrar incremento Especificar formalmente o sistema Desenvolver o perfil operacional Projetar testes estatísticos Testar sistema integrado Retrabalho devido a erroCaracterísticas do Processo
Cleanroom
• Especificação formal usando um modelo de
transição de estados.
• Desenvolvimento incremental.
• Programação estruturada – controle limitado
e construções abstratas são utilizados no programa.
• Verificação estática utilizando inspeções
rigorosas.
Especificação Formal e Inspeções
• O modelo baseado em estados é a
especificação e o processo de inspeção checa o programa com relação a esse modelo.
• A abordagem utilizada para o desenvolvimento baseia-se em transformações bem definidas que tentam preservar a correção, a cada
transformação, para uma representação mais detalhada.
• Argumentos matemáticos (não provas) são
usados para aumentar a confiança no processo de inspeção.
Times do Processo Cleanroom
• Time de Especificação. Responsável pelo
desenvolvimento e pela manutenção da especificação do sistema.
• Time de Desenvolvimento. Responsável por
desenvolver e verificar o software. O software não é executado durante esse processo.
• Time de Certificação. Responsável pelo
desenvolvimento de um conjunto de testes estatísticos para exercitar o software após o seu desenvolvimento.
Avaliação do Processo Cleanroom
• Os resultados da utilização do processo
Cleanroom têm sido muito bons e os sistemas possuem bem menos erros.
• Avaliações mostram que o processo não é
mais caro do que outras abordagens.
• Menos erros do que em um processo de
desenvolvimento tradicional.
• Entretanto, o processo não é largamente
utilizado. O uso do processo tem sido restrito a organizações tecnologicamente
