1. Chapter 16: The project
Chapter 16: The project
Introduction
For this unit you are expected to undertake an individual software-
engineering project and to submit a project report to London. You should
take some care in selecting a project topic and preparing for this substantial
task. To achieve good results in this unit you will need to devote substantial
time to this project and ensure that you work on your project consistently
over the year. In past years some students have failed their project because
they started work on it too late or failed to keep work up throughout the
year. There is no way that you can ‘rush’ the project at the last
moment.
You should also understand that the idea of the project is to demonstrate
an understanding of the software engineering process and professional
practices. It is not intended to be about producing computer programs for
their own sake. In fact, you are not required to deliver a fully
running computer program with your project. The crucial part of
your project is the description of the development process which is a
model-based task. You are merely required to implement parts of your
system in order to demonstrate that the design you have created can
actually be translated into program code, and to undertake some testing of
the crucial parts.
The time you devote to your project will be of benefit to you when it comes
to sitting the examination. The experience of developing your own project
will show through in the examination, and will provide you with important
examples of how systems development works in practice. You will know
what you are talking about. Indeed the problems, frustrations, moments of
breakthrough, difficulties and joy you will feel undertaking this work are
the same as those experienced by software engineers in their daily work.
In a section below, I provide some ideas of possible projects that you might
like to consider. You are, however, encouraged to develop your own project
idea for small and medium scale software systems. In general, you should
understand that we are looking for a system that allows you to carry out a
software engineering process which leads to a model of a complete system.
At the end of the project these models should be capable of being easily
developed as software code. This should also include some small coded
elements of the significant parts of the project – for example to
demonstrate and test how a crucial algorithm is performed.
Students coming to this unit are expected to have some experience of
various package environments including databases and spreadsheets. You
are also expected to have a general understanding of programming and
some programming skills (through the units Elements of information
and communication technologies and/or Introduction to
Programming). While you will probably undertake some programming,
and so develop these skills, you should understand that the main emphasis
of this unit is not to teach you more programming, but rather to
concentrate on the intellectual work that leads up to and surrounds the
coding activity.
Details on how to submit the project and the date by which the entire
project must be in London are given in the booklet Completing and
submitting coursework and projects which all students taking this unit
113

2. Software engineering: theory and application
should receive. This booklet is revised each year, and you should make sure
that you have the most recent edition. The booklet contains the exact
deadlines for each year, the forms required to accompany your project and
details of how to submit the project.
Overview
The project, which counts for 40 per cent of the final mark, is intended to:
• take you through the process of developing a sophisticated piece of
software, tackling a realistic problem
• provide practical demonstrations of the key issues discussed in the
subject guide. It is when doing the project that you will come to
realise the importance of good requirements analysis and design, the
benefits of setting up a proper testing process and the problems of
keeping to deadlines and managing projects
• be an enjoyable experience where you can make the mistakes that you
will learn from.
In order to complete the project you are required to produce a number of
documents. It is very important that you maintain coherence
between the documents you create.
In addition to these documents, you are expected to write a final project
report. The main section of the final project report provides a summary of
the lessons you learned, what went well and what you would do differently
next time.
You should note that the focus of the project is not on the system produced,
but on the quality of the process undertaken, the coherence of the
documents presented, and how successful the documents would be in
developing a software system.
One way to think of the project is as an attempt to produce a set of
documents which could be sent to an outsourcing company to ask them to
produce a system for you. Your aim is to produce a set of documents which
would enable the outsourcer to understand what was needed, and go
ahead and produce the complete software system.
The project as a development process
The aim of the project is to give you the experience of the processes and
practices of software engineering. As such, we intend you to undertake the
process of analysing and designing a software product, and submit to us
the documents you used in this process. This means that the documents
should be the practical documents you would use to develop the system.
Before you hand in your project, you could of course go back over your
individual documents again and edit them. However, although you could
go back and change, for example, an initial system requirement so that
they match exactly (and surprisingly) your final design, this is not what the
examiners are looking for. We are much more interested in how you
progressed through the various stages of your project than in the final
result.
In the past many students have achieved a poor mark in their project,
because they have paid too much attention to one part of the process
(usually coding the software) and far too little attention to the coherence of
their development process overall. A project that has many problems
throughout its development process may be rated as highly as one where
everything went well. What is important is that the project documents
114

