Guidelines

for the
DT211-3 Projects Module
(PROJ3501)

September 2007

Project Co-ordinator: Damian Bourke

Room: K 115A
Phone: 01 402 2844
E-mail: [email protected]
 Table of Contents
1 INTRODUCTION..............................................................................................................2
2 STAGES OF THE PROJECT...........................................................................................3
2.1 STAGE 1 - IDENTIFY A PROJECT TOPIC..............................................................................3
2.2 STAGE 2 - RESEARCH / ANALYSE THE PROJECT TOPIC.....................................................3
2.3 STAGE 3 - DESIGN A SOLUTION FOR THE PROJECT............................................................5
2.4 STAGE 4 - IMPLEMENT THE SOLUTION..............................................................................5
2.5 STAGE 5 - TESTING AND EVALUATION..............................................................................5
3 PROJECT DELIVERABLES...........................................................................................6
3.1 PROJECT PROPOSAL...........................................................................................................6
3.2 THE INTERIM REPORT.......................................................................................................6
3.3 THE PROJECT MANUAL.....................................................................................................6
3.4 THE PROJECT DEMONSTRATION........................................................................................7
3.5 ASSESSMENT OF WORK.....................................................................................................7
4 ROLES OF THE INDIVIDUALS INVOLVED..............................................................8
4.1 THE ROLE OF THE SUPERVISOR........................................................................................8
4.2 THE ROLE OF THE STUDENT.............................................................................................8
4.3 THE ROLE OF THE PROJECT CO-ORDINATOR....................................................................8
4.4 THE ROLE OF THE PROJECT MONITORS............................................................................8
4.5 THE ROLE OF THE SECOND READERS...............................................................................8
5 REFERENCING.................................................................................................................9
APPENDIX A............................................................................................................................10
A1 FORMAT OF THE PROJECT MANUAL.................................................................................10
A2 GUIDELINES ON THE STRUCTURE OF A CHAPTER ............................................................12
A3 SAMPLE TITLE PAGE .......................................................................................................13
1 Introduction
Every final year degree student is required to undertake a final year project. The purpose of
this project is to evaluate the student’s ability to undertake a significant piece of independent
work under the guidance of a Supervisor.

The aim of the project is to test the student’s ability to research, design, implement and
report on a software system that they have developed. Subject areas for projects can cover a
wide variety of areas. Examples of such areas are: the development of software tools, the
development of graphics based systems, the implementation of information systems of
sufficient complexity and scope etc. Even though these topics cover different areas, the work
involved can be sub-divided into the following five generic stages:
Stage 1: Identify a problem area (i.e. project topic) and main objectives of the project.
Stage 2: Research and/or analyse the project area to gain an understanding of the work
involved. At this stage the student should be able to articulate the proposed
solution, objectives and scope of the project.
Stage 3: Design a solution.
Stage 4: Implement the solution.
Stage 5: Testing and evaluation.

Each project has the following deliverables:

 The Interim report (at the end of Stage 3).
 System Software (Stages 4 and 5).
 The Project Manual (at the end of Stage 5). This incorporates the Interim Report and
documentation relating to work completed during the other stages of the project.

This document presents a set of guidelines developed within the School of Computing for
both staff and students involved in the final year degree projects.

Section 2 describes the stages of the project outlined above in more detail.

Section 3 outlines the project deliverables. It also briefly describes how work will be
assessed.

Section 4 describes the roles of the people involved in the project. In particular the role of
the student, the Supervisor, the Project Co-ordinator and Project Monitors are clearly
outlined.

Section 5 introduces the concepts of references, citations and plagiarism. This is extremely
important and should not be overlooked or taken lightly. There is also a link in this section to
another essential document which describes these concepts in more detail.
2 Stages of the Project
There are five distinct stages associated with the progression of the project as follows:

1.1 Stage 1 - Identify a project topic

Each student is expected to identify their own project topic. Ideas for projects can come from
a variety of places including an area where a student has a particular interest or where a
student has undertaken work outside or even from family and friends. There may also be
some project ideas put forward by members of the School of Computing lecturing staff. A
student who is interested in pursuing one of these projects should contact the staff member
involved. These projects are allocated at the lecturer’s discretion.

