Inspeção (Product Backlog)
1. Versionamento
Tabela 1: Versionamento
| Versão | Autor | Alterações | Revisor |
|---|---|---|---|
| 1.0 | Pedro Henrique Nogueira | Criação do Documento | Iago Cabral |
| 1.1 | Pedro Henrique Nogueira | Adição da fonte nas tabelas | Iago Cabral |
Fonte: Grupo 7
2. Introdução
"O Product Backlog é uma lista contendo todas as funcionalidades desejadas para um produto. O conteúdo desta lista é definido pelo Product Owner" Milene Serrano e Maurício Serrano (2017). O Product Backlog costuma ser alterado no decorrer do projeto, é comum que ao longo do tempo mais ideias de funcionalidades sejam pensadas tanto pelo cliente (Product Owner) quanto pelo time de desenvolvimento e é por isso que não é necessário ter o Product Backlog pronto no início do projeto. Através de gráficos e checklist, é possível descobrir as fraquezas existentes no trabalho e facilita a melhoria da qualidade do artefato em questão.
3. Metodologia
O foco da inspeção é que um membro que não fez parte do desenvolvimento do artefato adote a postura de "inspetor" do mesmo, sendo assim foi escolhido o membro Pedro Henrique Nogueira para inspeção e o Matheus Soares para Revisão.
3.1 Corpo da tabela de inspeção
Tabela 2: Corpo da Tabela
| Codigo | Item | Total | Sim | Não | Ocorrência de Erros |
Tipos de erro | Pontos a serem ajustados |
|---|---|---|---|---|---|---|---|
Fonte: Grupo 7
4. Inspeção (Léxico)
4.1 Detecção de Defeitos
Para detecção de defeitos elaborou-se um checklist com a própria ferramenta Mkdown.
Tabela 3: Lista de Checagem
| Código | Item | Total | Sim | Não | Ocorrência de Erros | Tipos de erro | Pontos a serem ajustados |
|---|---|---|---|---|---|---|---|
| 1 | Possui versionamento com versão, descrição, autor e revisor? | 1 | 1 | 0 | 0.00% | ||
| 2 | Possui introdução? | 1 | 1 | 0 | 0.00% | ||
| 3 | Possui explicação da metodologia? | 1 | 1 | 0 | 0.00% | ||
| 4 | Possui referências bibliográficas? | 1 | 1 | 0 | 0.00% | ||
| 5 | As referências estão citadas no artefato | 1 | 0 | 1 | 100% | Omissão | Citar referências no artefato |
| 6 | Possui legenda nas tabelas e figuras? | 3 | 3 | 0 | 0.00% | ||
| 7 | Possui fonte nas tabelas e figuras? | 3 | 0 | 3 | 100% | Omissão | Adiconar fonte nas tabelas e figuras |
| 8 | Há registro do processo? | 4 | 4 | 0 | 0.00% | ||
| 9 | Na rastreabilidade, os requisitos possuem hyperlink para a priorização? | 41 | 0 | 41 | 100% | Omissão | Adicionar hyperlinks entre a rastreabilidade e o documento de priorização |
| 10 | Cada história de usuário tem uma descrição? | 41 | 41 | 0 | 0.00% | ||
| 11 | Cada história de usuário tem um nive de prioridade? | 41 | 41 | 0 | 0.00% |
Fonte: Pedro Henrique Nogueira
Gráfico 1: Ocorrência de Erros
Fonte: Pedro Henrique Nogueira
4.2 Correção de defeitos
O objetivo da desta fase é que o autores relacionados ao Product Backlog estejam cientes do que será corrigido, garantindo que as falhas identificadas sejam eliminadas.
4.4 Acompanhamento
A fim de garantir que as modificações necessárias no Léxico foram feitas em conformidade, o autor e o inspetor são responsáveis por isso. O objetivo do processo de acompanhamento é garantir que o(s) autor(es) do Product Backlog tenha(m) retificado todos os requisitos declarados incompletos e/ou inconsistentes ou os defeitos detectados. - [ ] - Product Backlog Corrigido
Referências
- Product Backlog. Disponivel em: https://requisitos-de-software.github.io/2022.1-TikTok/product-backlog/ . Acesso em: 16 ago. 2022.
- Grafico feito no Canvas. Disponível em: https://www.canva.com/design/DAFJnRbYUp0/znifwgTNFU7acVVRVLuuxA/edit . Acesso em: 16 ago. 2022.