Técnicas de Leitura Baseadas em Listas de Verificação (Checklists)

Olá sejam bem-vindos ao canal engenharia de software com ênfase uml Eu sou professor jis Gets e eu já atuo na área de modelagem de software a vários anos eu tenho quatro livros publicados sobre o assunto e eu já ministrei diversas palestras cursos técnicos com modelagem de software utilizando a linguagem uml na aula de hoje eu vou continuar sobre o tema de verificação e validação dessa vez abordando a técnica de leitura baseada em lista de verificação Então vamos iniciar a nossa aula então nessa técnica como o nome já diz é são utilizadas listas de verificações ou

checklists então os inspetores eles recebem uma lista de perguntas que eles precisam utilizar para inspecionar o documento essas listas de perguntas essas listas de verificação elas versam sobre relativos ao artefato a ser inspecionado ã e as perguntas elas são elaboradas com base de em defeitos e anomalias que costumam ocorrer sobre o tipo de artefato que irá ser inspecionado ah Lembrando que técnicas de leitura são diferentes de técnicas de verificação técnicas de verificação podem utilizar diversas técnicas de leitura ah basicamente nós estamos nos concentrando em inspeções Então inspeções pode utilizar qualquer tipo de de de técnica

de leitura existente Vamos hoje falar sobre a técnica de leitura baseada em nío de verificação Ah então os inspetores eles então devem responder as perguntas que são fornecidas e as perguntas elas servem como guia para que eles possam encontrar determinados defeitos determinadas anomalias determinadas Fas então a lista de verificação ela oferece alguma orientação para os inspetores sobre como conferir o artefato Lembrando que artefato é qualquer produto H relativo a um processo de desenvolvimento de software qual tudo que fori produzido por um processo eh de desenvolvimento de software é considerado um artefato então um artefato pode

ser especificação de requisitos pode ser modelo arquitetural pode ser modelo de projeto detalhado pode ser caso de testes pode ser código etc Ah então a list de verificação ela oferece uma certa orientação para os inspetores de forma que eles inspecionam o artefato mas não determina como eles devem descobrir os defeitos então por isso ela em geral é classificada como não sistemática Lembrando que na aula anterior nó nós eh estudamos a os tipos de orientação de leitura que existem que são intuitivo não sistemático sistemático E altamente sistemático então não sistemático a orientação não sistemática é uma

orientação mínima mas ainda assim alguma orientação sobre como inspecionar determinado artefato ah essa técnica também costuma ser classificada como geral uma vez que todo documento é inspecionado e Idêntica porque em geral toda todos os inspetores ã leem o documento da mesma maneira então aqui E esse tipo de técnica ela precisa de uma categorização de erros que podem ser encontrados no artefato que vai ser inspecionado então Aqui nós temos um conjunto de categorias de erros relativos a um documento de especificação de requisitos eh embora a técnica de verificação pode ser possa ser aplicada a qualquer artefato

é bastante comum que ela seja aplicada em documentos de especificação de requisitos Lembrando que o documento de especificação de requisitos ele descreve os requisitos as funcionalidades bem como os requisitos não funcionais que o software deve atender bom então Aqui nós temos essa categoria de erros então nós temos erros de omissão que são eh informações omitidas como requisitos ou regras de negócio que não foram informados erros de ambiguidade que é um erro muito grave para a engenharia de requisitos que significa que um requisito ou informação pode ser passível de mais de uma interpretação erros de inconsistência

quando existem requisitos ou informações que estão em conflito ou se contradizem erros de incompletude quando estão faltando partes documentos Ou eles ou essas partes estão incompletas ou são ou são detalhadas de forma insuficiente ah por exemplo podem não haver cenários alternativos ou cenários de sessão ou existem falta de detalh sobre requisitos não funcionais Lembrando que requisitos não funcionais representam características que devem a ser atendidas como pelo software como um todo em geral também são chamados requisitos eh de qualidade então exemplos de requisitos não funcionais são por exemplo desempenho e confiabilidade outro tipo de erros são

os erros de precisão ah os requisitos estão mal definidos com pouca precisão sobre o que precisa ser implementado ah como não como por exemplo eh números exatos não foram especificados em termos de tempo de resposta ou capacidade erros de redundância quando informações ou requisitos estão repetidos de forma desnecessária ao longo do documento outros tipos de erro erros de rastreabilidade quando eu não consigo saber a origem de um requisito em termos de quem pediu quando pediu e por pediu erros de viabilidade que eh identificam requisitos que são inviáveis em termos técnicos ou econômicos como por exemplo

