The reality of undergraduate computing education is that the vast majority of students do not go through software engineering curricula where there is time to address the academy questions in some depth. Instead, they are in computer science or computer engineering programs, and receive their software engineering education in a single course.
What students should really learn in this first, and often only, software engineering course is important because the majority of computing students will not see any other software engineering. The course designer will need to make judicious choices in selecting the material for this course because all of software engineering will not fit in just one course even if you try by using one of the classic software engineering tomes as the textbook.
I do not know the right answer to the question I pose in the title of this position paper. I suspect that there is no one set of software engineering topics that should be included, but rather a range of topics to select from based on the purpose and perspective of the course.
The answer to this question is important to everyone who has responsibility for providing the software engineering education for the next generation of computing students.
The approach that we have taken (at RTI) for selecting topics in our introduction to software engineering course has two tenets: less is better, and for our students in software engineering it is OK if some topics are skipped because they will see the full breadth and depth of software engineering through the rest of their program.
The course content is more important for the students in the other majors because this most likely is the only software engineering that they will see. What are the key software engineering learning outcomes that the course should deliver?
Using our two guiding principles, some decisions that we have made about course content include: dropping full-detail use cases for user story specification of requirements, emphasize unit testing more and back off on acceptance testing, and completely eliminating functional specification documents which were typically so bad that we saw no educational value being gained.
Reasonable course design says that there are a limited number of topics that can be covered. Should a course focus in particular areas of software engineering, such as, requirements, process, design, or implementation? Does it need to be the “communication course”, the “teamwork course”, or both? If it does, then time should be allocated for that, displacing some “hard” software engineering topics. So many possible topics, but not nearly enough time.
To read more of this external content, download the complete paper from the author archives at Rochester Institute of Technology.