Keywords

1 Introduction

Software Engineering (SWE) is hard to teach and learn, because of several different aspects, including a lot of abstract processes, different procedures that have to be used appropriately, the high complexity of problems/tasks and – as a consequence of these facets – the fact that the development of Software has to be done in a team.

Through the implementation of the Bologna Process, the “shift from teaching to learning” [1] is demanded in order to (1) increase the employability of students by (2) fostering needed competencies. Therefore the students shall gain (a) knowledge, (b) abilities and (3) competencies [2, p. 27f.]; listed in ascending order.

The transfer of the active role – and thus also the partial discharge of responsibility – from the teacher to the learner and the shaping of collaboration skills respectively the growth of experiences in a team, can be carried out in combination simultaneously by a guided collaborative and self-controlled knowledge acquisition and implementation.

The expected/required achievements can be condensed into: A deeper understanding of the subject matter, not only theoretical knowledge, but also the transmission of theory into practice (“realistic” software project – SWP), to work collaboratively and to acquire needed transferable skills (e.g., teamwork, communication, presentation, cooperation skills, conflict ability).

The subsequent section contains information about the context of the project and its intentions (see Sect. 2). In Sect. 3 the didactical approach of the course design in 2014 (see Sect. 3.1) – already published in [3] –and in contrast the planned concept for 2016 are displayed (see Sect. 3.2). Furthermore two major changes will be described in detail (the Story Line and the Grouping Phase; see Sects. 3.3 and 3.4). The two following Sects. 4 and 5 characterise the seminar– the focus of this paper – and the project phase. All of this combined is then summarised in Sect. 6, which includes an outlook containing ideas for improvement.

2 Context, Intentions and Objectives

At the University of Applied Sciences Aschaffenburg the focus is on the degree programme of Mechatronics (B.Eng.); especially on the course “Software Engineering” (5 ECTS) in the fourth semester and the courses “Computer Science I and II” (second and third semester; 5 ECTS each), which form the basic programming skills.

As the students of the Software Engineering course are undergraduates in an engineering subject, Computer Sciences and all related disciplines are not their key thematic area [4, p. 911].

Moreover, Software Engineering covers highly complex and abstract processes and techniques to solve large as well as multilayered problems and is therefore hard to understand, learn and teach.

Thus, the pursued objectives in 2015 and 2016 are:

  1. 1.

    Activation and motivation: The students should get activated by the need for self-studying and collaboration. To motivate them, the task is to work jointly on a seminar topic and a project and therefore to support teamwork, which is based on the necessity to orientate themselves within a team. The evaluations show that exactly this aim is the aspect the students like the most throughout the semesters (seminar & project).

  2. 2.

    Sustainable knowledge: To avoid “bulimic learning” in the seminar phase, ways to promote a continuous processing shall be implemented and the application of knowledge in a realistic project simulation [5] shall deepen the theoretical knowledge.

3 Didactical Overall Concept of the Course

In 2016 the didactical approach (see Sects. 3.1 and 3.2), which has been invented and tested in the years 2012–2015Footnote 1, was further developed on the basis of the design of two years ago (2014, see [3]). Here a short flashback trough the years is given:

  • The didactical concept (see Fig. 1) was developed in 2012 (for more information see [6]).

  • In 2013 the Wiki was used for the first time. For this, the MediaWiki engine (cf. [7, 8]) was utilised.

  • Since 2014 Moodle [9] as a learning management system (LMS) and the Moodle-Wiki are exploited. Consequently, all documents and artifacts during the seminar and project phase (see Sects. 4 and 5) are submitted via Moodle. Also central questions for the seminar topics have been generated to improve the quality of the Wiki articles.

To explain the main changes from 2014 [3] to the current (2015/2016) elaboration of the arrangement in detail, the following Subsections deal with the course designs of 2014 and 2016 (Sects. 3.1 and 3.2). Additionally, the Story Line (Sect. 3.3) and the Grouping (Sect. 3.4) are made a subject in this section, which is followed by a detailed look at the seminar and the project phase (Sects. 4 and 5).

3.1 Course Design in 2014

The course Software Engineering has a theoretical (ex-cathedra lectures) and a practical part, which are temporally separated. But their content is highly interrelated, as they both cover central theoretical input, which is of crucial importance for coping with the project phase.

Hence the practical sessions are split into seminar and project phase (see Fig. 1).

Fig. 1.
figure 1

Principle course design including highlighted evaluations (cf. [3, 6])

Full size image
  1. 1.

    The lectures are intended to provide theoretical professional contents in the form of ex-cathedra teaching. As the whole course is supported by the LMS Moodle, the materials for the lectures are available here.

  2. 2.

    The practical lessons are sequentially divided into seminar (first third of the semester) and project phase (remaining two thirds of the semester).

    1. a.

      The function of the seminar phase is to accumulate, compact, share and transfer (“learning by teaching” [10]) expert knowledge in groups self-directedly.

    2. b.

      In the project phase the students should use knowledge from the seminar and the lecture in a simulated software project. In this part technical as well as transferable skills are required, but also fostered.

3.2 Course Design in 2016

