Revisões Técnicasricardo.aramos/disciplinas/ESI2009_2/Aula06.p… · codificação e teste Revisão de módulos Aprovar a finalização da implementação e teste das unidades;

26/8/2009 Revisão de Software 1

Edmundo Sérgio Spoto

Revisões Técnicas

Edmundo S. Spoto



Histórico

• A atividade de revisãocomeçou como uma ferramenta de controle gerencial– Revisão de progresso

• O progressonão pode ser avaliado simplesmente contando-se o número de tarefas finalizadas

• Era preciso estabelecer um meio de avaliartambém a qualidadedo trabalho executado



Revisões Técnicas

• Surgiram então as revisõesque avaliam aspectos técnicosdo produto

• Qualquer produto pode ser submetido a uma revisão técnica

• A técnicapode ser aplicada desde as primeiras fasesdo ciclo de vida

• Formais ou informais



Planejamento

• Cabe ao engenheiro de softwareplanejar– o que deve ser revisado

– quais os resultados esperados

– quem deve fazer a revisão

• Determinar “checkpoints” dentro do ciclo de vida onde a revisão deve ser aplicada

• Determinar resultados esperados



Checkpoints

Revisão Resultado esperado

Requisitos de sistema Entendimento do que o sistema deve fazer

Requisitos do software Aprovar a especificação de requisitos e iniciar projeto preliminar

Plano de teste Aprovar a estratégia de teste

Projeto preliminar Estabelecer uma linha base para o projeto;

determinar uma abordagem básica para o projeto e teste do software

Projeto detalhado Aprovar projeto detalhado; autorizar o início da codificação e teste

Revisão de módulos Aprovar a finalização da implementação e teste das unidades; liberar para demais fases de teste

Teste de validação (sistema) Determinar o final dos testes de validação (sistema)

Aceitação Aceitar o produto; aprovar implementação operacional



Exercício

• Defina Checkpointsde revisão para sua proposta de um Ambiente de trabalho seguindo as partes:– Planejamento do projeto

– Laboratório ou escritório de desenvolvimento.

– Controle de Materiais de Uso

– Viabilidades de execução (técnica e financeira)



Planejamento ...

• quem participa?

• qual informação é requerida antes da revisão?

• pré-condições que devem ser satisfeitas antes que a revisão possa ser conduzida?

• Como Organizar?



Planejamento...

• Gerar checklistsou outra indicação do que deve ser cobertona revisão;

• Determinar as condições de término ou critérios que devem ser satisfeitos para que a revisão termine;

• Gerar registros e documentosque devem ser produzidos.



Resultados obtidos

• revisõessão o principal mecanismo para avaliar o progresso do desenvolvimento de maneira confiável;

• revisões trazem à luz as capacidades de cada indivíduo envolvido no desenvolvimento;

• revisõessão capazes de revelar lotesou classesde erros de uma só vez;



Resultados obtidos

• revisões proporcionam retorno já nas primeiras fases, prevenindo que erros mais sérios surjam;

• revisõestreinam e educamos participantes e têm significante efeito positivo na competência dos desenvolvedores.



Custo da remoção de erros

• Atividades de projeto são responsáveis por 50a 65% dos erros

• Revisão pode revelar até75% desses erros• Revelar erros cedo diminui o custo de validação e

correção– Fase de projeto: custo 1– Fase anterior ao teste: custo 6.5– Fase de teste: custo 15– Fase de manutenção: custo 60 a 100



Amplificação de defeitos

• cada caixa representa um passo

• erros podem ser criados, passados a frente, amplificados ou ainda revelados

Erros passados a diante

Erros amplificados 1:x

Erros novos gerados

Percentagem de erros

detectados

Defeitos Detecção

Erros vindosdo passo anterior

Erros para o próximo passo



Amplificação sem revisões

00

10

0% 64 x 1.5

25

0% 1027 x 3

25

20%

0

0

50%

0

0

50%

0

0

50%

12

94

10

37

94

47

24

projeto preliminar

Projeto detalhado

Codigo/test unidade

Teste integr.

Teste validação

Teste sistema



0

0

10

70% 2

1 x 1.5

25

50% 5

10 x 3

25

60%

0

0

50%

0

0

50%

0

0

50%

3

24

3

15

24

12

6

projeto preliminar

Projeto detalhado

Codigo/test unidade

Teste integr.

Teste validação

Teste sistema

AmplificaAmplificaçção com revisõesão com revisões



Custo final

Fase Erros revelados

Custo unitário

Total

Com revisões Projeto 22 1.5 33

Antes do teste 36 6.5 234

Durante teste 15 15 315

Após liberação 3 67 201

783

Sem revisões Antes do teste 22 6.5 143

Durante teste 82 15 1230

Após liberação 12 67 804

2177



Regras (Walkthrough)

• Tipicamente 3 a 5 pessoas

• autor, líder de revisões e 2 ou 3 revisores

• Preparação antecipada– 1 a 2 horas

• Duração de no máximo 2 horas– Uma parte pequena do software deve ser

