Rr CAPITULO 9 Métodos Estruturados de Verificagao Os testes de verificacdo devem garantir a qualidade de todas as etapas do desenvolvimento de sistemas. A qualidade sera obtida através da correta construgao de documentos e a adequada realizacao das atividades previstas no processo corporativo de engenharia de software. Portanto, os testes de verificacao devem concentrar-se em dois aspectos bem distintos: as ativida- des de verificacgao que focalizam as documentacées, as chamadas revis6es, ¢ as que avaliam as atividades, as chamadas auditorias. As duas situacoes s40 consideradas métodos estruturados, pois possuem planejamento, regras de conducdo e necessitam de profissionais qualificados para desempenhar es- sas funcdes e acompanhar seu progresso. Figura 9.1 Métodos estruturados de verificagéo75 Métodos Estruturados de Verificagdo 9.1, Revisées Arevisdo é um processo “humano” de anilise de determinado documento. Esse processo requer pessoas adequadamente treinadas para desempenhar seus papéis durante a conducdo das atividades de verificacdo. Existem mui- tas formas de organizar as sessdes de revises, sendo que cada uma delas possui suas caracteristicas e particularidades. Para cada fase do processo de criacao de documentos poderemos aplicar um tipo diferente de revisao: na fase de elaboracao inicial do documento, poderemos aplicar a revisao isolada, cujo objetivo é fazer validacoes parciais do documento. Na fase de validacao do documento poderemos aplicar a revisao formal, cujo objeti- vo € validar 0 documento finalizado com todos os grupos interessados. Na fase de divulgacao, poderemos aplicar as reunides de acompanhamento, cujo objetivo é garantir a leitura do documento por todas as pessoas-chave envolvidas. ae Air = a eee ce Documento ere Grupo de Revisao Figura 9.2 Fases de criagéo de documentos e respectivos tipos de revisdes 9.1.1. Revisées Isoladas Esse € um método de verificacéo pouco explorado mas muito eficiente na detecgdo prematura de erros de definicdes e solugées registradas. Trata-se de uma verificacado individual do material produzido, executada por alguém diferente do autor, que tem por objetivo revisar e identificar o maior numero possivel de problemas. A idéia aqui € antecipar a revisao dos documentos com entregas de ver- sdes ainda nao acabadas, para que sofra andlise e julgamento sobre os topi- cos ja abordados. Isso possibilita correcdes nos documentos durante sua fase de concep¢ao.76 GARANTIA DA QUALIDADE DE SOFTWARE cipado dos revisores com as do. Essas revis6es permitem o contato ante Pi xilia na familiaridade com ° cumentacdes que estdo sendo geradas, o que av : ; formato de como determinadas regras estao sendo organizadas ¢ registradas, O grande cuidado que devemos tomar aqui € para que as Tevisdes nag ocorram apenas de forma unilateral. Comoaacao dos revisores serd isolada, poder um unico revisor propor mudancas que prejudiquem uma visao in. tegrada do problema. Como o autor pode ter essa visao de conjunto mais apurada, o revisor pode interpretar a negativa de mudangas como uma im- Pposicdo do autor a alteracdes em seu trabalho. Nesse caso, o autor deverd fazer uma rapida reuniao para decidir qual ca- minho trilhar. Se essas situacdes tornarem-se muito recorrentes, as agoes de tevisdes isoladas podem prejudicar o andamento de concep¢4o do documen- to, atrasando os trabalhos. Isso indica que as areas envolvidas nao estao com- preendendo a extensao dos problemas que estao sendo abordados. Neste caso, o melhor a fazer é propor uma reunido na qual seja explicado o propésito dos trabalhos para todo o grupo de revisores, de forma a nao permanecerem duvi- das estruturais em relacdo a solucdo que esta sendo documentada. Outro grande problema aqui é a chamada “revisao superficial” dos docu- mentos. Isso ocorre quando o revisor nao esta preparado para interpretar 0 documento ou tem pouca iniciativa para realizar sugestoes ou mesmo criti- cas. A tendéncia neste caso seria apenas uma revisao superficial do docu- mento, como erros gramaticais e sugestées estéticas, nado sendo analisado 0 contetido das decisdes apontadas, dando um falso parecer de qualidade so- bre o documento. Quando executadas nesse formato, essas revisoes serao pouco eficientes e detectarao poucos erros. 9.1.2. Revisées Formais As revisoes formais sao as mais efetivas e bem estruturadas técnicas existen- tes de verificacdo. Baseiam-se em reunides com um grupo de profissionais responsaveis em identificar falhas presentes em documentos gerados nas di- versas etapas do desenvolvimento. A identificacdo de erros é obtida através da andlise e discussao de topicos presentes na documentagao. As revisdes tém regras préprias que devem ser Tespeitadas, objetivando 0 maior sucesso da conducao desses trabalhos, que visam a identificac4o 4° maior numero posstvel de erros nas documentacoes, O autor do documento estard presente somente Para responder as diivi- das e eventuais questoes levantadas pelos revisores, nao podendo conduzir417 Métodos Estruturados de Verificagdo reunido. Assim, evitamos que 0 autor desvie de assuntos complicados e omi- ta trechos da documentacdo que ndo esto adequadamente finalizados. Com a participacao limitada do autor, o documento podera ser analisado de uma perspectiva diferente, possibilitando identificar de imediato potenciais in- terpretacdes equivocados sobre um determinado assunto. Todos os participantes ‘devem ter estudado e ter afinidade com o docu- mento e assuntos tratados por este. Dessa forma, cada participante deve, in- dividualmente, preparar-se para coletar o maior numero possivel de infor- magées antes da referida reuniao. Os profissionais envolvidos nesse proces- so devem ter experiéncias e conhecimentos diferentes, para que todas as de- cisdes sejam analisadas por diversos angulos, aumentando o nivel de andlise de cada t6pico a ser discutido, uma vez que possuem uma perspectiva dife- rente dos autores dos documentos. Assim, suas contribuigées serao funda- mentais para o aperfeigoamento da solugao: Apés a execucao das reunides de revisao, ¢ fundamental documentar tudo que foi discutido, os principais problemas detectados, suas corrégdes e as sugestoes de melhoria a serem executadas. Esse material devera ser pro- duzido pela equipe de garantia da qualidade de software que deveraapresen- ta-lo aos autores dos documentos. Os autores realizarao'as mudancas e irdo produzir uma nova versao da documentacao, que devera ser submetida'a uma nova revisdo, porém com um enfoque somente nos pontos modificados (lembre-se de que a primeira revisdo apenas apontou imprecisdes que deve- riam ser corrigidas e essa nova revisdo necesita avaliar se tais mudangas eli- minaram os defeitos anteriormente apontados). 9.1.3. Reuni6es de Acompanhamento Essa forma de verificacao € menos formal do que as reuniées de revisdo, uma vez que nao necessita de uma adequada preparacao por parte dos participan- tes. Somente o apresentador (que € 0 autor do documento) prepara-se paraa Teuniao, enquanto que os demais participantes simplesmente comparecem. O objetivo maior dessas reunides é tornar o documento e o discurso familiar a todos os participantes, enquanto a detec¢do de erros torna-sé uma preocu- pacdo secundaria. As reunides de acompanhamento sao interessantes porque permitem én- volver um ntimero maior de pessoas do que nas reuniGes de inspecdo, permitin- do que mais pessoas envolvam-se na dinamica do ciclo de desenvolvimento do software e, consequentemente, possuam mais colaboradores nesse processo,78 GARANTIA DA QUALIDADE DE SOFTWARE riavelmente, menos eficientes do que ay Esses tipos de reunides sao, inva) blemas. Isso ocorre pelo despreparo inspecédes em termos de detec¢ao de pro! dos participantes e também pelo fato de ser 0 autor do documento quem conduz a dinamica da reuniéo, sendo comum que determinados assuntog sejam estrategicamente nao citados para que exista um sentimento de que tudo esta indo muito bem. Essas reunides devem substituir, com vantagens, as famosas “coletas de assinaturas”, que nao incentivam os profissionais debaterem as decisées registradas nos documentos. Uma forma eficiente de conduzir essas reunides € distribuindo o mate- rial a todos os participantes para que todos possam analisar as documenta- gOes em questo. Sera agendada uma reuniao na qual todos poderao debater diividas e divergéncias existentes e, somente no final desta, caso exista um consenso em relacdo a conducao dos trabalhos e as decisdes tomadas, é que efetivamente sera realizada a coleta de assinaturas. Para a adequada efetivi- dade desse método de verificacdo, todos que sao afetados por aquelas docu- mentacoes deveriam estar presentes na lista de assinaturas do documento e comparecer a reuniao. Isso evitaria o chamado efeito retardado: mudar as coisas depois que determinados assuntos ja foram encerrados simplesmente porque alguns profissionais nao interpretaram adequadamente todas as decis6es registra- das nos documentos e mesmo assim 0 assinaram. Na “coleta de assinatu- ras” € muito comum as pessoas nao lerem adequadamente o material dis- ponibilizado. 9.2. Auditorias As auditorias concentram-se nas atividades criticas de um processo de enge- nharia de software. O principal objetivo das auditorias de qualidade é avaliar se em determinado projeto as diversas equipes estdo respeitando 0 process? de desenvolvimento, se estao registrando os defeitos encontrados, se estao produzindo as atas de reuni6es, se estdo realizando as reunides de revisoes, se estio realizando as documentacées obrigatérias, se estao envolvendo cli- entes e usuarios nos processos € se estao atualizando continuamente o map de riscos dos projetos. Enfim, os auditores da qualidade sao os grandes “guardides do processo”. Esses profissionais devem estar muito atentos as chamadas “quebras de processos”, muito comuns em projetos de desenvolvimento de software: AS quebras sao muito freqtentes em organizagées que nao possuem etapas bem79 Métodos Estruturados de Verificagao definidas e ainda estao dando os primeiros passos na criaca4o de um processo corporativo de desenvolvimento de software. Ocomportamento de “desrespeitar 0 processo” é sempre justificado pe- los profissionais que estao atuando em projetos de software coma argumen- tacdo de que estes sao diferentes dos demais e determinados procedimentos, documentos e controles sao desnecessarios. Everdade que asatuais metodo- logias pregam que os processos de software devem adequar-se a determina- das categorias de sistemas, exigindo uma flexibilidade dos processos em atender niveis de exigéncias diferentes em cada situacao. Apesar de essa afir- macao ser correta, devemos ter cuidado com essa linha de argumenta¢ao, pois cada equipe tenderd a definir o que ¢ importante e fundamental em um projeto de software, estabelecendo quais documentos e procedimentos de- vem ser realizados, criando uma verdadeira confusao metodolégica. Somen- te um grupo que represente o modelo corporativo de desenvolvimento po- dera estabelecer as regras do processo de engenharia de software. Um trabalho de base corrigird essa falta de processos corporativos. Sera necessaria a existéncia de uma equipe de profissionais, preferencialmente a equipe de processos de engenharia de software — SEPG (Software Enginee- ring Process Group), para estabelecer o conjunto minimo de controles e do- cumentagoes que devera ser obrigatorio a todos os projetos, e quais catego- rias de sistemas deverao apresentar controles e procedimentos adicionais. Caso isso nao aconteca, os auditores de qualidade nao terao parametros para conduzir seus trabalhos. 9.3. Aplicando o Processo de Verificagao Como vimos, existem varias abordagens que podemos aplicar para a realiza- cao efetiva de um processo de verificacao de documentos ou mesmo de vali- dacao de atividades executadas em determinadas etapas do ciclo de desen- volvimento. Aqui estabelecemos um conjunto de procedimentos e regras que auxiliarao as equipes de qualidade na pratica e conducdo dessas revi- ses, ampliando as chances de identificacao prematura de erros de levanta- mento e das decisées. 9.3.1. Planejando as Reuniées de Verificagao Uma das primeiras decisoes a serem consideradas no planejamento das veri- ficagdes é estabelecer o alvo dos trabalhos e definir 0 grupo que participara80 GARANTIA DA QUALIDADE DE SOFTWARE das atividades a serem realizadas. Todos os membros do grupo devem ser orientados em relacdo as regras e objetivos a serem alcancados com as atiyi. dades de verificacao. E recomendavel que esse grupo seja heterogéneo, com profissionais de diferentes areas, habilidades e especialidades, permitindo que as anilises e discussées sejam aplicadas sobre varias perspectivas diferentes, garantindo uma revisio do documento sob as varias dimensoes do problema. No planejamento dos trabalhos devera ser considerado o numero de pro- fissionais que desempenharao os papéis de revisores dos documentos. O di- mensionamento sera em funcao da complexidade, importancia e impacto que esse documento poders trazer a determinadas areas da empresa. Poucos revisores deixam o processo pouco eficiente, pois teremos pouca diversida- de de opiniées e, conseqtientemente, poucos elementos que subsidiarao a equipe para decidir se determinado documento esta adequado ow ndo. Em contrapartida, muitos revisores poderao deixar as reunides longas e pouco produtivas, reduzindo a eficiéncia das atividades de revises. Muitos profis- sionais geram um excesso de divergéncia de opinioes que resultam em mui- tas discussées e poucas conclusées, o que deve ser evitado. Um numero ade- quado de revisores gira em torno de quatro a sete profissionais. 9.3.2. Preparando os Profissionais Feito o planejamento adequado das reunides, € necessario preparar 0s parti- cipantes para que recebam o maximo de informagées possiveis sobre o tema aser discutido na reuniao. Cabe aos profissionais que esto organizando as reuniées estruturar uma fonte de informagées que possibilite agregar ©” nhecimento a todos que estarao participando do processo. Oacesso a documentacdo que sera alvo das revisoes também é estraté- gico para o sucesso dessas atividades. Antes de executarmos as revis0es: devemos distribuir os documentos a todos os participantes, dando opo™ tunidade a todos de lerem os materiais e assimilar todos os topicos 4 se- rem discutidos. Durante esse periodo de distribuicdo, os revisores devem estudar 0S do- cumentos e realizar diversos questionamentos referentes a falta de entendi- mento, auséncia de exemplos ou comentarios, a falta de estudos comproba- torios, entre outros pontos. Uma semana ¢ um prazo adequado para um cone veniente estudo das documentagées, sendo possivel estender por algumas semanas, dependendo da carga de servicos e do volume do material.81 Métodos Estruturados de Verificagéo 9.3.3. Executando a Ve agao de Documentos Durante as revisées, o profissional que esta conduzindo as reunides devera garantir que todos os pontos dos documentos foram questionados e avalia- dos pelos revisores. Se a reunido nao for orientada pela estrutura de topicos do documento, corre-se um alto risco de dispersao dos assuntos, dificultan- do o controle de cobertura final do documento. Seguir a estrutura do mate- rial a ser revisado da ao grupo uma possibilidade concreta de avaliar se a or- dem dos assuntos esta adequadamente montada e se existe a necessidade de anexar fontes complementares de informagées para fundamentar algumas decisoes. A conducao de um processo de verificacao segue uma sequiéncia logica simples. As principais atividades a serem executadas esto listadas abaixo: v Um topico é definido e sera escopo das discussées. v Uma questao é levantada por um revisor. v A questao é discutida e avaliada. Os revisores confirmam a existéncia do defeito. ¥ Odefeito éregistrado e detalhado para que seja corrigido pelos autores. v Outras questées sao levantadas até que todas tenham sido analisadas. v Um novo t6pico € identificado até que todos tenham sido discutidos. Os trabalhos de revisao tem como objetivos a identificagao de problemas. Todos os documentos deverdo ser analisados com um olhar critico, exploran- do e questionando todos os pontos do trabalho. Quando determinada questio é levantada, os revisores devem analisar os motivos do ndo-entendimento. Revisdes sao, muitas vezes, encaradas como criticas aos autores, 0 que torna essa tarefa mais dificil, porém, devemos entender que nosso propésito esta em fazer melhor nosso trabalho, e as revisdes estao simplesmente aper- feicoando 0 documento. Todos nés temos a ganhar com esse processo, até mesmo 0 autor, que poder contar com o apoio de outros profissionais, divi- dindo a responsabilidade pelo trabalho. 9.4. Aplicando Checklist na Verificagao Checklist 6 um poderoso instrumento a ser aplicado nas revises de docu- mentos e auditorias de processos de trabalho, pois possibilita direcionar todas as atividades dos testes de verificac4o, criando uma abordagem tni- ca de como avaliar a qualidade de um documento. Esse direcionamento é82 : GARANTIA DA QUALIDADE DE SOFTWARE realizado através de “ ‘guias” que orientam as auditorias e inspecées de do. cumentos, reduzindo o grau de subjetividade em relacdo ao que deve ser avaliado ou nado. A checklist deve ser utilizada como um acessorio durante as fases de veri. ficacdo, pois orienta o profissional a investigar diversos aspectos em Telacao ao documento ou atividade. Apesar de considerada essencial, devemos yer checklist apenas como um “guia” que disciplina a atividade. Figura 9.3, Checklist ap/icada nas diversas fases dos testes de verificagao A pratica de checklist € muito empregada nas organizacées, porém, mui- tas recomendagoes obrigatérias sao desconsideradas, prejudicando a quali- dade de documentos e produtos que estado sendo gerados. O profissional de qualidade podera empregar essas checklists e avaliar sua aderéncia com 0 que esta sendo praticado.