Students who have difficulty identifying a topic should communicate this to the Project Co-
ordinator or to a member of the School of Computing staff who will endeavour to assist the
student in this regard.

Having identified a possible project each student must complete Section A of the Project
Proposal Form with a brief description of their project idea and submit it to a member of the
School of Computing staff for discussion and approval. Once the staff member is satisfied
that the project is feasible and appropriate, they will sign the form. The student should then
submit the Project Proposal Form to the Project Co-ordinator.

It is the responsibility of the student to ensure that the form is submitted to the Project Co-
ordinator. Once the Project Proposal is accepted, the student will be allocated a Supervisor
and a Second Reader.

1.2 Stage 2 - Research / Analyse the project topic

During this stage the student is expected to research the project in order to fully understand
the domain of the project and any appropriate solutions.

One area to consider is the methodology to be used. There may be a variety of

methodologies to choose from depending on the project. The student should consult with
their Supervisor on choosing the most appropriate methodology. As a guide to possible
approaches to use for research, four categories of projects with appropriate research
methodologies are presented below.

i) Development of a Software Application

These projects involve the automation of an existing manual system, making an existing
computerised system more efficient or developing a new and innovative application. An
example would include developing a sales and purchasing system for an organisation. At the
heart of these projects is a data storage and retrieval component. The complexity and
standard of such applications should far exceed that expected for lab assignments undertaken
during the course.

The type of research appropriate for such projects would involve

 Carrying out an industry focussed feasibility study.
 Performing a systems analysis on any existing systems and for the final system. This may
involve the use of traditional analysis or object-oriented analysis approaches.
 Determining the requirements and objectives and scope of the application.
 Researching and choosing the most appropriate platform and technology for the
development and deployment of the final application.
 Outlining a proposed development strategy,

ii) Development of a Software Tool

These projects generally involve the implementation of a software tools on specific
platforms. Examples of such tools include: text editors, file viewers, web browsers and
client/server backup systems. The research approach for such projects would normally
involve:
 Researching the area for similar tools and solutions.
 Determining the user requirements for the software tool.
 Outlining the objectives and scope of the project.
 Determining the most appropriate platform and technology to be used both for
development and deployment of the software tool.
 Outlining the strategy to be employed for developing the software tool.

iii) Development of a Graphics based system

These projects involve developing graphics based applications (2D) such as a games
application e.g. Chess. The research for such projects would involve:
 Researching graphics programming concepts.
 Performing analysis to determine the requirements and scope of the project.
 Determining the most appropriate platform and technology to be used both for
development and deployment of the final system.
 Outlining the strategy to be employed for developing the Graphics System.

iv) Development of a Hybrid System (Systems Integration)

These projects involve the implementation of software applications across multiple platforms.
Examples would include an application implemented on a PDA or some other mobile device
communicating with a server. The research for such projects would typically involve:
 Researching the communications technologies and development tools appropriate to
each platform.
 Determining the user requirements for system.
 Outlining the objectives and scope of the project.
 Deciding on the most appropriate equipment and technology to be used for the
development and deployment of the Hybrid System. The use of “plug and play”
systems on their own will not be deemed appropriate.
 Outlining the strategy to be employed for developing the hybrid system.
 Defining a deployment strategy for installing and using the system.
Depending on the project, the use of systems analysis methods or techniques may be
appropriate.

1.3 Stage 3 - Design a solution for the project

At this stage the student should design a solution for the project. The design method used
will vary depending upon the project area but it should be presented in such a way that it is
clear to the reader how the project will be implemented. The tools that will be required to
implement the project should also be decided upon at this stage.

In general, the design task should produce documents detailing the following:
 The functionality of the proposed system.
 The structure and relationships between the entities/objects in the system.
 A user interface design. A user interface prototype may be appropriate at this stage
to validate the user interface with the users.
 A testing strategy detailing the criteria to be used for stage 5 (Testing and Evaluation)
of the project.

It will also be necessary at this stage to produce technical prototypes to demonstrate the
student’s grasp of the chosen technologies and the proposed solution.

