Updated: 11/12/2016

Overview: Sitemap


Accordingly to Mark Scheme

  • An attractive and informative home page, to introduce the project, the team, and highlight specific features.
    Can be found following this link.

  • A logical structure, with each of the sections listed below contained in their own set of pages, accessed via a menu from the home page and other pages.
    By default.

  • Background and context. What is the system to be designed is meant to do and in what context. Include the initial problem statement, information about the client and the specific challenges to be met. State what is needed for the project to be a success.
    Can be found following this link.

  • The detailed project requirements and scope that have been identified and agreed with the client. A clear and well-defined set of requirements should be presented, including use cases as appropriate. Include user interface requirements (as relevant to your project).
    Can be found following this, this and this link.

  • Results of the research done. What were your sources, what did you find out, what conclusions or decisions did you reach?
    Can be found following this link.

  • A description of each relevant prototype built or experiment done. What was discovered, how did it contribute? The use of photos, diagrams and videos is encouraged here.
    Can be found following this and this link.

  • The development of the user interface as applicable to your project. Describe the proposed UI features using your HCI knowledge. Justify why it is suitable and why it meets your usability requirements.
    Can be found following this link.

  • A link to the project version control repository, which all team members must use and must use it properly. This means updating very regularly, keeping the repository organised and not checking in broken code. The repository should contain all the source code artefacts and documentation.
    Can be found following this link.

  • Initial strategies for how to test your system, to demonstrate that it is functional and meets the requirements. Look at unit, functional and acceptance testing tools. Testing should be automated as much as possible (i.e., done by a computer). Manual testing alone is not acceptable.
    Can be found following this link.

  • A record of the progress of your project, including meeting minutes and copies of the bi-weekly reports.
    Can be found following this link.

  • Plans for developing the final PoC design during term 2.
    Can be found following this link.

  • What are the potential platforms, operating systems, operational environments needed. The platform is the hardware or environment needed to run support the PoC.
    Can be found following this link.
  • What did you look at? Compare the alternatives.
  • What did you choose and why? What examples did you find?
  • What are the trade-offs?.

  • What are the potential programming languages, libraries and other software components identified.
    Can be found following this link.
  • What choices were there and what are their strengths and weaknesses?
  • What did you choose and why?

  • A description of the tool chain needed to build, setup and configure the platform, OS, settings and application.
    Can be found following this link.
  • Again, identify and compare the choices.
  • For example, configuration scripts, build process, version control and deployment process.
  • The goal is to automate as much as possible to avoid having to build or configure manually every time something changes. Also to manage all the source code and other artefacts efficiently.

  • Critical discussion on what you have identified as the required performance and operational capabilities for the system.
    Can be found following this link.
  • How can they be achieved?
  • Why is your PoC fit for purpose? Provide the evidence.

  • Progress made in constructing your PoC Design prototype(s) by discussing the experiment phases.
    Can be found following this link.
  • Using the experiment log data you build weekly, describe what you have created so far, showing the design and other features. Especially note when things change.
    Can be found following this link.
  • Use appropriate language, notation (e.g., UML) and terminology to describe the design.
    Can be found following this link.
  • Justification of choices and trade-offs, especially for use of design patterns to refactor, optimise and integrate your solution phases.
  • Can be found following this link.
  • How you are configuring your OS, what packages are included or removed.
    Can be found following this link.
  • Discussion on the build and integration processes.
  • Scripts or other processes for configuring and launching the OS and application.
  • The layers identified (e.g., hardware, OS, library/framework, application) and how they communicate with each other.
    Can be found following this link.
  • The public APIs that your platform and/or OS make available to allow the application to be written.
  • Identification of what has been adapted from the open source community and what is to be newly developed or configured.

  • Your research, what you investigated, why it is relevant, what did you discover.
    Can be found following this link.

  • How is the work good Computer Science?
    Can be found following this link.

  • Testing Strategy.
    Can be found following this link.
  • Investigation of relevant available testing tools and methods.
  • Comparison of alternatives.
  • How automation can be achieved.
  • Results of experiments on the experimental phases and PoC prototype(s).