PROJETO INTEGRADOR — PROBABILIDADE E ESTATÍSTICA

Engenharia de Software

PARTE 1 — ENUNCIADO GERAL DO PROJETO INTEGRADOR

1. Identificação

  • Disciplina: Probabilidade e Estatística
  • Curso: Engenharia de Software
  • Modalidade: Projeto Integrador (PI) em equipe (máximo de 4 integrantes)
  • Carga horária do PI: Atividade final (10 pontos — peso 2)
  • Prazo único: 1 semana para execução, entrega e apresentação

2. Objetivo Geral

Aplicar os conceitos de Estatística Descritiva, Probabilidade, Variáveis Aleatórias e Distribuições, Intervalo de Confiança e Teste de Hipóteses para uma única amostra na análise de um problema real (ou simulado com base realista) de Engenharia de Software — cobrindo desenvolvimento, DevOps, segurança, dados, qualidade e operação.

3. Objetivos Específicos

  • Compreender um processo de software (qualidade, provisionamento, deploy, segurança, dados, suporte) a partir de dados.
  • Organizar, descrever e interpretar conjuntos de dados por meio de medidas de tendência central, dispersão e representação gráfica adequada.
  • Calcular probabilidades e modelar o comportamento de variáveis aleatórias relevantes ao problema (contagens, tempos, proporções, latências).
  • Construir e interpretar intervalos de confiança para a média, proporção ou variância populacional.
  • Formular, executar e interpretar testes de hipóteses para uma única amostra, com diferentes níveis de informação sobre o desvio padrão (σ conhecido ou desconhecido).
  • Comunicar tecnicamente as conclusões, com respeito aos limites da análise e à ética no uso de dados.

4. Estrutura da Equipe

  • Equipes com máximo de 4 integrantes, definidas pelos próprios alunos.
  • Cada equipe recebe um cenário distinto, conforme a Parte 2 deste documento.
  • A composição deve priorizar diversidade de perfis (desenvolvimento, infraestrutura, dados, segurança, gestão) e equilíbrio de responsabilidades.
  • É vedada a troca de cenário entre equipes sem autorização do docente.

5. Guia de Resolução do Problema (substitui o cronograma semanal)

O PI é executado em 1 semana. A equipe deve seguir o guia abaixo, passo a passo, e registrar a evidência de cada passo no relatório.

Passo 1 — Imersão no problema

  • Ler o cenário atribuído em profundidade.
  • Identificar a variável de interesse, o parâmetro populacional-alvo (média, proporção, variância, λ, p) e a pergunta de decisão.
  • Listar, no relatório, as suposições admitidas e os limites do estudo.

Passo 2 — Construção e organização da base de dados

  • Reproduzir a tabela do cenário em planilha (Excel, Google Sheets ou LibreOffice Calc).
  • Conferir unidades, contagens e identificadores.
  • Calcular as medidas-resumo e os gráficos dos Passos 3 e 4 na própria planilha, com fórmulas auditáveis.

Passo 3 — Análise descritiva

  • Calcular média, mediana, desvio padrão, mínimo, máximo, amplitude e, quando aplicável, coeficiente de variação.
  • Construir pelo menos um gráfico adequado (histograma, boxplot, gráfico de barras, gráfico de linhas temporal, Pareto).
  • Interpretar o padrão observado (simetria, dispersão, presença de outliers) antes de qualquer teste.

Passo 4 — Análise probabilística

  • Identificar a distribuição teórica plausível para o fenômeno (Binomial, Poisson, Hipergeométrica, Geométrica, Binomial Negativa, Exponencial ou Normal), com justificativa.
  • Calcular pelo menos uma probabilidade no contexto do problema (por exemplo: “P(observar mais de X ocorrências) sob a distribuição adotada”).

Passo 5 — Inferência estatística (intervalo de confiança)

  • Construir o IC 95 % (ou outro nível, com justificativa) para o parâmetro-alvo.
  • Interpretar o IC em linguagem de Engenharia de Software, sem afirmar “probabilidade de que o parâmetro esteja no intervalo” (interpretação frequentista).

Passo 6 — Teste de hipótese para uma única amostra

  • Definir H₀, H₁, nível de significância α (com justificativa) e tipo de teste (unilateral ou bilateral).
  • Escolher a estatística de teste adequada (Z, t, χ²), informando se σ é conhecido ou estimado.
  • Calcular a estatística de teste, o valor-p e a regra de decisão.
  • Decidir rejeitar ou não rejeitar H₀ e interpretar a decisão em linguagem de Engenharia de Software.

Passo 7 — Conclusão técnica e limites

  • Articular o resultado estatístico com a decisão de engenharia (manter o processo, investigar causa-raiz, revisar meta, refatorar, adotar feature flag, etc.).
  • Declarar limites: tamanho da amostra, escopo, possíveis vieses, generalização.
  • Listar recomendações fundamentadas nos dados.

Passo 8 — Comunicação e apresentação

  • Relatório escrito em PDF ou DOCX, com capa, sumário, seções numeradas, tabelas, gráficos, fórmulas, comandos utilizados e referências (ABNT ou APA).
  • Seminário de 10 a 15 minutos por equipe, com 5 minutos de arguição.

Sugestão de divisão de tarefas para 4 alunos

Aluno Responsabilidade principal
A Imersão, organização da base, descritiva (Passos 1–3)
B Probabilidade, modelo teórico, probabilidades calculadas (Passo 4)
C IC, teste de hipótese, valor-p (Passos 5–6)
D Conclusão, limites, relatório escrito, ensaio da apresentação (Passos 7–8)

Check-list de autoavaliação antes da entrega

6. Entregáveis Obrigatórios

  • Relatório técnico (PDF ou DOCX) contendo:
    • Capa com identificação da equipe, cenário, disciplina e professor.
    • Contextualização do problema.
    • Base de dados completa, em tabela.
    • Estatísticas descritivas (com interpretação).
    • Gráfico(s) com legendas, títulos e fonte.
    • Modelo probabilístico adotado, com justificativa e cálculo de probabilidades.
    • Intervalo de confiança (nível justificado).
    • Teste de hipótese (H₀, H₁, α, estatística de teste, valor-p, decisão).
    • Conclusão técnica, recomendações e limites da análise.
    • Referências bibliográficas (ABNT ou APA).
  • Seminário de apresentação (10 a 15 minutos por equipe, com 5 minutos para arguição).

7. Requisitos Técnicos Mínimos

Toda apresentação deve conter, no mínimo: - Descrição dos dados (média, mediana, variância, desvio padrão, mínimo, máximo — quando aplicável). - Pelo menos um gráfico adequado ao tipo de variável e ao objetivo (histograma, boxplot, barras, Pareto, linhas temporal). Não é permitido o uso de análise de correlação como foco do trabalho. - Cálculo e interpretação de pelo menos uma probabilidade no contexto do problema, com modelo teórico explícito. - Construção e interpretação de um intervalo de confiança (95 %, 90 % ou 99 %, com justificativa). - Execução e interpretação de um teste de hipótese para uma única amostra, com nível de significância α definido e justificado. - Conclusão técnica com discussão sobre os limites da análise (tamanho da amostra, possíveis vieses, escopo, generalização).

