e fala pessoal Professor crime Vilela aqui hoje vamos falar sobre revisões técnicas formais mais um assunto dentro do Toca de engenharia de software tá fica ligada Então eu tenho uma interessante Então vamos lá pessoal revisões técnicas formais nenhum assunto interessante a fica dentro aí do corpo de validação e verificação de soft a gente tem que descobrir os defeitos do software antes de entregar para o cliente e as técnicas de revisão é a técnica divisão serve para isso é também conhecida como o teste estático Então como a atividade de teste na verdade pressupõe que você vai
executar o software e a revisão pode ser feita sem você necessariamente tem que executar o código portanto é conhecida também como teste estático Tá bom vamos lá uma olhadinha aqui e Olha que bonitinho é o Olá faltam revisão técnica da fala um pouco também subwoofer ou revisão técnica é uma técnica de garantia de qualidade onde um subproduto do processo de desenvolvimento e revisado e comentado por um time de desenvolvedores com o objetivo de identificar problemas conflitos e omissões o cça é uma é utilizado para comunicar aspectos mais amplos sobre o projeto para uma equipe de
desenvolvimento na e outros interessados o cliente autogerenciado tá então a gente focar na verdade mais sobre revisão técnica formal cão a revisão é uma expressão de um objeto objetivo de avaliá-lo já existe essa essa história de fazer revisão técnica já é antiga não é recente tá surgiu Se não me engano os primeiros a primeira empresa que aplicou isso de forma generalizada assim foi h e na bastante tempo atrás e e ela vindo um conceito de tentar avaliar o progresso do desenvolvimento de alguma coisa no caso de software a gente simplesmente dizer que um determinado número
de tarefas foi concluído não é o suficiente para saber o progresso do desenvolvimento porque as atividades que foram feitas anteriormente Pode não ter sido feito com a qualidade necessária e os produtos nos artefatos gerados não ter em qualidade necessária e o projeto ter que voltar atrás e refazer aquelas coisas aí então uma das aplicações para revisão técnica é revisão de progresso na avaliar quanto do projeto realmente caminho o atual projeto o progresso não pode ser avaliado simplesmente contando-se o número de tarefas finalizados por causa disso eu precisava de um jeito de saber a qualidade das
tarefas realizadas com as revisões técnicas surgiram Então como uma forma de fazer revisão de aspectos técnicos do produto qualquer produto pode ser submetido a uma revisão técnica isso que é O interessante é a parte de teste eu só consegui efetivamente executar quando o código tá pronto não podemos executar revisão não previsão eu posso fazer a qualquer momento desde que eu tenho algum tipo de subproduto ali algum tipo de artefato produzido eu consigo aplicar revisão sobre aquele artefato é essa técnica pode ser aplicada desde as primeiras fases do ciclo de vida na hora do ciclo de
desenvolvimento de sofre isso é muito interessante muito útil para as empresas existe aí um Ranger de formalidade para as revisões técnicas na elas podem e informais ou mais formais tá então aí vai variar vai depender do ambiente de trabalho onde você se encontra o que que se encaixa melhor tá a revisão revisões informais pode ser feita por Paris pode ser feita na entrega de alguns subprodutos e revisões formais e precisam aí de um de um mecanismo um pouco mais organizado não vou sair do grupo de pessoas treinadas para fazer esse tipo de visão e o
processo todo será implantado de forma sistemática na empresa e tem custo também né a principal motivação que eu vejo assim para se aplicar revisão é o que ele fala aqui ó quando aplicar né você fazer algum tipo de validação ao final do processo de desenvolvimento de alguma coisa e só lá é muito perigoso né então tem um exemplo aqui ó é do teu norcranes presidente da velcro questão assim nosso processo ele não aceitava nós estávamos inspecionando a qualidade do produto e não manufaturando a qualidade no produto no seja estão fazendo a expressão a revisão apenas
no final do processo isso não tava dando bons resultados Então tem um exemplo interessante aí um vamos supor que você tenha uma fábrica de tijolos em uma olaria e atender bem o seu cliente você garante que para caminhão de tijolo vendido no máximo dez porcento dos tijolos que estão naquele caminhão teria um motivo de problema seria com a qualidade necessária aí está no contrato você garante isso só que você não tem nenhum mecanismo de qualidade de garantia de qualidade dentro do seu processo de fabricação do tijolo você só nasci só tem que garantir que não
vai tijolo com defeito para o cliente então o que você faz você bom e lá em cima do caminhão toda vez que sobra um tijolo o cara dá uma olhada nesse tijolo se ele tiver bom vai para o caminhão se não tiver bom ele joga fora que jogo tá para garantir que não vai perder o contrato não vai deixar de receber por aqui de caminhão A então o que vai acontecer você vai desperdiçar muito tijolo então tijolo cara te juro que é jogado fora porque ele não tinha a qualidade necessária foi Barro a argila sei
lá a consumida foi armazenamento consumido foi Toda energia para prensar a energia para assar que esse tijolo armazenamento do tijolo pronto a mão de obra para carregar de lá para cá até chegar no caminhão e o cara jogar fora então todo esse todo esse custo foi desperdiçado tudo bem eu garanto que o meu cliente não vai receber tijolo com problema mas eu tô jogando dinheiro fora eu para evitar esse tipo de problema o que eu deveria fazer a analisar todo o processo identificar os pontos no meu processo onde eu poderia fazer algum tipo de revisão
com tipo de inspeção de qualidade então eu percebo que pôr o barro chega e armazenado algum lugar antes de se balançar ir para prensa lá para ser moldado tijolo eu verifico se tá com boa qualidade aquele Barros não tem folha assim tá caindo coisa dentro dele tá se tem eu já resolvo esse problema já descartou a matéria prima que tá ruim já resolvo ali então e visto de seguir todo o processo e investir todo esse dinheiro para no fim tem um produto de má qualidade que tem que ser descartado aí eu posso fazer isso em
vários pontos esse processo inclusive ele tem um nome para isso não nesse processo de revisão técnica gente vai ver daqui a pouco que são os cheque pões os pontos de verificação cada checkpoint tem uma lista de verificação que eu vou percorrer para ver se tá tudo ok naquele. a semente um resumo do processo de revisão que a gente vai ver hoje mas isso é interessante aí quando aplicar né então aplicação no fim uma abordagem que desperdiça recursos nem abraço dinheiro não é bom então melhor aplicar revisão técnica em várias etapas do ciclo de movimento logo
Vinícius por tanta ó Então a gente tem aqui o nosso como engenheiro de software tem que planejar esse processo todo né então o que vai ser revisado os resultados esperados ficar a revisão Quem deve fazer a revisão e determinar checkpoints dentro do ciclo de vida ou de visão deve ser aplicado Então esse chá que pode são exatamente esses pontos onde vai ter vai ser executado o processo de divisão é um aqui tem alguns exemplos de checkpoints dentro de um ciclo de vida comum ruim né Então logo que eu faço levantamento de requisitos a quando eu
faço o plano de teste e quando eu tenho projeto preliminar 673 de acordo com o processo de desenvolvimento que você tiver utilizando Mas é interessante identificar Onde colocar esse checkpoints parte do planejamento aí é determinado Também quem participa dessas reuniões que tipo de informação necessária Antes de acontecer uma revisão assim preciso atender alguma pré-condição a antes de poder fazer a revisão e sério também é importante é um check list check list é basicamente aquela listinha de verificação que eu vou perguntas que eu vou fazer sobre o artefato que está sendo revisado A então basicamente aqui
acha que ele se é que nem aquele que aquele se de avião né que um piloto co-piloto faz copiloto certo né então Verifica o qual FV controle lista tão no software vai ser a mesma coisa cada checkpoint que onde eu vou ter um processo de divisão ali acontecendo atividade de divisão acontecendo para cada um desses pontos em 1841 ser revisados E aí Eu determino previamente um check list uma lista de perguntas que você fez e claro os resultados obtidos desse processo são a melhor forma que eu tenho aí de melhorar o meu produto isso vai
realimentar o processo e vou identificar problemas eu vou identificar omissões defeitos Para poder melhorar o produto dele sempre interessante do processo de revisão é que ele proporciona um benefício Logo no início do processo de desenvolvimento da quanto antes resolver um problema mais barato ele vai custar para mim se eu deixar para resolver o problema no fim quando eu entregar para o cliente por exemplo ele vai custar muito mais caro então quanto antes eliminar um problema mais barato ele vai ficar aqui fala um pouquinho de um processo aí de ampliação de defesa que um estudo feito
pela IBM com isso aqui é só para só para justificar aí a importância do processo de revisão e aqui tá falando seguinte se eu removo defeito somente nas fases de teste eu saio com certo número de problemas lá no final então aquele que eu vou percorrendo as fases desenvolvimento EA que considera um ciclo de vida clássico Cascatas eu vou ampliando os defeitos que são gerados estão cada fase de ar um tanto de defeitos e amplifica para fase seguinte e nas suas detesto eu removi não sem processo de revisão tá dizendo aqui que eu chego lá
com 12 defeitos Afinal tá por exemplo dado aqui e com processo de divisão como eu removo defeitos antes é porque eu tenho processo de revisão não é só nos testes que removido eu aplico o mesmo número de defeitos gerados novos a cada fase e amplificados para fazer só que agora eu removo problemas antes porque eu tenho revisão é um shampoo número muito menor de perfeito final é então que são comparativo aí eu estudar E aí BM para fazer isso um tempão algumas regrinhas aí para se fazer as reuniões divisão técnica né só fique reuniões então
não tem muita gente envolvida três a cinco pessoas por reunião é importante o autor daquele artefato que você tá sendo realizado esteja presente existam Líder no processo de revisão para conduzir a revisão e aí dois ou três revisores presentes é que vão realmente leu material desse pagamento e participar dessa discussão exige então uma antecipação a preparação antecipada e demoroso a minha reunião e se deve durar no máximo duas horas e eu acho muito Cruzeiro Mas é isso aí então uma parte pequena deve ser revisado a cada reunião Ou como que é dinâmica das Reunião um
dos revisores fica como secretário da revisão para Anotar os problemas encontrados tá inicia-se com uma discussão sobre a pauta e uma breve introdução sobre o produto que vai ser avisado e o autor descreve o produto seja ele caminha sobre o produto então a minha experiência prática com isso aqui muitas vezes quando o autor vai explicar o que ele fez ele mesmo percebe problema aí então muitas vezes nem precisa do próprio revisora para identificar problemas próprio autor já percebe mas se o autor não percebemos revisores vão colocando dúvidas e questionamentos sobre aquilo que está sendo revisar
não precisa ser feito somente em cima ele código-fonte por exemplo mas pode posso fazer esse processo em cima de código-fonte um print do código mesmo ou posso fazer isso qualquer outro artefato na lista de requisitos levantados o modelo foi criado então sobre Qualquer coisa pede documentação tem é manual para o usuário qualquer coisa pode passar pelos processos os defeitos identificados devem ser anotados uma lista de problemas e os revisores preenchem um relatório sumário da revisão Então quem foi que foi realizado Quem fez a revisão e conclusões e tão é gerado um relatório final sobre sobre
resposta processo for ao final da revisão todos os participantes devem decidir se aceitam produto rejeitam na com porque tem problema sério aceitam com modificações estão em uma conclusão aí na revisão em relação à aceitação do produto e aí é gerado um uma lista de problemas e um modelinho de relatório esse processo é interessante mas tem que ser bem feito né se não fizer ele bem feito pode dar problema então uma uma mais visão pode ser pior do que não ter revisão nenhum e assim essas reuniões são importantes mas tem custo né Você tem um grupo
de pessoas parado por um certo tempo fazendo esse atividades Então ela deve ser feita de uma maneira organizada Então você tem que ter uma agenda e mantém essa agenda limitar os debates aquele momento não é o momento para bolar soluções para nada é mais um momento para identificar problemas mesmo e revisar o produto e não autor Traz esse tipo de reunião não pode ser algo apontando o dedo para pessoa pode ser feliz você fez aqui esse algo não deu o produto se limitar o número de participantes insistir que eles vêm preparados seu check list daquilo
lá preparado acho que eles estão a listinha de perguntas que vão ser feitas sobre aquele material que está sendo realizado reservar recursos e projetos e recursos até tempo no cronograma para fazer criatividade os revisores são ser treinados precisa ter é realimentação desse processo e é revisar o processo de revisão aprender com ele falando um pouco sobre o check list é um basicamente qualquer produto pode ser realizado tem que ter um check list amesquinha de perguntas que vão ser feitas sobre aquele produto tá então aqui tem alguns exemplos lembro se eu tiver fazendo especificação de requisitos
eu vou até as perguntas lá nada de domínio de informações tá completa consistente correta condicionamento do do problema está completa não só as perguntas que eu vou fazer sobre aquele material que está sendo realizado E aí ela fazia aí do processo momento tem as suas perguntas então isso aqui é importante o projeto detalhado cada uma tem código sobre código toma série de perguntas sobre o plano de teste Então tem um monte aí de perguntinhas essas perguntas eu tirei do capítulo do livro do Prisma que fala sobre esse assunto algumas dicas sobre como implementar isso nem
todo o ambiente não é o grupo de pessoas é muito receptivo à mudanças e tal então se eu tô colocando alguma coisa nova no processo desenvolvimento Pode ser que haja resistência ainda mais colocar um tipo de avaliação aí sobre o seu trabalho tão especial ser comunicado com antecedência e com cuidado que você começar devagar né então começa com duplas de líderes poucos líderes de revisão treinar esses líderes e eles começam fazer algumas revisões inicialmente com o material deles mesmos não faz com produto jeito pelo outro e vice-versa ted's pegar o jeito de como se faz
isso não é colocar uma fatia do cronograma é prevendo esse esforço para fazer revisão é ela iniciar a revisão com partes não críticas ou soft até você pegar o jeito aprender aí tá E é isso então é isso que a ideia de começar devagar o que que vai pegar um jeito e aprendendo como faz aqui então de revisão técnica era isso que eu tinha que passar para vocês as coisas mais importantes são determinar os pontos no processo de desenvolvimento que você usa onde você vai parar para fazer revisão do dos artefatos são sendo produzidos são
checkpoints E aí para cada uma desse cheque pode criar a listinha de perguntas do material que vai ser revisado acção check list se esse check list seus próprios peões podem mudar ao longo do tempo e o check list com certeza vai sendo aprimorada no dia que você vai fazendo mais revisões Tá bom vamos até mais tchau tchau fala pessoal Paulinho Vilela falando aqui bosta hoje o meu cabelo tá maneiro hein Oi Flôr estou ficando velho cara é só ruga