Course analysis for Software Engineering (MVK), spring -00

Author: Karl Meinke, NADA

Below is a course analysis for the course on software engineering.

Course Data

The course was taught in spring 2000 and consisted of:
Lectures: 28 hours
Exercises: 14 hours
Coursebook: Software Engineering by Ian Sommerville (1997) (5th Ed), also "Software Engineering Standards" by C. Mazza et al. (1994), and "Managing your Software Project" by I.W. Ricketts (1998) (1st ed)
Number of students: 42.
Student performance:
first exam April '00, 38 students took exam (previously 32), 6 VG (pass with distinction) (previously 6), 30 G (pass) (previously 26), 8 U (fail) (previously 0). Average grade = 54%, pass mark = 19 points = 48%
second exam May '00: 9 students took exam, (previously 1) 0 VG (previously 0) 8 G (pass) (previously 1) 1 U (fail) (previously 0).
third exam August '00: 1 student took exam, (previously 0) 1 G (pass).
Course leader: Karl Meinke
Assistents: none.


To cover all phases of the waterfall software development lifecycle. Also to cover related quality assurance issues such as formal methods. The course is intended to give assistance to the project course. In particular, a specific industrial standard for lifecycle documentation is discussed, namely the PSS 05 standard issued by the European Space Agency (ESA).