8. Condutas Esperadas

  • Autoria e honestidade acadêmica: todos os cálculos, gráficos e interpretações devem ser de produção da equipe. Plágio total ou parcial implica nota zero e encaminhamento à coordenação. O uso de IA generativa (ChatGPT, Copilot, etc.) é permitido como apoio, mas não substitui a produção da equipe; todo trecho gerado por IA deve ser revisado, validado e explicitamente creditado.
  • Coerência metodológica: as análises estatísticas devem estar alinhadas ao tipo de variável, à distribuição admitida e à pergunta do problema.
  • Comunicação técnica: uso correto da terminologia estatística, com clareza, organização e referência a fontes.
  • Ética no uso de dados: mesmo em dados sintéticos, as equipes devem tratar a análise com o mesmo rigor que aplicariam a dados reais. Em dados reais, deve-se observar a legislação aplicável de proteção de dados, anonimizando identificadores quando necessário.

9. Observação Final do Enunciado Geral

Este enunciado é único. As especificidades — contexto, empresa, base de dados, perguntas, indicador de processo, modelo probabilístico e teste inferencial — variam de acordo com o cenário atribuído a cada equipe e estão detalhadas na Parte 2 deste documento.

PARTE 2 — CENÁRIOS POR EQUIPE

A seguir, são apresentados 15 cenários distintos, ordenados por progressão didática (do mais simples ao mais completo). Cada equipe recebe apenas o cenário correspondente à sua numeração, previamente divulgado pelo docente.

A alocação garante: - 5 modelos probabilísticos diferentes (Binomial, Poisson, Hipergeométrica, Geométrica, Binomial Negativa) alocados em contextos variados de Engenharia de Software, com progressão didática. - 4 tipos de teste inferencial (Z com σ conhecido para média, Z para proporção, t de Student com σ desconhecido, qui-quadrado para variância). - Mix de resultados: cenários em que H₀ não é rejeitada, cenários em que H₀ é rejeitada e cenários borderline (valor-p próximo de α), exigindo interpretação crítica. - Contextos mistos: desenvolvimento, DevOps, segurança, dados, qualidade de software, help desk.

EQUIPE 1 — DEFÉITOS EM RELEASE: PROPORÇÃO DE BUGS CRÍTICOS (BINOMIAL)

1.1 Contexto

A DevLog Sistemas S.A. é uma fábrica de software que mantém um produto SaaS de gestão empresarial. A política de qualidade admite que a proporção de defeitos (bugs) críticos por release não ultrapasse 6 % dos itens entregues. Nos últimos meses, a engenharia tem observado variação, mas acredita que o processo esteja dentro da meta.

1.2 Problema de Engenharia de Software

Verificar se a proporção de bugs críticos por release é superior a 6 %, com base em 30 releases de 2025.

1.3 Base de Dados

Tabela 1 — Itens entregues e bugs críticos por release (30 releases, 2025).

Release Itens Bugs Release Itens Bugs Release Itens Bugs
1 200 9 11 200 11 21 200 10
2 200 12 12 200 8 22 200 13
3 200 10 13 200 14 23 200 9
4 200 11 14 200 9 24 200 12
5 200 13 15 200 12 25 200 8
6 200 8 16 200 10 26 200 11
7 200 12 17 200 9 27 200 10
8 200 10 18 200 11 28 200 13
9 200 9 19 200 12 29 200 9
10 200 11 20 200 10 30 200 8

1.4 Perguntas

  • Pergunta principal: A proporção de bugs críticos é superior a 6 % (política interna)?
  • Pergunta secundária 1: Qual a probabilidade aproximada de um release sorteado aleatoriamente apresentar mais de 14 bugs críticos?
  • Pergunta secundária 2: Construir um IC 95 % para a verdadeira proporção de bugs críticos.

1.5 Análise Estatística Esperada

  • Estatística descritiva: proporção média, desvio padrão, mínimo, máximo, histograma.
  • Modelo probabilístico: Binomial com n = 200 e p̂ amostral. Justificar: ensaios de Bernoulli (item com ou sem bug crítico) independentes em release de tamanho fixo.
  • Probabilidade: sob Binomial, P(X > 14) com p̂ amostral ≈ 0,053. Comparar com aproximação Normal (n·p ≥ 5).
  • Inferência: IC 95 % para a proporção (Wilson ou Normal com correção).
  • Teste de hipótese: Z unilateral à direita para proporção (H₀: p = 0,06 contra H₁: p > 0,06), α = 0,05. Resultado esperado: não rejeitar H₀ (p̂ ≈ 0,053; Z ≈ −1,05; valor-p ≈ 0,85).
  • Gráfico sugerido: barras com a proporção de bugs por release e linha do limite de 6 %.

1.6 Orientação para Interpretação e Conclusão

  • Reportar: “ao nível de 5 %, não há evidências estatísticas de violação da política de qualidade”.
  • Recomendar manter o controle atual, com monitoria via DORA change failure rate.
  • Limites: amostra de 30 releases, ausência de estratificação por squad e por tipo de item.

EQUIPE 2 — CHAMADOS CRÍTICOS DE HELPDESK POR DIA (POISSON)

2.1 Contexto

A HelpDesk Ágil S.A. presta suporte técnico de primeiro nível. A gestão de operações considera que uma média superior a 4 chamados críticos por dia indica degradação da base instalada. A coordenação suspeita que a média esteja acima do limite.

2.2 Problema de Engenharia de Software

Verificar se a média diária de chamados críticos é superior a 4, com base em 30 dias úteis.

2.3 Base de Dados

Tabela 1 — Chamados críticos por dia (30 dias, outubro/2025).

Dia Chamados Dia Chamados
1 4 16 6
2 5 17 4
3 3 18 7
4 6 19 5
5 4 20 6
6 7 21 4
7 5 22 5
8 4 23 8
9 6 24 6
10 5 25 5
11 8 26 7
12 4 27 6
13 5 28 5
14 6 29 4
15 7 30 6

2.4 Perguntas

  • Pergunta principal: A média diária de chamados críticos é superior a 4?
  • Pergunta secundária 1: A variável pode ser razoavelmente modelada por Poisson? (verificar razão variância/média ≈ 1).
  • Pergunta secundária 2: Construir um IC 95 % para a média diária.

2.5 Análise Estatística Esperada

  • Estatística descritiva: média ≈ 5,4, variância ≈ 1,5, histograma.
  • Modelo probabilístico: Poisson com λ̂ = média amostral.
  • Probabilidade: sob Poisson, P(X ≥ 7) e P(X = 0).
  • Inferência: IC 95 % para λ via qui-quadrado: (2S/χ²ₐ/₂, 2S/χ²₁₋ₐ/₂).
  • Teste de hipótese: t unilateral à direita (H₀: μ = 4 contra H₁: μ > 4), α = 0,05. Resultado esperado: rejeitar H₀ (Z ≈ 7,0; valor-p ≈ 1,8·10⁻⁹).
  • Gráfico sugerido: histograma com a curva Poisson sobreposta (λ = 5,4).

2.6 Orientação para Interpretação e Conclusão

  • Reportar: “há evidências estatísticas de que a média diária de chamados críticos é superior a 4”.
  • Recomendar ações (revisão do runbook de incidentes, monitoramento proativo, FAQ dinâmico, base de conhecimento).
  • Limites: amostra de 30 dias, ausência de estratificação por tipo de cliente e por severidade original.

