1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
|
\documentclass{projdoc}
\input{meta.tex}
\title{Project Plan}
\begin{document}
\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}
|