Walkthrough

Diogo
Marcia
Marcio
Renato
 Processos de Revisão
• "um processo de revisão pode ser definido
como uma avaliação crítica de um objeto (...)
assim walkthroughs, inspeções e auditorias
podem ser visualizados como formas de
processos de revisão."

SEI CMM (3-1.5, 1988)

 Processos de Revisão
• O custo para a correção de uma falha no projeto de software aumenta
proporcionalmente quando é detectado em fases posteriores ao processo
de desenvolvimento do software, o que justifica a aplicação de processos
de revisão de software em todas as fases do processo.
Os processos de revisão de software também fornecem subsídios aos
processos de avaliação de qualidade de software:

• aumentar a qualidade de um produto de trabalho;

• identificar e documentar defeitos;
• identificar melhorias necessárias em um produto de trabalho;
• verificar que o produto de trabalho está em conformidade com padrões,
especificações e requerimentos adotados;
• atingir consenso em relação aos produtos de trabalho;
• aumentar o conhecimento dos pares em relação ao produto;
 Fase de Avaliação - Walkthrough
• Diversas avaliações devem ser feitas ao longo do processo de construção de um programa. Esta fase
trata especificamente da certificação de que o produto construído atende às expectativas de qualidade
do cliente e é confiável.

• Para cumprir esta fase, a engenharia de programas dispõe de técnicas como

revisão estruturada (walkthrough), onde o produto é submetido a um "checklist"
para certificação de qualidade; testes caixa preta, através da qual prepara-se
uma massa de dados para testar o programa, baseado apenas na funcionalidade
dos seus módulos; testes caixa branca, na qual os casos teste são elaborados
levando em consideração os algoritmos dos módulos.

• Um walkthrough é uma revisão em grupo de um produto com a finalidade de

encontrar deficiências nesse produto.
 Walktrough
“É uma revisão por pares, em grupo, de
qualquer produto técnico." Essa revisão pode
envolver tanto outros engenheiros de software
quanto também usuários, programadores,
analistas, projetistas, operadores e que
possam estar envolvidos nos vários aspectos
de um software.

Yourdon (2000)
 Walktrough
“Walkthroughs são técnicas práticas, simples e
bem aceitas para a melhoria da qualidade do
software."
O autor define o termo como "walkthrough é
uma revisão por pares, em grupo, de qualquer
produto."

Corliss (2001)
 Walktrough
Níveis de Formalidades de revisões de software:

• Walkthroughs formais - incluem a alta gerência, são superficiais, possuem

feedback lento, as críticas apresentam alta variação de qualidade, é revisto por
supervisores, leva um longo tempo de preparação e é aplicado a produtos, em
estágio, relativamente completos. Tendem a ocorrer no final do processo e
registra as ocorrências.

• Walkthroughs informais - requerem pouca preparação, consistem de pequenas

notas, apresentam feedback rápido, são freqüentemente levados a termo por
pares e os revisores têm a "propriedade" do produto. Tendem a ocorrer no início
do processo e não registra as ocorrências.

• Walkthroughs semiformais - consistem em revisões por pares de determinados

produtos resultantes do processo de desenvolvimento de software, que têm uma
pauta, limite de tempo e um conjunto de regras e procedimentos.
 Papéis em um walkthrough :
1) Apresentador: alguém que conheça o produto,
preferencialmente alguém diferente do
profissional responsável pelo produto a ser
avaliado.
2) Coordenador: responsável pela condução do
processo como um todo.
3) Escriba ou secretário, responsável pelo registro
de todo processo.
4) "Oráculo da manutenção": profissional que deve
trazer à discussão o ponto de vista da
manutenibilidade do produto final.
 Papéis em um walkthrough :
5) "Guardião dos padrões": profissional que deve
assegurar que as normas, padrões e
especificações estão sendo obedecidas.
6) Usuário: Deve-se assegurar que as
necessidades do cliente são consideradas no
processo.
7) Outros: Dependendo do tipo de revisão a ser
feita, papéis podem ser eliminados ou outros
adicionados ao processo.
 Procedimentos antes do walkthrough
• O responsável pelo walkthrough deve escolher o coordenador e os
participantes, agendar e providenciar os materiais necessários com
antecedência, escolher um produto que possa ser revisado em
aproximadamente uma hora.