The course material was revised and restructured from the previous year with about 25% new material (on formal verification, Floyd's method etc). An extra coursebook to cover student project administration was introduced. Most importantly, in collaboration with Lars Kjelldahl, student projects were based on real industrial projects for the first time. This raised the general level of quality of project work. Student exam performance was similar to '99 in terms of performance, but weaker in terms of the number of students resitting the exam (up from 1 to 9). Nevertheless a slight drop in student satisfaction seems to be visible, though this is based on only half the sample size percentage wise, and may not fully reflect the general class opinion.


The course now only half follows Sommerville's book "Software Engineering"). At least 50% of the course material is original. For this reason, Sommerville is now only "suggested" and not recommended. For the following year, a new coursebook was sought (and subsequently found!). New material for '00 concerned formal programn analysis and verification, theoretically in terms of Hoares logic and practically in terms of Floyd's inductive assertions method. In the lektioner, many practical examples of using Floyd's method were considered. New material constituted about 20% of the course.

Lektioner and Project Work

As in previous years, 2 points were available for project reporting and project work. Project groups were slightly larger than in '99, with 6 being an average. New for this year was the possibility of an industrial project with an industrial sponsor (for which I have to thank Lars Kjelldahl, who did all of the hard work of collecting projects). This was very popular with the students, and nearly all projects had an industrial sponsor. In practise the level of support from the sponsor varied greatly.

Also new for this year was the recommended book, "Managing your Software Project" by I.W. Ricketts (1998) (1st ed). This was an attempt to solve student dissatisfaction with project support the previous year. The book itself is quite good with lots of practical advice. However, it was not clear how many students bought a copy, and the impact did not seem to be great.

To support the project work, examples of PSS 05 documents (requirements documents etc) were added to the course web site.


Exercise classes were again used for two main purposes. Partly to go through material from Mazza et al, which presents a concrete standard for documentation of the development process (PSS 05), and partly for students to present the results of their documentation work. PSS 05 also contains components of IEEE documentation standards, 828, 829, 1012, etc.

Four reports were to be produced as part of the project exercise, namely a project planning document, a user requirements document, systems requirement document and an architectural design document. The project planning document was a new addition meant to allow the students further time and space to prepare for the project before starting it formally. This was a clear benefit.

A third purpose of lektioner was to go through practical examples of using Floyd's method to verify programs.


Examination was by a 5 hour paper. The grades obtained on the first examination indicate a suitable level of difficulty on the first paper, while the second exam was perhaps slightly too easy? Unusually, a third exam was necessary for one student.

Student questionnaire

A simplified questionnaire with more space for comments and a more uniform mark scale was used, compared to the previous year. This makes comparison with the previous year a little tricky and I have renormalised the previous years averages where necessary. The questionnaire was handed out in the final lecture, so that all students attending that class replied.

A total of 23 returns from 42 students (i.e. 54% of student participants - previously 99%) were received.

Here are the results of the survey.

1. Rate the clarity and quality of the lectures (förläsningar): average 3.4 (previously 3.87)

1 very unclear 2 unclear 3 fair 4 clear 5 very clear


repetition av logik lite väl omfattande.

Några av logik delarna var grumliga och lite oklara. Notationen var inte strikt. Mer exempel, annars bra!

Ibland intressant.

The logic part was not completely clear.

När Karl håller sig till ämnet är han bra.

2. Rate the clarity and quality of the course notes (kursbunt): average 3.0 (previously 3.45)

1 very unclear 2 unclear 3 fair 4 clear 5 very clear


Förkortningar används utan introduktion och långt ifrån ursprung - svårläst.

Missing some clear examples in some areas.

Bra, MVK och OOP2 kursbunterna kommer att användas även efter NADA tiden.

It was clear, but it could be better if we gave all the notes in one and in (the) beginning of the course.

Jag gillar dina kursbunter.

Handskriven kursbunt ger ett mycket oseriöst intryck av kursen.

3. Rate the clarity and value of the project exercises: average 3.0 (previously 3.29)

1 very unclear 2 unclear 3 fair 4 clear 5 very clear


OK genomgång av innehåll men lite för dålig info om struktur på arbete, informationsamling.

Good practice.

Visa dokument var det mycket svårt att veta vad som skulle ingå, exemplerna på nätet var inte bra alla gånger.

Man har lärt sig mycket genom att göra dem, men vad de ska innehålla kunde klargöras bättre.

Viktigt och nyttigt, PSS 05 bra!

Väldigt tidskrävande innan man kommer igång.

Projektet i sig är jättebra, men som du sa i kursensbörjen, så vet man inte vad som ska vara med i resp. dokument. Fler exempel på bra dokument.

Ingen feedback, dålig info på hemsidan, svårt att veta vad som ska vara till alla dokument.

Good to have a real project to work on.

4. Were you satisfied with support for project work (redovisning, advice etc)?: average 2.7 (previously 3.1)

1 very useless 2 useless 3 fair 4 useful 5 very useful


Önskar mer feedback på inlämnade dokument.

Good to have to present your work in front of the class.

Jag tycker att rapporterna rent språkligt borde användas i svenska kursen eftersom svenska kursens uppgifter är mindre intressanta. Det ger en bättre genomgång av rapporterna och skulle förbättra båda kurserna!

5. Overall, how satisfied with the course were you? average 2.8 ( previously 3.06)

1 very unsatisfied 2 somewhat satisfied 3 fair 4 satisfied 5 very satisfied


Klart relevant kurs och kursinnehåll!

A bit unclear what the exam is really good for, a lab on Z, TRIO, CASE tools would have been better.

Orelevant matematik, övningar på Floyd's method & temp logik, där vi får öva hemma och där vi går igenom svaren gången därpå.

A small project can never get a VG on its reports.

Bra kurs men vad har logik mm med mvk att göra. Kanske allt, men ingen som jag vet anväder det vid projektet.

Behövs något i den här stilen för att man skulle få en bild av problemen ute i jungeln.

Maybe there is a good book containing a small introduction to formal methods?

More focus on managing a project and maybe testing and integration. Floyds method doesn't feel too necessary to learn.

I'm not a writing person. It's good to finally be taught formal methods (I missed them in OOP2) but they or the PSS 05 didn't really fit our project, so it felt a little stupid using it anyway.


The course went "reasonably well" this year, though student evaluations indicate a slightly lower level of satisfaction compared with '99. This is a little bit surprising considering that several improvements were made, and the statistical significance is perhaps slightly questionable.

For next year, I will try to:

find a better coursebook that covers as many aspects of the course as possible.

reduce the total amount of material, and focus in more depth on what remains

make a detailed contents description for each of the PSS 05 reports.

Page editor: <>
Last changed May 15 1999
Technical support: <>