O documento aborda os processos de verificação e validação no desenvolvimento de software, destacando suas definições e importância para garantir que o software atenda aos requisitos do cliente e especificações. Trata também de técnicas como inspeções de software, análise estática e testes de software, ressaltando a necessidade de planejamento cuidadoso para maximizar a eficácia desses processos. Além disso, discute o desenvolvimento em 'sala limpa', enfatizando a prevenção de defeitos durante o processo de software.

1. Engenharia do Software IManuel Menezes de SequeiraDCTI, ISCTE-IULManuel.Sequeira@iscte.pt, D6.02As apresentações desta série baseiam-se nas apresentações disponibilizadas por IanSommerville, tendo sido alteradas e adaptadas primeiro por Anders Lyhne Christensen e finalmente por Manuel Menezes de Sequeira.

2. Na aula anteriorDesenho de interfaces com o utilizadorProblemas de desenhoHeurísticas de Nielsen para interfaces com o utilizadorEstilos de interacçãoProcesso de desenho de interfaces com o utilizadorAnálise dos utilizadoresPrototipagem de interfaces com o utilizadorAvaliação de interfaces2009/20102Engenharia do Software I

3. Verificação e validação2009/20103Engenharia do Software I

4. SumárioVerificação e validaçãoPlaneamento da verificação e validaçãoInspecções de softwareAnálise estática automáticaDesenvolvimento de software em sala limpa2009/20104Engenharia do Software I

5. ObjectivosApresentar verificação e validação de software e sua distinçãoDescrever processo de inspecção de software e seu papel na verificação e validaçãoExplicar análise estática como técnica de verificaçãoDescrever processo de desenvolvimento de software em sala limpa2009/20105Engenharia do Software I

6. Verificação vs. validação2009/2010Engenharia do Software I6

7. Processo de verificação e validaçãoProcesso de ciclo de vida completo: aplicado em cada etapa do processo de softwarePrincipais objectivosDescobrir defeitos no sistemaAferir se o sistema é útil e usável em operação2009/2010Engenharia do Software I7

8. Objectivos da verificação e validaçãoCriar confiança de que software é adequado ao seu propósitoNão significa que seja completamente livre de defeitosTem de ser suficientemente bom para a utilização pretendidaTipo de utilização determina grau de confiança necessário2009/2010Engenharia do Software I8

9. ConfiançaDepende de Propósito do sistemaExpectativas do utilizadorAmbiente de marketing2009/2010Engenharia do Software I9

10. Confiança2009/2010Engenharia do Software I10

11. Verificações estática e dinâmica2009/2010Engenharia do Software I11Verificação estáticaVerificação dinâmica

12. Verificação e validação estáticas e dinâmicas2009/201012Engenharia do Software IInspecções de softwareEspecificação de requisitosDesenho de alto nívelEspecificação formalDesenho pormenorizadoProgramaProtótipoTeste de software

13. Teste de softwarePode revelar errosNão demonstra ausência de errosÚnica técnica de validação para requisitos não funcionais: software tem de ser executado para observar como se comportaUsado em conjunto com verificação estática para cobrir completamente verificação e validação2009/2010Engenharia do Software I13

14. Tipos de testesTestes de defeitosDescobrem defeitos do sistemaTeste com sucesso revela presença de defeitoTestes de validaçãoMostram que software cumpre requisitosTeste com sucesso mostrar que requisito foi devidamente implementado2009/2010Engenharia do Software I14Capítulo 23

15. Teste e depuraçãoSão processos distintosVerificação e validação estabelecem existência de defeitos em programaDepuração localiza e corrige errosDepurar envolve formular hipóteses sobre comportamento do programa e testá-las para encontrar erro no sistema2009/2010Engenharia do Software I15

16. Processo de depuração2009/201016Engenharia do Software IResultados do testeEspecificaçãoCasos de testeLocalizar erroDesenhar correcção do erroCorrigir erroTestar programa de novo

17. Planeamento da verificação e validaçãoPlanear cuidadosamente para obter máximo resultado de processos de teste e inspecçãoPlanear logo no início do processo de desenvolvimentoIdentificar equilíbrio entre verificação estática e testeDefiner normas para processo de testeNão descrever testes de produto2009/2010Engenharia do Software I17

18. Modelo em V2009/201018Engenharia do Software IEspecificação de requisitosServiçoTestes de aceitaçãoEspecificação de sistemaDesenho de sistemaTestes de integração de sistemaPlano de testes de integração de subsistemasPlano de testes de integração de sistemasPlano de testes de aceitaçãoDesenho de pormenorTestes de integração de subsistemasCodificação e teste de módulos e unidades

19. Estrutura de um plano de teste de softwareProcesso de testeRastreabilidade de requisitosItens testadosCalendário de testesProcedimento de registo de testesRequisitos de hardware e softwareRestrições2009/2010Engenharia do Software I19

