Project Handbook


 

Department of Computing, Engineering and

Technology

September 2015

 

 

 

1. INTRODUCTION

2. MODULE DESCRIPTOR

3. OPERATION OF THE MODULE

3.1 Project Selection/Allocation

3.2 Definitive Brief

3.3 Project Tutorials

3.4 Project Supervision

3.5 Documentation - the ePortfolio system

3.5.1 Your Journal/Learning Logs

3.6 Reviews

3.7 Project Report

3.8 Project Demonstration

3.9 Project Viva

3.10 General Information

4. ASSESSMENT

4.1 Areas of Assessment

4.2 Method of Assessment

4.3 Assessment Grades

5 REPORT

5.1 Structure and Layout

5.2 Writing Style

5.3 Submission

 

1. INTRODUCTION

The aim of this module handbook is to help you understand the operation of the final year project (CET300) taken by all degree programmes within the Computing academic area of the Department of Computing, Engineering and Technology.

The project provides a framework for you to demonstrate the skills and knowledge that you have acquired throughout the course of your degree programme. This is achieved through independent work through which you will:

• formulate a problem statement,

• explain the context of the problem, and

• communicate a proposed solution to the problem (and undergo ethics approval if this is deemed necessary to progress the proposed solution)  conduct in-depth research, after which you will:

• design, implement and evaluate a substantial software artefact (or several smaller artefacts) appropriate to your programme of study, and

• present your body of work in a formal written dissertation.

The handbook provides information and advice on a number of important aspects of the project, in terms of:

• what is required of you,

• what you can expect from the module, and

• how it is operated and administered throughout the year.

Although the module requires you to plan and organise your own time spent on the project, it is formally timetabled throughout the year for individual supervision meetings and for key sessions which everyone must attend. These sessions cover, for example, how to formulate your problem statement; advice on research and writing the dissertation; and technical lectures or surgeries.

It is unlikely that the handbook will provide answers to all possible questions, and it is therefore vital that you attend regular supervision sessions (details in Section 3). This will enable the module leader and project supervisors to keep a check on your progress and provide advice on problems, which may arise during the project. You will also create and maintain a project eportfolio as you work through the module and this will enable the module leader and supervisor (who will have access to it) to monitor your progress and advise you throughout. The module leader should be advised of any organisational problems as soon as possible. In addition, regular briefings and updates will be provided through SunSpace.

2. MODULE DESCRIPTOR

TITLE:

PROJECT

CODE:

CET300

CREDITS:

40

LEVEL:

3

DEPARTMENT:

COMPUTING, ENGINEERING AND TECHNOLOGY

MODULE BOARD:

LEVEL 3

PRE-REQUISITES:

All Level 1 core modules plus 80 core credits at level 2

CO-REQUISITES:

NONE

LEARNING HOURS:

400 the nature of which is specified in the module guide

LEARNING OUTCOMES

Upon successful completion of this module, students will have demonstrated

(a) in depth knowledge and critical understanding of a research topic and its relevance and application to the subject area of the project and the ability to

(b) plan, schedule and control an individual project and critically appraise their performance

(c) formulate a problem statement, explaining the context of the problem, and communicate a proposed solution to it that appropriately considers and addresses the social, ethical, professional and legal issues associated with the solution and its context of use

(d) design, implement and evaluate a substantial software artefact/several smaller artefacts that is/are appropriate to their particular programme of study

(e) collect, organize and present the body of work, including critical evaluation and correct citation and reference of appropriate research sources

 

CONTENT SYNOPSIS

Students must undertake advanced study in order to define, research and develop to completion a substantial piece of individual work that demonstrates the range of skills acquired on their programme of study. Either using their own idea or a bank of department proposed ideas incorporating tutor sponsored, and industry and community sponsored projects, the students are required to write an initial proposal document. Following consultation with relevant tutors, they will submit a definitive brief of the project to an approval panel comprising key staff from each programme team (incorporating a learning contract, and an agreed set of final outcomes). This is assessed, and where change is required feedback will be given to students in order to meet the learning outcomes. The students’ work will be monitored by regular supervision sessions which will also incorporate an assessed project review in which the research paper must be submitted. There will also be a series of workshops and presentations on study skills for project students. The module will be supported by the university’s VLE, and there will be a number of on-line learning supported tutorials.

 

TEACHING AND LEARNING METHODS:

The module teaching and learning strategy will be a combination of: self study, supervision sessions which will be run by teams of staff from the relevant programmes and which will incorporate the review at the half way point, workshops and lectures delivered by the module leader and supervision team, and surgery sessions in which staff with specific subject knowledge will be available for advice or minitutorials.

