Data de Publicação

12/09/2026

Data de Modificação

31/08/2026

Relatório de Avaliação - L02

Gerado em 31/08/2026 09:18:02

📊 Resumo de Entregas

Aluno	Q1	Q2	Q3	Q4	Q5	Total
ANDERSON DE LIMA.	✅	✅	✅	✅	✅	5/5
ANDRÉ GUILHERME R.	✅	✅	✅	✅	✅	5/5
ARTHUR BALTAR ELE.	✅	✅	✅	✅	✅	5/5
BIANCA DA SILVA B.	✅	❌	❌	❌	❌	1/5
CARLOS ESTEVÃO	✅	✅	✅	✅	✅	5/5
CARLOS MATHEUS	✅	✅	✅	✅	✅	5/5
DANYEL MARTINS ZI.	✅	✅	✅	✅	✅	5/5
DAVI JOSÉ DO NASC.	✅	✅	✅	✅	✅	5/5
EMMANUEL DINIZ CH.	✅	✅	✅	✅	✅	5/5
EVELYZE PINHEIRO.	✅	✅	✅	✅	✅	5/5
FILLIPE TOMAZ CAR.	❌	✅	✅	✅	✅	4/5
FLÁVIO CORCINI DE.	✅	✅	✅	✅	✅	5/5
GABRIEL ALVARENGA.	✅	✅	✅	✅	✅	5/5
GABRIEL PINHEIRO.	✅	✅	✅	✅	✅	5/5
GABRYEL FERREIRA.	✅	✅	✅	✅	✅	5/5
ISAÍAS CÉSAR SAMP.	✅	✅	✅	✅	✅	5/5
JOÃO CARLOS FERRE.	✅	✅	✅	✅	✅	5/5
JOÃO VÍTOR MARQUE.	✅	✅	✅	✅	✅	5/5
LETICIA MAURICIO.	✅	✅	✅	✅	✅	5/5
MATEUS SILVA LOPE.	✅	✅	✅	✅	✅	5/5
MATHEUS MATOS BOT.	✅	✅	✅	✅	✅	5/5
NATHAN BALMANT DE.	✅	✅	✅	✅	✅	5/5
PEDRO CLAUDIO JAC.	✅	✅	✅	✅	✅	5/5
RONALD RODRIGUES.	✅	✅	✅	✅	✅	5/5
SABRINA EVELYN SI.	✅	✅	✅	✅	✅	5/5
SAMUEL BRUM LELLE.	✅	✅	✅	✅	✅	5/5
SAULO DIAS DE OLI.	✅	✅	✅	❌	❌	3/5
THALLES VINÍCIUS.	✅	✅	✅	✅	✅	5/5
VICTOR GABRIEL MA.	✅	✅	✅	✅	✅	5/5
VICTOR OTAVIO SOU.	✅	✅	✅	✅	✅	5/5
VITOR EMANUEL VEN.	✅	✅	✅	✅	✅	5/5
VITOR OLIVEIRA CA.	✅	✅	✅	✅	✅	5/5
CARLOS EDUARDO	❌	❌	❌	❌	❌	0/5
GABRIEL CAMPOS MA.	❌	❌	❌	❌	❌	0/5
GABRIEL SILVA GON.	❌	❌	❌	❌	❌	0/5
HUGO VICENTE COEL.	❌	❌	❌	❌	❌	0/5
RAFAEL DE OLIVEIR.	❌	❌	❌	❌	❌	0/5
WELLINGTON JHONNEY	❌	❌	❌	❌	❌	0/5

🟢 ANDERSON DE LIMA. (Matrícula: 20213005825, Login: @limaanderson)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

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

Seria um erro fatal, pois tentar documentar 100% da arquitetura antes de programar, pois projetos de IA carregam muitas incertezas.

A engenharia moderna exige o uso de modelos ágeis, justamente para lidar com essas incertezas, pois eles permitem planejar, construir e ir avaliando em ciclos menores, parantindo que com as avaliações, a equipe possa adaptar a arquitetura e as respostas na prática.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Engenharia de Requisitos

Os requisitos funcionais eles basicamente definem oque o sistema deve fazer, quanto as regras de negócio, descrevendo as ações e como elas vão ser executadas.

Já os requisitos não funcionais, no lugar de descrver regras de negócios e ações específicas, eles garantem que o software funcione bem em uma situação real, definindo como o sistema deve se comportat e determinam a velocidade, segurança e facilidade do uso.

Como requisito Funcional, o sistema deve reecber a dúvida do aluno, analisar o problema e retornar uma dica sobre aonde pesquisar para aprender ou um questionamento que faça o usuário encontrar a solução por conta própria.

E como requisito, não funcional, o motor da Ia deve conter restrições rigorosas de segurança, que proiba de qualquer forma a geração de respostas diretas ao aluno.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Project Charter como Escudo

Tendo o project Charter, o gerente pode argumentar que aquela funcionalidade rápida e pequenininha não é tão rápida, nem pequena, que pode acarretar no projeto inteiro, como no orçamento ou no prazo, pode argumentar também que foge dos objetivos Smart que criam as metas e aquilo que não pode ser mudado no projeto.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: O Perigo dos Objetivos Vagos

Não é Smart pois não aplica uma estrututa completa que faça que seja Smart, falta elementos essenciais da metodologia, diz que será criado um chatbot inteligente que ajude os alunos, mas não diz com que tipo de técnologia será feito, não diz a precisão, e não diz um prazo final.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

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

Viabilidade técnica, pois a equipe não possui o conhecimento e a capacitação necessária.

Viabilidade Econômica, Pois não há orçamento disponível para resolver a limitação técnica.

Viabilidade Legal, pois o projeto acaba se tornando inviável perante a lei, pois expor dados de usuários na nuvem sem nenhuma segurança, fere a lei.

Viabilidade Operacional, sem o conhecimento técnico, se torna incapaz sustentar a segurança, realizar manutenções.

Tempo, o tempo necessário para a equipe estudar e aprender sobre o assunto, estouraria qualquer prazo definido para a entrega do projeto

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 ANDRÉ GUILHERME R. (Matrícula: 20243000982, Login: @andreguilherme)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

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

Como a IA não é deterministíca, criar um projeto que não tem nenhum tipo de mudança nas expecificações iniciais ia dar errado justamente pela IA ser imprevisivel, e tambem porque é impossivel expecificar totalmente o projeto no inicio porque podem surgir varios problemas com a IA que não consideramos no começo

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Engenharia de Requisitos

Um requisito funcional descreve o que um sistema faz, enquanto um requisito não funcional descreve como o sistema deve se comportar na questão de desempenho, segurança e arquitetura

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Project Charter como Escudo

Falaria que pelo project charter essa funcionalidade não foi expecificada anteriormente e que para adicionar ela teria um possivel aumento no prazo máximo e no custo final do projeto

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: O Perigo dos Objetivos Vagos

Seguindo as definições do smart, ele não é expecífico o suficiente, não tem nenhuma expecificidade sobre como ele será construído, não é possível mensurar pela definição como deve ser a performance dele, não tem nenhuma restrição expecificada, não fala se é relevante e nem para quem é relevante, e não tem um prazo expecificado

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

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

De acordo com o TELOS isso fere o L que é seguir a LGPD, criptografar os dados dos usuários nesse caso é importante pra evitar quebrar a LGPD que mantem os dados do usuário privados no banco de dados

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 ARTHUR BALTAR ELE. (Matrícula: 20223004240, Login: @ArchieBaltar)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

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

Usar Cascata no nosso Projeto Integrador seria um erro fatal porque o modelo pressupõe baixa incerteza, e um sistema baseado em LLM é exatamente o oposto disso. A gente não controla o comportamento da IA com precisão total: o mesmo prompt pode gerar respostas diferentes, o modelo pode alucinar, a API pode mudar de comportamento ou cair. Tentar documentar 100% da arquitetura e do comportamento antes de escrever qualquer código significa prever algo que só se descobre testando.

Além disso, o Cascata trava o escopo no início e só entrega no final, então se o System Prompt não funcionar como esperado, ou se a cota de tokens estourar, ou se a API externa se comportar diferente do previsto, a gente só vai descobrir isso perto do prazo — quando já é tarde e caro pra corrigir. Um modelo Iterativo permite testar o comportamento da IA em ciclos curtos, ajustar o System Prompt com base em feedback real, e corrigir rota antes que o problema vire uma bomba-relógio, exatamente como discutimos antes sobre dívida técnica.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Engenharia de Requisitos

A diferença é que o Requisito Funcional descreve o que o sistema faz, e o Requisito Não-Funcional descreve como o sistema se comporta ao fazer isso.

No nosso Assistente de IA:

Requisito Funcional: O assistente deve responder dúvidas de programação em C++ usando a estratégia socrática (dando pistas, não a resposta pronta).
Requisito Não-Funcional: O tempo de resposta da API não deve ultrapassar 3 segundos, mesmo com 50 usuários simultâneos.

Na prática, o Funcional é o que aparece nos casos de uso (o comportamento esperado), e o Não-Funcional é o que garante que o sistema seja utilizável de verdade (performance, segurança, disponibilidade), mesmo que não apareça diretamente pro usuário.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Project Charter como Escudo

Se o cliente me encurralar no corredor pedindo “só mais uma funcionalidade urgente e bem pequenininha”, eu não recuso na hora, mas também não aceito ali mesmo. Eu digo que qualquer funcionalidade nova precisa passar pelo processo formal, porque o escopo do projeto já está definido no Charter, que foi assinado com Requisitos de Alto Nível, Premissas e Restrições acordadas.

Uso o Charter como referência concreta: mostro que aquela funcionalidade não estava prevista, e que aceitar sem avaliar impacto quebra o Tempo, o Custo ou a Qualidade combinados (Triângulo de Ferro). Assim, a decisão não fica no campo pessoal (“o gerente não quer fazer”), fica no campo contratual: “isso está fora do escopo assinado, precisamos renegociar prazo/orçamento ou deixar para uma versão futura”. O documento me protege porque tira o peso da decisão de cima de mim e coloca em cima do que já foi formalmente combinado.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: O Perigo dos Objetivos Vagos

“Fazer um chatbot inteligente que ajude alunos” não é SMART porque não define nada mensurável nem verificável. “Inteligente” e “ajude” são palavras vagas, cada pessoa do time pode entender de um jeito diferente, e no final ninguém sabe dizer se o objetivo foi cumprido ou não. Também não tem prazo, então o projeto nunca teria um ponto de “pronto”.

