= Puzzle Box Project Plan
include::share/meta.adoc[]

== Table of Contents
:toc:

== Introduction

This document has been written by students following the computer science
curriculum at Avans University of Applied Sciences in Den Bosch. The purpose of
this document is to plan out the puzzle box project, in which realistic goals
will be established. Key points of this document include the way this project
is going to be developed, the expected outcome, and project management.
Throughout the semester project, this approach ensures process control and
provides a clear overview of activities and the work organization.

== Background information

This section gives the reader background information as to why the project is
necessary.

=== Project

During the introductory week, students participate in a competition task on
Monday afternoon. The goal is for teams to perform tasks related to electrical
engineering and computer science programs. The competitive element and
interaction with other groups are crucial. For the 19-20 introduction, the bomb
task was created, inspired by the game "Keep Talking and Nobody Explodes." A
description of the game can be found on the website [1].

Originally, the plan was to create a bomb that needs to be defused and a puzzle
box generating codes for defusing the bomb. A previous group successfully
developed a bomb requiring software and hardware creation by intro students,
followed by entering defusing codes. This system includes an RPI connecting to
the internet for bomb countdown time synchronization and remote control.
Additionally, a configuration program for PCs allows the bomb to be set to
countdown at a specific time. The bomb's hardware is ready, but a puzzle box
could still be created.

This puzzle box would generate codes to be entered on the bomb for defusing.
The bomb's software can be expanded for collaboration with puzzle boxes or
other additional features. Several puzzles for the puzzle box were developed in
the 20-21 academic year and improved upon in 21-22. A design for the box's
appearance has been created, along with software and a web-based user interface
for accessing a mesh network set up by the boxes.

== Project definition

This section describes the different aspect of the project, including the
analysis of the project, the approach to completing the project, and the goal
of the project.

=== Problem analysis

Currently, the idea of defusing a bomb has been realized and is being used in
the introductory weeks at Avans. However, a puzzle box has yet to be realized. 

Several puzzles were already developed in the 20-21 academic year and improved
upon in the 21-22 academic year. A design for the box's appearance has been
created, along with the software and web-based user interface for accessing a
mesh network which is set up by the boxes.

The puzzle box hardware and software need to transition from prototype status
to a final product, including the integration with the bombs. The hardware is
not complete for all puzzles, as these have been redesigned in the 22-23
academic year.

=== Project approach

During this project, kanban is used, in which different tasks are described
that are actually in constant motion. The advantage of this is that it is
actually always clear who is working on which task and which tasks still need
to be done. This does require each project member to keep track of their tasks
on the kanban board, to ensure efficiency and discipline while the project is
ongoing. The tools to enforce this are shown in §7.3.

=== Project goal

The purpose and motivation of this project is to create a puzzle box that
interacts with the existing bomb, which can be used in the introductory week. 

The bomb would have to be defused using codes given by the puzzle box. The
puzzle box would consist of several puzzles for the student to solve. These
puzzles are related to the Smart Hardware and Smart Software study paths.

The focus of this year's run of the puzzle box project (23-24) is to create a
new software framework from scratch, that allows future students working on
this project to easily integrate new puzzle modules, or port the existing
puzzles to different hardware. Previous iterations of this project were
realized with complicated libraries and/or frameworks, which requires extensive
research for students unfamiliar with them.

=== Halfway goal

Due to this project being divided over two periods a halfway goal has been
established. This goal must be reached in week seven of the project. The first
half of this project focuses on researching and designing the final product. As
a result, several documents are created. The documents delivered in this phase
of the project are the following:

-	Project Plan (this document)
-	Requirements document
-	Research document (1st version)
-	Design document (top-level software design)

=== Project outcome

The outcome of the project is that the puzzle box software has been brought to
a product-level. Furthermore, a software framework has been implemented, which
uses only software and programming languages native to the curriculum. A
temporary cli-interface has been realized, allowing for management of the game
state.

=== Project deliverables

