diff options
| -rw-r--r-- | plan.tex | 204 | ||||
| -rw-r--r-- | sources.bib | 36 |
2 files changed, 239 insertions, 1 deletions
@@ -4,6 +4,208 @@ \title{Project Plan} \begin{document} -hoi + +\tablestables +\newpage + +\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. + +\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. + + + +\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 + + + +\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. +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. + +% 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:\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[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[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} +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} + + +\subsection{Work Hours} +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 +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 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. + +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 + 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. + +\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. + + + +% 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. + +\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. +\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}. +\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. + + +% 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: 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. +\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}, +} + + |