1.4 Stage 4 - Implement the solution

This is the implementation stage of the project.

This implementation stage must contain a strong programming element and must follow to a
large extent the design developed in Stage 3. Some deviation from the initial design may be
acceptable provided it is authorised by the Supervisor and well documented.

It is important that the tools used in the implementation stage are appropriate for the task and
that they are used correctly. Rapid application development tools should be used only in
conjunction with substantial coding. Any exception to this will only be allowed under strict
circumstances in consultation with the Supervisor and Project Co-ordinator.

1.5 Stage 5 - Testing and evaluation

This stage involves two distinct processes, testing and evaluation. Testing is to check that
everything works, whereas evaluation is about the student’s perception of how well the
project went and how they perceived their own performance. These processes should be
separately identified in the Project Manual.

For projects that involve the implementation of software the testing phase is often the stage
that requires the most careful planning and organisation. Testing is central to any well-
developed system and is something that should not be left until the last moment. Testing
should be carried out as the product is being developed during the implementation stage. At
the end of this testing and evaluation stage, the student should be fully aware of the strengths
and weaknesses of their product.
In relation to the evaluation process the student discusses their own performance in relation to
the project. In particular the student should discuss:
 Whether the objectives of the project were satisfied, and if not, the reasons why.
 Any weaknesses in the project or weaknesses in how they approached the project.
The student should indicate how they would do things differently if they were
starting the project again.
 The successes of the project comparing it to other equivalent systems they may
have encountered during the course of the project.

The use of third party evaluation techniques such as Nielsen's Heuristics might form part of
this evaluation process.

It is important that the student has previously discussed and agreed a testing strategy with
their Supervisor during Stage 3 of the project and that these are included in the Project
Manual.

3 Project Deliverables
The key dates for the project deliverables are clearly set-out on the Project Co-ordinator’s
web page. Students must keep track of these dates as they may change during the project.
Late submissions will not be accepted.

1.6 Project Proposal

Ideas for projects can come from a student’s particular interest in an area, from outside work
undertaken by students, or many other sources. There will also be project topics suggested by
staff or external companies available on the Project Co-ordinator’s website. Students who
have difficulty identifying a topic should communicate this to the Project Co-ordinator or any
member of the School of Computing staff who will assist them in choosing an area.

Having identified a possible project each student must complete a Project Proposal Form
which should include a brief description of the project together with the aims and objectives
of the project. The student must then submit this form to a member of the School of
Computing staff for discussion and approval. Once the staff member is satisfied that the
project is feasible and appropriate, they will sign the form. The student should then submit
the Project Proposal Form to the Project Co-ordinator. It is the responsibility of the student
to ensure that the form is given to the Project Co-ordinator by the due date. Once the Project
Proposal is accepted, the student is allocated a Supervisor and a Second Reader.

1.7 The Interim Report

This deliverable includes all of the work produced as a result of Stages 1, 2 and 3. It
contributes to 15% of the final project mark. It is in the form of a written report submitted
to the Supervisor and Second Reader1. It is envisaged that the interim report will form a basis
for a number of chapters in the Project Manual.

1
Refer to the Project Coordinator’s web site for a list of the key milestone dates.
1.8 The Project Manual
The main deliverable from the project is the Project Manual. It tests the student’s ability to
clearly document the work involved in completing the project. Essentially it is the student’s
record of the work they have undertaken during the year and serves as a guide to how well
the student understands the project area.

Each project is assessed by a number of people including the Project Supervisor, Second
Reader, a Project Monitor and an external examiner. As the Supervisor meets with the
student most regularly throughout project it is imperative that the various stages of the
manual are presented to the Supervisor on a regular basis for his/her comment. The objective
is to ensure that the manual is as detailed and clear as possible for the benefit of the other
examiners.

As stated previously the Interim Report will form the basis of a number of chapters in the
Project Manual so it is important to ensure that this Interim Report is detailed and clear. It is
also advisable to continue to write-up the manual during the implementation stage. Do not
leave the write-up until the last few weeks of the project.