3. Chapter 16: The project
demonstrate how problems faced were addressed. Examiners are much
more interested in seeing a genuine learning effort that uses the methods
and techniques of software engineering than a running system. Remember
that even professionally produced software regularly fails – we are looking
for the professional approach to software design.
Examiners would be happy to see a page in the later stages of design which said
something like ‘The initial user requirement for XYZ was unachievable as it conflicted
with the other requirement for ABC. It is therefore decided that XYZ is to be dropped
from the design.’ This is the kind of thing seen in real software engineering projects all
the time, so why should your project be any different?
When you write and edit your project, remember Brook’s comment (1995):
‘Most documentation fails in giving too little overview; the trees are
described, the bark and leaves are commented, but there is no map of the
forest. To write a useful prose description, stand way back and come in
slowly’.
It is essential that your documents form a coherent project in which the
examiners can see how the individual development stages have been
carried out and how they relate to the previous and the following stages.
Finally, remember we are very unlikely to reward the ‘software hacker’ who
works through the night to come up with a wonderful piece of software
without bothering to undertake requirements analysis or design properly,
by faking the testing, and by ignoring proper planning. Yes, this person
might produce something which looks impressive, but do not expect marks
for producing a system in a way that does not take into account
requirements, and which is likely to be unreliable and dangerous.
Choosing your development tool
You are encouraged to make use of development tools in your project;
however, this is not a formal requirement so do not feel you have to. You
may want to use modelling tools, design tools etc. In addition you will need
to produce small amounts of software to demonstrate how aspects of the
design will operate. For this you may either want to choose a programming
language, like for example Pascal, Visual Basic, C++ or Delphi.
Alternatively, you may want to choose a spreadsheet or database package.
Although programming languages offer the greatest flexibility, some
application areas may be best suited to, for example, a database package.
Your choice should depend on the kind of application you are designing
and the development tool you have access to. If you choose the object-
oriented development approach for your project you will probably want to
use an object-oriented language to undertake any coding.
Although the project does not require you to write the program
code for a fully running system, you will have to do some
programming of some of the important parts. It is essential that you start to
acquire the necessary programming skills as soon as possible. The unit
Elements of information and communication technologies and
possibly Introduction to programming has given you an introduction
to the component parts of a program. You should be able to use these
concepts within the programming language you have chosen.
You are not expected to write the code for a fully running and
complete system. You must, however, deliver sufficient coding to
demonstrate how a small number of complex elements of your design can
be translated into code. As such you are only expected to produce
programming stubs rather than a complete system.
115

