Diploma in Software

Engineering
Final Year Project Guidelines

UDM, DEC 2013

Contents
1.0 Overview .......................................................................................................... 3
2.0 General Requirements for the Final Year Project Documentation.................... 3
3.0 The User Guide ............................................................................................... 5
4.0 Guidelines for the Student ............................................................................... 6
5.0 Guidelines for the Supervisor ........................................................................... 7
6.0 Assessment ...................................................................................................... 7
Appendix A ............................................................................................................ 9
Appendix B........................................................................................................... 10
Appendix C ........................................................................................................... 11
Appendix D .......................................................................................................... 12

2|Page

1.0 Overview
The purpose of the project is to perform a complete analysis and design of a chosen system
ending up with a completely tested and operational software system performing the tasks as
specified in the requirements.

2.0 General Requirements for the Final Year Project Documentation

The project must follow a standard format and must contain the following elements in order:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

Title Page
Declaration Form
Abstract
Acknowledgements
Table of Contents
Introduction
Main Body
Conclusion
References
Appendices (optional)

Please refer to APPENDIX A for further details on documentation formatting guidelines.

2.1 Title Page
A sample Title Page is shown in APPENDIX B.
2.2 Declaration Form
A sample Declaration Form is shown in APPENDIX C.
2.3 Abstract
The abstract should provide a short overview of your project that enables a reader to decide if
your report is of interest to them or not. It should be concise, to the point and interesting.
Avoid jargon or acronyms as the reader may not be familiar with them. An abstract usually
contains a brief description of:
the project and its context;
how the project work was carried out;
the major findings or results.
2.4 Acknowledgements
2.5 Table of contents
2.6 Introduction/Background Study
The contents of this chapter depend on the nature of your project. In a development project, you
may describe the domain in which you are working and the technologies and programming tools
you are using.
3|Page

The following should be covered in this chapter:

Present the problem under investigation. The problem statement defines current
problems/issues in the system.
Indicate the aims and objectives of the project. The objectives of the project must reflect
with the problem statement defined earlier. The objectives must be clear, measurable and
achievable.
Define the scope of the project. This section describes the boundaries of the project, i.e.
what aspects of the system will be covered in the project.
Software and Hardware requirements.
Limitations - discussion of constraints under which the project has to be completed.
Indicate a timeline for the project e.g. use of Gantt chart.
Indicate the distribution of tasks - If you are working in a group, a detailed breakdown of
tasks that were undertaken by each team member and a record of how much time was
spent on each should be included in the documentation.

2.7 Main body

2.7.1 Analysis
This section documents the analysis of the system to be implemented. It consists of the
following:
Feasibility study.
Functional and Non-Functional requirements.
Alternative ways of solving the problem.
Proposed solutions with reasons.
Evaluations of tools pros and cons.
Choice of final tool/s with justification.
Detailed description of the system.
Context diagram.
Functional modeling of the system by the use of Data Flow Diagram.
2.7.2 Design
The design section documents the design decisions that have been taken. The structure of the
system and its components need to be established.
Structure Chart.
Entity Relationship Diagrams / Class Diagrams.
Process Design/Description of UML diagrams / Use Case Diagrams.
Database design.
Data dictionary.
Menu design.
Screen/Form design.
Report Design.
Security Design.

4|Page

2.7.3 Implementation
The implementation section describes how the different components of the project have been
implemented. It should consist of:
Development tools and environment used.
Implementation of different modules.
Sample codes including standards and conventions.
2.7.4 Testing
This section will document the testing carried out the test data and the results obtained. When
independent modules have been implemented and tested, they can be integrated and tested as a
whole. Different types of testing carried out:
Unit test testing a single component.
Integration testing combining different components.
System testing testing the system as whole.
User acceptance test user perspective of the system to check if requirements have been
met.
2.7.5 Any other applicable issues
2.7.7 Conclusion
This last chapter in the report consists of three main parts:
Achievements it should critically assess the work done including the strengths and
weaknesses and explain the results obtained.
Difficulties faced in the project can also be summarised.
Future enhancements If future work is carried out, it can be indicated what other
domain would have been explored without the current time/resource constraints.
2.7.8 Bibliography
2.7.9 Appendices
Note: Fragments of source codes can be used and explained as and when required in the
project report but avoid having print outs of ALL the source codes used.

