Introdução a Verificação e Validação de Software

Olá sejam bem-vindos ao canal engenharia de software com ênfase um ml eu sou o professor gilian Gets e eu já atuo na área de modelagem de software há vários anos eu tenho quatro livros publicados sobre o assunto e eu já ministrei diversas palestras e cursos técnicos sobre modelagem de software utilizando a linguagem uml na aula de hoje eu vou abordar a área de verificação e validação de software que é uma área essencial para garantir a qualidade de um software Então vamos iniciar esse conteúdo então nessa Essa vai ser a primeira aula sobre verificação e validação

então eu vou introduzir alguns conceitos básicos sobre essa área então vamos comear com uma definição básica O que é verificação e o que é validação verificação ela tenta responder a pergunta estamos construindo o produto de maneira correta então a verificação ela tenta determinar se o software está de acordo com o que foi solicitado e especificado tenta determinar se está se construindo o software de acordo com o que foi planejado já a validação ela é bastante mais complexa porque ela tenta responder à pergunta se estamos construindo o produto correto ela tenta determinar se o software que

está sob desenvolvimento realmente irá atender às necessidades da das partes interessadas partes interessadas Como já foi falado em outras aulas eh são todas as pessoas que serão afetadas pelo software de alguma maneira então a validação é muito mais complexa muita muito mais profunda e muitas vezes Ela implica numa espécie de consultoria porque eh muitas vezes as partes interessadas elas não sabem se expressar corretamente em termos de conseguir eh passar para a equipe de desenvolvimento o que elas desejam que o software faça o que elas precisam que o software faça na verdade muitas vezes elas não

conseguem conceber muitas das possibilidades que um software poderia trazer para elas Então faz parte da validação às vezes sugerir muitas ã funcionalidades muitos comportamentos sugerir que se modifique a forma como a informação é tratada pela empresa para que a empresa estor mais competitiva então a validação é bastante mais complexa então a verificação ela tenta garantir que o produto que está sendo desenvolvido está de acordo com a especificação de requisitos a especificação de requisitos é um documento ou conjunto de documentos que contém o detalhamento dos requisitos das funcionalidades que o software precisa ser atendido precisa ser

precisa atender a partir da da elicitação e análise dos requisitos então a verificação ela tenta garantir que o produto sob desenvolvimento Está correto consistente completo com relação à especificação de requisitos em cada fase do ciclo de desenvolvimento e também entre essas fases já a validação ela tenta garantir que o produto realmente satisfaz as necessidades dos clientes eh ele vai além da verificação se o produto está de acordo com o que foi especificado implica em uma análise muito mais profunda dos requisitos e das necessidades reais das partes interessadas então muitas vezes ao Se começar a projetar

um software ao se iniciar a a a desenvolver a engenheria de requisitos de um software é necessário surgir muitas mudanças muitas alter as ao que foi solicitado e isso precisa ser feito com bastante tato e experiência Porque dependendo da forma como foi falado as partes interessadas podem não gostar das sugestões então é preciso falar com certo jeito sugerir possibilidades que não haviam sido aventadas sugerir possibilidades e explicar por essas alternativas seri melhor de forma a tornar a empresa mais competitiva ou permitir que o desempenho do software seja melhor ou que ah a forma que os

usuários utilizam o software seja mais agradável ã seja mais fácil seja mais intuitiva que facilitem a vida dos usuários finais bom então a validação ela tenta demonstrar que o software realmente fará o que as partes interessadas esperam e precisam que ele faça apesar de elas talvez não terem conseguido expressar totalmente o que elas esperam e precisam então a validação ela é essencial por as especificações e requisitos às vezes não refletem totalmente ou completamente os desejos e as necessidades reais ou completas das partes interessadas então a validação não não se pode se ater simplesmente é o

