Copyright Chris Johnson, 1999.

Safety-Critical Systems Development

Open Assessment 1999-2000

A. Introduction

It is difficult to provide a realistic exercise in a one-term course on safety-critical systems development. In particular, it is hard to avoid using COTS or a contrived example. Instead, I want to pose a design challenge that may have significant real-world benefits. The challenge is to support the on-line presentation of accident reports. You are free to choose an appropriate presentation format and to choose which accident you will look at.

The main point behind this exercise is to move beyond paper-based presentation techniques for accident and incident reports. The on-line documents produced by the FAA, NTSB and CAA tend to be direct translations of their paper based versions (for more examples of this see This ignores the opportunities provided by electronic media. I have written a paper about improving the presentation of accident reports .

Warning: you are not accident investigators. Therefore, it is important that you minimise any unnsupported interpretation of the evidence presented in the reports. In particular, it is not the purpose of your analysis to assign blaim to any individual or organisation involved in the incident.

B. Your Task: Alternative Presentation Formats for Accident Reports

It is important to start by recognising the information needs of the people who read these reports. There is a questionnaire into the usability issues that surround these documents. In particular, these documents must provide easy access to both the narrative accounts of the events that took place and the interpretation/analysis of those events. It is, therefore, important NOT to include gratuitous icons, distracting animations, unnecessary noises etc. There are a number of different approaches that you might adopt (it is NOT recommended that you try to support all of these options):

C. The Design Brief

This exercise enables you to apply the knowledge that you have gained about safety critical systems development. Each of the approaches, outlined in the previous section, present information about previous systems failures. The focus is on effective communication and not the gratuitous application of technology. A well designed, low-tech approach will score more highly that a poorly designed desktopVR system.

In the documentation (see below) that you submit with your solutions, it is very important that you explain who the users of your system will be. You must also specify the particular information needs that the site will support.

D. Assessment Criteria and Submission Details

This exercise is degree assessed. It contributes 30% to the total marks associated with this course. The body of the report should not exceed twenty A4 pages. The report must be printed out and must be submitted in a secure binder (i.e., one that will keep the pages together and in the correct order). It must include:

  1. A title page containing the name of the student as well as their contact details (email address etc);
  2. A table of contents and appropriate page numbers;
  3. A section on the design of the system. This should include some consideration of alternative approaches and a considered justification of the reasons why you build the system in the way that you did.
  4. An implementation section. This should describe the techniques that you used during the development of your system.
  5. An evaluation section. This must consider both formative and summative testing. Formative evaluation might include user testing of pencil and paper prototypes and of partial implementations. Summative evaluation describes the testing of the final system.
In addition to the twenty pages associated with the body of the report, you may also include appendices. These should contain:
  1. the listing of any code used during the implementation together with suitable acknowledgements for the source of code that has been borrowed from other programmers;
  2. internal documentation (maximum two sides). These are notes that are intended to provide guidance for anyone who must maintain or develop your system.
It should be handed in at the start of the lecture on Tuesday 14th December 1999. Extensions will only be granted in exceptions circumstances and they should be requested prior to the deadline. Extensions for medical reasons should be reported as soon as possible and should be supported by forms from a medical practitioner. Extensions for equipment failures may be granted provided that you let me know as soon as they occur; so that I can make sure they get fixed as soon as possible. Please make sure that you keep back-up copies of all of your work towards this exercise.

The following marking scheme will be applied:

All solutions must be the work of the individual submitting the exercise. If any code or design ideas are borrowed from course notes, books or other students then those sources MUST be clearly acknowledged. All questions about this exercise should be addressed to Chris Johnson. There are detailed submission instructions for the final pages.

Back to the main index...