4. Software engineering: theory and application
A programming stub is a small section of code which a developer uses to
demonstrate a principle or idea, and to test that it works. A programming
stub might implement a single Class, or even just one of a class’s methods,
if that method undertakes complex processing (for example an Order class
might have a method GetPrice() which calculates the prices by processing a
range of inputs. You could produce a programme stub to test that you
understand how this would work, and that your design is correct).
This is not the same as pseudocode as a programming stub must be written
in a programming language so that it can be tested. They are usually pretty
short (at most a couple of pages in length) and implement the most
difficult parts of the system (so the developer can test and verify the
important parts of the system before we waste time on the easy parts). It is
also usual to develop some kind of interface to interact with the
programming stub (for example a way of reading a file of attributes, of
calling the program stub with these attributes, and of displaying or saving
the returned parameters).
Examples of other things you might implement are:
• some user interface screens, since these may be needed to produce
your user manual
• if you use a database you will need to provide most of the database
schema
• if you are using data files you will need to describe their format.
Additionally, you should remember that it is very important that you
explain any programming stubs etc. you provide. They should be written
with sensible variable names, and plenty of comments in the code. You
should describe how they would be used within the complete system, and
how they relate to the design activity. Finally, you should provide details of
what components require further implementation.
You are required to provide a printed copy of the source code you produce
as an appendix to your project. In addition, you should submit a disk
containing executable versions of the parts of the system which have been
coded. These do not necessarily need a user interface (you could just ask
for input from the command line, or by reading a file), but must be
relatively easy for the examiner to try.
Those students who are very keen to implement a complete system rather
than just programming stubs can do so. Such students should however
remember that only a small proportion of the marks is allocated for the
programming component of the project, and therefore it is not likely to
drastically improve their marks and could damage their marks by diverting
their attention from the important tasks.
Reuse
Reuse is an important part of software development, and you are
encouraged to reuse code or models and patterns, and auto-generated
code, to aid you in your development of the programming stubs. However,
to avoid charges of plagiarism you must make it clear which
elements of your project constitute reuse. All that we ask is that
you indicate to us the pieces of code that you did not write (or alternatively
highlight the pieces you did) and tell us where the code you are reusing
came from (by referencing its source). You should do this on the source-
code that you submit as part of your report; for example, why not put all
your own code in bold or italic, or you could put comments into the code
where the auto-generated or reused part starts and ends. This allows you to
116

5. Chapter 16: The project
download small sections of code from the Internet and use them as long as
you highlight to us that you are reusing the code. If you fail to do this
you could be accused of plagiarism (cheating), rather than
being rewarded for taking advantage of reuse.
Suggested projects
You are expected to choose your own project to work on. A suitable project
will probably have most of the following characteristics: It will:
• handle some real world data of non-trivial complexity
• require a user-interface tailored to some defined user (who should not
be you)
• undertake some processing/calculation/selection on the data it
contains.
Conceptually a project does not have to be very big to present a real
challenge – as the examples below show, a database type application
tailored to some particular domain is a good starting point.
Projects that do not contain a substantial software analysis and design
component are not suitable. For example developing a computer game is
not appropriate as it does not have specific user requirements (other than
perhaps being enjoyable for users!).
When choosing a topic, remember that you need a project that will enable
you to demonstrate your understanding of the whole software engineering
process. Below is a list of projects you may choose from if you wish:
A personal data management system
This would consist of a small database management system used to record
personal information such as details of records and books, information
about recipes and so on. There may be a diversity of information recorded,
and the system should be easily used by people without a computer
background.
A photograph library sales system
This records and retrieves information about photographs in a library and
the worldwide sales of these photographs. It should support keyword
classification and retrieval requests for different types of photographs. It
should maintain details of fees received and due for each photograph that
is published. Again, the system should be designed for use by people who
are not familiar with computing aspects.
An online recipe and meal planner
This could compute the overall nutritional value of a meal, summarise the
necessary ingredients, and estimate costs. It might also be able to suggest a
meal given ‘I want to use up this corned beef’ or ‘I’m out of eggs and
lettuce’.
A personal organiser for a university lecturer
This would schedule the lecturer’s teaching, send reminders when
necessary (possibly through an e-mail system), perhaps co-ordinate with
other lecturers’ (or even students’) calendars for scheduling meetings, and
so on. Printing parts of the calendar on demand is a must. Questions that
such an organiser should be able to answer include ‘What’s up for today?’
117

