[SISTEMA DE TRÁFEGO AÉREO] Claor

1. 1️⃣ Disclaimer

1.1. Nosso case tem elementos reais e elementos fictícios

1.1.1. Vamos assumir os pontos apresentados como premissas verdadeiras para o case

1.2. Não apresentaremos hoje uma solução, ela será construída pelos participantes

1.2.1. Forneceremos os insumos

1.2.2. Forneceremos todo o ambiente de aprendizagem

1.2.3. Forneceremos suporte e revisão de alguns cases escolhidos (dependendo do volume, não de todos)

1.3. Os alunos que entregarem o case no ArcHOne receberão o certificado da ArcH 👊

2. 2️⃣ Nosso desafio

2.1. Definir e validar a arquitetura de software de um sistema de controle de tráfego aéreo

2.2. Será utilizado por 2 aeroportos de grande porte do Brasil

2.3. Deve suportar a integração com informações de outros sistemas de voos online e com a ANAC que fornecerá os planos de voo

2.4. Registro de posições críticas

2.4.1. Posições que precedem ações que requerem autorização da torre de controle (via rádio ou sinal de luz)

2.4.1.1. Posições críticas

2.4.1.1.1. 1- Ponto de espera (estacionamento)

2.4.1.1.2. 2 - Posição de posição de pré-decolagem

2.4.1.1.3. 3 - Posição de decolagem

2.4.1.1.4. 4 - Em voo (permissão para pouso)

2.4.1.1.5. 5 - Posição manobra para ingresso ao estacionamento

2.4.1.1.6. 6 - Posição de estacionamento

2.4.1.2. Registro de todas as solicitações

2.4.1.3. Registro de todas as respostas

2.4.1.4. Registro da altitude, latitude e longitude

2.5. Deve suportar integração com sistema de radares

2.5.1. Estes alimentarão o sistema com dados realtime de aeronaves na área monitorada

2.5.1.1. Incluindo posição geográfica altitude, latitude e longitude

2.6. O plano de voo deve ser disponibilizado com 1 dia de antecedência

2.6.1. Mudanças no plano de voo de qualquer companhia precisam ser atualizados online

2.6.2. Deve haver uma validação do plano de voo

2.6.2.1. Caso haja inconsistência ou risco ou uma janela menor a 10 minutos entre uma aeronave e outra na mesma posição geográfica uma mensagem de risco crítico deve ser reportada a ANAC

2.7. Qualquer problema de atraso ou aeronave não reconhecida ou fora do horário do plano deve ser reportado online a ANAC

2.8. O sistema deve operar 24x7

2.8.1. Indisponibilidades sistêmicas geram multas de elevado valor por minuto offline

3. 4️⃣ O que fazer?

3.1. Com base nas nossas aulas 02 e 03, elaborar o primeiro diagrama de arquitetura da nossa solução

3.1.1. Deve Contemplar

3.1.1.1. A segmentação das camadas

3.1.1.2. As práticas arquiteturais de desenvolvimento

3.1.1.3. Os componentes arquiteturais

3.1.2. Utilizar a área de posts do ArcHOne para postar o seu diagrama

3.1.2.1. O diagrama deve ser feito utilizando o draw.io

3.1.3. Utilizar o chat do evento para discutir a solução em grupo

3.2. As aulas disponibilizadas devem servir como base para o trabalho de definição da arquitetura

4. 3️⃣ Riscos que precisam ser resolvidos pela arquitetura

4.1. Ataques cibernéticos

4.2. Desastres naturais

4.3. Obsolescência de software

4.4. Interrupções humanas

4.5. Falhas de comunicações

4.6. Tráfego congestionado

4.7. Erros de Integrações

5. RAs & VAs

5.1. RAs

5.1.1. (p14) RA01 - Segurança

5.1.2. (p10) RA02 - Performance

5.1.3. (p16) RA03 - Manutenabilidade

5.1.4. (p12) RA04 - Disponibilidade

5.1.5. (p06) RA05 - Escalabilidade

5.1.6. (p18) RA06 - Observabilidade

5.1.7. (p08) RA07 - User Experience

5.2. VAs

5.2.1. VA02 - Deve-se fazer lock-ins?

5.2.1.1. Sim, Microsoft

5.2.2. VA03 - Senioridade do time

5.2.2.1. Predominantemente Junior

5.2.3. VA01 - Em geral como a empresa deseja otimizar os custos com deenvolvimento de ativos de software?

5.2.3.1. A longo prazo

5.2.4. VA04 - Stack Tecnológica

5.2.4.1. .Net

5.2.5. VA05 - Tecnologias ou padrões preferenciais

5.2.5.1. Preferir

5.2.5.1.1. .Net

5.2.5.2. Sempre utilizar

5.2.5.2.1. TDD

5.2.6. VA06 - Tecnologias ou padrões proibidas ou a serem evitadas

5.2.6.1. Evitar

5.2.6.1.1. Java

5.2.6.1.2. Oracle

5.2.6.2. Nunca utilizar