20. Plano de teste de software2009/2010Engenharia do Software I20

21. Inspecções de softwareExame de representações fonte para descobrir anomalias e defeitosNão requerem execução do sistema: podem ocorrer antes da implementaçãoAplicadas a qualquer representação do sistemaRequisitosDesenhoDados de configuraçãoDados de testeEtc.Eficazes a descobrir erros em programas2009/2010Engenharia do Software I21

22. Sucesso da inspecçãoMuitos diferentes defeitos podem ser descobertos numa única inspecçãoComo um defeito pode esconder outro, necessárias várias execuçõesComo conhecimento do domínio e de programação é reutilizado, revisores podem já ter visto tipos de erro mais comuns2009/2010Engenharia do Software I22

23. Inspecções e testesTécnicas de verificação complementaresAmbas usadas durante processo de verificação e validaçãoInspecçõesPodem verificar cumprimento de especificação Não podem verificar cumprimento dos requisitos reais do clienteNão podem verificar características não funcionais como desempenho ou usabilidade2009/2010Engenharia do Software I23

24. Inspecções de programaAbordagem formalizada a revisões documentaisDestinadas explicitamente a detectar defeitos (e não a corrigi-los)DefeitosErros lógicosAnomalias no código que podem indicar uma condição errónea (e.g., variável não inicializada)Violação de normas2009/2010Engenharia do Software I24

25. Pré-condições da inspecçãoDisponibilidade de especificação precisaMembros da equipa familiarizados com normas organizacionaisDisponibilidade de código ou outras representações do sistema sintacticamente correctas2009/2010Engenharia do Software I25

26. Pré-condições da inspecçãoLista de verificação de erros preparadaGestão mentalizada para aumento inicial dos custos devido à inspecçãoGestão mentalizada para não usar inspecções para avaliação de pessoal (i.e., para não procurar os responsáveis pelos erros)2009/2010Engenharia do Software I26

27. Processo de inspecção2009/201027Engenharia do Software IPlaneamentoVisão globalPreparação individualReunião de inspecçãoRetrabalhoSeguimento

28. Procedimento de inspecçãoApresentar visão geral do sistema à equipa de inspecçãoDistribuir com tempo código e documentos associadosInspeccionar anotando erros descobertosCorrigir erros descobertosReinspeccionar se necessário2009/2010Engenharia do Software I28

29. Papéis na inspecção2009/2010Engenharia do Software I29

30. Listas de verificação da inspecçãoDevem usar-se para guiar inspecçãoDependem da linguagem de programação e reflectem seus erros típicosVerificação de tipos “fraca” implica lista maiorExemplosInicializaçãoNomes de variáveis e constantesTerminação de ciclosLimites de matrizes2009/2010Engenharia do Software I30

31. Verificações da inspecçãoErros nos dadosVariáveis inicializadas antes de usadas?Sem números mágicos (constantes sem nome)?Índice máximo de matrizes é comprimento ou comprimento - 1?Deve atribuir-se explicitamente delimitador a cadeias de caracteres?Pode ocorrer transbordamento de memória? Erros de entrada e saídaVariáveis de entrada todas usadas?Variáveis de saída com valor atribuído antes da saída?Entradas inesperadas podem causar corrupção?2009/2010Engenharia do Software I31

32. Verificações da inspecçãoErros no controloGuardas de instruções condicionais correctas?Terminação de ciclos assegurada?Instruções compostas correctamente envolvidas?Cobertura de instruções de selecção de casos correcta?Se necessária, foi incluída quebra depois de cada caso?Erros de interfaceInvocações com número correcto de argumentos?Tipos de argumentos e parâmetros correspondem?Argumentos estão na ordem correcta?Se componentes acedem a memória partilhada, têm o mesmo modelo da sua estrutura?2009/2010Engenharia do Software I32

33. Verificações da inspecçãoErros de gestão de armazenamentoQuando estrutura com ligações modificada, ligações correctamente atribuídas?Memória dinâmica correctamente reservada?Memória libertada quando deixa de ser necessária?Erros de gestão de excepçõesLida-se com todas possíveis condições de erro?2009/2010Engenharia do Software I33

34. Taxa de inspecçãoRitmoVisão global: 500 instruções/horaPreparação individual: 125 instruções/horaInspecção: 90-125 instruções/horaCustoProcesso de inspecção é caroInspecção de 500 linhas exige esforço de 40 humanos hora – cerca de £2800 no Reino Unido (≈ 3260 €)2009/2010Engenharia do Software I34

35. Análise estática automáticaLevada a cabo por analisadores estáticosAnalisadores estáticosFerramentas de softwareAnalisam o código fonteTentam descobrir potenciais condições de erroReportam à equipa de verificação e validaçãoEficazes como auxílio às inspecçõesSuplementam inspecção, não a substituem2009/2010Engenharia do Software I35