EQUIPE 3 — INSPEÇÃO DE COMPONENTES CRÍTICOS SEM REPOSIÇÃO (HIPERGEOMÉTRICA, BORDERLINE)

3.1 Contexto

A PlenoSys Hardware S.A. importa lotes de 500 módulos eletrônicos. A norma de aceitação exige que a proporção de módulos defeituosos no lote não ultrapasse 4 %. Para cada lote, uma amostra de 25 módulos é inspecionada sem reposição. O controle de qualidade vem registrando proporções próximas do limite e quer evidência estatística antes de decidir pelo bloqueio sistemático.

3.2 Problema de Engenharia de Software

Verificar se a proporção de defeituosos no lote é superior a 4 %, a partir de 30 amostras de 25 módulos.

3.3 Base de Dados

Tabela 1 — Módulos defeituosos encontrados em amostras de 25, em 30 lotes.

Lote Defeituosos Lote Defeituosos Lote Defeituosos
1 1 11 2 21 0
2 0 12 1 22 1
3 1 13 0 23 2
4 2 14 1 24 1
5 1 15 2 25 0
6 0 16 1 26 1
7 1 17 0 27 2
8 2 18 1 28 1
9 0 19 2 29 0
10 1 20 1 30 1

3.4 Perguntas

  • Pergunta principal: A proporção de defeituosos no lote é superior a 4 % (norma interna)?
  • Pergunta secundária 1: Por que a Binomial é inadequada neste cenário e a Hipergeométrica é indicada?
  • Pergunta secundária 2: Calcule a probabilidade de, em uma amostra de 25 módulos de um lote com 20 defeituosos (4 %), encontrar 2 ou mais defeituosos.

3.5 Análise Estatística Esperada

  • Estatística descritiva: proporção amostral média ≈ 0,04, histograma.
  • Modelo probabilístico: Hipergeométrica (N = 500, n = 25, K = número de defeituosos no lote). Justificar por amostragem sem reposição em população finita (n/N = 5 %).
  • Probabilidade: P(X ≥ 2 | N = 500, n = 25, K = 20) pela Hipergeométrica.
  • Inferência: IC 95 % para a proporção (Haldane-Anscombe ou Wilson).
  • Teste de hipótese: Z unilateral à direita para proporção (H₀: p = 0,04 contra H₁: p > 0,04), α = 0,05. Resultado esperado: borderline (p̂ ≈ 0,040; Z ≈ 0,00; valor-p ≈ 0,50 — estatística não conclusiva).
  • Gráfico sugerido: histograma do número de defeituosos por amostra, com a Hipergeométrica sobreposta.

3.6 Orientação para Interpretação e Conclusão

  • O valor-p muito próximo de 0,5 exige interpretação crítica: a estatística, isoladamente, não resolve.
  • Recomendar combinar o resultado estatístico com evidências qualitativas (reclamações de campo, histórico do fornecedor, laudos de inspeção visual) antes de bloquear lotes.
  • Limites: amostra de 30 lotes, K desconhecido na população (estimado por p̂), ausência de estratificação por fornecedor.

EQUIPE 4 — NÚMERO DE BUILDS ATÉ A PRIMEIRA FALHA (GEOMÉTRICA)

4.1 Contexto

A PipelineForge DevOps S.A. opera um sistema de integração contínua. Conta-se o número de builds executados até a primeira falha (pipeline interrompido por erro de teste, lint ou compilação). O SRE espera que a média de builds entre falhas seja de pelo menos 80 (taxa de falha ≤ 1,25 %). A operação tem apresentado falhas mais cedo do que o esperado.

4.2 Problema de Engenharia de Software

Verificar se a média de builds até a primeira falha é inferior a 80, com base em 30 sequências de operação.

4.3 Base de Dados

Tabela 1 — Número de builds até a primeira falha (30 sequências, 2025).

Sequência Builds Sequência Builds Sequência Builds
1 62 11 70 21 58
2 75 12 65 22 72
3 55 13 80 23 60
4 68 14 58 24 75
5 72 15 62 25 65
6 60 16 78 26 55
7 82 17 60 27 78
8 58 18 70 28 62
9 65 19 55 29 68
10 75 20 72 30 70

4.4 Perguntas

  • Pergunta principal: A média de builds até a primeira falha é inferior a 80?
  • Pergunta secundária 1: Qual a probabilidade de a primeira falha ocorrer antes do build de número 50, admitindo Geométrica com p̂ = 1/67?
  • Pergunta secundária 2: Construir um IC 95 % para a média da distribuição Geométrica.

4.5 Análise Estatística Esperada

  • Estatística descritiva: média ≈ 66,7, desvio padrão, histograma.
  • Modelo probabilístico: Geométrica (nº de tentativas até o 1º sucesso, em que “sucesso” = falha). Justificar por ensaios de Bernoulli independentes.
  • Probabilidade: P(X < 50) com p̂ = 1/67.
  • Inferência: IC 95 % para μ = 1/p (transformação do IC para p).
  • Teste de hipótese: t unilateral à esquerda (H₀: μ = 80 contra H₁: μ < 80), α = 0,05. Resultado esperado: rejeitar H₀ (x̄ ≈ 66,7; valor-p ≈ 1,5·10⁻⁷).
  • Gráfico sugerido: histograma com a curva Geométrica sobreposta (p̂ = 1/67).

4.6 Orientação para Interpretação e Conclusão

  • Reportar: “há evidências estatísticas de que a média de builds até a primeira falha é inferior a 80”.
  • Recomendar revisão da suíte de testes, hardening do pipeline, pré-validação de dependências, gates de qualidade.
  • Limites: 30 sequências, possível não estacionariedade do pipeline ao longo do ano.

EQUIPE 5 — TEMPO ENTRE INCIDENTES DE SRE (EXPONENCIAL)

5.1 Contexto

A SREWatch Operações S.A. monitora a infraestrutura de uma plataforma SaaS. O plano de continuidade estabelece que o tempo médio entre incidentes (MTBI) deve ser de pelo menos 200 horas. A equipe suspeita que o MTBI esteja abaixo da meta, especialmente após mudanças recentes no deploy.

5.2 Problema de Engenharia de Software

Verificar se o MTBI é inferior a 200 horas, com base em 30 registros de incidentes.

5.3 Base de Dados

Tabela 1 — Tempo entre incidentes (em horas) — 30 registros (2024–2025).

Registro Tempo (h) Registro Tempo (h) Registro Tempo (h)
1 150 11 190 21 160
2 220 12 130 22 210
3 140 13 250 23 145
4 180 14 170 24 195
5 165 15 200 25 175
6 240 16 155 26 220
7 135 17 185 27 130
8 260 18 210 28 200
9 145 19 170 29 180
10 175 20 165 30 155

5.4 Perguntas

  • Pergunta principal: O MTBI é inferior a 200 horas?
  • Pergunta secundária 1: A variável pode ser razoavelmente modelada por uma Exponencial? Justifique.
  • Pergunta secundária 2: Construir um IC 95 % para o MTBI.