requisitos que exigem hardware ou software que não está disponível ou é muito caro ou funcionalidades que não são compatíveis com o cronograma e o orçamento projeto outro erro são os erros de consistência terminológica em que termos técnicos são usados com significados diferentes ao longo do documento ou são usados sinônimos ou variações para se referir ao mesmo ao mesmo conceito isso é gravíssimo para um documento especificação de requisitos pode causar graves erros de compreensão erros de testabilidade que ocorrem quando um requisito ele não pode ser verificado para garantir que ele foi implementado de forma correta de

acordo com que foi especificado Então os requisitos podem não ter critérios de citação Claros os requisitos não funcionais não não possuem informações que permitam medir o seu sucesso ah erros de incorret quando existem informações incorretas ou que não foram validadas pelos pelas partes interessadas eh erros de compatibilidade quando não é definido de que maneira o sistema deverá ser compatível com outras tecnologias plataformas ou softwares como nos casos em que o software precisa trabalhar integrado com outros sistemas ou que o software precisa interagir com outros softwares ou outros hardwares erros de proteção quando não são abordados

ou são abordados de forma inadequada aspectos de proteção como de que maneira os usuários irão se autenticar no sistema o como os ativos do software vão ser protegidos por exemplo dados como eles vão estar protegidos erros de usabilidade quando não há deamento profundo ou correto de como o software deverá ser usado aliás Qual será o de usabilidade do software ou ainda quando esses requisitos de usabilidade eles são vagos ou inexistentes erros de desempenho que não descrevem o o nível de desempenho esperado por ceros requisitos como tempo de resposta ou o desempenho esperado não é realista

erros de confiabilidade quando não são não está explícito o quão confiável o software deve ser ou está descrito de forma muito vaga erros de manutenibilidade e evolução quando não se determina ã requisitos que estabeleçam o nível de manutenibilidade ou de evolução e ou de evolução esperado pelo software ou Isso está muito vago erros de legibilidade quando é difícil ler o documento quando o documento está mal organizado ã como a de formatação como as sessões não estão numeradas esse tipo de coisa opa e Aqui nós temos a lista de verificação ah a respeito do documento de

especificação de requisitos da mesma forma que a que aquela categorização de erros essa lista de verificação também não é exaustiva quer dizer que podem haver outros tipos de erros e podem haver outras perguntas para essa lista de verificação então ah Eu dividi essa verificação em diversas categorias a primeira cobre a justificativa e Esopo do software ou seja por deve se desenvolver o software e qual é o seu objetivo realista de desenvolvimento eh se essas respostas não forem respondidas eh de maneira positiva Então os possíveis erros encontrados são omissão ou ambiguidade Então a primeira pergunta ela

pergunta se existe uma justificativa Clara para o desenvolvimento do software ah O inspetor ele deve marcar sim parcialmente ou não e em caso parcial ou se as respostas foram parcialmente ou não ele deve preencher as observações com os erros que foram encontrados e o tipo de erro se é omissão ou ambiguidade ou ambos ã a que obviamente eh o campo de observações deveria ser maior certo mas por uma questão de espaço eh não foi possível eh colocar o tamanho correto eh a segunda pergunta os benefícios esperados com a implementação dos sistemas estão descritos isso é

importante para justificar o desenvolvimento do software o objetivo e o escopo do software estão claramente definidos pode haver ambiguidade nisso o escopo de determina o objetivo e o escopo são semelhantes mas o escopo determina o objetivo real o objetivo do que é realmente factível além de estabelecer as fronteira do sistema os limites do software estão claramente estabelecidos os limites são mesmos que as fronteiras está relacionado ao escopo as soluções principais do sistema são são listadas de forma geral se qualquer uma dessas respostas for respondida como parcialmente ou não então é necessário identificar o que está

errado e classificar o erro com missão ou ambiguidade ou ambos ah eventualmente as respostas podem ser diferentes por exemplo pode o parcialmente às vezes pode não não ser adequado a resposta parcialmente pode não ser adequada mas vamos ver outras outros níveis de verificação com relação à clareza E compreensibilidade se o documento está claro e fácil de entender Então os requisitos estão claramente definidos e são compreensíveis por todas as partes interessadas Lembrando que parte interessada é qualquer pessoa que tem interesse no desenvolvimento software ou que afetará o desenvolvimento ou que será afetado por ele ã aqui

eu coloquei erros um tipo de erro particular para cada pergunta porque essa categoria pode ter erros diferentes erros distintos dependendo da pergunta então aqui com relação à primeira pergunta o erro seria de ambiguidade em seguida deve se responder existe um glossário definindo siglas e termos técnicos utilizados no documento isso é muito importante para evitar ambiguidade se não existir o erro é omissão os requisitos são passíveis de uma única interpretação isso é básico não deve haver um documento de especificação passivo deais de uma interpretação aqui o erro de ambiguidade os requisitos utilizam uma linguagem uniforme consistente

