Software Engineering with Objects and Components 2
Design Practical
This page describes the assessed practical exercise for the Software
Engineering with Objects and Components 2 module given in
January-March 2003. The practical counts for 30% of your final mark
for the module. Its primary aim is to give you experience in working
within a team to deadlines to produce an outline specification for a
large system from an independently produced requirements document.
You are provided with a real industrial report describing the
requirements for track monitoring and control operation in a national
railway company.
Imagine that the rail company now wishes to build an "information management"
system to record appropriate operational information and make it
available to the right people at the right times. The task of
producing the system is sent out to competitive tender, and teams from
different companies have to work to a deadline to produce a proposed
plan of work.
Schedule of Work
The timing of work is as shown below. The principal deadlines are
20th February (for team reports) and 5th March (for individual
assessment reports).
- 9th January (second SEOC2 lecture): We form teams of
approximately five people (four is too small; eight is too large).
The task of each team will be to produce a proposed
design for the information management system (see below for the
required contents and format of the design report). Each team must
nominate a leader who is responsible for coordinating the work of
the group.
- Week beginning 19th January: Each team leader should be able to
send me, this week, a plan for subdividing and coordinating effort
on his or her team's proposal. This need not be more than a
paragraph or two but it should identify the overall archictecture you are
choosign for the design and explain how you plan to construct the
proposal. This is not assessed but it is important that you
produce it so that I know you are working as a team.
- Week beginning 26th January: Inside your team you
should by now be a clear division of labour and each team member
should have made some progress on their part of the design. If
this is not happening in your team then your team leader should let me know.
- Week beginning 9th February: Each individual's contribution to
the design should by now be taking shape and the main issue should
be how to pull the individual contributions together into your
team's final report. If this is not happening in your team then
your team leader should let me know.
- 20th February (SEOC2 lecture): Each team's report is delivered
to me at the end of the SEOC2 lecture today (see below for report format).
- 27th February (SEOC2 lecture): You now change role and
work as a proposal reviewer. Copies of each team's project
proposal will be made available in the lecture. You choose one
proposal (not your own team's proposal) and write a brief critical review
of it (no more than one A4 page of 12 point text).
- 5th March (SEOC2 lecture): You give to me your 1-page
review at the end of the SEOC2 lecture today.
Content of Team Report
The report produced by each team (and delivered to me on 26th
February) should contain the following information, formatted into the
sections shown by the headings below:
- Team description: Name the members of the team and for
each give an estimate of the proportion contributed by him or her to
the proposal. This need not be simply a function of the number of
hours an individual spends on the task, although I would expect that
to be a major influence on the way you decide to share credit. You
should measure effort as a percentage of the total project, so if
everyone put in the same amount of effort and there are 10 team
members then the estimate for each of you is 10%. It is the
responsibility of the team leader to obtain consensus on this. If it
is impossible to obtain consensus then I will adjudicate.
- Architectural specification: A description of the overall
architecture of the system, identifying its main components and their
interactions.
- Selective design specification: A more detailed
description of those components of the system which you consider
deserve closer attention (e.g. because they are pivotal to the success
of the project or because they are unusual in some way). Explain why
you chose to concentrate on those components.
- Safety case: Explain what you consider to be the principal
safety issues in deploying your system and explain the measures (in
software or in the wider social structure of the railway company) necessary to
address these issues.
- Preliminary plan of work: Assume that your company has a
large number of staff, so you are not unduly limited by staff availability.
Also assume that you do not have to deal with legacy code when
implementing your system, so you would start with brand new hardware
and software for the core of your system. Give a rough plan of work
to reach a first prototype of your system, ready for preliminary
testing, within 1 year using no more
than 60 person-months of labour. You should describe the
main implementation tasks; the distribution of people to tasks over
time; and give milestones at which you would monitor the progress of
the implementation.
The report must be no longer than 15 sides (including diagrams)
using 11 point text on A4 paper.
Assessment
Your total practical mark is calculated from the following components:
- 80% on the final ranking of your proposal (balanced against your
proportional contribution to it).
- 20% on your 1-page review report.
