Questionário e Gabarito - Aula 2: Viabilidade e Estrutura (2026-2)

Este documento contém as questões que devem ser enviadas aos alunos via GitLab Issues para o Sprint 2 (Aula 2). O prazo final geral (Milestone) é 23/08/2026. A Questão 1 tem prazo individual para 20/08/2026.

Questão 1: Avaliação TELOS na Prática

Due Date: 2026-08-20

Texto da Issue

Em uma avaliação TELOS, sua equipe percebe que não faz ideia de como criptografar os dados dos usuários na nuvem, e não há orçamento para terceirizar esse serviço. Quais viabilidades (das 5 dimensões do framework TELOS) foram feridas diretamente nessa situação e por quê?

Gabarito / Rubrica de Correção

Excelente (10): Identifica e explica a Viabilidade Técnica (falta de conhecimento técnico da equipe) e a Viabilidade Econômica (falta de orçamento para terceirizar). Pode mencionar também a Legal (dados expostos ferem a LGPD).
Bom (7): Identifica a técnica e a econômica, mas não justifica corretamente usando os conceitos.
Insuficiente (0): Cita as viabilidades incorretas ou não sabe o que é o modelo TELOS.

Questão 2: O Perigo dos Objetivos Vagos

Due Date: 2026-08-23

Texto da Issue

Por que definir um objetivo do tipo “Fazer um chatbot inteligente que ajude alunos” não é considerado um objetivo SMART? Reescreva este objetivo aplicando a estrutura SMART completa (Específico, Mensurável, Atingível, Relevante e Temporal) para o nosso contexto do Projeto Integrador.

Gabarito / Rubrica de Correção

Excelente (10): Explica que a frase original é vaga e não permite medir sucesso. Apresenta uma frase reescrita cobrindo todos os pontos do SMART (Ex: “Desenvolver um bot socrático via API Gemini [Específico/Atingível] com 90% de precisão [Mensurável] para reduzir dúvidas de algoritmos [Relevante] até o fim do semestre [Temporal]”).
Bom (7): Entende o problema do objetivo vago e tenta reescrever, mas esquece 1 ou 2 letras do modelo SMART.
Insuficiente (0): Apenas critica a frase original sem conseguir reescrevê-la ou não sabe o que é SMART.

Questão 3: O Project Charter como Escudo

Due Date: 2026-08-23

Texto da Issue

Imagine que, no meio do desenvolvimento, o cliente te encurrala no corredor e pede “só mais uma funcionalidade urgente e bem pequenininha”. Como você, no papel de Gerente de Projetos, usaria o documento do Project Charter (Termo de Abertura) como escudo pessoal para proteger a sua equipe contra o temido Scope Creep?

Gabarito / Rubrica de Correção

Excelente (10): Argumenta que o Charter é o “contrato” inicial assinado. Usaria o documento para mostrar que a funcionalidade não está no escopo acordado e exigiria uma renegociação formal de prazos e custos antes de aceitar.
Bom (7): Diz que negaria o pedido baseado no documento, mas não menciona renegociação de prazo/custo.
Insuficiente (0): Diz que aceitaria a mudança por ser o cliente, ignorando completamente o propósito do Charter.

Questão 4: Engenharia de Requisitos

Due Date: 2026-08-23

Texto da Issue

A Engenharia de Requisitos classifica os requisitos em Funcionais e Não-Funcionais. Qual a diferença conceitual e prática entre eles? Dê um exemplo de Requisito Funcional e um exemplo de Requisito Não-Funcional estritamente focados no Assistente de IA que sua equipe vai construir.

Gabarito / Rubrica de Correção

Excelente (10): Funcional (O QUE o sistema faz) e Não-Funcional (COMO o sistema faz/Restrições). Ex: Funcional -> O bot deve analisar código C++ e identificar complexidade ciclomática. Não-Funcional -> A resposta do LLM deve retornar em menos de 5 segundos.
Bom (7): Define corretamente a teoria, mas dá exemplos ruins ou que não se aplicam ao projeto da disciplina.
Insuficiente (0): Inverte os conceitos ou dá exemplos absurdos.

Questão 5: Cascata vs. Ágil no Mundo da IA

Due Date: 2026-08-23

Texto da Issue

Historicamente a Engenharia de Software utilizou o Modelo Cascata (Preditivo), mas hoje dominam os Modelos Ágeis (Iterativos). No contexto específico do nosso Projeto Integrador (desenvolver um Assistente baseado em LLM), explique por que usar o Modelo Cascata — tentando prever e documentar 100% da arquitetura e do comportamento da IA antes de escrever qualquer código — seria um erro fatal.

Gabarito / Rubrica de Correção

Excelente (10): Entende a alta incerteza e comportamento probabilístico de um LLM (ex: Engenharia de Prompt precisa de tentativa e erro). O modelo cascata falharia porque é impossível prever todas as alucinações e comportamentos da IA de antemão. Ciclos iterativos com feedback são essenciais.
Bom (7): Responde genericamente que o método Ágil é mais rápido ou flexível, sem relacionar com o comportamento probabilístico da IA e as limitações do Cascata.
Insuficiente (0): Afirma que o modelo cascata seria melhor ou não compreende a imprevisibilidade de um LLM.