Background - Course Structure

Advanced Software Design is a 5 cr. course based on project work. There are 8 lectures that cover UML (class, sequence, communication, architecture), and GRASP and design patterns.

The lecturer provides 3 documents with explanations about the goals of the course and the case study to work on during the course (goals.pdf and requirements.pdf). In the case study, there is information about the achievement-based system. This system takes ideas from IOOPM, but converts it into a feedback-based system, where students are not evaluated on the achievements (as if it was an exam), but rather they are free to ask questions and feedback on the design.

For the project, students form teams of 4 and have 30 min weekly meetings with the TA. Each week, the students work on some of the achievements of their choosing and send the achievements to the TA. Students must submit the achievements at least 24 h before the actual meeting. The TA gives them feedback on how to improve the design, errors in notation, misconceptions, etc.

(There is an extra assignment where students peer-review each others design.)

This process is repeated until the end of December (usually the last meeting is December 20). After that, the students can continue working on their design until the final date, Jan 10. On Jan 10, all teams submit to studentportalen a report with all the software artefacts produced. The report should link the diagrams with the achievements.

Changes with Respect to 2018

More Meetings with the TAs

In 2018/19, the course has the same structure but the number of meetings that the TAs had was lower than other years. The main reason was that the TAs were new and we only had one TA (Raphaela Heil, 120 h), and a master student (50 h). This year, we had Raphaela and Albert Mingkun Yang (who had TA the course in previous years). Given that they both had experience, I asked whether it would be ok to introduce more meetings than in previous years, to what they said they could manage. This meant that they met students 6 times, instead of 4 (as in 2018).

Peer-review moved to another week

In 2018, students had a peer-review assignment and the overall comment was that it was placed way too early in the course. That meant that they could not give meaningful feedback. For this reason, we postponed the peer-review assignment to one week later.

More in-class Examples

Based on input from previous years, I introduced much more examples in the lectures, which were not covered on the slides. In many ocassions, we took some familiar idea and design it on the fly during the lectures. We did this with examples such as Fitbit or a blog.

Individual Exercise for Higher Grades

To get a higher grade than the one that the group pursues, students could setup a meeting with the main lecturer and establish how to show that the student has in-depth knowledge of the subject. In most cases, these was equal to doing the higher grade achievements at a small scale. I believe this approach worked quite well overall, although it is a bit more messy and puts more pressure on the main lecturer.

Reflections from 2019

Better Explanation of the Project

The requirements.pdf shows a project description of a system. This description should serve as a guideline, but students do not need to strictly follow this as a definition. However, this is not well understood and many students try to fit all the elements described, even when these are not well understood. This leads to designs which do not make sense, as the responsibilities of the designed components do not do what is expected. In many other cases,students try to explain what it is supposed to do just to realise that they do not understand what the component is supposed to do.

Suggestion for improvement

1. Remove some elements that may caused confusion.
2. Introduce another project
3. Explain very clearly that they do not need to introduce all the elements and that they are free to add or remove components as needed.
4. Let groups decide on what to design from a bunch of unspecified and vague projects, and go with the flow on the design that they want to do.

Design vs Coding Expectations

My overall feeling is that students think they are going to write code on some fun project and create a design. However, to completely separate the distinction between design and implementation, the course is solely focus on design (with minimal part of implementation). I believe many students would find the course much more meaningful and appealing if there was a bit more of implementation. However, to do this right, the course would need to increase its workload and 5 cr. is not enough.

Suggestion for improvement

1. Merge this course with another of similar characteristics and introduce a coding part
2. Nothing more unless it has higher workload, e.g., > 5 cr.

What do Students Think

The course evaluation had a high number of students responses, 41 out of 85 students replied. However, from the total 85, only actually 80 took the course, so I think it is fair to assume that 41 out of 80 students replied (51%).

Questions

Regarding Q1. How satisfied are you with the course (Figure 1), a total of:

• 11 students (27%) ranked the course between very low and low (1 and 2).
• 14 students (34%) ranked the course as generally satisfied (3).
• 9 students (22%) ranked the course as quite satisfied (4).
• 7 students (17%) ranked the course as extremely satisified (5).

and all students thought that the course was relevant to their education (grading 3 and higher in the evaluation, Figure 2).

A large number of students considers that they put the right appropriate amount or effort (Figure 3).

The course has 8 lectures, and 56% of students came only to half the lectures or less. The remaining number of students (44%) came to 5 to 8 lectures (Figure 4).

From the two seminars, 30% do not attend to the seminar or do not want this to be known, 39% only attended one seminar, and 29% attended both seminars.

Interpretation of the Results

The course evaluation seems to be quite similar to the results from 2018. This was surprising to me, since the year before we had less meetings and inexperienced TAs. However, we got pretty much the same feedback and grading results (and mostly similar grades, Figure 6):

• We should improved the overview.pdf and requirements.pdf, which we did.
• We should have more meetings with the TAs, which we also did.
• We should include more examples, which we did during the lectures.

In terms of the PDFs, we provide quite a bit of information so that the students are aware of the system. We also omit all the details so that they can choose modifications. Next year, the explanation of the system under design must be improved / or reduced. I would also consider giving almost no information on the project under design and let students work on what they find interesting to design.

In terms of TAs, we also had the best possible scenario, two experienced TAs. In this regard, there was misunsderstanding with one of the TAs, who applied an evaluation approach (as in IOOPM) to the meetings until quite late in the course. The students complaint and we did as much as we could to fix this in the remaining meetings. The take away message is: check that all TAs are on the same page, regularly.

The slides contain some examples and I did, during the lectures, just-in-time examples starting from 0, such as modelling a blog, a health tracker (Fitbit), etc. However, after 4 lectures, only a max. of 25 students were showing up. This means that many students missed important explanations on how to design a system from the ground up. If possible, I think the course could benefit from making X number of lectures mandatory to attend.

TA Workload

• Raphaela Heil is a senior TA in this course. She manages 10 groups. The number of hours is roughly:

  2 h / group for preparation, booking room and, includes the 30 min meeting.

  2 h / group * 10 groups * 6 meetings = 120 h

  I usually check a bit on how much workload she has, since it is pretty close to the number of hours and any setback can throw this off. She has been managing really well the workload.

• Albert is a senior TA and had < 120 h

  2 h / group * 7 groups * 6 meetings = 96 h

• The introduction of a new TA in this course is quite difficult. One needs to give advice on a design, right on the spot, and designs are not 100% right or wrong. If the TA does not know the course content, give the TA 3 h for preparation of meetings. The preparation of the meeting could be actually trying to understand the design document, or reading chapters on the book to familiarise themselves with the material.

  Example: A master student who knows some bits of the course but needs to catch up will take on 50 h TA, which amounts to:

  3 h /group * (2 or 3 teams) * 6 meetings = 50 h