em todo documento o erro é consistência termin lógica se a resposta for não ah uma nova categoria é com relação a completude ou seja se o documento está completo e o possível erro é o erro de incompletude Então se pergunta se todos requisitos funcionais estão listados se todos os requisitos não funcionais estão cobertos se há omissões em relação às necessidades do sistema se os cenários alternativos de sessões relacionados a cada requisito funcional foram estão devidamente descritos ainda continuando nesse tópico as áreas de negócio consistências e validações necessárias a cada requisito funcional estão devidamente descritas o

documento contém todas as informações necessárias para que o desenvolvimento e teste possa ser realizados adequadamente o impacto de constrangimentos legais ou regulamentares foi considerado outra categoria consistência para verificar se não há conflitos ou contradições o erro se for encontrado é de inconsistência Então se pergunta os requisitos estão consistentes entre si sem contradições ou conflitos a terminologia é usada de forma consistente em todo documento isso é muito importante os diagramas e descrições textuais não entram em conflito e são coerentes com relação à categoria de viabilidade e implement se realmente é viável eh desenvolver o software o

erro o erro se for encontrado é o de viabilidade Então se pergunta os requisitos são factíveis considerando os os recursos e tecnologias disponíveis os requisitos são realistas considerando as restrições de projeto tais como cronograma orçamento e expertiz da equipe existem riscos identificados relacionados à implementação dos requisitos é importante sempre identificar esse tipo de erro aliás de de risco com relação à categoria de testabilidade se for encontrado erro ele classificado como erro de testabilidade obviamente Então se pergunta todos os requisitos são testáveis ou seja eles podem ser verificados por meio de revisões inspeções ou testes basicamente

se determina se o requisito foi atingido foi coberto ou foi foi satisfeito de acordo com que foi especificado outra pergunta existem critérios de aceitação claros para cada requisito isso é importante pros testes de aceitação com cliente outra pergunta os requisitos não deixam margem para subjetividade Ao serem verificados ainda in testabilidade as características relativas à descrição dos itens de dados como tipo taxa de variação unidade exatidão resolução limites média e valores críticos são definidos sempre que necessário as características relativas à descrição das entradas e saídas de cada funcionalidade tais como precisão média frequência e volume foram

definidas com relação à categoria de rastreabilidade rastreabilidade no caso determinando a origem do requisito o erro se for encontrado é o de rastreabilidade Então se pergunta a origem de cada requisito está bem documentada em termos de quem o solicitou quando o solicitou e por o solicitou os requisitos possuem referências Claras a fontes como necessidad das partes interessadas ou documentos que os originaram a há uma conexão Clara entre os requisitos de negócio e de usuário e os requisitos de sistema Lembrando que os requisitos de negócio e de usuário são menos detalhados e os requisitos de sistema

são os mais detalhados eles só são produzidos durante a análise de requisitos e eles já definem um passo a passo de como ã aqueles requisitos se comportarão enquanto que requisitos de negócio são mais gerais e os requisitos de usuário são requisitos intermediários mas ainda com pouco detalhe relação à categoria de prioridade se for encontrado erro ele poderá ser de inconsistência ou omissão ou os dois então se pergunta os requisitos foram priorizados isso é muito importante para identificar o mínimo produto viável o mínimo que é necessário desenvolver para que o cliente se sinta minimamente satisfeito cada

requisito tem uma prioridade claramente definida ou seja ele é essencial desejável opcional está fora do escopo do projeto foi definido o MVP o mínimo produto viável contendo os requisitos cruciais do sistema as prioridades refletem realmente as necessidades das partes interessadas e o escopo do projeto aqui no no no caso se realmente foi validado esse esse software ã com relação à categoria de correção ou seja se o se a especificação está correta se houver um erro ele será classificado como incorret se pergunta todos os requisitos são realmente necessários para o sistema os requisitos foram validados pelas

partes interessadas para garantir que eles reflitam as necessidades reais e estão corretos então de novo aqui validação dos requisitos garantir que o software realmente atenderá as necessidades dos das partes interessadas ainda se pergunta Existe algum requisito que precisa ser reformulado ou ido aqui é diferente se a resposta for sim então vai se classificar como erro de incorret ah com relação aos requisitos de interface se houver erro o erro é desabilidade com exceção da última pergunta primeira pergunta então Eh se pergunta se há protótipos escrevendo Como será a interface Human computador do sistema se os requisitos

