Uma equipe de desenvolvimento está criando um sistema de gestão escolar que deve processar notas de alunos, calcular médias, determinar situação acadêmica e gerar relatórios. Inicialmente, todo o código estava concentrado em uma única função principal com mais de 200 linhas, dificultando manutenção e testes. A equipe decidiu aplicar princípios de modularização para melhorar a estrutura do software. O sistema refatorado inclui funções específicas: calcularMedia() que recebe um array de notas e retorna a média aritmética; determinarSituacao() que recebe a média e retorna "Aprovado", "Recuperação" ou "Reprovado"; validarNota() que verifica se uma nota está no intervalo válido (0-10); formatarRelatorio() que organiza os dados em formato apresentável; e lerDadosAluno() que coleta informações do usuário. Cada função foi projetada para ter uma responsabilidade específica, receber parâmetros bem definidos, retornar valores apropriados e ser independente das demais. A modularização trouxe benefícios como reutilização de código, facilidade de testes unitários, melhor organização lógica e redução de duplicação. Entretanto, surgiu debate sobre boas práticas de design de funções, incluindo questões sobre acoplamento, coesão, passagem de parâmetros e tratamento de erros. Considerando o contexto apresentado, é correto o que se afirma em: I. A função calcularMedia() deve ter alta coesão funcional, executando apenas a tarefa de calcular média aritmética sem misturar outras responsabilidades como validação de dados ou formatação de resultados. II. O baixo acoplamento entre funções é desejável, significando que cada função deve depender minimamente de outras funções e poder ser testada e modificada independentemente. III. A passagem de parâmetros por valor é sempre preferível à passagem por referência em funções modulares, pois garante que os dados originais nunca sejam modificados acidentalmente. IV. Funções que não retornam valores (procedures) devem ser evitadas em programação modular, pois dificultam a composição de oper