3.0 The User Guide

The User Guide must contain sufficient information so that one can use the software easily.
You should remember that this document is intended for end-users and must include very
few technical terms or details. A b r i e f guideline of its contents is as follows:
a)
Introduction.
b)
Table of contents;
c)
Overview;
d)
List of errors which may occur and how to handle them;
e)
Detailed description of how to use each screen or dialog box;
f)
Description of each operation/option in the menu;
g)
Glossary (if any)
5|Page

4.0 Guidelines for the Student

The Final Year Project is meant to showcase a students skills and knowledge acquired during
their study. It is a unique opportunity to carry out independent research and lay a foundation for
future study or a career. In case of difficulties of any kind, the student should inform the
supervisor or coordinator as soon as possible.
4.1 Important Guidelines

You may use portions of lawfully acquired copyrighted work in your project, with
proper credit and citations, giving full bibliographic information when available.
ALSO: MAKE SURE YOU KEEP A BACK UP COPY OF YOUR PROJECT. Nonsubmission due to computer crashes, corrupt files etc is not an excuse for late
submission.

4.2 Supervision meetings with the supervisor

Students are advised to benefit from the supervisors guidance by scheduling weekly meetings.
The student will record the main points of each meeting in a progress report form, summarise
them and submit to the supervisor immediately following the meeting. This strategy will help
both sides to track the progress and identify any difficulties.
Each group should come up with a complete analysis and design of the chosen system and
finally the system should be completely tested and operational. Moreover, the system
should perform exactly the tasks as specified in the requirements. The group will not be
allowed to change the project specifications after submission of the project title and synopsis.
However, if need be, the requirements of the project can be subject to changes prior to full
consent of the project supervisor.
4.3 Progress Report Book
Progress reports should be recorded on a regular basis. A sample Progress Report Form is given
in APPENDIX D. The report should be updated whenever the student meets his/her supervisor.
The progress report should address the following issues:

When did the meeting take place?

What was the purpose of the meeting?
What progress was made since the meeting?
What suggestions were made by the supervisor?
Is acceptable progress being made by the student?
What tasks are to be done by the student until the next meeting?
Every entry made in the Progress Report MUST be signed by the supervisor.

Important Note: No project will be accepted for marking without the progress report book.

6|Page

4.4 Plagiarism
A project must be the students own work and must not contain any plagiarised material. Use of
plagiarised material will be strictly penalised. Furthermore, it is important that students adhere
to the standard conventions for the referencing of other peoples work.

5.0 Guidelines for the Supervisor

The supervisor must be accessible so that students can discuss problems with them.
Project supervisors will guide and monitor the work of the students.
The supervisor will keep a record of the progress of the student in the Progress
Report Book. This book will be taken into consideration when marking the
project. It is thus important that the student work regularly on the project.
The supervisor will provide guidance only and will not write codes, debug
programs or correct grammatical errors in the students report. Note that the final
version of the project report is the result of the students own work and the
responsibility for the work submitted lies entirely on the student and not on the
supervisor.

6.0 Assessment
6.1 Submission of interim reports
The development of the project is divided into different phases so that individual
implementations can be evaluated as they are being completed. At the end of each phase,
students will be required to submit interim reports to their respective supervisors. Also, late
submissions or failure to submit interim reports will be penalised.
You will be required to submit interim reports as detailed below:

7|Page

Project phases

Deadline

Background study/Initial investigation

Week 2(26 Jan 30 Jan 2015)

Analysis & Design (Interim Report)

Week 5(16 Feb 20 Feb 2015)

Coding & Testing

Week 9(16 Mar 20 Mar 2015)

Final documentation (Final Report)

Monday 27 April 2015

Panel Presentation