(a) Lectures

 

24 hours

(b) Supervision

 

6 hours

(c) Tutorial workshops

 

12 hours

(d) Surgeries

 

8 hours

(e) Self Study

 

350 hours

ASSESSMENT METHODS

(i) Definitive Brief

10%

Learning outcomes(c)

(ii) Review and Conduct of Project

10%

Learning outcomes (a)(b)

(iii) Report

35%

Learning outcomes (a)(b)(c)(d)(e)

(iv) Artefact(s)

35%

Learning outcomes (a)(c)(d)

(v) Presentation and Viva

10%

Learning outcomes (a)(b)(c)(d)(e)

Assessment methods (c) and (d) must be passed at 35%, with an overall pass mark of 40%.

 

INDICATIVE READING LIST

Please refer to MyModule Resources (MMR)

PROGRAMMES USING THIS MODULE AS CORE:

BA Business Computing

BSc Computing

BSc Computer Forensics

BSc Computer Science

BSc Games Software Development

BSc Information Communication Technology

BSc Network Computing

Franchised: NO

 

MODULE LEADER

Siobhan Devlin This email address is being protected from spambots. You need JavaScript enabled to view it.

Supplementary Information

 

Module : Project

 

AMPLIFIED CONTENT

Topics covered in the module workshops/lectures will be: formulating a project proposal and placing it in the broader context; project planning; literature searching and review; writing style and conventions; correct use of citation and reference; compiling a dissertation; oral and written communication; assessment of projects. Subject-specific surgery sessions will be held by relevant staff at various points during the year.

READING LIST

 

Please refer to MyModule Resources (MMR)

Due to the fact that the project will be taken by students from a number of different programmes, additional relevant articles from current literature, and associated resources, will be identified at the time of delivery by programme teams.

SPECIALISED RESOURCE REQUIREMENTS

Standard CET computing facilities.

3. OPERATION OF THE MODULE

3.1 Project Selection/Allocation

Deciding on an idea for your final year project can be quite a difficult task since you will be looking for something that is both interesting and challenging. Moreover, the project you choose needs to be relevant to your particular programme of study. (This does not mean, however, that the project’s subject area needs to exactly match that of your degree programme title: as long as you have covered modules on your programme that are relevant to the project, and the project will allow you to meet your programme learning outcomes, you should be able to choose the project that most interests and is most suitable for you.)

A list of project titles will be available from the Module Leader. Information about these projects will be given out during the Project Forum and a list will be posted on the module space in SunSpace. Any student who is interested in these projects should contact the Module Leader to gather more information about the project. If after finding out more information you are interested in taking up one of the ideas - and the project idea is relevant to your programme of study - then you should notify the project sponsor and the Module Leader. Projects are awarded somewhat on a’ first come first served’ basis, but importantly also according to your suitability for the project. Where there is more than one person interested in a particular project the Module Leader will select one student.

The projects are sourced from:

• external links with business, industry and the community, and from

• research groups in the Department of Computing, Engineering and Technology.

This ensures that your projects are both relevant to real world problems, and academically rigorous. You may also find your own sponsorship for your final year project – if you choose to do this however the project must be approved by the Module Leader as being appropriate to your subject area and of a suitable level of challenge. Here are a few ideas of how you might find a project:

• from your placement company: it may be an extension of your original placement work, or a new project, or work for a different part of the same company

• from a local company – for example an SME (Small - Medium Sized Enterprise) who does not have IT expertise.

If you have a project idea that is your own, you still need to find a sponsor who is willing to act in that role to allow you to develop and demonstrate negotiation and liaison skills in that respect. The module leader can help you to find an appropriate person.

Once an idea for a project has been established, your first task will be to draft an initial proposal document which incorporates the main aims and objectives of the project. During the project forum you will have an opportunity to discuss your ideas with a member of the supervision team. Supervisors will offer advice and guidance with regard to the initial proposal document and may suggest small modifications, this will be to ensure that the project is achievable within the scope of the module and also, that the objectives are of a suitable standard for an Honours Degree.

Your initial project proposal should be signed off (approved) by the end of week 2. You must have Module Leader approval to start the project. The Module Leader will keep the signed copies in the project room. Once your proposal is signed off you should start scoping and scheduling your project with the help of your supervisor, and begin the task of surveying the literature and developing your definitive brief.

3.2 Definitive Brief

