Olá sejam bem-vindos ao canal engenharia de software com ênfase o ML Eu sou professor julianes gues e eu já atuo na área de modelagem de software há vários anos eu tenho quatro livros publicados sobre o assunto e eu já ministrei diversas palestras e cursos técnicos sobre modelagem de software utilizando a linguagem uml na aula de hoje eu vou dar continuidade ao tema de verificação e validação de software dessa vez abordando a técnica de leitura baseada em perspectiva é uma técnica de leitura poderosa Principalmente quando aplicada na inspeção de documentos de especificação de requisitos Vamos iniciar
Então a nossa aula então como eu falei eu vou tratar da técnica de leitura baseada em perspectivas ou Perspective based Reading ou PBR eh Então vamos iniciar esse conteúdo então Eh essa técnica como o nome já diz ela examina o o artefato ah por meio de diversas perspectivas ou seja diversos pontos de vista então cada inspetor o grupo de inspetores assume o papel de um determinado tipo de parte interessada pode ser o usuário final pode ser o projetista pode ser o desenvolvedor pode ser o testador pode ser o gerente de projeto entre outras possibilidades e
ele passa a inspecionar o artefato de acordo com a perspectiva do Papel escolhido levando em consideração as prioridades interesses e preocupações relacionadas a esse papel Então essa é uma técnica que garante uma uma cobertura muito abrangente dos problemas anomalias ou inconsistências que um artefato possa conter eh já que examinar o artefato so diferentes perspectivas pode revelar falhas que outros pontos eh de vista não detectar eu então se examina o artefato considerando diversas facetas diversos pontos de vista diferentes e cada um cobre eh o documento analiza o documento de uma maneira e encontra Possivelmente erros diferentes
então por isso ela é mais abrangente é mais completa porém ela costuma ser mais demorada e mais cara também ã Então essa técnica ela é mais voltada para a inspeção de documentos e especificação de requisitos mas ela pode ser utilizada na inspeção de outros documentos essa técnica ela pode ser classificada como sistemática Porque existe quando se adota uma determinada perspectiva existe uma orientação para o inspetor como ele deve eh procurar defeitos e onde ele deve procurar esses defeitos essa é uma técnica específica ou também chamada focada porque o inspetor ele se concentra em aspectos específicos
do documento e ela é distinta porque cada inspetor ou cada grupo de inspetores examina o artefato sobre uma perspectiva diferente outras características dessa técnica ela é customizável Ela produz listas de verificação personal personalizadas para cada perspectiva ela tem uma cobertura muito Ampla ela permite um aperfeiçoamento controlado e permite treinamento aos inspetores vamos falar um pouquinho sobre cada uma dessas características então com relação à customização a PBR ela não formaliza eh explicitamente um conjunto de procedimentos de inspeção para cada artefato eh na verdade ela simplesmente instrui como as perspectivas os procedimentos e as listas de verificação
podem ou devem ser criadas eh levando em consideração o tipo de artefato que está sendo examinado que está sendo inspecionado claro como ela foi proposta inicialmente para a inspeção de documento especificação de requisitos já existem muitas listas de verificação já existem muitas instruções para diversas perspectivas que eh podem ser utilizadas para inspecionar o documento Mas elas podem ser customizadas para cada projeto e para e também para outros tipos de artefatos ah listas de verificação personalizadas por perspectiva então cada perspectiva ela deve possuir uma lista de verificação ou seja um conjunto de perguntas e critérios de
análise específico dependendo da perspectiva as perguntas que deverão ser feitas ou que deverão ser respondidas serão diferentes embora ocorram às vezes perguntas semelhantes ah entre um duas ou mais perspectivas como nós vamos perceber Ah então um inspetor por exemplo que analise o documento a partir da perspectiva do usuário final ele se concentra em verificar aspectos como usabilidade e determinar se os requisitos realmente atendem às necessidades do usuário já se o inspetor ele examinar o documento sobre a perspectiva do desenvolvedor então ele irá analisar a clareza técnica dos requisitos e se a implementação desses requisitos é
realmente viável levando em consideração restrições de projeto com relação à característica de cobertura Ampla como Como já foi falado uma vez que são aplicadas diversas perspectivas então Eh essa técnica ela tende a cobrir melhor a inspeção do artefato e de maneira que ah como o artefato é inspecionado sobre diversas perspectivas erros diferentes erros diversos costumam ser encontrados então é uma cobertura mais Ampla mais abrangente do do artefato e encontra um número maior de anomalias de erros e falhas permite acionamento controlado Então as instruções a respeito de cada perspectiva e as questões relacionadas a cada perspectiva
elas podem ser melhoradas levando em consideração as experiências das inspeções anteriores permite treinamento já que essa não é uma técnica AD hoc Então ela não se baseia exclusivamente no conhecimento ou na experiência do Inspetor Então os inspetores eles podem ser treinados então qualquer pessoa com o conhecimento técnico necessário a perspectiva que vai ser eh que ele vai examinar a partir da qual ele vai examinar o documento ele pode ser treinado nessa técnica Ah então a aplicação dessa técnica consiste em três partes principais introdução instruções e perguntas ou lista de verificações como nós vamos abordar a
seguir então introdução basicamente a introdução ela fornece um texto como o nome já diz introdutório básico que explica como O inspetor deverá aplicar a perspectiva em questão vai haver uma introdução para cada tipo de perspectiva diferente porque a a introdução os objetivos eles variam dependendo da perspectiva obviamente então a introdução ela explica como O inspetor deverá aplicar essa a perspectiva que ele assumiu Que tipo de informações Ele precisará se concentrar para cumprir o objetivo da perspectiva e que tipo de erros ou anomalias ele estará buscando então cada perspectiva busca por determinados erros responde a determinadas
questões e com relação às instruções elas basicamente elas informam ao inspetor de que maneira ele deverá examinar o artefato e dependendo da perspectiva e ele recebe instruções também para desenvolver certos modelos ou produzir documentos em Alto Nível que sirvam de apoio para a inspeção na verdade ele pode utilizar documentos ou ou modelos que já estejam prontos na no artefato como por exemplo num documento de esp ação de requisitos e a o terceiro item são as perguntas que é um conjunto o nome já diz é um conjunto de perguntas que formam uma lista de verificação que
são utilizadas pelo inspetor para a verificar o artefato essas perguntas elas precisam ser elaboradas levando em consideração a perspectiva selecionada como eu falei já existem eh sugestões de perguntas mas como a técnica ela é customizável essas perguntas podem ser atualizadas podem ser modificadas podem ser melhoradas então o efeito dessas instruções são três as instruções ajudam os inspetores os inspetores a decompor os requisitos do documento em partes menores força os inspetores a trabalhar mais ativamente com os requisitos levando em consideração a perspectiva e focalizam a atenção do Inspetor nas informações que realmente são antes para a
perspectiva em questão bom existem vários tipos de de perspectivas aqui nós vamos apresentar uma lista não exaustiva de perspectivas para a técnica eh para essa técnica de leitura então Eh pode ser aplicadas a perspectiva do usuário final a perspectiva do projetista a perspectiva do desenvolvedor a perspectiva do testador a perspectiva do gerente de projetos a perspectiva do mantenedor a perspectiva do regulador e a perspectiva do auditor Mas como eu falei essa é uma lista não exaustiva ou seja podem eh serem criadas outras perspectivas por exemplo um aluno meu de mestrado na na sua dissertação Ele
criou como parte do trabalho dele uma perspectiva de um de um agente de software uma vez que ele estava desenvolvendo uma um padrão de especificação de requisitos para sistemas multiagentes e ele então ele também desenvolveu uma técnica de inspeção para esse padrão e ele criou uma ele utilizou a técnica de leitura baseada em perspectiva criando a perspectiva de um agente de soft então outras perspectivas podem ser adicionadas outras perspectivas podem ser criadas agora é necessário ã analisar o documento sobre todas essas perspectivas não depende do objetivo do projeto alguns projetos não precisam que todas essas
perspectivas eh sejam aplicadas dependendo do projeto dependendo do objetivo do do software H algumas perspectivas são mais válidas que outras Eu recomendo que pelo menos a perspectiva do usuário final do projetista e do testador sejam aplicadas Mas como eu falei essa técnica ela é customizável a cada projeto e cada projeto terá as suas prioridades e as suas perspectivas mais adequadas ã Então vamos falar sobre a perspectiva do usuário ou operador Então vamos iniciar com a introdução ah Assuma que você está lendo os requisitos so a perspectiva do usuário você está interessado em saber se os
requisitos descrevem adequadamente as funções do sistema concentre-se sobre a corretude completude e usabilidade dos requisitos instruções caso não existam Produza um conjunto de casos de uso casos de uso são muito úteis para entender as funcionalidades que um sistema oferece aos seus usuários e Quais atores ou seja quais grupos de usuário podem pode utilizar essas funcionalidades Então esse conjunto de casos de uso ele deve cobrir pelo menos os requisitos essenciais e mais críticos do sistema preferencialmente que cubram-se todos os todos os casos de uso primários ou seja casos de uso que ah agregam valor ao sistema
os casos de uso eles devem ser documentados cuidadosamente e devem ser definidas as entradas necessárias e as saídas geradas para cada funcionalidade também se não existirem deve-se definir fluxos de controle para cada funcionalidade utilizando por exemplo diagramas de atividade e agora nós temos a lista de verificação relacionada à perspectiva do usuário então primeira pergunta os requisitos são passíveis de uma única interpretação o possível erro caso essa a a resposta a essa pergunta seja negativa é o de ambiguidade em seguida os requisitos cobrem os as principais necessidades e expectativas dos usuários possível erro omissão toda informação
relevante está disponível para a criação dos casos de uso possível erro incompletude se os casos de uso já existem eles estão Claros precisos e completos possíveis erros incompletude ou ambiguidade se os casos de uso já existem eles cobrem corretamente os cenários principais alternativos de exceção de cada funcionalidade possível erro incompletude os cenários quando existem são consistentes com as necessidades do usuário possível erro inconsistência a especificação permite criar um software intuitivo e fácil de aprender e usar possível erro usabilidade a especificação inclui considerações sobre a acessibilidade e a experiência do usuário possíveis erros omissão ou ambiguidade
a especificação tempo o treinamento e a documentação necessários para os usuários possível erro omissão ou irrealismo há protótipos descrevendo a proposta de interface com os usuários Eles foram validados e aprovados possível erro omissão agora vamos analisar a perspectiva do projetista Assuma que você está examinando os requisitos a partir da perspectiva do projetista do software você está interessado em saber se os requisitos estão detalhados o suficiente para que o projeto possa ser feito baseado neles Verifique se os requisitos cobrem todos os aspectos relevantes Garanta que o software descrito possa ser projetado de forma eficiente sustentável e
consistente com boas práticas de engenharia de software então essencialmente essa perspectiva ela tenta determinar se é possível fazer um projeto adequado baseado na especificação de requisitos E aí nós temos as instruções baseando-se no documento de especificação e requisitos crie um projeto de alto nível do sistema que abranja uma proposta de arquitetura para o software identificado Lembrando que a arquitetura é o esqueleto do software é estrutura a partir do Qual o software será construído por exemplo pode ser uma arquitetura mvc uma arquitetura em camadas uma arquitetura de microsserviços uma arquitetura architecture uma arquitetura de componentes distribuídos
e assim vai então uma proposta essa essa proposta de arquitetura ela deve identificar módulos componentes E se for o caso sistemas integrados E também como eles se integrarão dentro dessa arquitetura também o projetista deve produzir qualquer outro modelo de projeto em Alto Nível que julgar necessário como por exemplo modelos de classe de domínio ou diagramas de interação e agora nós vamos à lista de verificação relacionada a essa perspectiva ela tem ela está dividida em diversos noos tópicos o primeiro tópico é sobre clareza e completude técnica então primeira pergunta os requisitos são claros precisos e não
ambíguos de maneira que um projeto possa ser produzido baseado em uma única interpretação possível erro caso a resposta seja negativa ambiguidade ou incompletude todas as funcionalidades necessárias estão definidas no documento possível erro omissão o documento cobre Tod todas as regras de negócio e outras consistências associadas às funcionalidades possível erro omissão todas as restrições de projeto ou seja cronograma orçamento ã expertiz da equipe limitações de ferramentas estão listadas e detalhadas possível erro comissão a especificação fornece informações suficientes para permitir o desenvolvimento do projeto arquitetônico e do projeto detalhado Lembrando que o projeto arquitetônico como nome já
diz define a arquitetura e o projeto detalhado detalha as funcionalidades demonstra como as funcionalidades serão solucionadas o projeto destaca a solução enquanto que a especificação de requisitos identifica o problema possível erro omissão ou incompletude os requisitos são suficientemente detalhados para o projeto possível erro incompletude existem informações específicas sobre modularidade interface integração que o projetista precisa saber para construir o sistema possível erro omissão os cenários principais alternativos e de exceção de cada requisito funcional estão devidamente descritos possível erro omissão ou incompletude há um modelo conceitual identificando as classes de entidade devidamente classes de entidade são classes
relacionados diretamente ao domínio do problema possível erro omissão ou incompletude os requisitos são consistentes entre si não existem contradições ou conflitos entre eles possível erro inconsistência os requisitos são consistentes com as normas e padrões da organização possível erro inconsistência os requisitos são Tecnicamente viáveis para a implementação considerando as restrições de projeto possível erro e realismo agora falando sobre viabilidade de implementação a descreve Quais são as exigências de hardware sistema operacional ou outras ferramentas possível erro omissão existem considerações sobre a escalabilidade do sistema levando em consideração carga de usuários processamento de dados ou comunicação possível erro
omissão os requisitos levam em conta otimizações de desempenho uso de memória e consumo de recursos possível erro omissão os requisitos consideram aspectos de proteção e controle de acesso como autenticação e proteção contra ataques possível erro omissão existem requisitos explícitos sobre a proteção dos dados do usuário e confidencialidade possível erro omissão os requisitos garantem robustez e tratamento de erros possível erro omissão Ahã falando um pouco sobre o tópico de confiabilidade a especificação detalha o quão confiável o software deve ser em termos de disponibilidade e transparência de falhas possível erro omissão o sistema inclui mecanismos para lidar
com falhas ou situações excepcionais como erros de rede falta de recursos ou entradas inválidas possível erro omissão existe um plano Claro para recuperação de falhas e continuidade de operação possível erro omissão manutenibilidade e extensibilidade os requisitos permitem que o sistema seja projetado para ser fácil de manter e evoluir no futuro possível erro omissão a especificação prevê a possibilidade de atualizar ou modificar o sistema sem comprometer a integridade dos componentes já implementados possível erro omissão existe preocupação com a modularidade e a separação de responsabilidades facilitando futuras expansões possível erro omissão o sistema foi pensado para suportar
futuras mudanças e evoluções tecnológicas possível erro omissão há requisito que prevêem possíveis necessidades de atualização ou mudança de tecnologias permitindo que o sistema acompanhe a evolução do mercado possível erro comissão o documento destaca-se a requisitos com alto nível de volatilidade e que poderão sofrer mudanças após o software ser concluído ou Mesmo durante seu desenvolvimento possível erro omissão com relação aos requisitos não funcionais os requisitos não funcionais como desempenho escalabilidade proteção usabilidade e outros estão claros e são mensuráveis possível erro ambiguidade ou omissão os requisitos especificam limites ou metas Claras para tempo de resposta capacidade de
carga e outros critérios de desempenho possível erro ambiguidade ou omissão requisitos como tempo de inatividade permitido capacidade de suportar milhões de usuários ou tempo de recuperação em caso de falha estão bem definidos possível erro omissão bom e nós terminamos a lista de verificação da perspectiva do projetista Lembrando que essa é uma sugestão de lista de verificação essa é uma lista não exaustiva e como já foi falado essa técnica ela é customizável novas perguntas podem ser adicionadas perguntas anteriores podem ser retiradas ou modificadas agora nós vamos falar sobre a perspectiva do desenvolvedor a suma que você
está lendo a especificação a partir da perspectiva do desenvolvedor do software você está interessado em Verificar se os requisitos fornecem informações suficientes e Claras para a implementação correta do sistema seu objetivo é garantir que os requisitos serão viáveis bem detalhados e não ambíguos instruções revise os requisitos para determinar se estão Claros completos e são implementáveis o foco aqui é garantir que os requisitos Eles são passíveis de serem implementados de forma fácil identifique se existem ambiguidades ou lacunas que possam dificultar o desenvolvimento avalie a viabilidade de implementação considerando as restrições de projeto lembrando restrições de projeto
leva em consideração por exemplo orçamento cronograma ã necessidade ferramentas necessidade hardware necessidade de software conhecimento da equipe esse tipo de coisa e vamos à lista de verificação da perspectiva do desenvolvedor os requisitos são claros precisos e e detalhados o suficiente para transformar para serem transformados em código possível erro ambiguidade vocês vão notar que algumas perguntas são semelhantes H entre as listas de verificação possuem alguma semelhança algumas À vezes são muito parecidas Esse é um dos problemas dessa técnica às vezes existe uma certa redundância nas perguntas Mas como já foi falado o objetivo é cumrir completamente
o artefato ou mais completamente possível por meio de diversas perspectivas continuando os requisitos são viáveis considerando as restrições de projeto possível erro inviabilidade os requisitos são Tecnicamente viáveis considerando as ferramentas e tecnologias disponíveis possível erro inviabilidade as dependências entre componentes do sistema foram especificadas claramente possível erro omissão ou incompletude há instruções específicas sobre o desempenho esperado como tempo de resposta ou uso de memória possível erro omissão a especificação aborda a modularidade do sistema promovendo baixo acoplamento ou seja pouca dependência entre as classes e alta coesão classe possuindo apenas uma responsabilidade possível erro omissão os requisitos
incluem informações sobre segurança e proteção de dados durante a implementação possível erro omissão os cenários de exceção e mensagens de erro estão claramente descritos permitindo que o código trate corretamente todas as situações possíveis possível erro omissão ou incompletude os requisitos consideram a escalabilidade do sistema para suportar crescimento futuro e maior volume de usuários possível erro omissão a especificação menciona práticas recomendadas de desenvolvimento como reutilização de código padrões de projeto ou uso de arcabouços ou seja frameworks específicos possível erro omissão existem requisitos de testes automatizados que garantam a qualidade e a confiabilidade do código implementado possível
erro omissão e agora vamos falar sobre a perspectiva do testador basicamente o testador ele tenta determinar se os requisitos Eles são passíveis de serem testados com certa facilidade se é possível produzir casos de testes baseados nele então vamos vamos à introdução Assuma que você está lendo os requisitos a partir da perspectiva do testador do software você está interessado em saber se os requisitos estão adequados para que se possa escrever casos de teste baseados neles de maneira que possa se garantir que o comportamento software está de acordo com o esperado em todos os cenários possíveis incluindo
cenários de exceção e de falhas concentre-se em encontrar requisitos vagos ambíguos incompletos obscuros e inconsistentes e vamos às instruções então para cada requisito crie um caso de teste ou um conjunto de casos de testes que possam ser usados para verificar o requisito eh se recomenda que se crie testes para cada saída diferente de uma determinada funcionalidade E que sejam documentadas as entradas e saídas esperadas para cada caso de teste e vamos a às perguntas relacionados a essa perspectiva a especificação apresenta critérios Claros de aceitação para cada requisito se a resposta for não o possível erro
pode ser de omissão ou ambiguidade caso os critérios não sejam fáceis de interpretar ou sejam passíveis de mais uma interpretação os requisitos são testáveis de forma Clara e objetivo possível erro ambiguidade a especificação descreve adequadamente todosos cenários incluindo casos de sucesso casos em que há fracasso ou seja erros falhas e exceções possível erro omissão os requisitos são testáveis a um custo e a um prazo aceitável não adianta o requisito ser testável se demora demais ou se o custo para isso é alto demais possível erro irrealismo requisitos não funcionais como desempenho proteção ou escalabilidad são descritos
de maneira que possam ser testados em termos de parâmetros quantitativos e mensuráveis como por exemplo tempo de resposta ou capacidade de carga possível erro omissão ou ambiguidade há detalh suficientes sobre os fluxos de dados e interações do sistema para que testes de integração possa ser planejados possível erro inconsistência ou omissão há informações suficientes para criar testes automatizados Quando aplicável possível erro omissão requisitos de proteção e privacidade estão definidos de forma que possam ser validados possíveis erros omissão ou ambiguidade Lembrando que na engenheria de software proteção equivale Ao que se chama mente de segurança segurança na
verdade diz respeito a evitar que erros não intencionais ocorram enquanto que proteção ela está mais voltada para impedir invasões que pessoas eh entrem no sistema sem serem autorizadas outra pergunta a especificação inclui informações sobre os ambientes de teste necessários que incluem qual hardware qual software qual rede são necessários ferramentas de teste necessárias possível erro omissão ou desatualização vamos falar agora sobre a perspectiva do gerente de projetos Assuma que você está lendo os requisitos so a perspectiva de um gerente de projetos você está interessado em garantir que os requisitos são viáveis dentro das restrições do projeto
e que não apresentam riscos graves ao cronograma orçamento ou escopo do software o escopo determina os objetivos viáveis do software os objetivos factíveis dentro de uma eh visão pragmática se realmente é capaz de ser eh desenvolvido o escopo também serve para determinar quais são H os requisitos que realmente fazem parte do software Eos quais estão fora das suas fronteiras Ahã então o objetivo é identificar qualquer obstáculo que possa impactar o sucesso das entregas dentro dos parâmetros acordados com as partes interessadas então o objetivo do gerente é garantir que ele consegue entregar o software dentro dos
prazos e e orçamentos estabelecidos e que o software é funcional e atende a atende o que o que o cliente pediu bom vamos às instruções primeiro revise os requisitos considerando as restrições de cronograma orçamento e recursos para o projeto aí recursos vem software hardware equipe etc identifique qualquer risco potencial de mudanças no escopo ou problemas de comunicação entre as equipes que possam prejudicar o andamento do projeto aval os requisitos foram especificados de forma Clara e com critérios mensuráveis facilitando monitoramento e controle de desempenho do projeto então o gerente ele tenta descobrir se há riscos relacionados
ao projeto primeiramente seria viável se é viável desenvolver o o o software e quais são os riscos ã relacionados a esse ao desenvolvimento desse software e como ele pode impedir que eles ocorram e se ocorrerem como ele pode eh tratar impedir que esses riscos causem Impacto ainda falando sobre as instruções Produza uma matriz de riscos para auxiliar a identificar e classificar os riscos Associados aos requisitos então deve-se utilizar essa Matriz para determinar se esses riscos podem mesmo ocorrer E caso ocorram qual seria o impacto desse risco no projeto priorize os requisitos de maneira a identificar
os requisitos essenciais desejáveis e opcionais e também os que estão fora do escopo do software Então tem que se determinar se os os requisitos solicitados realmente fazem parte do escopo do software realmente devem ser desenvolvidos e também para determinar o mínimo produto viável então se eu consigo isolar os requisitos essenciais eu sei qual é o mínimo que eu tenho que desenvolver para esse software caso o cronograma ao orçamento não sejam suficientes e vamos às perguntas os requisitos são realistas dentro dos prazos de orçamentos estabelecidos se a resposta for não o possível erro é de planejamento
a clareza suficiente nos requisitos para evitar retrabalho e mudanças de escopo possível erro ambiguidade ou incompletude os requisitos leve em consideração possíveis riscos e contingências possível erro gestão de riscos os os requisitos são mensuráveis e permitem acompanhar o progresso do projeto possível erro falta de critérios mensuráveis os requisitos permitem uma alocação eficaz de recursos humanos e materiais possível erro gestão de recursos há requisitos que podem gerar mudanças no escopo do projeto durante a execução possível erro controle de escopo as dependências entre os requisitos e os diferentes entregáveis estão bem mapeadas possível erro dependência os requisitos
estão AL ados com os objetivos do projeto e os interesses das partes interessadas possível erro desalinhamento com os objetivos do projeto Vamos falar agora sobre a perspectiva do mantenedor Assuma que você está lendo os requisitos sobre perspectiva do mantenedor do sistema ou seja quem irá corrigir erros fazer adaptações ou mesmo evoluir o software você está interessado em saber se os requisitos são fáceis de compreender e permitem fácil manutenção e evolução concentre-se em garantir que as justificativas para os requisitos estão explicadas se há dependências entre eles e se há informações suficientes para que o software seja
mantido ou evoluído sem contraindicações a um curo de tempo aceitáveis contraindicações é quando eu faço uma manutenção numa parte de um software e outros módulos componentes classes deixam de funcionar est funcionando e passam a não funcionar a partir da manutenção então é uma manutenção com contraindicações uma manutenção basicamente mal feita Então eu preciso analisar as dependências entre os diversos componentes diversas classes para evitar esse tipo de coisa instruções baseado nos requisitos crie diagramas de classes de domínio de atividades e divisão Geral de interação descrevendo as funcionalidades a o diagrama de visão Geral de interação ele
ajuda a identificar as dependências entre as várias funcioná idades ah as classes de domínio um diagrama de classe domínio é um diagrama de projeto é uma extensão do modelo conceitual onde eu já enfoco o problema então as classes por exemplo já contém métodos de novo esses diagramas eles são representados em Alto Nível são mais um rascunho do que os diagramas reais mas eles servem para auxiliar na inspeção analise as dependências entre as funcionalidad e para cada funcionalidade verifique sua origem e motivação ou seja quem pediu por pediu quando pediu suaid sua compreensibilidade e seu nível
de modificabilidade ou seja o quão rá requisito aparenta ser crie uma matriz de rastreabilidade para estabelecer a origem e o impacto da mudança de cada requisito no projeto é mais fácil a matriz estabelecer a origem Mas é bom se for possível determinar o impacto caso o requisito seja seja modificado o impacto em termos de quais outros artefatos do projeto deverão ser modificados então Artefatos de projeto detalhado Artefatos de teste Artefatos de código em termos de módulos de código componentes de código classes etc Então vamos à lista de verificação os requisitos são claros o suficiente para
que o software seja facilmente compreendido e modificado no futuro possível erro ambiguidade a especificação prevê baixo acoplamento ou seja pouca dependência entre as classes e alta coesão ou seja classe possuindo apenas uma responsabilidade possível erro comissão é possível rastrear a origem e motivação de cada requisito para garantir que ele ainda é válido porque os requisitos podem mudar então a justificativa inicial de um requisito pode deixar de ser válida ao longo do tempo possível erro rastreabilidade há informações suficient sobre dependência entre os módulos e ou classe de software para evitar contraindicações de manutenção possível erro omissão
o sistema foi projetado para ser extensível permitindo a adição de novas funcionalidades possível erro omissão a arquitetura dotada facilita a manutenção do sistema possível erro omissão ou inconsistência Lembrando que nem sempre isso é possível dependendo dos requisitos não funcionais uma arquitetura ela às vezes precisa sacrificar um pouco a manutenção Ah ainda requisitos não funcionais como desempenho confiabilidade ou escalabilidade são realistas e sustentáveis ao longo do tempo possível erro e realismo as dependências de software e hardware estão bem documentadas e são facilmente gerenciáveis possíveis erros desatualização ou omissão Vamos falar agora sobre a perspectiva do regulador
basicamente ele tenta determinar se as normas e leis estão sendo idas Assuma que você está lendo os requisitos da perspectiva de um regulador você está interessado em saber se a especificação de requisitos tem boa qualidade e segue todas as leis normas diretrizes e padrões necessários isso é crucial em áreas que precisam obedecer a requisitos rigorosa de conformidade como saúde Finanças segurança e dos quais dependem vidas humanas ou a risco de desastres ambientais instruções baseado nos requisitos cria na lista de padrões leis normas políticas e possíveis outros documentos relevantes que devam ser obedecidos pela especificação de
requisitos Verifique se os padrões e normas estão sendo seguidos corretamente e vamos a lista de verificação a especificação segue corretamente o padrão de documentação adotado cobrindo todos os tópicos relevantes prescritos como por exemplo padrão de documentação eh de especificação de requisitos da i3e possível possível erro falta de padronização a especificação cumpre com todas as regulamentações e leis aplicáveis à área ou Setor possível erro omissão os requisitos abordam as necessidades de proteção a dados e privacidade conforme exigido pelas normas possíveis erros informação insuficiente ou ambígua há requisitos para garantir que o sistema estará preparado para auditorias
de conformidade possível erro omissão requisitos incluem a verificação de padrões de certificação obrigatórios para o setor quando por exemplo a a empresa quer adotar um cmmi adotar um padrão de padrão de certificação CMI cmmi ou mpsp possível erro omissão o sistema leva em consideração a necessidade de manter registros para fins de auditoria possível erro omissão ou incompletude e vamos falar sobre a perspectiva do auditor na maioria das se trata de auditor externo e ele pode por exemplo Verificar se os projetos os processos de desenvolvimento estão de acordo com os programas de maturidade que a empresa
busca certificação como o cmmi por exemplo então a sua que você está lendo da especificação e requisitos da perspectiva de um auditor você deve avaliar a conformidade da especificação com as normas e padrões estabelecidos pela organização bem como com os critérios exigidos pelos programas de maturidade externos Garanta que os processos e práticas estejam alinhados com os critérios de controle de qualidade e conformidade estabelecidos pelos programas de maturidade instruções a partir da especificação compire uma lista de padrões leis normas políticas e regulamentos relevantes que são necessários para conformidade e certificação dos projetos dos processos da empresa
esta lista deve incluir requisitos específicos relacionados a qualquer programa de maturidade que a organização esteja buscando como por exemplo cmmi ou MPS BR verifique-se a especificação atende aos critérios de conformidade com padrão de maturidade e vamos às perguntas os requisitos atendem à normas e padrões estabelecidos pela organização possível erro e inconformidade a especificação segue os critérios exigidos por programas de maturidades externas como cmbi ou msbr possível erro inconformidade os requisitos contemplam todas as leis e regulamentos aplicáveis à área de atuação do software possível erro omissão a documentação de requisitos inclui referências Claras a normas e
políticas que precisam ser seguidas possível erro omissão há conflitos com as normas e padrões estabelecidos possível erro inconsistência a especificação fornece informações suficientes sobre como os requisitos serão monitorados E auditados durante o desenvolvimento e a operação do sistema possível erro omissão a especificação considera todos os aspectos de controle de qualidade e conformidade necessários para a certificação conforme os programas de maturidade possível erro e inconformidade os requisitos garantem que todas as práticas e processos estejam documentados de acordo com os padrões exigidos para a certificação possível erro inconformidade a especificação inclui um plano para revisões e auditorias
regulares para garantir a manutenção da conformidade ao longo do ciclo de vida do sistema possível erro omissão bom agora nós vamos falar sobre as vantagens dessa técnica só lembrando que como eu falei as perspectivas que foram apresentadas elas não são exaustivas ou seja podem-se incluir outras perspectivas ou pode retirar Não não é necessário aplicar todas aquelas perspectivas isso depende do projeto depende dos objetivos do software as perguntas as listas de verificação que foram apresentadas são sugestões Como já foi falado essa técnica ela customizável ou seja aquelas listas podem ser adaptadas podem inclusive serem abandonadas de
uma outra lista ser criada aquelas perguntas elas podem ser adaptadas para cada projeto e para cada artefato que está sendo avaliado então novas perguntas pode podem ser adicionadas perguntas antigas podem ser eliminadas ou modificadas mas vamos falar sobre as vantagens dessa técnica Então como já foi falado ela fornece uma cobertura abrangente ela é boa em identificar ambiguidades ela detecta diversos tipos de erros em sobre diversas dimensões sobre diversos aspectos ela aumenta a qualidade do sistema ela permite uma detecção antecipada de problemas e portanto uma uma mitigação de riscos eh precoce ela suporta a colaboração entre
as partes interessadas ela permite uma melhoria contínua e ela permite a adaptabilidade a diferentes projetos como eu já falei vamos falar um pouquinho sobre cada uma dessas vantagens com relação à cobertura abrangente Como já foi falado como são aplicadas várias perspectivas os artefatos eles são ã examinados considerando vários pontos de vista e isso permite uma verificação do artefato de uma de uma maneira muito Ampla e abrangente Então muitos aspectos que poderiam ser negligenciados se apenas uma perspectiva fosse considerada eh são cobertos e isso reduz a chance que algum erro passe despercebido vamos falar alguns exemplos
então a perspectiva do desenvolvedor ele assegura que os requisitos sejam Tecnicamente viáveis a perspectiva do usuário verifica os habilidades se as funcionalidades realmente atendem as necessidades dos usuários finais a perspectiva do regulador Analisa conformidade legal a perspectiva do gente projeto determina se o cronograma e o o cronograma e orçamento são viáveis para para o projeto se é viável desenvolver realmente o software fque em riscos agora vamos falar um pouquinho sobre a a a vantagem que essa técnica ela detecta erros em várias dimensões ou seja sobre diversos aspectos então cada perspectiva ela tende a identificar certos
tipos de erros certos tipos de anomalias ou ou inconsistências então as perspectivas elas se elas se complementam então várias dimensões são cobertas Então muitos tipos de erros são são identificados Então as dimensões podem ser funcionalidade usabilidade estabilidade escalabilidade conformidade proteção legalidade desempenho e outras Aqui nós temos alguns exemplos então o desenvolvedor ele pode detectar ambiguidades técnicas um testador pode encontrar lacunas relacionadas à testabilidade das funcionalidades um regulador aponta problemas de conformidade regulatória um projetista identifica problemas relativos a arquitetura ou a modidade ou interface entre os componentes do software ou a incapacidade de projetar de de
fazer um projeto relacionado a uma determinada funcionalidade um auditor ele verifica adesão a programas de maturidade um gerente de projeto identifica riscos relacionados a prazo custo e alocação de recursos entre outros eh possíveis erros uma outra uma outra vantagem é que existe um aumento da qualidade do sistema então a os as várias perspectivas garantem uma análise e detalhada os requisitos Então existe uma maior qualidade na no documento de especificação de requisitos o que provavelmente levará a um bom projeto a um um bom conjunto de testes a uma boa a uma boa codificação então da perspectiva
do auditor se garante a qualidade dos processos da perspectiva do desenvolvedor se garante que o sistema seja escalável ã a perspectiva do regulador garante a conformidade com normas a perspectiva do gente projeto assegura que o sistema atenda aos prazos e orçamentos planejados entre outras possibilidades com relação à vantagem de detecção antecipada de problemas e mitigação de riscos Então como existem múltiplas perspectivas então problemas potenciais como por exemplo ambiguidades inv viabilidades inconsistências elas são identificada cedo durante o desenvolvimento do software e isso permite que ã riscos para o projeto eles sejam identificados precocemente Ou seja no
início e então é possível eh determinar se realmente eles podem ocorrer e criar planos de contingência para evitar que ocorram Ou pelo menos que a ocorrência cause pouco Impacto Ah então por exemplo o usuário pode identificar problemas de usabilidade ou que as funcionalidades não atendem realmente as suas necessidades urgente projeto identificar riscos operacionais de orçamento ou de cronograma o testador pode identificar inconsistências que poderiam ser problemáticos para a produção de casos de teste o auditor ele destaca lacunas falhas de conformidade o desenvolvedor identifica desafios técnicos e requisitos complexos entre outras possibilidades com relação ao suporte
e a colaboração entre as partes interessadas bom ah essa técnica ela facilita a comunicação entre as partes interessadas uma vez que embora cada grupo ou cada inspetor individual revie os requisitos levando em consideração a sua próprias as suas próprias perspectivas ou responsabilidades depois da inspeção eles trocam informações e falam sobre Que tipos de erros eles encontraram Que tipos de defencia eles identificaram no artefato com relação à melhoria contínua no momento que se aplicam diferentes perspectivas isso permite que a equipe identifique áreas a serem ajustadas Então os artefatos eles vão ser constantemente melhorados os novos Artefatos
de especificação de requisitos por exemplo sofrerão melhorias contínuas considerando as inspeções que foram realizados então por exemplo o auditor ele sugere melhorias no controle nos controles de qualidade o gerente de projeto propõe otimizar otimizações no cronograma e alocação de recursos o mantenedor propõe melhor modularidade o regul sugere maior alinhamento com com as regulamentações entre outras entre outras possíveis sugestões com relação à adaptabilidade a diferentes projetos Como já foi falado essa técnica é bastante customizável então ela pode ser adaptável facilmente a de projetos diferentes com objetivos diferentes Então nem todas as perspectivas precisam ser aplicadas ou
novas perspectivas podem ser sugeridas as perguntas não precisam ser feitas do jeito que foram sugeridas Novas Novas perguntas ou novas de verificação podem ser produzidas então ah as perspectivas elas podem ser adaptadas de acordo com o projeto as perspectivas e as listas de verificação então por exemplo na área de saúde um regulador ele eh seria uma perspectiva bastante adequada porque ele pode verificar se os requisitos estão em conformidade com as normas sanitárias e de proteção de dados científicos sensíveis já em projeto financeiro ah a perspectiva de um de um auditor é bastante importante porque ele
Pode garantir que os requisitos atendam aos padrões de segurança e de conformidade ã no caso de sistemas críticos de segurança então a perspectiva do projetista ela Pode garantir que os requisitos considera as melhores práticas de arquitetura levando em consideração que haja alta disponibilidade e integridade do sistema se for eh se o objetivo é desenvolver um software para dispositivos móveis então a perspectiva do desenvolvedor pode revisar se os requisitos Realmente são adequados para garantir Bom desempenho e experiência de usuário nas diversas plataformas e condições de uso isso são exemplos então para cada eh tipo de projeto
H as perspectivas determinadas perspectivas podem ser selecionadas e adaptadas o mesmo valendo para as listas de verificação inclusive novas perspectivas e novas listas de verificação podem ser criadas agora nós vamos falar também sobre as desvantagens dessa técnica as desvantagens principais são complexidade custo elevado sobrecarga de trabalho demanda por expertiz diversificada tempo de execução prolongado e possível redundância na descoberta de anomalias vamos falar um pouquinho sobre cada uma delas com relação à complexidade bom Como já foi visto a técnica exige que o artefato seja analisado sobre diversas perspectivas no mínimo três então isso pode tornar o
processo de verificação mais complexo pode exigir um esforço adicional para que seja compreendido ou que seja abordado cada ponto de vista e também obviamente isso impacta no tempo e no custo para a inspeção bom com relação a custo elevado tá associado à complexidade Então como e vocês perceberam a cada perspectiva faz uma análise detalhada dos erros levando dos erros não do artefato considerando osos objetivos da perspectiva bom e como são várias perspectivas isso torna muitas vezes o processo caro principalmente levando em consideração que é preciso selecionar pessoal com conhecimento para revisar os requisitos sobre diferentes
aspectos Então não é uma técnica barata sobrecarga de trabalho às vezes quando a equipe de inspeção é pequena muitos inspetores têm que aplicar a técnica diversas vezes utilizando perspectivas diferentes então isso pode levar à fatiga da equipe e aumentar as chances de erros humanos Ou seja que ã erros não sejam identificados com relação à demanda por expertiz diversificada como é necessário aplicar várias técnica várias perspectivas e cada perspectiva exige conhecimentos diferentes então a a equipe tem que ser formada por profissionais com esses conhecimentos então Isso inclui conhecimentos técnicos conhecimentos regulatórios conhecimentos de usabilidade etc então
se eu não conseguir pessoas com conhecimento AD para as perspectivas que eu preciso analisar o documento então a qualidade da análise pode ser prejudicada tempo de execução prolongado bom são muitas perspectivas e as perspectivas elas fazem uma análise profunda então Isso pode impactar no cronograma do projeto então quando o cronograma ele é muito rígido ou ele é muito pequeno ele não não é não tem um prazo o prazo é curto Então essa técnica pode não ser adequada o impacto no no cronograma pode ser eh forte e pode ser eh proibitivo para situações em que o
cronograma eh é muito restrito possível redundância na descoberta de anomalias isso já foi falado vocês poderão podem ter percebido que H várias perguntas em perspectiva diferentes apresentavam algumas semelhanças então eventualmente pode haver redundância na descoberta de erros de anomalias de problemas então duas ou mais perspectivas podem encontrar o mesmo erro então algumas perguntas elas podem se repetir podem se podem se se sobrepor podem ser parecidas em diversas perspectivas isso pode produzir resultados redundantes e por consequência desperdício de tempo e recurs Bom agora vamos falar quando se deve usar a técnica de leitura baseada em perspectiva
bom Como já foi visto essa é uma técnica muito poderosa uma técnica abrangente uma téc uma técnica Ampla que analisa o documento considerando várias perspectivas vários aspectos Então ela encontra muitos erros porém ela é cara ela é demorada e exige muitos recursos em termos de pessoas com conhecimentos diferentes Então ela é mais adequada em situações em que o projeto ele tem uma complexidade maior tem um conjunto de riscos Associados a ele que justificam esse esforço esse investimento para garantir a qualidade dos requisitos então em projeto Por exemplo essa técnica deve ser aplicada em projetos críticos
ou de alta complexidade como por exemplo sistemas dos quais dependem de vidas humanas então sistemas de controle de aeroporto sistemas de controle hospitalar sistemas que envolvem equipamentos sensíveis por exemplo até sistema equipamentos que possam servir para operações ou que possam causar acidentes sistemas para controle de usinas hidrelétricas termoelétricas ou nucleares sistemas financeiros sistemas que H são altamente dependentes de proteção contra evasões sistemas com alto nível de exigência em desempenho com fiabilidade escalabilidad sistemas militares ou que impactem na segurança nacional outras situações projetos com múltiplas partes interessadas quando se trata de sistemas integrados que vão ser
utilizados por grandes corporações ou plataformas que envolvam uma grande quantidade de setores de um governo de organização projetos regulados por normas estritas então softwares para setores como o da Saúde como setores financeiros ou como setor militar Como já foi falado em que os requisitos eles precisam ser rigorosos em termos de eh seguirem estarem de acordo com padrões também ah em projetos de maturidade alta para empresas que buscam certificação ou que estão no nível 13 desejam subir num modelo de maturidade como cmmi ou msbr então essa técnica é útil para garantir que processos e requisitos eles
sejam bem documentados que eles possam ser auditáveis que estejam em conformidade com os padrões de qualidade exigidos para certificação por exemplo e também projetos com elevadas exigências de qualidade na verdade também corresponde aos outros exemplos Mas então softwares que exigem um nível elevado de robustez escalabilidade e desempenho com por exemplo aplicações bancárias que leva em consideração também a questão de proteção plataformas de comércio eletrônico de grande escala que também tem bastante que ã dependência de proteção e confiabilidade ou sistemas de telecomunicações entre outros exemplos então nós terminamos mais essa técnica de leitura eu espero que
vocês tenham considerado esse essa aula útil se vocês gostaram dessa aula eu peço que vocês curtam esse vídeo compartilh com quem possa ter interesse e se ainda não estão inscritos eu peço que se inscrevam no canal obrigado pela atenção nós nos vemos nas próximas aulas