Reescrevendo pra estrutura SMART, no nosso contexto do Projeto Integrador:

“Desenvolver e integrar um Assistente Socrático via API do Gemini (Específico e Atingível), capaz de responder dúvidas de programação com 95% de precisão (Mensurável), reduzindo a sobrecarga dos professores (Relevante), até o fim do Sprint 4, na 15ª semana do semestre (Temporal).”

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

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

Foram feridas as duas primeiras dimensões: viabilidade técnica (T) e viabilidade econômica (E).

A viabilidade técnica foi ferida, pois, como está escrito, a equipe “não faz ideia de como criptografar os dados dos usuários na nuvem”.

A viabilidade econômica foi ferida, porque o time não pode contratar quem sabe, já que “não há orçamento para terceirizar esse serviço”.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟡 BIANCA DA SILVA B. (Matrícula: 20223004410, Login: @biancaB)

Progresso: 1 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

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

As viabilidades diretamente afetadas são a técnica e a econômica. A viabilidade técnica é comprometida porque a equipe não possui o conhecimento necessário para implementar a criptografia dos dados na nuvem. Já a viabilidade econômica é afetada porque não há orçamento disponível para contratar especialistas ou terceirizar esse serviço.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

❌ Questões Faltantes

Questão 2: O Perigo dos Objetivos Vagos
Questão 3: O Project Charter como Escudo
Questão 4: Engenharia de Requisitos
Questão 5: Cascata vs. Ágil no Mundo da IA

🟢 CARLOS ESTEVÃO (Matrícula: 20243001658, Login: @carlos-e-araujo)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

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

Usar modelo cascata é falta porque LLMs são probabilísticos. Não tem como prever e documentar coisas como respostas, alucinações dos prompts planejados e seus comportamentos, ajuste só apareceriam durante o desenvovimento. Com o metódo Cascata, a equipe só descobriria erros e falgas no fim do projeto, quando já não tem mais tempo para corrigir, tornando a abordagem ágil e iterativa a única viável para esse tipo de projeto.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Engenharia de Requisitos

Um RF define o que o sistema deve fazer como funcionalidades, comportamentos especificos, entradas e saídas de dados, enquanto os RNF estabelecem como o sistema deve se comportar coisa como desempenho, restrições de qualidade, segurança, disponiblidade.

Para o assistente uma RF seria: Receber uma pergunta em lingua natural sobre determinado desafio e explicar sem dar a resposta uma forma de solucionar.

Um RNF seria: O assistente deve processar a requisição e exibir o resultado em até 3 segundos.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Project Charter como Escudo

O Project Charter é um contrato que delimita o que foi aprovadao no escopo inicial do projeto. O que eu alaria para o cliente é que o documento estabelece os requisitos de alto nível, os prazos e o orçamento para a equipe. Se aceitar um pedido assim geraria um Scope Creep e colcaria em risco a entrega combinada. Eu poderia orianta-lo a formalizar a solicitação por um procesos de controlde mudanças, onde é avaliado o impacto e é renegociado custos e prazos. Ou registar no backlog para adicionar em versões futuras, fora do escopo atual.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: O Perigo dos Objetivos Vagos

Especifico (S): Chatbot para tirar dúvidas de alunos com relaçao a exercicios de programação.

Mensuravel (M): Respostas com no minimo 90% de precisão.

Atingível (A): Uso de APIs e infraestrutura gratuitas.

Relevante (R): Reduz “colas” feitas em outras ferramentas de IA e sobrecarga do professor com duvidas.

Temporal (T): 10 semanas para finalizar.

Chatbot para tirar dúvidas de alunos com relaçao a exercicios de programação, que retornet respostas com no minimo 90% de precisão. Para isso vamos utilizar de APIs e infraestrutura gratuitas. Reduzindo “colas” feitas em outras ferramentas de IA e sobrecarga do professor com duvidas. Com cerca de 10 semanas para finalizar.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

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

Foram feridas as viabilidades Técnica porque a equipe não possui a competência e o conhecimento necessário para implementar a criptografia. E econômica porque a empresa não possuí orçamento para cobrir os custos de terceirização.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 CARLOS MATHEUS (Matrícula: 20233007620, Login: @Carlos_Matheus_2005)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

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

Seria um erro fatal porque tudo é imprevisível, não dá para garantir que o nosso conhecimento atual, junto com os nossos planos, seja capaz de garantir que o projeto irá fluir do início ao fim sem nenhum tipo de falha. Sendo assim, é possível que a equipe trabalhe fielmente com tudo dando certo nas linhas de código e estruturas individuais, aí quando chega no final (a hora de juntar todo o trabalho duro que foi feito durante meses) para fazerem os testes, podem ser encontradas falhas que vão atrasar com o cronograma e afetar o projeto. O método ágil permite que façamos as coisas aos poucos, avaliando o que precisa ser feito, construindo e planejando quais serão os próximos passos a serem seguidos, caso tenha dado certo ou errado, permitindo feedbacks contínuos e correção de rota.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Engenharia de Requisitos

Os Requisitos Funcionais, são aqueles que descrevem o que o sistema deve fazer (ações, regras de negócio e dados), como por exemplo: “O chatbot deve responder perguntas sobre C++ usando a estratégia socrática”

Os Requisitos Não-Funcionais, são aqueles que descrevem como o sistema deve se comportar ou como executa essas funções (desempenho, segurança e usabilidade), como por exemplo: “O tempo de resposta da API não deve ultrapassar 3 segundos com 50 usuários simultâneos”

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Project Charter como Escudo

O Project Charter é o documento oficial que concede a autoridade ao Gerente de Projetos para aplicar os recursos organizacionais. Sendo assim, a proteção que ele fornece dá o poder de barrar solicitações e exigências novas que o cliente requere, podendo ser canceladas ou forçar uma renegociação formal de prazos e orçamentos, assim evitando o fenômeno do Scope Creep, que é um aumento descontrolado do escopo.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: O Perigo dos Objetivos Vagos

Um objetivo apenas como: “Fazer um chatbot inteligente que ajude alunos” não é considerado SMART porque as metas de um projeto não podem ser tão vagas, um alvo definido apenas como “melhorar o sistema” é impossível de ser gerenciado.

Uma forma melhor de reescrever seria: “Desenvolver e integrar um Assistente Aristotélico via API do Gemini que será capaz de responder com precisão mais de 95% das dúvidas de programação, reduzindo a sobrecarga dos professores e aumentando a eficiência dos alunos nas realizações de suas tarefas até o fim do semestre, um prazo de 20 semanas.”

Essa forma apresenta uma estrutura SMART, pois temos um objetivo específico, mensurável, atingível, relevante e temporal.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

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

As viabilidades feridas do framework TELOS são a Técnica, pois isso indica que não foram avaliadas a maturidade da tecnologia e o conhecimento/competência da equipe necessários para o projeto (neste caso criptografar os dados dos usuários na nuvem), e o Econômico, tendo em vista que eles deveriam levar em consideração na montagem do orçamento possíveis terceirizações de serviços que o grupo designado não conseguiria realizar.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 DANYEL MARTINS ZI. (Matrícula: 20243014020, Login: @DanyelZini)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

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

É praticamente impossível definir 100% a documentação de um projeto de assistente baseada em LLM, já que o tema traz muita instabilidade durante seu desenvolvimento, que provavelmente os desenvolvedores achariam alguma limitação do modelo ou algum problema relacionado com a qualidade das respostas a qual seria necessário ajustar algo para melhora-lo. Por isso é mais viável o uso do Modelo Ágil, já que a equipe pode desenvolver uma versão simples de assistente e ir testando e melhorando enquanto uma versão esta em produção.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Engenharia de Requisitos

A diferença principal é que Requisitos Funcionais descrevem o que o sistema faz, enquanto Requisitos Não funcionais descrevem como o sistema deve se comportar. Agora, um exemplo para o uso desses requisitos focado no tema de Assistente de IA seria:

RF-01: O assistente IA deve responder às dúvidas dos alunos sobre o conteúdo estudado.
NRF-01: O assistente de IA deve responder as perguntas em menos de 5 segundos e com taxa de acerto de 90%.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Project Charter como Escudo

Utilizaria o Project Charter para verificar se a nova funcionalidade está dentro do escopo e das metas do projeto, caso não esteja, explicaria ao cliente que não seria possível a adição da funcionalidade pois ela representaria um risco ao escopo.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: O Perigo dos Objetivos Vagos

Esse objetivo não é SMART já que é um assunto muito amplo e genérico não definindo claramente o que deverá ser feito, mas aplicando cada critérios ficará:

Específico: O chatbot responderá dúvidas dos alunos sobre os assuntos estudados.
Mensurável: Estabelecer métricas com percentual de respostas corretas.
Atingível: Considerar os recursos e conhecimentos disponíveis pela equipe.
Relevante: O chatbot devera responder todas as perguntas feitas pelos alunos dentro dos temas estudados.
Temporal: Estabelecer um prazo para desenvolver e entregar.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

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

Foram feridas as viabilidades Técnica e Econômica, pois a equipe não tem a tecnologia ou o conhecimento necessário para realizar a criptográfica dos dados dos usuários na nuvem e não possuem recursos financeiros suficientes para contratar um serviço terceirizado.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 DAVI JOSÉ DO NASC. (Matrícula: 20243001685, Login: @DaviJ)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

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

O projeto desenvolvido em cascata tem que ter um escopo e funcionalidades bem definidas desde o começo, o que é incompatível com o nosso projeto onde dependendo de como a IA se portar o escopo do projeto pode variar. A instabilidade da tecnologia nesse caso a torna ruim para ser feita com o modelo cascata.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Engenharia de Requisitos

O requisito funcional se refere ao que o software deverá fazer, isso é, as funcionalidades que ele terá e o que ele será ou não responsável por fazer, os requisitos não funcionais se referem a como o software deve agir e como ele deve ser criado, se possui resposta rápida ou é leve e de fácil entendimento. No exemplo do assistente de IA podemos dizer que um requisito funcional seria a capacidade de responder a perguntas do usuário e um requisito não funcional seria quantidade de dados que ele iria gastar para cumprir tal prompt.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Project Charter como Escudo

Eu diria que usaria o Project Charter como uma espécie de limitador de mudanças, se o que o cliente quer está previsto nele e sua implementação não afeta o resto do projeto eu faria, caso contrário, o cliente teria que se conter com uma implementação tardia da funcionalidade.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: O Perigo dos Objetivos Vagos

