From 4bceae124b7dcb7592c1c6244516e8423c4ccc90 Mon Sep 17 00:00:00 2001 From: Silvan Kisseleff <silvan.kisseleff@gmail.com> Date: Thu, 19 Dec 2024 10:29:47 +0100 Subject: [PATCH 1/2] changed chapters --- docs/sections/06_project_plan.typ | 22 +++++++++------------- 1 file changed, 9 insertions(+), 13 deletions(-) diff --git a/docs/sections/06_project_plan.typ b/docs/sections/06_project_plan.typ index 4826802..b76bc8b 100644 --- a/docs/sections/06_project_plan.typ +++ b/docs/sections/06_project_plan.typ @@ -210,13 +210,14 @@ As defined in Scrum we will work in different iterations called sprints. Each sp caption: [Meetings] ) -#pagebreak() +== Assistance -== Risk management +For this project, we received valuable guidance from our advisor, Olaf Zimmermann. He provided insights into defining a strong MVP, offered advice on writing a technical document, assisted with user testing, and gave highly useful feedback on the application, its setup, and our tutorials. +Additionally, Mathias Lenz conducted a code review, during which he highlighted potential improvements for both our project setup and codebase. -To avoid failure we want to identify risks and find solutions for them. +#pagebreak() -=== Risks += Risks We identified the following risks for our project: @@ -231,7 +232,7 @@ We identified the following risks for our project: - *Unexpected vulnerabilities appear*: When working with web technologies there are always security issues that can appear. It could be crucial if a new security vulnerability would appear. -=== Risk matrix +== Risk matrix Probability and Severity are rated on a scale of one to five (with five being the highest). The Risk level is then calculated as the product of probability and severity. Below the table you will find the explanation of the given ratings. The Risk Level reach from a minimum of five to the maximum of 25. We have grouped the Risk Level in the following categories. (0-4) Very low @@ -273,7 +274,7 @@ Probability and Severity are rated on a scale of one to five (with five being th - *Likelihood:* Major vulnerabilities do not appear that often without any possible near time solutions, thus a vulnerability that has a major impact are not that likely with a well aged platform like NodeJS. (2) - *Impact:* Most vulnerabilities have a mitigation and thus can be resolved. The main goal of this project is not a safe development but rather a rapid development, which can sometimes compromise full security. (2) -=== Countermeasures +== Countermeasures The following countermeasures have been taken to minimize the risk. (residual risk) @@ -287,7 +288,7 @@ The following countermeasures have been taken to minimize the risk. (residual ri - *Unexpected vulnerabilities appear:* For the duration of the project we will keep our libraries up to date to the newest released version ensuring that the project is up to date. This reduces the risk a little bit. (2) -=== Residual Risk +== Residual Risk #figure( table( @@ -302,7 +303,7 @@ The following countermeasures have been taken to minimize the risk. (residual ri caption: [Residual risk matrix] ) -=== Updated risk +== Updated risk We created the tutorials and the application and could test the efficiency of the tooling, and of extending the application. The libraries we are working with are still actively maintained and our edge cases could be implemented. Thus we update the risk matrix to the its final remaining risk. @@ -330,11 +331,6 @@ We created the tutorials and the application and could test the efficiency of th - *Unexpected vulnerabilities appear:* During the development no major vulnerabilities were reported on the used libraries and we updated to the newest available version at the end of the project. (1) -== Assistance - -For this project, we received valuable guidance from our advisor, Olaf Zimmermann. He provided insights into defining a strong MVP, offered advice on writing a technical document, assisted with user testing, and gave highly useful feedback on the application, its setup, and our tutorials. -Additionally, Mathias Lenz conducted a code review, during which he highlighted potential improvements for both our project setup and codebase. - = Personal report In this chapter we document our own reflection of this project and how it went for the individuals. -- GitLab From 10595f26dd2d28765cc8b367208b3034f750f32e Mon Sep 17 00:00:00 2001 From: Silvan Kisseleff <silvan.kisseleff@gmail.com> Date: Thu, 19 Dec 2024 10:32:02 +0100 Subject: [PATCH 2/2] write out sep --- docs/sections/06_project_plan.typ | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/sections/06_project_plan.typ b/docs/sections/06_project_plan.typ index b76bc8b..0c9dfa6 100644 --- a/docs/sections/06_project_plan.typ +++ b/docs/sections/06_project_plan.typ @@ -12,7 +12,7 @@ For Collaboration, we chose *SCRUM+* which is a mix of RUP (Rational Unified Pro === Implementation of SCRUM+ We implemented our SCRUM+ process predominantly in Jira. We created Epics for all RUP phases and linked work items to them. The timeline is generated based on the Epics and contains also the milestones and planned sprints. All items are stored in the backlog. The content for each sprint is planned based on the backlog. The sprint board contains all items planned for this sprint. In the following image is the workflow of a story/item shown. \ -The SCRUM+ process was introduced in the course SEP2 @sep2. +The SCRUM+ process was introduced in the course "Software Engineering Practices 2" @sep2. #figure( image("../images/scrum_plus.png", width: 100%), caption: [ -- GitLab