iTRAIN – A Technical Proposal-Assessment

iTRAIN – A Technical Proposal

Identification.

Central to the ethos of our college is our co-curricular programme, comprising sport and cultural events. The management of TRAINING teams for events is currently managed in a hap-hazard way using paper rolls and spreadsheets. The College wants to investigate ways we can use an online digital system to better record who turns up for training events. This could formally feed into the process of team member selection for individual games, rewarding training attendance. Additionally, reliable team membership data needs to be generated for inclusion on Semester Reports.

STUDENTS in this system attend training events and, somehow, are marked present by an OFFICIAL. The system needs to automate much of the management and record keeping and present simple attendance analytics per team and member.

Interactions.

This system is to be facilitated by a normalised relational database and PHP interface, live to web. There are 3 VIEWS (or "personas") for this system. Participants are allocated levels – student, official or admin. Their view of the system necessarily changes with the access level granted.

Students can participate in this system (registered or not)
Students can see the training schedule and choose to attend a training event. For their attendance to count,

they must check-in with an OFFICIAL or their delegate. The system tallies these attendances live.
A student can choose to REGISTER, then they will be able to see their DASHBOARD which lists past attendances.

Officials (coaches or nominated delegate) are registered in the system by an administrator and are chosen because they can attend events and (hopefully) know something about the activity. They should be able to easily collect student check-ins for a training event. A student should only be able to check-in once for each training event. Officials would use their mobile phone (or Internet connected Laptop and bar code reader) to complete the data collection from a participant’s student card (barcode or student number).

Administrators add events. Additionally, they register organisers into the system and can see summaries of event attendance. If necessary, they can manage stored user data.

Component Specifications:

Student developers will be supplied with a sample CSV file of students details from TASS (our student management system) that includes snumber, full name, email address and house information. They will use the student's email address to send a confirmation email to verify their account on registration. This data can also be used to personalise the interface. In addition, developers have access to a bar code reader in class to test their check-in solution live.

• Students are able to choose to register and then log in.
• Students, when logged in, should be able to see details of those training events they have checked-in to.
• Officials need to be able to log in and select the training event they are accepting check-ins for.
• Officials should be able to see who attended – names and tallies for their training event.
• Administrators need to be able to manually add/remove an official - this should generate a notification to
  the official.
• Administrators need a summary of each training event (tallied) and an end of the semester summaries
  Boundaries and Limitations
  • The system will employ SECURITY of passwords – either hashing or encryption – personal data is personal so you must ensure only authorised personnel can see personal data
  • User-proofing is important – filter ALL text input, ensure you handle/store only sanitised data
  • "Rorting" the system should be prevented – only individuals can register their presence (ie. students cannot check-in for a mate). Similarly, organisers are accountable for the events they are allocated to accept check- ins for.

Your response must include:

• A3 pages that

demonstrate all phases of the problem-solving process

communicate knowledge and understanding by way of annotated sketches, diagrams, images or screenshots

• A4 pages of code with annotations explaining analysis, synthesis and evaluation decisions related to the code element or problem

Detail to include on A4 and A3 page response

To complete this task, you must:

•  recognise and describe

–  programmed and user-interface components

–  useability principles, including accessibility, effectiveness, safety, utility and learnability

•  symbolise

–  the user and developer problem using mind maps and one or more of constructed sketches, annotated diagrams, images or screenshots

–  algorithms communicated in pseudocode that demonstrate knowledge and understanding of programming features

–  interrelationships between user experiences and data in the prototype web application

•  explain

–  internal and external data components and data structures using appropriate symbols, code, data samples and screenshots from the prototype web application with annotations

–  the prototype web application from a user-experience perspective communicated by way of a collection of annotated images of the user interface components

–  how programming elements and user-interface components connect, communicated in an annotated diagram

–  the functionality, useability and efficiency of the coded components communicated through code comments and annotations on the 4–6 A4 pages

•  analyse the prototype web application problem and information to identify
•  analyse the prototype web application problem and information to identify

–  data inputs

–  data and programmed components and their relationships to the structure of the prototype web application

–  the prototype web application’s potential personal, social and economic impacts

•  determine

–  solution requirements that include

essential elements and features of the user interface based on useability principles

data structures and linkage to interface and code

–  prescribed and self-determined criteria

•  synthesise ideas and information about solutions for

–  user interfaces

–  data and programmed components of the prototype web application, e.g. annotated diagrams identifying and describing proposed components of the prototype web application

–  data repositories

–  programming to generate a prototype web application

•  generate

–  sample code for the digital prototype on the 4–6 A4 pages, demonstrating

• selection
• iteration
• user input
• data output

–  a prototype web application by combining the user interface, data and coded components

•  evaluate against criteria

–  personal, social and economic impacts supported by a collection of data samples or representations

–  accuracy and efficiency of the coded components supported by a collection of annotated code segments in tables, diagrams and written paragraphs identifying errors and actions to make refinements

–  the prototype web application from a user-experience perspective supported by a collection of annotated images of the user-interface components

•  make refinements and justified recommendations for current and future improvements.