que foi solicitado é preciso verificar se o que foi solicitado é realmente o que a empresa precisa é realmente o que as partes interessadas precisa precisam e fazer sugestões [Música] aqui nós vamos dar um exemplo prático de verificação e validação é o primeiro exemplo então aqui nós enfocamos uma situação onde há Um fabricante de rolhas para garrafas de vinho Então dependendo do material que vai ser utilizado na fabricação de uma rolha ele pode influenciar no Gosto do Vinho então nós temos um fabricante que ele fabrica rolhas para garrafas de vinho então o fabricante ele recebe

uma solicitação de rolhas de um determinado material com um determinado diâmetro e com um determinado comprimento o fabricante ele irá produzir as rolhas no momento que ele produzir essas rolhas ele irá testar o material o diâmetro e o comprimento ele vai verificar se o material das rolhas é o que foi solicitado se as rolhas possuem o diâmetro e o comprimento que foi pedido Então nesse momento ele fez uma verificação do que foi produzido então ele Pode garantir o meu produto atende ao que foi solicitado já aliás no entanto verificar não significa que o fabricante tenha

certeza que o produto dele satisfará o cliente Ele apenas tem certeza que o produto dele está de acordo com que foi pedido para garantir que o produto dele satisfaz o cliente ele precisaria pegar algumas rolhas e fechar algumas garrafas do cliente aí sim ele faria uma validação do produto ele poderia ter certeza que as rolhas deles funcionam satisfazem as necessidades do cliente mas ele não Pode garantir que elas estão de acordo com o especificado verificação é uma coisa validação é outra por isso é preciso faz fazer as duas então Aqui nós temos um outro exemplo

Ah nós temos uma situação de um departamento de trânsito que ele autoriza pessoas A dirigirem veículos para poder emitir essa autorização esse departamento ele estabeleceu um padrão de conhecimentos que os motoristas devem possuir um conjunto de habilidades que eles devem possuir e e um conjunto de de atitudes que eles devem ter quando dirigindo no momento que um motorista ele atender a esses requisitos ele será autorizado a dirigir vai receber uma carteira de motorista então quando se aplicam os testes teóricos e práticos a um candidato a motorista nós estamos verificando se o candidato possui o conhecimento

habilidades e atitudes necessários para que ele possa receber uma carteira de motorista agora eu não tenho garantia que quando o c o motorista realmente começar a dirigir na no mundo real nas ruas e estradas se ele realmente vai obedecer ao que lhe foi ensinado somente quando nós observarmos ele dirigindo no mundo real é que nós estaremos validando a sua competência então resumindo verificar é determinar se o produto está de acordo com o que foi foi pedido e planejado já validar é determinar se o produto é realmente adequado para o propósito desejado validar é muito mais

complexo a validação exige um nível de de dificuldade muito mais alto Ah então o objetivo dos processos de verificação e validação é determinar a confiança de que o software está pronto para ser utilizado dentro do nível de exigência ah esperado pelos usuários esperado pelas instituições que controlam esse software então um processo de verificação e validação ele garante que o sistema ele é bom o suficiente para o que ele se destina então de acordo com o summerville o nível de confiança irá depender de vários fatores entre eles do propósito do software das expectativas dos usuários e

do atual ambiente de Marketing com relação ao propósito do software o software precisa ser confiável no nível necessário então em uma situação em que um software ele se trata de um sistema crítico do qual dependem vidas humanas do qual podem causar acidentes graves do qual pode haver uma grande perda de Capital uma grande perda de recursos ou uma grande perda de informações importantes um software que se destine a um controle de aeroporto a um sistema militar a um órgão de segurança do governo então o nível de confiança precisa ser muito alto ISO significa que a

o software precisa ser verificado validado e testado com muita ênfase o mais exaustivamente possível já se se tratar de um protótipo que e está sendo desenvolvido para demonstrar as ideias de Novos Produtos então o nível de confiança naquele momento ainda não é alto certo e também se o software não tem esse nível de criticidade tão alta então o nível de confiança não precisa ser Tão Profundo Então depende do propósito do software para garantir se ele está adequado ou não Qual o nível de verificação e validação que deve ser aplicado a ele Ah um outro item

