Pular para conteúdo

Planejamento da Verificação da Etapa 3

Introdução

A verificação é uma abordagem metódica para avaliar e garantir a qualidade de um produto de software, assegurando que ele atenda às especificações e requisitos elicitados1.

Neste artefato, planejaremos o processo de verificação dos artefatos desenvolvidos pelo Grupo 02 para o aplicativo Carteira de Trabalho Digital. O objetivo é garantir que todos os componentes desenvolvidos estejam em conformidade com os requisitos estabelecidos. Isso assegura que a plataforma ofereça uma experiência robusta e alinhada às expectativas dos usuários finais. É importante citar que essa verificação em momento nenhum busca diminuir os membros do Grupo 2 ou seu trabalho, apenas aplicar os conceitos de verificação nos artefatos.

Metodologia

A metodologia que utilizaremos será a de inspeção, que é aplicada para a verificação de documentos, pois seu objetivo principal é a descoberta de "defeitos" nos mesmo2. Será utilizado uma espécie de checklist, parte da análise estática, onde não há execução do produto1. Avaliaremos cada entrega com base nos artefatos desenvolvidos, utilizando checklists detalhados para garantir que todos os aspectos do projeto estejam cobertos. Isso nos permitirá verificar se todos os itens estão definidos e completos, e se não há ausência de dados ou especificações importantes.

Utilizaremos de referência as listas de verificação da disciplina que foram especificadas pelos monitores e o feedback dos outros grupos, fornecidos durante as apresentações.

Essa abordagem sistemática nos ajudará a identificar lacunas ou inconsistências nos artefatos, assegurando que todos os requisitos sejam atendidos de maneira completa e precisa. O uso de checklists proporciona uma maneira estruturada e repetível de conduzir a verificação, facilitando a detecção de problemas e garantindo que as entregas estejam alinhadas com as expectativas e padrões de qualidade definidos. Ao final de cada avaliação, compilaremos os resultados e destacaremos as correções necessárias para manter a integridade e a qualidade do projeto.

Características da Verificação dos Artefatos

Os responsáveis pela criação do planejamento da verificação da entrega 03 seram os integrantes do Grupo 01 - Luiz Gustavo e João Artur. A tabela 1 descreve as caraterísticas sobre como irá proceder as verificações dos documentos referente aos artefatos da primeira entrega:

Tabela 1 - Caracteristicas das Verificações dos Artefatos.

Entrega referente Nome do Artefato Versão do artefato Responsável pelo Desenvolvimento do Artefato Responsável pela Verificação do Artefato
Entrega 03 Cenários 2.5 Breno, Bruno, Caio, Iago, Larissa, Luana e Pedro Arthur Alves, Eric Silveira, Diego Sousa, Douglas Marinho, Henrique Torres, João Artur e Luiz Gustavo
Entrega 03 Léxicos 1.7 Breno, Bruno, Caio, Iago, Larissa, Luana e Pedro Arthur Alves, Eric Silveira, Diego Sousa, Douglas Marinho, Henrique Torres, João Artur e Luiz Gustavo
Entrega 03 Caso de Uso 2.8 Breno, Bruno, Caio, Iago, Larissa, Luana e Pedro João Artur, Diego Sousa e Luiz Gustavo, Henrique Torres
Entrega 03 Especificação Suplementar 1.9 Breno, Bruno, Caio, Iago, Larissa, Luana e Pedro Henrique Torres

Fonte: Luiz Gustavo.

Os resultados obtidos após as verificações serão exibidos na respectiva guia destacadas a seguir:

Checklists

Os checklists são uma ferramenta essencial de verificação, ajudando a identificar defeitos ou características ausentes no projeto. Esses checklists asseguram a consistência, completude e conformidade dos artefatos com os requisitos estabelecidos, promovendo a qualidade e a integridade do projeto.

Baseando-se na padronização dos repositórios da disciplina e dos artefatos, o integrante do grupo 01, Eric Silveira, elaborou um checklist geral, que deve ser aplicado a todos os artefatos desenvolvidos pela equipe ao longo do projeto. A tabela 2 a seguir apresenta as verificações gerais para todos os artefatos incluídos no projeto:

Tabela 2 - Checklist geral dos artefatos.

ID Descrição Avaliação Observações
1 O artefato possui uma introdução descrevendo-o?
2 O artefato possui padronização nos títulos?
3 O artefato, caso contenha tabelas, as referencia no texto?
4 O artefato, caso tenha figuras, as referencia no texto?
5 O artefato possui a fonte das figuras, tabelas e outras aspectos que necessitem da mesma?
6 O artefato possui bibliografia e/ou referência bibliográfica?
7 O artefato chama as referências bibliográficas presentes de forma correta no texto?
8 O artefato possui um histórico de versão padronizado apresentando as versões, datas, datas de revisão, descrição, responsáveis e revisores?