In contrast to 2014 (see Fig. 1), in 2016 (see Fig. 2) – and already in 2015 – some adaptations have been done in order to meet the objectives (Sect. 2):

  1. 1.

    The course is implemented into a comprehensive “story”, as the students are supposed to work in “companies”, the semester is introduced by the customers for the students to recognize the meaningfulness of the holistic didactical concept to encourage knowledge acquisition (cf. Objective 2-1) and motivation (cf. Objective 2-1).

  2. 2.

    The grouping is done in a new format with a long-term prospect and less in small steps as before. Additionally, the students build the groups themselves to motivate them (cf. Objective 2-1).

  3. 3.

    At the beginning of the seminar phase the students accumulate seminar topics to strengthen their commitment. This is done in order to promote the self-organised group work (cf. Objective 2-1) and again to foster motivation (cf. Objective 2-1).

  4. 4.

    The formulations of seminar topics are revised in order to meet the collection of seminar topics.

  5. 5.

    Because of perennially occuring problems and negative statements – concerning the evaluations of the last years – a hands-on workshop introducing the development hardware (Fujitsu Dice-KitFootnote 2), is given in the first practical session. This is done on account of not demotivating the students while working on the platform (cf. Objective 2-1).

  6. 6.

    The exercises of and for students have been part of the course design for some time, but have not been subject to previous publications. The students are more motivated to follow the instructions of their peers (cf. Objective 2-1) while both parties benefit regarding their knowledge (cf. Objective 2-1).

Fig. 2.
figure 2

Changes in the course design from 2014 to 2016

Full size image

The elements collecting seminar topics (see Pt. 3.2-3), formulating seminar topics (see Pt. 3.2-4) – as a consequence – and the exercises of and for students (see Pt. 3.2-6) are main changes in the seminar phase. Section 4 covers the seminar phase, paying special attention to these points (see Sects. 4.2 and 4.4).

The hands-on workshop (see Pt. 3.2-5) is introduced in order to support both phases; on the one hand the project phase, where the students have to implement a program for the Dice-Kit, and on the other hand the seminar phase, where the Dice-Kit is one seminar topic to hollow the theme after the hands-on workshop so that the students are prepared for the subsequent project.

The comprehensive “story” (see Pt. 3.2-1) as well as the grouping (see Pt. 3.2-2) are issues concerning the whole semester and therefore will be explained in detail hereafter (see Sects. 3.3, 3.4).

3.3 Story Line in 2016

Since last year (2015) the course is embedded in a story to raise the students’ curiosity right at the beginning of the semester (1\(^{st}\) lecture). This is done in order to make the students understand and see the necessity of the knowledge acquisition during the seminar and the lectures; to have the knowledge and tools as background that make the project manageable. This may help to strengthen the motivation of participants and to activate them (see Objective 2-1).

3.4 Grouping in 2016

The grouping is done by the students – with limitations of framework conditions (e.g., lecture plan) – in order to foster motivation.

For a better understanding of the process of grouping, its several steps are summarised in Table 1. The whole approach is also visualised in Fig. 3.

Fig. 3.
figure 3

Grouping in 2016 (cf. [3, p. 286])

Full size image
Table 1. Grouping process in 2015 and 2016
Full size table

Because of the Story line (see previous Sec.), the decision was made to first separate the practical sessionsFootnote 3 into two “companies” each (SWP1...6) to show the practical relevance and orientation, although the project phase is preceded by the seminar phase (see step 1 in Table 1).

These “companies” have the task to brain storm for needed knowledge, which they will have to acquire by themselves in the seminar phase.

During the seminar phase, the students have to work on one seminar topic (A, B, C, D, E); detailed explanation in Sect. 4. This is done by using Wikis in small groups of two to three students (1E, 2A, 3B, 5C,...; see steps 2 & 3 in Table 1).

To assure the quality of the Wiki contents and to reflect and evaluate the articles, the 15 Wikis (see Fig. 3) are merged into five group articles A, B, C, D and E (see step 4 in Table 1). This also reduces the students’ effort to prepare themselves for the intermediate exam (the 1\(^{st}\) Quality Gate; see step 5 in Table 1), in which every student has to demonstrate his/her knowledge concerning their own expert topic as well as those of the other groups.

Afterwards, the experts are interchanged (cf. “group or jigsaw puzzle”Footnote 4 [13]) and again form the companies (cf. steps 1&6 in Table 1).

4 Seminar Phase

The Wiki is the central tool used throughout the whole seminar phase.

The following Figure (Fig. 4) shows the functions of the Wiki (five elements at the top), which are subject of Sect. 4.1. Three more aspects are highlighted here: The collection of seminar topics (see Sect. 4.2), the Conference of Knowledge (see Sect. 4.3) and the exercises of and for students (see. Sect. 4.4).

Fig. 4.
figure 4

Seminar phase and Wiki in 2016 with highlighted aspects

Full size image

4.1 Wiki and Its Functions

The reasoning for using a Wiki instead of a text document is the opportunity to include media-rich contents (cf. [7, 8, 14]), besides the time- and location-independence, the access via the web and the author role of all team members.

