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 2002. 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 6th March (for
individual assessment reports).
- 11th 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.
- 16th January (third SEOC2 lecture): Everyone gets
the requirements document.
- Week following 16th January: Each team meets for a
half-hour with me for orientation and preliminary division of
responsibilities.
- Week beginning 4th February: Each team meets for a
half-hour with me to review progress. 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.
- 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).
- 22nd February (SEOC2 lecture): We now change roles
and work individually in assessing the proposals of the
teams. In the lecture today you will be allowed to choose a
proposal from a team other than your own team. Your job now
is to review this proposal and present a brief justification
(no more than one A4 page of 12 point text) for your
assessment. A copy of the lecture slide with questions to ask
yourself about proposals appears
here.
- 6th March (SEOC2 lecture): You give to me your
1-page review at the end of the SEOC2 lecture today.
- 8th March (last SEOC2 lecture): I shall summarise
the outcome and announce the winning team in the last SEOC2
lecture.
Content of Team Report
The report produced by each team (and delivered to me on 20th
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 the 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 pages (including diagrams)
using 11 point text on A4 paper.
Assessment
Your total practical mark is calculated from the following
components:
- The ranking of your team's proposal (judged by me,
informed by everyone's assessment reports) balanced with the
estimate given by your team of your contribution to it counts
for a maximum of 70%. Notice that this means someone making a
big contribution to a lower ranked proposal could do better
than someone making a smaller contribution to a more highly
ranked proposal.
- The quality of your 1-page assessment report (judged by
me) counts for a maximum of 30%.