6. Software engineering: theory and application
or ‘Let’s see next week at a glance’ or ‘What in the world was I doing last
Tuesday?’ or ‘On what day of the week for the next four weeks is there an
hour free starting at 10:00?’.
A terminal reservation system for a computer terminal room
This would be an automated sign-up sheet for a collection of terminals
(and possibly other resources). People should be able to express
preferences for various times. The system should include facilities for
administrators to collect and print statistics on usage as well as a
scheduling algorithm to ensure fair distribution of resources among users.
It should be easy to change the scheduling algorithm. (Ignore the fact that
you need to use a terminal to sign up for a terminal. For example, assume
that one is reserved for this purpose.)
An online holiday planning system for a busy department
This allows staff to choose and book when they are on holiday. It might
also need details such as who is taking over the person on holiday’s work,
where they can be contacted etc, and maybe make sure that important
people are not off at the same time.
An online system for managing bookings
This might be for a cruise liner or railway.
Deliverables
The deliverables are split into three sections. The first section involves
planning how you will approach the software engineering project. The
second section contains all the documents you produce in undertaking the
project (the models etc). The third section asks you to assess your project
critically, and reflect on the learning it has given you.
Deliverables section 1: project description and planning
This section is an important task as you need to ensure that you can
complete all the necessary documents on time. You should not take it
lightly, and should use project management techniques to help you plan.
You should ensure that you produce a timetable for undertaking the
project, including plenty of contingency time should things go wrong and
including time off, holidays etc. It is important that you balance the
demands of this project with the need to study the subject and
relax. Remember that the project accounts for 40 per cent of
your mark, and should therefore constitute no more than 40
per cent of the time you put to study software engineering. The
project can expand to fill the time available, so make sure you
limit this by planning your activity well and sticking to your
timetable. Indeed, it is better to decide to cut your project
down (for example by ignoring certain requirements) so that
you can finish it than to hand in a half-completed project. If
you need to do this you must explain why you took this
decision in your document.
It is essential that you stick to your timetable in order to avoid severe time
pressure towards the end of the project and to get maximum benefit from
the project. Remember that you will be marked on the entire development
process and not only on the end product. If you start your project too late
118

7. Chapter 16: The project
you will not have enough time to carry out all the stages that are part of
software development.
In no less than two pages you should summarise the project you propose to
work on:
• Give your system a name.
• Describe what the system will do and who its users will be. What
needs will your system satisfy? How will it help the users?
• Outline the most important features of your system.
• Describe the physical environment in which your system will be used
including any other systems with which the new system will interface.
• Are there any important performance goals for your system: time or
space efficiency, security or reliability?
On another two to three pages you should describe the software
engineering process you intend to employ, and how this is relevant to the
system you describe:
• Outline the basic principle of the chosen approach (including
references to relevant literature on this approach). You should also
establish the software development paradigm you have chosen (i.e.
structured or object-oriented).
• Discuss why this process is suited to the problem previously described.
• Provide a very detailed timetable for the activity you are going to
undertake and a detailed plan of the documents you will be providing
and how they will address the need for requirements analysis, design
and elaboration, approaches to implementation, documentation of the
system, and testing. You can use diagrams such as Gannt charts for
this if you wish.
• Consider any problems you might envisage encountering and how you
intend to manage such risk.
You can also use this section to plan how you will manage the
development project and keep to your timetable.
Deliverables section 2: the software engineering practice documents
In the next section of your project you must provide documents which
outline how the software engineering process was undertaken in terms of
analysing the user’s requirements, undertaking design, elaborating that
design, approaching implementation, documenting the system and
undertaking testing. The format for this section depends on the software
engineering processes you have decided to follow (as detailed in section
1).
Examples of the documents you might produce for different software
engineering processes:
Pressman chapter 2 provides a good description of various software
development processes and the types of documents which might be
produced. Below we provide examples of the different sections which
might be produced for projects following different development
processes.
119