5.5 Análise Estatística Esperada

  • Estatística descritiva: média ≈ 179, desvio padrão, histograma.
  • Modelo probabilístico: Exponencial com média amostral. Justificar por processos sem memória (taxa de incidente aproximadamente constante).
  • Probabilidade: P(X < 100) = 1 − exp(−100/179).
  • Inferência: IC 95 % para a média da Exponencial via qui-quadrado.
  • Teste de hipótese: t unilateral à esquerda (H₀: μ = 200 contra H₁: μ < 200), α = 0,05. Resultado esperado: não rejeitar H₀ (t ≈ −2,65; valor-p ≈ 0,007 — borderline; se a equipe usar t com df = 29, fica em 0,007, ainda rejeita). Equipe deve discutir a potência do teste e a proximidade com o limite.
  • Gráfico sugerido: histograma com a curva Exponencial sobreposta (μ̂ = 179).

5.6 Orientação para Interpretação e Conclusão

  • Reportar com cautela: a média está abaixo da meta, mas a evidência estatística depende do teste escolhido.
  • Recomendar combinar o resultado com o impacto operacional dos incidentes antes de decidir por mudanças estruturais.
  • Limites: amostra de 30 registros, possível mistura de tipos de incidente (rede, aplicação, banco), ausência de estratificação.

EQUIPE 6 — REPROCESSOS POR SPRINT COM SUPERDISPERSÃO (BINOMIAL NEGATIVA)

6.1 Contexto

A SprintForge Tecnologia S.A. mede o número de itens reabertos por sprint (reprocessos) em um squad. A média histórica aceitável é de até 3 reaberturas por sprint. O controle de processo tem registrado superdispersão: algumas sprints apresentam muitos reprocessos, enquanto outras têm quase nenhum. A engenharia quer avaliar se a média está acima do limite, e se a variabilidade justifica o uso de um modelo mais flexível que a Poisson.

6.2 Problema de Engenharia de Software

Verificar se a média de reprocessos por sprint é superior a 3, com base em 30 sprints.

6.3 Base de Dados

Tabela 1 — Reprocessos por sprint (30 sprints, 2025).

Sprint Reprocessos Sprint Reprocessos Sprint Reprocessos
1 4 11 5 21 6
2 2 12 3 22 4
3 6 13 7 23 5
4 3 14 4 24 3
5 5 15 8 25 7
6 8 16 5 26 4
7 3 17 3 27 6
8 4 18 7 28 5
9 6 19 4 29 3
10 2 20 6 30 4

6.4 Perguntas

  • Pergunta principal: A média de reprocessos por sprint é superior a 3?
  • Pergunta secundária 1: Por que a Poisson é inadequada neste cenário e a Binomial Negativa é mais indicada? (usar a razão variância/média).
  • Pergunta secundária 2: Ajuste uma Binomial Negativa e estime seus parâmetros.

6.5 Análise Estatística Esperada

  • Estatística descritiva: média ≈ 4,6, variância ≈ 2,5 (superdispersão), histograma.
  • Modelo probabilístico: Binomial Negativa com parâmetros estimados por máxima verossimilhança ou método dos momentos.
  • Probabilidade: P(X ≥ 6) sob Binomial Negativa ajustada.
  • Inferência: IC 95 % para a média (via t-Student, já que a Binomial Negativa converge para Normal em amostras grandes).
  • Teste de hipótese: t unilateral à direita (H₀: μ = 3 contra H₁: μ > 3), α = 0,05. Resultado esperado: rejeitar H₀ (x̄ ≈ 4,6; valor-p ≈ 1,6·10⁻⁸).
  • Gráfico sugerido: histograma com a curva Binomial Negativa e a Poisson sobrepostas (evidenciar a superdispersão).

6.6 Orientação para Interpretação e Conclusão

  • Reportar: “há evidências estatísticas de que a média é superior a 3, com variabilidade superior à prevista por uma Poisson”.
  • Recomendar investigar causas especiais de variabilidade (dívida técnica, mudança de requisito, dependências entre squads) — a superdispersão sugere causas sistemáticas.
  • Limites: amostra de 30 sprints, Binomial Negativa com r estimado tem maior incerteza que a Poisson.

EQUIPE 7 — DEFEITOS EM UAT (BINOMIAL, REJEITA)

7.1 Contexto

A QualityForge Testes S.A. realiza testes de aceitação (UAT) em entregas de módulos críticos. A norma interna admite uma taxa máxima de defeitos críticos de 5 % dos casos de teste executados. Acima desse limite, a entrega é bloqueada até saneamento. A engenharia de QA tem registrado taxas acima do limite.

7.2 Problema de Engenharia de Software

Verificar se a taxa de defeitos críticos é superior a 5 %, com base em 30 ciclos de UAT.

7.3 Base de Dados

Tabela 1 — Casos executados e defeitos críticos em 30 ciclos de UAT (2025).

Ciclo Casos Defeitos Ciclo Casos Defeitos Ciclo Casos Defeitos
1 200 14 11 200 18 21 200 12
2 200 16 12 200 13 22 200 15
3 200 12 13 200 19 23 200 14
4 200 17 14 200 12 24 200 18
5 200 13 15 200 16 25 200 13
6 200 19 16 200 14 26 200 17
7 200 15 17 200 20 27 200 12
8 200 13 18 200 16 28 200 19
9 200 18 19 200 14 29 200 15
10 200 12 20 200 13 30 200 16

7.4 Perguntas

  • Pergunta principal: A taxa de defeitos críticos é superior a 5 %?
  • Pergunta secundária 1: Construir um IC 95 % para a verdadeira taxa de defeitos críticos.
  • Pergunta secundária 2: Qual a proporção de ciclos com taxa acima do limite?

7.5 Análise Estatística Esperada

  • Estatística descritiva: proporção média ≈ 0,075, desvio padrão, histograma.
  • Modelo probabilístico: Binomial com n = 200 e p̂ amostral.
  • Probabilidade: P(X ≥ 18) com p̂ ≈ 0,075.
  • Inferência: IC 95 % para a proporção (Wilson ou Normal com correção).
  • Teste de hipótese: Z unilateral à direita para proporção (H₀: p = 0,05 contra H₁: p > 0,05), α = 0,05. Resultado esperado: rejeitar H₀ (Z ≈ 5,15; valor-p ≈ 1,3·10⁻⁷).
  • Gráfico sugerido: barras com a taxa por ciclo e linha de 5 %; opcionalmente Pareto dos módulos com mais defeitos.

7.6 Orientação para Interpretação e Conclusão

  • Reportar: “ao nível de 5 %, há evidências estatísticas de que a taxa é superior a 5 %”.
  • Recomendar ações (revisão dos critérios de aceitação, saneamento de débito técnico, ampliação de cobertura, gate de qualidade automatizado).
  • Limites: amostra restrita a um produto, ausência de estratificação por módulo.

EQUIPE 8 — ACESSOS INVÁLIDOS POR DIA EM API (POISSON)

8.1 Contexto

A ShieldWare Security S.A. monitora tentativas de acesso inválido (token expirado, IP bloqueado, credencial inválida) em uma API pública. A política de segurança admite no máximo 8 acessos inválidos por dia em regime normal. A equipe de SOC suspeita que a média esteja acima do limite, possivelmente indicando tentativa de ataque.

8.2 Problema de Engenharia de Software

