From b9b2b0379f7d15dc2adb27955c8b5bb829c2cc0d Mon Sep 17 00:00:00 2001 From: Jaro Date: Wed, 4 Sep 2024 19:35:21 +0200 Subject: Added Git Workflow (placeholder), Scrum (placeholder), Documentation Standard(placeholder) and Work Agreements --- plan.tex | 86 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 85 insertions(+), 1 deletion(-) (limited to 'plan.tex') diff --git a/plan.tex b/plan.tex index 4ad9bad..82385f1 100644 --- a/plan.tex +++ b/plan.tex @@ -4,6 +4,90 @@ \title{Project Plan} \begin{document} -hoi + +% Information regarding the git workflow of this project. Diagram explaining the workflow +\section{Git Workflow} + +GitHub is used for version management of both code and documentation, each in its own respective repository. +This keep the documentation and code seperate, resulting in ordened and manageable repositories. + +\begin{itemize} + \item Code Repository: \href{https://github.com/lonkaars/crepe}{crepe} + \item Documentation Repository: \href{https://github.com/lonkaars/crepe-docs}{crepe-docs} +\end{itemize} + +\subsection{Git new branch} +% TODO: add here details from contributing.md? +\subsection{Git merge to master} +% TODO: add here diagram on what actions are taken before merge. +\newpage + +% Information about how and when Scrum will be used in this project (using Miro). +\section{Scrum (Miro)} +\subsection{Scrum Board} +\subsection{Burn down chart} +\newpage + +% Documentation Standard is described here +\section{Documentation Standard} +\newpage + +\section{Work Agreements} +\subsection{Project roles} + +\begin{itemize} + \item \textbf{Loek Le Blansch}: Integrator + \item \textbf{Wouter Boerenkamps}: Project Member + \item \textbf{Jaro Rutjes}: Team Leader / Scrum Master + \item \textbf{Max Smits}: Project Member + \item \textbf{Niels Stunnebrink}: Project Member +\end{itemize} + + +\subsection{Work hours} +Each project member will keep track of their own working hours and +add them to the 'file'. + +\subsection{Absents} +If a project member is going to be absent, 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} +Inconsistent participation will be addressed in a structured manner: + +\begin{enumerate} + \item \textbf{Initial Discussion}: The team leader will first discuss the + issue of inconsistent participation with the individual team member. + \item \textbf{Team Discussion}: If no improvement is observed, the issue + will be brought up with the entire team to seek a collective solution. + \item \textbf{Project Supervisor Involvement}: Should the problem persist + despite these efforts, it will be escalated to the project supervisor for + further action. +\end{enumerate} + +Valid reasons for absence or inconsistency will be considered, and no +repercussions 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 +member's performance be resolved through unanimous agreement within the team. + + +\subsection{Weekly update} +Each team member is required to send their technical weekly update to Jaro +Rutjes before 12:00 on Friday. Personal updates may also be included and will be kept +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 team's overall progress. +\newpage + \end{document} -- cgit v1.2.3 From 014c30c4dfd302cd049f3f52a89dc67f6e1bae5b Mon Sep 17 00:00:00 2001 From: Jaro Date: Wed, 4 Sep 2024 20:44:44 +0200 Subject: Filled placeholder scrum with information --- plan.tex | 51 +++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 49 insertions(+), 2 deletions(-) (limited to 'plan.tex') diff --git a/plan.tex b/plan.tex index 82385f1..eaf32be 100644 --- a/plan.tex +++ b/plan.tex @@ -24,14 +24,48 @@ This keep the documentation and code seperate, resulting in ordened and manageab % 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 inital fase of sructering the project is over. +This fase is over when proof of concepts are being made. + \subsection{Scrum Board} +The \href{https://miro.com/app/board/uXjVKjtdM64=/?share_link_id=303851465474}{Scrum board} will consist of the following tabs: + +\begin{itemize} + \item \textbf{Backlog}: This tab contains a list of all tasks and user stories that are planned for future sprints. + \item \textbf{Next Sprint}: This tab includes tasks and user stories that have been selected for the upcoming sprint. + \item \textbf{Current Sprint}: This tab displays the tasks and user stories that are actively being worked on in the current sprint. + \item \textbf{In Progress}: Tasks that are actively being worked on are moved to this tab. + \item \textbf{Review}: Completed tasks that are awaiting review or testing will be placed in this tab. + \item \textbf{Done}: Once tasks have been reviewed and are considered complete, they are moved to the Done tab. + \item \textbf{Blocked}: This tab is used for tasks that cannot proceed due to obstacles or dependencies. +\end{itemize} + +\noindent +To manage tasks effectively: +\begin{itemize} + \item A task from the \textbf{Current Sprint} tab should be selected and moved to the \textbf{In Progress} tab when work begins. + \item The status of the task should be updated to \textbf{In Progress} as soon as work starts. + \item Once the task is completed and reviewed, it should be moved to the \textbf{Done} tab, and its status should be updated to \textbf{Done}. +\end{itemize} + +\noindent +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 + \subsection{Burn down chart} +The Burn Down Chart will be generated using Excel from the Scrum board data every week. +Each user story or tasks 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. \newpage % Documentation Standard is described here \section{Documentation Standard} \newpage +\section{Documents} +\newpage + \section{Work Agreements} \subsection{Project roles} @@ -48,8 +82,8 @@ This keep the documentation and code seperate, resulting in ordened and manageab Each project member will keep track of their own working hours and add them to the 'file'. -\subsection{Absents} -If a project member is going to be absent, they are required to notify the +\subsection{Absents 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 should be informed of the absence as well. @@ -87,7 +121,20 @@ 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} +The project team will hold at least two meetings each week, with each meeting +lasting a maximum of 30 minutes. Following these meetings, an additional one +hour will be scheduled for discussions on the topics covered. + +Meetings will be planned and discussed one week in advance, with invitations +sent via Outlook. Additional meetings may be scheduled if necessary to address +issues or project needs. + + \newpage + + \end{document} -- cgit v1.2.3 From 0fda79a5d90a66a32b0c21d6951f67d2cf140107 Mon Sep 17 00:00:00 2001 From: Jaro Date: Thu, 5 Sep 2024 08:55:29 +0200 Subject: Filled in documentation --- plan.tex | 128 ++++++++++++++++++++++++++++++++++++--------------------------- 1 file changed, 74 insertions(+), 54 deletions(-) (limited to 'plan.tex') diff --git a/plan.tex b/plan.tex index eaf32be..40c0c9a 100644 --- a/plan.tex +++ b/plan.tex @@ -5,70 +5,39 @@ \begin{document} -% Information regarding the git workflow of this project. Diagram explaining the workflow -\section{Git Workflow} - -GitHub is used for version management of both code and documentation, each in its own respective repository. -This keep the documentation and code seperate, resulting in ordened and manageable repositories. - -\begin{itemize} - \item Code Repository: \href{https://github.com/lonkaars/crepe}{crepe} - \item Documentation Repository: \href{https://github.com/lonkaars/crepe-docs}{crepe-docs} -\end{itemize} - -\subsection{Git new branch} -% TODO: add here details from contributing.md? -\subsection{Git merge to master} -% TODO: add here diagram on what actions are taken before merge. +\tablestables \newpage -% 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 inital fase of sructering the project is over. -This fase is over when proof of concepts are being made. - -\subsection{Scrum Board} -The \href{https://miro.com/app/board/uXjVKjtdM64=/?share_link_id=303851465474}{Scrum board} will consist of the following tabs: - -\begin{itemize} - \item \textbf{Backlog}: This tab contains a list of all tasks and user stories that are planned for future sprints. - \item \textbf{Next Sprint}: This tab includes tasks and user stories that have been selected for the upcoming sprint. - \item \textbf{Current Sprint}: This tab displays the tasks and user stories that are actively being worked on in the current sprint. - \item \textbf{In Progress}: Tasks that are actively being worked on are moved to this tab. - \item \textbf{Review}: Completed tasks that are awaiting review or testing will be placed in this tab. - \item \textbf{Done}: Once tasks have been reviewed and are considered complete, they are moved to the Done tab. - \item \textbf{Blocked}: This tab is used for tasks that cannot proceed due to obstacles or dependencies. -\end{itemize} - -\noindent -To manage tasks effectively: +% Documentation Standard is described here +\section{Documentation} +This section describes the required documentation for the project, including the types of documents to be created and the standards they must adhere to. +\subsection{Documents} +This project consists of five main documents: \begin{itemize} - \item A task from the \textbf{Current Sprint} tab should be selected and moved to the \textbf{In Progress} tab when work begins. - \item The status of the task should be updated to \textbf{In Progress} as soon as work starts. - \item Once the task is completed and reviewed, it should be moved to the \textbf{Done} tab, and its status should be updated to \textbf{Done}. + \item \textbf{Project Plan:} Contains all elements related to the + organization of the project, including timelines, milestones, roles, + responsibilities. + \item \textbf{Requirements:} Details the requirements and + user stories, including both functional and non-functional requirements. + \item \textbf{Research:} Consists of all research related to this project. + \item \textbf{Design:} Describes the design choices, including + architecture, user interface, and system components. + \item \textbf{Qualification:} Includes test cases, test plans, and quality measures to + ensure the project meets its requirements and standards. \end{itemize} -\noindent -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 +\subsection{Documentation Standard} -\subsection{Burn down chart} -The Burn Down Chart will be generated using Excel from the Scrum board data every week. -Each user story or tasks 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. -\newpage - -% Documentation Standard is described here -\section{Documentation Standard} -\newpage - -\section{Documents} \newpage \section{Work Agreements} -\subsection{Project roles} +Work agreements are the expectations and commitments made by the team members. +This section includes details on roles and responsibilities, documentation of +work hours, protocols for handling absences or delays, guidelines for +addressing inconsistent participation, and procedures for weekly updates and +meetings. All team members reviewed and agreed to these terms. +\subsection{Project roles} \begin{itemize} \item \textbf{Loek Le Blansch}: Integrator \item \textbf{Wouter Boerenkamps}: Project Member @@ -131,10 +100,61 @@ Meetings will be planned and discussed one week in advance, with invitations sent via Outlook. Additional meetings may be scheduled if necessary to address issues or project needs. +\newpage + +% 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 inital fase of sructering the project is over. +This fase is over when proof of concepts are being made. + +\subsection{Scrum Board} +The \href{https://miro.com/app/board/uXjVKjtdM64=/?share_link_id=303851465474}{Scrum board} will consist of the following tabs: + +\begin{itemize} + \item \textbf{Backlog}: This tab contains a list of all tasks and user stories that are planned for future sprints. + \item \textbf{Next Sprint}: This tab includes tasks and user stories that have been selected for the upcoming sprint. + \item \textbf{Current Sprint}: This tab displays the tasks and user stories that are actively being worked on in the current sprint. + \item \textbf{In Progress}: Tasks that are actively being worked on are moved to this tab. + \item \textbf{Review}: Completed tasks that are awaiting review or testing will be placed in this tab. + \item \textbf{Done}: Once tasks have been reviewed and are considered complete, they are moved to the Done tab. + \item \textbf{Blocked}: This tab is used for tasks that cannot proceed due to obstacles or dependencies. +\end{itemize} + +\noindent +To manage tasks effectively: +\begin{itemize} + \item A task from the \textbf{Current Sprint} tab should be selected and moved to the \textbf{In Progress} tab when work begins. + \item The status of the task should be updated to \textbf{In Progress} as soon as work starts. + \item Once the task is completed and reviewed, it should be moved to the \textbf{Done} tab, and its status should be updated to \textbf{Done}. +\end{itemize} + +\noindent +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 +\subsection{Burn down chart} +The Burn Down Chart will be generated using Excel from the Scrum board data every week. +Each user story or tasks 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. \newpage +% Information regarding the git workflow of this project. Diagram explaining the workflow +\section{Git Workflow} + +GitHub is used for version management of both code and documentation, each in its own respective repository. +This keep the documentation and code seperate, resulting in ordened and manageable repositories. +\begin{itemize} + \item Code Repository: \href{https://github.com/lonkaars/crepe}{crepe} + \item Documentation Repository: \href{https://github.com/lonkaars/crepe-docs}{crepe-docs} +\end{itemize} + +\subsection{Git new branch} +% TODO: add here details from contributing.md? +\subsection{Git merge to master} +% TODO: add here diagram on what actions are taken before merge. +\newpage \end{document} -- cgit v1.2.3 From 441e03b613064552d8ab11a6a7eacf6d66d5b999 Mon Sep 17 00:00:00 2001 From: Jaro Date: Thu, 5 Sep 2024 15:26:42 +0200 Subject: Recieved feedback --- plan.tex | 121 +++++++++++++++++++++++++++++++++------------------------------ 1 file changed, 63 insertions(+), 58 deletions(-) (limited to 'plan.tex') diff --git a/plan.tex b/plan.tex index 40c0c9a..7eea565 100644 --- a/plan.tex +++ b/plan.tex @@ -10,21 +10,27 @@ % Documentation Standard is described here \section{Documentation} -This section describes the required documentation for the project, including the types of documents to be created and the standards they must adhere to. + +This section describes the required documentation for the project, including the + types of documents to be created and the standards they must adhere to. + \subsection{Documents} + This project consists of five main documents: -\begin{itemize} - \item \textbf{Project Plan:} Contains all elements related to the - organization of the project, including timelines, milestones, roles, - responsibilities. - \item \textbf{Requirements:} Details the requirements and - user stories, including both functional and non-functional requirements. - \item \textbf{Research:} Consists of all research related to this project. - \item \textbf{Design:} Describes the design choices, including - architecture, user interface, and system components. - \item \textbf{Qualification:} Includes test cases, test plans, and quality measures to - ensure the project meets its requirements and standards. -\end{itemize} + +\begin{description} + \item[Project Plan] Contains all elements related to the organization of the + project, including timelines, milestones, roles, responsibilities. + \item \textbf{Requirements:} Details the requirements and + user stories, including both functional and non-functional requirements. + \item \textbf{Research:} Consists of all research related to this project. + \item \textbf{Design:} Describes the design choices, including architecture, + user interface, and system components. + \item \textbf{Qualification:} Includes test cases, test plans, and quality + measures to ensure the project meets its requirements and standards. + \item \textbf{Working hours:} + \item \textbf{Api referenece:} +\end{description} \subsection{Documentation Standard} @@ -33,47 +39,47 @@ This project consists of five main documents: \section{Work Agreements} Work agreements are the expectations and commitments made by the team members. This section includes details on roles and responsibilities, documentation of -work hours, protocols for handling absences or delays, guidelines for -addressing inconsistent participation, and procedures for weekly updates and -meetings. All team members reviewed and agreed to these terms. +work hours, protocols for handling absences or delays, guidelines for addressing + inconsistent participation, and procedures for weekly updates and meetings. All + team members reviewed and agreed to these terms. \subsection{Project roles} \begin{itemize} - \item \textbf{Loek Le Blansch}: Integrator - \item \textbf{Wouter Boerenkamps}: Project Member - \item \textbf{Jaro Rutjes}: Team Leader / Scrum Master - \item \textbf{Max Smits}: Project Member - \item \textbf{Niels Stunnebrink}: Project Member + \item \textbf{Loek Le Blansch}: Integrator + \item \textbf{Wouter Boerenkamps}: Project Member + \item \textbf{Jaro Rutjes}: Team Leader / Scrum Master + \item \textbf{Max Smits}: Project Member + \item \textbf{Niels Stunnebrink}: Project Member \end{itemize} \subsection{Work hours} Each project member will keep track of their own working hours and -add them to the 'file'. +add them to the `file'. \subsection{Absents 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 should -be informed of the absence as well. +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} Inconsistent participation will be addressed in a structured manner: \begin{enumerate} - \item \textbf{Initial Discussion}: The team leader will first discuss the - issue of inconsistent participation with the individual team member. - \item \textbf{Team Discussion}: If no improvement is observed, the issue - will be brought up with the entire team to seek a collective solution. - \item \textbf{Project Supervisor Involvement}: Should the problem persist - despite these efforts, it will be escalated to the project supervisor for - further action. + \item \textbf{Initial Discussion}: The team leader will first discuss the + issue of inconsistent participation with the individual team member. + \item \textbf{Team Discussion}: If no improvement is observed, the issue + will be brought up with the entire team to seek a collective solution. + \item \textbf{Project Supervisor Involvement}: Should the problem persist + despite these efforts, it will be escalated to the project supervisor for + further action. \end{enumerate} Valid reasons for absence or inconsistency will be considered, and no -repercussions 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. - +repercussions 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 @@ -82,14 +88,14 @@ member's performance be resolved through unanimous agreement within the team. \subsection{Weekly update} Each team member is required to send their technical weekly update to Jaro -Rutjes before 12:00 on Friday. Personal updates may also be included and will be kept -confidential between the team member, the Team Leader, and/or the teacher, -if requested. +Rutjes 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 team's overall progress. +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} The project team will hold at least two meetings each week, with each meeting @@ -105,28 +111,27 @@ issues or 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 inital fase of sructering the project is over. -This fase is over when proof of concepts are being made. +The team will start using scrum after the inital fase of sructering the project is over.This fase is over when proof of concepts are being made. \subsection{Scrum Board} The \href{https://miro.com/app/board/uXjVKjtdM64=/?share_link_id=303851465474}{Scrum board} will consist of the following tabs: - + \begin{itemize} - \item \textbf{Backlog}: This tab contains a list of all tasks and user stories that are planned for future sprints. - \item \textbf{Next Sprint}: This tab includes tasks and user stories that have been selected for the upcoming sprint. - \item \textbf{Current Sprint}: This tab displays the tasks and user stories that are actively being worked on in the current sprint. - \item \textbf{In Progress}: Tasks that are actively being worked on are moved to this tab. - \item \textbf{Review}: Completed tasks that are awaiting review or testing will be placed in this tab. - \item \textbf{Done}: Once tasks have been reviewed and are considered complete, they are moved to the Done tab. - \item \textbf{Blocked}: This tab is used for tasks that cannot proceed due to obstacles or dependencies. + \item \textbf{Backlog}: This tab contains a list of all tasks and user stories that are planned for future sprints. + \item \textbf{Next Sprint}: This tab includes tasks and user stories that have been selected for the upcoming sprint. + \item \textbf{Current Sprint}: This tab displays the tasks and user stories that are actively being worked on in the current sprint. + \item \textbf{In Progress}: Tasks that are actively being worked on are moved to this tab. + \item \textbf{Review}: Completed tasks that are awaiting review or testing will be placed in this tab. + \item \textbf{Done}: Once tasks have been reviewed and are considered complete, they are moved to the Done tab. + \item \textbf{Blocked}: This tab is used for tasks that cannot proceed due to obstacles or dependencies. \end{itemize} \noindent To manage tasks effectively: \begin{itemize} - \item A task from the \textbf{Current Sprint} tab should be selected and moved to the \textbf{In Progress} tab when work begins. - \item The status of the task should be updated to \textbf{In Progress} as soon as work starts. - \item Once the task is completed and reviewed, it should be moved to the \textbf{Done} tab, and its status should be updated to \textbf{Done}. + \item A task from the \textbf{Current Sprint} tab should be selected and moved to the \textbf{In Progress} tab when work begins. + \item The status of the task should be updated to \textbf{In Progress} as soon as work starts. + \item Once the task is completed and reviewed, it should be moved to the \textbf{Done} tab, and its status should be updated to \textbf{Done}. \end{itemize} \noindent @@ -146,8 +151,8 @@ GitHub is used for version management of both code and documentation, each in it This keep the documentation and code seperate, resulting in ordened and manageable repositories. \begin{itemize} - \item Code Repository: \href{https://github.com/lonkaars/crepe}{crepe} - \item Documentation Repository: \href{https://github.com/lonkaars/crepe-docs}{crepe-docs} + \item Code Repository: \href{https://github.com/lonkaars/crepe}{crepe} + \item Documentation Repository: \href{https://github.com/lonkaars/crepe-docs}{crepe-docs} \end{itemize} \subsection{Git new branch} -- cgit v1.2.3 From 8012948973ab4074c74193aff727870706f587fe Mon Sep 17 00:00:00 2001 From: Jaro Date: Thu, 5 Sep 2024 16:10:18 +0200 Subject: added some feadback --- plan.tex | 56 ++++++++++++++++++++++++++++---------------------------- 1 file changed, 28 insertions(+), 28 deletions(-) (limited to 'plan.tex') diff --git a/plan.tex b/plan.tex index 7eea565..69a28ae 100644 --- a/plan.tex +++ b/plan.tex @@ -16,27 +16,27 @@ This section describes the required documentation for the project, including the \subsection{Documents} -This project consists of five main documents: +This project consists of five main documents:\noparbreak \begin{description} \item[Project Plan] Contains all elements related to the organization of the project, including timelines, milestones, roles, responsibilities. - \item \textbf{Requirements:} Details the requirements and + \item[Requirements] Details the requirements and user stories, including both functional and non-functional requirements. - \item \textbf{Research:} Consists of all research related to this project. - \item \textbf{Design:} Describes the design choices, including architecture, + \item[Research] Consists of all research related to this project. + \item[Design] Describes the design choices, including architecture, user interface, and system components. - \item \textbf{Qualification:} Includes test cases, test plans, and quality + \item[Qualification] Includes test cases, test plans, and quality measures to ensure the project meets its requirements and standards. - \item \textbf{Working hours:} - \item \textbf{Api referenece:} + \item[Working hours] + \item[Api referenece] \end{description} -\subsection{Documentation Standard} +\subsection{Documentation standard} \newpage -\section{Work Agreements} +\section{Work agreements} Work agreements are the expectations and commitments made by the team members. This section includes details on roles and responsibilities, documentation of work hours, protocols for handling absences or delays, guidelines for addressing @@ -57,23 +57,23 @@ work hours, protocols for handling absences or delays, guidelines for addressing Each project member will keep track of their own working hours and add them to the `file'. -\subsection{Absents or delay} +\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 should be informed of the absence as well. -\subsection{Inconsistent Participation} +\subsection{Inconsistent participation} Inconsistent participation will be addressed in a structured manner: -\begin{enumerate} - \item \textbf{Initial Discussion}: The team leader will first discuss the +\begin{description} + \item[Initial Discussion] The team leader will first discuss the issue of inconsistent participation with the individual team member. - \item \textbf{Team Discussion}: If no improvement is observed, the issue + \item [Team Discussion]: If no improvement is observed, the issue will be brought up with the entire team to seek a collective solution. - \item \textbf{Project Supervisor Involvement}: Should the problem persist + \item [Project Supervisor Involvement]: Should the problem persist despite these efforts, it will be escalated to the project supervisor for further action. -\end{enumerate} +\end{description} Valid reasons for absence or inconsistency will be considered, and no repercussions will be necessary in such cases. However, if the inconsistency is @@ -116,22 +116,22 @@ The team will start using scrum after the inital fase of sructering the project \subsection{Scrum Board} The \href{https://miro.com/app/board/uXjVKjtdM64=/?share_link_id=303851465474}{Scrum board} will consist of the following tabs: -\begin{itemize} - \item \textbf{Backlog}: This tab contains a list of all tasks and user stories that are planned for future sprints. - \item \textbf{Next Sprint}: This tab includes tasks and user stories that have been selected for the upcoming sprint. - \item \textbf{Current Sprint}: This tab displays the tasks and user stories that are actively being worked on in the current sprint. - \item \textbf{In Progress}: Tasks that are actively being worked on are moved to this tab. - \item \textbf{Review}: Completed tasks that are awaiting review or testing will be placed in this tab. - \item \textbf{Done}: Once tasks have been reviewed and are considered complete, they are moved to the Done tab. - \item \textbf{Blocked}: This tab is used for tasks that cannot proceed due to obstacles or dependencies. -\end{itemize} +\begin{description} + \item[Backlog]: This tab contains a list of all tasks and user stories that are planned for future sprints. + \item[Next Sprint]: This tab includes tasks and user stories that have been selected for the upcoming sprint. + \item[Current Sprint]: This tab displays the tasks and user stories that are actively being worked on in the current sprint. + \item[In Progress]: Tasks that are actively being worked on are moved to this tab. + \item[Review]: Completed tasks that are awaiting review or testing will be placed in this tab. + \item[Done]: Once tasks have been reviewed and are considered complete, they are moved to the Done tab. + \item [Blocked]: This tab is used for tasks that cannot proceed due to obstacles or dependencies. +\end{description} \noindent To manage tasks effectively: \begin{itemize} - \item A task from the \textbf{Current Sprint} tab should be selected and moved to the \textbf{In Progress} tab when work begins. - \item The status of the task should be updated to \textbf{In Progress} as soon as work starts. - \item Once the task is completed and reviewed, it should be moved to the \textbf{Done} tab, and its status should be updated to \textbf{Done}. + \item A task from the \emph{Current Sprint} tab should be selected and moved to the \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} \noindent -- cgit v1.2.3 From c95bb1495b7dc781ffd4528dbcf6ec292bd7a645 Mon Sep 17 00:00:00 2001 From: Jaro Date: Mon, 9 Sep 2024 19:00:08 +0200 Subject: Added more topics and filled in problem definition --- plan.tex | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 53 insertions(+), 12 deletions(-) (limited to 'plan.tex') diff --git a/plan.tex b/plan.tex index 69a28ae..19f7aac 100644 --- a/plan.tex +++ b/plan.tex @@ -8,6 +8,47 @@ \tablestables \newpage +\section{Problem Definition} +The assignment is part of a fourth-year minor. The assignments are not set in stone to give the team an opportunity to discuss with the project supervisor on specifics for this 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, graphical artist, and the client, 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 willing to maintain or expand an existing engine one day per week. + +The client seeks a custom game engine that is easy to maintain, extend, and user-friendly. Additionally, the engine should be well-documented, which is considered an essential aspect of being user-friendly. + +So far, the client has made all his games in Unity and is very fond of the structure. 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 `Validation App.' + +\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 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. + +\newpage + +\section{Planning} +% todo add table of deliverables +week 4: sprint oplevering, project plan +week 7: sprint oplevering +week 10: sprint oplevering, POC and design +week 17: eind oplevering + +\newpage + +\section{Risks} +\subsection{Techincal Risks} +% todo add technical risks +\subsection{Project Management Risks} +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. +\subsection{Measures} +Scope Expansion: By writing detailed requirements and having weekly team meeting to check if the progress is within the scope should be sufficient to decrease the risk. +Lack of Team Collaboration: Weekly team meetings will result is collaboration among team members and discussing what each other tasks is will decease this risk. +\newpage + % Documentation Standard is described here \section{Documentation} @@ -32,18 +73,18 @@ This project consists of five main documents:\noparbreak \item[Api referenece] \end{description} -\subsection{Documentation standard} - +\subsection{Documentation Standard} +% todo add link to contributing in this repo \newpage -\section{Work agreements} +\section{Work Agreements} Work agreements are the expectations and commitments made by the team members. This section includes details on roles and responsibilities, documentation of work hours, protocols for handling absences or delays, guidelines for addressing inconsistent participation, and procedures for weekly updates and meetings. All team members reviewed and agreed to these terms. -\subsection{Project roles} +\subsection{Project Roles} \begin{itemize} \item \textbf{Loek Le Blansch}: Integrator \item \textbf{Wouter Boerenkamps}: Project Member @@ -53,11 +94,11 @@ work hours, protocols for handling absences or delays, guidelines for addressing \end{itemize} -\subsection{Work hours} +\subsection{Work Hours} Each project member will keep track of their own working hours and add them to the `file'. -\subsection{Absence or delay} +\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 should be informed of the absence as well. @@ -86,7 +127,7 @@ without valid reasons. It is essential that any concerns regarding a team member's performance be resolved through unanimous agreement within the team. -\subsection{Weekly update} +\subsection{Weekly Update} Each team member is required to send their technical weekly update to Jaro Rutjes 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 @@ -97,7 +138,7 @@ 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} +\subsection{Weekly Meetings} The project team will hold at least two meetings each week, with each meeting lasting a maximum of 30 minutes. Following these meetings, an additional one hour will be scheduled for discussions on the topics covered. @@ -111,7 +152,7 @@ issues or 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 inital fase of sructering the project is over.This fase is over when proof of concepts are being made. +The team will start using scrum after the initial fase of structering the project is over. This fase is over when proof of concepts are being made. \subsection{Scrum Board} The \href{https://miro.com/app/board/uXjVKjtdM64=/?share_link_id=303851465474}{Scrum board} will consist of the following tabs: @@ -138,7 +179,7 @@ To manage tasks effectively: 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 -\subsection{Burn down chart} +\subsection{Burn Down Chart} The Burn Down Chart will be generated using Excel from the Scrum board data every week. Each user story or tasks 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. @@ -155,9 +196,9 @@ This keep the documentation and code seperate, resulting in ordened and manageab \item Documentation Repository: \href{https://github.com/lonkaars/crepe-docs}{crepe-docs} \end{itemize} -\subsection{Git new branch} +\subsection{Git New Branch} % TODO: add here details from contributing.md? -\subsection{Git merge to master} +\subsection{Git Merge To Master} % TODO: add here diagram on what actions are taken before merge. \newpage -- cgit v1.2.3 From 963430c931a85c3985a99c5bebd3fc6e9ae3b43b Mon Sep 17 00:00:00 2001 From: Jaro Date: Tue, 10 Sep 2024 08:53:39 +0200 Subject: added sources --- plan.tex | 27 ++++++++++++++------------- sources.bib | 36 ++++++++++++++++++++++++++++++++++++ 2 files changed, 50 insertions(+), 13 deletions(-) (limited to 'plan.tex') diff --git a/plan.tex b/plan.tex index 19f7aac..55a6d12 100644 --- a/plan.tex +++ b/plan.tex @@ -26,7 +26,7 @@ The goal is to develop a custom game engine that meets the client's requirements \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. -\newpage + \section{Planning} % todo add table of deliverables @@ -35,7 +35,7 @@ week 7: sprint oplevering week 10: sprint oplevering, POC and design week 17: eind oplevering -\newpage + \section{Risks} \subsection{Techincal Risks} @@ -47,7 +47,7 @@ may hinder progress. \subsection{Measures} Scope Expansion: By writing detailed requirements and having weekly team meeting to check if the progress is within the scope should be sufficient to decrease the risk. Lack of Team Collaboration: Weekly team meetings will result is collaboration among team members and discussing what each other tasks is will decease this risk. -\newpage + % Documentation Standard is described here \section{Documentation} @@ -69,13 +69,13 @@ This project consists of five main documents:\noparbreak user interface, and system components. \item[Qualification] Includes test cases, test plans, and quality measures to ensure the project meets its requirements and standards. - \item[Working hours] - \item[Api referenece] + \item[Working hours] A tabel which includes all working hours of each team member. + \item[API Reference] Details the available endpoints, request and response formats, authentication methods, error codes, and examples for interacting with the project's API. \end{description} \subsection{Documentation Standard} -% todo add link to contributing in this repo -\newpage +The documentation standard can be found in the contributing.md \autocite{crepe:docs-standard}. + \section{Work Agreements} Work agreements are the expectations and commitments made by the team members. @@ -147,7 +147,7 @@ Meetings will be planned and discussed one week in advance, with invitations sent via Outlook. Additional meetings may be scheduled if necessary to address issues or project needs. -\newpage + % Information about how and when Scrum will be used in this project (using Miro). \section{Scrum (Miro)} @@ -155,7 +155,7 @@ issues or project needs. The team will start using scrum after the initial fase of structering the project is over. This fase is over when proof of concepts are being made. \subsection{Scrum Board} -The \href{https://miro.com/app/board/uXjVKjtdM64=/?share_link_id=303851465474}{Scrum board} will consist of the following tabs: +The Scrum board \autocite{miro:scrum-board} will consist of the following tabs: \begin{description} \item[Backlog]: This tab contains a list of all tasks and user stories that are planned for future sprints. @@ -183,7 +183,7 @@ TODO: add examples The Burn Down Chart will be generated using Excel from the Scrum board data every week. Each user story or tasks 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. -\newpage + % Information regarding the git workflow of this project. Diagram explaining the workflow \section{Git Workflow} @@ -192,15 +192,16 @@ GitHub is used for version management of both code and documentation, each in it This keep the documentation and code seperate, resulting in ordened and manageable repositories. \begin{itemize} - \item Code Repository: \href{https://github.com/lonkaars/crepe}{crepe} - \item Documentation Repository: \href{https://github.com/lonkaars/crepe-docs}{crepe-docs} + \item Code Repository: crepe \autocite{crepe:code-repo} + \item Documentation Repository: crepe-docs \autocite{crepe:docs-repo} \end{itemize} \subsection{Git New Branch} % TODO: add here details from contributing.md? \subsection{Git Merge To Master} % TODO: add here diagram on what actions are taken before merge. -\newpage +\subsection{Code standard} +The code standard can be found in the contributing.md \autocite{crepe:code-standard}. \end{document} diff --git a/sources.bib b/sources.bib index b088784..5848f86 100644 --- a/sources.bib +++ b/sources.bib @@ -12,3 +12,39 @@ institution = {RFC Editor}, } +@misc{miro:scrum-board, + author = {Jaro Rutjes}, + title = {Scrum Board on Miro}, + url = {https://miro.com/app/board/uXjVKjtdM64=/?share_link_id=303851465474}, + date = {2024-09-10}, +} + +@misc{crepe:code-repo, + author = {lonkaars}, + title = {Crepe Code Repository}, + url = {https://github.com/lonkaars/crepe}, + date = {2024-09-10}, +} + +@misc{crepe:docs-repo, + author = {lonkaars}, + title = {Crepe Documentation Repository}, + url = {https://github.com/lonkaars}, + date = {2024-09-10}, +} + +@misc{crepe:docs-standard, + author = {lonkaars}, + title = {Crepe Documentation Standard}, + url = {https://github.com/lonkaars/crepe-docs/blob/master/contributing.md}, + date = {2024-09-10}, +} + +@misc{crepe:code-standard, + author = {lonkaars}, + title = {Crepe Code Standard}, + url = {https://github.com/lonkaars/crepe/blob/master/contributing.md}, + date = {2024-09-10}, +} + + -- cgit v1.2.3 From 603db3fe74db94ded146b22e9303dd8c064df494 Mon Sep 17 00:00:00 2001 From: Jaro Date: Tue, 10 Sep 2024 17:13:15 +0200 Subject: Added some risks --- plan.tex | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) (limited to 'plan.tex') diff --git a/plan.tex b/plan.tex index 55a6d12..43997f5 100644 --- a/plan.tex +++ b/plan.tex @@ -9,7 +9,7 @@ \newpage \section{Problem Definition} -The assignment is part of a fourth-year minor. The assignments are not set in stone to give the team an opportunity to discuss with the project supervisor on specifics for this project +The assignment is part of a fourth-year minor. The assignments will be discussed with the project supervisor on specifics for this project. This will give the team the ability to direct 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, graphical artist, and the client, 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 willing to maintain or expand an existing engine one day per week. @@ -39,6 +39,9 @@ week 17: eind oplevering \section{Risks} \subsection{Techincal Risks} +Multiplatform: The team works in linux and windows which poses a risk for the development if there is a platform dependencies. +Integration: Users can make a wrong integration causing for delay or risk of losing code. + % todo add technical risks \subsection{Project Management Risks} Scope Expansion: There is a risk of creating a scope that is bigger than the requirements. @@ -47,7 +50,8 @@ may hinder progress. \subsection{Measures} Scope Expansion: By writing detailed requirements and having weekly team meeting to check if the progress is within the scope should be sufficient to decrease the risk. Lack of Team Collaboration: Weekly team meetings will result is collaboration among team members and discussing what each other tasks is will decease this risk. - +Multiplatform: The team can switch any time to a single platform so this risk is metigated. +Integration: By follwing standard and having an integrator which checks every pull request this risk is minimilised. % Documentation Standard is described here \section{Documentation} -- cgit v1.2.3 From 57b1d29670d4b8dbe1b3b00cad6f74a172a4d30b Mon Sep 17 00:00:00 2001 From: Max-001 <80035972+Max-001@users.noreply.github.com> Date: Wed, 11 Sep 2024 15:55:48 +0200 Subject: First review of Jaro's Plan document (the document is not ready to hand in yet, there is still quite some work to do) --- plan.tex | 122 +++++++++++++++++++++++++++++++-------------------------------- 1 file changed, 60 insertions(+), 62 deletions(-) (limited to 'plan.tex') diff --git a/plan.tex b/plan.tex index 43997f5..2274c87 100644 --- a/plan.tex +++ b/plan.tex @@ -1,79 +1,94 @@ \documentclass{projdoc} \input{meta.tex} +% @Jaro: Zie hieronder +% Version 0.0 seems not right +% I'm also missing a 'version table' +% Shall we use this version system?: +% Version numbers after the comma indicate an interim version and version numbers before the comma indicate versions ready for publication + \title{Project Plan} +\version{0.1} \begin{document} \tablestables \newpage + +\section {Background} +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. + \section{Problem Definition} -The assignment is part of a fourth-year minor. The assignments will be discussed with the project supervisor on specifics for this project. This will give the team the ability to direct the project. +% The assignments will be discussed with the project supervisor on specifics for this project. This will give the team the ability to direct the project. +% @Jaro: Ik snap niet wat je met deze zinnen wil zeggen. Het lijkt een soort van background information, maar toch niet helemaal ofzo. Hoe dan ook heb ik het er nu even uit gehaald en een nieuw kopje background toegevoegd. \subsection{Problem Analysis} -CodedFun Games is a small, single-person game company looking to scale up. The owner, who is also a game programmer, graphical artist, and the client, 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 willing to maintain or expand an existing engine one day per week. +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, 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 willing to maintain or expand an existing engine one day per week. -The client seeks a custom game engine that is easy to maintain, extend, and user-friendly. Additionally, the engine should be well-documented, which is considered an essential aspect of being user-friendly. +The client seeks a custom game engine that is easy to maintain, easy to extend, and user-friendly. Additionally, the engine should be well-documented, which is considered an essential aspect of being user-friendly. So far, the client has made all his games in Unity and is very fond of the structure. 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 `Validation App.' +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 `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 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 should be 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. - \section{Planning} -% todo add table of deliverables -week 4: sprint oplevering, project plan -week 7: sprint oplevering -week 10: sprint oplevering, POC and design -week 17: eind oplevering - +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}. +\begin{table} + \begin{tabularx}{\linewidth}{lXr} + \toprule + Week & Deliverable & \\ + \midrule + 4 & Project Plan & \\ + 7 & Requirements document & \\ + 10 & POCs and Design document & \\ + 17 & Game engine, Validation application, Research document, and Qualification document & \\ + \bottomrule + \end{tabularx} + \caption{Planning} + \label{tab:planning} +\end{table} \section{Risks} \subsection{Techincal Risks} -Multiplatform: The team works in linux and windows which poses a risk for the development if there is a platform dependencies. +Multiplatform: The team works in both linux and windows, which poses a risk for the development if there is a platform dependency. Integration: Users can make a wrong integration causing for delay or risk of losing code. -% todo add technical risks \subsection{Project Management Risks} 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. + \subsection{Measures} -Scope Expansion: By writing detailed requirements and having weekly team meeting to check if the progress is within the scope should be sufficient to decrease the risk. -Lack of Team Collaboration: Weekly team meetings will result is collaboration among team members and discussing what each other tasks is will decease this risk. -Multiplatform: The team can switch any time to a single platform so this risk is metigated. -Integration: By follwing standard and having an integrator which checks every pull request this risk is minimilised. +Multiplatform: The team can switch any time to a single platform, so this risk is metigated. +Integration: By following standards and having an integrator, which checks every pull request, this risk is minimilised. +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. +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. + % Documentation Standard is described here \section{Documentation} - -This section describes the required documentation for the project, including the - types of documents to be created and the standards they must adhere to. +This section describes the required documentation for the project, including the types of documents to be created and the standards they must adhere to. \subsection{Documents} - -This project consists of five main documents:\noparbreak - +This project consists of seven main documents:\noparbreak \begin{description} - \item[Project Plan] Contains all elements related to the organization of the - project, including timelines, milestones, roles, responsibilities. - \item[Requirements] Details the requirements and - user stories, including both functional and non-functional requirements. + \item[Project Plan] Contains all elements related to the organization of the project, including timelines, milestones, roles, and responsibilities. + \item[Requirements] Details the requirements and user stories, including both functional and non-functional requirements. \item[Research] Consists of all research related to this project. \item[Design] Describes the design choices, including architecture, - user interface, and system components. + user interface, and system components. \item[Qualification] Includes test cases, test plans, and quality measures to ensure the project meets its requirements and standards. - \item[Working hours] A tabel which includes all working hours of each team member. + \item[Working hours] A table which includes all working hours of each team member. \item[API Reference] Details the available endpoints, request and response formats, authentication methods, error codes, and examples for interacting with the project's API. \end{description} @@ -84,9 +99,7 @@ The documentation standard can be found in the contributing.md \autocite{crepe:d \section{Work Agreements} Work agreements are the expectations and commitments made by the team members. This section includes details on roles and responsibilities, documentation of -work hours, protocols for handling absences or delays, guidelines for addressing - inconsistent participation, and procedures for weekly updates and meetings. All - team members reviewed and agreed to these terms. +work hours, protocols for handling absences or delays, guidelines for addressing inconsistent participation, and procedures for weekly updates and meetings. All team members reviewed and agreed to these terms. \subsection{Project Roles} \begin{itemize} @@ -97,10 +110,8 @@ work hours, protocols for handling absences or delays, guidelines for addressing \item \textbf{Niels Stunnebrink}: Project Member \end{itemize} - \subsection{Work Hours} -Each project member will keep track of their own working hours and -add them to the `file'. +Each project member will keep track of their own working hours and add them to the `file'. \subsection{Absence Or Delay} If a project member is going to be absent or delayed, they are required to @@ -109,35 +120,28 @@ should be informed of the absence as well. \subsection{Inconsistent participation} Inconsistent participation will be addressed in a structured manner: - \begin{description} - \item[Initial Discussion] The team leader will first discuss the + \item[Initial Discussion]: The team leader will first discuss the issue of inconsistent participation with the individual team member. \item [Team Discussion]: If no improvement is observed, the issue will be brought up with the entire team to seek a collective solution. - \item [Project Supervisor Involvement]: Should the problem persist - despite these efforts, it will be escalated to the project supervisor for - further action. + \item [Project Supervisor Involvement]: Should the problem persist, despite these efforts, it will be escalated to the project supervisor (Bob van der Putten) for further action. \end{description} Valid reasons for absence or inconsistency will be considered, and no repercussions 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. - +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 -member's performance be resolved through unanimous agreement within the team. - +member's performance, should be resolved through unanimous agreement within the team. \subsection{Weekly Update} Each team member is required to send their technical weekly update to Jaro -Rutjes 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. +Rutjes 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 +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. @@ -152,15 +156,12 @@ sent via Outlook. Additional meetings may be scheduled if necessary to address issues or 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 fase of structering the project is over. This fase is over when proof of concepts are being made. +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. \subsection{Scrum Board} The Scrum board \autocite{miro:scrum-board} will consist of the following tabs: - \begin{description} \item[Backlog]: This tab contains a list of all tasks and user stories that are planned for future sprints. \item[Next Sprint]: This tab includes tasks and user stories that have been selected for the upcoming sprint. @@ -181,20 +182,18 @@ To manage tasks effectively: \noindent 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 +% TODO: add examples \subsection{Burn Down Chart} The Burn Down Chart will be generated using Excel from the Scrum board data every week. -Each user story or tasks 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. +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. % Information regarding the git workflow of this project. Diagram explaining the workflow \section{Git Workflow} - GitHub is used for version management of both code and documentation, each in its own respective repository. -This keep the documentation and code seperate, resulting in ordened and manageable repositories. - +This keeps the documentation and code seperate, resulting in ordened and manageable repositories. \begin{itemize} \item Code Repository: crepe \autocite{crepe:code-repo} \item Documentation Repository: crepe-docs \autocite{crepe:docs-repo} @@ -204,8 +203,7 @@ This keep the documentation and code seperate, resulting in ordened and manageab % 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} +\subsection{Code Standard} The code standard can be found in the contributing.md \autocite{crepe:code-standard}. \end{document} - -- cgit v1.2.3 From 454b9e222473c67d0b3bb6935bf3bfb8d2e2043d Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Fri, 13 Sep 2024 16:40:50 +0200 Subject: merge #10 --- plan.tex | 276 ++++++++++++++++++++++++++++++++++++++++-------------------- projdoc.cls | 18 +++- sources.bib | 10 +-- 3 files changed, 205 insertions(+), 99 deletions(-) (limited to 'plan.tex') diff --git a/plan.tex b/plan.tex index 2274c87..076ce11 100644 --- a/plan.tex +++ b/plan.tex @@ -5,132 +5,200 @@ % Version 0.0 seems not right % I'm also missing a 'version table' % Shall we use this version system?: -% Version numbers after the comma indicate an interim version and version numbers before the comma indicate versions ready for publication +% Version numbers after the comma indicate an interim version and version numbers +% before the comma indicate versions ready for publication \title{Project Plan} \version{0.1} \begin{document} - \tablestables \newpage +\section{Background} -\section {Background} -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. +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. \section{Problem Definition} -% The assignments will be discussed with the project supervisor on specifics for this project. This will give the team the ability to direct the project. -% @Jaro: Ik snap niet wat je met deze zinnen wil zeggen. Het lijkt een soort van background information, maar toch niet helemaal ofzo. Hoe dan ook heb ik het er nu even uit gehaald en een nieuw kopje background toegevoegd. + +% The assignments will be discussed with the project supervisor on specifics for this +% project. This will give the team the ability to direct the project. + +% @Jaro: Ik snap niet wat je met deze zinnen wil zeggen. Het lijkt een soort van +% background information, maar toch niet helemaal ofzo. Hoe dan ook heb ik het er nu +% even uit gehaald en een nieuw kopje background toegevoegd. \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, 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 willing to maintain or expand an existing engine one day per week. -The client seeks a custom game engine that is easy to maintain, easy to extend, and user-friendly. Additionally, the engine should be well-documented, which is considered an essential aspect of being user-friendly. +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, +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 +willing to maintain or expand an existing engine one day per week. -So far, the client has made all his games in Unity and is very fond of the structure. 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. +The client seeks a custom game engine that is easy to maintain, easy to extend, and +user-friendly. Additionally, the engine should be well-documented, which is +considered an essential aspect of being user-friendly. -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 `validation application.' +So far, the client has made all his games in Unity and is very fond of the structure. +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}. \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 should be 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 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}. + \begin{table} - \begin{tabularx}{\linewidth}{lXr} + \begin{tabularx}{\linewidth}{lX} \toprule - Week & Deliverable & \\ + \textbf{Week\#} & \textbf{Deliverable}\\ \midrule - 4 & Project Plan & \\ - 7 & Requirements document & \\ - 10 & POCs and Design document & \\ - 17 & Game engine, Validation application, Research document, and Qualification document & \\ + 4 & Project Plan\\ + 7 & Requirements document\\ + 10 & POCs and Design document\\ + 17 & Game engine, Validation application, Research document, and Qualification + document\\ \bottomrule \end{tabularx} \caption{Planning} \label{tab:planning} \end{table} - \section{Risks} + \subsection{Techincal Risks} -Multiplatform: The team works in both linux and windows, which poses a risk for the development if there is a platform dependency. -Integration: Users can make a wrong integration causing for delay or risk of losing code. + +\begin{description} + \item[Multiplatform] The team works in both linux and windows, which poses a risk + for the development if there is a platform dependency. + \item[Integration] Users can make a wrong integration causing for delay or risk of + losing code. +\end{description} \subsection{Project Management Risks} -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. + +\begin{description} + \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. +\end{description} \subsection{Measures} -Multiplatform: The team can switch any time to a single platform, so this risk is metigated. -Integration: By following standards and having an integrator, which checks every pull request, this risk is minimilised. -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. -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. +\begin{description} + \item[Multiplatform] The team can switch any time to a single platform, so this + 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. +\end{description} -% Documentation Standard is described here \section{Documentation} -This section describes the required documentation for the project, including the types of documents to be created and the standards they must adhere to. + +This section describes the required documentation for the project, including the +types of documents to be created and the standards they must adhere to. \subsection{Documents} + This project consists of seven main documents:\noparbreak \begin{description} - \item[Project Plan] Contains all elements related to the organization of the project, including timelines, milestones, roles, and responsibilities. - \item[Requirements] Details the requirements and user stories, including both functional and non-functional requirements. + \item[Project Plan] Contains all elements related to the organization of the + project, including timelines, milestones, roles, and responsibilities. + \item[Requirements] Details the requirements and user stories, including both + functional and non-functional requirements. \item[Research] Consists of all research related to this project. - \item[Design] Describes the design choices, including architecture, - user interface, and system components. - \item[Qualification] Includes test cases, test plans, and quality - measures to ensure the project meets its requirements and standards. + \item[Design] Describes the design choices, including architecture, user interface, + and system components. + \item[Qualification] Includes test cases, test plans, and quality measures to + ensure the project meets its requirements and standards. \item[Working hours] A table which includes all working hours of each team member. - \item[API Reference] Details the available endpoints, request and response formats, authentication methods, error codes, and examples for interacting with the project's API. + \item[API Reference] Details the available endpoints, request and response formats, + authentication methods, error codes, and examples for interacting with the + project's API. \end{description} \subsection{Documentation Standard} -The documentation standard can be found in the contributing.md \autocite{crepe:docs-standard}. +The documentation standard can be found in the contributing.md +\autocite{crepe:docs-standard}. \section{Work Agreements} -Work agreements are the expectations and commitments made by the team members. -This section includes details on roles and responsibilities, documentation of -work hours, protocols for handling absences or delays, guidelines for addressing inconsistent participation, and procedures for weekly updates and meetings. All team members reviewed and agreed to these terms. -\subsection{Project Roles} -\begin{itemize} - \item \textbf{Loek Le Blansch}: Integrator - \item \textbf{Wouter Boerenkamps}: Project Member - \item \textbf{Jaro Rutjes}: Team Leader / Scrum Master - \item \textbf{Max Smits}: Project Member - \item \textbf{Niels Stunnebrink}: Project Member -\end{itemize} +Work agreements are the expectations and commitments made by the team members. This +section includes details on roles and responsibilities, documentation of work hours, +protocols for handling absences or delays, guidelines for addressing inconsistent +participation, and procedures for weekly updates and meetings. All team members +reviewed and agreed to these terms. -\subsection{Work Hours} -Each project member will keep track of their own working hours and add them to the `file'. +\subsection{Project roles} + +\begin{description} + \item[Loek Le Blansch] Integrator + \item[Wouter Boerenkamps] Project Member + \item[Jaro Rutjes] Team Leader / Scrum Master + \item[Max Smits] Project Member + \item[Niels Stunnebrink] Project Member +\end{description} + +\subsection{Work hours} + +Each project member will keep track of their own working hours and add them to the +`file'. + +\subsection{Absence or delay} -\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 should be informed of the absence as well. \subsection{Inconsistent participation} + Inconsistent participation will be addressed in a structured manner: + \begin{description} - \item[Initial Discussion]: The team leader will first discuss the - issue of inconsistent participation with the individual team member. - \item [Team Discussion]: If no improvement is observed, the issue - will be brought up with the entire team to seek a collective solution. - \item [Project Supervisor Involvement]: Should the problem persist, despite these efforts, it will be escalated to the project supervisor (Bob van der Putten) for further action. + \item[Initial Discussion] The team leader will first discuss the issue of + inconsistent participation with the individual team member. + \item [Team Discussion] If no improvement is observed, the issue will be brought up + with the entire team to seek a collective solution. + \item [Project Supervisor Involvement] Should the problem persist, despite these + efforts, it will be escalated to the project supervisor (Bob van der Putten) for + further action. \end{description} -Valid reasons for absence or inconsistency will be considered, and no -repercussions 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. +Valid reasons for absence or inconsistency will be considered, and no repercussions +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 @@ -138,8 +206,11 @@ 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} -Each team member is required to send their technical weekly update to Jaro -Rutjes 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. + +Each team member is required to send their technical weekly update to Jaro Rutjes +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 @@ -147,63 +218,82 @@ on what has been accomplished, plans for upcoming work, and an overview of the team's overall progress. \subsection{Weekly Meetings} -The project team will hold at least two meetings each week, with each meeting -lasting a maximum of 30 minutes. Following these meetings, an additional one -hour will be scheduled for discussions on the topics covered. -Meetings will be planned and discussed one week in advance, with invitations -sent via Outlook. Additional meetings may be scheduled if necessary to address -issues or project needs. +The project team will hold at least two meetings each week, with each meeting lasting +a maximum of 30 minutes. Following these meetings, an additional one hour will be +scheduled for discussions on the topics covered. +Meetings will be planned and discussed one week in advance, with invitations sent via +Outlook. Additional meetings may be scheduled if necessary to address issues or +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 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. \subsection{Scrum Board} + The Scrum board \autocite{miro:scrum-board} will consist of the following tabs: + \begin{description} - \item[Backlog]: This tab contains a list of all tasks and user stories that are planned for future sprints. - \item[Next Sprint]: This tab includes tasks and user stories that have been selected for the upcoming sprint. - \item[Current Sprint]: This tab displays the tasks and user stories that are actively being worked on in the current sprint. - \item[In Progress]: Tasks that are actively being worked on are moved to this tab. - \item[Review]: Completed tasks that are awaiting review or testing will be placed in this tab. - \item[Done]: Once tasks have been reviewed and are considered complete, they are moved to the Done tab. - \item [Blocked]: This tab is used for tasks that cannot proceed due to obstacles or dependencies. + \item[Backlog] This tab contains a list of all tasks and user stories that are + planned for future sprints. + \item[Next Sprint] This tab includes tasks and user stories that have been selected + for the upcoming sprint. + \item[Current Sprint] This tab displays the tasks and user stories that are + actively being worked on in the current sprint. + \item[In Progress] Tasks that are actively being worked on are moved to this tab. + \item[Review] Completed tasks that are awaiting review or testing will be placed in + this tab. + \item[Done] Once tasks have been reviewed and are considered complete, they are + moved to the Done tab. + \item [Blocked] This tab is used for tasks that cannot proceed due to obstacles or + dependencies. \end{description} -\noindent 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. - \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}. + \item A task from the \emph{Current Sprint} tab should be selected and moved to the + \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} -\noindent -Each task or user story will be assigned user points, which indicate the relative size or complexity of the task compared to these examples. +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 \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. +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. -% Information regarding the git workflow of this project. Diagram explaining the workflow +% 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 and documentation, each in its own respective repository. -This keeps the documentation and code seperate, resulting in ordened and manageable repositories. -\begin{itemize} - \item Code Repository: crepe \autocite{crepe:code-repo} - \item Documentation Repository: crepe-docs \autocite{crepe:docs-repo} -\end{itemize} + +GitHub is used for version management of both code \autocite{crepe:code-repo} and +documentation \autocite{crepe:docs-repo}, each in its own respective repository. This +keeps the documentation and code seperate, resulting in ordened and manageable +repositories. \subsection{Git New Branch} + % 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}. \end{document} diff --git a/projdoc.cls b/projdoc.cls index cc25e67..c0257ca 100644 --- a/projdoc.cls +++ b/projdoc.cls @@ -119,6 +119,16 @@ itemsep=\dimexpr\style@itemsep-\style@parsep\relax, parsep=\style@parsep, } +\def\projdoc@setdescriptionstyle{% + \renewcommand\makelabel[1]{% + {\bfseries ##1}:% + }% +} +\setdescription{ + before={\projdoc@setdescriptionstyle}, + leftmargin=3em, + labelindent=3ex, +} \makeatother % create a label using \customlabel[]{}{} that displays @@ -213,10 +223,16 @@ \def\projdoc@trailer{ % bibliography (if citations used) \ifbool{projdoc@used@cite}{% + \hfuzz=50pt% reduce overfull hbox warnings for bibliography (mostly URLs) \printbibliography% }{}% % glossary - \ifbool{projdoc@used@cite}{% + \ifbool{projdoc@used@gls}{% + \setdescription{ + before={\projdoc@setdescriptionstyle}, + leftmargin=2ex, + labelindent=0pt, + }% \section*{Glossary}% \begin{multicols}{2}% \renewcommand{\glossarysection}[2][]{}% diff --git a/sources.bib b/sources.bib index 5848f86..50f5ead 100644 --- a/sources.bib +++ b/sources.bib @@ -13,35 +13,35 @@ } @misc{miro:scrum-board, - author = {Jaro Rutjes}, + author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, title = {Scrum Board on Miro}, url = {https://miro.com/app/board/uXjVKjtdM64=/?share_link_id=303851465474}, date = {2024-09-10}, } @misc{crepe:code-repo, - author = {lonkaars}, + author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, title = {Crepe Code Repository}, url = {https://github.com/lonkaars/crepe}, date = {2024-09-10}, } @misc{crepe:docs-repo, - author = {lonkaars}, + author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, title = {Crepe Documentation Repository}, url = {https://github.com/lonkaars}, date = {2024-09-10}, } @misc{crepe:docs-standard, - author = {lonkaars}, + author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, title = {Crepe Documentation Standard}, url = {https://github.com/lonkaars/crepe-docs/blob/master/contributing.md}, date = {2024-09-10}, } @misc{crepe:code-standard, - author = {lonkaars}, + author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, title = {Crepe Code Standard}, url = {https://github.com/lonkaars/crepe/blob/master/contributing.md}, date = {2024-09-10}, -- cgit v1.2.3 From 40f485af1bdcc04477a2cfcb71c899d397d7c6e6 Mon Sep 17 00:00:00 2001 From: Jaro Date: Wed, 18 Sep 2024 19:03:53 +0200 Subject: removed TODO and change some small typos --- plan.tex | 70 +++++++++++++++++++++------------------------------------------- 1 file changed, 23 insertions(+), 47 deletions(-) (limited to 'plan.tex') 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} -- cgit v1.2.3 From 28d0733146aa3a8ba720bda20ff66ffa4cf4e64d Mon Sep 17 00:00:00 2001 From: Jaro Date: Wed, 18 Sep 2024 19:30:48 +0200 Subject: added feedback to project plan --- plan.tex | 5 ++++- sources.bib | 7 +++++++ 2 files changed, 11 insertions(+), 1 deletion(-) (limited to 'plan.tex') diff --git a/plan.tex b/plan.tex index 2f9cc94..147e49c 100644 --- a/plan.tex +++ b/plan.tex @@ -53,7 +53,10 @@ Finally, because the client does not want to dive deeply into the engine himself \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 is 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. The engine may integrate third-party software (as agreed with the client) to support specific features, such as audio, physics, and rendering. In addition, a validation application is created to show and test the engine's features. + +\subsection{Scope} +The requirements document \autocite{crepe:requirements} has several requirements with a MoSCoW `must', `should', `could' or `won't' priority to indicate the project's scope. \subsection{Result} diff --git a/sources.bib b/sources.bib index 50f5ead..8d96ce1 100644 --- a/sources.bib +++ b/sources.bib @@ -47,4 +47,11 @@ date = {2024-09-10}, } +@misc{crepe:requirements, + author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, + title = {Requirements}, + url = {https://github.com/lonkaars/crepe/blob/master/requirements.pdf}, + date = {2024-09-10}, +} + -- cgit v1.2.3 From b5ad864b5f020a73e4e0a068302cd22209f01fbb Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Thu, 19 Sep 2024 17:27:21 +0200 Subject: remove version from documents --- contributing.md | 4 ---- latexmkrc | 2 +- meta.tex | 1 - plan.tex | 8 -------- projdoc.cls | 11 ++++++++--- 5 files changed, 9 insertions(+), 17 deletions(-) (limited to 'plan.tex') diff --git a/contributing.md b/contributing.md index c11c834..db58388 100644 --- a/contributing.md +++ b/contributing.md @@ -2,10 +2,6 @@ This document is an extension of the [crêpe engine contribution guidelines][crepe-engine-contrib]. Rules in this document override those in the other document. -# Versioning - -- TODO: discuss w/ group - # Code style - Indent using tabs diff --git a/latexmkrc b/latexmkrc index 880f859..d2c3cdc 100644 --- a/latexmkrc +++ b/latexmkrc @@ -2,7 +2,7 @@ use File::Spec::Functions; -$pdflatex = "xelatex --interaction=nonstopmode %O %S"; +$pdflatex = "xelatex --interaction=nonstopmode --shell-escape %O %S"; $pdf_mode = 1; $dvi_mode = 0; $postscript_mode = 0; diff --git a/meta.tex b/meta.tex index cad4b81..db7c7b1 100644 --- a/meta.tex +++ b/meta.tex @@ -1,6 +1,5 @@ \organization{Avans University of Applied Sciences} \project{Project cr\^epe} -\version{0.0} \author{% Loek Le Blansch\and% Wouter Boerenkamps\and% diff --git a/plan.tex b/plan.tex index 076ce11..6ebd73a 100644 --- a/plan.tex +++ b/plan.tex @@ -1,15 +1,7 @@ \documentclass{projdoc} \input{meta.tex} -% @Jaro: Zie hieronder -% Version 0.0 seems not right -% I'm also missing a 'version table' -% Shall we use this version system?: -% Version numbers after the comma indicate an interim version and version numbers -% before the comma indicate versions ready for publication - \title{Project Plan} -\version{0.1} \begin{document} \tablestables diff --git a/projdoc.cls b/projdoc.cls index fe6317b..ee94835 100644 --- a/projdoc.cls +++ b/projdoc.cls @@ -164,8 +164,6 @@ \def\project#1{\def\@project{#1}} \let\@organization\relax \def\organization#1{\def\@organization{#1}} -\let\@version\relax -\def\version#1{\def\@version{#1}} \def\@maketitle{% \centering% \parskip=0pt% @@ -195,8 +193,15 @@ }% \vfill\flushright% \par{% - \par{\strut{}Version \@version\strut}% \par{\strut\@date\strut}% + \begingroup% + \endlinechar=\m@ne\everyeof{\noexpand}% + \edef\x{% + \endgroup% + \def\noexpand\commit{\@@input|"git rev-parse --short HEAD" }% + }% + \x% + \par{\strut\footnotesize({\ttfamily\commit})\strut}% }% \par\vspace*{2in}% } -- cgit v1.2.3 From be63aadea11619a08878c25a26b7ccafc6174b53 Mon Sep 17 00:00:00 2001 From: Jaro Date: Thu, 19 Sep 2024 18:10:43 +0200 Subject: added some feedback --- plan.tex | 32 +++++++++++--------------------- sources.bib | 7 +++++++ 2 files changed, 18 insertions(+), 21 deletions(-) (limited to 'plan.tex') diff --git a/plan.tex b/plan.tex index 147e49c..13c487d 100644 --- a/plan.tex +++ b/plan.tex @@ -1,13 +1,6 @@ \documentclass{projdoc} \input{meta.tex} -% @Jaro: Zie hieronder -% Version 0.0 seems not right -% I'm also missing a 'version table' -% Shall we use this version system?: -% Version numbers after the comma indicate an interim version and version numbers -% before the comma indicate versions ready for publication - \title{Project Plan} \version{0.1} @@ -18,19 +11,12 @@ \section{Background} 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 +consists of several courses throughout 20 weeks, which create the basis for this +project. The project focus is on building a game engine using the programming language C++. This document describes the plan of attack for the project. \section{Problem Definition} -% The assignments will be discussed with the project supervisor on specifics for this -% project. This will give the team the ability to direct the project. - -% @Jaro: Ik snap niet wat je met deze zinnen wil zeggen. Het lijkt een soort van -% background information, maar toch niet helemaal ofzo. Hoe dan ook heb ik het er nu -% even uit gehaald en een nieuw kopje background toegevoegd. - \subsection{Problem Analysis} CodedFun Games is a small, single-person game company looking to scale up. The owner, @@ -45,7 +31,7 @@ user-friendly. Additionally, the engine should be well-documented, which is considered an essential aspect of being user-friendly. So far, the client has made all his games in Unity and is very fond of the structure. -Therefore, he wants the new engine to adhere to a similar structure. A simple +Therefore, the client 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. @@ -62,6 +48,10 @@ The requirements document \autocite{crepe:requirements} has several requirements 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. +\subsection{validation application} + +The validation application \autocite{crepe:validation-application} is explained in a document where the features of the validation application are linked to the user stories. + \section{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}. @@ -72,10 +62,9 @@ The customer specified multiple deliverables throughout the 20 weeks of this pro \textbf{Week\#} & \textbf{Deliverable}\\ \midrule 4 & Project Plan\\ - 7 & Requirements document\\ + 7 & POCs\\ 10 & POCs and Design document\\ - 17 & Game engine, Validation application, Research document, and Qualification - document\\ + 17 & Game engine, Validation application\\ \bottomrule \end{tabularx} \caption{Planning} @@ -100,6 +89,7 @@ The customer specified multiple deliverables throughout the 20 weeks of this pro 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. + \item[Falling out of specific team member] Within the team the scrum master and integrator have additional roles. If one or both members can not continue it can hinder progress of the project. \end{description} \subsection{Measures} @@ -113,6 +103,7 @@ The customer specified multiple deliverables throughout the 20 weeks of this pro 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[Falling out of specific team member] The scrum master can be taken over by any other team member. All tools (e.g. scrum board) are open to all members. The tasks of the integrator can be taken over by the team. Within GitHub the team as a whole has the same rights as the integrator. \end{description} \section{Documentation} @@ -128,7 +119,6 @@ This project consists of seven main documents:\noparbreak project, including timelines, milestones, roles, and responsibilities. \item[Requirements] Details the requirements and user stories, including both functional and non-functional requirements. - \item[Research] Consists of all research related to this project. \item[Design] Describes the design choices, including architecture, user interface, and system components. \item[Qualification] Includes test cases, test plans, and quality measures to diff --git a/sources.bib b/sources.bib index 8d96ce1..31262fb 100644 --- a/sources.bib +++ b/sources.bib @@ -54,4 +54,11 @@ date = {2024-09-10}, } +@misc{crepe:validation-application, + author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink}, + title = {Validation Application}, + url = {https://github.com/lonkaars/crepe/blob/master/Validation-Application.pdf}, + date = {2024-09-10}, +} + -- cgit v1.2.3 From 3c6a635c6a8d38aae2284cbe744c060e765968a6 Mon Sep 17 00:00:00 2001 From: Jaro Date: Thu, 19 Sep 2024 18:13:16 +0200 Subject: removed qualification --- plan.tex | 2 -- 1 file changed, 2 deletions(-) (limited to 'plan.tex') diff --git a/plan.tex b/plan.tex index 74f6a2b..54cc9d6 100644 --- a/plan.tex +++ b/plan.tex @@ -120,8 +120,6 @@ This project consists of seven main documents:\noparbreak functional and non-functional requirements. \item[Design] Describes the design choices, including architecture, user interface, and system components. - \item[Qualification] Includes test cases, test plans, and quality measures to - ensure the project meets its requirements and standards. \item[Working hours] A table which includes all working hours of each team member. \item[API Reference] Details the available endpoints, request and response formats, authentication methods, error codes, and examples for interacting with the -- cgit v1.2.3 From 23ceaf0edc1db82240740dbcc6d305d1e10726c8 Mon Sep 17 00:00:00 2001 From: Jaro Date: Thu, 19 Sep 2024 18:37:07 +0200 Subject: changed role max --- plan.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'plan.tex') diff --git a/plan.tex b/plan.tex index 54cc9d6..a1cbb15 100644 --- a/plan.tex +++ b/plan.tex @@ -145,7 +145,7 @@ reviewed and agreed to these terms. \item[Loek Le Blansch] Integrator \item[Wouter Boerenkamps] Project Member \item[Jaro Rutjes] Team Leader / Scrum Master - \item[Max Smits] Project Member + \item[Max Smits] Project Member / Product owner \item[Niels Stunnebrink] Project Member \end{description} -- cgit v1.2.3 From 77c9588359df6a72097e46074b1ff14f80350285 Mon Sep 17 00:00:00 2001 From: heavydemon21 Date: Thu, 19 Sep 2024 20:02:17 +0200 Subject: Read through the plan.tex and fixed some issues --- plan.tex | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'plan.tex') diff --git a/plan.tex b/plan.tex index a1cbb15..11d8d41 100644 --- a/plan.tex +++ b/plan.tex @@ -72,10 +72,10 @@ The customer specified multiple deliverables throughout the 20 weeks of this pro \section{Risks} -\subsection{Techincal Risks} +\subsection{Technical Risks} \begin{description} - \item[Multiplatform] The team works in both linux and windows, which poses a risk + \item[Multiplatform] The team works in both Linux and windows, which poses a risk for the development if there is a platform dependency. \item[Integration] Users can make a wrong integration causing for delay or risk of losing code. @@ -95,9 +95,9 @@ The customer specified multiple deliverables throughout the 20 weeks of this pro \begin{description} \item[Multiplatform] The team can switch any time to a single platform, so this - risk is metigated. + risk is mitigated. \item[Integration] By following standards and having an integrator, which checks - every pull request, this risk is minimilised. + every pull request, this risk is minimized. \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. @@ -209,7 +209,7 @@ project needs. % Information about how and when Scrum will be used in this project (using Miro). \section{Scrum (Miro)} -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. +The team starts using scrum after the initial phase, of structuring the project, is finished. This phase is finished after a initial design of the product is made. \subsection{Scrum Board} @@ -255,7 +255,7 @@ Burn Down Chart is shared in the weekly updates with the team. GitHub is used for version management of both code \autocite{crepe:code-repo} and documentation \autocite{crepe:docs-repo}, each in its own respective repository. This -keeps the documentation and code seperate, resulting in ordened and manageable +keeps the documentation and code separate, resulting in ordered and manageable repositories. \subsection{Code Standard and git workflow} -- cgit v1.2.3 From dcd17e39494010e3696f8e6b935e2da1d63ea37a Mon Sep 17 00:00:00 2001 From: Max-001 <80035972+Max-001@users.noreply.github.com> Date: Fri, 20 Sep 2024 10:22:07 +0200 Subject: Corrected cappital letters --- plan.tex | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) (limited to 'plan.tex') diff --git a/plan.tex b/plan.tex index 11d8d41..55707ce 100644 --- a/plan.tex +++ b/plan.tex @@ -47,7 +47,7 @@ The requirements document \autocite{crepe:requirements} has several requirements 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. -\subsection{validation application} +\subsection{Validation Application} The validation application \autocite{crepe:validation-application} is explained in a document where the features of the validation application are linked to the user stories. @@ -61,7 +61,7 @@ The customer specified multiple deliverables throughout the 20 weeks of this pro \textbf{Week\#} & \textbf{Deliverable}\\ \midrule 4 & Project Plan\\ - 7 & POCs\\ + 7 & Some POCs\\ 10 & POCs and Design document\\ 17 & Game engine, Validation application\\ \bottomrule @@ -139,7 +139,7 @@ protocols for handling absences or delays, guidelines for addressing inconsisten participation, and procedures for weekly updates and meetings. All team members reviewed and agreed to these terms. -\subsection{Project roles} +\subsection{Project Roles} \begin{description} \item[Loek Le Blansch] Integrator @@ -149,18 +149,18 @@ reviewed and agreed to these terms. \item[Niels Stunnebrink] Project Member \end{description} -\subsection{Work hours} +\subsection{Work Hours} Each project member will keep track of their own working hours and add them to the `file'. -\subsection{Absence or delay} +\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 should be informed of the absence as well. -\subsection{Inconsistent participation} +\subsection{Inconsistent Participation} Inconsistent participation will be addressed in a structured manner: @@ -258,7 +258,7 @@ documentation \autocite{crepe:docs-repo}, each in its own respective repository. keeps the documentation and code separate, resulting in ordered and manageable repositories. -\subsection{Code Standard and git workflow} +\subsection{Code Standard and Git Workflow} The code standard and the git workflow can be found in the contributing.md \autocite{crepe:code-standard}. -- cgit v1.2.3 From f55937c99dfdd08d89d3d7db24780d42b9f4ea75 Mon Sep 17 00:00:00 2001 From: Max-001 <80035972+Max-001@users.noreply.github.com> Date: Fri, 20 Sep 2024 12:03:16 +0200 Subject: Last minor changes --- plan.tex | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'plan.tex') diff --git a/plan.tex b/plan.tex index 55707ce..c439aa7 100644 --- a/plan.tex +++ b/plan.tex @@ -38,18 +38,18 @@ Finally, because the client does not want to dive deeply into the engine himself \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. The engine may integrate third-party software (as agreed with the client) to support specific features, such as audio, physics, and rendering. In addition, a validation application is 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. The engine may integrate third-party software (as agreed with the client) to support specific features, such as audio, physics, and rendering. In addition, a \emph{validation application} is created to show and test the engine's features. \subsection{Scope} The requirements document \autocite{crepe:requirements} has several requirements with a MoSCoW `must', `should', `could' or `won't' priority to indicate the project's scope. \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 \emph{validation application} should be provided to test and showcase the engine's capabilities. \subsection{Validation Application} -The validation application \autocite{crepe:validation-application} is explained in a document where the features of the validation application are linked to the user stories. +The \emph{validation application} \autocite{crepe:validation-application} is explained in a document where the features of the \emph{validation application} are linked to the user stories. \section{Planning} @@ -63,7 +63,7 @@ The customer specified multiple deliverables throughout the 20 weeks of this pro 4 & Project Plan\\ 7 & Some POCs\\ 10 & POCs and Design document\\ - 17 & Game engine, Validation application\\ + 17 & Game engine, \emph{validation application}\\ \bottomrule \end{tabularx} \caption{Planning} @@ -145,7 +145,7 @@ reviewed and agreed to these terms. \item[Loek Le Blansch] Integrator \item[Wouter Boerenkamps] Project Member \item[Jaro Rutjes] Team Leader / Scrum Master - \item[Max Smits] Project Member / Product owner + \item[Max Smits] Project Member / Product Owner \item[Niels Stunnebrink] Project Member \end{description} -- cgit v1.2.3 From 6329755a372d90985bda1cd164fae8d91d4a60c6 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Thu, 26 Sep 2024 15:50:58 +0200 Subject: remove meta.tex and just set defaults directly in projdoc.cls --- example.tex | 1 - meta.tex | 9 --------- plan.tex | 1 - projdoc.cls | 15 +++++++++++++-- requirements.tex | 1 - research.tex | 1 - timerep.tex | 1 - 7 files changed, 13 insertions(+), 16 deletions(-) delete mode 100644 meta.tex (limited to 'plan.tex') diff --git a/example.tex b/example.tex index 24c525b..9f36f59 100644 --- a/example.tex +++ b/example.tex @@ -1,7 +1,6 @@ \documentclass{projdoc} % if the document compiles too slow (likely due to many/large images), try compiling % with the [draft] option. this replaces all images with placeholders. -\input{meta.tex} \title{Example Document} diff --git a/meta.tex b/meta.tex deleted file mode 100644 index db7c7b1..0000000 --- a/meta.tex +++ /dev/null @@ -1,9 +0,0 @@ -\organization{Avans University of Applied Sciences} -\project{Project cr\^epe} -\author{% - Loek Le Blansch\and% - Wouter Boerenkamps\and% - Jaro Rutjes\and% - Max Smits\and% - Niels Stunnebrink% -} diff --git a/plan.tex b/plan.tex index c439aa7..a67598e 100644 --- a/plan.tex +++ b/plan.tex @@ -1,5 +1,4 @@ \documentclass{projdoc} -\input{meta.tex} \title{Project Plan} diff --git a/projdoc.cls b/projdoc.cls index 16b1790..8a2c05d 100644 --- a/projdoc.cls +++ b/projdoc.cls @@ -1,6 +1,19 @@ \NeedsTeXFormat{LaTeX2e} \ProvidesClass{projdoc}[2024-09-03 class projdoc] +% project defaults +\makeatletter +\def\@project{Project cr\^epe} +\def\@organization{Avans University of Applied Sciences} +\def\@author{% + Loek Le Blansch\and% + Wouter Boerenkamps\and% + Jaro Rutjes\and% + Max Smits\and% + Niels Stunnebrink% +} +\makeatother + % based on article \LoadClass{article} @@ -160,9 +173,7 @@ % \maketitle format \makeatletter -\let\@project\relax \def\project#1{\def\@project{#1}} -\let\@organization\relax \def\organization#1{\def\@organization{#1}} \def\@maketitle{% \centering% diff --git a/requirements.tex b/requirements.tex index be0e103..6b4a87a 100644 --- a/requirements.tex +++ b/requirements.tex @@ -1,5 +1,4 @@ \documentclass{projdoc} -\input{meta.tex} \makeatletter \projdoc@description@leftmargin=2ex diff --git a/research.tex b/research.tex index 228f3ac..5aa7c4f 100644 --- a/research.tex +++ b/research.tex @@ -1,5 +1,4 @@ \documentclass{projdoc} -\input{meta.tex} \title{Research document} diff --git a/timerep.tex b/timerep.tex index 7590217..34a30ea 100644 --- a/timerep.tex +++ b/timerep.tex @@ -1,5 +1,4 @@ \documentclass{projdoc} -\input{meta.tex} \title{Time Report} -- cgit v1.2.3