selecionada para revisão



Walkthrough

• Um dos revisoresfica como secretárioda revisão

• Inicia-se com uma discussão sobre a pauta e uma breve introdução sobre o produto

• Autor descreveo produto– “caminha” sobre ele

• Revisorescolocam suas dúvidas, baseados no estudo prévio do produto



Walkthrough

• Erros identificados devem ser anotados– lista de problemas

• Revisores preenchem também um relatório sumário de revisão– o que foi revisado

– quem fez a revisão

– conclusão



Lista de problemas - EX

Número da revisão: 0013 Data: 14-08-97 Líder da revisão: Plínio Vilela Secretário: Márcio Delamaro Lista de problemas: Introduções aos módulos YMOTION e ZMOTION não estão consistentes com os padrões de projeto. O propósito do módulo deveria estar explicitamente declarado (referência não é aceita) e uma especificação de itens de dados deveria ser declarada. Contador de laço para interpolação em X, Y e Z é incrementado uma vez a mais para controle de passo do motor. Equipe de revisão recomenda uma verificação na especificação do controle de passo e se necessário a correção do contador. Equipe de revisão recomenda a alteração do algoritmo “comparador de posição” para melhorar a performance. As alterações necessárias estão anotadas em PDL. O autor tem restrições quanto à modificação e deverá analisar potenciais impactos antes de efetuar a alteração.



Sumário de revisão

R e la tó r io S u m á r io d e r e v is ã o té c n ic a I d e n t i f i c a ç ã o d a r e v is ã o P r o je to : C o n t r o la d o r d e te m p o r e a l N C N ú m e r o d a r e v is ã o : 0 0 1 3 D a ta : 14 -0 8 9 7 L o c a l : S a la 1 0 9 8 H o r á r io : 1 0 :0 0 I d e n t i f i c a ç ã o d o p r o d u to M a te r ia l r e v is a d o : P r o je to d e ta lh a d o - m ó d u lo s p a r a c o n t r o le d e m o v im e n to A u to r : G e r a ld o S e te M e io B r e v e d e s c r iç ã o : 3 m ó d u lo s p a r a c o n t r o le d e m o v im e n to n o s e ix o s X Y e Z M a te r ia l r e v is a d o 1 . D e s c r iç õ e s d o s m ó d u lo s X M O T IO N , Y M O T IO N e Z M O T IO N 2 . P D L p a r a o s m ó d u lo s R e v is o r e s : N O M E A s s in a tu r a 1 - P l ín io V i le la ( l íd e r ) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ 2 - M á r c io D e la m a r o (s e c r e tá r io ) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ 3 - D o r o té ia B a n z o _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 4 - B o b D u m o n t _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ A v a l ia ç ã o d o p r o d u to A c e i to c o m o e s tá ( ) c / p e q u e n a m o d i f ic a ç õ e s (X ) N ã o a c e i t o r e v is ã o ( ) r e v is ã o s e c u n d á r io ( ) R e v is ã o n ã o fo i c o m p le ta d a (e x p l ic a r m o t iv o s ) M a te r ia l s u p le m e n ta r a n e x a d o: L is ta d e p r o b le m a s (X ) M a te r ia is d e p r o d u ç ã o (X )



Guidelines ou“ Uma má revisão pode ser pior que nenhuma revisão”

• Determine uma agenda(e mantenha-a)

• Limite os debates

• Levante as áreas problemáticas– não tente resolver todos os problemas

• Tomenotas

• Revise o produto, nãoo produtor



Guidelines

• Limite o número de participantes e insista na preparação;

• Prepare um checklist, de acordo com o produto a ser revisado;

• Reserve recursos do projetopara revisões;• Promova treinamento para os revisores;

• Revise suas antigas revisões.



Checklists

• Quase qualquer produto pode ser revisado.

• Dependendo do produto, os revisores devem focalizar sua atenção em determinados pontos.

• Para cada checkpointdeve ser gerada uma lista de pontos importantes, um checklist!



Especificação de requisitos...

� A análise do domínio da informação está completa, consistente e correta?

� O particionamento do problema está completo?

� As interfaces internas e externas estão definidas corretamente?

� Os modelos de dados refletem os objetos, seus atributos e relacionamentos corretamente?

� Todos os requisitos podem ser mapeados para o nível de sistema?



Especificação de requisitos

� Prototipagem foi conduzida com o usuário?

� Os requisitos de performance podem ser alcançados, dadas as restrições impostas por outros elementos do sistema?

� Os requisitos são consistentes com cronograma, recursos e orçamento?

� Os critérios de validação estão completamente especificados?



Projeto preliminar...

�Os requisitos do software estão refletidos na arquitetura?

�Modularidade foi alcançada de maneira eficaz? Os módulos são funcionalmente independentes?

�Foram definidas as interfaces dos módulos e dos elementos externos do sistema?



Projeto preliminar

�As estruturas de dados são consistentes com o domínio da informação?

�As estruturas de dados são consistentes com os requisitos do software?