As the publication [3] covers the functions of the Wiki in great detail, the four core functions of the Wiki are listed and explained briefly hereafter – in chronological order (cf. Fig. 4):

  1. 1.

    Knowledge Acquisition: The 15 small groups (see Fig. 3) first focus on knowledge acquisition of their topic. The parallelism of group working serves as a quality assurance mechanism.

  2. 2.

    Knowledge Assurance: To ensure the quality of the accumulated knowledge, a Conference of Knowledge (CoK) as one part of a Quality Gate was implemented. Three groups with the same seminar topic have to combine and exclude their acquired information in one group article and a poster, in order to regulate the quality and the information depth.

  3. 3.

    Knowledge Transfer: The transfer takes place in two parts:

    • The CoK, see Fig. 1, to pass on the knowledge and to benefit from learning-by-teaching.

    • The exercises of and for students, see. Sect. 4.4, in which the non-experts learn from their peers & the experts learn-by-teaching.

    The knowledge gained from team working is multiplied by the Wiki and spread over the whole semester.

  4. 4.

    Knowledge Assessment: The “Quality Gate” (see. Fig. 1 & Table 1-step 5) ensures that every students has gained knowledge of all five seminar topics before they enter the project phase.

  5. 5.

    Knowledge Platform: The Wiki is a knowledge platform in two perspectives:

    • To learn for the intermediate exam (see Table 1-step 4).

    • To look up content in the project phase, because experts are present, but their work in the group is not limited to their own topic.

4.2 Collection of Seminar Topics

At the beginning of the seminar phase the students collect seminar topics in order to foster their commitment. The topics are predefined by the laboratory team, but unknown on the students’ side.

In the \(1^{st}\) lecture (see Table 1-step 1) the learners get ten minutes to work in the SWP on the question: What do you lack to be able to work collaboratively in your “company”Footnote 5? Afterwards, the elements are collected in plenum and allocated to prepared cluster, which represent the predefined seminar topics.

In advance, the formulations of the seminar topics have been revised in order to – hopefully – meet the expected collection of seminar topics.

4.3 Conference of Knowledge

The Conference of Knowledge can be described as an enlarged poster session and is used as a tool of “knowledge forwarding” [3, p. 284]. The students have to create a common poster “in order to illustrate [the key facts of] their seminar topic to the other groups” [3, p. 286]. This method was chosen to make sure that the students spend time on the other seminar subjects [3, p. 285].

4.4 Exercises of and for Students

This element takes place after the development of the Group Wikis and the CoK.

Within the three practical sessions, every seminar topic is deepenedFootnote 6 by the experts. Hereby, a activation of learners takes place in two parts:

  • Activation of experts: Have to find exercises and ways to “teach”.

  • Activation of peers: Are confronted with other topics and the application of this knowledge in an exercise (e.g., cooking spaghetti as a project management task in 2015).

5 Project Phase

The project phase covers recurrent submissions (see five elements at the top in Fig. 5; cf. seminar topics in Sect. 4) to foster the continuous associated work in the teams.

Fig. 5.
figure 5

Project phase in 2016 with highlighted aspects

Full size image

This phase also contains three customer dialogues per SWP.

5.1 Roles of the Laboratory Team

As the embedded systems laboratory team of the university at present consists of four persons, it is sensible to have clearly defined roles in the project phase:

  • Lecturer: In the role of the observer and point of contact for theoretical questions.

  • The Laboratory engineer answers technical question and lends a hand while progamming.

  • The customers’ role is embodied by the the Research assistants, i.e. they have the time schedule in mind, give feedback to the students.

5.2 Project Tools

The tools in the project phase are nearly covered by every seminar topic (cf. Table 2), except the topic “Requirements”.

Table 2. Tools in the project phase on basis of the seminar topics
Full size table

6 Summary and Outlook

The course and esp. the Wiki is still implemented in the existing learning management system Moodle [9]. The usage of central questions concerning the seminar topics has been very helpful [3]. The collection of seminar topics worked well, as the students’ brain storming overlapped well with the predefined cluster (2015).

Therefore the usage of the Wiki, the collection and formulation of seminar topics have again been proven and should be exploited in 2016.

The teams have been quite motivated last semester (2015). This aspect as well as the linked activation should be the focus of evaluations in 2016.

One rather negative aspect remains: A lot of effort is done to evaluate and grade all the steps and artifacts the students produce during the semester. It is essential to define criteria to be able to grade fair and objective. Different schemes with defined criteria have already been established: e.g., one for the Wikis, one for posters, but also one to give feedback during the project concerning every submission. This was done in order to fasten the review process, to reduce the effort for lab team in general and to increase objectivity.

Could several elements be “outsourced” to the students? On the one hand, this might be too huge a responsibility, partially because they are in the middle of the learning process, i.e. they have no experiences concerning either factual knowledge or giving constructive feedback. On the other hand, students might be able to reflect the work of others and conversely their own.

This aspect has to be discussed.

As the title of this publication promises a “validated educational format”, all semesters (2013–2015) have been validated from the students’ as well as the lecturers’ perspective (cf. Fig. 1 Footnote 7), however it is unfortunately beyond the scope of this publication to present these results in detail.