A capstone student project is regarded as being an essential element of a software engineering degree program. Such a project provides students with the opportunity to undertake a significant software engineering task, deepening their understanding of many of the knowledge areas forming the SEEK, and with a significant experience at the “a” (application) level of the Bloom taxonomy of learning.
Key characteristics of such a project should include the following:
-
The project should span a full academic year, giving students adequate time to reflect upon experiences and retry solutions as appropriate.
-
Where possible, this should preferably be undertaken as a group project. If such factors as assessment make this difficult, it is essential that there should be a separate group project of substantial size.
-
A project should have some form of implementation as its end deliverable so that the students can experience a wide set of software development activities and adequately evaluate these experiences. Theory-based projects such as the development of formal specifications are therefore inappropriate for this role.
-
Evaluation of project outcomes should go beyond concept implementation (“we built it and it worked” [Glass et al., 2004]), using walkthroughs, interviews, or simple experiments to assess the effectiveness and limitations of the deliverables.
Where possible, a project should have a “customer” other than the supervisor so that the student gains fuller experience with product development life-cycle activities.
Assessment of a capstone project should consider how effectively software engineering practices and processes have been employed, including the quality of student reflection on the experience, and not be based only on the delivery of a working system.
CG
|
Summary of Guideline
|
CG 14
|
The curriculum should have a significant real-world basis.
|
Patterns for Delivery
At a detailed level, program delivery will depend on many factors, including the need to share with other programs and the availability of staff with relevant knowledge and experience. Two general strategies, or patterns, however, are used in a range of programs. The first strategy begins by addressing software engineering issues (SE-first), while the second starts with computer science in the first year and then introduces software engineering issues later (CS-first). There is no clear evidence to suggest that one of these is necessarily better than the other. Use of a CS-first approach is more common for pragmatic reasons (such as course sharing), although some would advocate that an SE-first approach is better in terms of developing a deeper understanding of software engineering.
An SE-first approach can help to:
-
Encourage a student to think as a software engineer from the start, focusing on requirements, design, and verification as well as coding, in preparation for the application of these practices to the development of larger systems.
-
Discourage the development of a code-and-fix mentality that may later be difficult to discard. (This can also be achieved with CS-first, but it needs to be explicitly incorporated into that approach.)
-
Encourage students to associate themselves with the discipline from the start.
Equally, a CS-first approach has the following benefits:
-
It is possible to establish a sound level of programming expertise, thus providing a good basis for understanding software engineering concepts. Programming is a fundamental skill, and a certain level of programming proficiency can facilitate understanding of more abstract software engineering practices. Early exposure and repeated practice can help to build this proficiency, while appropriate supervision and feedback can minimize the adoption of bad habits.
-
Because this is the learning pattern assumed by many textbooks, there is less need to develop dedicated material.
-
Software engineering specialists may be in short supply, so the CS-first pattern allows these specialists to focus on teaching later, more specialized, courses.
CG
|
Summary of Guideline
|
CG 7
|
Software engineering must be taught in ways that recognize it is both a computing and an engineering discipline.
|
CG 10
|
Software engineering problem solving should be taught as having multiple dimensions.
|
CG 12
|
The curriculum must be taught so that students gain experience using appropriate and up-to-date tools, even though tool details are not the focus of the learning.
|
CG 15
|
Ethical, legal, and economic concerns and the notion of what it means to be a professional should be raised frequently.
|
CG 18
|
Software engineering education needs to move beyond the lecture format and to consider a variety of teaching and learning approaches.
|
Share with your friends: |