8. Software engineering: theory and application
For a project following the software development lifecycle the contents of
the section may look like this:
1. Requirements analysis.
(a) Introduction.
(b) Functional requirements and conceptual model.
(c) Non-functional requirements.
(d) Hardware.
2. Detailed requirements analysis.
3. Design.
4. User manual and maintenance manual.
5. Coding of key algorithms and database schema.
6. Testing document.
In contrast, a student trying to follow the Rapid Application Development
approach (clearly without the team working elements) might have a
document of this form (or similar):
1. Cycle 1
(a) Business modelling.
(b) Data modelling.
(c) Process modelling.
(d) Stub application generation using Visual Basic.
(e) Testing and turnover.
2. Cycle 2
(a) Further business modelling using feedback.
(b) Further data modelling.
(c) Further process modelling.
(d) Application elaboration and changes.
(e) Testing and turnover.
3. Cycle 3
4. User manual of the final system.
Finally, a project which is following the spiral model might have the
following sections (or similar):
1. Spiral 1
(a) Customer communication.
(b) Planning documents – construction of task sets.
(c) Risk analysis.
(d) Engineering (including analysis and design) of tasks.
(e) Construction and release of algorithms central to the problem and
considered of high risk. Construction and release of prototype user
interface.
(f) Requirements planning.
2. Spiral 2
(a) Risk analysis.
(b) Prototype 2 construction (including simulations of a small user
interface).
(c) Detailed requirements and requirements validation.
(d) Development planning.
120

9. Chapter 16: The project
3. Spiral 3
(a) Risk analysis.
(b) Prototype 3 construction (including simulation and benchmarking of
core algorithms).
(c) Design of the complete software product.
(d) Validation of the design.
(e) Test planning.
4. Spiral 4
(a) Risk analysis.
(b) Further design activity to elaborate section 3(c).
(c) Implementation of core algorithm code.
(d) Unit testing.
(e) Acceptance testing.
5. User documentation of system.
Note that just because some of these projects have many more sections, it
does not mean that they should be longer in length, nor involve more
work. You should also try to avoid unnecessary repetition in your
documents. For example you do not need to include every test case you
undertook.
Note that each of these examples differs in some way from the way
textbooks describe the processes. This is expected as it is unlikely that a
project that is undertaken by one developer who has little experience will
precisely follow a formal software development project. You should decide
which sections you need.
Whatever form your documents take, they must include descriptions of
how you undertook the following activities:
You must document how you captured requirements and turned these
into design
This should include some description of the need for the system and place
the system into context, briefly describing its functions and presenting a
rationale for the software system.
Functional requirements – the conceptual model
Your documents should describe the functions that the system will perform
(i.e. it should present the conceptual model of the requirements of your
system). This means that you will have to model your functional
requirements applying (for example) levelled data flow diagrams, entity-
relationship diagrams if you are following the structured approach, and you
will have to produce use-case diagrams and class diagrams if you opt for
object orientation.
It is very important that you document your modelling processes very
carefully. You are expected to explain how they support the further analysis
of your particular problem domain. However, keep in mind that you are not
supposed to give an explanation of how exactly certain modelling
techniques such as, for example, data flow diagrams work.
Non-functional requirements
You should state all non-functional requirements, such as technical
constraints or security requirements, your system might have.
121

10. Software engineering: theory and application
Hardware
If the system is to be implemented on special hardware, this hardware and
its interfaces should be described. If off-the-shelf hardware is to be used,
the minimal and optimal configuration on which the system may execute
should be set out here.
You must document how you approach the design of the system
You must outline the top level decisions you have made, and how these
decisions were broken down into components, how these components are
linked, etc.
The overall design within structural software development, for example, is
concerned with determining the modules and how the modules are linked
and interact with each other. For this purpose you would have to apply
structured design and create structure charts from your data flow diagrams.
The overall design within an object-oriented approach requires you to
model interaction and object behaviour using sequence diagrams and
statecharts.
After this you will need to describe how you elaborated these designs,
adding sufficient detail to them so that it can be used as a reference from
which any competent software engineer can produce code, set up the
testing process, and write a user manual and a system maintenance guide.
The detailed design should include answers to all of the questions for as
many levels as possible.
The detailed design within structured development, for example, will have
to provide the details of the algorithms used within the individual modules.
The detailed design within an object-oriented approach involves the exact
definition of classes (with their attributes and operations) and the messages
sent between objects. You may want to use pseudocode (an outline of
programming code) in order to represent the details required within
detailed design.
During the design process you should focus on the parts of the design that
are essential to producing a core system. You only need to outline the
extensions to a more complete system. Also, do not waste time and energy
repeating the details for parts that have a similar structure. Instead you
should give one design example and explain which parts (and why) follow
the same or a similar design pattern. One of your major goals is to develop
a model that is complete by the deadline. This is not expected to be the full
system. It is essential that you review the entire design process to ensure
that everything has been covered, that the parts of the documents hang
together, and that the design can be related to the requirements.
The user manual
This document should be a self-contained description of how to use your
system. A user manual should be a polished, professional piece of technical
prose that a software company is proud to have accompanying one of their
products. (Also, it is a handy accomplishment to show off at job
interviews.)
The document should have a structure that is evident both to someone
reading it straight through and to someone looking for a particular topic or
fact. A table of contents is required, and the organisation it reflects should
be considered carefully. An index and appendices might also be helpful.
122

