Grupo 15:
- Bleno Humberto Claus
- Giovanni Di Luca Evangelista
- Lucas Gabriel dos Santos
- Mateus Sales Albino
- Wellyson de Freitas Santos
Nosso MVP é uma versão simplificada para fins de demonstração dos requisitos atendidos durante o Hackathon. Compreende um monolito com um banco de dados relacional e uso de serviços serverless na AWS. Toda a infraestrutura descrita em Terraform e a imagem da aplicação são automatizados em nossas pipelines com GitHub Actions, que inclui verificação dos testes e análise estática no SonarCloud.
O MVP inclui:
- documentação abrangente, incluindo de DDD, diagramas C4, etc
- 15 ADRs cobrindo requisitos não funcionais
- pipelines para IaC com Terraform e deploy no Kubernetes
- testes unitários e de integração com Cucumber
- análise estática para qualidade e segurança
- uso de EKS, RDS, S3, VPC, Cognito, ECR, KMS, SSM, etc.
- estimativa de volumetria
- setup para execução local (Docker Compose, Makefile, etc.)
Projeto no SonarCloud: https://sonarcloud.io/project/overview?id=FIAP-3SOAT-G15_healthmed-app
Também criamos uma extensa documentação para suportar uma aplicação escalável e resiliente que atenda a todos os requisitos não funcionais.
Health&Med, uma startup inovadora no setor de saúde, está desenvolvendo um novo sistema que irá revolucionar a Telemedicina no país. Atualmente, a startup oferece a possibilidade de agendamento de consultas e realização de consultas online (Telemedicina) por meio de sistemas terceiros como Google Agenda e Google Meetings.
Recentemente, a empresa recebeu um aporte e decidiu investir no desenvolvimento de um sistema proprietário, visando proporcionar um serviço de maior qualidade, segurança dos dados dos pacientes e redução de custos. O objetivo é criar um sistema robusto, escalável e seguro que permita o gerenciamento eficiente desses agendamentos e consultas.
Além de conter as funcionalidades de agendamento e realização de consultas online, o sistema terá o diferencial de uma nova funcionalidade: o Prontuário Eletrônico. O Prontuário Eletrônico permitirá o armazenamento e compartilhamento de documentos, exames, cartão de vacinas, e outros registros médicos entre as partes envolvidas, garantindo maior assertividade nos diagnósticos.
Para viabilizar o desenvolvimento de um sistema que esteja em conformidade com as melhores práticas de qualidade e arquitetura de software, a Health&Med contratou os alunos do curso (SOAT) para fazer a análise do projeto e a arquitetura do software.
- O sistema deve permitir que o médico faça login usando o número de CRM e uma senha.
- O sistema deve permitir que o médico cadastre e edite os horários disponíveis para agendamento de consultas.
- O médico deve poder aceitar ou recusar consultas médicas agendadas.
- O sistema deve permitir que o paciente faça login usando um e-mail, CPF e uma senha.
- O sistema deve permitir que o paciente visualize a lista de médicos disponíveis, utilizando filtros como especialidade, distância (em kms) e avaliação.
- Após selecionar o médico, o paciente deve poder visualizar a agenda do médico e o valor da consulta, e efetuar o agendamento.
- O usuário paciente poderá cancelar a consulta mediante justificativa.
- A consulta agendada deve criar um link de reunião online de duração padrão de 50 minutos que será utilizado pelo usuário e pelo médico no dia da consulta.
- Acesso e Upload:
- O paciente deve poder acessar seu prontuário eletrônico e fazer o upload de arquivos, como exames e laudos médicos.
- Gestão de Compartilhamento:
- O paciente deve poder compartilhar seu prontuário com médicos, definindo quais arquivos ou grupos de arquivos serão acessíveis e por quanto tempo.
- O sistema deve estar disponível 24/7 devido à sua natureza crítica no setor de saúde.
- O sistema deve ser capaz de lidar com alta demanda, especialmente para profissionais muito procurados.
- O sistema deve suportar até 20.000 usuários simultâneos em horários de pico.
- O prontuário eletrônico deve possuir alta camada de segurança para prevenir falhas no compartilhamento de documentos.
- A proteção dos dados sensíveis dos pacientes deve seguir as melhores práticas de segurança da informação.
Os grupos deverão entregar o seguinte:
- Diagrama da arquitetura que atenda aos requisitos funcionais e justificativas das escolhas técnicas.
- Descrição de como os requisitos não funcionais serão atendidos.
- Mostrando a aplicação funcionando na infraestrutura de nuvem, com exemplos de uso real (como chamadas de API).
- Explicação e demonstração do pipeline de deploy da aplicação.
Aplicação executando na nuvem, os itens de 1 a 6 dos requisitos funcionais, contemplando:
- Autenticação do Usuário (Médico)
- Cadastro/Edição de Horários Disponíveis (Médico)
- Aceite ou Recusa de Consultas Médicas (Médico)
- Autenticação do Usuário (Paciente)
- Busca por Médicos (Paciente)
- Agendamento de Consultas (Paciente)
Itens adicionais que serão diferenciais para a classificação dos grupos:
- Aplicação das melhores práticas de qualidade e arquitetura de software.
- Conhecimento e práticas de desenvolvimento seguro.
- Documentação abrangente de todos os componentes e níveis da solução.
- Automatização do processo de gerenciamento e alteração de infraestrutura.
- usuários: 20.000 usuários simultâneos usando em horários de pico sem problemas na experiência do usuário.
- consultas: 10.000 consultas diárias (2 consultas x 5000 médicos x dia), cada consulta gerando um link de reunião online com duração padrão de 50 minutos, suportando centenas de sessões simultâneas.
- prontuário eletrônico: milhões de documentos variados, de até 100 MB por arquivo.
Architectural Decision Records (ADRs):
- Infraestrutura
- Microserviços
- Bancos de dados
- Estratégia de testes
- CI/CD
- Orquestração de containers
- Observabilidade
- Autenticação e autorização
- Validação de médicos
- Mensageria
- Notificações
- Videoconferências
- Prontuário Eletrônico
- LGPD
- Otimização de rede
Descrição dos workflows do GitHub Actions:
- build.yaml: faz o build da aplicação, executando testes e análise estática.
- destroy.yaml: destrói todos os recursos de infra na AWS.
- docs.yaml: cria o website para a documentação contida em
/docs. - provision.yaml: realiza o provisionamento dos recursos de infra na AWS.
docker compose upmvn clean compile
mvn clean verify
Testes de integração:
mvn clean verify -DskipITs=false
mvn antrun:run@ktlint-format
Acesse localmente:
- UI: http://localhost:8080/swagger-ui/index.html
- JSON: http://localhost:8080/v3/api-docs (baixar .json)
- YAML: http://localhost:8080/v3/api-docs.yaml (baixar .yaml)
Geração da documentação:
mvn -B verify -DskipOpenAPIGen=false