- Project Plan
- Requirements Specification
- Design Specification
- Site acceptance test
- Factory acceptance test
- Qualification Document
- Puzzle box games/interface
- Handover plan

=== Product quality

Multiple tests will be created to safeguard the quality of the project. Code
and document reviews are also used to safeguard quality. More about this can be
found in §6.2.

== Project phases

=== Research phase

This project consists of several research topics which are stated below.

Investigating the already existing code/software that has been written by
previous project members to determine if the code/software could be
reused/ported to another controller or software language.

Another vital research topic to explore is the unit testing framework. By
investigating different unit testing frameworks, project teams can identify the
most suitable one for their specific needs, enabling them to maintain code
quality, detect bugs early, and facilitate smoother integration processes. That
means that for this project a new, robust, and future proof unit testing
framework needs to be chosen since there is none now.

Lastly, researching the controller, there is already a controller picked for a
prototype version of the puzzle box for this project, but it is unclear which
controller it is and if it is still a good option to continue using since the
puzzle box itself uses a Raspberry Pi, but the puzzle box consists out of
several puzzle modules which each must have their own controller. The raspberry
Pi for the box itself should be fine but for now it is unclear what is used for
the modules and what is the best option to move forward.

A design document will be set-up in where the decisions will be made based on
the conclusion of the research document for the following components:

- Puzzle modules (four sides)
- Main controller
- Communiction (with the bomb)
- Power supply

=== Development phase

The development phase is used to develop a product, or a predetermined part of
the product based on the research done in the previous phase and agreements
made with the customer.

This project and thus this phase will be executed using the well-known
KANBAN-method to not only bring more structure and an overview of the product
development but also to make sure that everything is according to the plan and
the customer is satisfied. This means that there will be regularly meetings
with the customer to verify that the requirements are met as expected by the
customer.

The development will be done using Visual Studio Code in combination with
several add-ons, if necessary, together with GitHub (GIT) for version
management. GitHub will also be used to manage project related tasks so that
all the tasks and issues can be tracked.

The software will be created according to the tasks planned in GitHub projects.
Each piece of software needs to be tested using a testing framework. 

The development will exist out of five main tasks which are:

- Main controller
- Side 1
- Side 2
- Side 3
- Side 4

The main controller's development will take up the most time thus will be
executed parallel to the development of the four sides. The development of the
sides will also mostly be parallel with just a small delay creating an overlap
between the sides.

=== Qualification

The last phase is the phase where everything needs to be tested and verified to
the agreed upon specifications. This will also be done using the KANBAN-method
as discussed in the previous chapter.

Testing of the code will be done using a unit testing framework to test
individual components, later manual testing is needed to test the complete
system which will be documented in a FAT. The customer will also be able to
test and verify the results during this phase to make sure that everything was
executed according to the plan.

Lastly, a document needs to be made with a recap of everything of this project,
from research, decisions that have been made to verify progress and a
conclusion with tips to continue this project so that the next project group
can continue this project.

Also all the other documents will need to be finalized and double checked,
especially the design document since it will function as a 'blueprint' of the
project.

== Project control

=== Risk management

What the possible risks are, and how they are managed, can be seen in the table
below.

.Risk management calculations
[cols="2,1"]
|===
| General risk calculation (Chance x Impact) | Outcome

| HxH | High
| HxA | High
| HxL | Average
| AxH | High
| AxA | Average
| AxL | Low
| LxH | Average
| LxA | Low
| LxL | Low
|===

=== Quality control

This project just as any other project need to meet a certain level of quality
and this quality needs to be controlled or better said verified/management.

The level of quality must be defined within each task so that it is easier to
verify, this also why tasks should be created as SMART tasks. After that the
quality can be verified by someone else on the project and/or the customer
using the definition within the task. 

The quality of the project itself should be defined within a separate so called
qualification document. A qualification document for a technical project serves
as a crucial piece of information that outlines the necessary qualifications
and criteria for individuals or teams involved in the project. 

