Selected topics in software development

Quarter 3, 2008

> Evaluation
   ISIS home

The CPH STL project

Course evaluation

The course evaluation was carried out in the form of a structured dialogue. Each student was allowed to write at most five (5) comments about the course, including what was good and what was bad. Thereafter, the comments were circulated around and each student could mark the comments he or she agreed on. The comments that got most marks were then discussed by the students and the teachers (Claus and Jyrki) in a dialogue. The comments that gained general acceptance are listed below. The number of "votes" received is given in parentheses after the comment.

Based on the comments and the dialogue, some corrective actions will be necessary when the course will be offered next time (spring 2009). The corrective actions, both at the department and at the course level, are listed below.


Number of students who registered for the course: 23
Number of students who passed the course: 11
Number of students who have registered for the re-exam: 3
Number of students who took part in the structured dialogue: 5 Number of students who sent their feedback in electronic form: 4

Positive feedback (in Danish)

- Meget spændende, forskellige emner der alligevel 'hang sammen'. (5)
- De emner der behandles ved forelæsningerne er meget relevante og spændende. (5)
- Godt at kurset er bredt rent fagligt (f.eks. lige fra psykologi til kode). (5)
- Kurset var godt når der blev lagt vægt på at dele viden om værktøjer de studerende i mellem. Dog skal værktøjerne demostreres live. (5)
- Testingopgaven var god; måske den burde hedde testing + refactoring. (5)
- At holde de studerende aktive med oplæg er godt. (4 1/2)
- Det var et godt "supplement" til pensum med de individuelle fremlæggelser fra de studerende. (4 1/2)

Negative feedback (in Danish)

- Pensum er forholdsvis stort inden for visse emner. (5)
- Testingopgave er en udviklingsopgave. (5)
- Testing-assignment bør omformuleres, da der er meget arbejde at gøre, før der kan testes. (4 1/2)

Corrective actions at the department level

* A course on software construction should be offered earlier in the curriculum. This point was mentioned by two of the students and crystallized as follows by one of them: "I would like to congratulate you on a very inspiring course---I'd wish I'd attended it on my first year, but I probably wouldn't have gained the same."

* The new grading scale is a disaster. We used---and will continue using---the European counterpart, except when giving the final official grades. The European scale A, B, C, D, E, F, Fx indicates clearly that the scale is linear which is not the case with the new Danish scale. Our hope is that the European standard is adapted in the whole faculty as soon as possible.

* Half of the assignments were handed in via the ISIS. The course had two external teachers, but the course period was too short (7 weeks) to obtain permissions for them to access the assignments handed in. It should be possible for the course coordinator to give the other teachers the right to access the ISIS pages related to our course.

Corrective actions at the course level

* Textbook on software construction: We can rely more on McConnell's Code Complete; we did not know before the course start that the 2nd edition of the book covers so many of the topics we also wanted to cover.

* Textbook on testing: The exam requirements contained far too many pages from Binder's book. There were many pages with little contents. Simply, we must find some better material on testing.

* Less photocopies: We should focus on, say, two course books, ask the students to acquire them, and provide the remaining material via the course home page if possible.

* Assignments: The name of the testing assignment should be changed; the assignment involves both refactoring and new development. Based on individual learning preferences, some participants liked the testing assignment but disliked the survey assignment; and for others it was vice versa. That is, we keep the assignments as such, except that we change the name of the testing assignment.

* Feedback: For one of the groups the feedback for their testing assignment was provided quite late (four days before the exam). We should distribute the grading of the assignments more evenly among the teachers and work in parallel to be able to provide timely feedback for the students.

* Course description: We should improve the course description so that it becomes clear that the course is on software development and that in the assignments we work with real programs, not with toys. This year the library code considered was written in C++ and relied heavily on templates. That is, earlier experience with generic programming was useful if not necessary.

* Dropping out: 9 of the 23 registered students dropped out from the course. Most of this dropping out occurred during the first two weeks. It is positive that not many of the dropouts wasted their time with the course, but in our opinion the dropping out was too large. Some who dropped out had a family, a full-time work, and wrote their bachelor project simultaneously with the course. Under these conditions it is difficult, if at all possible, to pass the course. Next time we should announce clearly that this is a work-intensive course (1/2 workload for a full-time student).


We are grateful for the feedback we received, and we want to thank those who provided it for us.

On behalf of the course team,

April 14th, 2008
Jyrki Katajainen

This page was last modified by Jyrki Katajainen on 19.04.2008.