Software Engineering and Design 2003-04
Principal lecturer: Dr Alan Blackwell
Taken by: Part II (General), Diploma, Part IB (but only aimed at those who have not taken Part IA Software Engineering)
Syllabus
Past exam questions are in several places: [SoftwareEngineeringandDesign] [SoftwareEngineeringI] [SoftwareEngineering]
See also the following relevant questions from related courses:
2000 Paper 7 Question 13 (Additional Topics),
2002 Paper 2 Question 7 (Software Engineering), and
2002 Paper 7 Question 10 (HCI).
Online Teaching Material
The printed course material has been designed (following sound
software engineering principles) so that lecture notes and
presentation slides can be maintained as a single source document -
authored in MS PowerPoint. An Acrobat version of that
printed material
is available here (3.5 MB)
Notes for Supervisors and Directors of Studies
General Approach
My intention in this course is to emphasise practical skills for
system design rather than theory of software engineering. I do
this for two reasons. The first is to concentrate on
transferrable skills, as it is my impression that rather more Diploma and
Part IIG students go straight into professional software development
jobs than do Part IA students. The second is better to prepare
students for their project work next term. In supervising many
Diploma projects, and when organising the group projects last
year, I've found that the Dip/IIG students benefit greatly from
some basic guidance on how to go about the different phases of
system design.
Comparison to Software Engineering IA
The material in this course is partially derived from the IA
software engineering course, so provides some opportunity to catch up
for students who have entered Part IB directly. However I have also
removed much of the material from the Part IA course, especially on
the topics of software risks, security and safety critical
systems.
I have added to this core material two lectures on practical code
construction techniques, two lectures on object-oriented design, and
three lectures on user interface design. Each of these topics is
addressed at a basic level, but emphasising techniques that can be
applied immediately in project work.
Course texts
More detail, supplementary to the unusually broad range of
introductory material in the lectures, is available in the course
texts. I've done a lot of research into selecting the texts. I
believe they are the best available, and all genuinely useful to
students entering professional life. There is no single text that
adequately describes current best practice in these different
areas. I know that four texts is a lot for a single course, and
I'm very consious of the expense involved for students. I can
honestly recommend acquiring these texts for your college
libraries - they will be of general interest and utility beyond
computer science students.
If supervisors wish to do some background reading, some of the
key passages are chapter 2 of the "UML Distilled" book, chapters
5-10 and 22 of the "Code Complete" book, and chapters 2,3 & 9 of
the Interface Design book. Pressman is the best overview of the
whole process, but is not really adequate on the specific topics
I've listed.
Supervisions
The question of how a practically-oriented course should be
supervised is not straightforward. When this kind of material is
taught in engineering schools, it is usually done within
practical design classes and assessed short term design
exercises. I think there is little point in adding this kind of
additional load to our students.
As my intention has been to help these students get to grips with
their project work, my proposal is that they use the projects
themselves as the context in which to test the material they have
learned on this course. I therefore suggest that you schedule
supervisions for this course after the start of the projects (group
projects for IIG and IB, dissertation projects for Dip).
As in Software Engineering 1A, it is likely that examination
questions will be essay-based. It will therefore be valuable for
students to have some practice at composing essays and seeing
how they are assessed. My suggestions for set supervision work
are as follows:
Diploma students:
- Write a short essay (2 pages) describing the way in which your
project has taken account of the needs of people who might use
the system you are developing.
- Write a short essay (2 pages) describing the overall design
of your project, supplemented with UML diagrams (you may draw
these by hand if necessary).
Part IIG students:
- Write a short essay (2 pages) describing the project
management structure that has been adopted by your group, and
analyse its effect on the project lifecycle.
- Compare the coding styles that have been used by different
members of the implementation team on your group project, and
explain the way in which they have influenced the design.
The normal equations would suggest at least two supervisions for
a 12 lecture course. I would recommend following that model -
meaning that if the above questions are used, all students will
have a chance to answer each.
Marking
Essays written for this course should not be a "rant" or collection
of personal opinion. Unfortunately, computer science students do
sometimes treat essays as an invitation to give their opinion, not as
a piece of academic work. Students who submit work of this kind should
be given clear feedback to indicate why it is not appropriate in an
academic approach to engineering and design, and also fair warning
that exam questions, if answered in this way, will not be marked
favourably.
I recommend that students be asked explicitly to refer to specific
analytic, evaluative or planning techniques that have been presented
in the lectures, and even to cite the actual location in one of the
course texts where each point they make can be found. This can form
the basis for valuable discussion during the supervision, if you can
arrange to have a copy of the textbook with you.
Feedback
Feedback on the course, the lecture notes, the texts, or these
notes is highly welcome. This course is not directly modelled on
any other taught elsewhere, and is derived from my own research
into best practice in design. Because of this, there are bound to
be resulting weak areas. I hope to fix those in future years,
with the help of your feedback.
|