Planejamento da Verificação da Etapa 4
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.
Para estruturar a verificação, será utilizada uma checklist. Inicialmente, serão criadas tabelas contendo o ID e a respectiva pergunta a ser feita para verificar se cada item está implementado no artefato. Além disso, cada pergunta tem uma fonte (quando possível) que indica as referências bibliográficas que fundamentaram sua formulação, proporcionando uma base sólida para que o Grupo 02, no caso de haver correções a serem feitas, possam consultar as fontes.
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
A Tabela 1 apresenta os artefatos da etapa 04, suas respectivas versões e os responsáveis pelo desenvolvimento. Esses itens serão avaliados pelo encarregado da verificação. O responsável pela execução da verificação da entrega 04 será o integrante do Grupo 01 - Arthur Alves.
Tabela 1 - Caracteristicas das Verificações dos Artefatos da Entrega 04.
| Nome do Artefato | Versão Pré-Verificação | Responsável pelo Desenvolvimento do Artefato | Responsável pela Verificação do Artefato | Resultado da Verificação |
|---|---|---|---|---|
| Backlog | 1.2 |
Bruno, Caio e Larissa | Arthur Alves e Eric Silveira | Verificação do Backlog |
| História de Usuário | 1.8 |
Breno, Bruno, Caio, Larissa e Luana | Arthur Alves e Eric Silveira | Verificação da História de Usuário |
| NFR Framework | 1.8 |
Breno, Larissa, Luana e Pedro | Arthur Alves e Eric Silveira | Verificação do NFR Framework |
Fonte: Arthur Alves, Eric Silveira e Henrique Torres.
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 checklists gerais que devem ser aplicados 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.
Backlog
Veja na tabela 3 de verificação que será usada para Backlog.
Tabela 3 - Checklist para Backlog.
| ID | Descrição | Avaliação | Observações | Explicação e Referência | Imagem da Referência |
|---|---|---|---|---|---|
| 9 | O backlog está devidamente priorizado, com os itens mais importantes no topo? | Os itens mais importantes estão no topo para guiar o foco da equipe3. | |||
| 10 | O backlog está acessível e visível para todas as partes interessadas? | Manter o backlog em documentos isolados impede atualizações e visibilidade3. | |||
| 11 | Há justificativas claras para a priorização dos itens do backlog? | Priorização: os itens são ordenados por importância, com base na prioridade do cliente, urgência do feedback e dificuldade de implementação3. | |||
| 12 | As histórias de usuário estão inclusas no backlog? | Incluir todos os tipos de itens de trabalho (por exemplo, histórias de usuário, bugs, dívida técnica) para garantir um planejamento abrangente3. | |||
| 13 | O backlog foi priorizado com o cliente, PO ou persona? | A gestão eficaz do backlog envolve uma revisão regular e priorização com base no feedback de stakeholders, clientes e membros da equipe3. | |||
| 14 | Os temas e os épicos foram descritos? | N/A | N/A | ||
| 15 | Os temas estão em um grau de hierarquia maior e mais amplo que os épicos? | Da mesma forma que as epopéias são feitas de histórias, os temas são feitos de épicos. Os temas oferecem outro nível de organização acima dos épicos. Em muitos casos, um tema compila épicos de diversas equipes para atingir um objetivo muito mais amplo e maior do que qualquer um dos próprios épicos4. | |||
| 16 | Os temas e épicos estão alinhados com os objetivos estratégicos do projeto? | Eles representam objetivos de alto nível que a organização espera alcançar4. | |||
| 17 | Os épicos estão em um grau de hierarquia maior que as histórias de usuário? (Os épicos não devem ter uma narrativa simples) | Uma história é uma narrativa simples; uma série de histórias relacionadas e interdependentes constitui um épico. O mesmo se aplica à gestão do seu trabalho, onde a conclusão de histórias relacionadas leva à conclusão de um épico4. | |||
| 18 | Os épicos foram divididos em histórias menores para facilitar o gerenciamento e a execução? | Dividir um épico em histórias mais práticas ajuda a entender um projeto e a manter o impulso5. |
Fonte: Arthur Alves, Eric Silveira e Henrique Torres.
História de Usuário
Veja na tabela 4 de verificação que será usada para História de Usuário.
Tabela 4 - Checklist para História de Usuário.
| ID | Descrição | Avaliação | Observações | Explicação e Referência | Imagem da Referência |
|---|---|---|---|---|---|
| 19 | As histórias de usuário estão escritas do ponto de vista do usuário final? | Uma história de usuário é uma explicação geral e informal de um recurso de software escrita do ponto de vista do usuário final6. | |||
| 20 | As histórias de usuário articulam como uma funcionalidade de software fornecerá valor ao cliente? | O objetivo de uma história de usuário é articular como uma peça de trabalho fornecerá um valor particular ao cliente6. | |||
| 21 | As histórias de usuário estão descritas em linguagem simples e sem detalhes técnicos? | As histórias de usuário são algumas frases em linguagem simples que descrevem o resultado desejado6. | |||
| 22 | As histórias de usuário são usadas para facilitar a colaboração e a criatividade da equipe? | As histórias ajudam a fornecer uma estrutura focada no usuário para o trabalho diário, o que impulsiona a colaboração, a criatividade e um produto melhor em geral6. | |||
| 23 | As histórias de usuário são acompanhadas por critérios de aceitação claros? | As histórias de usuário devem ter critérios de aceitação claramente definidos6. | |||
| 24 | O “quem”, “o que” e o “por que” estão definidos na história de usuário? | Cada história de usuário inclui uma persona (quem), o que ela quer e por quê6. | |||
| 25 | A participação do cliente e/ou persona na validação das histórias de usuário? | As histórias ajudam a fornecer uma estrutura focada no usuário para o trabalho diário, o que impulsiona a colaboração, a criatividade e um produto melhor em geral. Geralmente, uma história é escrita pelo proprietário do produto, gerente de produto ou gerente de programa e enviada para revisão6. | |||
| 26 | As histórias de usuário seguem algum modelo ou padrão? | Histórias de usuários são frequentemente expressas em uma frase simples, estruturada da seguinte forma: “Como [persona], eu [quero], [para que].” | |||
| 27 | Todos os membros do grupo contribuiram com o artefato? | N/A (Apenas para controle de organização) | |||
| 28 | As histórias de usuário são testáveis? | As histórias devem ser escritas de modo a serem testáveis. A aprovação nos testes prova que uma história foi desenvolvida com sucesso. Se a história não puder ser testada, como os desenvolvedores poderão saber quando terminaram a codificação?7 |
Fonte: Arthur Alves, Eric Silveira e Henrique Torres.
Checklist para Verificação do NFR Framework
Veja na tabela 5 de verificação que será usada para NFR Framework.
Tabela 5 - Checklist para NFR Framework.
| ID | Descrição | Avaliação | Observações | Explicação e Referência |
|---|---|---|---|---|
| 29 | Os requisitos não-funcionais (NFRs) estão claramente definidos e documentados? | É crucial ter NFRs bem definidos para garantir que o sistema atenda às expectativas de qualidade e desempenho8. | ||
| 30 | Os NFRs foram elicitados com a participação de todas as partes interessadas relevantes? | Envolver todas as partes interessadas ajuda a capturar uma visão completa dos requisitos de qualidade8. | ||
| 31 | Os NFRs são mensuráveis e verificáveis? | Para garantir que os NFRs sejam cumpridos, eles devem ser mensuráveis, com critérios claros de aceitação8. | ||
| 32 | Os NFRs foram categorizados adequadamente (e.g., usabilidade, desempenho, segurança)? | Categorizar NFRs ajuda a estruturar e priorizar os requisitos de qualidade8. | ||
| 33 | Existem conflitos entre NFRs diferentes? Se sim, foram documentados e gerenciados? | Identificar e gerenciar conflitos entre NFRs é essencial para evitar problemas de implementação futuros8. | ||
| 34 | Os softgoals foram utilizados para representar NFRs de forma que capturem suas qualidades sutis? | Softgoals são usados para capturar a natureza qualitativa dos NFRs e são refinados em metas mais específicas8. | ||
| 35 | Existe um gráfico de interdependência de softgoals (SIG) para visualizar as relações entre NFRs? | Um gráfico de interdependência ajuda a visualizar como os diferentes NFRs se relacionam e afetam uns aos outros8. | ||
| 36 | As relações de contribuição (positiva ou negativa) entre softgoals foram identificadas? | Entender as contribuições ajuda a balancear trade-offs entre NFRs conflitantes8. | ||
| 37 | As decisões de design foram documentadas em relação aos NFRs? | Documentar decisões de design com base nos NFRs assegura que as escolhas feitas durante o desenvolvimento são justificáveis e rastreáveis8. | ||
| 38 | Há evidências de que os NFRs foram considerados durante todas as fases do ciclo de vida do projeto? | Garantir que os NFRs sejam considerados desde o início até a fase de manutenção é vital para a qualidade do produto final8. |
Fonte: Arthur Alves, Eric Silveira e Henrique Torres.
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 às 21:00.
2. SERRANO, Milene. SERRANO, Maurício. Apresentação: Requisitos - Aula 23. Página 19.
3. RADIGAN, Dan. Product Backlog Explained [+ Examples]. Atlassian, 2023. Disponível em: https://www.atlassian.com/agile/scrum/backlogs. Acesso em: 9 jun. 2024.
4. REHKOPF, Max. Epics, Stories, Themes. Atlassian, 2023. Disponível em: https://www.atlassian.com/agile/project-management/epics-stories-themes. Acesso em: 9 jun. 2024.
5. REHKOPF, Max. Epics. Atlassian, 2023. Disponível em: https://www.atlassian.com/agile/project-management/epics. Acesso em: 9 jun. 2024.
6. REHKOPF, Max. User Stories. Atlassian, 2023. Disponível em: https://www.atlassian.com/agile/project-management/user-stories. Acesso em: 9 jun. 2024.
7. COHN, Mike. User Stories Applied: For Agile Software Development. Boston: Addison-Wesley, 2004. Capítulo 2: Testable, p. 27. Disponível em: https://github.com/free-educa/books/blob/main/books/User-Stories-Applied-Mike-Cohn.pdf. Acesso em: 9 jun. 2024.
8. Chung, L., Nixon, B. A., Yu, E., Mylopoulos, J. Non-functional requirements in software engineering. Springer Science & Business Media: [S.l.], 2000. v. 5. Acesso em: 9 jun. 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 às 20:00.
2. SERRANO, Milene. SERRANO, Maurício. Apresentação: Requisitos - Aula 23.
Histórico de Versão
| Versão | Data | Data Prevista de Revisão | Descrição | Autor(es) | Revisor(es) |
|---|---|---|---|---|---|
1.0 |
09/06/2024 | 10/06/2024 | Criação do documento | Arthur Alves | Eric Silveira e João Artur |
1.1 |
09/06/2024 | 10/06/2024 | Adicionando o checklist de verificação do NFR | Henrique Torres | Eric Silveira e João Artur |