Buscar

Aula cap.2 Verificação e validação

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 3, do total de 62 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 6, do total de 62 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 9, do total de 62 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Prévia do material em texto

Verificação e Validação de 
Software
Prof. M.e: Ricardo Camparim
2
� Introduzir verificação e validação de software;
� Descrever o processo de inspeção de programa;
� Explicar análise estática;
� Introduzir o processo de desenvolvimento de software 
Cleanroom.
Objetivos
3
Tópicos abordados
� Planejamento de verificação e validação;
� Inspeções de software;
� Análise estática automatizada;
� Verificação e métodos formais
Verificação e validação
4
Qual a diferença entre Verificação e Validação?
Verificação vs validação
“Verificação se preocupa em avaliar se o produto está sendo 
desenvolvido corretamente, enquanto a validação visa assegurar 
que se está desenvolvendo o produto correto, isto é, o produto 
que o cliente deseja” (BOEHM, 1981). 
5
Verificação vs validação
O que deve ser questionado?
� Verificação:
� Confirmar por testes e com provas objetivas que
requisitos especificados foram cumpridos.
� Visa garantir que os produtos de uma dada fase
implementam em sua totalidade as entradas para aquela
fase, ou seja, tenta responder à pergunta:
� “O produto foi construindo corretamente?”
6
Verificação vs validação
� Validação:
� Confirmar por testes e com provas objetivas que
requisitos particulares para um determinado uso foram
cumpridos.
� Busca provar que o software implementa cada um dos
requisitos corretamente e completamente ou seja, tenta
responder à pergunta:
� “O produto correto foi construído?”
7
Verificação vs validação
� Diferenças:
Fonte: www.spider.ufpa.br
8
Verificação vs validação
� Problemas:
Fonte: www.spider.ufpa.br
� Custo por NÃO realizar testes:
� Foi feito tudo? 
� Foi executado corretamente? 
� Produto falho:
� Insatisfação do cliente
� Retrabalho
� Baixa reputação
9
Processo 
� O processo de V&V
� É um processo que engloba todo o ciclo de vida - V & V
deve ser aplicado em cada estágio no processo de
desenvolvimento.
� Tem dois objetivos principais:
� a descoberta de defeitos no sistema;
� Assegurar se o sistema é ou não utilizável em uma
situação operacional. Ex: Máquinas ultrapassadas
10
Propósitos
� Propósitos da Verificação
� O propósito do processo Verificação é confirmar que cada
serviço e/ou produto de trabalho do processo ou do projeto
atende apropriadamente os requisitos especificados.
� O propósito do processo Validação é confirmar que um
produto ou componente do produto atenderá a seu uso
pretendido quando colocado no ambiente para o qual foi
desenvolvido
� Propósitos da Validação
Fonte: www.sotex.br
11
Confiabilidade
� Confiança de V&V
� Depende do propósito do sistema, das expectativas dos
usuários e do ambiente de mercado.
� Função de software: O nível de confiança depende de quão
crítico é o produto para a empresa.
� Expectativas do usuário: Os usuários podem ter baixas
expectativas de certos tipos de software.
� Ambiente de mercado: Colocação de um produto no
mercado pode ser mais importante do que descobrir defeitos
no programa. Ex: Windows 98
12
Confiabilidade – História de erros
de software
� Problemas no Mariner (1962) – Custo aprox.: 80 milhões dólares.
� Desastre: Mariner, um foguete com uma sonda espacial para Vênus, foi
desviado de seu percurso de voo logo após o lançamento.
� Causa: Um programador, ao passar para o computador uma fórmula que
haviam lhe entregado escrita manualmente, se esqueceu de uma barra. Sem
ela, o software tratava variações normais de velocidade como se fossem sérios
problemas, causando falhas por tentativas de correções que acabaram por
enviar o foguete fora do curso.
� 3ª Guerra Mundial “Quase!” (1983).
� Desastre: O sistema de alerta precoce soviético falsamente indicou que os
Estados Unidos tinham lançado cinco mísseis balísticos. Felizmente, o oficial
de serviço soviético argumentou: se os EUA estavam realmente atacando,
eles lançariam mais de cinco mísseis. por isso ele relatou o aparente ataque
como um alarme falso.
� Causa: Um bug no software soviético falhou ao detectar reflexos solares como
falsos mísseis.
Fonte: http://www.edn.com/
� Inspeções de software
� Preocupadas com a análise estática das representações do sistema
para descobrir problemas (verificação estática).
� pode ser complementadas por alguma análise automática do
texto de origem de um sistema ou dos documentos associados.
� Teste de software
� preocupado com a execução e observação do comportamento do
produto (verificação dinâmica).
� O sistema é executado com dados de teste e o seu
comportamento operacional é observado.
13
Verificação estática e dinâmica
� Teste de programa
� Pode revelar a presença de erros e NÃO a ausência;
� Um teste bem sucedido é um teste que descobre um ou mais
erros;
� É a única técnica de validação para requisitos não funcionais
(desempenho, confiabilidade);
� Deve ser usado em conjunto com a verificação estática para
uma cobertura total das atividades de V&V.
14
Teste de programa
15
Tipos de testes
� Os testes de defeito
� Testes projetados para descobrir defeitos no sistema;
� Um teste bem sucedido é aquele que revela a presença de
defeitos em um sistema.
� Testes estatísticos
� Usado para testar o desempenho e a confiabilidade do
Programa;
� Confiabilidade: número de falhas no sistema, etc...
� Desempenho Tempo de execução, tempo de resposta, etc.
16
Teste de depuração
� Testes de depuração e de defeitos são processos distintos;
� Verificação e validação estão relacionados ao estabelecimento
da existência de falhas em um programa;
� Depuração está relacionado à localização e reparação dessas
falhas.
17
Processo de depuração
18
Planejamento de V&V
� Planejamento cuidadoso é necessário para obter sucesso nos
processos de inspeção e teste;
� O planejamento deve iniciar no começo do processo de
desenvolvimento (em cada fase);
� O processo de planejamento deve decidir sobre o equilíbrio
entre as abordagens estáticas e dinâmicas;
� O planejamento de testes se ocupa em estabelecer os
padrões para o processo de testes.
19
Plano de teste
� O plano de teste é um dos documentos produzidos na
condução de um projeto.
� Como ele funciona:
� Um ‘integrador’ entre diversas atividades de testes no
projeto;
� Mecanismo de comunicação para os stakeholders (a
equipe de testes e outros interessados);
� Guia para execução e controle das atividades de testes.
Fonte: http://www.devmedia.com.br
20
� O plano de teste pode ser elaborado pelo gerente de projeto
ou gerente de testes;
� Visa planejar as atividades a serem realizadas;
� Definir os métodos a serem empregados;
� Planejar a capacidade necessária;
� Estabelecer métricas e formas de acompanhamento do 
processo.
Plano de teste
21
Estrutura de um plano de teste
� Processo de teste;
� Rastreabilidade de requisitos;
� Itens testados;
� Cronograma de testes;
� Procedimentos de registro de testes;
� Requisitos de hardware e de software;
� Restrições
22
Estrutura de um plano de teste
� Gráfico de Gantt para estrutura de um plano de teste .
Fonte: http://www.wthreex.com
23
O processo de inspeções
Planejamento
Visão Geral
Preparação 
Individual
Reunião de 
Inspeção
Retrabalho
Acompanhamento
apresentado à equipe de 
inspeção
Cada membro da equipe
estuda a especificação e
procura defeitos no código.
Durante a inspeção, os erros
descobertos são anotados.
Modificações são feitas para
corrigir os erros descobertos.
Uma nova inspeção pode
ser ou não necessária.
24
Pré-condições para inspeções
� Uma especificação precisa deveestar disponível;
� Os membros da equipe devem estar familiarizados com os padrões
organizacionais;
� O código sintaticamente correto ou outras representações do
sistema devem estar disponíveis;
� Um checklist de erros deve ser preparado;
� A gerência deve aceitar que a inspeção aumentará os custos no
início do processo de software;
� A gerência não deve usar inspeções para avaliar pessoal
25
Inspeções de software
� Envolve pessoas examinando uma representação de software
para descobrir anomalias e defeitos;
� Não há a necessidade de execução do sistema, assim pode ser
usada antes da implementação (processo V&V estático);
� Pode ser aplicada a qualquer representação do sistema
(requisitos, projeto, dados de teste, etc.);
� Técnica muito eficaz para a descoberta de erros (testes de
mesa).
26
Sucessos da inspeção
�Muitos defeitos diferentes podem ser descobertos em uma
única inspeção.
� Em teste, um defeito pode mascarar outros, assim várias
execuções são necessárias.
� Conhecimento sobre o domínio e sobre programação
aumentam a eficácia.
� Revisores tem alta probabilidade de já ter visto os tipos de
erros que normalmente surgem.
27
� Inspeções (estática) e testes(dinâmico) são complementares:
� Inspeções => verificação;
� Testes => verificação e validação.
� Ambos devem ser usados durante o processo de V&V;
� As inspeções podem verificar a conformidade com uma
especificação:
� Não verificam a conformidade com os requisitos reais do cliente.
� As inspeções não podem verificar características de
qualidade, tais como desempenho, usabilidade, etc.
Inspeções e testes
28
Inspeções de programa
� Abordagem formalizada para revisões de artefatos;
� Voltadas explicitamente para detecção de falhas (não correção);
� Falhas podem ser erros lógicos (por exemplo, uma variável não
iniciada) ou não conformidade com padrões.
29
Checklist para inspeção de programa
� Um checklist de erros comuns deve ser usado para direcionar a
inspeção;
� Checklists de erros são dependentes de linguagem de programação.
� Refletem os erros característicos com maior probabilidade de
surgimento na linguagem.
� Exemplos de itens da checklist: inicialização de variáveis, terminação
de laços, etc.
� Inspeções também podem “executar” o sistema, através da análise
passo-a-passo de seu código.
Classe de defeitos Checagem de inspeção
Defeitos nos dados
Todas as variáveis do programa são iniciadas antes de seu uso?
Todas as constantes foram denominadas
Existe alguma possibilidade de overflow de buffer
Defeitos de controle
Para cada declaração condicional, a condição está correta?
Cada laço está certo para terminar?
Se um identificador break é requerido após cada caso em declarações 
‘case’, esse identificador foi incluído?
Defeitos de entrada/saída
Todas as variáveis de entrada são utilizadas?
Entradas inesperadas podem fazer com que os dados sejam 
corrompidos?
Defeitos de interface
Todas as chamadas de funções ou métodos tem o número correto de 
parâmetros?
Os tipos formais e reais de parâmetros combinam?
Os parâmetros estão na ordem certa?
Defeitos de Gerenciamento 
de armazenamento
Se o armazenamento dinâmico é utilizado, foi alocado espaço 
correto?
O espaço é explicitamente liberado, depois que não é mais 
necessário?
Defeitos de gerenciamento 
de exceções
Todas as possíveis condições de erros foram levadas em conta?
30
Verificações de inspeções
31
Benefícios da inspeção
Detecção de defeitos antecipada
� As inspeções melhoram a qualidade desde o início do projeto 
detectando mais defeitos desde a fase de requisitos. 
32
Os defeitos inseridos em uma fase 
não são identificados na própria 
fase, e se estendem por várias outras 
fases do desenvolvimento.
A maior parte dos defeitos inseridos na 
fase de requisitos são identificados na 
mesma fase, ou logo em seguida; o 
mesmo acontece para as outras fases. 
Sem inspeção Com inspeção
Adaptado Prof. Márcio Eduardo Delamaro – ICMC/USP 
Benefícios da inspeção
33
Benefícios da inspeção
� As inspeções melhoram a produtividade uma vez que os
defeitos são encontrados quando são mais fáceis e mais
baratos para corrigir.
Adaptado Prof. Márcio Eduardo Delamaro – ICMC/USP 
34
Técnicas de inspeção de Software
� A Inspeção faz o uso da revisão com base na leitura e
compreensão dos artefatos de software;
� As técnicas de leitura podem auxiliar na melhoria do
entendimento dos artefatos;
� Segundo Braga e Coelho (2012), algumas das principais
técnicas de leitura são:
� Ad-hoc:
� A detecção de defeitos depende exclusivamente da habilidade,
do conhecimento e da experiência do inspetor.
� Checklist (LBCh):
� Baseia-se em uma série de questões (tipo sim/não) sobre
assuntos do artefato a ser inspecionado.
� Cenário (LBCe):
� Seguindo um cenário, o inspetor adquire um conhecimento
mais aprofundado do sistema, possibilitando que ele ache
defeitos mais sutis;
35
Técnicas de inspeção de Software
36
Técnicas de da inspeção de Software
� Stepwise Abstraction (SA):
� Esta técnica fornece instruções de leitura mais estruturadas e
precisas e é ideal para inspecionar documentos de código;
� Perspectiva (LBPe):
� O produto de software deve ser inspecionado a partir das
perspectivas dos diferentes stakeholders. Ela pode ser dividida
em três partes: introdução, instruções e perguntas
� N-fold:
� Método de leitura que consiste na replicação do processo de
realização de inspeções formais usando diversas equipes, que
fazem o trabalho em paralelo (único moderador).
37
Análise estática
� Técnicas de Análise Estática
� São técnicas de verificação de sistema que não envolvem
a execução de um programa;
� Trabalham em uma representação fonte do software
(modelo ou o código) do programa em si;
� Podem ser usadas para identificar erros antes que uma
versão executável do sistema esteja disponível;
� Inspeções e avaliações em pares são uma forma de análise
estática;
38
� Técnicas de Análise Estática para sistemas críticos:
� Verificação formal;
� Verificação de modelos;
� Análise estática automática.
Análise estática
39
Verificação e método formais 
� Os métodos formais utilizam modelo formal de sistema que
serve como uma especificação;
� Esses métodos formais são relacionados, principalmente, a
uma análise matemática da especificação;
� No processo de V & V, os métodos formais podem ser usados
em diferentes estágios:
40
Verificação e método formais 
� Estágio 1:
� A especificação é desenvolvida e matematicamente
analisada por inconsistências. É eficaz em descobrir erros
de especificação e omissões;
� Estágio 2:
� Utilização de argumentos matemáticos para verificar, se o
código de um sistema de software é consistente com sua
especificação. É eficaz em descobrir erros de programação
e design.
41
Argumentos a favor dos métodos formais 
� A produção de uma especificação matemática requer uma
análise detalhada dos requisitos, por isso, a descoberta de
erros é mais provável;
� Podem detectar erros de implementação antes do teste
quando o programa é analisado em paralelo com a
especificação
� Requerem notações especializadas que não podem ser
compreendidas por especialistas de domínio;
� Desenvolver uma especificação é muito dispendioso, mas é
mais dispendioso mostrar que um programa atende à essa
especificação;
� Pode ser possível atingir o mesmo nível de confiança em um
programa mais barato usando outras técnicas de V &V.
42
Argumentos contra os métodos formais 
� Abordagem alternativa à análise formal;
� Baseada em uma noção maisrestrita de correção;
� Usada na verificação de projetos de sistemas de hardware e
em sistemas críticos de software. Ex:
� Software de controle de veículos de exploração de Marte
de NASA;
� Software processador de chamadas telefônicas.
43
Verificação de modelos
� Estágios verificação de modelo:
� Envolve a criação de um modelo de um sistema e a
verificação da correção desse modelo, geralmente como
uma máquina de estado finito estendida;
� Um conjunto de propriedades desejáveis de sistema é
identificado e escrito em uma notação formal;
44
Verificação de modelos
� O verificador de modelos explora todos os caminhos pelo
modelo (isto é, todas as possíveis transições de estado) e
verifica se uma propriedade especificada pelo usuário é
válido para cada caminho;
45
Verificação de modelos
Requisitos, 
projeto ou 
programa 
Construção 
de modelo 
Especificação 
de 
propriedade 
Modelo de estado 
finito estendido do 
sistema 
Propriedades do 
sistema desejadas 
Verificador 
de modelo 
Confirmação 
ou não
� Computacionalmente, a verificação de modelos é muito cara:
� Usa uma abordagem exaustiva para verificar todos os
caminhos do modelo de sistema;
� Tamanho do sistema aumenta, também aumenta o
número de estados, e, consequentemente, o número de
caminhos a ser verificado;
� Para sistemas grandes, a verificação de modelos pode ser
pouco útil, devido ao tempo de computador requerido
para executar as verificações.
46
Verificação de modelos
� As ferramentas de análise estática trabalham no código fonte
de um sistema;
� A análise estática automatizada é mais fácil de ser introduzida
em um processo de desenvolvimento do que a verificação
formal ou a verificação de modelos:
� Programadores não precisam aprender notações especializadas para
escrever as especificações de programa.
47
Análise estática automatizada
� Os analisadores estáticos automatizados são as ferramentas
de software que fazem a varredura no código fonte de um
programa e detectam possíveis defeitos e anomalias;
� A intenção é desenhar um código para as anomalias no
programa, como: variáveis usadas sem iniciação, sem uso, ou
ainda, dados, cujos valores poderiam sair dos limites.
48
Análise estática automatizada
49
Classe de defeitos Checagem da análise estática
Defeitos em dados
Variáveis utilizadas antes da inicialização
Variáveis declaradas, mas nunca utilizadas
Variáveis atribuídas duas vezes, mas nunca utilizadas
entre as atribuições
Possíveis violações de limites de vetor
Variáveis não declaradas
Defeitos de controle
Código inacessível
Ramos incondicionais centro de loops 
Defeitos de entrada/saída
Saída de variáveis duas vezes sem atribuição 
intermediária .
Defeitos de interface
Desacordo quanto ao tipo de parâmetro
Desacordo quanto ao número de parâmetros
Não utilização dos resultados de funções
Funções e procedimentos não chamados
Defeitos de gerenciamento
De armazenamento
Ponteiros não atribuídos 
Ponteiro aritmético
Perdas de memória
Checagem da análise estática
50
Estágios da análise estática
� Análise de fluxo de controle:
� Verifica laços com múltiplos pontos de saídas ou de entrada,
encontra código inacessível, etc.
� Análise de uso de dados:
� Detecta variáveis não iniciadas, variáveis que são declaradas mas
nunca usadas, etc.
� Análise de interface:
� Verifica a consistência das declarações de rotina e procedimentos e
seus usos.
51
Estágios da análise estática
� Análise de caminho:
� Identifica caminhos através do programa e estabelece as declarações
executadas naquele caminho;
� Pode também verificar se certo predicados são verdadeiros;
� Destaca as informações para inspeção ou revisão de código.
� Outros tipos de análises:
� Ex: Análise de fluxo de informações: Identifica as dependências das
variáveis ou I/O.
� Limitações: escalabilidade, completude, precisão, excesso de
informações
52
� Particularmente valiosa quando uma linguagem como C é
usada, já que trata-se de uma linguagem com checagem de tipo
fraca e, por isso, muitos erros não são detectados pelo
compilador.
�Menos efetiva para linguagens como Java, que possuem uma
checagem de tipos forte e, portanto, podem detectar muitos
erros durante a compilação
�O analisador estático pode descobrir áreas de vulnerabilidade,
tais como buffer, overflows ou insumos não fiscalizados;
Uso da análise estática
53
�É rotineiramente usada no desenvolvimento de segurança em
muitos sistemas críticos de segurança: Ex:
� Microsoft introduziu a análise estática no desenvolvimento de
drivers de dispositivos;
� Como parte do processo de V & V, muitos sistemas críticos,
incluindo os de aviação e os sistemas nucleares, são analisados
estaticamente.
Uso da análise estática
54
Desenvolvimento de software Cleanroon
� Nome derivado processo ‘Cleanroom’ na fabricação de
semicondutores;
� A filosofia é a prevenção ao invés de remoção de defeitos;
� Esse processo de desenvolvimento de software é baseado
em:
� Desenvolvimento incremental;
� Especificação formal;
� Programação estruturada;
� Verificação estática usando argumentos de correção;
� Testes estatísticos para determinar a confiabilidade de programa.
55
O processo Cleanroom
Especificar
formalmente
o sistema
Desenvolver
perfil
operacional
Definir
incrementos
do software
Construir
programa
estruturado
Verificar
código
formalmente
Integrar
incremento
Projetar
testes
estatísticos
Testar
sistema
integrado
56
Características do processo Cleanroon
� Especificação formal usando um modelo de transição de
estados;
� Desenvolvimento incremental onde o cliente prioriza os
incrementos (o software é particionado em incremento
desenvolvidos e validados separadamente);
� Programação estruturada – controle limitado e construções
abstratas são usadas no programa;
� Verificação estática usando rigorosas inspeções de software;
� Testes estatísticos do sistemas, cada incremento de software é
testado estatisticamente para determinar a confiabilidade.
57
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 tem como
base transformações bem definidas, que tentam preservar a
exatidão em cada transformação, para uma representação
mais detalhada;
� Argumentos matemáticos são usados para aumentar a
confiança no processo de inspeção.
58
Equipes no processo Cleanroom
� Equipe de especificação: Responsável pelo desenvolvimento
e pela manutenção da especificação do sistema;
� Equipe de desenvolvimento: Responsável por desenvolver e
verificar o software. O software não é executado durante esse
processo;
� Equipe de certificação: Responsável pelo desenvolvimento de
um conjunto de testes estatísticos para exercitar o software
após o seu desenvolvimento (certificação da confiabilidade do
software).
59
Avaliação de processo Cleanroon
�Resultados na IBM tem mostrado que os softwares possuem
bem menos erros;
� Avaliação mostra que o processo não é mais caro do que
outras abordagens;
� Menos erros do que em um processo de desenvolvimento
tradicional;
� Uso do processo tem sido restrito a organizações
tecnologicamente avançadas.
60
Resumo
� Verificação certifica a conformidade com a especificação;
� Validação certifica que o programa faz o que o usuário
precisa;
� Planos de teste descrevem os itens a serem testados;
� Inspeção de programas é o processo de analisar o código
fonte, sem executá-lo.� O código do programa é sistematicamente checado por uma
pequena equipe, para localizar defeitos.
61
Resumo
� Ferramentas de análise estática pode revelar anomalias no
programa (possíveis defeitos);
� Processo de desenvolvimento Cleanroom é uma abordagem
de desenvolvimento de software que se apoia em
desenvolvimento incremental, verificação estática e teste
estatístico.
62
� DEVMEDIA. Revista Engenharia de Software. Disponível em: http://www.devmedia.com.br/revista-engenharia-de-software-
magazine.
� SOFTEX. Qualidade – MPS.BR. Disponível em http://www.softex.br/mpsbr.
� SOMMERVILLE, I. Engenharia de software. 8. ed. São Paulo: Pearson, 2008. 552pp.
� PRESSMAN, Roger S. Engenharia de software. São Paulo, SP: Makron Books do Brasil, 2007. 1056p.
� Projeto Spider. Disponível em: http://www.ufpa.br/srbo/Disciplinas/CBCC_CBSI_Mestrado_Qualidade/2012.2/VERVAL.pdf.
� Prof. Márcio Eduardo Delamaro – ICMC/USP . Disponível em: moodle.stoa.usp.br/mod/resource/view.php?id=32906.
� Fábio Procópio. Engenharia de Software. Disponível em: https://sites.google.com/site/fabiooprocopio/engenharia-de-software.
� Caso de Desenvolvimento para Projetos Pequenos: Elaboração. Gráfico de Gantt. Disponível em:
http://www.wthreex.com/rup/examples/devcase_sp/sip_iie.htm.
� Jessica MacNeil.Mariner 1 destroyed due to code error, July 22, 1962. Disponível em: http://www.edn.com.
Referências

Outros materiais