Sprint 5
O sprint 5 nada mais é do que a consolidação de tudo o que foi feito até então. As entregas estão divididas em:
- Documentação; e
- Prova de conceito.
1. Documentação
Registro do processo de desenvolvimento dos artefatos da sprint. Os itens obrigatórios para uma boa documentação são:
- Manter uma qualidade textual adequada, sem cometer erros graves de português e nem utilizar uma linguagem completamente inadequada.
- Apresentar de forma clara as instruções para execução do projeto. Esse item é importante para que o parceiro consiga utilizar sua solução.
- Descrever a metodologia de desenvolvimento do projeto. Aqui deve ficar claro quais foram as principais decisões de desenvolvimento e como vocês implementaram o sistema. Pense que o cliente pode decidir integrar o projeto de vocês no sistema dele e isso só é possível se ele for capaz de compreender completamente como o sistema foi construído.
1.1. Padrão de entrega
O padrão de entrega do artefato inclui requisitos essenciais para a conclusão da atividade. Embora não seja atribuída uma pontuação direta para cada item, o não cumprimento pode resultar em uma redução da nota ou, em casos extremos, na rejeição total do artefato entregue. Atenção é crucial.
- O texto desenvolvido pelo grupo deve estar disponível em uma página estática
gerada pelo framework Docusaurus. A estrutura do repositório deve incluir um
diretório denominado
docs, que servirá como raiz para o Docusaurus. - A documentação da sprint 4 deve ser composta e organizada integralmente na
seção
Sprint 4. Cada artefato e sua respectiva descrição devem estar contidos em uma página ou subseção dentro desta seção. - As figuras utilizadas na documentação devem ser claramente referenciadas e descritas no texto para garantir uma conexão visual e contextual clara com o conteúdo documentado.
- Todas as imagens empregadas na documentação devem ser armazenadas dentro do
diretório
docs, especificamente em um subdiretório chamadostatic.
1.2. Padrão de qualidade
1.2.1 Qualidade textual (até 2,0 pontos)
A qualidade textual avalia o conteúdo documentado durante a sprint corrente. Defeitos textuais remanescentes de sprints anteriores também podem ser penalizados pelo professor orientador.
| Atende (1,5 - 2,0) | Quase lá (1,0 - 1,5) | Insuficiente (0,5 - 1,0) | Desalinhado (0,0 - 0,5) |
|---|---|---|---|
| Texto correto, coeso e com fluidez. O grupo demonstrou preocupação em apresentar os conceitos da forma mais didática possível, escolhendo cuidadosamente quando e como utilizar tabelas e imagens. | Texto razoavelmente bem escrito, com poucos problemas de adequação da linguagem ou erros gramaticais. | O texto escrito tem problemas graves de linguagem, apresentando erros gramaticais graves e constantes e/ou apresenta linguagem inadequada para um texto técnico. | Entrega fora de contexto ou não entregou. |
1.2.2 Instruções para execução (até 2,0 pontos)
| Supera (1,75 - 2,0) | Atende (1,25 - 1,75) | Quase lá (0,75 - 1,25) | Insuficiente (0,25 - 0,75) | Desalinhado (0,0 - 0,25) |
|---|---|---|---|---|
| Instruções completas e apresentadas de forma amigável ao usuário. Ficou claro que o grupo considerou genuinamente as dúvidas que podem surgir e a melhor forma de apresentá-las (imagens, vídeos, texto, trechos de código) | Todas as principais ações do usuário foram contempladas no guia de execução do sistema. | As instruções para execução do projeto estão presentes, mas ainda bastante incompletas. O usuário vai precisar procurar informações por fora para conseguir utilizar o sistema. | Instruções escassas ou ausentes, de modo que o usuário não consiga extrair praticamente nada do guia. | Entrega fora de contexto ou não entregou. |
1.2.2 Metodologia (até 6,0 pontos)
| Supera (5,5 - 6,0) | Atende (4,5 - 5,5) | Quase lá (2,5 - 4,5) | Insuficiente (0,5 - 2,5) | Desalinhado (0,0 - 0,5) |
|---|---|---|---|---|
| Não só todas as etapas foram descritas de forma precisa e sem omitir etapas, como ficou claro que o grupo se preocupou em utilizar recursos para facilitar a compreensão da metodologia. Imagens, vídeos, trechos de código foram usados para as partes mais complexas. | Todas as etapas do desenvolvimento foram descritas com precisão e de forma completa. | Quase todas as etapas foram descritas com precisão e de forma completa. No entanto, ainda tem um ou mais etapas mal definidas, de modo que ainda não seja possível reproduzir o projeto apenas com a leitura dessa seção | As etapas de desenvolvimento foram descritas de forma superficial ou incompleta. Falta clareza nos processos e etapas de desenvolvimento. É impossível reproduzir o projeto apenas seguindo as etapas descritas no texto. | Entrega fora de contexto ou não entregou. |
2. Prova de conceito
Nesse artefato, será avaliada a qualidade do protótipo final desenvolvido. Sendo assim, torna-se a avaliar todos os sistemas desenvolvidos.
2.1. Padrão de entrega
O padrão de entrega do artefato exige a completa aderência aos requisitos listados. A falta de cumprimento de qualquer um dos requisitos pode resultar em penalidades na nota ou até mesmo na rejeição total do artefato entregue. É essencial que todos os detalhes sejam meticulosamente seguidos.
- O código-fonte da solução deve estar integralmente disponível no repositório
do grupo no GitHub, na branch
main, dentro de um diretório chamadosrc. Para soluções compostas por múltiplos módulos, estes devem ser organizados em subdiretórios apropriados. - Os testes desenvolvidos para verificar a funcionalidade do código devem
estar disponíveis no diretório
tests. Testes automatizados são preferíveis, mas os procedimentos e resultados de testes manuais devem ser claramente documentados. - As instruções detalhadas para a execução do projeto devem ser facilmente acessíveis na documentação, com um link direto no arquivo README para facilitar a consulta.
- A versão mais recente do projeto deve estar disponível como um release no
GitHub, nomeado adequadamente com a referência à sprint atual, por exemplo,
release-sprint-1. - As principais questões de desenvolvimento abordadas durante a sprint e os resultados dos testes devem ser claramente apresentados durante a revisão com os parceiros do projeto.
2.2. Padrão de qualidade
Para a análise do padrão de qualidade da entrega final do projeto, serão avaliados aspectos de entrega das sprints anteriores. Portanto, espera-se: