[Música] olá essa aula seis da disciplina de gerência de qualidade de software ea gente vai falar sobre técnica de revisão então que a revisão é a revisão é a forma que a gente faz pra avaliar algum produto artefatos de software genericamente à procura de defeitos isso aí pode ser usado tanto pra garantia da qualidade como também para a verificação e validação se a gente usar para garantia da qualidade que a gente dava que a gente vai ver é o atendimento aos padrões então se o produto a ser avaliado atende os padrões definidos a gente também
pode analisar do ponto de vista da verificação e validação que vai considerar os problemas e omissões frente ao que foi especificado para atividade ou especificado de uma forma geral o produto então a as revisões elas são formas tradicionalmente estáticas de a verificação e validação quando a gente está considerando esse processo é porque é estática porque a gente vai pegar o produto e vai olhar o analisar ele sem executar mas existem algumas formas de revisão que são dinâmicas ou seja você faz uma revisão com a execução do produto um exemplo típico é a questão da inspeção
de usabilidade com seu inspeciona as habilidades e precisa executar o produto para saber se há possibilidade é adequado e o interessante da revisão que ela é aplicável para vários produtos de software não precisa ser só o software pode inspecionar qualquer coisa pode pressionar por exemplo um modelo que você criou durante o desenvolvimento você pode inspecionar também manuais que foram que foram criadas por usuários usarem e você pode a avaliar qualquer outra coisa qualquer artefato que foi produzido durante o processo de desenvolvimento e qualquer idéia da revisão como ela funciona então ela funciona como um filtro
vamos ver como funciona o processo normal de desenvolvimento sem revisão então a idéia é que você vai ter em cada atividade envolvimento você tem alguns defeitos que aparecem então eu vou fazer a definição nos requisitos é natural que eu tenho alguns defeitos que aconteceu ali uma falha de especificação não entendi exatamente o que os stakeholders estão querendo a não encontrei um consenso não conseguiu encontrar um bom consenso mas obviamente não tem nenhum defeito que vem anteriormente tem só defeitos novos que vão aparecer aqui então apareceram por exemplo nesse caso aqui 12 defeitos na próxima atividade
a gente vai pegar esses defeitos que aparecendo na definição análise de requisitos e eles vão ser amplificados por que amplifica um defeito ele vai amplificar porque você vai considerar aquele defeito o o melhor você vai começar a projetar e desenvolver o seu software baseado em um defeito e aquilo vai ser propagado em várias portas do seu software por exemplo no projeto você tem um requisito não dizer que tem um defeito em um requisito não funcional então puxa esse requisito não funcional vai afetar vários pedaços seu software vários módulos do seu software então ele vai sempre
ficar em vários lugares quando for corrigir aquilo você não tem que corrigir um lugar só sem corrigir em vários esta amplificação esse é o grande problema então há por exemplo aqui eu estou considerando o fator de amplificação de 50% então você tem oito defeitos que foram repassados sempre ficar mais quatro defeitos foram passados complicação então eles foram aumentados em 50% e você tem defeitos novos então apareceram aqui 18 defeitos novos e durante as atividades a gente consegue pegar alguns defeitos naturalmente sem fazer uma revisão sem fazer nada então às vezes você só de trabalhar com
documento você já consegue descobrir alguns defeitos então tem aqui uma porcentagem de defeitos corrigidos que estou considerando 30 por cento no projeto na próxima atividade bom verificar esses defeitos são 16 defeitos não foram foram repassados mais amplificados oito foram repassados e amplificados de novo pegando pegando a 50% e tem novos efeitos implementação pareceu ac montes trinta e dois defeitos então no final você vai de novo descobrir algumas alguns desses defeitos antes de passar para a próxima atividade mas ainda assim vai aparecer um monte de feito o teste bom teste aí sim vai pegar bastante defeito
espera-se que não gera efeitos na atividade de teste mas você vai ter então os 42 defeitos que foram sendo passados aqui pelo pelo processo de desenvolvimento depois a gente tem aqui aqui eu estou considerando 50% de correção dos defeitos estão usando estudo no final o que a gente vai ter é 21 defeito em produção então claro tem alguns defeitos que a gente identificou na atividade de teste eles vão para a produção naturalmente então esse é um desenvolvimento processo de desenvolvimento normal que não tem revisão que acontece na revisão basicamente na revisão a gente vai aumentar
a porcentagem dos efeitos corrigidas não perceba que aumentou o número agora eu estou considerando um valor maior 50% então antes de passar para a próxima atividade a gente já analisa os artefatos produtos de software encontra alguns defeitos então para a próxima atividade vai ter menos defeito que foi propagado no projeto se a gente fizer a revisão também aumenta a taxa de defeitos que a gente conseguiu corrigir antes sem revisão por exemplo se tinha 30% agora tem 60 e por aí vai da implementação também a gente consegue aumentar e no teste em teorias e pode aguentar
também a quantidade de defeitos encontrados e pode revisar os seus testes por exemplo então a gente poderia até ter uma taxa maior aqui do que 50% estou revisando meus testes eu consigo fazer testes melhores então consigo pegar mais defeitos ainda assim no final claro vai sobrar defeito mas a idéia aqui a gente vai ter menos defeitos do que sem revisão então a idéia da revisão é a gente encontrar defeito antes e claro há bom essa é a grande vantagem a gente vai encontrar o efeito antes e vai diminuir o retrabalho a gente não vai precisar
corrigir esses defeitos posteriormente identificou antes de fazer alguma coisa com então até um gráfico aqui clássico do autor que propôs a idéia de inspeção que foi feita em 1986 em um artigo o clássico dele que ele fala como funciona o processo de desenvolvimento com considerando a inspeção que é uma forma de revisão que a gente vai ver daqui a pouco a no começo tem um custo um pouco maior então você vai demorar um pouco mais nas atividades iniciais porque vai ter que fazer uma revisão vai ter que fazer uma atividade a mais então tem um
custo pra isso mas isso vai se pagar mais para frente a idéia da revisão é que no final você consegue chegar a entregar o seu produto de software antes aqui ele está considerando uma expressão que é uma forma de revisão mas a idéia vale para qualquer outra forma de revisão estão no começo é um custo maior mas compensa isso no final outras vantagens da revisão uma unidade interessante é que na revisão se conseguem encontrar vários defeitos de uma vez por exemplo revisão um artefato que visam um código então vamos revisar o código você consegue encontrar
vários defeitos naquele código não é que nenhum é um compilador que ele só é às vezes ele só encontra o primeiro defeito primeiro erro de compilação acabou não aqui numa revisão se pode continuar a ter um defeito ok o próximo defeito ou proposta uma parte do código encontrou outros defeitos a e teste um problema de teste que às vezes um defeito máscara outro então tem um efeito compensatório às vezes então um teste que estava com um problema um algo que tinha um problema compensou um outro problema com quando a gente vai revisão esse tipo de
coisa não acontece há outra vantagem interessante da revisão é que ela vale para artefatos que estão incompletos então você não precisa ter o seu código 100% funcionando você pode ter um pedaço dele e ele já pode ser revisado a inspeção tem a expressão na revisão vale para isso daí também a outro outra vantagem da revisão é que ela pode avaliar algum pouco mais subjetivo então as características de qualidade que às vezes são difíceis de serem medidas a gente consegue medir através da revisão porque envolve uma pessoa uma outra vantagem é o treinamento você pode ajudar
você pode treinar sua equipe fazendo revisão de algum código revisão de algum modelo pega alguém que não é tão experiente pede para revisar um determinado modelo ele ao revisar ele está aprendendo sobre o software está aprendendo a algumas questões sobre o a produção daquilo que alguns números sobre revisão tão a inspeção de código é uma forma de revisão que vai revisar o código em si a detectar 60% e defeitos e teste de unidade detectar sua 30% do que é o número de uma conta então a princípio se consegue pegar muito defeito na revisão mas a
revisão não é um substituto proteste é um teste pega outros tipos de defeito então se tiver um problema de temporização então só puxa isso aqui esse defeito só acontece quando eu chamo isto aqui chamo esse método é com um pouco tempo antes desse outro método esse tipo de coisa senão vai conseguir encontrar a revisão é muito difícil de encontrar na revisão estão questões de temporização questões de integração de componentes quando você tem vários componentes e precisa juntar esses componentes é difícil pegar na revisão porque acaba se tornando um complexo demais pra alguém olhar o teste
é mais fácil de ver outra desvantagem é o custo então você tem uma atividade a mais de desenvolvimento então tem um curso para isso não é de graça essa atividade mas a idéia é que isso vai compensar com o tempo ainda assim você tem um custo pra fazer a revisão e tem um curso também para treinar a sua equipe para fazer revisão pode não ser tão simples assim a depender do tipo de revisão se de um treinamento um pouco mais específica pessoal que tem um tem uma cultura adequada para fazer algum tipo de revisão há
uma outra desvantagem é uma dificuldade a gente vê se a revisão trazendo vantagem ou não é se você não sabe qual o quanto você tem de problema antes fica difícil de saber se como pensou se melhorou não só como era antes então você tem um histórico nem sempre as empresas têm por isso é difícil medir as grandes vantagens da da revisão e um outro problema outra dificuldade da revisão é que e é um processo público para encontrar defeitos então em geral a gente faz uma reunião de revisão várias pessoas estão avaliando um artefato um determinado
produto de software e muitas vezes a pessoa que fez aquele produto naturalmente tenta se defender achando que estão falando mal de mim mas na verdade não é essa a verdade é que a gente está tentando avaliar o produto a gente está tentando encontrar defeito no produto então a forma como a gente faz a revisão tem que ser de uma forma que não não seja uma inquisição falar com pessoa você está fazendo isso errado não ou artefatos está com defeito a gente encontrou um defeito então não deve ser alguma coisa pessoal tem que ser algo mais
geral tem que ser uma coisa sobre o produto em si ea gente tem vários tipos de revisão existe uma forma só a gente tem revisões informais que são revisões que não tem uma agenda muito bem definida simplesmente revisa o produto anunciado de preparação não precisa de um planejamento muito bem feito é simplesmente às vezes a revisão é simplesmente é você conversar com alguém no corredor por exemplo há outros exemplos de revisões informais a programação em duplas acaba sendo uma revisão informal então você tem duas pessoas programando a segunda que não tá com o teclado ela
está pensando em algumas coisas e também está revendo o código da de quem está escrevendo naturalmente tá tá acontecendo uma revisão tem também as reuniões diárias semanais ou de final de interação que também fazem uma revisão do que do que foi feito e claro essas revisões também podem se informar mais sobre as revisões formais a existem alguns tipos de revisão formal a gente vai ver esses tipos e elas são realizadas por grupos de pessoas em geral de duas das sete pessoas que estão trabalhando em regiões formais mas por ser formal ela tem já uma um
formato mais bem definido então você tem atividades antes da revisão você tem a revisão em si e têm atividades depois da revisão que a gente faz antes da revisão tem que fazer um planejamento muitas vezes então você precisa alguém precisa ler o artefato rever o artefato marcar uma data preparar o ambiente para fazer revisão e aí sim você consegue ter a reunião de revisão e depois que acabou a revisão terminou reunião não é que acabou o processo de revisão você pode acompanhar o que aconteceu então terminou a revisão você pode acompanhar pra mim pra ver
se os defeitos foram corrigidos que foram identificados oprah talvez realizar uma próxima reunião uma outra revisão dependendo da quantidade de efeitos da gravidade deles são os tipos de revisão formal que são definidos por uma norma da lei 3 é é são esses aqui você tem revisão gerencial revisão técnica em expressão ok show e auditoria a gente vai focar aqui em revisão técnica e inspeção e outro acabam sendo tipo de revisão técnica a inspeção é uma rã é uma revisão bem específica um algo que às vezes o pessoal fala é erroneamente no desenvolvimento de software que
a vou fazer uma inspeção como se fosse sinônimo de revisão não é bem assim a inspeção é um tipo muito específico de revisão formal e esse tipo de inspeção é esse tipo de revisão foi proposto por fegan lá em 1986 a gente vê um que em 86 ele tem outros trabalhos mas em 76 ele propôs essa ideia fazendo vários experimentos de como ele conseguiu encontrar defeitos como seria mais fácil encontrar defeitos através de uma revisão então a proposta dele foi um tipo de revisão que tem alguns detalhes algumas características que a princípio encontraria mais defeitos
e originalmente feita fez a análise para código ele pensou em core fazem inspeção de código mas a idéia da expressão pode ser usada para outros artefatos e considerando outras desculpas também os acessos o código quais são as características principais da inspeção a primeira coisa tem um check list ou seja você tem alguma você tem uma lista de quais são os defeitos que um mais comuns que você deve considerar que você deve analisar então essa idéia da checklist vamos pegar a checklist ver como base para encontrar os defeitos tradicionais há uma outra característica que você tem
uma classificação dos defeitos você considerar o efeito em conta o efeito e classifica ele de alguma forma e isso daí serve depois pra gente tem um histórico uma outra característica importante é a preparação tão a as revisões formais tem vários níveis de formalismo na preparação no caso da inspeção é exigido que as pessoas façam a lição de casa então elas precisam pegar os artefatos estão sendo inspecionados e tem que ler esses artefatos com atenção seguindo a check list considerando a checklist pra na reunião de inspeção ci algo mais objetivo e um outro detalhe uma outra
característica interessante da inspeção é que durante a reunião de revisão a leitura do artefato não é feita pelo promotor tem uma pessoa específica que vai ler isso o autor daquele artefato está sendo inspecionado faz parte também da reunião mas não é ele que lê então essa é uma característica diferente na inspeção o outro é um outro tipo de revisão técnica tão qualquer idéia do óbito a idéia do outro é você executar passo a passo o produto de software então geral a gente faz o outro dian de um código então vamos executar o passo a passo
desse código ea gente vai inspecionar vai inspecionar não vai revisar esse produto ao em cada um desses momentos em cada um desses espaços então é uma é um tipo de revisão diferente e interessante do outro aquele é bastante usado pra a gente usa bastante com a gente vai depurar algum código quando você faz coletivamente a isso chama o outro um e outro nome para o outro é taxa de mesa então tem muita gente faz um teste de mesa pega no papel e vai anotando o que está sendo executado quando é feito por várias pessoas é
uma revisão formal e qual é o uso disso é procedente ficar na manhã a anomalia no código a 1 algo interessante que não tem a expressão é que você pode também sugerir soluções inspeção não só não se sugere solução é só para identificar o efeito do oxi pode até sugerir soluções você pode avaliar as habilidades do produto também e você pode melhorar o produto por que não então você pode enquanto está executando o passo a passo para descobrir que tem um algoritmo ali que a complexidade dele está muito boa e dá pra ser melhorado um
outro uso próprio ou é treinar é que você pode treinar a equipe falando é assim que funciona esse algoritmo como conclusão a a gente viu que revisam é uma outra forma de a gente fazer é da gente encontrar defeitos em produtos de software então não precisa ser só teste a forma da gente encontrar defeito revisão uma ótima forma para se encontrar defeito e claro não dá pra fazer só revisão assim como a gente não deveria só fazer o teste o ideal é misturar teste e revisão para encontrar mais defeito e evitar que esses defeitos cheguem
até os usuários ea gente viu que existem várias formas de fazer revisão existem algumas formas mais formais outras informações e você tem que usar oa a forma de revisão mais adequada para o que você está fazendo é isso nos vemos a próxima aula [Música] o [Música] [Música] [Música]