Verificar se a média diária de acessos inválidos é superior a 8, com base em 30 dias.

8.3 Base de Dados

Tabela 1 — Acessos inválidos por dia (30 dias, outubro/2025).

Dia Acessos Dia Acessos Dia Acessos
1 9 11 12 21 10
2 11 12 10 22 13
3 8 13 14 23 9
4 13 14 10 24 12
5 10 15 11 25 11
6 14 16 9 26 14
7 11 17 13 27 10
8 10 18 12 28 12
9 15 19 9 29 11
10 12 20 11 30 13

8.4 Perguntas

  • Pergunta principal: A média diária de acessos inválidos é superior a 8?
  • Pergunta secundária 1: A variável pode ser razoavelmente modelada por Poisson? (verificar razão variância/média).
  • Pergunta secundária 2: Construir um IC 95 % para a média diária.

8.5 Análise Estatística Esperada

  • Estatística descritiva: média ≈ 11,2, variância ≈ 3,2, histograma.
  • Modelo probabilístico: Poisson com λ̂ = média amostral.
  • Probabilidade: P(X ≥ 14) sob Poisson(11,2).
  • Inferência: IC 95 % para λ via qui-quadrado.
  • Teste de hipótese: t unilateral à direita (H₀: μ = 8 contra H₁: μ > 8), α = 0,05. Resultado esperado: rejeitar H₀ (t ≈ 10,5; valor-p ≈ 2·10⁻¹¹).
  • Gráfico sugerido: histograma com a curva Poisson sobreposta (λ = 11,2).

8.6 Orientação para Interpretação e Conclusão

  • Reportar: “há evidências estatísticas de que a média diária é superior a 8”.
  • Recomendar ações (revisão de rate limit, ativação de CAPTCHA, bloqueio de IP, análise de padrão do atacante, MFA em endpoints sensíveis).
  • Limites: amostra de 30 dias, ausência de estratificação por endpoint e por tipo de falha.

EQUIPE 9 — NÚMERO DE CODE REVIEWS ATÉ APROVAÇÃO (GEOMÉTRICA, NÃO REJEITA)

9.1 Contexto

A CodeReview Academy S.A. adota um processo em que cada pull request passa por revisões sucessivas até a aprovação final. O programa de qualidade espera que a média de rodadas de revisão por PR seja de no máximo 2,5. A engenharia acredita que o processo esteja dentro da meta.

9.2 Problema de Engenharia de Software

Verificar se a média de rodadas de revisão por PR é superior a 2,5, com base em 30 PRs.

9.3 Base de Dados

Tabela 1 — Número de rodadas de revisão por PR (30 PRs, 2025).

PR Rodadas PR Rodadas PR Rodadas
1 2 11 3 21 2
2 1 12 2 22 3
3 2 13 2 23 1
4 3 14 1 24 2
5 2 15 3 25 2
6 1 16 2 26 1
7 2 17 2 27 3
8 3 18 1 28 2
9 2 19 2 29 2
10 1 20 2 30 1

9.4 Perguntas

  • Pergunta principal: A média de rodadas de revisão por PR é superior a 2,5?
  • Pergunta secundária 1: Qual a probabilidade de um PR precisar de 4 ou mais rodadas de revisão, admitindo Geométrica com p̂ = 1/1,9?
  • Pergunta secundária 2: Construir um IC 95 % para a média da distribuição.

9.5 Análise Estatística Esperada

  • Estatística descritiva: média ≈ 1,9, desvio padrão, histograma.
  • Modelo probabilístico: Geométrica (nº de tentativas até o 1º sucesso = “aprovação”). Justificar por ensaios de Bernoulli independentes.
  • Probabilidade: P(X ≥ 4) com p̂ = 1/1,9.
  • Inferência: IC 95 % para μ = 1/p.
  • Teste de hipótese: t unilateral à direita (H₀: μ = 2,5 contra H₁: μ > 2,5), α = 0,05. Resultado esperado: não rejeitar H₀ (t ≈ −8,3; valor-p ≈ 1,0 — média bem abaixo da meta).
  • Gráfico sugerido: histograma com a curva Geométrica sobreposta (p̂ = 1/1,9).

9.6 Orientação para Interpretação e Conclusão

  • Reportar: “ao nível de 5 %, não há evidências estatísticas de que a média de rodadas seja superior a 2,5”.
  • Recomendar manter o processo, com monitoria contínua do lead time de revisão.
  • Limites: 30 PRs, ausência de estratificação por tamanho do PR e por complexidade do módulo.

EQUIPE 10 — VARIABILIDADE DA LATÊNCIA EM API (QUI-QUADRADO PARA VARIÂNCIA, BORDERLINE)

10.1 Contexto

A APIxpress Gateway S.A. opera uma API REST pública. O SLA de UX exige que o desvio padrão da latência não ultrapasse 30 ms, para garantir uma experiência P95 consistente. A engenharia de SRE suspeita que a variabilidade esteja próxima do limite após uma mudança de infraestrutura.

10.2 Problema de Engenharia de Software

Verificar se o desvio padrão da latência é superior a 30 ms, com base em 30 medições.

10.3 Base de Dados

Tabela 1 — Latência (em ms) de 30 requisições (amostra de produção, outubro/2025).

Amostra Latência Amostra Latência Amostra Latência
1 180 11 195 21 175
2 210 12 200 22 220
3 195 13 215 23 185
4 220 14 180 24 205
5 200 15 210 25 195
6 215 16 200 26 215
7 185 17 220 27 190
8 205 18 195 28 210
9 200 19 200 29 200
10 190 20 185 30 205

10.4 Perguntas

  • Pergunta principal: O desvio padrão da latência é superior a 30 ms?
  • Pergunta secundária 1: Construir um IC 95 % para a variância σ².
  • Pergunta secundária 2: Calcule o P95 empírico e compare com o limite de UX.

10.5 Análise Estatística Esperada

  • Estatística descritiva: média ≈ 201,3, desvio padrão ≈ 13,2, histograma, boxplot.
  • Modelo probabilístico: Normal (latência é contínua; verificar pelo histograma).
  • Inferência: IC 95 % para σ²: ((n−1)·s²/χ²ₐ/₂, (n−1)·s²/χ²₁₋ₐ/₂).
  • Teste de hipótese: qui-quadrado unilateral à direita (H₀: σ² = 30² contra H₁: σ² > 30²), α = 0,05. Estatística: χ² = (n−1)·s²/σ₀². Resultado esperado: não rejeitar H₀ (s ≈ 13,2; χ² ≈ 5,8; crítico ≈ 42,6 — muito abaixo do crítico).
  • Gráfico sugerido: histograma com a curva Normal sobreposta; boxplot.

10.6 Orientação para Interpretação e Conclusão

  • Reportar: “ao nível de 5 %, não há evidências estatísticas de que σ seja superior a 30 ms”.
  • Recomendar manter o controle atual, com monitoria contínua de P95 e P99.
  • Limites: amostra de 30 requisições, normalidade presumida (verificar pelo histograma e por testes de normalidade se disponível).

EQUIPE 11 — PULL REQUESTS ABERTAS POR DIA COM SUPERDISPERSÃO (BINOMIAL NEGATIVA)

11.1 Contexto