Fonte: Eric Silveira.

Cenários

Tabela 3 - Checklist para Cenários.

ID Descrição Avaliação Observações Explicação e Referêcia
9 Os cenários possuem os elementos básicos de um cenário (Título, Metas, Objetivo, Contexto, Atores, Recursos, Exceção e Episódios)? A verificação de que os cenários possuem os elementos básicos é fundamental para a clareza dos requisitos de software. Cada elemento desempenha um papel específico e indispensável na definição e compreensão dos cenários3.
10 O título é claro, descritivo e reflete o objetivo principal do cenário? Um título claro e descritivo ajuda a identificar rapidamente o cenário, facilitando a comunicação entre os membros da equipe e a referência em documentos futuros3.
11 A meta/objetivo do cenário está claramente definida? Definir claramente as metas/objetivos assegura que todos os envolvidos compreendam o propósito do cenário e possam avaliar se os requisitos atendem às necessidades3.
12 O contexto inicial do cenário está claramente descrito? Descrever o contexto inicial garante que todas as condições pré-existentes e suposições sejam compreendidas, proporcionando uma base sólida para a interpretação correta do cenário3.
13 Todos os atores envolvidos e suas respectivas responsabilidades no cenário estão identificadas? Identificar todos os atores e suas responsabilidades assegura que todas as interações necessárias sejam consideradas, evitando lacunas na definição dos requisitos3.
14 Os recursos necessários para a execução do cenário estão listados? Listar os recursos necessários previne a falta de elementos críticos durante a execução do cenário, garantindo que todos os pré-requisitos técnicos e materiais estejam disponíveis3.
15 Todas as possíveis exceções e situações anômalas estão identificadas? Identificar possíveis exceções e anomalias permite planejar respostas adequadas, aumentando a robustez do sistema e a capacidade de lidar com imprevistos3.
16 Os episódios (etapas) do cenário estão descritos em uma sequência lógica? Descrever os episódios em sequência lógica facilita a implementação e validação do cenário, garantindo que todos os passos necessários para alcançar o objetivo sejam seguidos corretamente3.

Fonte: Luiz Gustavo.

Léxicos

De acordo com Sayão e Carvalho (2006)4, Léxicos são ferramentas que auxiliam no entendimento entre clientes, usuários e profissionais de software ao registrar termos e símbolos do domínio da aplicação. Os léxicos, garantem uma compreensão comum dos termos técnicos e específicos, minimizando interpretações diversas. Construir um léxico envolve a identificação de atores, recursos, verbos e estados relevantes, facilitando a comunicação e consulta durante o desenvolvimento de software.

Tabela 4 - Checklist para Léxicos.

ID Descrição Avaliação Observações Explicação e Referêcia
9 O Léxico Ampliado da Linguagem foi adotado na construção dos léxicos? O Léxico Ampliado da Linguagem, ou LAL, é uma forma mais elaborada de registro de termos próprios do domínio da aplicação, fornecendo mais informações que simplesmente a definição de um termo5
10 Os símbolos possuem noção e impacto? Símbolos do LAL possuem noção e denotação. A noção de um símbolo é o que o define, e a denotação registra os impactos que o símbolo provoca ou recebe no domínio considerado 6
11 Caso seja do tipo Estado, as definições de noção e de impacto se encaixam com o que é descrito? Estado: o que indica e ações que levaram a esse estado6
12 Caso seja do tipo Verbo, as definições de noção e de impacto se encaixam com o que é descrito? Verbos registram ações ou funcionalidades a serem desempenhadas pelos sujeitos ou pelo sistema em desenvolvimento, com algum impacto ou reflexo no ambiente operacional.6
13 Caso seja do tipo Objeto, as definições de noção e de impacto se encaixam com o que é descrito? Objetos são entidades passivas utilizadas ou necessárias a uma ação ou conjunto de ações, e estados são caracterizados por atributos significativos que registram valores em diferentes momentos da execução do sistema6
14 O artefato possui um léxico relacionado aos usuários? Sujeitos correspondem a entidades ativas, atores com papel relevante para a aplicação; um sujeito pode ser um ator, um componente ou um outro sistema com o qual deverá ocorrer interação6
15 A descrição dos léxicos é coerente? O léxico não é apenas uma exigência de processos de qualidade, mas se constitui também em fonte de consulta para os participantes do processo de requisitos7
16 O vocabulário foi apropriadamente adotado nas descrições? Os termos a serem inseridos num glossário são aqueles utilizados pelos participantes do processo para fazer referências às características da aplicação, visando facilitar o entendimento entre eles6

