Capítulo 35 — Ateliê de projeto II
Mapa da aula
Aula 35 publicada. Mapa, exemplo, EX069.
flowchart TD
N0["35.1 Do conceito ao projeto detalhado"]
N1["35.2 Argumentos de garantia"]
N2["35.3 Enunciado do Ateliê II sintético"]
N3["35.5 Atividade prática"]
N4["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX069"]
Desenho lógico
flowchart LR
N0["35.1 Do conceito ao projeto detalhado"]
N1["35.2 Argumentos de garantia"]
N2["35.3 Enunciado do Ateliê II sintético"]
N3["35.5 Atividade prática"]
N4["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX069"]
[35.1 Do conceito ao projeto detalhado]
|
v
[35.2 Argumentos de garantia]
|
v
[35.3 Enunciado do Ateliê II sintético]
|
v
[35.5 Atividade prática]
|
v
[Síntese do capítulo]
|
v
[Exemplo resolvido] --> [Exercício EX069]
Objetivos de aprendizagem e conexão
Ao fim deste capítulo você será capaz de (1) levar um projeto do conceito ao projeto detalhado, com justificativa quantitativa; (2) integrar as análises de confiabilidade, segurança operacional, segurança da informação, desempenho e custo num único argumento; (3) construir um argumento de garantia estruturado que ligue alegações a evidências; e (4) defender decisões de projeto detalhado sob revisão. Ele integra os capítulos 26 a 34 e prepara os capítulos 36 a 40.
35.1 Do conceito ao projeto detalhado
O Ateliê I selecionou um conceito. O Ateliê II o detalha: componentes, configurações, interfaces, procedimentos e verificação específicos. Todos os números dos capítulos anteriores voltam: tempos de autonomia (capítulos 1 e 6), dimensionamento das baterias (Capítulo 3), taxas-base (Capítulo 7), latência (Capítulo 11), árvore de falhas (Capítulo 23), métricas de detecção (Capítulo 29), disponibilidade (Capítulo 32), filas (prévia do Capítulo 36). Um projeto detalhado é coerente quando esses números são consistentes entre si e com os requisitos. Para o TMRP, o dimensionamento das baterias, as 72 horas de operação automática local, a reserva de quatro horas do hospital e o tempo de recuperação precisam contar a mesma história; o EX069 mostra o que acontece quando um deles não conta.
35.2 Argumentos de garantia
Um caso de garantia é um argumento estruturado de que um sistema atende a uma alegação, apoiado em evidências. Ele tem uma alegação de topo ("o TMRP mantém o hospital abastecido em cenários críveis, incluindo a falsificação de comandos remotos"), subalegações (cada requisito atendido; riscos residuais aceitáveis), argumentos (por que as subalegações apoiam a alegação) e evidências (resultados de testes, análises, revisões). O modelo de argumentação de Toulmin — alegação, dados, garantia, respaldo, qualificador, refutação (Toulmin, 1958/2003) — é uma lente útil: que evidência apoia a alegação, por que ela é pertinente e o que a derrotaria. Derrotadores explícitos ("a menos que o centro SCADA esteja comprometido") mantêm o argumento honesto.
35.3 Enunciado do Ateliê II (sintético)
Produza o projeto detalhado da fase 1 do TMRP (PS2, PS3, PS4 e Hollin Hill): lista de componentes com seus recursos de segurança; listas de permissões de zonas e condutos; procedimento de gestão de chaves; procedimentos de manual local e de failover; racionalização dos novos alarmes de segurança; plano de verificação; e um caso de garantia para a alegação de topo, com pelo menos quatro subalegações e derrotadores identificados. O enunciado cobre os quatro ativos que mais importam para St Brenna's: a PS2 como piloto comprovado, a PS3 e Hollin Hill como o caminho do reservatório e a PS4 como a alimentação direta. As demais estações e a estação de tratamento de Fenwick vêm em fases posteriores, então o caso de garantia da fase 1 precisa dizer claramente que ainda não as cobre.
35.4 Exemplo resolvido: um ramo do caso de garantia (sintético)
Subalegação C2: comandos remotos forjados não podem causar a perda do abastecimento do hospital. Argumento: os comandos exigem um MAC válido por estação (R1) e um contador novo (R2); mesmo comandos aceitos não conseguem levar o processo além dos limites locais (R3); a perda dos dois caminhos de abastecimento exige, além disso, que o tanque do hospital falhe (árvore de falhas). Evidências: T1 e T2 aprovados (bancada e aceitação em campo na PS2); T3 aprovado na v2; análise de condicionamento do Laboratório 9; revisão independente da gestão de chaves. Derrotadores: (D1) servidores SCADA comprometidos — os comandos são autênticos; mitigado pelos limites locais e pela aprovação por duas pessoas de mudanças em massa, residual aceito pela diretora de operações; (D2) chave de uma estação extraída de uma RTU roubada — confinado a uma estação, detecção pelo alarme de violação, procedimento de rotação. Qualificador: a alegação vale para os cenários do registro de riscos v1.2; não para um ataque físico às duas estações de bombeamento.
35.5 Atividade prática
Escreva o caso de garantia completo para o enunciado do Ateliê II e apresente-o a uma banca instruída a encontrar derrotadores. Dê à banca o enunciado, sua lista de componentes e o caso de garantia, e peça que encontrem o que derrotaria cada subalegação. Registre todo derrotador encontrado, quer você já o tivesse listado ou não, e escreva uma resposta: evidência que o trate, uma mudança de projeto ou uma aceitação explícita com um dono. Derrotadores como um centro SCADA comprometido ou a chave de uma RTU roubada são esperados; o trabalho da banca é encontrar os que você deixou passar, como o uso indevido do modo manual local.
35.6 Erros comuns e limites
- Números inconsistentes entre as análises.
- Casos de garantia com alegações e sem evidências, ou com evidências e sem argumento.
- Derrotadores omitidos para que o caso pareça mais forte.
- Projeto detalhado que muda os requisitos em silêncio.
O EX069 é um exemplo do primeiro erro dentro do próprio TMRP: R6 pede oito horas, mas o ensaio de recuperação mediu doze. Um caso que alegasse R6 citando o ensaio seria inconsistente, então o caso registra R6 como não atendido e explica por que a alegação sobre o hospital ainda pode se sustentar graças à operação automática local.
Exercícios — capítulo 35
EX069 — Verificação de consistência. Objetivo: encontrar inconsistências entre as análises. Entradas: autonomia das baterias da PS4 de 24 h (R5); reserva do hospital de 4 h; R6 restaurar a operação remota em 8 h; o ensaio do Capítulo 47 mostra 12 h. Passos: identifique quais alegações conflitam e o que o conflito significa para o caso de garantia. Evidência esperada: análise. Rubrica: 3 = identifica que R6 não é atendido (12 > 8), que o abastecimento não depende da operação remota (automático local), de modo que a alegação sobre o hospital ainda pode se sustentar, e que o caso precisa registrar R6 como reprovado, com plano; 2 = parcial; 1 = não percebe R6; 0 = nada.
EX070 — Encontre um derrotador. Objetivo: contestar um argumento. Entradas: a subalegação C2 da §35.4. Passos: proponha mais dois derrotadores não listados e a evidência ou mudança de projeto que trataria cada um. Evidência esperada: dois derrotadores com respostas. Rubrica: 3 = derrotadores críveis (p. ex., uso indevido do modo manual local por um insider; caminho de atualização do firmware do gateway comprometido; falha na persistência do contador) com respostas específicas; 2 = um fraco; 1 = repete os listados; 0 = nada.
Síntese do capítulo
O projeto detalhado faz com que todos os números anteriores se encontrem. Um caso de garantia liga a alegação de topo às evidências por meio de argumentos explícitos, com qualificadores e derrotadores declarados abertamente. A consistência entre as análises e a honestidade sobre os derrotadores são o que torna um projeto detalhado defensável.
Continue estudando — capítulo 35 de 50
← Capítulo 34 · Índice de capítulos do curso · Capítulo 36 →
Siga para a próxima lição escrita.