removed TODO and change some small typos

1 files changed, 23 insertions, 47 deletions

diff --git a/plan.tex b/plan.tex
index 076ce11..2f9cc94 100644
--- a/plan.tex
+++ b/plan.tex
@@ -20,7 +20,7 @@
 This project is part of the fourth-year minor `Systems Programming in C++'. The minor
 consists of several courses troughout 20 weeks, which create the basis for this
 project. The project is focussed on building a game engine using the programming
-language C++. This document describes our plan of attack for the project.
+language C++. This document describes the plan of attack for the project.
 
 \section{Problem Definition}
 
@@ -34,7 +34,7 @@ language C++. This document describes our plan of attack for the project.
 \subsection{Problem Analysis}
 
 CodedFun Games is a small, single-person game company looking to scale up. The owner,
-who is also a game programmer, and graphical artist, has received government funding,
+who is a game programmer, and graphical artist, has received government funding,
 which he wants to invest in a custom-built game engine. The owner has no interest in
 developing or maintaining a game engine himself, so he has hired a part-time engine
 programmer. This programmer does not have time to create an entire engine but is
@@ -49,29 +49,19 @@ Therefore, he wants the new engine to adhere to a similar structure. A simple
 requirements document is defined to specify how strictly this structure should be
 followed.
 
-Finally, because the client does not want to dive deeply into the engine himself, he
-wants a secondary application (preferably a game) that can be used to test the
-engine's features. This is referred to as the \emph{validation application}.
+Finally, because the client does not want to dive deeply into the engine himself, he wants a secondary application (preferably a game) that can be used to test the engine's features. This is referred to as the \emph{validation application}.
 
 \subsection{Goal}
 
-The goal is to develop a custom game engine that meets the client's requirements for
-maintainability, extensibility, user-friendliness, and adherence to a Unity-like
-structure. In addition, a validation application should be created to show and test
-the engine's features.
+The goal is to develop a custom game engine that meets the client's requirements for maintainability, extensibility, user-friendliness, and adherence to a Unity-like structure. In addition, a validation application is created to show and test the engine's features.
 
 \subsection{Result}
 
-The expected result is a well-documented, custom game engine that follows a structure
-similar to Unity. Additionally, a validation application should be provided to test
-and showcase the engine's capabilities.
+The expected result is a well-documented, custom game engine that follows a structure similar to Unity. Additionally, a validation application should be provided to test and showcase the engine's capabilities.
 
 \section{Planning}
 
-The customer specified multiple deliverables troughout the 20 weeks of this project.
-Despite the fact that 20 weeks have been reserved for this project, the intention is
-that the game will be delivered in week 17. Any delay/resit will take place between
-weeks 17 and 20. A rough planning can be found in \cref{tab:planning}.
+The customer specified multiple deliverables throughout the 20 weeks of this project. Despite the fact that 20 weeks have been reserved for this project, the game will be delivered in week 17. Any delay/resit will take place between weeks 17 and 20. A rough planning can be found in \cref{tab:planning}.
 
 \begin{table}
 	\begin{tabularx}{\linewidth}{lX}
@@ -106,21 +96,20 @@ weeks 17 and 20. A rough planning can be found in \cref{tab:planning}.
 	\item[Scope Expansion] There is a risk of creating a scope that is bigger than the
 		requirements. Lack of Team Collaboration: Insufficient collaboration among team
 		members may hinder progress.
+	\item[Lack of Team Collaboration] Within the team a lack of collaboration can result in miscommunication or delay in work.
 \end{description}
 
 \subsection{Measures}
 
 \begin{description}
 	\item[Multiplatform] The team can switch any time to a single platform, so this
-		risk is metigated. 
+		risk is metigated.
 	\item[Integration] By following standards and having an integrator, which checks
 		every pull request, this risk is minimilised.
 	\item[Scope Expansion] By writing detailed requirements and having weekly team
 		meetings, to check if the progress is within the scope, should be sufficient to
 		decrease the risk.
-	\item[Lack of Team Collaboration] Weekly team meetings will result in collaboration
-		among team members and discussing what each other tasks is, will decease this
-		risk.
+	\item[Lack of Team Collaboration] Weekly team meetings will result in collaboration among team members and discussing what each other tasks is, will decease this risk.
 \end{description}
 
 \section{Documentation}
@@ -177,8 +166,8 @@ Each project member will keep track of their own working hours and add them to t
 
 \subsection{Absence or delay}
 
-If a project member is going to be absent or delayed, they are required to 
-notify the team through either WhatsApp or Outlook. Additionally, the teacher 
+If a project member is going to be absent or delayed, they are required to
+notify the team through either WhatsApp or Outlook. Additionally, the teacher
 should be informed of the absence as well.
 
 \subsection{Inconsistent participation}
@@ -200,9 +189,9 @@ will be necessary in such cases. However, if the inconsistency is due to other
 factors, potential repercussions may include additional assignments or actions as
 determined by the project supervisor.
 
-A team member is considered to have inconsistent participation if their hours 
-are significantly behind the team’s average or if tasks are not completed 
-without valid reasons. It is essential that any concerns regarding a team 
+A team member is considered to have inconsistent participation if their hours
+are significantly behind the team’s average or if tasks are not completed
+without valid reasons. It is essential that any concerns regarding a team
 member's performance, should be resolved through unanimous agreement within the team.
 
 \subsection{Weekly Update}
@@ -212,9 +201,9 @@ before 12:00 on Friday. Personal updates may also be included and will be
 confidential between the team member, the Team Leader, and/or the teacher, if
 requested.
 
-Jaro Rutjes will compile and send a team update to the project supervisor, Bob 
-van der Putten, also by Friday. This update will include technical information 
-on what has been accomplished, plans for upcoming work, and an overview of the 
+Jaro Rutjes will compile and send a team update to the project supervisor, Bob
+van der Putten, also by Friday. This update will include technical information
+on what has been accomplished, plans for upcoming work, and an overview of the
 team's overall progress.
 
 \subsection{Weekly Meetings}
@@ -230,8 +219,7 @@ project needs.
 % Information about how and when Scrum will be used in this project (using Miro).
 \section{Scrum (Miro)}
 
-The team will start using scrum after the initial phase, of structering the project,
-is finished. This phase is over when proof of concepts are being made.
+The team starts using scrum after the initial phase, of structering the project, is finished. This phase is finished after a initial design of the product is made.
 
 \subsection{Scrum Board}
 
@@ -257,26 +245,22 @@ To manage tasks effectively:
 
 \begin{itemize}
 	\item A task from the \emph{Current Sprint} tab should be selected and moved to the
-		\emph{In Progress} tab when work begins. 
+		\emph{In Progress} tab when work begins.
 	\item The status of the task should be updated to \emph{In Progress} as soon as
 		work starts.
 	\item Once the task is completed and reviewed, it should be moved to the
 		\emph{Done} tab, and its status should be updated to \emph{Done}.
 \end{itemize}
 
-Each task or user story will be assigned user points, which indicate the relative
-size or complexity of the task compared to these examples.
-% TODO: add examples
+Each task or user story will be assigned user points, which indicate the relative size or complexity of the task. Examples of certain tasks will be available in the scrumboard.
 
 \subsection{Burn Down Chart}
 
 The Burn Down Chart will be generated using Excel from the Scrum board data every
 week. Each user story or task marked as done, will burn the chart downwards. This
-Burn Down Chart is shared in the weekly updates with the team and the project
-supervisor.
+Burn Down Chart is shared in the weekly updates with the team.
 
 % Information regarding the git workflow of this project.
-% TODO: Diagram explaining the workflow
 \section{Git Workflow}
 
 GitHub is used for version management of both code \autocite{crepe:code-repo} and
@@ -284,16 +268,8 @@ documentation \autocite{crepe:docs-repo}, each in its own respective repository.
 keeps the documentation and code seperate, resulting in ordened and manageable
 repositories.
 
-\subsection{Git New Branch}
+\subsection{Code Standard and git workflow}
 
-% TODO: add here details from contributing.md?
-
-\subsection{Git Merge To Master}
-
-% TODO: add here diagram on what actions are taken before merge.
-
-\subsection{Code Standard}
-
-The code standard can be found in the contributing.md \autocite{crepe:code-standard}.
+The code standard and the git workflow can be found in the contributing.md \autocite{crepe:code-standard}.
 
 \end{document}