Mark Dixon 1

Tech04004 – Final Report

Mark Dixon 2

Aims & Objectives• Give guidance on:

– Project Report– Demonstration

Mark Dixon 3

Final Report: Why?• “I’m interested in writing code,

why do I need to do this?”

• Selling– Need to describe software to potential customer

• Management– Need to judge what to fund, ensure completion.

• Learning– Describe technology used – was it any good?

Mark Dixon 4

Assessment 3: Final Report• Deadline 4th May• Electronic submission (Progress Report Document)

– 4000 words maximum (excluding Appendices)– Must Describe

• Title Page: Title, Student Number (not name), Module Code, Date of Submission• Background: Application domain (subject area), why is it needed – what problem(s) will it solve?)

Aims and objectives: what will it do overview (for the end user)• Method: Techniques and Technology used (with rationale)• Analysis: Describe problem domain.• Design:

– Functionality– User-Interface (screen shots)– Data: database schema, ERD– Code: Modules, Classes, Pages, etc. (architecture, overall structure)

• Implementation: Describe 1 or 2 key pieces of code.• Testing

– Verification – Does software meet specification?– Validation – Does software meet user requirements (empirical testing)?

• Conclusions– Compare actual progress with plan (7 / 8 items complete)– Reasons for differences (no emotion, no blame)– Describe adjustments– Review – what have you learnt

• References• Appendix A: Functional Specification• Appendix B: User-Interface Design• Appendix C: Data Design• Appendix D: Test Plan• Appendix E: Full Code

Mark Dixon 5

Functional Specification• Lists what the software will do (not how).

– Used as to-do list by developers– Used as contract with users– Usually numbered + hierarchical, and presented

as:• List, or• Table

• Examples:– Tech043 assignment brief,– Sommerville 2001 p.99

Mark Dixon 6

Database Design• Lists tables and fields within tables

(datatype and purpose)

• Samples:– Tech043 assignment brief

Mark Dixon 7

Test Plan• Formal (written) Protocol (Procedure) to

ensure consistent testing:– Usually table:

• User action• Computer response• Comments

Sommerville 2001, Ch. 20

Mark Dixon 8

Conclusions• Compare Actual Progress with Plan

– How many facilities were completed (out of how many)?

– Explain the differences?• Issues: Planning (Over / under estimation – lack of

experience), Personal (no need to describe), Technical, Workload

• How were difficulties tackled / solved?• What have you learned?

– you next time / advise others• Technology, methods

• Describe Future Work

Mark Dixon 9

Belief vs. Knowledge• Evidence

– Put evidence in same sentence as point

‘This project has been successful’.

‘Most facilities have been provided as planned (14 out of 16 as show in the functional specification on page 19)’.

Could still be a lie – that’s what the demo is for

Mark Dixon 10

References• Harvard system (recommended)

– Author and year, e.g. (Jones 2008)

• Vancouver system– Numbered as the appear in text, e.g. [1]

• Reliability of source:– Google Scholar: scientific papers

Mark Dixon 11

3 Writing Stages• Ideas (Brainstorming)

– Generate as many ideas as possible– Write down notes / phrases (not full sentences)– Write down everything that comes to mind– Don’t delete anything

• Structure– Decide what to keep and what to remove– Rearrange into a logical order– Merge / remove repetition

• Finishing– Expand notes / phrases into grammatical

sentences (including other people)

Mark Dixon 12

Writing Style• Formal, avoid:

– 1st Person (i.e. use of I and me)

– slang– underlines (makes

words harder to read)

• Grammatical

• Succinct

• Clarity

Seely 1998

Mark Dixon 13

References• Seely J (1998) The Oxford Guide to Writing

and Speaking. Oxford University Press. ISBN 0-19-863144-8

• Sommerville I (2001) Software Engineering (6th Edition). Addison-Wesley.ISBN 0-201-39815-X