The Definitive Brief is submitted around week 6 of the project and should clearly describe your main aims and objectives in terms of explaining the context of the problem, and a proposed solution to it. In explaining the context of the problem, you will clearly have had to make progress on the research element of your project. In addition to providing key references as background to the work, you will need to write a research overview, which demonstrates understanding of the purpose of the research and how it fits with your proposed development. Any initial knowledge gathering, design documentation (e.g. DFDs, storyboards etc) or development that you might have done by the time of the Definitive Brief hand in may also be included in the document.

The definitive brief also forms a ‘learning contract’ that details the major tasks to be undertaken and identifies any constraints there might be placed on the project. Hardware and Software to be used during the development will be stated here. You must draw up a schedule of work that lists all of the tasks required to complete the project along with their associated time allocation. The total time allocated for the project is 400 hours and this must be reflected in your schedule. A sample and framework for the definitive brief can be found in SunSpace.

3.3 Project Tutorials

Every two weeks, when you don’t have a supervision session with your supervisor, you have a group tutorial with the module leader. This enables you to get some practical experience and advice about the topics that are covered at that time. It also gives you an opportunity to work through exercises targeting certain sections of the dissertation, using exemplars from previous students.

3.4 Project Supervision

On the alternate weeks to tutorials, you must attend project supervision with your individual supervisor who is allocated from within the team of supervisors. This person is allocated to you because of their subject expertise/specialist knowledge and experience, and will ensure consistency of advice during your project. They will be your primary marker once you submit your finished work. Usually, but not always, this person is your programme leader. A second member of the supervisory team will be your second marker.

You are expected to attend the supervision slot shown on your timetable to meet with your supervisor. Although you will primarily meet with your allocated supervisor, there may be times when you also wish to see other staff in the department for additional advice.

Your initial supervision meetings will be to discuss your project ideas and proposal and to help you define realistic targets, and the supervisory staff will try to make sure that this is done, by checking your initial proposal and guiding you in the development of your definitive brief. Once the definitive brief is submitted in week six your primary concern is to complete a draft literature review in an appropriate topic and your supervision sessions at this point will be focused in that area, as well as generally keeping you on schedule.

3.5 Documentation - the ePortfolio system

An eportfolio is a digital tool and platform that allows a learner to easily customise and present readily accessible content. It enables the learner to curate specific and evolving collections of artefacts that demonstrate knowledge, skills and self-awareness appropriate to a particular purpose and audience, including themselves.

In the process of doing your project you will use the university’s eportfolio system (Mahara) in order to:

• present your project progress both for your own benefit and for your supervisor to be able to monitor your progress; and also

• demonstrate the knowledge, skills and self-awareness that you are developing (you will use it as a presentation platform for final project assessment).

Hence, the eportfolio is what you need to show your supervisor every time you meet. They will be able to see what you have planned to work on, what you have actually managed to work on, evidence for this, and reflection on your progress by means of a journal or learning log that you keep. When you create your project eportfolio at the start of the year you will need to share it with both the module leader and your project supervisor. Towards the end of the year when you know who your allocated second marker is, you will also share your pages with this person.

There will be guidance sessions on developing the eportfolio as you work through the year, and you will work to a template so that each supervisor can find things quickly and easily in each students’ pages. As you must evidence what you are doing on your project it is expected that among the documentation stored in your eportfolio is:

• Initial Proposal

• Definitive Brief: including Schedule, Gantt charts etc.

• Regularly kept journal/learning log, including date, time, place and duration of activities

• Research literature, reference list and working notes

• Interview notes and correspondence with sponsor/end users

• Drafts of chapters as you write them up (which should be throughout the project, not just at the end!)

• Any deliverables, such as design diagrams, storyboards etc.as you go along

• Supervision records - which will be typed in-session and uploaded into your eportfolio. (If you fail to attend a supervision session your supervisor will still look at your work and comment on it.)

3.5.1 Your Journal/Learning Logs

You are required to keep a weekly journal/learning log for the duration of the project and to have it uploaded in your eportfolio each week when you attend the supervision session. This will make it easy for you to demonstrate quickly and clearly to the supervisor what you have done in between supervisions. You must document in the log what you have done on the project but in addition you might also want to document all of your academic study each week. The decision is yours. The following paragraphs explain in more depth the purpose and value of keeping a learning log.

A learning log is a written commentary on your course of study. By writing things down you make clear – and so understand better - the learning processes you go through and develop during your time as a student. Normally you would write things down frequently – perhaps every day – noting the date each time. Importantly, the learning log is not just a record of what you do. It also contains discoveries you make – about your work or about yourself and your own practices – and so is also a reflection on the week's activity.

