Arquitetura do Sistema

• Fluxograma de funcionamento do aplicativo
• Git Branching Model
• Próximos artefatos

Fluxograma de funcionamento do aplicativo

Este fluxograma é referente à aplicação mobile que tem como principal função a coleta do tempo das atividades.

Perceba que num primeiro momento estamos abstraindo o fluxo de inserção de dados, considere que estes já estarão disponíveis na API. Nossa prioridade é o desenvolvimento do App (Android e IOS) para coleta de tempos, para que posteriormente possamos dedicar tempo para as tarefas administrativas (Cadastrar Hospitais, Cadastrar Processos - que contém atividades -).

É possível notar que não é necessário login para o uso de funcionários e bolsistas, estes só precisam identificar o respectivo hospital, para que sejam vinculados os processos e atividades referentes à sua função. A identificação do paciente é apenas para identificar e diferenciar possíveis processos parecidos sendo realizados ao mesmo tempo. Esta identificação deve ser feita de forma que facilite o máximo possível o atendimento. Possíveis identificações: Iniciais do paciente, Código do atendimento do paciente no hospital ou outro. (Esta identificação deve ser informada no momento no fluxo apresentado).

Git Branching Model

O modelo de gestão das branches do Git é baseado no Git Flow "trandicional" com adaptações. Não é previsto o uso de branches hotfix/*, uma vez que na AGES não há situações onde um ajuste do produto entregue será integrado antes do final da sprint corrente.

O desenvolvimento nos repositórios app e api deve seguir o fluxo de Git aqui definido:

• uma branch master com o código atualmente em produção;
• uma branch develop com o código em desenvolvimento, com funcionalidades finalizadas mas ainda em fase de testes para validação;
• feature branches para tasks relacionadas às user stories a serem desenvolvidas. Uma branch de task deve ser nomeada com o número único da task, seguida da breve descrição da task (por exemplo, feature/t06-login ou feature/t24-reports-ui);
• quando uma feature é finalizada, um PR da branch feature/ relacionada é aberto com destino à branch develop.

O código da develop é integrado com a master ao final da sprint, após validação dos stakeholders do que foi desenvolvido.

Dessa forma, o fluxo usual de trabalho é o seguinte:

1. antes de iniciar o desenvolvimento de uma task, fazer checkout para a branch develop e pegar as últimas atualizações (pull);
2. criar uma branch para a task com o ID da task (feature/tXX-YYYYY);
3. "enviar" a branch para o remoto (git push -u origin feature/tXX-YYYYY);
4. desenvolver, commitar mudanças e atualizar o remoto (push);
5. voltar para o item 4 até finalizar a task;
6. abrir um PR com destino à branch develop;
7. mover o card da task no Trello para a lista Code Review e avisar no Slack (canal #code-review) que a task está pronta para review;
8. fim! 😃

Próximos possíveis artefatos:

• Segurança
• Rotas de Backend (Arquitetura funcional)
• Objects – Backend API
• Methods – Backend API
• Arquitetura - Não Funcional
• Diagrama de Pacotes / Componentes (Arquitetura de software)
• Diagrama de Deploy
• Documentação sobre aplicação de Design do Projeto
• Análise dos principios SOLID
• Plano de code review

Devem ser apresentados das seguintes formas:

• Imagens ou Gifs
• Diagramas ou Sistemas
• Descrições ou textos explicativos