Skip to main content

Artefatos Sprint 5 (Computação)

1. Prova de conceito de infraestrutura para cidades inteligentes​

1.1. Enunciado​

Proposta final apresentada ao parceiro da infraestrutura para cidades inteligentes. O grupo deverá refinar tudo o que foi desenvolvido. Para isso, deve-se seguir os padrões de qualidade anteriores, além das issues registradas pelo orientador nos sprints anteriores.

1.2. Padrão de entrega​

  1. O código fonte da solução deve estar disponível no repositório do grupo no Github (na branch 'main'), em uma pasta denominada 'src'.
  2. Os testes desenvolvidos devem estar disponíveis na pasta 'tests' e, quando possível, aplicados de forma automatizada (e.g., utilizando o Github Actions). Quando não for possível essa integração, deve-se descrever os testes e os resultados em um arquivo markdown dentro da pasta 'tests'.
  3. As instruções para que o parceiro possa executar o projeto devem estar claramente discriminadas na documentação, com um link no README para que a seção possa ser prontamente acessada.
  4. O projeto em seu estado atual deve estar disponível em um release do Github cujo nome deve incluir a numeração da sprint.
  5. As questões centrais de desenvolvimento da sprint e os testes devem ser apresentadas de forma clara durante o review com o parceiro.
  6. As issues abertas pelo orientador no decorrer do projeto somente podem ser fechadas por ele. A condição fundamental para o fechamento de um issue é a existência de ao menos um commit que referencie aquele issue diretamente.

1.3. Padrão de qualidade​

  1. Fechamento adequado das issues de desenvolvimento abertas pelo professor orientador (até 2,5 pontos);
  2. O simulador de dispositivos foi implementado de acordo com os requisitos especificados (até 1,0 pontos);
  3. O broker MQTT foi implementado de acordo com os requisitos especificados (até 1,0 pontos);
  4. O sistema de armazenamento de dados foi implementado de acordo com os requisitos especificados (até 1,0 pontos);
  5. O dashboard desenvolvido atende os requisitos especificados (até 1,0 pontos);
  6. O sistema atende os requisitos de performance e escalabilidade especificados (até 1,0 pontos);
  7. O sistema é funcional e sua execução é possível a partir do release final feito no github (até 2,5 pontos).

2. Documentação​

2.1. Enunciado​

O grupo deverá entregar a versão final da documentação do projeto desenvolvido. Para o refinamento a ser feito na última sprint, deve-se considerar as issues registradas pelo professor orientador no decorrer do projeto.

2.2. Padrão de entrega​

  1. O texto desenvolvido pelo grupo deve estar disponível no repositório do GitHub (branch main), dentro da pasta docs e em formato markdown;
  2. As figuras utilizadas no documento devem sempre ser referenciadas no texto, com descrições textuais que estimulem a coesão entre o que é apresentado visualmente e o restante do texto;
  3. Todas as figuras utilizadas na documentação devem estar salvas dentro da pasta docs, em uma subpasta chamada assets.
  4. As issues abertas pelo orientador no decorrer do projeto somente podem ser fechadas por ele. A condição fundamental para o fechamento de um issue é a existência de ao menos um commit que referencie aquele issue diretamente.

2.3. Padrão de qualidade​

  1. Fechamento adequado das issues de documentação abertas pelo professor orientador (até 2,5 pontos);
  2. O documento deve apresentar os objetivos, metas e requisitos do projeto de forma clara e, quando cabível, quantificável (até 1,0 pontos);
  3. Deve-se apresentar uma descrição detalhada da implementação do sistema, com diagramas UML de sequência e implementação devidamente integrados à explicação textual (até 2,0 pontos);
  4. A documentação deve apresentar a implementação e resultados dos testes de segurança do sistema (até 1,0 pontos);
  5. A documentação deve apresentar a implementação e resultados dos testes de performance e escalabilidade do sistema (até 1,0 pontos);
  6. O documento deve ser coeso, apresentando o desenvolvimento do projeto do começo ao fim de modo que a sua reprodução posterior seja possível (até 1,0 pontos);
  7. O documento deve apresentar de forma clara e acessível as orientações para execução do software desenvolvido (até 1,5 pontos).