A CodeForge Open S.A. mede o número de pull requests abertas por dia em uma organização com 200 contribuidores. A média histórica aceitável é de até 12 PRs por dia. A operação tem registrado superdispersão: dias de lançamento concentram dezenas de PRs, enquanto dias comuns têm poucas. A engenharia de DevEx quer avaliar se a média está acima do limite e se a variabilidade justifica um modelo mais flexível que a Poisson.

11.2 Problema de Engenharia de Software

Verificar se a média diária de PRs abertas é superior a 12, com base em 30 dias.

11.3 Base de Dados

Tabela 1 — PRs abertas por dia (30 dias, outubro/2025).

Dia PRs Dia PRs Dia PRs
1 14 11 18 21 16
2 10 12 12 22 20
3 22 13 16 23 14
4 12 14 24 24 18
5 16 15 14 25 22
6 20 16 13 26 16
7 14 17 18 27 20
8 18 18 22 28 14
9 24 19 16 29 18
10 13 20 19 30 17

11.4 Perguntas

  • Pergunta principal: A média diária de PRs abertas é superior a 12?
  • Pergunta secundária 1: Por que a Poisson é inadequada neste cenário? (usar razão variância/média).
  • Pergunta secundária 2: Ajuste uma Binomial Negativa e estime seus parâmetros.

11.5 Análise Estatística Esperada

  • Estatística descritiva: média ≈ 16,7, variância ≈ 12,5 (superdispersão), histograma.
  • Modelo probabilístico: Binomial Negativa com parâmetros estimados.
  • Probabilidade: P(X ≥ 22) sob Binomial Negativa ajustada.
  • Inferência: IC 95 % para a média (via t-Student).
  • Teste de hipótese: t unilateral à direita (H₀: μ = 12 contra H₁: μ > 12), α = 0,05. Resultado esperado: rejeitar H₀ (x̄ ≈ 16,7; valor-p ≈ 2,3·10⁻⁹).
  • Gráfico sugerido: histograma com Binomial Negativa e Poisson sobrepostas.

11.6 Orientação para Interpretação e Conclusão

  • Reportar: “há evidências estatísticas de que a média é superior a 12, com variabilidade superior à prevista por uma Poisson”.
  • Recomendar investigar causas especiais de variabilidade (datas de release sprints, freeze de código, hackathons) e ajustar a capacidade de revisão.
  • Limites: amostra de 30 dias, Binomial Negativa com r estimado tem maior incerteza que a Poisson.

EQUIPE 12 — CONVERSÃO DE CHECKOUT EM E-COMMERCE (BINOMIAL COM σ HISTÓRICO)

12.1 Contexto

A UXtrack Analytics S.A. monitora a taxa de conversão de checkout de um e-commerce. A referência de mercado é de 65 % de conversão. O desvio padrão histórico do percentual de conversão, controlado por CEP nos últimos 12 meses, é σ = 4 %. O time de produto quer testar se a taxa atual está abaixo da referência, usando a referência histórica de variabilidade.

12.2 Problema de Engenharia de Software

Verificar se a taxa de conversão de checkout é inferior a 65 %, com base em 30 semanas e σ histórico conhecido.

12.3 Base de Dados

Tabela 1 — Taxa de conversão de checkout (%) em 30 semanas (janeiro/2024 a junho/2025).

Semana Conversão (%) Semana Conversão (%) Semana Conversão (%)
1 60 11 63 21 61
2 62 12 60 22 64
3 58 13 65 23 60
4 61 14 62 24 63
5 64 15 59 25 58
6 59 16 61 26 62
7 63 17 64 27 60
8 60 18 60 28 61
9 62 19 63 29 59
10 58 20 61 30 60

Resumo: p̂ = 0,611 (média), σ histórico = 0,04.

12.4 Perguntas

  • Pergunta principal: A taxa de conversão é inferior a 65 % (referência)?
  • Pergunta secundária 1: Construir um IC 95 % para a taxa de conversão usando o σ histórico.
  • Pergunta secundária 2: Por que, neste cenário, o teste Z com σ conhecido é mais adequado que o teste Z com p̂ estimado?

12.5 Análise Estatística Esperada

  • Estatística descritiva: proporção amostral, valor de σ histórico.
  • Modelo probabilístico: aproximação Normal para a proporção.
  • Inferência: IC 95 % para p usando σ conhecido: p̂ ± z_{α/2} · σ.
  • Teste de hipótese: Z unilateral à esquerda para proporção (H₀: p = 0,65 contra H₁: p < 0,65), α = 0,05, com σ = 0,04. Estatística: Z = (p̂ − 0,65)/σ. Resultado esperado: rejeitar H₀ (Z = (0,611 − 0,65)/0,04 = −0,98 — se σ = 0,04, valor-p ≈ 0,16; se σ = 0,02, valor-p ≈ 0,007. Equipe deve explorar o impacto do σ no resultado).
  • Gráfico sugerido: gráfico de linhas temporal da conversão com a linha de referência de 65 %.

12.6 Orientação para Interpretação e Conclusão

  • Reportar com clareza sobre o σ usado: o resultado depende criticamente do σ histórico adotado.
  • Recomendar ações (testes A/B no checkout, simplificação do formulário, múltiplas formas de pagamento, redução de campos obrigatórios, análise de abandono por etapa).
  • Limites: σ histórico pode não representar a variabilidade atual; verificar estabilidade do processo por carta de controle antes de aplicar.

EQUIPE 13 — TEMPO DE EXECUÇÃO DA SUITE DE TESTES (TESTE t, NÃO REJEITA)

13.1 Contexto

A TestForge Automação S.A. monitora o tempo médio de execução da suíte de testes automatizados. A meta do programa de CI é de até 8 minutos por execução. O σ populacional é desconhecido e deve ser estimado a partir da amostra. A engenharia acredita que o tempo esteja dentro da meta, com pequena margem.

13.2 Problema de Engenharia de Software

Verificar se o tempo médio de execução é superior a 8 minutos, com base em 30 execuções e σ desconhecido.

13.3 Base de Dados

Tabela 1 — Tempo de execução (em minutos) — 30 execuções (setembro–outubro/2025).

Execução Tempo Execução Tempo Execução Tempo
1 7,8 11 8,2 21 7,5
2 8,1 12 7,9 22 8,3
3 7,6 13 8,4 23 7,7
4 8,0 14 7,8 24 8,1
5 7,9 15 8,0 25 7,6
6 8,3 16 7,7 26 8,2
7 7,5 17 8,1 27 7,8
8 8,2 18 7,9 28 8,0
9 7,7 19 8,3 29 7,6
10 8,0 20 7,8 30 7,9

13.4 Perguntas

  • Pergunta principal: O tempo médio de execução é superior a 8 minutos?
  • Pergunta secundária 1: Construir um IC 95 % para o tempo médio.
  • Pergunta secundária 2: Se a suíte crescer 20 %, qual seria o impacto esperado no tempo médio?