11. Chapter 16: The project
Remember, the document should be completely self-explanatory. Do not
assume the reader has seen your functional specification. You may, of
course, edit in sections of prose from your previous documents. Do not
discuss any implementation unless it directly affects the user’s interface to
the system.
Your document ought to cover the list of topics below. The exact order in
which you present material and whether certain topics are combined
should be dictated by your particular project and your own style of writing.
• Introduction: a concise statement of what your program does, possibly
including motivation and philosophy.
• How to use your system: an overall description of the style of user
interaction, device constraints, and any arbitrary design choices you
made that the user ought to know about.
• Detailed system operations: an organised list of all the user commands
and when they are appropriate. Some examples (preferably with
screenshots) might be helpful. Also, it is often appropriate to divide
the user manual into a novice section and an expert section.
• Error recognition and handling: what are the errors that might occur,
and how can they be handled?
• An extended example: show exactly what the user may have to type or
what buttons he might have to press (and why) and how the system
responds (and why).
• A list of known ‘features’ and deficiencies: everyone complains about
how cryptic current computer manuals are. This is your chance to
show us what a good manual looks like.
Outline of the programming stubs/examples you have produced as part
of your design activity
You do not need to implement the complete software; however, you do
need to produce some of the key algorithms – for example, you may need
to implement a couple of classes or models to demonstrate how they would
be achieved. These should be included in your documents along with a
description of what they are for and how they work. You should also
highlight any code-reuse, and ensure that the code is commented and
consistent with the design and requirements.
A description of the testing you undertook as part of the software
engineering process
Testing is an important part of a software project. Testing needs to
accommodate both system verification and validation. The software team
must carefully plan the different testing stages, develop a schedule of when
they are to be carried out, design the test cases that are needed and
eventually collect and evaluate the test results. Accordingly, the software
team must document the order in which modules or classes are to be
integrated and the order in which the individual modules or classes are to
be tested in isolation. Testing and debugging methods must also be agreed
upon, documented, and eventually carried out.
The purpose of a testing document is to convince the management (in this
case, the examiners) that a feasible testing approach has been designed and
undertaken. You are expected to schedule several stages of your tests.
Scheduling is required for unit testing, integration testing, and validation
123