Refer to Appendix A for guidelines on the structure of the Project Manual.

1.9 The Project Demonstration

Towards the end of the project the student is required to make a Project Demonstration. This
will involve a short presentation (with appropriate slides) based on the project report and a
full demonstration of the final software/system. The Supervisor, Second Reader and Project
Monitors will attend the Project Demonstrations and will ask appropriate questions of the
student to test their knowledge and understanding. Guidelines for the Project Demonstration
will be provided at the appropriate time.

1.10 Assessment of Work

The final completed project is assessed under a number of categories as follows:
1. Presentation - The quality of the student’s Project Demonstration.
1. Project Report - The quality of the student’s deliverables and the Project Manual.
1. Research and Understanding - The extent of the student’s background research and
overall understanding of the project subject area.
1. Design Quality - The quality of the System Designs.
1. Software Quality - The quality of the final software/system.
1. Completeness and Complexity - Some projects are by nature technically more
complex than others. In such cases, these projects may not be required to be as
complete as others; this category reflects how complete a particular project is, with
respect to the complexity of the project.
1. Project Management - The conduct of the student during the project and in particular
their project management skills and dedication will be assessed.
1. Value and Usability - The value and the usability of the system designed and
implemented will be assessed.
The Interim Report will be assessed using a different set of criteria by the Supervisor and
Second Reader and an Interim Progress Report produced and submitted to the Project Co-
ordinator for inclusion in the final mark.

4 Roles of the Individuals Involved

1.11 The Role of the Supervisor
The role of the Supervisor is to advise the student through each stage of the project and to
assess the student’s work in consultation with other examiners. The Supervisor should meet
the student once a week at an agreed time that suits both Supervisor and student. It is
important to remember that the Supervisor is not there to do the work for the student but to
guide and assess the work as it is completed. The Supervisor also gives technical assistance
to the student as required. The Supervisor should encourage initiative in the student so that
the student learns to take responsibility for their own work and does not become overly
dependent upon the Supervisor.

At the start of the project, the Supervisor will assist the student in working out a time-scale
for the various stages of the project; this should be regularly updated as the project continues.
The Supervisor should continue to guide the student though each stage of the project and
should advise the student on any difficulties he/she may experience. The Supervisor should
also regularly update the student on their performance. If a Supervisor is worried about the
performance of a student, this should be communicated to the Project Co-ordinator so that
corrective action can be taken.

1.12 The Role of the Student

The project gives the student the opportunity to apply the skills they have acquired on the
course. The ultimate responsibility for the completion of the project lies with the student and
the project should be entirely the student’s own work. This means that students are expected
to develop strategies for completing their project and for addressing any problems that may
arise in their project. The student should consult with the Supervisor to develop their ideas
and should not depend upon the Supervisor to actively sort out problems. Project meetings
should consist of an exchange of views by student and Supervisor and should not just involve
the Supervisor telling the student what to do and how to do it.

Both the student and the Supervisor should engage with each other in a courteous,
considerate and professional manner. For instance if either party cannot attend a pre-
arranged meeting, this should be communicated to other party in advance.

1.13 The Role of the Project Co-ordinator

The role of the Project Co-ordinator is to oversee the management and administration of the
projects as a whole. Any queries or problems experienced by either staff or students should
be communicated to the Project Co-ordinator.

1.14 The Role of the Project Monitors

The role of Project Monitor is to ensure consistency in the marks allocated across all projects
by examiners. In order to achieve this, a Project Monitor attends each project demonstration.
1.15 The Role of the Second Readers
The role of the Second Reader is to act as a second internal examiner to a project.

5 Referencing
The Project Manual like any other scientific work will contain thoughts and ideas from other
peoples work or material. This is not unusual or wrong provided that appropriate credit is
given to the other person or people. This is achieved through the use of references and
citations.

A reference is information that allows the source of other peoples work or material to be
identified by the reader (in order that he/she can ‘follow’ the reference to the source).
References appear in the bibliography in a list form.

A citation is the short ‘tag’ that appears after a word, statement, or paragraph in the text of
the Project Manual. It indicates that the word, statement, or paragraph is based upon, or
derived from material from another source. The citation allows the reader to identify the
correct reference to use to track back to the original source.