13.5 Análise Estatística Esperada

  • Estatística descritiva: média ≈ 7,9, desvio padrão ≈ 0,25, histograma, boxplot.
  • Modelo probabilístico: Normal (tempo de execução é contínuo; n = 30, TLC).
  • Inferência: IC 95 % para μ com σ desconhecido: x̄ ± t_{α/2, n−1} · s/√n.
  • Teste de hipótese: t unilateral à direita (H₀: μ = 8 contra H₁: μ > 8), α = 0,05, com σ desconhecido. Estatística: t = (x̄ − 8)/(s/√n). Resultado esperado: não rejeitar H₀ (t ≈ −2,2; valor-p ≈ 0,98 — média abaixo da meta).
  • Gráfico sugerido: histograma com a curva Normal sobreposta; boxplot.

13.6 Orientação para Interpretação e Conclusão

  • Reportar: “ao nível de 5 %, não há evidências estatísticas de que o tempo médio seja superior a 8 minutos”.
  • Recomendar manter o controle, com paralelização e sharding se a suíte crescer.
  • Limites: σ estimado de 30 observações, ausência de estratificação por tipo de teste (unitário, integração, E2E).

EQUIPE 14 — LATÊNCIA EM CONSULTAS SQL (Z PARA MÉDIA, σ CONHECIDO, NÃO REJEITA)

14.1 Contexto

A DataPulse Sistemas S.A. monitora a latência de consultas SQL em um data warehouse. A meta de SLA é de 200 ms. O desvio padrão histórico do processo, controlado por CEP nos últimos 24 meses, é σ = 15 ms. O time de banco de dados quer testar se a latência média atual está acima da meta, usando a referência histórica.

14.2 Problema de Engenharia de Software

Verificar se a latência média é superior a 200 ms, com base em 30 medições e σ histórico conhecido.

14.3 Base de Dados

Tabela 1 — Latência (em ms) de 30 consultas (outubro/2025).

Consulta Latência Consulta Latência Consulta Latência
1 195 11 200 21 192
2 205 12 198 22 210
3 198 13 210 23 195
4 210 14 195 24 200
5 200 15 205 25 198
6 215 16 200 26 210
7 195 17 215 27 192
8 205 18 200 28 205
9 200 19 198 29 200
10 198 20 205 30 195

Resumo: x̄ = 202,0 ms, σ histórico = 15 ms.

14.4 Perguntas

  • Pergunta principal: A latência média é superior a 200 ms (meta), considerando σ histórico conhecido?
  • Pergunta secundária 1: Construir um IC 95 % para a média usando o σ histórico.
  • Pergunta secundária 2: Compare o resultado deste teste com o que seria obtido pelo teste t. Em que situação eles coincidem?

14.5 Análise Estatística Esperada

  • Estatística descritiva: média amostral, desvio padrão amostral, histograma.
  • Modelo probabilístico: Normal (latência é contínua; σ conhecido por CEP).
  • Inferência: IC 95 % para μ com σ conhecido: x̄ ± z_{α/2} · σ/√n.
  • Teste de hipótese: Z unilateral à direita (H₀: μ = 200 contra H₁: μ > 200), α = 0,05, com σ = 15. Estatística: Z = (x̄ − 200)/(σ/√n). Resultado esperado: não rejeitar H₀ (x̄ = 202; Z = 2/2,74 = 0,73; valor-p ≈ 0,23).
  • Gráfico sugerido: histograma com a curva Normal sobreposta e a linha da meta.

14.6 Orientação para Interpretação e Conclusão

  • Reportar: “ao nível de 5 %, não há evidências estatísticas de que a latência média esteja acima da meta”.
  • Recomendar manter o processo, com monitoria contínua por APM.
  • Limites: σ histórico assume estabilidade do processo; se houver mudança de esquema, índice ou versão do banco, σ deve ser reestimado.

EQUIPE 15 — TENTATIVAS DE LOGIN ATÉ SUCESSO (GEOMÉTRICA, BORDERLINE)

15.1 Contexto

A AccessGuard Identity S.A. monitora tentativas de login em um sistema corporativo. Conta-se o número de tentativas até o primeiro login bem-sucedido (incluindo a bem-sucedida). A política de UX espera que 80 % dos usuários consigam logar na primeira tentativa (média da Geométrica ≤ 1,25). A engenharia suspeita que o sistema esteja próximo da meta, sem conseguir afirmar com clareza se está acima ou abaixo.

15.2 Problema de Engenharia de Software

Verificar se a média de tentativas até o sucesso é superior a 1,25, com base em 30 sessões de login.

15.3 Base de Dados

Tabela 1 — Número de tentativas de login até sucesso (30 sessões, 2025).

Sessão Tentativas Sessão Tentativas Sessão Tentativas
1 1 11 2 21 1
2 1 12 1 22 2
3 2 13 1 23 1
4 1 14 3 24 1
5 1 15 1 25 2
6 2 16 1 26 1
7 1 17 1 27 1
8 1 18 2 28 3
9 3 19 1 29 1
10 1 20 1 30 1

15.4 Perguntas

  • Pergunta principal: A média de tentativas é superior a 1,25 (meta de UX)?
  • Pergunta secundária 1: Construir um IC 95 % para a média da distribuição.
  • Pergunta secundária 2: Se a meta for borderline, que outras evidências devem ser buscadas para decidir?

15.5 Análise Estatística Esperada

  • Estatística descritiva: média ≈ 1,33, desvio padrão, histograma.
  • Modelo probabilístico: Geométrica (nº de tentativas até o 1º sucesso). Justificar por ensaios de Bernoulli independentes (sucesso = login correto).
  • Probabilidade: P(X = 1) com p̂ = 1/1,33.
  • Inferência: IC 95 % para μ = 1/p.
  • Teste de hipótese: t unilateral à direita (H₀: μ = 1,25 contra H₁: μ > 1,25), α = 0,05. Resultado esperado: borderline (t ≈ 0,68; valor-p ≈ 0,25 — estatística não conclusiva).
  • Gráfico sugerido: histograma com a curva Geométrica sobreposta (p̂ = 1/1,33).

15.6 Orientação para Interpretação e Conclusão

  • Discutir o caso borderline: a estatística, isoladamente, não resolve.
  • Recomendar complementar com análise qualitativa (logs de erro, UX do formulário de login, taxa de MFA, perfil de dispositivo) e, se possível, ampliar a amostra.
  • Limites: amostra de 30 sessões, possível mistura de usuários novos e recorrentes, ausência de estratificação.

PARTE 3 — RUBRICA DE AVALIAÇÃO DO PROJETO INTEGRADOR

A avaliação do PI é feita por equipe, em escala de 0 a 10 pontos, distribuídos em cinco critérios ponderados.

Critério Descrição Pontuação Máxima
1. Clareza do problema e aderência ao contexto Capacidade da equipe de apresentar o problema de Engenharia de Software com clareza, situando o cenário, o processo em análise e a relevância da questão para a tomada de decisão técnica. 2,0
2. Organização e qualidade dos dados Apresentação completa da base de dados em tabela, identificação correta das variáveis e das escalas de medição, consistência e integridade dos dados, registro das fontes ou do processo de geração. 2,0
3. Aplicação correta dos conceitos estatísticos Uso correto das técnicas estatísticas: estatística descritiva, probabilidade com modelo teórico adequado, intervalo de confiança e teste de hipótese para uma única amostra. Coerência entre a técnica escolhida, o tipo de variável e a pergunta do problema. 3,0
4. Interpretação, conclusão e limites da análise Interpretação correta dos resultados em linguagem técnica, articulação com o problema de software, recomendações fundamentadas e discussão explícita dos limites da análise (amostra, escopo, possíveis vieses, generalização). 2,0
5. Comunicação técnica e apresentação Qualidade do relatório escrito, correção gramatical, uso adequado de tabelas e gráficos com títulos, legendas e fontes, domínio do tempo no seminário, clareza na exposição oral, postura e resposta à arguição. 1,0
Total 10,0