How does a learning log help with learning?

Keeping a learning log and re-reading it, comparing your performance over time, helps you to self-reflect and understand the things you do well and thereby make changes to how you operate when you come up against problems. Sometimes just writing down your thoughts helps you to make more sense of them. Learning logs can help you to ‘integrate’ your learning, for example you may suddenly realise that understanding in one module leads you to understanding in another, or that one way of learning in one topic is useful to adopt in another. In the workplace, many employers encourage the use of ‘quality management techniques’ to continually improve the quality of their work. In exactly the same way as learning logs, these methods require that records are kept, and that employees use these records (logs) to reflect on what went right or wrong, in order to work out how to improve quality in the future.

What does a learning log look like?

A learning log may be a notebook, folder of collected pages, or electronic document in an eportfolio (as it is in this project). In the log you:

List o what work you have done, and o how long you spent on it.

Explain

o how you did it o why you did it, o what you think about what you’ve done or found out/learned,

Highlight

o any questions, difficulties, initial conclusions you might have at that point to follow up later.

Write in whatever style suits you, as these notes are for your own use when you reflect on them later on. So, you may say “I did this because…” and “I think that this means…” rather than using more formal academic language like “It was decided that….” etc.

An example learning log template is given in the appendixes.

3.5.1 Your Journal/Learning Logs

Apart from bringing the learning log to each supervision to demonstrate to your supervisor what you have been doing, you can also use it to help improve your own academic performance. Write in your log regularly: every day that you do some coursework, if possible. Then, at the end of each week – or every 2-3 weeks at most - look over your notes on your own, and think about the learning processes you have gone through. Be critical of yourself. Consider:

 

Did something go well? If so  What did you learn from it?

• How can you build upon it?

Did something go badly? If so

• What went wrong?

• How can you fix it, overcome difficulties, and improve upon it?

Have you discovered/understood something new/important to your subject? If so

• What is it?

• What implications does it have on the rest of the subject - what new questions does it raise? Have your ideas changed? If so

• Why?

• Can you now synthesise different ideas and topics?

• What might this mean?