12. Software engineering: theory and application
testing. You should note that the schedule of testing, and the tests
undertaken, will vary depending on the software development process you
have chosen.
In documenting your testing you should include an introductory section
that summarises how testing was undertaken. This should include a
description of how testing was planned and undertaken in detail.
Remember that this description is intended for several audiences. The
document should be organised so that it is easy to find schedule summaries
and monitoring plans.
Your description of the testing should contain the following components:
• a statement of the objectives and success criteria
• an integration plan
• a plan of the testing techniques and test cases used
• a testing schedule
• a summary of the test results and debugging procedures applied.
These components are described in more detail below.
Objectives and success criteria
The testing document should contain a statement of the overall testing
objectives and the objectives of the individual tests that are planned.
Integration plan
It is important to decide the order in which modules or classes are to be
combined and therefore the order in which they will be tested individually.
You must plan for individual module tests, the combination of modules
during integration testing, and a validation test that tests the functionality
of your system.
The testing document should describe and justify your integration method.
The ‘big bang’ method of integration is not acceptable, but many variants
or combinations of top down and bottom up integration (or an appropriate
alternative within an object-oriented approach) are acceptable if
convincingly defended.
Testing techniques and test cases
You should design a plan to test all of the modules (or classes) of your
system. Your testing document should state what kind of testing technique
is applied to test the components of your system, and it should explain why
a particular technique has been chosen. It is very important that you
establish the test cases you will use. Keep in mind that a test case includes
the test input and the expected output against which the actual test output
will be compared. You do not need to carry out your tests for all
components. However, you will want to employ some basic testing
techniques to test the main algorithms within your system (those
implemented as programming stubs). The purpose of this is that you
demonstrate that you are able to select and employ some relevant testing
techniques.
Schedule
The testing document should provide a schedule describing the dates of the
different tests to be carried out within your chosen software engineering
process. First, determine an order in which to perform integration and
validation (functional) tests. This order should be used to determine the
124

13. Chapter 16: The project
order in which the individual modules (components) are to be tested.
Determine the dates by which tests are to be completed. Finally, you must
define a monitoring procedure to ensure that tests are designed and carried
out on schedule. There must also be a procedure for reporting and
correcting bugs. Note that if you are following a evolutionary approach
your schedule may include many cycles of activity.
Test results and debugging procedures
Finally, you should interpret the outcome of your tests and report on the
errors that have been found and the action taken to locate and correct
them.
Deliverables section 3: the final project report
The purpose of the final report is to give an overview and evaluation of
your entire project. This is an important document for the markers as it is
used to evaluate what you have learnt from your project and from the
process you have chosen. The document should be around two pages long.
The document provides an opportunity to step back and put things in
perspective and appreciate how much you have accomplished. In your
report you should cover the following issues.
• What changed: You should discuss how well your project satisfied
the users. Did it do what they wanted? What did you leave out and
why?
• The software process: Were you satisfied with the chosen
approach? What problems did you encounter? Where did you break
from the usual approach to the process?
• Developing the system: Do you think your document could really
be used to develop a software system? What is missing? What is going
to be difficult for someone to follow? Note you will not lose marks for
highlighting problems with your system.
• Management: Compare the actual time spent on the project with
your predicted times. Have your learned anything that will help you
make better predictions next time?
• Lessons learnt: Here you should list the things you have learnt
from doing the project.
• Final comments: If there is anything that you really want to get off
your chest about the way you did the project that would be valuable
for other students, you should put them into this section.
Finally, on a separate set of pages you should include the following:
• Bibliography: You should list the books and papers which you used
to help you develop your system. These should not be the standard
textbooks and can include manuals, web sites and journal articles.
• Software used: List the software you used in developing your
system.
125

14. Software engineering: theory and application
Marking the project:
In marking the project the examiners will be looking explicitly for the
following main elements:
1. The completeness and correctness of the report (around 50 per cent of
the marks). In particular, they will ensure that you have chosen a
relevant process, that you have followed your outlined process well
with requirements being captured, design undertaken, the design
elaborated, a user manual being written, a small amount of relevant
programming stubs being produced which reflect the design, and that
relevant and appropriate testing was undertaken. A project which is
problematic can gain some marks for correctness by reflecting on the
problems in the final report.
2. The coherence and structure of the report (around 30 per cent of the
marks). Examiners will give marks on how coherent the development
paradigm and process are, how well they are followed, and that the
project holds together as a complete system. For example, marks will
be lost if the data structures in the coding stubs are not related to the
initial designs, ER diagrams or Class diagrams.
3. Sophistication (around 20 per cent). Examiners will award some
marks for how sophisticated the project is – this is not simply in terms
of how complex the problem addressed is, but also how sophisticated
the process is, how well the techniques are applied and how well the
document is written and presented.
126