Capítulo 4 — Programação I

Mapa da aula

Aula 04 publicada. Mapa, exemplo, EX010.

flowchart TD
  N0["4.1 Registros como dados"]
  N1["4.2 Verificações simples"]
  N2["4.3 Código legível"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3
  N3 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX010"]

Desenho lógico

flowchart LR
  N0["4.1 Registros como dados"]
  N1["4.2 Verificações simples"]
  N2["4.3 Código legível"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3 --> Q["EX010"]

[4.1 Registros como dados]
    |
    v
[4.2 Verificações simples]
    |
    v
[4.3 Código legível]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX010]

Objetivos de aprendizagem

Você vai (1) representar registros de governança em código; (2) escrever verificações simples sobre eles; (3) manter os scripts legíveis para os auditores.

4.1 Registros como dados

O primeiro programa de Nadia lê a lista de políticas da Ardwell como registros estruturados: título, responsável, data de aprovação e data da próxima revisão. Representar as políticas como dados, e não como prosa, permite que um programa as confira. Ela guarda a lista num arquivo CSV e a lê com a biblioteca padrão do Python. O professor insiste em nomes de campos claros e num registro por linha, porque os dados de governança serão lidos por pessoas que não são programadoras, incluindo os auditores internos, que precisam entender o que o script verifica e por quê.

4.2 Verificações simples

Nadia escreve funções que sinalizam políticas sem responsável e políticas com revisão vencida. Testa cada função numa pequena lista feita à mão, em que conhece a resposta certa, incluindo casos-limite como uma revisão que vence hoje. Quando uma verificação falha, o programa imprime o título da política e o motivo, e não só uma contagem. Ela aprende que o valor de um script de governança está numa saída acionável: um responsável consegue corrigir uma política específica, mas não consegue fazer nada com um número sem explicação.

4.3 Código legível

O Prof. Brenner revisa o código de Nadia com olhar de auditor. Cada função tem uma docstring curta que explica a regra aplicada e de onde ela vem, como a política da Ardwell sobre políticas. Constantes como o intervalo de revisão têm nome, em vez de ficarem escondidas como números soltos. Ele explica que, quando os scripts produzem evidências de compliance, o próprio script passa a fazer parte da evidência, então precisa ser compreensível e estar sob controle de versão. Nadia faz commit do código num repositório, com um histórico curto de cada mudança.

Exemplo resolvido

Nadia lê as políticas de um CSV, sinaliza responsáveis ausentes e revisões vencidas com os motivos e documenta as regras para os auditores.

Caso sintético. Os registros de políticas são sintéticos.

Erros e limites

Os scripts conferem só o que está registrado. Dados errados produzem saídas erradas e confiantes.

Exercícios

• EX010 — Campos da política. Que campos cada registro de política contém?
  Mostrar critérios de avaliação

  Rubrica: 3 = título, responsável, data de aprovação, data da próxima revisão;; 2 = quatro campos;; 1 = vago;; 0 = nenhuma.
• EX011 — Saída acionável. Por que imprimir o título da política e o motivo, e não só uma contagem?
  Mostrar critérios de avaliação

  Rubrica: 3 = os responsáveis podem agir sobre itens específicos;; 2 = acionável;; 1 = vago;; 0 = nenhuma.
• EX012 — Script como evidência. Por que os scripts de compliance precisam ser legíveis e versionados?
  Mostrar critérios de avaliação

  Rubrica: 3 = o script passa a fazer parte da evidência;; 2 = evidência;; 1 = vago;; 0 = nenhuma.

Síntese

Scripts simples e legíveis tornam os registros de governança verificáveis e a sua saída acionável.