Fonte: João Artur.

Caso de Uso

Segundo Barbosa e Silva no livro Interação Humano-Computador8, o diagrama de casos de uso é uma representação visual que descreve as interações entre um sistema e seus usuários externos, destacando as principais funcionalidades do sistema e como os usuários as utilizam.

Tabela 5 - Checklist para Caso de Uso.

ID Descrição Avaliação Observações Explicação e Referêcia
9 As elipses representam as ações caso de uso? Na UML, um caso de uso é representado como uma figura oval9
10 O caso de uso representa o usuário e suas interações com o sistema? Casos de Uso modelam um diálogo entre um ator e o sistema. Eles representam a funcionalidade fornecida pelo sistema 9
11 O usuário reside fora das fronteiras da aplicação? Atores não são parte do sistema - eles representam algo ou alguém que deve interagir com o sistema 12
12 O caso de uso produzido é uma funcionalidade completa que entrega algum valor? Um caso de uso tipicamente representa uma peça maior de funcionalidade que está completa do início ao fim. Um caso de uso deve fornecer algo de valor para um ator9
13 Existem fluxos como: principal, alternativo e de exceção? O fluxo de eventos para um caso de uso é uma descrição dos eventos necessários para atingir o comportamento esperado do caso de uso. O fluxo de eventos é escrito em termos do que o sistema deveria fazer, não como o sistema o faz11
14 Os fluxos principais representam como usuário usaria a funcionalidade de forma primária? Cada sistema normalmente tem um Diagrama de Caso de Uso principal, o qual é uma representação da fronteira do sistema (atores) e a maior funcionalidade fornecida pelo sistema (casos de uso)10
15 A fronteira do sistema é apresentada? Cada sistema normalmente tem um Diagrama de Caso de Uso principal, o qual é uma representação da fronteira do sistema (atores) e a maior funcionalidade fornecida pelo sistema (casos de uso)10
16 Os relacionamentos "include" são representados nos casos de uso? Muitos casos de uso podem compartilhar pedaços de pequenas funcionalidades. Esta funcionalidade é colocada em separado em outro caso de uso ao invés de ser documentada em cada caso de uso que precisa dela. Relacionamentos de "include" são criados entre um novo caso de uso e qualquer outro caso de uso que utilize esta funcionalidade13
17 Os relacionamentos "extend" são representados nos casos de uso? Um relacionamento de "extend" é usado para mostrar: comportamento opcional,comportamento que somente é executado sobre determinadas condições, como o disparo de um alarme, muitos diferentes caminhos que podem ser executados de acordo com uma seleção feita por um ato13

Fonte: João Artur.

Especificação Suplementar

Tabela 6 - Checklist para Especificação Suplementar.

ID Descrição Avaliação Observações Explicação e Referêcia
9 Os requisitos não funcionais, como desempenho, confiabilidade e usabilidade, estão bem especificados? Garante que o sistema atenda a padrões de qualidade e desempenho esperados, além de requisitos legais e de segurança14.
10 As restrições de design, incluindo limitações técnicas e de conformidade, estão claramente descritas? Ajuda a orientar as decisões de design e implementação, assegurando a conformidade com padrões e regulamentos14.
11 O artefato segue o modelo FURPS+? O modelo FURPS+ (Funcionalidade, Usabilidade, Confiabilidade, Desempenho, Suporte + requisitos adicionais) é uma estrutura amplamente reconhecida para a especificação de requisitos de software. Seguir este modelo assegura uma cobertura abrangente dos diferentes aspectos de qualidade do software, permitindo uma análise detalhada e organizada dos requisitos14.
12 O documento especifica o tempo de resposta, no Desempenho? Especificar o tempo de resposta é crucial para definir expectativas claras sobre o desempenho do sistema. O tempo de resposta afeta diretamente a experiência do usuário e a eficiência operacional do sistema14.
13 O documento especifica qual plataforma o aplicativo pode ser executado? Especificar a plataforma de execução é fundamental para garantir a compatibilidade, otimização, planejamento eficaz, testes adequados e conformidade regulatória, todos essenciais para o sucesso do desenvolvimento e implantação do aplicativo14.
14 O documento aborda sobre a manutenção do sistema? Facilita futuras atualizações e correções, garantindo que o sistema possa ser mantido e melhorado com eficiência14.
15 Os requisitos físicos estão bem especificados? Os requisitos físicos garantem que o software não apenas funcione conforme o esperado, mas também que a implementação e operação sejam viáveis e eficientes14.