�O item manutenibilidade foi considerado?

�Outros fatores de qualidade foram explicitamente considerados?



Projeto detalhado

�O algoritmo realiza a função desejada?

�O algoritmo está logicamente correto?

�A interface está consistente com o projeto da arquitetura?

�A complexidade lógica é razoável?

�Manipulação de defeitos e abordagens anti-defeito foram especificadas?



Projeto detalhado

� Estruturas de dados locais estão propriamente definidas?

� As construções de programação estrutura são utilizadas em todos módulos?

� Os detalhes de implementação são adaptáveis para linguagens de programação?

� Lógica composta ou negativa é utilizada?

� O item manutenibilidade foi considerado?



Código ...

�A tradução do projeto procedimental para código foi feita de maneira correta?

�Existem erros de digitação?

�As convenções de utilização da linguagem foram seguidas?

�O código está de acordo com padrões de estilo, comentários e introdução do módulo?



Código

�Existem comentários incorretos ou ambíguos?

�Tipos e declarações de dados estão corretos?

�Constantes físicas estão corretas?

�Todos os itens do walkthrough de projeto re-examinados? (quando necessário)



Plano de teste ...

�As principais fases de teste estão bem identificadas e seqüenciadas?

�Foram estabelecidos critérios e requisitos de validação nos requisitos do software?

�O plano de teste é consistente com o plano de desenvolvimento geral?

�O cronograma de teste foi explicitamente determinado?



Plano de teste

�Os recursos e ferramentas de teste estão disponíveis?

�Foi estabelecido um mecanismo para manter os registros do teste?

�Drivers e stubs foram identificados? Foi estabelecido tempo no cronograma para seu desenvolvimento?

�Teste de estresse foi especificado?



Procedimentos de teste ...

�Foram especificadas diversas técnicas de teste?

�Critérios para avaliação de casos de teste foram utilizados?

�Casos de teste foram identificados e guardados?



Procedimento de teste

�Tratamento de erros foram testados?

�Valores limites foram testados?

�Performance e sincronismo devem ser testados?

�Foi especificada uma variação aceitável para os resultados esperados?



Exercício

• Elabore um planejamento de revisão para um dos checkpointsestabelecidos no exercício anterior.– Quem participa?

– Qual informação é requerida antes da revisão?

– Pré-condições que devem ser satisfeitas antes que a revisão possa ser conduzida;

– Checklist ou outra indicação do que deve ser coberto na revisão.

– Condições de término ou critérios que devem ser satisfeitos para que a revisão termine;

– Registros e documentos que devem ser produzidos.



Exercício

• Considere que o produto a ser revisado sendo a documentação de Projeto de EscritórioEspecificação de Requisitose Descrições funcionais:– Defina um planejamento para a revisão.

– Elabore um checklist para esse tipo de material.

– Forme um grupo de 4 pessoas e faça a revisão do Material.



Ex: Checklist

• Erros de sintaxe• Erros de concordância• Uso de terminologia padrão• Seqüência de descrição fora de ordem• A descrição das Funcionalidades não são explicativas• As dependências (pré e pós condições) em cada funcionalidade

não estão claras.• Pouca clareza nas descrições do fluxo de informação das

Funcionalidades.• Apresenta pouca Figura ilustrativa.• A escrita atende um entendimento técnico e de fácil interpretação?



Ex:: Checklist

• Os termos utilizados são pertinentes ao tipo de aplicação?

• O texto é fluente e didático? (Especificação)

• As não funcionalidades foram citadas?

• As características técnicas possuem uma tabela de sinônimos?

• A qualidade de impressão é boa?



Como implementar

• Muitas vezes encontram-se resistênciasà implementação de técnicas “novas”



Treinamento

• Investimento inicial para treinar os revisores– treinar algumas poucas pessoas que vão se

encarregar de treinar os outros

• Duplas de lideres



Cronograma

• A fatia do cronograma que deve ser alocada– 2 a 10% (dependendo do ambiente)

• Inicialmente, deve-se fazer uma projeção pessimista pois não se dispõem de dados anteriores

• Inicialmente o “tamanho” do produto revisado tende a ser pequeno



Outras dicas

• Inicie a revisão com partes não críticas do software– revisores necessitam de tempo para aprender a

revisar

• Tente revisar, por exemplo, o seu guia para conduzir revisões– isso pode aprimorar a aplicação na sua

organização



Problemas e Pontos a Ponderar

• Um programa pode estar correto e ainda assim não exibir boa qualidade? Explique.

• Foi lhe dada a responsabilidade de melhorar a qualidade de software em sua empresa. Qual é a primeira coisa que você deve fazer? E depois?

• Como você reconheceria um bom candidato a participar da revisão? E o não preparado? Quais as providências, se você fosse o lider?



Duvidas?

• Perguntas?

Documents

Revisões Técnicasricardo.aramos/disciplinas/ESI2009_2/Aula06.p… · codificação e teste Revisão de módulos Aprovar a finalização da implementação e teste das unidades;