• Os participantes devem ter um contato prévio com o responsável com

antecedência, ler os documentos disponibilizados e se preparar com
antecedência para o encontro, trazendo ao menos um comentário
negativo e um comentário positivo.
Procedimentos durante o walkthrough
• Coordenador :
→ Abrir e encerrar a sessão.
→ Manter a discussão focada no objetivo do encontro.
→ Manter a ordem

• Apresentador:
→ Apresentar o produto.
→ Certificar-se de que todos os detalhes são fornecidos aos participantes.
→ Ter forte expectativa de conhecer os erros no produto apresentado.
→ Não responder a comentários .

• Revisores:
→ Prover críticas construtivas, comentários e sugestões.
→ Não desperdiçar tempo buscando soluções

• Escriba:
→ Registrar comentários e sugestões.
→ Detalhar uma lista de ações.
→ Atribuir status a todos os itens (exemplo: sugestão, defeito a ser corrigido, em definição)
 Atividades após o walkthrough
• Coordenador:
→ Preparar e distribuir o relatório final do
processo.

• Participantes:
→ Checar todos os itens comentados e validá-
los.
Para avaliar software são necessárias
as seguintes informações:

Características de Qualidade de Interesse

Documentos do Projeto

Informações sobre o Processo

Técnicas de Avaliação
 Walkthrough e Inspeções
OBJETIVOS
 detectar erros em qualquer representação do software
 verificar se o software sob avaliação atinge os requisitos
 assegurar que foram obedecidos normas e padrões
 assegurar que o software é desenvolvido de forma
uniforme
 tornar o produto gerenciável
 treinar a equipe
CARACTERÍSTICAS
 reunião com grupos de 3 a 5 pessoas
 envolve preparação prévia à reunião
 devem durar em torno de 2 horas
 Walkthrough
Recursos

Fim previsto do
projeto

t
Início do Marcos de revisão
projeto

FIGURA REPRESENTATIVA DA TÉCNICA WALKTHROUGH

Diretrizes e técnicas que devem ser adotadas:
→ O sistema é culpado até que se prove o contrário.
Se encontrar falhas no projeto, não tente corrigi-las durante o walkthrough para evitar correções
precipitadas e prejudiciais. Deixe o próprio programador assuma os problemas após o walkthrough.

→ O programador é sempre inocente porque não está em julgamento..

É importante lembrar que o sistema (programas) e não o programador está sendo revisado.

→ Um walkthrough não tem o propósito de avaliação.

O gerente de projeto deve receber um relatório do que foi tratado como: falhas no sistema, plano para
correção e marcação para um posterior walkthrough.

→ Uma relação de prováveis problemas deve ser seguida como orientação.

Através da relação de prováveis problemas e de falhas mais comuns, você não perderá tempo.

→ Deve haver um mínimo de 3 e um máximo de 7 revisores.

Ter 2 revisores é pouco para dar uma visão ampla, necessária no walkthough, enquanto que ter mais de 7
corre-se o risco de tornar a reunião festiva.
 Diretrizes e Técnicas
→ Escolha os participantes do walkthough cuidadosamente.
Deverão estar presentes no walkthrough: membros da equipe de desenvolvimento; alguém experiente que
atue em outra parte do projeto ou mesmo em outro projeto para servir de presidente ou moderador
do walkthough.

→ Mantenha o walkthrough breve.

Limite o walkthrough por mais ou menos 1 hora. Ocasionalmente, num período crítico do projeto, você
precisará de 3 a 4 horas para revisão. Neste caso, divida em períodos com intervalos de 10 minutos cada.

→ Torne-o formal somente quando necessário .

Os walkthrough não precisam ser formais. Ele deve ser planejado com antecedência por dois motivos: é
prático avisar as pessoas com antecedência para a reunião, e o envio de material sobre o que será revisado
com antecedência para os participantes. Assim, o walkthrough poderá ser mais objetivo e com
conseqüente economia de tempo.

→ Torne cada walkthrough efetivo em termos de custo.