O objetivo citado não cumpre nenhum dos requisitos para ser chamado de objetivo SMART. Ele não especifica o que o chatbot fará com todo o escopo, não é um objetivo mensurável, não descreve se é viável ou não, não cita relevância nem temporalidade. Uma forma melhor de definir o objetivo seria:

Desenvolver em período T, um chatbot que irá ser utilizado por alunos estudando X, com capacidade de acerto estimada de M, utilizando as tecnologias disponibilizadas no laboratório em busca de ajudar os alunos a melhorarem seu aprendizado.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

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

As três principais viabilidades da TELOS feridas foram a viabilidade técnica, econômica e legal.

A viabilidade técnica foi ferida porque a equipe não possui a capacidade técnica de realizar o projeto, tornando impossível fazer o projeto nas condições atuais.

A viabilidade econômica foi ferida pois o projeto não possui orçamento suficiente para arcar com a contratação de uma equipe que possa fazer essa funcionalidade.

A viabilidade legal foi ferida pois com a falta da criptografia dos dados acaba criando uma vulnerabilidade podendo expor dados sensíveis dos clientes, ferindo diretamente a LGPD.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 EMMANUEL DINIZ CH. (Matrícula: 20213005843, Login: @EmmanuelD1)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

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

O modelo Cascata seria ruim nesse projeto porque o comportamento da IA não é totalmente previsível. Muitas coisas só vão aparecer quando começarmos a testar os prompts e a integração com a API. Com o modelo Ágil, dá para desenvolver aos poucos, testar, receber feedback e corrigir o que for necessário durante o projeto.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Engenharia de Requisitos

O requisito funcional define o que o sistema deve fazer. Já o não-funcional define como ele deve funcionar, por exemplo em relação a desempenho ou segurança.

Funcional: o assistente deve analisar o código enviado pelo aluno e fornecer uma dica.

Não-funcional: o assistente deve responder em no máximo 5 segundos.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Project Charter como Escudo

Eu usaria o Project Charter para mostrar o que foi definido como escopo e objetivo do projeto. Se essa nova funcionalidade não estiver prevista, ela não deveria ser incluída direto. Primeiro seria necessário avaliar o impacto no prazo e no restante do trabalho antes de aceitar a mudança.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: O Perigo dos Objetivos Vagos

Esse objetivo não é SMART porque é muito genérico. Ele não explica exatamente o que o chatbot vai fazer, como o resultado será medido e nem qual é o prazo.

Uma forma melhor seria: Desenvolver até a 15ª semana um assistente de IA que ajude alunos com dúvidas de programação sem entregar a resposta pronta, alcançando pelo menos 95% de precisão nas respostas avaliadas.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

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

As viabilidades mais afetadas são a Técnica e a Econômica. A técnica porque a equipe não sabe implementar a criptografia dos dados, e a econômica porque não existe orçamento para contratar alguém que faça isso. Também pode gerar um problema legal, já que envolve proteção de dados dos usuários.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 EVELYZE PINHEIRO. (Matrícula: 20213012374, Login: @evelyze)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

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

Documentar “100% do comportamento da IA” antes de escrever código é tentar especificar o output de uma função que você mesmo não consegue prever analiticamente. Não é falta de disciplina de documentação, é impossível por natureza. Você escreve uma versão do prompt, roda, vê que o modelo alucina ou foge do tom, ajusta, roda de novo. Esse ciclo é fundamentalmente iterativo. Em Cascata, você fecharia o “documento de comportamento esperado da IA” antes de rodar um único teste, e esse documento estaria obsoleto no primeiro dia de implementação.

Em cascata, adiar o código para depois de “fechar toda a arquitetura” significa descobrir o risco mais crítico só no fim, quando não há mais tempo ou orçamento para pivotar. Ágil ataca esse risco primeiro (via protótipos e iterações curtas), exatamente onde a incerteza é maior.

Cascata trata mudança de requisito como falha de planejamento; em projeto de IA generativa, mudança de requisito após ver o comportamento real é o processo normal e esperado de refinamento.

Se depois de “fechar tudo” na documentação você descobrir que a arquitetura de RAG escolhida não resolve alucinação, ou que o modelo escolhido não tem contexto suficiente, isso derruba fundação inteira, não é um ajuste de tela, é trocar a espinha dorsal do sistema. Em Cascata essa descoberta chega tarde (fase de testes/homologação), quando o custo de retrabalho é máximo. Em Ágil, esse tipo de decisão crítica é testada logo no Sprint 1 ou 2, com pouco investido ainda.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Engenharia de Requisitos

Requisitos funcionais descrevem o que o sistema faz. Por exemplo, o chatbot com IA deve responder perguntas sobre python usando a estratégia socrática, de dar dica para direcionar o usuário, sem dar a resposta pronta.

Requisitos não-funcionais descrevem como o sistema deve se comportar. Por exemplo, o tempo de resposta da API construída não deve exceder 3 segundos com 50 usuários simultâneos.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Project Charter como Escudo

Posso usar o Charter assinado para barrar a solicitação ou forçar a renegociação formal de prazos e orçamentos, evitando o temido fenômeno do Scope Creep.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: O Perigo dos Objetivos Vagos

Esse objetivo falha em praticamente todos os critérios SMART(Específico, Mensurável, Atingível, Relevante e Temporal), porque é feito de palavras vagas que soam bem mas não são verificáveis. Esse objetivo é uma visão, não uma meta de projeto.

Desenvolver e implantar um chatbot via Telegram (S, A) capaz de responder corretamente as dúvidas sobre códigos da maratona de programação dos alunos com precisão de 95% (M), reduzindo a sobrecarga dos professores (R), até o final do semestre letivo (30/11) (T)

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

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

Foram feridas as viabilidades técnica e econômica. A equipe declarou explicitamente que “não faz ideia de como criptografar os dados”. Isso define a ausência do conhecimento da equipe ou da capacidade interna necessária para executar aquele requisito específico do projeto, denotando o ferimento da viabilidade técnica.

A saída natural para resolver uma lacuna de conhecimento técnico seria contratar ou terceirizar quem já sabe fazer, mas não há orçamento para isso. A viabilidade econômica avalia se o projeto tem recursos financeiros suficientes para ser executado da forma como foi desenhado, e aqui a resposta também é não.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟠 FILLIPE TOMAZ CAR. (Matrícula: 20233004600, Login: @Fillipe)

Progresso: 4 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

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

Os modelos de LLM e IAs generativas além delas serem imprecisas para determinadas ações, hoje elas não conseguem compreender com precisão o contexto daquele código a ser gerado pelo desenvolvedor, sendo assim, ela deve ser usada como uma ferramenta junto ao DEV do projeto.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Engenharia de Requisitos

o Requisito Funcional (RF) define o que o sistema faz (as funções e ações), enquanto o Requisito Não Funcional (RNF) define como o sistema se comporta em termos de qualidade, limite ou regra técnica.

O RF é focado totalmente no usuário final, sendo aquilo que será usado diretamente por ele, como por exemplo, enviar um arquivo em word e converter para pdf.

Já o RNF é de uso da equipe de desenvolvedores daquele software, que querem esse requisito seja comprido para o melhor funcionamento do software. Ex: Esse jogo não pode usar mais que 1GB de RAM.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Project Charter como Escudo

Explicaria que como um avião, um software que se preze e bem planejado, ele deve está planejado sempre pensando nos minuciosos detalhes, sendo assim, adicionando uma funcionalidade no improviso, pode acabar ferrando com o equilíbrio do sistemas e trazendo mais problemas a equipe

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: O Perigo dos Objetivos Vagos

Pois cada aluno tem uma necessidade diferente, não sendo limitado apenas ao acadêmico, pois ele pode também sofrer com dificuldades de compreensão, socialização, adaptação, entre outros problemas na qual ele pode passar em sua jornada acadêmica. A minha sugestão seria a criação de um “Chatbot aos alunos que os auxiliem ao tirar duvidas sobre as diversos contextos escolares”, assim sendo mais especifico, e ao mesmo tempo, mais amplo para todas as dificuldades.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

❌ Questões Faltantes

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

🟢 FLÁVIO CORCINI DE. (Matrícula: 20243007295, Login: @FlavioCorcini)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

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

Porque o Modelo Cascata não prevê imprevistos e mudanças no planejamento e, um assistente de I.A., se encaixa melhor com um Modelo Ágil que recebe constantes alterações e atualizações.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Engenharia de Requisitos

Os requisitos funcionais são essenciais para o funcionamento do chatbot, por exemplo, a interação entre o usuário e a I.A.. Os requisitos não funcionais são essenciais, mas não possuem o mesmo nível de prioridade e necessidade, em relação ao funcionamento do chatbot, por exemplo, acessibilidade para usuários com deficiências físicas ou mentais.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Project Charter como Escudo

Eu explicaria os possíveis impactos da funcionalidade proposta, iria esclarecer os limites claros sobre o que está ou não está incluso no projeto e estabeleceria um protocolo de controle de mudanças, onde a funcionalidade poderia ser avaliada pela equipe e aprovada ou rejeitada.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: O Perigo dos Objetivos Vagos

Porque ele não cumpre todos os requisitos e objetivos da metodologia SMART como: ser específico no quê ou a qual nível de escolaridade serão os alunos alvos do chatbot; a métrica para feedback do chatbot, estatísticas de sucesso e erros; para ser “inteligente”, o chatbot deve ter acesso e fazer bom uso das API’s de forma segura e eficiente; o chatbot deverá propor impacto ou revolucionar de alguma forma no plano didático de ensino e possuir uma data ou limite de tempo para ser elaborado.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

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

As dimensões mais prejudicadas do framework TELOS são a tecnológica, econômica e legal. A dimensão tecnológica não foi atendida, uma vez que a equipe não possuía a capacidade técnica de implementar métodos de criptografia de dados. A econômica não foi cumprida considerando que a equipe deveria haver uma reserva financeira para poder contratar serviços de terceiros e poder mitigar imprevistos. E, por último, a dimensão jurídica foi fragilizada também, uma vez que os dados dos usuários na nuvem não são protegidos.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 GABRIEL ALVARENGA. (Matrícula: 20243001694, Login: @gLx)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

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

os modelos de linguagem exigem ajustes frequentemente para evitar respostas incorretas ou alucinações, o projeto necessita obrigatoriamente da flexibilidade de um Modelo Ágil. As sprints permitem criar protótipos rápidos, testar a IA, corrigir o comportamento do sistema, coisas que o planejamento do cascata não é bem compativel

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Engenharia de Requisitos