The project module makes use of review points during the year – if you have kept a weekly log it is very easy for you to demonstrate control over the work and to get good marks for this component. (The journal is time stamped so we can see that you have recorded and reflected on your progress as it happens.

At the end of the project you will also write an honest, reflective account of your performance during the year: final reports that read as if everything went to plan from start to finish are not generally true to life. You will encounter problems, struggle with them, and finally overcome them. Learning logs should reveal this process. They will also help you write up the dissertation as you go along, and stop you from having to try to remember everything right at the end. Importantly, the journal facility in the eportfolio allows you to tag your entries. This will mean that when you reflect at the end of the year you can for example search on anything you wrote about ‘scoping’, or anything you wrote about ‘client interaction’. This ought to make for a very thorough write up at the end.

(This section has been compiled with acknowledgements to Jenny Moon (multiple sources).

3.6 Reviews

The purpose of the review is to assess your progress to date and provide you with feed back on how well we think you are controlling your project. There are two key review points during the course of the module: submission of the definitive brief around week 6, and the review and conduct of the project which requires you to submit your research review chapter in week 12 and have a face to face review with 2 of the supervisory team immediately after the Christmas break. The exact dates of these events are given in the year planner in SunSpace. In the case of face to face reviews, each will take approximately 15 minutes, and will be held within normal supervision sessions.

Submission of Definitive Brief: The definitive brief should consist of: A statement of the problem; details of the sponsor; a three page contextualisation of the problem in terms of the agreed research topic, complete with a reference list of sources consulted; a list of objectives, constraints and resources; schedule and Gantt Chart.

Submission of Research Review: You are expected to submit your completed research review at this point. Although the research is expected to be complete, you will receive feedback on it so that you can make suggested improvements before the final project hand in. You must also submit your system designs, and any development work that you might have completed at that point. Control documents will be scrutinised at this review and you must make account of your attendance and your progress.

You will receive written feedback from each of these review points – together with a mark, as each is worth 10% of the final project mark.

If during the project, as a result of factors outside of your control, or as a result of the review of your definitive brief it becomes clear that the project objectives need to change, then written agreement from your individual supervisor and the Module Leader must be obtained. No changes should be made after the first review point.

3.7 Project Report

Details of the style and contents for the report are given in Section 5.

Two copies of the report must be submitted, one of which is returned to you after the viva.

Late submission of the report without valid reason will be penalised.

On submission, a disk containing the artefact produced must accompany each copy of the report, unless the nature of the development deems this inappropriate/not possible. This copy of the software will be used for the demonstration. Students are advised to keep their own copy in case problems are encountered with the disks that have been submitted. Your artefact should also reside in your eportfolio if this is possible and you should have a screen capture demonstration of it working in the eportfolio, for use at your presentation and viva.

 

3.8 Project Demonstration

Your developed artefact must be demonstrated to both your project supervisor and second marker. The demonstration should last around 15 minutes, in which time you will demonstrate the features of the system and your markers will ask you question about its operation.

3.9 Viva

The viva provides an opportunity for you to demonstrate in a formal setting, your knowledge and understanding of the subject area of your project. The duration of the viva is approximately 25 minutes, starting with you giving a formal presentation (lasting 10 minutes) from your eportfolio to the viva panel, followed by questions from the panel. The viva panel will normally consist of your two markers, and on some occasions an external examiner may also be present.

You should prepare for the viva after handing in the final report. A small number of slides that summarise the aims and achievements of the project may be required - your module leader will clarify after the handin what the precise nature of your presentation using the eportfolio will look like.

Students who fail to turn up for a scheduled viva (which is a formal exam) without valid reasons will be failed in the viva. A non submission of any part of the project module will, as with any module, mean you cannot pass the module overall.

 

 

3.10 General Information

 

Software

There is a wide range of software available on the terraces for use by all students. A full upto-date list is available through the Technical Support Manager in the DGIC. Enquiries about software availability and licences should be directed to the Technical Support Manager via the help desk on the terraces.

You should be aware of what is available and understand that requests for 'special' software packages cannot be met. If a project is being developed for an external sponsor in a software environment not available within the department, then it is up to the sponsor to either provide a copy of the software for use by you, or allow you to develop the software on-site.

Project Room

Final year students have exclusive use of DG218 as a project room all year. (It can be used for all modules, not just projects.)

 

Technical Support

Technical support for students whilst working on their project on the terraces is available through the normal channel, that is the Help Desk. Whilst the technical support team have a vast amount of knowledge and experience in working with a range of software packages, their role is to assist with the smooth running of the hardware and software. They are not a ‘private tutoring’ service, nor should they be expected to know about every feature for every piece of software currently on the terraces.

Getting to grips with a new software package is all part of the challenge of the final year project. Use the support team considerately and they will be more than happy to help you with your software/hardware problems.

Staff Availability

Supervisors in the project team are specially chosen for their subject area knowledge and expertise in supervising projects of this nature. Every programme area will be represented and supported by programme/subject related staff. In addition, staff with particular expertise will be invited to provide specialised workshops and surgeries. You may also on occasion be directed towards another member of staff within the department who is not timetabled for project students. If this is so, you need to make an appointment to see them in the usual way.

Contact with your Sponsor

You should agree with the project sponsor the mode of communication to be used during the course of the project (for example visits, email, fax, and telephone). It is important that this is clear from the onset of the project to ensure that both the student’s and the sponsor’s time is used to good effect. You should plan your meetings well in advance and they should be appropriate in terms of the development methodology you are following - for example whether you are using a sequential or an agile approach, the number and nature of the meetings you will need will be different .

At the start of the project you should ask the sponsor if they are willing to evaluate the final artefact. A copy of the final evaluation signed by the sponsor must be included in the report. During the assessment of the project the markers will be using this feedback from the sponsor to measure to some extent the success of the system. For advice on the type of sponsor feedback and evaluation expected in the final report, speak to your supervisor during the normal supervision sessions.

Intellectual Property Rights (IPR)

The University of Sunderland Terms of Student Projects with External Clients includes the following statements regarding confidentiality and Intellectual Property Rights:

Our projects are undertaken as part of an educational programme and are examined by supervisors and examiners appointed by the University of Sunderland. All supervisors and examiners are bound contractually and in common law to keep confidential any confidential information disclosed to them in the supervision and examination of the projects.

For the benefit of our project partners, the intellectual property rights arising from the work undertaken and/or the deliverables produced rest with the host company, save that the University and the students retain the right to use details of the work undertaken and the results to write up and submit for examination any coursework (or similar) in connection with the project and the educational programme and that copyright in any such coursework (or similar) will be owned by the relevant student and/or the University. However, any intellectual property rights in existence prior to the project and used in the project will remain the property of the party who introduced it.

Carrying out your Research

The research component for the project makes a significant contribution in the final assessment mark. Up until this point in your degree studies, you may have had limited exposure to research. This is nothing to worry about as there will be support on the module for the development of research and writing skills, by means of targeted lectures, workshops and surgeries, and through online materials in SunSpace. In addition, the university produces study skills materials which will be of use in your research and write up. These can be accessed through the university’s portal and on SunSpace. If you are going to be working with children or vulnerable adults in your project, it is important that you speak with the module leader about whether or not you may need police clearance (DBS), and/or ethical approval from the university. In most cases these are not necessary, but you must check. There will be ethics sessions during the running of the project.

Notices

Any notice relating to the final year project will be displayed in SunSpace. You are encouraged to check this on a regular basis.

 

 

4. ASSESSMENT

4.1 Areas of Assessment

There are five components that make up the final grade for the project. These components are:

• Definitive Brief

• Review and Conduct of Project

• Report

Artefact(s)

• Presentation and Viva

Definitive Brief

Worth 10% of the total mark, the definitive brief requires you to formulate a problem statement, explain the context of the problem, and communicate a proposed solution to it. You will be expected to have made a considerable start on the research element of your project by the time you submit this. A three page contextualisation of the system within the research area forms part of the brief. In addition, a detailed plan of action and schedule is required. Examples are provided in SunSpace. You will get the opportunity to look at and review each other’s Definitive Briefs, and to make amendments to your own before submission for marking by the project team. That way you should ensure a good mark for this first element in your project.

Review and Conduct of Project

You should demonstrate the ability, motivation, resolution and skills in managing your project. In particular you should demonstrate the ability to: plan, schedule and control your work; make effective use of appropriate project management and control tools; ensure deadlines are met and deliverables achieved; regularly attend supervision meetings. The two review points are the submission of the definitive brief (term 1) and the submission of the research review (term 2). This part of the assessment is worth 10% of the total mark.

 

 

Report (Dissertation)

The report is worth 35% of the total project mark. It is your opportunity to present your whole body of work in one coherent academic document. The report should be well written and demonstrate clear and logical progression: introduction and background; contextualisation in the research area; analysis and design; development and testing; evaluation and conclusion. Through the written report you should be able to demonstrate: the ability to identify a subject area which, through research, has enhanced your understanding of the subject; how this acquired knowledge has been used in the development of the system; and how you have reviewed and critically evaluated the research literature within the report. In addition you should demonstrate a systematic approach to requirements acquisition/analysis and system development and testing, and the ability to evaluate the conduct of the project.

 

Artefact(s)

The artefact is also worth 35% of the total project mark. You will be assessed in terms of how well you have: understood and been able to communicate your problem statement and your solution to it; integrated the research into the development; designed, developed and evaluated a substantial functioning system/artefact, the complexity of which goes beyond that of previously studied modules. In addition, the extent to which the practical deliverable(s) achieves the objectives stated in the agreed definitive brief is examined.

 

Presentation and Viva

The purpose of the presentation and viva is to allow you to demonstrate your general command of your body of work and your specific command of the subject area of the project. The format and content of the presentation along with the use of visual aids are assessed. You are also assessed on the way in which you present yourself and your body of work, and importantly, your answering of questions. Together the presentation and viva are worth 10%.

4.2 Method of Assessment

The table below shows those involved in assessing the various components of the project. A mark is given to each component, by each marker and then a final moderated mark is awarded.

 

Project

Review

Panel

Project

Superviso

r

Second Marker

External Examiner

Definitive Brief

X

   

X

Review and Conduct of Project

 

X

X

X

Report

 

X

X

X

Artefact(s)

 

X

X

X

Presentation and Viva

 

X

X

X

 

4.3 Assessment Grades

Grades are given as a percentage for each part of the assessment.

Over 70% First class - all round strength, and evidence of original thought

60 - 69% Upper second - generally a strong performance

50 - 59% Lower second - some strong performance points

40 - 49% Third - adequate

35 - 39% Fail - below standard for this course, but not without some worth

0 - 34% Fail - Unacceptable

Each component has a different contribution to the overall mark. The weighting for each component is as follows:

• Definitive Brief 10%

• Review and Conduct of Project 10%

• Report 35%

• Artefact(s) 35%

• Presentation and Viva 10%

Assessment Criteria

An full assessment criteria guide covering each of the components, which make up the final project mark will be given out in the winter term.

 

5 REPORT

The project report has a very important role in giving the markers a clear picture of the extent and quality of the work you have undertaken. It may be the first evidence that the second marker has of your work as s/he may not have encountered you in the supervision sessions. Therefore, it must give a very complete, clear, logical and chronological account of events during your project.

The following are the key points, which can be used to help you understand how to put together a high quality project. Failure to conform will lose you marks! As mentioned earlier in the handbook, specific lectures, tutorials and surgeries will be given during the project to help you develop your report writing skills. SunSpace materials are also available to support your learning. In particular, several project tutorials will systematically work through how to write your dissertation, with the help of previous student work as exemplars.

5.1 Structure and Layout

Binding

Two copies of the report need to be produced. One should be bound in blue, and the University will retain this one, while the second must be bound in green. The green copy will be returned to you. (The Print Centre will print and bind dissertations or you can take your own print out for them to bind. They are based on the Tech Park next to the Murray Library on Chester Road Campus. They may only have the green/blue card for the back cover in which case they will provide a plastic front cover on each copy.) See section 5.3.

 

Layout & Margins

The final report must be word processed, double-spaced or line and a half spaced on A4 size paper. The font size should ideally be size 11 point. It should be no smaller than 10 point and no larger than 12 point.

The left hand margin should be 3cm to allow for the spiral binding. The right margin should be about 2cm and the top and bottom margins about 2.5cm.

A good quality printer should be used. It is not necessary to use a colour printer the whole way through the dissertation although it may be a good idea to do so on some of your diagrams/screen shots.

All pages should be numbered sequentially from the first page of the first chapter (not the abstract or table of contents), and page numbers should appear at the bottom centre of the page.

Do not put a border around your pages.

Length

The body of the report (that is EXCLUDING the Appendices) should between 60 and 80 pages. The whole report (including appendices) should not be over 130 pages in length and must be bound in a single volume. This is a guideline – you should speak with your supervisor/module leader if you have a problem adhering to it.

The main body (chapters) should be line and a half spaced and only printed on one side of the paper, but the appendices may be single line spaced and printed on both sides if you are trying to save space.

Title Page

The report must have a title page laid out according to the format prescribed in SunSpace.

Abstract

A one page abstract, single-spaced, should be the first printed page after the title, and should summarise the project. The abstract is NOT an introduction - it is a SYNOPSIS of the entire document and must cover every aspect of it. A tutorial towards the end of the module will take you through how to write an abstract.

Table of Contents

A table of contents should be the next page, showing each of the main chapter headings and their appropriate page numbers. Sub-headings can also be shown, no more than three levels of sub-heading e.g.

1. Introduction

1.1 Background to the Project

1.1.1 The Sponsor Company

Etc….

Main Body

The main body of the report should follow the general model outlined below:

Chapter 1: Introduction

Chapter 2: Literature Review (use your actual title)

Chapter 3: Requirements Analysis/Knowledge Elicitation Chapter 4: Design

Chapter 5: Development and Testing

Chapter 6: Evaluation

Chapter 7: Conclusions and Recommendations for Further Work

References

Appendices

Note this is a general model only; because of the diverse nature of the projects, some deviation from this model can be expected. However, it should be used as a starting point in planning the report. Do not print your references at the end of chapter 2. They should be positioned at the end of the final chapter. They should not have a chapter number, because they are not a chapter.

Figures and Diagrams

Figures and diagrams should be used wherever possible to illustrate key points in the project. Hand-drawn figures should generally not be used (this will depend on the nature of the project – for example hand drawn storyboards would be acceptable). Figures should be included in the text at the most appropriate point to support an argument, and not kept to the end of chapters or the main body. All figures should have a caption, in bold italics, centred underneath the figure, and should be sequentially numbered throughout the report, according to which chapter they feature in e.g. the 2nd figure in chapter 3 would have the number 3.2., like so:

 

Figure 3.2. ER Model for the System

 

References

Wherever possible, references should be used to support your research and development work. There are several different standardised forms of citing references, but the Harvard system is the one which you must use in the final year project. Full details on bibliographical references can be found in SunSpace. In addition, some of the project lectures/workshops focused on citation and referencing – so check these lecture notes/handouts carefully. Here is an example of the Harvard system for citing references in text.

Give the author's name and year of publication, in either of the forms shown below:

a In a recent paper, Devlin (1996) suggested that...

 

b A recent study (Devlin 1996) argued that...

For publications by two authors, both names are given:

In a recent study (Devlin and Hopkins 1996) it was argued that...

Two or more publications by one author in the same year are distinguished by adding lowercase letters to the year, thus:

Devlin (1995a) disagreed, and in a later study (Devlin 1995b) suggested that....

If you wish to refer to individual pages of a particular book or article, the page number(s) should be given after the date, separated from it by a colon:

(Devlin and Hopkins 1996: 236).

The list of references should name ALL authors, and show the title of the book/paper/article, and all relevant information such as volume number, page number(s), conference or book title, publisher, ISBN number. Incomplete references are to be discouraged. Details of how to set out references at the end of your report is given in the handouts in SunSpace and in the project lectures/workshops.

Appendices

The appendices should include all relevant material, which is not appropriate for inclusion in the main body text. This should include (but is not limited to) the following:

A. Diagram of Programme Route

B. Ethics Documentation

C. Control Documentation: Definitive Brief, Schedule/Gantt Chart, Learning Logs, Supervision Records; Records of client interaction

D. Analysis Documentation

E. Design documentation

F. Development documentation (no code printout - that goes on disk)

G. Testing Documentation. Actual test results (as opposed to summaries or analyses of the results, which should go in the main body, evaluation chapter)

H. Evaluation Documentation. Questionnaires/user feedback forms

I. Disk with copy of the software (if appropriate)

J. User guide (if appropriate)

Appendices should be sequentially ordered by LETTER (not number) - e.g. Appendix A, B, C etc. They should also appear in a logical and chronological sequence, mirroring the sequence of the dissertation chapters.

5.2 Writing Style

Tense

The dissertation should be written in the past tense, passive voice, and third person.

This means that you should refer to work that WAS done (not is being done or will be done); and that you should refer to work that was done, decisions that were made e.g. “it was decided that an agile approach should be taken” rather than “I decided to use an agile approach”.

For example:

“I considered....” should be written as “It was considered that.....”

“I decided to....” should be written as “The decision was taken to....”

“I will do some tests....” should be written as “Tests were carried out....”

However, it is likely that in the introduction and discussion of results/recommendations for future work, some mix of tense may be required and this is acceptable.

For further clarification of writing style, students are directed towards the numerous texts on scientific writing in the Library.

Drafting and Correction

Draft chapters or sections should be produced at the regular supervision sessions, when your supervisor can give feedback both on the content of the report and the writing style. In particular, you are required to submit your research at the second review point.

Plagiarism

Plagiarism is “the deliberate and substantial unacknowledged insertion in student’s work of material derived from the work, published or unpublished, of another”.

Students are expected to observe “scholarly conventions”. Make it completely clear which are your own words, and which are the words of someone else. Use suitable annotation, quotations marks, and references (see section on references above). If you are not copying directly, but basing your words substantially on someone else’s, then you must still acknowledge that person. Any infringement by plagiarism will be dealt with according to the University Policy on Cheating, Collusion and Plagiarism.

 

5.3 Submission

Typing and Binding

You are responsible for production of the dissertation, including typing and binding. TWO COPIES of the project must be produced which are spiral bound. The University Print

Centre will bind reports for student projects, but will charge for the service. DO NOT LEAVE IT UNTIL THE LAST MINUTE to contact them - they are very busy! Two copies of the report need to be produced. One should be bound in blue, and the University will retain this one, while the second must be bound in green. The green copy will be returned to you. (The Print Centre will print and bind dissertations or you can take your own print out for them to bind. They are based on the Tech Park next to the Murray Library on Chester Road Campus. They may only have the green/blue card for the back cover in which case they will provide a plastic front cover on each copy.)

Submission

The two copies of the project must be submitted to Assignment Services, Prospect Library, St Peter’s Campus. The University Policy on late submission without valid reason is to deem the student to have failed in the assessment.

Common reasons given by students for late submission are:

• Computer viruses

• Corrupt disks

• Hardware failures

• Access to printers

• Binder not delivering as promised  Traffic problems getting in to University

• etc. etc. etc.

Excuses such as these, when given on submission day, reflect poor planning - you should allow yourself some leeway in submission, and should ensure you have backup copies of the dissertation and other deliverables. Ensure that the binder is given plenty of time, and allow for traffic jams! None of these excuses is likely to gain you any sympathy with the module leader, markers, or module board.

Queries relating to this module handbook should be addressed to the Module Leader, Dr Siobhan Devlin, email: This email address is being protected from spambots. You need JavaScript enabled to view it.

 

Appendix A: Indicative Learning Log Template

 

Name:

Programme:

Date:

Description

1. This week I worked on:

2. Time Spent on above work:

Reflection

3. Explain how you did the work listed in section 1:

4. Explain why you worked in the manner described above:

5. Think about and write down what you have found out/learned from your actions this week:

Carry Forward

6. Highlight any questions, problems, tentative conclusions to follow up on next week or later.