◇ OpenCyber Academy
Pesquisa doutoral · Capítulo 4 · Português

Capítulo 4 — Replicação da linha de base e piloto

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Capítulo 4 — Replicação da linha de base e piloto

Mapa da aula

Aula 04 publicada. Mapa, exemplo, EX021.

flowchart TD
  N0["4.1 Por que replicar primeiro"]
  N1["4.2 Resultado da linha de base"]
  N2["4.4 Teste do pipeline"]
  N3["4.5 Revisão do protocolo"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX021"]

Desenho lógico

flowchart LR
  N0["4.1 Por que replicar primeiro"]
  N1["4.2 Resultado da linha de base"]
  N2["4.4 Teste do pipeline"]
  N3["4.5 Revisão do protocolo"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX021"]
[4.1 Por que replicar primeiro]
    |
    v
[4.2 Resultado da linha de base]
    |
    v
[4.4 Teste do pipeline]
    |
    v
[4.5 Revisão do protocolo]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX021]

Objetivos de aprendizagem

Você vai (1) replicar uma linha de base publicada ou anterior antes de estendê-la; (2) conduzir um piloto para testar procedimentos, não efeitos; (3) conferir os pipelines de dados contra valores conhecidos; (4) revisar o protocolo a partir das evidências do piloto.

4.1 Por que replicar primeiro

Antes de testar sua intervenção, Amara verifica se consegue reproduzir a linha de base histórica da própria Tessaro: cerca de quatro defeitos de arquitetura por cem mudanças de design. Se sua extração e sua codificação produzirem um número muito diferente dos registros da organização, ou os registros ou o método dela estão errados, e qualquer comparação posterior seria construída sobre areia. Replicar a linha de base é um teste barato de toda a cadeia de medição. Ela extrai dois anos de mudanças e defeitos históricos, codifica-os com o manual do capítulo 1 e compara sua taxa com o número que a liderança de segurança relatou nos documentos de planejamento.

4.2 Resultado da linha de base

A codificação dela dá 3,6 defeitos de arquitetura por cem mudanças, um pouco abaixo dos 4,1 relatados. Ao investigar, ela descobre que o número relatado contava chamados duplicados para o mesmo defeito quando várias equipes eram afetadas. Depois de remover as duplicatas, os dois números coincidem dentro do arredondamento. Essa pequena descoberta importa: se ela tivesse comparado suas medições posteriores com o número inflado do planejamento, a intervenção teria parecido funcionar mesmo que nada tivesse mudado. Ela registra a discrepância e a correção no log de mudanças e informa a Tessaro, cuja equipe de planejamento corrige o dashboard para os relatórios futuros.

4.3 Objetivos do piloto

O piloto roda com três equipes voluntárias por três meses. Seus objetivos são procedimentais: as equipes conseguem concluir o protocolo em noventa minutos, o checklist de fidelidade pode ser pontuado de forma consistente, o pipeline de dados de defeitos captura todos os chamados relevantes, e os engenheiros acham a sessão aceitável. O piloto explicitamente não serve para estimar o efeito, porque três equipes em três meses produziriam defeitos de menos para qualquer conclusão. Amara declara isso no plano do piloto, para que ninguém, nem ela mesma, se sinta tentado a anunciar um sucesso precoce a partir de um punhado de números.

4.4 Teste do pipeline

Amara insere dez chamados de teste sintéticos, com classificações conhecidas, numa cópia do rastreador de defeitos e roda seus scripts de extração. Nove chegam corretamente; um, aberto num projeto renomeado, se perde. Ela corrige o mapeamento de projetos e roda de novo, recuperando os dez. Ela mantém os chamados sintéticos como um teste de regressão permanente, que roda antes de cada extração de dados. Essa prática, tomada emprestada dos testes de software, dá uma verificação de resposta conhecida para o pipeline da pesquisa, da mesma forma que os vetores de teste dão uma verificação de resposta conhecida para o código criptográfico.

4.5 Revisão do protocolo

As evidências do piloto levam a três revisões. As sessões das mudanças grandes se estenderam, então o protocolo agora permite dividi-las em duas sessões. A pontuação de fidelidade divergiu sobre se as fronteiras de confiança tinham sido desenhadas, então o checklist ganha um diagrama de exemplo. Os engenheiros acharam útil, mas lenta, a revisão do arquiteto externo, então as revisões agora precisam terminar em até cinco dias úteis. Cada revisão é registrada com o motivo antes do início do estudo principal. Amara relata o piloto na tese como um capítulo separado, incluindo os problemas, porque quem for replicar o estudo vai enfrentar as mesmas dificuldades práticas.

Exemplo resolvido

Amara replica a linha de base em 3,6 por cem mudanças, atribui o número de 4,1 a chamados duplicados, corrige uma lacuna do pipeline com chamados de teste sintéticos e registra três revisões do protocolo.

Caso sintético. Os números da linha de base, as equipes do piloto e os chamados são sintéticos.

Erros e limites

Um piloto com equipes voluntárias pode ser mais motivado do que as equipes típicas. Os testes de regressão só detectam os modos de falha conhecidos.

Exercícios

Síntese

Replicar a linha de base e pilotar os procedimentos expõe erros de medição antes que eles possam se passar por efeitos.

Continue estudando — aula 04 (capítulo 04 de 08)

← Capítulo 03 · Índice das aulas · Capítulo 05 →

Continue para a próxima aula já escrita.