From 1688d97ce89c51f612c536d43754041ecde3a6ae Mon Sep 17 00:00:00 2001 From: DanielRogs Date: Wed, 4 Sep 2024 20:32:55 -0300 Subject: [PATCH] docs: ultimos ajustes MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: JÉSUS GABRIEL --- .../unidade3/VeriVal-PBB-CalorieExplorer.md | 18 ++++++++-- docs/sections/historiasUsuarios/US.md | 34 ++++++++++++++++++- 2 files changed, 48 insertions(+), 4 deletions(-) diff --git a/docs/sections/entregas/unidade3/VeriVal-PBB-CalorieExplorer.md b/docs/sections/entregas/unidade3/VeriVal-PBB-CalorieExplorer.md index 46567b86..3ba26b02 100644 --- a/docs/sections/entregas/unidade3/VeriVal-PBB-CalorieExplorer.md +++ b/docs/sections/entregas/unidade3/VeriVal-PBB-CalorieExplorer.md @@ -1,6 +1,9 @@ # Verificação e Validação - PBB do Projeto Calorie Explorer -Para a fase de verificação, foi utilizado a metodologia de Checklist +# 1. Verificação +A verificação do PBB (Product Backlog Building) para o projeto Calorie Explorer foi conduzida utilizando um checklist para avaliar se todos os elementos fundamentais do Canvas PBB foram atendidos. Entre os pontos verificados, constatou-se que o Canvas PBB está devidamente identificado com o produto, e os problemas e expectativas do cliente foram corretamente listados. Também foram criadas personas, e as ações associadas a essas personas foram mapeadas, incluindo o que fazem atualmente e o que desejam fazer com o sistema. As funcionalidades foram definidas com base nas ações das personas, identificando os problemas que cada funcionalidade resolve e os benefícios que trazem. + +No entanto, durante a verificação, foram observadas algumas inconsistências: o PBI "Fazer atualizações e melhorias" não segue corretamente o modelo ARO, apresentando ausência do objeto, e alguns PBIs foram organizados sem seguir a prioridade estabelecida. Além disso, as histórias de usuário, que deveriam ser derivadas diretamente dos PBIs, não seguiram o modelo de escrita proposto, o que gerou inconsistências na forma como as histórias foram elaboradas em relação aos PBIs originais. Pergunta | Check | Comentários -------- | ----- | ---------- @@ -18,7 +21,10 @@ Foram criadas as histórias de usuário usando o PBI, personas e benefícios | N As histórias de usuários possuem critérios de aceitação | SIM | -- Os PBIs estão organizados verticalmente pelo valor de prioridade | NÃO | As US's foram montadas e receberam o seus códicos sem considerar a ordem de prioridade estabelecido nos PBIs. -Para a validação, também utilizamos o checklist, porém aqui avaliamos a qualidade de cada um dos itens desenvolvidos. +## 2. Validação +A validação do PBB envolveu uma análise detalhada da qualidade e coerência de cada item desenvolvido, comparando-os com o contexto do estudo de caso HealthNet. Os problemas e expectativas identificados foram considerados apropriados e relevantes, assim como as personas e suas atividades. As funcionalidades criadas foram bem associadas às personas e apresentaram um nível adequado de granularidade. No entanto, foi identificado que, em alguns casos, os benefícios descritos para as funcionalidades não eram suficientemente específicos, abrangendo vantagens que poderiam se aplicar a múltiplas funcionalidades, o que comprometeu a clareza. + +Adicionalmente, observou-se que as User Stories não estavam alinhadas ao modelo padrão de escrita, que envolve a estrutura "Eu, como [persona], posso [ação], para [valor de negócio]". Além disso, os critérios de aceitação, embora relevantes, foram redigidos de maneira inadequada, apresentando a visão das personas como executoras dos critérios, o que dificulta a compreensão das condições necessárias para o funcionamento da User Story. A reformulação dos critérios para um formato mais imparcial e padronizado é necessária para melhorar a qualidade das validações. Pergunta | Check | Comentários -------- | ----- | ---------- @@ -35,4 +41,10 @@ Os PBIs são coerentes com as funcionalidades com a qual estão associados | SIM Os PBIs foram escritos com o mesmo modelo (Estão padronizados) | SIM | -- As USs estão estruturadas no formato: "Eu, como [persona], posso [ação], para [valor de negócio]" | NÃO | Nenhuma das User Story seguem o modelo de escrita. Os critérios de aceitação estão coerentes com a US a qual estão associados | SIM | -- -Os critérios de aceitação informam apenas as condições para a US funcionar | NÃO | Os critérios de aceitação foram escritos como se as personas realizassem os critérios. Deverá ser feito pensado em qualquer usuário. \ No newline at end of file +Os critérios de aceitação informam apenas as condições para a US funcionar | NÃO | Os critérios de aceitação foram escritos como se as personas realizassem os critérios. Deverá ser feito pensado em qualquer usuário. + + +## Histórico de Versão: +Data | Versão | Descrição | Autor | Revisores +---- | ------ | --------- | ----- | --------- +04/09/24 | 1.0 | Criação do documento | Daniel Rodrigues | Jésus Gabriel \ No newline at end of file diff --git a/docs/sections/historiasUsuarios/US.md b/docs/sections/historiasUsuarios/US.md index 21b814bf..111964f9 100644 --- a/docs/sections/historiasUsuarios/US.md +++ b/docs/sections/historiasUsuarios/US.md @@ -56,7 +56,7 @@ F06 | EP04 | Autenticação e Cadastro de Conta Para a produção do sistema RISo, foram identificadas 11 User Stories, que descrevem as funcionalidades a serem desenvolvidas do ponto de vista dos usuários. Nº | Título | História de Usuário --- | ------ | --------- +-- | ------ | ------------------- US01 | Cadastrar e Logar na Conta | Eu como usuário, devo ser capaz de me cadastrar e logar na plataforma, para que eu possa utilizar das funções do software e ter a segurança de meus dados. US02 | Cadastrar Empresa-Unidade | Eu como usuário, devo ser capaz de registrar uma nova Unidade/Empresa, para que os dados obtidos pelo sistema RISO seja acessada apenas pelos associados à esta Unidade/Empresa. US03 | Adicionar Colaboradores | Eu como Administrador da Unidade/Empresa, devo ser capaz de adicionar colaboradores a partir de um código aleatório gerado no ato da criação da Unidade/Empresa, para que mais pessoas possam acompanhar os dados obtido pelo sistema RISO. @@ -69,6 +69,38 @@ US09 | Visualizar gráfico de média de sorrisos por pessoa por dia, semana e m US10 | Visualizar dados de taxas gerais de risos | Eu como usuário e usuário administrador, devo ser capaz de visualizar uma taxa em porcentagem que exibe a quantidade de pessoas capturadas para o levantamentos dos dados no dia e quantas dessas riram, para que eu obtenha dados aprofundados da taxa de sorrisos. US11 | Integrar em uma câmera única no Caixa | O Sistema, deve ser capaz de capturar e realizar o reconhecimento de sorrisos com uma câmera especializada do cliente, para que o sistema RISO seja devidamente aplicado ao contexto do cliente. +Para definir suas prioridades, foi considerado a frequência de uso da US e seu valor de negócio. Ao final é feito o somatório dos dois critérios para se obter a prioridade total: **Prioridade = (Frequência de Uso) + (Valor de Negócio)**. + +User Story | Frequência de Uso | Valor de Negócio | TOTAL +---------- | ----------------- | ---------------- | ----- +US01 | 4 | 3 | 7 +US02 | 1 | 2 | 3 +US03 | 4 | 3 | 7 +US04 | 2 | 1 | 3 +US05 | 2 | 2 | 4 +US06 | 5 | 3 | 8 +US07 | 5 | 3 | 8 +US08 | 4 | 3 | 7 +US09 | 4 | 4 | 7 +US10 | 3 | 2 | 5 +US11 | 5 | 3 | 8 + +Sendo assim, as US's em sua ordem de prioridade é: + +Código da US | Prioridade Total +------------ | ---------------- +US06 | 8 +US07 | 8 +US11 | 8 +US01 | 7 +US03 | 7 +US08 | 7 +US09 | 7 +US10 | 5 +US05 | 4 +US02 | 3 +US04 | 3 + Com base nos Épicos já categorizados, o agrupamento das User Stories em Features, mantendo-as nos respectivos Épicos, ficou da seguinte forma: Código do Épico | Código da Feature | Título da Feature | Código das US Associadas