são as expectativas dos usuários então devido às experiências que os usuários já tiveram com softwares anteriores existem empresas que já eh possuem software Há muitas décadas então usuários mais antigos podem ter tido experiências com vários softwares ao longo de sua carreira então elas podem ter expectativas mais baixas a respeito da qualidade do software de acordo com a sua experiência já esperam que o software apresente algumas falhas no início então quando o novo o novo software instalado os usuários podem tolerar um certo grau de falhas desde que os benefícios que o software traga compensem os custos

da recuperação dessas falhas então espera-se que o software se torne mais confiável nas versões seguintes já com relação ao ambiente marketing o ambiente marketing ele leva em conta vários fatores como os produtos concorrentes o preço que os clientes estão disposta a pagar os prazos para entrega do sistema vamos falar um pouquinho sobre cada um esses itens então ah em um ambiente competitivo ah eventualmente uma empresa ela pode lançar um produto antes que ele tenha sido totalmente verificado validado e testado Ah isso pode ser necessário a empresa pode considerar isso necessário uma vez que existem outras

empresas concorrentes que estão para lançar produtos semelhantes então elas podem lançar um produto não tão bem testado a um preço razoavelmente barato que compensaria o seu baixo nível de confiabilidade os usuários aceitariam esse baixo nível de confiabilidade esperando que novas versões fossem forem lançadas brevemente para contornar esse problema então tem muitas empresas que tem essa atitude agressiva no mercado ã Fala um pouquinho sobre inspeções ou revisões por pares e comparar com testes então inspeções elas são uma técnica estática de examinar o produto sobre desenvolvimento e inspeções diferentes dos Testes elas podem ser utilizadas em todos

os estágios do ciclo de desenvolvimento em todos os seus em todos os artefatos produzidos por ele artefato é qualquer produto é qualquer é qualquer ã resultado qualquer tudo que for desenvolvido ao longo do ciclo de desenvolvimento é considerado artefato então o artefato ele pode ser documento pode ser modelo pode ser diagrama pode ser caso de teste pode ser código entre outras possibilidades Então as inspeções elas podem ser aplicadas em todos os estádios do ciclo de desenvolvimento e serem aplicadas a qualquer artefato produzido por um ciclo de desenvolvimento Ah então como eu falei elas podem analisar

e verificar qualquer artefato que pode ser um documento de especificação de requisitos um modelo de projeto um modelo arquitetural casos de testes resultados desses testes e o próprio código fonte Ah já os testes software eles são dinâmicos eles são aplicados ao código propriamente dito em geral ao código funcionando então eles executam o software com dados de teste e tentam determinar se as saídas os o o comportamento demonstrado pelo software ou parte dele Está correto Então se analisam os resultados obtidos o comportamento das funcionalidades o desempenho ã dessas funcionalidades então testes eles são dinâmicos porque eles

trabalham normalmente com a execução do software enquanto que inspeções são estáticas porque elas analisam o software sem precisar executá-lo isso pode eh ter várias vantagens em relação aos testes porque um erro pode causar diversos outros erros no código enquanto que as inspeções elas identificam erros e anomalias reais um teste ele pode identificar um erro primário e depois diversos erros que são h o resultado desse erro original então não se tem certeza que os vários daqueles erros realmente eh são reais ou se são apenas um ã uma segund um segundo resultado de um um determinado erro

do código agora inspeções e testes elas não são mutuamente exclusivas elas se complementam deve-se usar inspeções e deve-se usar testes na verdade existem vários tipos de inspeções nós vamos falar sobre algumas delas ao longo das nossas aulas então nós concluímos essa primeira parte sobre a área de verifica ção e validação eu espero que vocês tenham gostado dessa aula Se vocês consideraram eh essa aula ã razoável se vocês ao verificarem e validarem esta aula consideraram ela adequada ao propósito a qual ela se destina eu peço que vocês curtam esse vídeo compartilh com quem possa interessar e

se ainda não estão inscritos no canal eu peço que se inscrevam obrigado pela atenção