o RF define o que o sistema faz, tipo o que o projeto tem que fazer mesmo, enquanto o RNF define como ele faz (qualidade, segurança, desempenho, quantos acessos simultaneos aguenta…

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Project Charter como Escudo

O Project Charter é o acordo fundamental do projeto. Nele estão as fronteiras do que foi aprovado (escopo, prazo e custo). Eu usaria o documento com educação, mas com firmeza

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: O Perigo dos Objetivos Vagos

É meio vago esse adjetivo inteligente, inteligente pra que e pra quem? A escrita melhor seria: Desenvolver um assistente de IA focado em resolver problemas de ICPC usando método socratico para ajudar os estudantes a entendenr problemas de programação.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

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

As duas viabilidades feridas foram a economica e a técnica, pois a equipe não possui o conhecimento para programar a criptografia na nuvem e a econômica falhou porque o projeto não tem orçamento para contratar um especialista ou alguem para resolver o problema

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 GABRIEL PINHEIRO. (Matrícula: 20243000884, Login: @gabriel_pinheiro067)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

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

Usar o modelo cascata no nosso projeto seria um erro fatal pois esse modelo trabalha em cima da ideia de que é possível prever e documentar todos os requisitos antes de começar a produzir qualquer coisa que não seja apenas conceitual no projeto. Como o projeto é sobre desenvolver um assistente virtual baseando-se em LLM, a forma como a IA se comporta é praticamente imprevisível o que faz com que qualquer limitação seja descoberta apenas aplicando testes repetitivos, tornando assim impossível de prever com antecedência tudo que será feito e como será implementado em um documento.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Engenharia de Requisitos

A diferença entre os dois é que os requisitos funcionais descrevem o que o sistema faz, ou seja, as ações que atendem diretamente o que o usuário necessita. Já os requisitos não funcionais descrevem como o sistema deve se comportar em questão de desempenho, segurança e arquitetura, sendo algo voltado para o quão bem o sistema inteiro se comporta quando o usuário o utiliza. Dentro da proposta da Assistente de IA que minha equipe irá desenvolver, um requisito funcional seria algo como “O sistema deve analisar todo o histórico da conversa com o aluno procurando entender quais são suas maiores dúvidas e dificuldades na matéria”, já um requisito não funcional seria algo como “O sistema deve garantir que toda a conversa seja guardada de forma segura e confidencial de forma que a interação não seja vazada e seja restrita apenas ao usuário”.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Project Charter como Escudo

Como gerente de projetos eu usaria o Project Charter como escudo pessoal pois eu mostraria ao cliente que aquela funcionalidade não estava prevista dentro dos requisitos de alto nível nem dentro das premissas e restrições que foi combinado e assinado antes do início do projeto e que, ao adicionar esta funcionalidade, todo o desenvolvimento do projeto teria que ser reavaliado para ver se a adição é possível o que poderia causar o atraso do projeto passando do prazo pré-definido. Mas, a fim de prestar suporte de qualquer maneira, eu discutiria a possibilidade de adicionar tal funcionalidade em uma próxima versão do projeto deixando minha equipe livre de problemas.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: O Perigo dos Objetivos Vagos

O objetivo “Fazer um chatbot inteligente que ajude alunos” não é considerado SMART pois ele é muito vago e não define nenhum dos cinco pilares de forma que possa ser avaliado se o objetivo foi comprido ou não. Reescrevendo o objetivo aplicando SMART ficaria: “Desenvolver um chatbot usando a API do Gemini que atue como um monitor auxiliar nos estudos dos alunos capaz dialogar com o aluno conforme suas necessidades a fim de conduzi-lo ao resultado correto 95% das vezes de forma que reduza o atendimento individual prestado pelos professores, tal projeto deve ser desenvolvido e testado dentro do prazo de 4 meses.” Desta forma, todos os cinco pilares estão sendo satisfeitos, o objetivo é específico pois evidencia bem o que está sendo feito, mensurável pois é explicitado que deve acertar 95% das vezes, atingível pois descreve como e com quais ferramentas o projeto pode e deve ser feito o que mostra sua possibilidade, relevante pois deixa claro que a conclusão do projeto ajudará os professores e temporal pois possui um prazo final definido.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

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

As viabilidades técnicas e a econômicas são feridas nesta situação. A técnica pois a equipe não domina a linguagem/stack escolhida e nem possui a devida maturidade tecnológica para resolver o problema visto que lhes faltam conhecimento de como criptografar dados na nuvem. Já a econômica é ferida pois a falta de orçamento necessário para terceirizar o serviço que a equipe não é capaz de fazer categoriza um Business Case impossível de resolver podendo acarretar em impasses no momento do desenvolvimento do projeto.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 GABRYEL FERREIRA. (Matrícula: 20243004954, Login: @Gabryel)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

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

Usar o modelo cascata para o desenvolvimento de um assistente baseado em LLM seria problemático pelo conhecimento já estabelecido sobre o modelo cascata, não poderia haver algumas mudanças e adequações a tecnologias e limitações do projeto. O modelo mais utilizado hoje por grandes empresas é o ágil ainda mais em projetos menores, mas por se tratar de algo tão novo como a IA e também sendo um dos primeiros projetos completos de muitos de nós alunos o modelo cascata é o mais adequado.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Engenharia de Requisitos

Requisitos Funcionais seriam o que o sistema faz: Um requisito funcional pode ser dito com uma reação do sistema de acordo com a ação do usuário.

Exemplo bem possível de ser integrado ao projeto: Indicar livros da área de estudo da pergunta.

Requisitos Não Funcionais é mais como o sistema deve funcionar e suas características.

Exemplo: Porcentagem de precisão de resposta.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Project Charter como Escudo

Basicamente, como o Project Charter já estaria consolidado desde o início do desenvolvimento de tal aplicação, realmente eu teria um escudo pessoal para proteger eu e minha equipe contra pedidos de acréscimos de funcionalidades no sistema pois já havia sido definido funcionalidades, custo, objetivo e o tempo de entrega. Estaríamos protegidos em relação ao aumento descontrolado do Escopo pelo documento, uma renegociação no tempo de entrega e valor poderiam ser negociados.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: O Perigo dos Objetivos Vagos

Desenvolver um sistema, usando uma interfaçe de chatbot como a do Telegram, via API de alguma IA já conhecida no mercado capaz de responder perguntas de alunos com 95% de precisão para ajudar os alunos no seu processo de aprendizado sem dar as respostas diretamente em X dias.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

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

As viabilidades do modelo TELOS que foram diretamente feridas são as viabilidades técnica e a econômica, onde os desenvolvedores daquele sistema não tem capacidade de realizar a operação e nem capital para terceirizar a ação e conseguir suprir uma demanda de estado crítico do desenvolvimento do sistema. Poderíamos também dizer que afeta a viabilidade operacional já que esse erro pode fazer com que o uso do sistema pelo usuário seja perigoso e inaceitável nesse caso.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 ISAÍAS CÉSAR SAMP. (Matrícula: 20243006289, Login: @isaiascsl)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

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

O modelo cascata ele falha, mesmo tentando ter alta previsibilidade do projeto, ao encontrar obstáculos no meio do desenvolvimento. Dessa forma, o que era para ser um fluxo contínuo de desenvolvimento é pausado por conta do modelo. O projeto integrador seguindo o modelo cascata seria um erro fatal pois não seríamos capaz de medir a capacitação do time na ferramenta, conciliação com a faculdade (provas, trabalhos e listas são impedimentos) e até mesmo desistências ao longo da disciplina, sem contar obstáculos comuns de projetos como bugs e alucinação de modelos gratuitos na fase de testes.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Engenharia de Requisitos

Os requisitos funcionais definem comportamentos e regra de negócio de uma aplicação (ex: cadastrar cliente). Já requisitos não funcionais definem a maneira de como os comportamentos definidos nos requisitos funcionais perfomam. Um exemplo para o assistente de IA que a equipe vai construir são trazer os pré requisitos de uma matéria do cefet, como requisito funcional, e que o tempo de processamento para dar resposta para o usuario é de, no máximo, 5 segundos, como requisito não funcional.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Project Charter como Escudo

Usaria o Project Charter a favor alegando que os termos combinados foram assinados pelo cliente e, para isso, teria que haver uma nova negociação. Mesmo que seja uma funcionalidade “bem pequenininha”, isso serve como barreira do cliente ficar pedindo mais funcionalidades no projeto e, assim, protegendo a equipe do scope creep

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: O Perigo dos Objetivos Vagos

Definir esse tipo de objetivo não é considerado um objetivo SMART pois é um escopo muito vago do que é o projeto e não segue nenhum dos tópicos que a SMART propõe. A metodologia busca especificar com detalhes o objetivo do projeto, dando esses 5 campos como referência para que o projeto do usuário tenha sentido e valor. O projeto de exemplo aplicado à SMART poderia ficar:

S: Fazer um chatbot inteligente com objetivo de atender pessoas e marcar uma reunião no google agenda das 8h as 18h de segunda a sexta.

M: O modelo deve ser capaz de atender 100% das pessoas por mensagem de texto sem intervenção humana no atendimento.

A: Construído em N8N, integrado com API do gemini e com conhecimento voltado à atuação do estabelecimento.

R: Para reduzir esforços de um funcionário fazendo tarefas repetitivas, focando em tarefas administrativas.

T: Entregar versão BETA em 45 dias e lançar em produção em 90 dais.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

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

Essa situação fere diretamente duas viabilidades: Technical e Economic. Se falta a competência técnica interna para implementar um requisito essencial de segurança, o projeto não é tecnicamente viável. Como a equipe não sabe executar a tarefa, a solução seria contratar especialistas ou ferramentas prontas. No entanto, a falta de recursos financeiros para cobrir a lacuna técnica do time inviabiliza a sua execução.

Isso gera um efeito em cascata cria um bloqueio para as etapas de Operational e Legal.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 JOÃO CARLOS FERRE. (Matrícula: 20213003750, Login: @joaocarlos.fm)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

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

O modelo cascata, neste caso, seria um erro devido a imprevisibilidade de assistente baseado em LLMs. O projeto deve ser monitorado e até reformulado devido a testes realizados visando avaliar a qualidade das respostas e mudanças no prompt do modelo escolhido.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Engenharia de Requisitos

Os requisitos funcionais servem para explicitar o que o sistema deve executar como, no caso de um assistente de IA, o sistema deve auxiliar nas perguntas dos usuários referentes à computação. Já os requisitos não funcionais devem mostrar como o sistema deve funcionar como responder em até X segundos ou até X respostas por dia.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Project Charter como Escudo

Eu explicaria que mesmo sendo uma funcionalidade pequena, fugiria do escopo que foi definido anteriormente no Termo de Abertura. Desta forma, o mais recomendado era abrir uma solicitação para implementar a funcionalidade em outro momento ou adicionando mais tempo, orçamento e alocações ao projeto original.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: O Perigo dos Objetivos Vagos

O objetivo não é considerado SMART pelo fato de apresentar partes específicas de como deve ser realizado e, por isso, genérico. O Objetivo reescrito atendendo a estrutura SMART: Desenvolver, neste período, um chatbot inteligente que ajude alunos em questões acerca da computação e acerte 90% das respostas em até 5 segundos.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

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

Foram feridas a viabilidade técnica e a viabilidade econômica. A falta de conhecimento da equipe para criptografar os dados impede de implementar corretamente a função. Já o orçamento não disponível é responsável pelo impedimento de repassar a tarefa a partes terceirizadas.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 JOÃO VÍTOR MARQUE. (Matrícula: 20243003394, Login: @joao)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

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

Ia ser um erro fatal pois não é possível prevermos 100% do comportamento que a IA vai ter e assim não vamos conseguir fazer 100% da documentação antes de desenvolvermos. A respostas podem trazer muitos comportamentos inesperados, então vamos ter que testar, identificar os problemas e ir ajustando.

Por isso o modelo interativo ágil é melhor pro nosso caso, pois nós podemos desenvolver uma versão inicial, testar, receber avaliações e irmos melhorando o sistema. Assim não temos pressa no planejamento que, posteriormente, e provavelmente ia estar inadequado e diferente do projeto após todos os testes e modificações.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Engenharia de Requisitos

A diferença entre os requisitos Funcionais e Não-Funcionais é que os Funcionais descrevem o que o sistema vai fazer, como por exemplo as funcionalidades que ele terá. Já os Não-Funcionais descrevem como o nosso sistema vai comportar, como por exemplo mostrando o desempenho, a segurança e a arquitetura.

Os exemplos, para Requisito funcional é a assistente analisando a pergunta que o aluno mandou como um código, e retornar uma resposta que se relacione com o conteúdo da matéria de uma forma fácil de se entender pro aluno.

Já o Não-Funcional é o tempo de resposta que a API da assistente não pode passar dos 5 segundos após o aluno ter enviado sua pergunta da atividade.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Project Charter como Escudo

Como o Project Charter é o documento oficial que formaliza o projeto e define os limites eu primeiramente iria verificar se essa nova funcionalidade está de acordo com os requisitos, as premissas e restrições e os objetivos SMART que já tinham sido definidas. Depois de olhar, e a funcionalidade tiver fora do escopo previsto eu explicaria para ele que mesmo sendo uma solicitação pequena e urgente, ela representa uma mudança no projeto. Assim não ia ser correto simplesmente adicionar pois ela poderia aumentar o trabalho da equipe, comprometer os prazos, custos e outras coisas no projeto.

Após tudo isso, eu poderia negociar com ele utilizando o Project Charter como base, analisando os impactos da nova funcionalidade e fazendo as alterações de uma forma que não impactasse no projeto atrapalhando ele.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: O Perigo dos Objetivos Vagos

O objetivo da questão não é SMART pois é muito genérico e não explica direito o que vai ser montado, não explica direito como podemos considerar que ele foi feito com sucesso, não diz se tem como fazer ela de acordo com as restrições, não apresenta qual o problema que vai solucionar e também não mostra o prazo para ele ser concluído.

Desenvolvimento de um chat assistente para os alunos que utilize alguma API como a do Gemini ou da Anthropic, ele vai ser capaz de responder dúvidas de perguntas de matérias da faculdade com pelo menos acima 90% de precisão, com isso vai diminuir a sobrecarga dos professores, o limite para terminar será até a 15ª semana do projeto.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

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

Foi ferida a Viabilidade Técnica pois a equipe não tem ideia de como faz para criptografar os dados dos usuários na nuvem, sendo que para a Viabilidade Técnica você tem que avaliar se sua equipe sabe dominar as tecnologias que precisa. Também foi ferida a Viabilidade Econômica pois também não tem orçamento para para terceirizar esse serviço de criptografia, sendo que para a Viabilidade Econômica antes de iniciar o projeto você deve fazer a analise dos custos que serão necessários para saber se é viável.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 LETICIA MAURICIO. (Matrícula: 20243001649, Login: @leticia)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

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

No cenário atual o mercado precisa lidar com uma alta incerteza tecnológica, principalmente associado ao uso de inteligência artificial, visto que se trata de uma tecnologia relativamente recente, que passa por mudanças, atualizações e melhorias constantemente, e que ainda apresenta muitos erros e pontos de melhoria. Dito isso, o modelo cascata funciona para ambientes com pouca incerteza, com requisitos claros, bem definidos e estáveis, o que não é possível em projetos que envolvem LLMs e IA, dando lugar às metodologias ágeis, com ciclos curtos, que permitem feedbacks contínuos e mudança de rota de acordo com a necessidade, com os objetivos do mercado e respeitando as capacidades da IA ao longo do processo. Em uma questão de dias as LLMs e modelos de IA passam por muitas mudanças, conforme temos visto, e essas mudanças já foram positivas, com atualizações de modelos e versões cada vez mais poderosas, mas também negativas, como a limitação da capacidade em versões gratuitas e o aumento dos preços para o acesso a essa tecnologia.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Engenharia de Requisitos

Requisitos funcionais descrevem o que o sistema faz, e são visíveis para o usuário final, representam algo que o sistema vai entregar, enquanto requisitos não funcionais descrevem como o sistema deve se comportar, descrevendo comportamentos que o sistema deve ter, sendo possíveis de serem medidos. No caso do projeto da disciplina, um dos requisitos funcionais do projeto é que o chatbot seja capaz de responder às duvidas dos alunos usando uma determinada linguagem ou metodologia de ensino, e um requisito não funcional que pode ser estabelecido pelo projeto é que o chatbot responda às dúvidas em até 10 segundos.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Project Charter como Escudo

O termo de abertura funciona como um contrato, contendo justificativas, requisitos, restrições, premissas e os objetivos smart, e assinado antes do projeto começar, de modo que possui autoridade máxima. Assim, na posição de gerente de projetos, eu conversaria com o cliente para que ele entenda o impacto que alterações nesse documento com o projeto em andamento trazem, trazendo a ideia do triângulo de ferro, de possíveis impactos financeiros e temporais, de tal forma que fique claro que mudanças desse tipo não são aconselháveis e podem acarretar em um descumprimento do que foi proposto para ser entregue a ele ao final.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: O Perigo dos Objetivos Vagos

Um objetivo do tipo “Fazer um chatbot inteligente que ajude alunos” não é considerado um objetivo SMART porque não especifica exatamente o que será construído, não detalha métricas de sucesso, não mostra a relevância do projeto e nem os prazos envolvidos. Reescrevendo, desenvolver um assistente inteligente usando uma API capaz de ajudar os alunos com 90% de precisão sem fornecer as respostas exatas dos problemas, reduzindo o trabalho dos professores e o tempo de espera dos alunos, até o final da disciplina, na primeira semana de dezembro.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

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

O framework TELOS envolve as dimensões técnica, econômica, legal, operacional e schedule. Essa situação descrita fere as dimensões técnica e econômica, uma vez que a equipe não se certificou que possui a tecnologia para fazer o projeto, e eles não possuem, e também não dispõem de recursos financeiros para compensar essa falta da tecnologia. A falta de viabilidade técnica gerou uma dependência financeira e no fim nenhuma das duas foi atendida.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 MATEUS SILVA LOPE. (Matrícula: 20243004300, Login: @MateusLopes15)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

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

A priori, grande parte dos alunos, se não todos, nunca desenvolveram algo envolvendo um chatbot, muitos nem devem ter usado muitas API’s, tentar definir os requisitos totais a cegas, sem ter conhecimento é um tiro no pé. Além disso, existe muita incerteza da tecnologia, o uso mais largo de IA é algo novo, é difícil aplicar um modelo mais antigo, do que dividir em sprints e ir fazendo os módulos aos poucos.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Engenharia de Requisitos

Os requisitos funcionais, são aqueles que como o nome diz, fazem parte do funcionamento, do fazer do sistema. Ou seja, ações, regras de negócio e afins. Com isso, por exemplo, teríamos, fazer login, responder mensagem.

Em contrapartida, os requisitos não funcionais são algo mais ligado à qualidade do projeto, por exemplo, desempenho, segurança, portabilidade, ou até mesmo “95% de precisão”.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Project Charter como Escudo

O Project Charter é um documento oficial, aprovado tanto pelo cliente quanto pelo desenvolvedor. Ele é um documento que define o escopo macro do projeto, tendo justificativa, requisitos de alto nível, custos, infraestrutura e metas claras do objetivo SMART. Eu tentaria então explicar para o cliente que adicionar uma funcionalidade urgente, pode prejudicar o projeto inteiro, pode aumentar o custo, o tempo de execução, podem surgir bugs nessa nova funcionalidade que dificultem a execução das outras. Dessa forma, como o project charter é um documento oficial, ele pode ser usado para se proteger legalmente do Scope Creep. Sem o project charter, poderia não ter como provar o escopo do projeto, e o cliente poderia pedir infinitamente.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: O Perigo dos Objetivos Vagos

No caso tal qual o TELOS, cada lera do SMART possui um significado. Com o texto que foi escrito, basicamente só cobriria o S e um pouco do R. Faltando assim as letras MAT. Como comprovaria sucesso dentro do que foi escrito? Quais as restrições do projeto, como vai ser feito, quando vai ser o prazo para acabar?

O Smart são metas claras e inegociáveis.

Desenvolver um chatbot inteligente utilizando via API do ChatGpt, capaz de sanar dúvida de diversos alunos, aliviando a carga dos professores em 20 semanas.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

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

O framework TELOS é resumidamente uma ferramenta de gestão para estudo de viabilidade de projetos. Cada letra dela é uma dimensão. Quando a equipe percebeu o problema envolvendo a criptografia, ela basicamente pode ter ferido todas as 5 dimensões. Em principal ela fere “T”, a viabilidade técnica, pois teoricamente era para a equipe ter analisado isso antes do projeto ter sido feito, a equipe antes precisava saber a tecnologia necessária e segunda principal seria o “E” a viabilidade econômica, se a equipe não sabe fazer e “não há orçamento para terceirizar esse serviço”, então o projeto não tinha o orçamento bem feito. Por fim, ele acaba abalando as outras 3 pois um projeto que precisa de criptografia provavelmente envolve algo da LGPD, fere também tanto o operacional quanto o “Schedule” pois o projeto não tem como ser entregue de maneira realista, prejudicando toda rotina da empresa.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 MATHEUS MATOS BOT. (Matrícula: 20243001353, Login: @matheusmb10)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

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

Creio que é impossível documentar todos os caminhos e saídas de uma LLM pois ela não tem natureza determinística. Não é exato. Não é possível prever algo com certeza absoluta em um sistema que funciona baseado em probabilidades. Ou seja, tentar documentar a arquitetura e comportamento da IA antes de codificá-la seria uma tarefa infinita.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Engenharia de Requisitos

O requisitos funcionais descrevem o que o sistema faz. Um exemplo para o assistente de IA é: “O sistema deve analisar um código C++ enviado e retornar uma dica pedagógica”.

Já os requisitos não-funcionais descrevem como o sistema precisa se comportar, principalmente quanto a desempenho, segurança, arquitetura entre outros fatores. Um exemplo: “O tempo de resposta da API de IA n˜ao deve exceder 5 segundos”.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Project Charter como Escudo

O project charter é um documento que reúne as principais informações sobre o que está sendo construído e concede autoridade ao gerente de projetos, dando o pontapé inicial do projeto. Tudo que será feito e foi planejado estará em evidência nesse documento, o que funciona como escudo para qualquer mudança não projetada e tomada de última hora, evitando sobrecarga e trabalho além do que foi contratado inicialmente.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: O Perigo dos Objetivos Vagos

Definir o objetivo dessa forma não especifica exatamente o que será construído, por meio de que será construído, de que forma é possível provar que isso terá resultados significativos, se é algo que está ao alcance da equipe, se resolve o problema do usuário e qual o prazo para tudo isso.

Forma correta (retirei do slide disponibilizado no sigaa):

“Desenvolver um Assistente Socrático via API do Gemini (S, A) capaz de responder a dúvidas com 95% de precisão (M), reduzindo a sobrecarga dos professores (R) até a 15ª semana (T).”

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

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

Estão sendo feridas as viabilidades técnica e a econômica. A primeira pois a equipe não possui conhecimento suficiente para realizar a tarefa de criptografar dados em nuvem. A segunda pois não há recursos financeiros suficientes e disponíveis para arcar com os custos na possibilidade de terceirizar esse serviço a outra equipe que saiba realizar a tarefa que a equipe em questão não tem domínio.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 NATHAN BALMANT DE. (Matrícula: 20223004358, Login: @NathanBalmant)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

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

Usar Cascata no desenvolvimento de um agente baseado em LLM seria um erro, devido ao modelo cascata tem como característica que todo o processo e arquitetura seja documentada antes, onde uma etapa so começa depois que a anterior acaba, ou seja, é um modelo que nao da muita abertura para mudanças. Porém, quando estamos falando de projetos que envolvem LLM nem tudo é tao previsível e os problemas que vao ser encontrados no caminho não podem ser totalmente documentados antes do desenvolvimento na prática.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Engenharia de Requisitos

Requisito funcional é algo que o sistema faz de forma concreta, envolvendo geralmente uma ação. Requisito nao funcional fala sobre comportamentos do sistema, é analisado como tal funcionalidade se comporta e se atinge um critério de qualidade estabelecido.

Requisito Funcional: O sistema deve permitir que o aluno envie um trecho de código com erro e receba uma explicação de por que o erro ocorreu, junto com uma sugestão de correção

Requisito nao funcional: As explicações do assistente devem ser geradas em no máximo 5 segundos e usar linguagem adaptada ao nível iniciante, evitando jargões técnicos não explicados.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Project Charter como Escudo

Usaria mostrando para o cliente que tudo que iria ser feito no projeto, ja foi acordado e aceito por ele, ou seja, qualquer funcionalidade que saia do escopo do que foi assinado, tem que passar por um novo planejamento onde irão ser definidos novos custos, prazos e impactos dessa nova funcionalidade.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: O Perigo dos Objetivos Vagos

Porque nao tem nenhuma característica específica nesse objetivo original, nao sabemos nem pra que serve o chat bot lendo essa frase,também nao é mensurável pois nao existe nenhuma metrica que permita saber se o objetivo foi concluído, pelo mesmo motivo também nao conseguimos saber se esse objetivo é atingivel, difícil também classificar se é relevante, pois nao sabemos o que esse chat bot vai resolver, por último, também nao é possível saber o tempo em que essa tarefa vai ser executada.

Reescrevendo ficaria assim: Desenvolver e implementar, até o dia 15 de novembro de 2026, um chatbot capaz de responder corretamente a pelo menos 80% das dúvidas mais frequentes dos alunos sobre prazos e entregas do Projeto Integrador, reduzindo em pelo menos 30% as mensagens repetitivas enviadas diretamente aos professores.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

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

A avaliação TELOS passa por cinco critérios Tecnico, Econômico, Legal, Organizacional e de Scheduling. Nessa situação proposta os critérios Técnicos e Econômicos foram violados, por que em sequência, a equipe nao possui conhecimento o suficiente para realizar o serviço tecnicamente e por outro lado também nao possui dinheiro o suficiente para terceirizar e pagar alguém que saiba. Isso claro, que mais pra frente pode inclusive atrapalhar outros pontos como o Scheduling (Cronograma), mas o que podemos ja afirmar agora é que os dois primeiros fundamentos da siglas foram feridos.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 PEDRO CLAUDIO JAC. (Matrícula: 20223006791, Login: @pejacome)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

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

Por falta de informação:

LLMs são imprevisíveis (em termos de custo de API, disponibilidade, funcionalidade e qualidade).
Não se sabe o quão bons são os desenvolvedores no time e quanto tempo eles precisariam para executar uma tarefa.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Engenharia de Requisitos

Um requisito funcional é algo que o sistema deve fazer, os requisitos não funcionais são como ele deve fazer.

Funcional: O usuário deve conseguir mandar mensagens e receber uma resposta

Não-Funcional: O usuário deve receber essa resposta em até 5 segundos depois de enviar a mensagem.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Project Charter como Escudo

O project charter tem todos os requisitos do sistema. Novas funcionalidades deveriam ter sido incluídas nele desde o começo.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: O Perigo dos Objetivos Vagos

Pois não é específico, e não é mensurável.

“Desenvolver um Assistente Socrático via API do Gemini (S, A) capaz de responder a dúvidas com 95% de precisão (M), reduzindo a sobrecarga dos professores (R) até a 15ª semana (T).” -> copiei do slide

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

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

Fere o T, E e L

T - Não temos a tecnologia pra fazer isso

E - O custo de implementar é proibitivo

L - É ilegal armazenar dados sem criptografia

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 RONALD RODRIGUES. (Matrícula: 20243003723, Login: @ronaldrodriguesvitorino)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

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

O modelo Cascata depende de um tempo muito grande de desenvolvimento, e é ideal para equipes grandes com um escopo fixo e quase inalterado, sendo necessário para sistemas de alta criticidade; o projeto de IA não corresponde a nenhum desses requisitos: não existe um tempo grande para desenvolvimento, a equipe é pequena, o escopo é altamente mutável visto que as ferramentas e as condições do projeto podem se alterar no meio da sua execução, além de não possuir a criticidade de um sistema militar ou aeronáutico. Essencialmente, o projeto é muito suscetível a mudanças para se considerar utilizar um modelo rígido de desenvolvimento, e é ideal que o modelo ágil seja utilizado para dar conta das mudanças frequentes.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Engenharia de Requisitos

Requisitos funcionais representam as ações específicas que o sistema deve ser capaz de executar, focado em ações e regras de negócio; de forma prática, eles trazem novos elementos que representam uma nova funcionalidade específica, e que tornam o software funcional e útil. Requisitos não-funcionais, por sua vez, especificam como o software deve fazer suas ações, delimitando restrições de desempenho, segurança e usabilidade; efetivamente, garantem que o software tenha uma maior robustez, confiabilidade e boa experiência de usuário.

Um exemplo de requisito funcional tendo em vista o assistente de IA seria: responder às dúvidas referentes a problemas de maratona estilo ICPC, dando dicas e sanando dúvidas mas sem dar a resposta sob hipótese alguma.

Um exemplo de requisito não-funcional seria: a IA deve ter até 95% de precisão, e deve ter disponibilidade em 95% do tempo.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Project Charter como Escudo

Um Project Charter (Termo de Abertura de Projeto) é um documento formal que define as premissas e restrições, os objetivos, o escopo, orçamento, requisitos e os responsáveis de um projeto, servindo como um acordo entre quem o desenvolve e os clientes. Visto que todas as delimitações do projeto estão descritas no documento, qualquer coisa que esteja fora do escopo do Project Charter não pode ser aceita cegamente, já que o documento serve justamente para não ser permissivo e começar a adicionar funcionalidades que explodem muito o escopo do projeto, fazendo a equipe trabalhar em coisas que não entraram em acordo previamente (tendo em vista que o cliente também assinou esse termo e, portanto, estava ciente das condições do projeto); isso precisa ser conversado com toda a equipe, tendo a sua viabilidade analisada para garantir que desenvolver a nova funcionalidade não irá comprometer o resto do desenvolvimento do projeto.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: O Perigo dos Objetivos Vagos

Um objetivo vago não explicita e atinge os cinco critérios de um objetivo SMART, que garante que o objetivo em questão seja alcançável e gerenciável: especificidade, mensurabilidade, atingibilidade, relevância e temporalidade. Uma reescrita do objetivo para atingir os cinco critérios é: ‘Desenvolver um chatbot para alunos via API do Gemini capaz de dar dicas e responder a dúvidas acerca de problemas de maratona, sem dar a resposta, tendo no mínimo 95% de precisão em suas respostas e habilitando que os alunos se preparem para competições reais até o final de quatro meses.’

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

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

Do framework TELOS (Tecnológico, Econômico, Legal, Operacional, Planejamento), três viabilidades ficam diretamente feridas: a tecnológica, pela ausência de conhecimento do time para realizar a encriptação dos dados de usuários; a econômica, pela falta de orçamento para a terceirização do serviço; a legal, visto que o projeto não cumprirá leis referentes à proteção de dados do usuário, podendo estar sujeito a punições caso ocorra um vazamento. As outras duas viabilidades não são feridas diretamente, embora também fiquem comprometidas pelas outras três que estão feridas, tendo em vista que o problema não se foca diretamente nos processos do projeto, ou nos prazos de entrega.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 SABRINA EVELYN SI. (Matrícula: 20243000454, Login: @SabEvelyn)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

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

O modelo cascata seria ruim, pois parte da premissa de planejar tudo e depois executar, é como fazer a planta de uma casa grande e bonita, mas não ter recursos para construí-la toda. Já o modelo ágil se baseia em pequenos passos de planejamento, testes e revisão. Por exemplo, começar construindo um sobrado e ir fazendo o resto da casa aos poucos.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Engenharia de Requisitos

Os requisitos funcionais dizem a respeito do que o sistema deve fazer, por exemplo: permitir o login. Já os requisitos não funcionais ditam como isso será feito, por exemplo: os dados de login serão criptografados.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Project Charter como Escudo

Antes de respondê-lo eu consultaria o Project Charter para conferir se essa funcionalidade está dentro do que foi esperado, se não estiver eu conversaria com o cliente para explicar a situação e resolver da melhor forma. Para que não ocorra o Scope Creep.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: O Perigo dos Objetivos Vagos

O planejamento aplicando a estrutura SMART já iria confrontar a afirmação no A (atingível), pois ele afirma que é necessário ser realista para a equipe e os recursos disponíveis. O que nos leva a questionar, temos a bagagem necessária para completar o projeto? Temos competência?.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

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

Foi ferida a dimensão legal (L), pois a lei LGPD não foi cumprida pela falta de criptografia e a possibilidade de dados sensíveis vazarem; Feriu o operacional (O) também, pois a equipe não saberá como manter isso rodando.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 SAMUEL BRUM LELLE. (Matrícula: 20243004560, Login: @Sam)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

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

os modelos de IA generativa estão em constante modificação de comportamento através de atualizações que as empresas mantenedoras dos modelos lançam mensalmente. Não é possível prever com precisão como a LLM se comportará desde o início do projeto, então é necessário treinar seu algoritmo e passar por diferentes etapas de adaptação do projeto até chegar em um resultado aceitável. Por tanto, dada essa característica modular do projeto seria mais adequado utilizar desenvolvimento ágil.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Engenharia de Requisitos

Requisitos funcionais são funções bem definidas que o projeto deve realizar, sendo tarefas concretas como ter capacidade de enviar notificações ao cliente, exibir alguma informação na tela. Requisitos não funcionais são aspectos gerais que o projeto deve cumprir, como ter responsivo ao usuário, ter navegação rápida e etc.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Project Charter como Escudo

Eu diria que o plano desenvolvimento, o escopo do projeto e suas funcionalidades já estavam bem definidas pelo Project Charter, e que adicionar funcionalidades não contempladas na abertura sem qualquer critério ou controle poderia levar ao scope creep, assim seria necessário reunir toda a equipe e discutir possíveis acréscimos ao trabalho de forma conjunta e planejada.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: O Perigo dos Objetivos Vagos

R: Porque essa descrição do projeto não define de forma conclusiva como o projeto deve ser feito, de que forma funcionará, em que tipo de ambiente será utilizado. Não havendo descrição de aspectos mensuráveis e concretos de como a coisa se delimitará não é possível considerar isso um objetivo SMART.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

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

R: Feriu a técnica pois os desenvolvedores não possuem know-how de como construir tal implementação, feriu o pilar econômico porque não há capital para terceirizar o trabalho e o princípio legal também foi atingido pois a não garantia de criptografia fere a garantia de privacidade dos usuários, cabendo processo judicial em caso de vazamentos e exposição de dados publicamente.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟠 SAULO DIAS DE OLI. (Matrícula: 20203013888, Login: @Saulo)

Progresso: 3 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

📝 Questão 3: O Project Charter como Escudo

Dizer que irá colocar a ideia para ser avaliada em questão de prazo e custo.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: O Perigo dos Objetivos Vagos

Criar um chatbot inteligente que ajude a aumentar em até 30% as notas dos alunos nas disciplinas de exatas ,ate o final do ano letivo

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

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

Fere a técnica e a jurídica.

jurídica: Por causa da LGPD e o risco dos dados sensíveis terceirizando o serviço.

técnica: Não foi avaliado se possuiam software/hardware para isso.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

❌ Questões Faltantes

Questão 4: Engenharia de Requisitos
Questão 5: Cascata vs. Ágil no Mundo da IA

🟢 THALLES VINÍCIUS. (Matrícula: 20243014001, Login: @Thalles_cruz)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

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

Historicamente a engenharia de sofware foi baseado em modelos tradicionais com banco de dados e instruções condicionais, os modelos baseados em IA envolvem alto grau de adaptações e treinamento, engenharia de prompts para treinamento, e reformulações, uma vez que a IA pode não responder como esperado, ou simplismente surtar. A IA é baseada em vários modelos estátisticos o que pode mudar o seu comportamento ou não sair como esperado, sendo necéssario várias adaptações ao longo do projeto, o que tornaria o modelo cascata, em que se pretende tudo mais previsivel e injeçado no projeto, um modelo inviavel.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Engenharia de Requisitos

Requisitos funcionais são requisitos fundamentais a que aquele sistema se propõem. Requisitos não funcionais são requisitos técnicos necessários ao sistema, por exemplo a IA que vamos criar deve ser feita uma pergunta pelo aluno e a IA deve responder de uma forma definida pelo padrão(Funcional) e essa resposta deve ser dada em até 2 segundos(Não-funcional).

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Project Charter como Escudo

O Project Charter é o termo de nascimento do projeto em que se mapeia o que deve ser entregue, estabelece riscos, equipe e orçamento, bem como os objetivos SMART do projeto, pode ser usado como um escudo em que se demontra ao cliente que esses novos pedidos não está especificado no Project Charter, o que demandaria uma reformulação e mapeamento do projeto para que não se perca qualidade no projeto e que talvez o novo pedido demandaria exclusão de outra feature.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: O Perigo dos Objetivos Vagos

Para ser considerado um objetivo SMART, precisamos tirar a subjetividade, deixar metas mais claras de avaliação de sucesso, especificar como poderá se atingir essa tecnologia, especificar para que fim ou gargalo atingir, bem como em quanto tempo se deve atingir, podemos transformar a ideia por exemplo em:

Fazer um chatbot inteligente para ensinar alunos utilizando falas sempre de uma pessoa mais velha e muito ranzinza, sempre muito irritada, turrona, zangada e sem paciencia, que não gosta de repetir as coisas, deve ser possivel comprovar o sucesso desse chat através de testes com outros alunos, feddback, bem como comprovação de sucesso pelo Gestor de Projetos, será utilizado a API do gemini para atingir o objetivo, isso ajuda alunos e professores, a diminuir o gargalo de ensinar e aprender, e estar sempre presente. De forma que não seja somente mais uma informação que o aluno vai ler, sendo apresentada de forma impactante para que o aluno se lembre melhor, se diferenciando um pouco das IAS tradicionais do mercado que são sempre muito passivas e falam o que o humano quer ouvir. Deve ser possivel atingir o resultado final do projeto até o final do semestre, 05/12/2026.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

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

Foram feridos a viabilidade técnica e econômica, uma vez que não se possui orçamento para contratar uma empresa especializada e nem mesmo conhecimento técnico para implementação.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 VICTOR GABRIEL MA. (Matrícula: 20203004575, Login: @vicmagione)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

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

Iria gastar muito tempo documentando algo que no fim haveria modificações, seria de péssima qualidade pois não ouve ajustes com usuários, e o cliente veria o produto só no final, não podendo opinar sobre como esta sendo o desenvolvimento.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Engenharia de Requisitos

Requisitos funcionais, são aqueles que te uma função de definir oque o software faz, um exemplo é que o assistente de IA deve ser interligado com o Telegram. Já os requisitos não-funcionais são determinam como esse software executara essas funções, e de exemplo temos que, o assistente de IA devera ter precisão de no mínimo 85%.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Project Charter como Escudo

A questão não é negar, mas sim aceitar contanto que tenha condições, seja elas tempo ou renda extra, utilizando a cláusula de mudança para que o cliente pense a respeito sobre se é urgente mesmo, ou apenas uma funcionalidade que pode ser implementada muito mais tarde.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: O Perigo dos Objetivos Vagos

Não é um objetivo SMART pois não tem especificação de nenhum componente, seja específico, mensurável, atingível, relevante ou temporal. Para que seja SMART devemos por exemplo escrever esse objetivo dessa forma: Com um prazo de 3 meses, crie um chatbot para ajudar de forma acadêmica alunos do curso de computação, utilizando o Telegram. Esse chatbot devera responder as 10 perguntas mais frequentes sobre prazos de entrega de trabalhos, notas e calendário de provas, direcionado exclusivamente aos alunos do 1º e 2º semestres do curso de Análise e Desenvolvimento de Sistemas, com testes realizados com 30 alunos voluntários e meta de 90% de satisfação na pesquisa pós-uso, com isso reduzindo a taxa de envio de mensagens para professores, deixando-os mais disponíveis para tirar duvidas sobre matéria.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

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

Se essa criptografia foi dita nos requisitos do projeto já fere o T, ferem o L pois descumpria a LGPD, e pode ser que fira o O , pois esse problema pode gerar impactos tanto nos processos quanto na estrutura da empresa. Ou seja Fere possivelmente 3 viabilidades, a Tecnologia ,Legal e operacional.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 VICTOR OTAVIO SOU. (Matrícula: 20243001219, Login: @vsouza)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

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

Diferente de sistemas tradicionais feitos com regras fixas nas quais se o usuário digitar x, se responde y, uma LLM (Large Language Model) prevê as palavras mais prováveis de uma resposta com base no prompt. Como uma LLM é não-determinística (comportamento e respostas evoluem), é impossível prever todas suas saídas com antecedência.

O modelo de cascata é preditivo e sequencial. Esse modelo pressupõe um ambiente de baixa incerteza e oferece uma falsa sensação de segurança. Já os métodos ágeis, ocorrem em ciclos curtos, permitindo feedbacks contínuos e correções de rota. Nesse sentido, como foi explicado o nosso assistente será uma LLM, portanto é necessário realização de testes continuamente, para entender os avanços que estão sendo realizados.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Engenharia de Requisitos

Conceitual

Requisitos Funcionais (RF): Descrevem o que o sistema faz. (funcionalidades e recursos)

Requisitos Não-Funcionais (RNF): Descrevem como o sistema deve se comportar. (desempenho, segurança, usabilidade)

Prática

Requisitos Funcionais (RF): Na prática viram features, telas, botões e fluxos de uso a serem desenvolvidas pelos programadores.

Requisitos Não-Funcionais (RNF): Na prática viram decisões de arquitetura, infraestrutura, escolha de banco de dados e políticas de segurança.

Exemplos

Requisitos Funcionais (RF): O chatbot deve responder perguntas sobre C++ usando a estratégia socrática.

Requisitos Não-Funcionais (RNF): O tempo de resposta da API não deve exceder 3 segundos com 50 usuários simultâneos.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Project Charter como Escudo

O documento do Project Charter permite ao gerente de projetos barrar esse tipo de situação, em que o cliente possa vir a pedir adições em cima da hora. Mas isso não significa que é um não. Ele apenas demonstra ao cliente que esse tipo de “adição” não pode ser feita de “palavra”. O documento apenas faz com que seja necessária uma nova análise formal, e se necessário uma renegociação de prazos e orçamentos, evitando o Scope Creep (inchaço descontrolado do escopo).

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: O Perigo dos Objetivos Vagos

Para ser um objetivo SMART, as metas do projeto não podem ser vagas, e um objetivo como “fazer um chatbot que ajude os alunos” é impossível de ser gerenciado. As metas profissionais que seguem a estrutura SMART são: Specifc/Especifico (objetivo deve ser claro e livre de ambiguidade), Measurable/Mensurável (Deve haver uma métrica para comprovar sucesso), Achievable/Atingível (A meta deve ser realista dentro das restrições técnicas), Relevant/Relevante (objetivo deve estar alinhado com o business case) e Time-bound/Temporal (Deve possuir data-limite ou prazo pra entrega).

Transformando o “Fazer um chatbot inteligente que ajude alunos” para estrutura SMART, seria “Desenvolver e integrar um Assistente Socrático via API do Gemini, sendo especifico (S e A), capaz de responder duvidas de programação com precisao (M), reduzindo sobrecarga dos professores (R), até o final do Sprint 4 na 15ª semana do semestre (T).

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

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

Foram feridas 2 viabilidades do framework TELOS : A Técnica e a Econômica.

A Técnica pois a equipe afirma que não faz ideia de como criptografar os dados, evidenciando a falta de maturidade e conhecimento da equipe. A Econômica é ferida quando é afirmado que não tem orçamento para terceirizar o serviço. Uma vez que não há verba para contratar quem saiba fazer a criptografia e resolver o problema da equipe.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 VITOR EMANUEL VEN. (Matrícula: 20243000919, Login: @VitorEmanuelVS)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

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

Relembrando de forma simplificada, os métodos tem como características principais:

Métodos em Cascata: etapas muito bem definidas e fluxo sequencial, uma vez que saiu de uma etapa, ela é considerada finalizada.
Métodos Ágeis: São cíclicos e adições/mudanças são feitas nas etapas diversas ao longo do processo.

Por essas explicações é possíveis dizer que o primeiro é muito mais rígido que o segundo, cada passo é muito mais definitivo do que no segundo. Os métodos em cascata exigem, por conta disso, um conhecimento muito bem definido sobre o que precisa ser entregue e como isso será feito, já os métodos ágeis permitem mudanças muito mais facilmente e eu acredito que é aí que moram os maiores motivos de implementarmos as metologias ágeis ao invés dos métodos em cascata. Nós alunos, estamos agindo como cliente e empresa reponsável pelo projeto e não temos experiência em nenhum desses dois papéis para tomarmos decisões que possam ser consideradas definitivas em nenhuma das etapas do processo. Logo, escolher uma metodologia rígida poderia ser muito problemático e gerar problemas insolucionáveis em basicamente todas as etapas do trabalho. Precisamos de algo, que nos permita errar e consertar ao longo do tempo de desenvolvimento.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Engenharia de Requisitos

No contexto da engenharia de software, requisito é aquilo que uma solução precisa ter para ser considerada concluída como projeto. Eles podem ser funcionais ou não-funcionais.

FUNCIONAIS: São basicamente aquilo que o sistema deve fazer. Tudo aquilo que é atividade do sistema: funcionalidades, comportamentos, é onde moram as regras de negócio.

NÃO-FUNCIONAIS: São propriedades práticas que o projeto deve possuir, mas não são comportamentos. Podem ser mencionadas caracterísitcas que são ligadas a áreas tais quais: SEGURANÇA e DESEMPENHO. O usuário é impactado por eles, mas frequentemente nem percebe que existem e que para funcionarem, planejamento e execução foram necessários.

EXEMPLO de requisitos:

FUNCIONAIS: O sistema deve ser capaz de manter os dados de login dos usuários.

NÃO-FUNCIONAIS: O sistema deve ter tempo de resposta em qualquer interação de, no máximo, 5 segundos se estiver em funcionamento normal.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Project Charter como Escudo

O Project Charter é o documento que encerra todo o tempo de pré-implementação de um projeto e libera-o para que ela comece. Tendo em visto que, nele é definido o escopo do projeto, ou seja, aquilo que está dentro dele e também aquilo que não está, posso usá-lo com tranquilidade para argumentar que há um documento formal que estabelece tudo que foi comentado ao longo de todo o tempo e, por fim, definido como parte do trabalho e, que fugir disso poderia acarretar em retrocesso no estágio de execução do projeto, com novos valores das variáveis, como custo e tempo de execução.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: O Perigo dos Objetivos Vagos

O objetivo dado como exemplo não é SMART e, por consequência, não é bom para ser considerado em um projeto, porque é muito vazio de significado objetivo e técnico. Não é possível dizer se ele foi atingido ou não com facilidade, deve-se buscar estabelecer algo que é possível ser dividido em partes que podem ser ditas como atingidas ou não atingidas. Refatorando o objetivo para algo dentro da estrutura SMART:

“Fazer um chatbot que ajude alunos dos cursos técnicos da escola ABC na área da computação(ESPECÍFICO), que tenha no mínimo 80% de acerto no que for perguntado dentro do contéudo relativo aos materias das aulas fornecidos pela instituição, que será a base de dados consultadas pela solução(MENSURÁVEL e ATINGÍVEL). O produto funciona como a primeira tentativa de reduzir a quantidade de tutores que devem estar sempre disponíveis para responder a grande quantidade de dúvidas que surgem diariamente(RELEVANTE). O projeto deve estar finalizado até o fim de julho de 2027(TEMPORAL).”

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

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

TELOS é um método que busca avaliar se um projeto é válido para ser desenvolvido por uma empresa. Significa se há viabilidade:

T - Técnica (Technical)

E - Econômica (Economic)

L - Legal (Legal)

O - Operacional (Operational)

S - Cronograma (Schedule)

Esse cenário entra em conflito diretamente com o Técnico, Econômico e Legal. Detalhando: no quesito técnico a empresa não possui equipe com conhecimento das tecnologias necessárias para realizar a criptografia, ou seja, não são especializados para o serviço; já no econômico, a empresa não é capaz de terceirizar essa etapa do processo de desenvolvimento, não é justificável economicamente; agora, no quesito legal, aceitar o projeto e realizá-lo sem essa criptografia é errado, visto que a segurança dos dados dos usuários do produto, será comprometida.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🟢 VITOR OLIVEIRA CA. (Matrícula: 20243001059, Login: @Vitor)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

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

Usar o Cascata daria muito errado porque é impossível prever exatamente como a IA vai responder aos alunos. Trabalhar com LLM exige muita tentativa e erro desde o começo. Se eu tentar documentar tudo antes de programar, só vou descobrir que o bot está inventando respostas erradas lá no final do semestre, quando não der mais tempo de consertar.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Engenharia de Requisitos

O Requisito Funcional é o que o sistema faz a ação prática que o usuário consegue executar. O Não-Funcional é como o sistema faz isso, os critérios de qualidade, restrições de tecnologia, segurança e velocidade. Ex:

Requisito Funcional: O assistente deve receber a dúvida do aluno sobre os horários das matérias e devolver a resposta certa pesquisando na base de dados da faculdade.

Requisito Não-Funcional: O bot precisa entregar essa resposta no WhatsApp em no máximo três segundos para garantir uma boa experiência de uso.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: O Project Charter como Escudo

Aviso que até podemos fazer a funcionalidade, mas isso vai exigir uma alteração formal no planejamento, custar mais caro e atrasar a entrega do projeto todo.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: O Perigo dos Objetivos Vagos

O objetivo original é ruim porque não tem métricas, prazo, nem escopo definido.

Específico: Criar um chatbot no WhatsApp para responder dúvidas frequentes dos calouros.

Mensurável: Resolver 70% das perguntas sem intervenção humana, testando com 40 alunos.

Atingível: Treinar o bot com PDFs da faculdade usando APIs prontas dentro da carga horária da disciplina.

Relevante: Facilitar a vida dos calouros perdidos no campus e desafogar a secretaria.

Temporal: Entregar a versão beta funcionando até a primeira semana de dezembro.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

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

Viabilidade Técnica: A equipe não possui o conhecimento prático nem as habilidades necessárias para implementar a criptografia na nuvem por conta própria, esbarrando na total falta de capacidade técnica interna.

Viabilidade Econômica: O projeto não tem dinheiro em caixa para contratar consultorias externas ou pagar pela terceirização do serviço, o que significa que a limitação financeira impede a resolução da falha técnica.

Viabilidade Legal: Ao não conseguir criptografar as informações pessoais dos usuários, o projeto esbarra diretamente em leis de proteção de dados, como a LGPD, tornando o lançamento do software inviabilizado perante a lei.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🔴 Alunos que não entregaram (0 questões)

CARLOS EDUARDO (@CarlosEduardo)
GABRIEL CAMPOS MA. (@gabrielcm)
GABRIEL SILVA GON. (@mewndigo)
HUGO VICENTE COEL. (@hugovicente)
RAFAEL DE OLIVEIR. (—)
WELLINGTON JHONNEY (—)

De volta ao topo