cobrem aspectos de usabilidade que impactam diretamente a experiência dos usuários as entradas e saídas do sistema são descritas adequadamente e por último os requisitos descrevem claramente as interface entre o software e possíveis outros softwares ou ou componentes de hardware aí seria um erro de omissão ou ambiguidade caso resposta for não aqui no caso pode ser que essa pergunta não essa pergunta não se aplique no caso de não haver integração com software ou não ter uma comunicação com hardware especial com relação a teia 11 proteção e confiabilidade então se pergunta os requisitos cobrem questões de proteção

como autenticação e proteção de ativos importantes do software como por exemplo dados aqui o erro seria de proteção caso a resposta for não há requisitos para continuidade do serviços e Recuperação de desastres aqu seria o erro de confiabilidade e a confiabilidade tolerância a falhas eh e se elas foram abordadas os requisitos não funcionais caso contrário o erro é de confiabilidade com relação ao item 12 desempenho se for encontrado o erro o erro será classificado como erro de desempenho se pergunta existem requisitos que abordam o desempenho do sistema como tempo de resposta taxa de transferência ou

uso de recursos outra pergunta o desempenho exigido é razoável e factível dentro das limitações do projeto as limitações São aquelas de cronograma oramento limitações da equipe limitações de ferramentas de apoio limitações de hardware com relação a item de manutenibilidade e evolução se houver um erro ele será classificado como um erro de manutenibilidade e evolução se pergunta existem existem requisitos que cubram a facilidade de manutenção e evolução do sistema no futuro dois foram definidos requisitos para garantir que o sistema pode ser atualizado sem grandes interrupções ou contraindicações quando outras outros setores do sistema deixam de funcionar

por exemplo com relação ao item legal e regulamentar o possível erro encontrado seria de omissão ambiguidade Então se pergunta o documento aborda todos os aspectos legais e regulamentares aplicáveis ao projeto e dois foram identificados e listados todos os padrões de regulamentações que o sistema deve seguir então essa foi um exemplo de de lista de verificação como eu falei ele não é exaustivo podem haver outras perguntas de acordo com o documento de acordo com o artefato que está sendo espionado essa lista foi voltada para um documento de especificação de requisitos se o artefato for outro as

perguntas podem mudar e de novo mesmo com relação a um documento de especificação de requisitos outras perguntas poem ser podem ser elaboradas vantagens da técnica de leitura baseada em lista de verificação é ela tem uma boa consistência uma lista de bem padronizada ajuda os inspetores a manter a consistência no exame do documento ah mesmo Que várias pessoas participem do processo ainda assim o resultado normalmente é consistente ah essa técnica ela permite uma cobertura completa essa lista Garanta que nenhum aspecto crítico que tenha sido previsto para o artefato em questão Deixe de ser coberto então cada

it representa uma verificação necessária que precisará ser feita eficiência uma vez que os os inspetores eles sabem o que procurar Isso é feito num tempo menor que outras técnicas e não é necessário improvisar como na técnica AD hck por exemplo eh Outra vantagem é que uma maior quantidade de erros eh são encontrados com relação à técnica AD hoc ã que foi explicada no vídeo anterior então o número de falhas e anomalias que costumam ser descobertos é maior que inspeções mais livres e uma Outra vantagem é a facilidade de aplicação não exige ferramentas complexas e ela

e essa técnica pode ser adaptada com facilidade para diferentes contextos agora com relação às desvantagens existe um foco excessivo em ítens específicos pode haver um foco excessivo em ítens específicos ah Então pode pode acontecer que os inspetores eles se concentrem somente nos itens que T que ser verificados então outros problemas que não haviam S previstos eles podem ser à Não cobertos podem não ser encontrados ã existe o risco de automatização os inspetores eles podem considerar que a lista é uma formalidade e eles podem preencher essa lista com com pouco empenho com pouca dedicação de maneira

superficial sem fazer uma análise profunda do documento com relação às perguntas Ou seja pode haver pouca seriedade e uma outra desvantagem é que existe uma dependência muito forte com relação à qualidade da lista de verificação a lista de verificação precisa ter sido bem feita ela precisa ter sido feita eh ela precisa ter abrangência e qualidade o sucesso da inspeção depende disso então se a lista não tiver sido bem elaborada Então muitos defeitos muitos erros muitas falhas muitas anomalias graves inclusive podem passar despercebidos e nós terminamos mais uma aula eu espero que vocês tenham considerado essa

aula válida se vocês gostaram da aula eu peço que vocês curtam o vídeo compartilhem com quem possa ter interesse e se ainda não estão inscritos eu peço que se inscrevam obrigado pela atenção nós nos vemos nas próximas aulas l