Um walkthrough pode ser custoso particularmente em termos de salário, mas se você se prender às
diretrizes acima, ele será um bom investimento. Caso você se afaste das diretrizes acima ou gaste tempo
em discussões que fogem do objetivo, então o walkthrough se tornaria caro e não teria utilidade como
ferramenta para descobrir as fraquezas do projeto num estágio anterior quando elas podem ser corrigidas
sem grandes traumas.
 CKECK-LIST DE WALKTHROUGH
• Há algum módulo com coesão menor que comunicacional?
• Cada interface entre módulos foi implementada claramente?
• Pode cada módulo ser implementado através de suas interfaces?
• Todas as interfaces de um módulo com fan-in têm o mesmo número e tipos de
parâmetros?
• Há algum módulo que apareça underfactoring por algum motivo?
• O sistema é balanceado?
• Foram considerados todos os casos de consistência de dados?
• Como foram tratadas as informações de erros?
• Há módulos restritivos ou com funções sobrepostas?
• Que módulos podem ser substituídos por módulos de biblioteca?
• A interface com o usuário é simples e compreensível?
• Deverão ser feitas modificações na programação em função da linguagem de
programação ou do ambiente operacional?
• As funções de cada módulo estão especificadas?
• As entradas e saídas de cada módulo foram especificadas por tipo, valores limites,
função e composição?
• O projeto preenche a especificação?
• Quais são as modificações mais prováveis que o usuário poderá requisitar?
• Finalmente: o sistema funcionará?
 VANTAGENS DA IMPLEMENTAÇÃO
INCREMENTAL TOP-DOWN
1) Feedback :
Durante a fase de análise, o feedback com os usuários é quase inexistente.

2) O usuário pode usar várias versões dependendo da fase de implementação top-

down.
Com as versões incrementais, as pessoas podem se acostumar, com o sistema e sua crescente capacidade.

3) O projeto tem maiores possibilidades de não ser cortado mesmo estando atrasado.
Um usuário jamais ficará satisfeito diante de um prazo não cumprido. Mas se ele puder ver a versão do
sistema em operação, ele estará mais inclinado a acreditar e confiar na sua capacidade. Se ele puder fazer
algum trabalho com a aversão atual, melhor.

4) As principais interfaces dos sistema são testadas primeiro e com mais freqüência.
Se o sistema tiver sido desenvolvido através do projeto estruturado, então a maioria das interfaces
importantes dos módulos devem estar no topo dos diagramas de estrutura.

5) Distribuição mais uniforme dos recursos em teste

Os recursos usados no teste/depuração incremental não apresenta picos acentuados e representa um uso
de recursos bem mais flexível que na abordagem tradicional de implementação.
6) Os resultados aparecem mais rapidamente, o que leva o moral dos
implementadores.
Tanto os implementadores quanto os usuários sentem-se tremendamente animados quando vêem
alguma coisa funcionando.

7) A taxa de progresso é medida pala quantidade de módulos em funcionamento em

vez da “pesagem” de códigos.
Usando a implementação incremental de cima para baixo, o trabalho de codificação provavelmente será
produzido mais rapidamente.
 Conclusão
Pode-se considerar as revisões de software como filtros. Esses são filtros pelos quais os principais
produtos do processo de desenvolvimento de software devem passar, com o propósito de detectar
erros durante o processo de desenvolvimento o mais cedo possível.
O walkthrough enquanto técnica de revisão de software por um grupo parece ser aplicável a todas
as fases do processo de desenvolvimento de software. A literatura apresenta, por exemplo, caso de
validação de usabilidade de sites web através de walkthroughs.
Walkthroughs informais podem ocorrer a qualquer momento, de forma natural, entre os
profissionais, todavia para que versões mais formais da técnica sejam produtivas, deve-se
considerar o fator humano dentro da organização, pois a técnica pode ser vista como uma invasão
na privacidade do produtor ou mesmo uma avaliação de sua capacidade como profissional.
As revisões de software devem acontecer de forma controlada e deve-se assegurar que todos os
papéis são desempenhados. Os critérios de escolha do produto ou artefato a ser revisado também
são ressaltados, uma vez que a seleção de um produto ou artefato em momento impróprio para
revisão pode ser contraproducente. A formalidade adotada na condução do processo deve
corresponder ao nível de desenvolvimento do produto.