Citations and referencing allows the reader to differentiate between the student’s own work
and that of others. Failure to correctly use citations and references may lead to accusations of
plagiarism; something which the Institute takes very seriously. If plagiarism is suspected, an
investigation will be instigated. If plagiarism is confirmed severe penalties may be applied
including (but not limited to) a student receiving zero marks for their project and/or a student
asked to repeat the module or ultimately it may lead to the student being expelled from the
Institute temporarily or permanently.

Consequently, careful consideration should be given to references and citations when

embarking upon writing the Project Manual. Refer to document titled “Referencing
Guidelines for DT211 Project Modules” from the main page.
Appendix A
A1 Format of the Project Manual (Return)

The Project Manual should not exceed 25,000 words excluding appendices and bibliography.
The Project Manual should be developed in consultation with the Supervisor and should
adhere to the following basic layout:

1. Introduction – This chapter provides a clear description of the aims and objectives of
the project. The case for the project should be argued. In addition it should introduce
the structure of the remainder of the Project Manual.

2. Chapters 2 to N-2 – The content and sequence of additional chapters will vary
depending upon the nature of the project and should be agreed with the Supervisor.
Generally, the second chapter will be a Research/Analysis Chapter which should
include sections on User/System Requirements, an analysis of similar
techniques/systems that have been developed and an analysis of the technologies
available at the very least. (Note that only information relevant to the project should
be included. An example of what not to include would be a chapter on the history of
the Java programming language just because Java is used for part of the
development). Other essential chapters include: a Design chapter detailing the design
of the proposed system, an Implementation chapter detailing how the system was
implemented and any issues encountered. Click here for more guidelines on the
structure of a chapter.

3. Chapter N-1, Results and Evaluation – This chapter is one of the most important
chapters in the Project Manual. It is mainly through this chapter that the student
demonstrates an ability to evaluate their own work. Here the student should discuss
whether the objectives of the project were satisfied, and if not, the reasons why. It is
good scientific practice to document any weaknesses associated with the project in an
objective and critical manner. Having identified the weaknesses the student should
also identify any future work that could be embarked upon to overcome them. The
successes of the project should also be discussed, comparing it to equivalent works.

4. Chapter N, Conclusions and Future Work – This chapter presents a summary of

what was achieved. It details the original objectives of the project, the results
(previous chapter), future work etc.

5. Bibliography – This should contain a list of references that were cited throughout the
Project Manual.

Appendices – This portion of the Project Manual should contain any supplementary material
that whilst not essential for the main body of the Project Manual, may provide extra
information for the reader. One appendix should contain a listing of the code developed with
appropriate comments and citations. Other appendices may include a brief explanation of
technologies, protocols or standards.
A2 Guidelines on the structure of a chapter (Return)

Each chapter should have a number, a title header and a number of sections (and optional
sub-sections). Each section/subsection should also have a number and a title header. The
chapter should begin with an introduction, a short paragraph that briefly describes the aim
and content of the chapter. The chapter should end with a conclusion paragraph that briefly
summarises the chapter and introduces the next chapter. The chapter and section headings
should use a consistent font style and size. The following is an example of a sample chapter
structure:

Chapter 3 – Design of System

3.1 Introduction
This chapter describes the design of the DIT Exam Processing
system. This design chapter is divided into two main sections.
The first section describes etc.

3.2 Overview of Design

Section content

3.3 Detailed Design

Section content

3.4 Conclusion
This chapter described the design of the DIT Exam processing
system. As has been seen in this chapter, the system will be
implemented as a client/server information system. The next
chapter describes the implementation of this system.
A3 Sample Title Page (Return)
The cover page of the manual should contain the following information:

Dublin Institute of Technology

Kevin Street
Dublin 8

School of Computing

Project Title

Student Name

2007 - 2008

Dissertation submitted in partial fulfilment of examination

requirements for a BSc in Computing (Ordinary)

I declare that all material contained within this dissertation is entirely

my own work unless otherwise stated.

Signed: ______________________

Supervisor: name