Home - ArthurSchiavom/gestao-informacao-chao-de-fabrica--projeto-academico GitHub Wiki

Projeto Integrador da LEI-ISEP Sem4 2019-20

1. Constituição do Grupo de Trabalho

O grupo de trabalho é constituído pelo estudantes identificados na tabela seguinte.

Aluno Nr. Nome do Aluno
1180842 Arthur Silva
1170554 Pedro Macieira
1161752 Diogo Almeida
1181477 Francisco Andrade

2. Distribuição de Funcionalidades

A distribuição de requisitos/funcionalidades ao longo do período de desenvolvimento do projeto pelos elementos do grupo de trabalho realizou-se conforme descrito na tabela seguinte.

Sprint B

1181477 - Francisco Andrade - US1004 - Bootstrap de matérias primas

1161752 - Diogo Almeida - US1005 - Bootstrap de categorias de matérias primas

1180842 - Arthur Silva - US1006 - Bootstrap de produtos

1161752 - Diogo Almeida - US1007 - Bootstrap de máquinas

1170554 - Pedro Macieira - US1008 - Bootstrap de linhas de produção

1170554 - Pedro Macieira - US1009 - Bootstrap de depósitos

1181477 - Francisco Andrade - US2001 - Registar matéria prima no catálogo

1161752 - Diogo Almeida - US2002 - Registar categoria de matéria prima

1180842 - Arthur Silva - US2003 - Consultar produtos sem ficha de produção

1180842 - Arthur Silva - US2004 - Especificar ficha de produção

1181477 - Francisco Andrade - US2005 - Registar produto no catálogo

1180842 - Arthur Silva - US2006 - Importar catálogo de produtos

1161752 - Diogo Almeida - US3001 - Registar máquina

1170554 - Pedro Macieira - US3002 - Especificar linha de produção

1170554 - Pedro Macieira - US3003 - Especificar novo depósito

Sprint C

Todos - US1010 - Elaborar um documento XSD para validar a exportação do UC 2007

1180842 - Arthur Silva - US1011 - Simular o funcionamento da máquina

1181477 - Francisco Andrade - US1012 - Pedidos de Monitorização de estado no simulador de máquina

1170554 - Pedro Macieira - US2007 - Exportar para ficheiro XML informação do chão de Fábrica

1161752 - Diogo Almeida - US2009 - Importar Ordens Produção de Ficheiro CSV

1180842 - Arthur Silva - US2010 - Introduzir manualmente uma ordem de produção

1161752 - Diogo Almeida - US2011 - Consultar Ordens de Produção e os detalhes de uma ordem de produção individual

1161752 - Diogo Almeida - US2012 - Consultar Ordens de Produção de uma encomenda

1181477 - Francisco Andrade - US3004 - Associar ficheiro de configuração a uma máquina

1170554 - Pedro Macieira - US3005 - Consultar Notificações de Erros por Tratar

1170554 - Pedro Macieira - US3006 - Arquivar Notificações de Erros de Processamento

1180842 - Arthur Silva - US3007 - Consultar notificações de erros de processamento arquivados

1181477 - Francisco Andrade - US4001 - Importar(de forma concorrente) mensagens em ficheiros de texto para processamento

1161752 - Diogo Almeida - US4002 - Recolha de mensagens gerados por máquinas numa determinada linha de produção

1181477 - Francisco Andrade - US5001 - Efetuar o processamento das mensagens disponiveis

1170554 - Pedro Macieira - US6001 - Monitorizar o estado das máquinas por linha de Produção

Sprint D

1161752 - Diogo Almeida - US1013 - Comunicações entre SCM e máquinas protegidas

1180842 - Arthur Silva - US1014 - Simulador Máquina receber ficheiros de configuração

1180842 - Arthur Silva - US1015 - Comunicações entre SCM e simulador máquina protegido

1181477 - Francisco Andrade - US1016 - Simulador de Máquina fazer reset do estado

1161752 - Diogo Almeida - US1017 - Elaboração de Relatório que descreva o uso de XML, XSD, XSLT, XPATH no sistema

1170554 - Pedro Macieira - US2013 - Visualisação e Transformação do ficheiro XML exportado

1170554 - Pedro Macieira - US3009 - Saber e alterar o estado de processamento de mensagens e a última que foi efetuado

1161752 - Diogo Almeida - US3010 - Solicitar o envio de uma determinada configuração de máquina

1181477 - Francisco Andrade - US5002 - Efetuar o processamento de mensagens no sistema

1170554 - Pedro Macieira - US6002 - Efetuar pedidos de reinicialização

Todos - US9002 - Elaboração de uma apresentação e relatório sobre o trabalho

Diagrama de Casos de Uso

Diagrama de Casos de Uso

Modelo de domínio atualizado

Modelo de Domínio

3. Regras e técnicas

Packages

Vertical slicing.

Issues

  • Atribuir o issue a quem o vai executar.
  • Alterar o estado do issue ao longo do progresso da sua execução.

Nomenclatura de commits

Cada commit deve estar associado a um issue. Formato: Tipo-Fase-Identificador

Exemplos: "UC-D-002: (...)" (use case) "IS-D-002: (...)" (issue não relacionado com use cases específicos)

Tipo

UC - Use Case IS - Issue

Fase

A - Análise

Conversar com o cliente para perceber os seus requisitos e o seu vocabulário. Construir glossário de conceitos. Perceber o contexto do caso de uso e quais os invariantes de domínio. Que tipo de interacção existirá com o utilizador? Que tipo de utilizador pode executar este caso de uso?

De - Design

Criar testes unitários que capturem os invariantes de domínio. Decidir que classes criar, onde as colocar, que responsabilides lhe atribuir, quais as interações existentes entre objetos para realizar o caso de uso.

P - Planeamento de testes

Que casos de testes devem ser efetuados para validar a funcionalidade a entregar ao cliente (funcionalidade end-to-end; testes funcionais manuais)? Que dados de entrada são necessários para os testes? Que (dados de) resultados são esperados em cada caso de teste de acordo com os dados de entrada?

DT - Desenvolvimento e testes

Codificação de acordo com o design e execução de testes de desenvolvimento (unitários e funcionais).

I - Integração

Junção do código na base de código comum do repositório, execução de testes unitários a todo o sistema. Execução dos testes funcionais principais.

Identificador

Número do issue no BitBucket.

Tasks

Apenas fazer assign pós terminar o anterior.

Desenvolvimento

Nomenclatura no código

  • Classes, enums e interfaces: CamelCase com a primeira letra maiúscula.
  • Instâncias de classes: CamelCase com a primeira letra minúscula.
  • Utilizam os nomes definidos no glossário sempre que possível.

Implementação

  • Documentar funções e classes sempre, mas comentar apenas se realmente necessário. Quem lê o código sabe programar e deve entendê-lo sem necessitar de comentários.
  • Identificar dependências entre tarefas e mitigar conflitos. Exemplo: decidir o nome das classes que são partilhadas entre user stories e fazer um commit inicial apenas com o esqueleto dessa classe.
  • Deixar o projeto sempre num estado estável, ou seja, em qualquer momento que se faça pull deve ser possível compilar sem erros e executar todos os testes automáticos a passar.
  • Fazer commmits frequentes para minimizar problemas de integração.