PSV 3/4

SOFTWARE ENGINEERING
(taught in English)

10 Points, Periods 3 & 4, Spring 2001

Instructor

Pierre Flener, PhD, Docent
http://user.it.uu.se/~pierref/
Pierre.Flener at it.uu.se

Goals

1. The main objective is to make students familiar with the fundamental principles and techniques of Software Engineering. This will allow the students to acquire further knowledge later, be it through advanced courses or through self study and practice. This also means that the lectures themselves have a theoretical flavour, as they discuss no particular tools or environments. Once the fundamental principles and techniques are understood, the usage of tools is easy, whereas the study of any particular tools would not prepare the student for the usage of other tools or of the better ones that are bound to emerge. Furthermore, the usage of tools without understanding their underlying principles is outright dangerous. The focus is on understanding why a particular technique should be applied, or why it should not be applied, rather than only on how to apply it.

2. Some practice of software engineering is acquired through the specification and design (but not the implementation and testing, for time reasons!) of a significant software application, as a project for teams of about 5 students. For comparison purposes, the same project is assigned to all teams. The topic is at the discretion of the instructor, but is chosen so as to be most likely outside the expertise of all the students. Such a project for an external client has the advantage of learning what it means not to decide in-house what the requirements actually are, so that the client must be consulted on every single issue. For pedagogical purposes, each major deliverable is rewritten at least once, so as to learn that no document is ever perfect, namely because of evolution of the requirements and because of errors in content and style. Major methodological decisions are taken by the instructor, but the actual choice of techniques, notations, tools, and environments is left to the teams, under the instructor's guidance.

Textbook

Shari Lawrence Pfleeger.
Software Engineering: Theory and Practice.
Prentice-Hall, 1998.

References

For the project management, we shall follow:

Watts S. Humphrey.
TSPi - Introduction to the Team Software Process.
Addison-Wesley, 2000.

You must use/adapt its on-line supplements, such as the forms and the support tool.

For the requirements process, we shall follow:

Suzanne Robertson and James Robertson.
Mastering the Requirements Process.
Addison-Wesley, 1999.

You must use/adapt its Volere Requirements Specification Template.

Office Hours

Upon appointment only, the instructor holds office hours for each team, in his office or elsewhere (the location is to be arranged by the team).

Lessons & Labs

There are no lessons and no labs, all practice being achieved through the project.

Project

Upon filled-out forms from each student, the instructor divides the class into teams (ideally of size 5, otherwise of size 6), and assign a precise role to each team member, early on in the course. The instructor is the coach for the teams, as well as their client and user. The same project is then launched by all teams.

Through appointments with the client/user, each team elaborates a requirements specification (version 1) for a software helping to solve the problem. Upon constructive feedback from the client/user and coach, each team eventually has to produce 2 more versions of their requirements specification, because of errors & inadequacies in earlier versions and/or because the client/user is changing his mind.

Each team also has to come up with a design specification (or module architecture) (version 1) corresponding to their requirements specification. Upon constructive feedback from the coach, each team eventually has to produce 1 more version of their design specification, because of errors & inadequacies in the earlier version and/or because of the occurring changes in the requirements specification!

Finally, without actually writing the software, each team has to produce a test plan according to which they would validate & verify the software, such that it would give them a reasonable degree of confidence in their software.

Schedule

Lecture Schedule

Project Schedule

Exam Schedule

Exams & Grading

Within the first exam, each team will have a 2 hour oral project postmortem with the instructor, only over the final versions of their documents for the project, and maybe over some of the course material.

30% of the grade depend on the requirements specification
20% of the grade depend on the design specification
10% of the grade depend on the test-plan
20% of the grade depend on participation in the classroom and in meetings with the instructor
20% of the grade depend on participation in internal team meetings, according to anonymous peer-evaluation

The second exam will be a written exam over the course material. It is reserved for those who failed the first exam and thus actually participated in a project team, as the project is a mandatory part of the course and can only be taken while the course takes place.

Miscellaneous

Check here if you used one of my many abbreviations and notations when copying from the board, but cannot remember what it means...

Former students enjoying the project work!