Educational Methods to SWEBOK Knowledge Areas Matrix

I wasn’t familiar with all educational methods highlighted in this SWEBOK v4 update article. So, here I’ll explore them and visualize their recommended connection to software knowledge areas.

For those who are unfamiliar, the Software Engineering Body of Knowledge (SWEBOK) organizes and outlines generally accepted software engineering practices. It is an IEEE standard meant to define a shared baseline of software knowledge to improve education and training across the field.

Envisioning software engineer training needs in the digital era through the SWEBOK V4 prism considers the SWEBOK v4 update and what the changes mean for software education.

My focus here is on a particular table from the article relating educational methods to the key knowledge areas outlined in SWEBOK. Since I didn’t know all these educational methods, I researched them and briefly summarize each below.

• Project-Based Learning: Students learn about a subject by working on a complex open-ended question for an extended time. The student creates some artifact (e.g. a presentation, paper, model, etc) that requires them to think critically and demonstrate gained knowledge in the target subject
• Learning by Reflection: “The intentional attempt to synthesize, abstract, and articulate the key lessons taught by experience” (source). In my own words, learning by taking time to examine what you know. Often includes clarifying ideas, reframing ideas in personalized terms, discovering connections between ideas, or seeing information from a new perspective.
• Problem-based Learning: Has a strong overlap with project-based learning. Both focus on open-ended questions, critical thinking, and student-driven inquiry. Problem-based learning appears to focus more on greater student ownership across the whole process (“learner-driven self-identified goals and outcomes”), whereas project-based learning may have more defined bounds.
• Active Learning/Learning by Doing: Students actively participate in experiential learning. Think science labs, debates, games, crafts, students explaining to peers, etc.
• Just-in-time Learning: A philosophy of making need-based educational materials available to learners to use when they encounter that need. Think youtube tutorials (bike maintenace, home maintenance, …). Common approaches in software might include documentation, knowledge bases, and blog posts.
• Flipped Learning: Instead of an in-class lecture with at-home exercise, the students review materials before coming to class and then work through exercises and questions together in class. You could say an at-home lecture with in-class exercises (thus “flipped”).
• Collaborative/Peer Learning: Students learn from each other, not just the teacher. Classroom examples could be group activities, peer reviews, or questions followed by quick small group discussions. Workplace examples could be lunch and learns, pair programming, and code reviews.
• Participation in the SW Community: SW means software. Otherwise, it’s all in the name. You learn by being a part of the software community.
• Global Software Development: This one is unclear. Most all of the references to Global Software Development I can find are in research papers. It doesn’t seem to be an eduction term, but the idea of distributed teams collaborating on a project along with the methods for managing touch-points between those teams effectively. The only topic they recommend this for is Software Construction. I think they’re saying people can learn about effective software construction by needing to draw effective boundaries between the responsibilities of different teams and their corresponding programmatic interfaces (APIs).
• Experimental/Research-based Learning: I couldn’t find an official source for this one. The only topic the recommend it for is testing. The article also brings attention to DevOps and empirical measures for evolving quality. I think they mean learning through hypothesis-test cycles, the method that underlies all scientific experiments.
• Agile Learning: The agile process applied to learning. Can include scoped requirements, iterations, and regular review of delivered value. It makes sense that the article recommend this for Engineering Management. It’s kind of like a Objectives and Key Results (OKR) process.

I tried to organize the knowledge area-to-method relationships in a table. The techniques are sorted by how many knowledge areas they’re recommended for, most recommended to least. It’s a bit of a mess to show compactly, but here it is anyway. Happy scrolling.