CSCI 265 Project Phase 4: Proof of concept (and updates)
This phase can be regarded as the transition between design and implementation. It is far
lighter on documentation than previous phases, as it is expected the team will be dealing with
the technical hurdles of setting up the necessary tools/technology for your chosen language(s)
and platform(s), plus the coding challenges associated with getting a proof-of-concept working.
of your product.
Deliverables for phase 4 are divided into three key areas:
a project update and suitable revisions to earlier project documents (due by 8pm Friday November 1st)
writing and submitting a proof-of-concept document (also due by 8pm on the 1st)
providing the code for your proof-of-concept in the appropriate branch of your team repo
giving a 10-14 minute team presentation on key updates plus demo of your proof-of-concept
(to be done in your team's lab section, Oct. 30th or Nov. 1st)
*The individual contribution assessments are due 48 hours after the other documentation.
Marks breakdown [30 marks total]
Project update and matching revisions to the charter, standards, requirements, and design documents (plus appropriate matching changes to the repo content) [10 marks]
Proof of concept document+code [15 marks]
Presentation [5 marks]
Project update and document revisions
A formal project update should be provided in an update.md file, outlining
key changes in project requirements since phase 3
key changes in the team charter since phase 3
key changes in the standards and processes since phase 3
key changes in the design since phase 3
All changes noted should, of course, be reflected in the other relevant project markdown document(s)
and team repo files/structure where appropriate.
The proof-of-concept document
The intent in this phase is for the team to demonstrate to themselves and the client (instructor)
that the project design is feasible, i.e. that the core functionality can be successfully
implemented by Dec. 6th following the current design.
To accomplish this, there are four key elements, each of which should be addressed in the
document:
Identifying the core technical challenges:
By this point in the design process, the team should be aware of (most of) the major
hurdles they will face in implementing their design.
This section of the document is intended to outline each of those challenges in sufficient detail
to explain the problem and why it is a key area of concern/focus.
Determining what is necessary to demonstrate each challenge can be met:
The goal of this phase is to convince the team and the client(instructor) that the core
of the product can be successfully implemented by the due date (Dec. 6th). In this section
the intent is to detail specifically how each of the challenges identified above will be
met. This might be by implementing a single program that shows all can be met, or by
creating a small set of programs demonstrating the challenges being met individually.
The documentation here should outline the code components that need to be created,
the accompanying assets that need to be created, and any servers/tools that need to be
set up/configured.
Producing the code and other assets to meet each challenge:
The team should decide (and document) where the proof of concept elements should reside.
It's possible (likely?) that you won't want the proof of concept code mixed in with the rest
of the 'real' project code, so the creation of a separate project branch or separate directory
in the repo are both possibilities.
The team should create the necessary code, setup/configure any tools/servers needed,
and create any assets needed to perform live demos of the proof of concept.
The proof of concept
document should clearly indicate where the associated code and other elements can be found
(typically their branch and location within the team github repository).
Where tools/servers need any significant setup or configuration, the necessary
steps should be documented somewhere in the team repo and the location of that documentation
should be noted in the proof-of-concept document.
Assessing the results of the proof-of-concept and any implications:
The proof-of-concepts may or may not be entirely successful, and may actually reveal
new challenges the team had not previously been aware of (or had not recognized the
full importance of).
The precise structure of this section will likely vary from team to team,
but in it the team should assess:
how successful the proof of concept was,
which concerns it successfully addressed plus any it failed to address and why,
how the team plans to address any remaining concerns (e.g. changes to the
requirements and/or design, different approaches to the implementation, backup plans
if the concerns continue to be an implementation problem).
Sample documentation:
as with previous phases, sample documentation for phase 4 can be found
in the example project documentation.
The presentation
As with previous phases, each team will provide a 10-14 minute formal presentation
discussing their current deliverables.
This presentation should
begin with a summary of any major changes to the earlier product requirements, team charter,
standards/processes, and/or design,
outline the core technical challenges identified and the way the proof of concept
code/assets is meant to address them,
provide a short demo of the proof of concept in action
provide a short assessment of the proof of concept results and any implications
for the project
Assessment and marks
Be sure all team members have read the contributions assessment
page, and complete and submit their assessments by 8pm Sunday November 3rd (phase4.md in your
individual contribution repos).