36. Verificações da análise estática2009/2010Engenharia do Software I36

37. Etapas da análise estática2009/2010Engenharia do Software I37Usar com cuidado! Geram grande quantidade de informação.Usar com cuidado! Geram grande quantidade de informação.

38. lint1 // test.c 2 #include <stdio.h> 3 4 printarray (Anarray) 5 int Anarray; 6 { 7 printf("%d", Anarray); 8 } 9 10 main()11 {12 int Anarray[5]; int i; char c;13 printarray(Anarray, i, c);14 printarray(Anarray) ;15 }> cc test.c> lint test.ctest.c(13): warning: c may be used before settest.c(13): warning: i may be used before setprintarray: variable # of args. test.c(4) :: test.c(13)printarray, arg. 1 used inconsistently test.c(4) :: test.c(13)printarray, arg. 1 used inconsistently test.c(4) :: test.c(14)printf returns value which is always ignored2009/2010Engenharia do Software I38

39. Utilização da análise estáticaParticularmente útil para linguagens fracamente tipificadas (e.g., C) em que compilador não detecta muitos errosRelação custo-benefício menos boa para linguagens fortemente tipificadas (e.g., Java) em que compilador detecta muitos erros2009/2010Engenharia do Software I39

40. Verificação e métodos formaisPode usar-se métodos formais quando houver especificação matemática do sistemaTécnica de verificação estática por excelênciaEnvolvem análise matemática pormenorizada da especificaçãoPodem produzir demonstração formal da conformidade de programa com especificação2009/2010Engenharia do Software I40

41. Argumentos a favor de métodos formaisProduzir especificação matemática requer análise pormenorizada dos requisitos, o que pode revelar errosPodem detectar erros de implementação antes de testes quando programa analisado em conjunto com especificação2009/2010Engenharia do Software I41

42. Argumentos contra métodos formaisRequerem notações especializadas não compreendidas por peritos do domínioMuito caro desenvolver especificação e mais caro ainda mostrar que um programa cumpre especificaçãoPode ser possível atingir mesmo nível de confiança em programa de forma mais económica usando outras técnicas de verificação e validação2009/2010Engenharia do Software I42

43. Desenvolvimento de software em sala limpaNome derivado do processo de “sala limpa” usado no fabrico de semicondutoresPrevenção e não remoção de defeitosProcesso de desenvolvimento baseado emDesenvolvimento incrementalEspecificação formalVerificação estática usa argumentos de correcçãoTestes estatísticos mostram fiabilidade do programa2009/2010Engenharia do Software I43

44. Processo de sala limpa2009/201044Engenharia do Software IEspecificar sistema formalmenteDesenhar testes estatísticosTestar sistema integradoDefinir incrementos do softwareConstruir programa estruturadoDesenvolver perfil operacionalretrabalhoVerificar formalmente códigoIntegrar incremento

45. Características do processo de sala limpaEspecificação formal com modelo de transição de estadosDesenvolvimento incremental com cliente prioritizando incrementosProgramação estruturada – Construções de controlo e abstracção limitadas usadas no programaVerificação estática usando inspecções rigorosasTestes estatísticos do sistema2009/2010Engenharia do Software I45Capítulo 24

46. Especificação formal e inspecçõesModelo baseado em estados é especificação do sistemaProcesso de inspecção verifica programa relativamente a modeloAbordagem à programação torna clara correspondência entre modelo e sistemaArgumentos matemáticos (e não demonstrações) usados para aumentar confiança no processo de inspecção2009/2010Engenharia do Software I46

47. Equipas do processo de sala limpa2009/2010Engenharia do Software I47

48. Avaliação do processo de sala limpaResultados muito impressionantesPoucas falhas nos sistemas entreguesAvaliações independentes mostram que não é mais caro que outras abordagensMenos erros que em processos “tradicionais”Pouco usado: pouco claro como transferir processo para ambiente com engenheiros menos hábeis ou motivados2009/2010Engenharia do Software I48

49. A reterVerificação e validação diferentesVerificação: conformidade com especificaçãoValidação: cumprimento de requisitos do clienteProcesso de testes guiado por planoTécnicas de verificação estática envolvem exame e análise do programa para detectar erros2009/2010Engenharia do Software I49

50. A reterInspecções muito eficazes na descoberta de errosCódigo sistematicamente verificado por pequena equipa para localizar erros de softwareFerramentas de análise estática descobrem anomalias que indiciam erros no códigoProcesso de desenvolvimento de sala limpaDesenvolvimento incrementalVerificação estáticaTestes estatísticos2009/2010Engenharia do Software I50

51. A lerIanSommerville, Software Engineering, 8.ª edição, Addison-Wesley, 2006Capítulo 222009/2010Engenharia do Software I51