3.1 Critérios de Desempate e Observações Complementares

  • Trabalhos entregues fora do prazo sofrerão desconto de 0,5 ponto por dia útil de atraso, até o limite de 2,0 pontos.
  • Caso duas ou mais equipes terminem empatadas, será considerado, como critério de desempate, o domínio técnico demonstrado na arguição oral.
  • Relatórios entregues sem a base de dados em tabela serão penalizados em 1,0 ponto no critério 2.
  • Gráficos sem título, sem legenda de eixos ou sem fonte serão penalizados em 0,5 ponto por gráfico no critério 5.
  • A simples apresentação de fórmulas ou resultados numéricos, sem interpretação no contexto do problema, implica nota zero no critério 4.
  • O uso de modelo probabilístico inadequado ao tipo de variável (por exemplo, Normal para contagens sem justificativa) implica penalização de até 1,0 ponto no critério 3.
  • Em cenários com dados reais, o descumprimento de boas práticas de proteção de dados (anonimização, minimização) implica penalização de até 1,0 ponto no critério 4.
  • O uso de IA generativa (ChatGPT, Copilot, etc.) deve ser explicitamente creditado; trechos não creditados serão tratados como produção da equipe e verificados na arguição.

3.2 Escala Qualitativa de Referência (para devolutiva)

Faixa Conceito Descrição Sintética
9,0 a 10,0 Excelente Domínio pleno, com interpretação crítica e recomendações fundamentadas.
7,0 a 8,9 Bom Domínio consistente, com pequenas lacunas de interpretação.
5,0 a 6,9 Regular Aplicação correta das técnicas, mas com interpretação superficial.
3,0 a 4,9 Insuficiente Erros conceituais relevantes ou ausência de itens obrigatórios.
0,0 a 2,9 Insatisfatório Trabalho não atende aos requisitos mínimos do PI.

PARTE 4 — OBSERVAÇÕES FINAIS AOS ALUNOS

4.1 Limites da Análise Estatística

  • Os resultados obtidos refletem apenas a amostra coletada e as condições registradas no período de análise. Generalizações devem ser feitas com cautela.
  • Toda conclusão estatística está associada a uma margem de erro e a um nível de confiança. Não confundir “ausência de evidência” com “evidência de ausência”.
  • O tamanho da amostra influencia a precisão do intervalo de confiança e a potência do teste de hipótese. Amostras pequenas podem não detectar desvios relevantes.
  • A normalidade dos dados é um pressuposto para o teste t e Z. Em amostras pequenas, recomenda-se avaliar a forma do histograma e, se possível, realizar testes de normalidade. Desvios acentuados devem ser reportados.
  • Para o teste de proporção, o produto n·p e n·(1 − p) deve ser maior ou igual a 5 para que a aproximação pela Normal seja adequada.
  • A modelagem por Binomial, Poisson, Hipergeométrica, Geométrica, Binomial Negativa e Exponencial deve ser avaliada quanto à sua aderência ao fenômeno, e não assumida como verdade. Em particular: Poisson exige variância ≈ média; Hipergeométrica exige amostragem sem reposição em população finita; Binomial Negativa é indicada quando há superdispersão (variância > média); Geométrica é adequada para “número de tentativas até o 1º sucesso”.
  • O uso de σ histórico no teste Z é aceitável apenas se o processo estiver estável (sem mudança de arquitetura, deploy, fornecedor de nuvem ou método de coleta). Caso contrário, σ deve ser estimado da própria amostra e usa-se o teste t.

4.2 Ética, Proteção de Dados e Autoria

  • Os dados deste PI são fictícios e foram elaborados com fins didáticos, mas devem ser tratados com o mesmo rigor que dados reais exigem.
  • É vedada a manipulação intencional de dados para obter resultados favoráveis. Se necessário, os dados podem ser depurados, com registro explícito do critério utilizado.
  • Em cenários com dados reais, deve-se observar a legislação aplicável de proteção de dados (LGPD), anonimizando identificadores pessoais e minimizando a coleta ao necessário.
  • O uso de IA generativa (ChatGPT, Copilot, Gemini, etc.) é permitido como apoio à revisão de texto, sugestão de hipóteses e geração de códigos, mas a equipe é integralmente responsável pela veracidade dos cálculos e pela coerência das interpretações. Todo trecho gerado por IA deve ser explicitamente creditado no relatório.
  • Citações a fontes externas (livros, artigos, manuais, documentação oficial) devem seguir as normas da ABNT ou APA, conforme orientação do docente.
  • A autoria do trabalho é da equipe. Cópias, ainda que parciais, serão tratadas como plágio.

4.3 Coerência e Comunicação Técnica

  • O texto deve usar terminologia estatística precisa (por exemplo, “evidências estatísticas de que…”, “ao nível de 5 % de significância, rejeita-se H₀”), evitando afirmações categóricas como “comprovou-se que…”.
  • O gráfico deve ter título claro, rótulos nos eixos, legenda (quando necessário) e fonte. Cores devem ter função, não apenas efeito estético.
  • As conclusões devem articular o resultado estatístico com a decisão de engenharia (ex.: “há evidências estatísticas de que a taxa de bugs críticos está acima do limite; recomenda-se reforçar code review e ampliar cobertura de testes automatizados”).
  • Em cenários com resultado borderline (valor-p próximo de α), a equipe deve explicitar a incerteza e discutir o que isso significa para a decisão, em vez de “forçar” uma conclusão.
  • A apresentação oral deve respeitar o tempo e priorizar a síntese: problema, método, resultado principal, conclusão e recomendação. Cálculos detalhados ficam no relatório escrito.

4.4 Sugestões de Boas Práticas

  • Construir a base de dados em planilha eletrônica desde o início, registrando unidades de medida, timestamps e data de coleta.
  • Usar, quando possível, ferramentas de observabilidade (Grafana, Datadog, New Relic, Kibana) para extrair amostras do mundo real, mesmo que o PI utilize dados sintéticos.
  • Conferir se as perguntas do cenário estão todas respondidas no relatório, com a técnica estatística adequada a cada uma.
  • Revisar o relatório com atenção à coerência entre as perguntas, a análise, a conclusão e as referências.
  • Ensaiar a apresentação oral, cronometrando o tempo e definindo quem apresenta cada parte.
  • Ao utilizar software (Excel, Google Sheets, LibreOffice Calc, R, Python, Minitab, Jupyter), registrar no relatório as fórmulas ou comandos utilizados, para garantir rastreabilidade e transparência.
  • Ao ajustar modelos (Binomial Negativa, Exponencial, Geométrica), comparar visualmente a curva ajustada com o histograma e reportar a qualidade do ajuste.

FIM DO PROJETO INTEGRADOR — PROBABILIDADE E ESTATÍSTICA (ENGENHARIA DE SOFTWARE)