ABC Interactive HET 402 Week 13 - 09/11/2009

ABC Interactive HET 402 Week 13 - 09/11/2009

Preparing final documentation and presentation.

Aleks has done a really good job the website so far.
He's now finishing off the collaborative art piece.


Charlie finishing off all research analysis.
I'm working on accountability.

Reevaluation of final submission:



HET402

Group Confirmation email

• Functional / Content Specification (only if starting a
new project, with subject convenor approval);

• Quality Assurance Review/Usabilit y Testing Plan.

• Project Definition – expanded from

Final Documentation – stage 2:

• Quality Assurance Review/Usabilit y Testing Report
– expanded from the QA Review / Usability Testing
Plan submitted earlier in the semester.

Technical Specification & Handover Instructions.
Resubmit Project Definition, Functional / Content
Specification. (see note below)

• Individual Contribution Summary.

Note:The original Project Definition and Functional /
Content Specification documents for HET401 must be
resubmitted for HET402 with a brief addenda for any
changes.





Documentation Assessment Weightings:

The documentation component of HET401 / HET402 is given a single mark. This mark is based on how well each of the documents are judged to address the criteria (elements) listed in the
documentation guides.

Project Proposal Document
(due week 9 so is ready for pitch)

Minimum of 1 proposal required
(loading of 5% available if submit 2nd proposal)
20% = 15% for “best” attempt + up to 5% loading for submitting 2nd proposal.

Final document Part 1
(due in exam period)
Functional Specification (or equivalent
= eg content specification / storyboard) 15%
Final document Part 2 Project Definition document – one only
required - (updated from project
proposal document) 5%
Total Documentation mark 40%


1.3 Overall document quality – structure and appearance. The documentation required for the project is expected to be of a professional standard. In each major document (except the Project Outline / Brief) the following should be included prominently and early in the document:

1.3.1 Cover information. The front cover of each document submitted must contain the following
information:

• Contractor’s logo (i.e. group logo) and / or client logo [optional].

• Document Title / Name in large font so that individual documents can be readil y identified, and any graphic / design elements the group feel will enhance the professional appearance of the documents.

• Elements contained in the document (e.g. if submitting Project Definition and Functional Specification in a single volume, this should be indicated on the cover). Also indicate whether a CD or other media is inserted into the document (make sure any such media are well secured in the document).

• Document number / total number of documents submitted (e.g. if the document is submitted in 3 separate volumes, they should be labeled document 1 of 3, document 2 of 3 and document 3 of 3 respectively).

The following footer information, is also required on the front page of every separate document. (this would not normally be necessary for “commercial” documents):

• Group name (as allocated by subject convener)
• Name and ID of each group member.

• Supervisor’s name

1.3.2 Important information about the document. The following information should be included earl y in the document, usuall y the first page inside the front cover:

• purpose of document;

• the intended “audience” or "readership" for the document (e.g. "Marketing Dept. or other non-technical personnel"; or "IT Dept. and Programmers familiar with PHP coding");

• how this document relates to other documents that need to be read in conjunction with this document (include date, version number where appropriate);

• Document Revision History – Major business documents normall y contain a Document
Revision History at the beginning. This section describes the evolution of the document through its drafting and version stages. Documents are often changed and updated as a project proceeds, so “version control” and Document Revision History ensures that the client can be aware which version of a document they are reading, and its background. Details provided would normall y include the version numbers, dates changes were made, which sections or document elements were altered, and the author and/or person responsible for the changes. This is usuall y in table format, before the table of contents.

For example, the Document Revision History (table) at the beginning of the Project Definition should identify clearl y those elements or sections of the Project Definition that have been expanded from the Project Proposal or changed in later revisions (and by which group member.

• Executive Summary This is recommended for any important project document, especiall y when you are trying to win work from a new client. It should be concise, (1 page maximum) while still covering all of the key issues (think about what these would be for a senior company executive). It may be the only page that is read by some busy key stakeholders, so make sure all bases are covered here (don't overlook any major issues that are contained in the body of the document. All of the important elements listed in the table of contents should ideall y be addressed (at least briefly) in the executive summary.