This document typically includes details such as the required technical skills,
educational background, work experience, certifications, and any other specific
requirements needed to successfully contribute to the project. By clearly
defining the qualifications needed, this document helps ensure that the right
individuals are selected for the project, leading to its successful completion.

=== Project scope

The aim of this project is to create a puzzle box with 4 different puzzles
representing the different directions in this study. Examining the existing
hardware designs is an important task to get a good idea of their status. The
existing hardware designs from previous groups will be used as a reference to
develop the software on. The software will enable interaction between the user
and the puzzle box for solving the different puzzles.

So, the task in this project is to develop this software using the given
hardware designs. If certain parts of this hardware don’t work, this should be
described in the handover document so that the next hardware student can work
on it. 

It was decided to focus only on the puzzle box itself because this project
requires a lot of research to ground out the documents of the previous groups.
So, the loose bomb and web interface are left out of this project and can be
realised later.

In addition, contact will be kept with the customer to properly incorporate the
requirements into the final product and both parties will not face any
surprises.

== Parties & Roles

This section defines the entities involved in this project and describes their
role in the project.

=== Team members

<<tab:members>> lists the executive party involved in this project. These
people are responsible for implementation, documentation, testing and
communication with the stakeholders. 

[[tab:members]]
.Team member table
[cols="3*"]
|===
| Name | Role | Study path

| Thomas in ‘t Anker | Developer | Software
| Loek Le Blansch | Developer & Project lead | Software
| Lars Faase | Developer | Software
| Elwin Hammer | Developer | Software
|===

=== Communication

Table 3 lists the stakeholders which receive regular updates about the project.
These people are informed about the current progress and are involved in any
meetings where requirements and/or specifications are discussed.

[[tab:stakeholders]]
.Project communication table
[cols="2,1,2,1"]
|===
|Name|Role|Communication tool(s)|Frequency

|Jasper van den Heuvel|Client|School email; Teams|Weekly
|Jonathan Overes|Client|School email; Teams|Weekly
|===

=== Version management

All source code developed during this project is kept under version control
using the Git [2] version control system and is available online at GitHub [3].
Each software component has a 3-digit version number following semantic
versioning [4] conventions (major, minor, patch).

This repository also utilizes Git submodules to track the versions of the
utilized libraries and SDKs. Submodules refer to commits, and can automatically
be initialized and managed using Git, so are not further specified in this
document.

All project documentation is realized using Microsoft Office products and is
therefore stored in a SharePoint folder [5]. These documents use a simple
2-digit (major, minor) version number system. The documents are published at
the discretion of the authors, with each new version incrementing the minor
version number. Major version number 0 is utilized for the document draft
versions, while 1 is utilized for documents after the project goal is reached.
A copy of all the documents is kept for each officially published version.

== Planning

This project utilizes GitHub Projects [6] to manage and allocate tasks to team
members. GitHub Projects supports multiple workflows, but this project only
follows the Kanban [7] workflow. Since the Kanban workflow does not require
sprints, the project is divided into milestones. A milestone is considered
complete once all tasks assigned to it are both marked as ‘complete’ and have
been reviewed.

At the request of the stakeholders, time spent working on the project is
tracked by each team member using Clockify [8].

Figure 1 shows a Gantt-chart including the phases from section 5. The
milestones are indicated with vertical dashed lines and are marked with week
numbers.

The research phase (§5.1) includes the planning and writing of the initial
draft versions of all the project documents. The documentation is also
continuously updated during the development phase, but this is not shown in
Figure 1.

The development phase (§5.2) consists of the continuous development of the main
(central) controller software and various accompanying tests. During this
phase, the software for each puzzle box side is developed in parallel. Each
side’s software development is staggered to avoid the accumulation of tasks.

The qualification phase (§5.3) consists of validating the results of the
development phase, fixing issues when they are discovered, and finalizing all
project documentation.

include::share/glossary.adoc[]