To be confirmed later

6.2 Project Submission

The final project must be submitted on Monday 27 April 2015 2015 by 14.00 hrs at latest to,
Mrs A Soopramanien (Departmental Secretary). It should consist of
The Progress Report Book.
Two printed copies of the Project Report.
Two printed copies of the User Guide.
One DVD containing all source code and a soft copy of the Project Report and User
Guide.
6.3 Assessment and Marking Scheme
An assessment panel shall be set up for the main assessment tasks. The assessment will be
performed as follows:
1. Introduction
The scope of the project shall be introduced to the panel through the team leader.
2. Demonstration of the system
In this part of the presentation each member will be requested to demonstrate that part of
the project he/she has been working on. Each member should adhere and present strictly
that part of the project that he/she has worked on. This session will be interactive with
questions from the members of the panel.
The software will be assessed on some of the following criteria:

Layout/HCI, user-friendliness, validation and error handling, coding, functionality,

navigation features, Database connectivity, security, Report/query facilities, presentation
skills and any extra features.

8|Page

Appendix A
General Formatting guidelines for documentation
The student must abide by the following formatting standards during the preparation of his/her
project:
Length of the project
The length of the project report must be between 5000 and 8000 words, excluding the appendix.
Paper
White A4 paper of good quality should be used. Only one side of the paper should be printed.
Fonts
The font to be used should be 12 point using Times New Roman. Exceptions may be made for:
(i)
(ii)

section headings and subheadings which may be as much as four points larger that
the font size used for the text;
computer code (or pseudocode) which should be 10 or 12 point courier font.

Line Spacing
Use one and a half line spacing both within and between paragraphs.
Margins
Every page of the report must use the following margins:

1.5 inches on the left of the page for binding purposes

1 inch on the right of the page
1.25 inches on the top and bottom of the page.

Page Numbering
Page numbers must be shown at the bottom of each page.
Sequence of Pages
The title page bears Roman numeral i, but is not printed.
The Abstract bears Roman numeral ii.
The Acknowledgements bears Roman numeral iii.
The Table of Contents bears Roman numeral iv.
From the Introduction to the Appendices (if any), use Arabic numeral starting with 1.
References
When referring to another persons ideas or direct words in the text of the reports, the student
must acknowledge that persons contribution in two places: in the body of the report at the point
where the idea or words (in-text referencing) is used and at the end of the report under the
heading References (end-text referencing). The Harvard Referencing Style is recommended.

9|Page

Appendix B
Sample Title Page

UNIVERSITE DES MASCAREIGNES

MedCare Health Centre

Computerisation of the Patient and Appointment System

GEORGE W. BLAIR

Project submitted to the Department of Information Technology in partial fulfillment of

the requirements for the award of the Diploma in Information Systems with specialization
in Software Development

SUPERVISOR: Mr x

14 JUNE 2012

10 | P a g e

UNIVERSITE DES MASCAREIGNES

Department of Software Engineering
Appendix C
Project Declaration Form
NAME OF STUDENT/S

STUDENTID

COURSE

TITLE OF PROJECT

NAME OF SUPERVISOR

Declaration
I/We declare that every part of this project work is my/our own unaided work and does not
contain unreferenced material from any other source.
I understand that violation of these conditions may result in a mark of zero being awarded for the
component or components of the project affected.

Signature

11 | P a g e

Date

UNIVERSITE DES MASCAREIGNES

Department of Software Engineering
Appendix D

Project Progress Report

PROJECT TITLE
DATE OF MEETING

-------------------------------------------------------------------------------------NAME OF
--------------------------- SUPERVISOR
----------------------------------

STUDENT DETAILS
Team Leader:

Team Member:

---------------------------------

----------------------------------

TOPICS/THEMES DISCUSSED
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

TASKS ALLOCATED TO STUDENTS BY SUPERVISOR

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

COMMENTS(If any)
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------SUPERVISORS SIGNATURE
STUDENTS SIGNATURE
--------------------------------------------

12 | P a g e

----------------------

------------------------