Mark Dixon 1 Tech – 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 4 th 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: –1 st 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 Sommerville I (2001) Software Engineering (6 th Edition). Addison-Wesley. ISBN X