Capítulo 29 — Construção do projeto final

Mapa da aula

Aula 29 publicada. Mapa, exemplo, EX085.

flowchart TD
  N0["29.1 Kit de ferramentas"]
  N1["29.2 Documentação"]
  N2["29.3 Testes"]
  N3["29.4 Entrega"]
  N0 --> N1 --> N2 --> N3
  N3 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX085"]

Desenho lógico

flowchart LR
  N0["29.1 Kit de ferramentas"]
  N1["29.2 Documentação"]
  N2["29.3 Testes"]
  N3["29.4 Entrega"]
  N0 --> N1 --> N2 --> N3 --> Q["EX085"]

[29.1 Kit de ferramentas]
    |
    v
[29.2 Documentação]
    |
    v
[29.3 Testes]
    |
    v
[29.4 Entrega]
    |
    v
[Exemplo resolvido] --> [Exercício EX085]

Objetivos de aprendizagem

Você vai (1) construir um kit de ferramentas de privacidade; (2) combinar os laboratórios; (3) documentá-lo.

29.1 Kit de ferramentas

Aisha combina num kit os scripts dos laboratórios anteriores: a revisão dos fluxos de SDKs, a verificação da cobertura dos pedidos de acesso, o varredor de arquivos, a verificação da retenção do CFTV e a rotina das contas inativas. Ela lhes dá uma estrutura comum, formatos de saída consistentes e um arquivo de configuração compartilhado para os limites, para que a equipe de privacidade os execute sempre do mesmo jeito. Limites como trinta dias para as imagens e dois anos para as contas inativas ficam no arquivo de configuração, e não no código, para que possam mudar sem reescrever nada.

29.2 Documentação

Cada script tem finalidade, entradas, saídas e limites documentados. No varredor, a seção de limites diz claramente que informações de saúde em texto livre não são detectadas; na verificação do CFTV, que o script lê um índice, e não as imagens. A documentação explica também como mudar os limites e onde as saídas ficam guardadas. Aisha a escreve para pessoas que não fizeram seu curso. Cada seção de limites é um aviso direto, por exemplo: uma varredura limpa não significa que o arquivo não contenha informações de saúde. Um exemplo resolvido com arquivos sintéticos mostra a saída esperada de cada script.

29.3 Testes

Aisha testa todos os scripts com dados sintéticos. Cada script tem um conjunto de arquivos de entrada sintéticos com resultados corretos conhecidos, para que qualquer pessoa confirme que ele continua funcionando depois de mudanças. Os testes incluem casos extremos, como arquivos vazios, datas ausentes e contas ao mesmo tempo inativas e com dívida; neste último caso, o teste confirma que a retenção prevalece sobre a exclusão. Todos os testes passam antes da entrega, e os resultados ficam guardados com o kit, para que a próxima pessoa saiba exatamente o que era esperado.

29.4 Entrega

O kit é entregue à equipe de privacidade da Quayside, que nomeia um responsável e combina uma revisão anual. Aisha explica que scripts escritos para uma versão de um sistema podem quebrar quando os sistemas mudam. Lembra também que o kit usa apenas as bibliotecas padrão do Python, o que simplifica a manutenção e evita dependências extras. A equipe de privacidade executa cada script uma vez com Aisha observando, e a data da primeira revisão anual é marcada. O Sr. Reilly observa que as ferramentas precisam de manutenção, e que uma ferramenta sem responsável logo deixa de ser confiável.

Exemplo resolvido

Aisha constrói e documenta um kit de cinco scripts testado com dados sintéticos.

Caso sintético. O kit é sintético.

Erros e limites

Ferramentas precisam de responsáveis.

Exercícios

• EX085 — Scripts. Quantos scripts são combinados?
  Mostrar critérios de avaliação

  Rubrica: 3 = cinco;; 2 = parcialmente correta;; 1 = errada;; 0 = nenhuma.
• EX086 — Documentação. O que a documentação de cada script inclui?
  Mostrar critérios de avaliação

  Rubrica: 3 = finalidade, entradas, saídas, limites;; 2 = a maioria;; 1 = um;; 0 = nenhuma.
• EX087 — Dados. Que dados são usados nos testes?
  Mostrar critérios de avaliação

  Rubrica: 3 = sintéticos;; 2 = parcialmente correta;; 1 = reais;; 0 = nenhuma.