Capítulo 29 — Construção do projeto final
Mapa da aula
Aula 29 publicada. Mapa, exemplo, EX085.
flowchart TD
N0["29.1 A ferramenta"]
N1["29.2 Testes"]
N2["29.3 Documentação"]
N3["Síntese"]
N0 --> N1 --> N2 --> N3
N3 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX085"]
Desenho lógico
flowchart LR
N0["29.1 A ferramenta"]
N1["29.2 Testes"]
N2["29.3 Documentação"]
N3["Síntese"]
N0 --> N1 --> N2 --> N3 --> Q["EX085"]
[29.1 A ferramenta]
|
v
[29.2 Testes]
|
v
[29.3 Documentação]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX085]
Objetivos de aprendizagem
Você vai (1) construir uma ferramenta de GRC para a Riverton como projeto final; (2) testá-la com usuários; (3) documentá-la para manutenção.
29.1 A ferramenta
Em seu projeto final, Priya constrói um pequeno painel de governança com a biblioteca padrão do Python, que lê o registro de riscos, os resultados dos testes de controles, os valores dos indicadores e o registro de evidências, e produz um resumo semanal em HTML para o gerente de operações. Ele destaca ações atrasadas, evidências vencidas, violações de limiares e controles que falharam, cada item com seu dono. Ela mantém o desenho simples para que o coordenador de TI da Riverton consiga mantê-lo. Usar só a biblioteca padrão significa que o coordenador não precisa de pacotes extras para mantê-lo funcionando.
29.2 Testes
Priya testa a ferramenta com dados de amostra que contêm problemas conhecidos, verificando se cada um é relatado corretamente. Depois pede ao gerente de operações e a dois gerentes de clínica que usem o resumo por duas semanas. Eles o acham útil, mas pedem um filtro por clínica. Um gerente percebe que uma ação resolvida ainda aparece porque o arquivo de origem não foi atualizado, o que leva Priya a acrescentar ao resumo a data da última atualização de cada fonte. Essa data permite ao leitor julgar se um item está de fato aberto ou só se baseia em dados desatualizados.
29.3 Documentação
Priya documenta a ferramenta: finalidade, entradas, saídas, como executá-la, como acrescentar uma nova verificação, limitações conhecidas e quem a mantém. Ela guarda o código no repositório da Riverton, com um registro de mudanças. Aprende que uma ferramenta de projeto final só dá certo se continuar útil depois que a estudante sai, o que depende de simplicidade, documentação e um mantenedor nomeado. A seção sobre como acrescentar uma nova verificação é a que mais importa, porque as necessidades da Riverton vão mudar depois que ela sair. O registro de mudanças mostra o que mudou entre as versões e por quê.
Exemplo resolvido
Priya constrói um resumo semanal de governança, testa-o com problemas conhecidos e com usuários, acrescenta um filtro por clínica e as datas das fontes e documenta a manutenção.
Caso sintético. A ferramenta e os dados são sintéticos.
Erros e limites
Os painéis podem ser ignorados. A qualidade dos dados de origem limita o valor.
Exercícios
- EX085 — Destaques. O que o resumo semanal destaca? Rubrica: 3 = ações atrasadas, evidências vencidas, violações de limiares, controles que falharam;; 2 = quatro;; 1 = vago;; 0 = nenhuma.
- EX086 — Datas das fontes. Por que Priya acrescentou a data da última atualização de cada fonte? Rubrica: 3 = uma ação resolvida aparecia porque uma fonte estava desatualizada;; 2 = atualidade;; 1 = vago;; 0 = nenhuma.
- EX087 — Valor duradouro. De que depende o valor duradouro? Rubrica: 3 = simplicidade, documentação e um mantenedor nomeado;; 2 = manutenibilidade;; 1 = vago;; 0 = nenhuma.
Síntese
Uma ferramenta de projeto final precisa ser testada com usuários e documentada para que outras pessoas possam mantê-la.
Continue estudando — aula 29 (capítulo 29 de 30)
← Capítulo 28 · Índice das aulas · Capítulo 30 →
Continue para a próxima aula já escrita.