O currículo de engenharia tem sofrido mudanças, notavelmente no modo que as escolas de engenharia têm adotado a aprendizagem baseada em problemas para suprir as demandas da prática de engenharia (CHUNG; HARMON; BAKER, 2001).
O principal conceito da aprendizagem baseada em problemas estabelece que o processo de ensino/aprendizagem inicie-se a partir de um ou mais problemas que deverão ser resolvidos pelo alunos utilizando os conceitos aprendidos em aula (RICHARDSON; DELANEY, 2009). As seguintes atividades são desempenhadas nas disciplinas que utilizam a aprendizagem baseada em problemas na área de Engenharia de Software, segundo Koper e René (2004):
Definir objetivos de aprendizado;
Identificar conceitos e partes do problema que necessitam de esclarecimento; Definir o problema;
Analisar o problema;
Utilizar técnicas de brainstorming para discutir as causas do problema e possíveis soluções;
Estruturar as soluções escolhidas; Implementar a solução;
Avaliar a solução implementada de acordo com os requisitos do problema; Reportar aprendizado realizado.
O domínio somente dos aspectos técnicos de engenharia não é mais suficiente para as demandas da sociedade. Cada vez mais, programas de ensino de engenharia estão inserindo os alunos em projetos multidisciplinares, com requisitos incompletos ou mal especificados, nos quais os estudantes também possam aprender habilidades para desenvolver soluções considerando restrições de qualidade, custo, tempo, esforço, entre outras (CHUNG; HARMON; BAKER, 2001).
Ainda segundo Chung, Harmon e Baker (2001), no processo de ensino/aprendizagem baseado na metodologia PBL, os estudantes são efetivamente envolvidos com os problemas, o que traz maior motivação para a aprendizagem significativa.
Princípio 15 - Aprendizado centrado no aluno
Abordagens pedagógicas práticas são construídas sobre o pressuposto que a mente humana é um recipiente e que a responsabilidade dos professores é preenchê- lo com conhecimento. Esse método de ensino é conhecido como aprendizado centrado no professor, no qual a educação é vista como um processo no qual o conhecimento é transferido do professor para o aluno (SCHÖN, 2000). Segundo essa concepção, os alunos são elementos passivos e cabe ao professor, elemento ativo do processo, inserir nos estudantes um conjunto de conhecimentos factuais e habilidades intelectuais, testando periodicamente a aquisição destes conhecimentos por meio de provas e exames. Baseado nas teorias pedagógicas descritas no Capítulo 2, o roteiro utiliza uma abordagem de ensino oposta, na qual o conhecimento é construído na mente do aluno, que participa ativamente do processo de aprendizagem, o que exige uma atitude proativa por parte dos estudantes.
Unindo o aprendizado centrado no aluno com uma forte iniciativa prática, pode- se explorar a habilidade inata do ser humano de explorar para descobrir, que segundo Ohlsson e Johansson (1995), fomenta a aprendizagem significativa.
Segundo a teoria construtivista, o estudante deve participar ativamente do processo de ensino/aprendizagem, exercitando a criatividade na resolução de problemas. Este ambiente, no qual o aluno participa ativamente em sua aprendizagem, cria uma motivação natural para aprender, o que certamente refletirá em sua vida profissional (MULDER; LIDTKE; STOKES, 1997).
Princípio 16 - Projetos “reais”
Segundo Mulder; Lidtke e Stokes (1997), pode-se aumentar a eficiência do aprendizado fazendo com que os alunos resolvam problemas relativamente complexos, cuja solução exija um determinado nível de estruturação arquitetural e um planejamento de engenharia, o que possibilita o trabalho em equipe e fomenta discussões e constantes avaliações do design e da qualidade da arquitetura de software do sistema e desenvolve nos estudantes habilidades práticas (ZHANG, 2013). A resolução de problemas reais de relativa magnitude e complexidade possibilita o aprendizado efetivo de conceitos e técnicas de arquiteturas de software.
Na aplicação do roteiro proposto, procura-se modelar uma situação real de projeto de software, sob a qual os alunos adquirem habilidades essenciais de um engenheiro de software como trabalho em equipe, gerenciamento de projetos, aplicação de metodologia de desenvolvimento de software, avaliação de qualidade de software, uso de padrões e normas e treinamento de habilidades de comunicação e liderança. A simulação de um ambiente de um projeto centrado em arquitetura de software, em que os alunos devem entender os processos de negócio, analisar trade-
offs entre requisitos de qualidade, escolher táticas arquiteturais para promover a
melhoria de qualidade e medir os atributos de qualidade auxilia na consolidação do aprendizado, permite que esse ambiente seja adaptado e replicado em diversas situações de sua vida profissional.
Princípio 17 - Aulas práticas
Sendo o roteiro de ensino de qualidade de arquitetura de software fortemente baseado em uma abordagem prática, o uso de aulas em laboratório é um dos principais recursos utilizados. O princípio de aulas práticas, juntamente com o princípio de “projetos reais”, possibilita a simulação, em menor escala, de situações e projetos da indústria, o que é fundamental na formação dos alunos (SMOLANDER, 2002). A apresentação da teoria e de modelos arquiteturais inseridos em um contexto prático potencializa o aprendizado dos alunos, além de solidificar os conceitos aprendidos, transcendendo mudanças tecnológicas (SHAW, 2000).
Princípio 18 - Documentação essencial
O objetivo da documentação arquitetural é registrar as principais decisões e respectivos racionais, de forma suficiente, para que possa ser utilizada para construir e manter um sistema de software (CLEMENTS et al., 2010).
Segundo Fairbanks (2010), a documentação ideal de arquitetura de software deve ser clara e concisa para permitir que o desenvolvedor entenda o que deve ser feito, sem perder a conexão com os requisitos de negócio e as restrições do sistema.
A documentação também deve conter diagramas, protótipos, tabelas, trechos de código, artefatos do dia a dia do desenvolvedor, o que potencialmente diminui a possibilidade de uma interpretação incorreta dos requisitos do sistema. De acordo
com estudo realizado por Prasad e Ojha (2012), tabelas e gráficos são entendidos de forma mais rápida e precisa pelos desenvolvedores, se comparadas a sentenças em texto livre.