Fonte: Luiz Gustavo.

Referência Bibliografica

1. Gerência e Qualidade de Software - Aula 05 - Verificação e Validação. UNIVESP. Disponível em: https://www.youtube.com/watch?v=1Y-1zz6rZxo&t=205s. Acesso em: 07 de junho de 2024.

2. SERRANO, Milene. SERRANO, Maurício. Apresentação: Requisitos - Aula 23. Página 19.

3. Cenários. Disponível em: http://www-di.inf.puc-rio.br/~julio/bnncap3.pdf. Acessado em: 09 de junho de 2024.

4. SAYÃO, Miriam, CARVALHO, Gustavo. Construção do léxico de aplicações. Information and Human Language Technology, 4th Workshop, Ribeirão Preto, 2006.

5. SAYÃO, Miriam, CARVALHO, Gustavo. Construção do léxico de aplicações, Tópico 2.1 LAL - Léxico Ampliado da Linguagem. Information and Human Language Technology, 4th Workshop, Ribeirão Preto, 2006.

6. SAYÃO, Miriam, CARVALHO, Gustavo. Construção do léxico de aplicações, Tópico 2. O processo de requisitos e léxicos. Information and Human Language Technology, 4th Workshop, Ribeirão Preto, 2006.

7. SAYÃO, Miriam, CARVALHO, Gustavo. Construção do léxico de aplicações, Tópico 1. Introdução. Information and Human Language Technology, 4th Workshop, Ribeirão Preto, 2006.

8. Barbosa, S. D. J.; Silva, B. S. da; Silveira, M. S.; Gasparini, I.; Darin, T.; Barbosa, G. D. J. (2021) *Interação Humano-Computador e Experiência do usuário Autopublicação. ISBN: 978-65-00-19677-1.

9. PIMENTEL, Andrey R. Projeto de Software Usando a UML, Tópico 3.4. CASOS DE USO. Paraná, 2007.

10. PIMENTEL, Andrey R. Projeto de Software Usando a UML, Tópico 3.5. DIAGRAMAS DE CASO DE USO. Paraná, 2007.

11. PIMENTEL, Andrey R. Projeto de Software Usando a UML, Tópico 4.2 A ESPECIFICAÇÃO DE UM CASO DE USO. Paraná, 2007.

12. PIMENTEL, Andrey R. Projeto de Software Usando a UML, Tópico 3.3. ATORES. Paraná, 2007.

13. PIMENTEL, Andrey R. Projeto de Software Usando a UML, Tópico Aula 5 RELACIONAMENTOS ENTRE CASOS DE USO . Paraná, 2007.

14. Exemplo: Especificação Suplementar do MINISTÉRIO DA CIÊNCIA, TECNOLOGIA, INOVAÇÕES E COMUNICAÇÕES. Disponível em: https://aprender3.unb.br/pluginfile.php/2845018/mod_resource/content/2/SiglaProjeto_EspecificacaoSuplementar.pdf. Acesso em: 10 de junho de 2024.

Bibliografia

1. Gerência e Qualidade de Software - Aula 05 - Verificação e Validação. UNIVESP. Disponível em: https://www.youtube.com/watch?v=1Y-1zz6rZxo&t=205s. Acesso em: 07 de junho de 2024.

2. SERRANO, Milene. SERRANO, Maurício. Apresentação: Requisitos - Aula 23.

3. GOIS, Samily. SOBRINHO, Francisco. Projeto de Software Floricultura Beija-Flor - Especificação Suplementar, 2012. Disponível em: https://aprender3.unb.br/pluginfile.php/2845019/mod_resource/content/1/Especificacao_Suplementar_Exemplo.pdf. Acesso em: 10 de junho de 2024.

Histórico de Versão

Versão Data Data Prevista de Revisão Descrição Autor(es) Revisor(es)
1.0 07/06/2024 08/06/2024 Criação do documento com Introdução, Metodologia, Características da Verificação dos artefatos e Checklists Luiz Gustavo Eric Silveira, João Artur e Arthur Alves
1.1 09/06/2024 09/06/2024 Adição da tabela de checklist para os cenários Luiz Gustavo Eric Silveira, João Artur e Arthur Alves
1.2 09/06/2024 09/06/2024 Adição da tabela de checklist para os Léxicos e o Caso de Uso João Artur Luiz Gustavo
1.3 10/06/2024 10/06/2024 Adição da tabela de checklist para especificação suplementar e padronização das tabelas Luiz Gustavo João Artur