Project End Report

0. Table of contents

• 1. INTRODUCTION
• 2. ASSIGNMENT, TARGET AND RESULTS
• 2.1. Overview of the project
• 2.2. Success of the project (plan versus result)
• 3. PROBLEMS AND SOLUTIONS
• 3.1. Problems during planning
• 3.2. Problems during implementation
• 4. SUMMARY
• 4.1. Self-evaluation
  • 4.1.1. Group work
  • 4.1.2. Planning the project work
  • 4.1.3. Interaction
  • 4.1.4. Attitude
  • 4.1.5. Result

1 INTRODUCTION

This end report is about the Overflow virtual company's 2021 WIMMA Lab assignment, the "FF Marketplace" service. The projects client was Jamk Future Factory, Mikko Keskinen acted as a main contact person and Heli Vepsäläinen was guiding character from FF team. In addition, Kari Pitkäniemi, Teemu Kontio, Paavo Nelimarkka and Marko "NarsuMan" Rintamäki act as guiding characters in the WIMMA Lab.

Overflow consisted of six engineering students from JAMK's IT Institute:

Name	Main role	Responsibility
Reetta Laitinen	Team leader	Project manager tasks, cybersecurity and Web Application security, developing
Joel Aalto	Technical leader	Technical leading, Backend developing, developing, Power Automate
Jesse Rissanen	Security	Cybersecurity and Web Application security, developing
Samu Vesiluoma	Software Developer	Backend developing, developing
Lassi Viitakoski	Front-End developer	Frontend developing, developing
Mikko Fredrikson	Test automation	Frontend developing, developing, testing tasks

The purpose of this document is to tell about the progress and results of the project.

2 ASSIGNMENT, TARGET AND RESULTS

2.1 Overview of the project

Project was about to do a "team building service" for the Future Factory: purpose of the software was to make it easier to cather team members to a assingment. The end users will be students, and coaches who will add assignments to the service. Our Requirement specification was mostly written based on these users (of course there is also other stakeholders but they don't use our service in this version, or at all).

Main functionalities/features, we wanted on the version 1:

• Multilingual: FI/EN
• Coaches can add projects: they fill a form on the service
• Assingment filtering by field, role and position
• Assignment sorting
• Student identification when adding him/herself to assingment and its role.
• The front page shows almost full teams: trying to get faster teams full
• Coaches have own admin panel to FF Marketplace: when login they can add and modify assignments
• Power automate flow gets the team data after assignment teams are filled

FF Martketplace -project was done by taking advantage of the following technologies:

• Microsoft Power Automate: The idea was that using Power Automate in some parts would be a nice addition.
• Kubernetes & Gitlab CI/CD: Service (backend's and frontend's containers) was meant to be put running on Kubernetes, while utilizing gitlab CI/CD pipelines. Mysticons was the expert of this thing and they gave us guidance.
• React: React was familiar to several team members and is a workable language, so we used it on the Frontend.
• .NET Core: .NET Core was also familiar to several team members, so we used it on the Backend.
• PostgreSQL: We chose PostgreSQL for the database because it is quick to set up and easy to use.
• Cypress: At first we planned to do tests using Robotframework but we switched it to Cypress because with Cypress it is, among other things, very easy to perform tests.

In addition, a test plan and tests were built around the product. And also we wrote documentations so especially the one who continues the project knows what we have done and where to continue.

2.2 Success of the project (plan versus result)

The project started in 17th of May and ended in 30th of July. The work was divided into eight sprints, which length were 1-2 weeks. The tasks were planned at the beginning of the sprint to suit the situation and need. The progress of the work was monitored mainly with the Gitlab issue tool.

After the orientation week, the first two-three sprints were spent on doing requirement specification, familiarizing with technologies, listening different visitor presentations and preparing material (e.g Mockup) for the Avoimet ovet 2021 -event. We were able to start the implementation of the product itself on the third sprint.

There were a little difficulties in planning the sprints but mostly they went okay. Sometimes our sprint plan was good but because there came some unexpexted challenges and problems, we needed to rethink our plan or move some issues to the next sprint.

Because of the challenges and problems, which took up the working time, we could not add all the wanted functionalities/features to our first version of the product. But we managed to cope well with the different challenges of the project and most importantly we learned something new and improved our existing skills.

3 PROBLEMS AND SOLUTIONS

3.1 Problems during planning

There was alot wishes for the service from Jamk Future Factory. Due to Wimma Lab lasting only 2,5 months, we came to a conclusion that trying to implement all the wishes wouldn't be possible in the timeframe of Wimma Lab. So, we decided to build such an implementation of the service that could be continued by some other developer.

During the planning phase we had some minor concerns with GDPR: could we implement a service without storing any personal data of the students in the service. On the other hand, the client (Jamk Future Factory) had a thought of having the possibility for adding the option for logging in to the service by using Haka-login, which is used by Jamk on some other occasions. We also thought of Haka-login ourselves prior to the clients wishes, because if students would want to cancel a chosen team position before the start of the course, the service would have to store some information of the students.

However, to get all the permissions needed to operate with Haka would've taken too long, so we had to come up with some other solution. We also didn't have any prior experience working with Haka, so implementing it into our service might've have been too hard anyway. We also wouldn't have the time, or would it make any sense, to build our own authentication service.

We ended up implementing a "ready made" authentication solution that would make integrating Haka-login to the service easier. Haka uses SAML 2.0 as does our chosen authentication solution (Keycloak). SAML 2.0 related things have been added to the backend, which should make transferring to Haka in the future easier.

We would like the Haka-login to be added to the service later, so the students wouldn't have to manage so many different credentials.

We also thought of implementing a privacy policy for practice, but we didn't have the time for it as we prioritized other things instead.

We had to make changes on some of our plans because of problems be faced and couldn't solve them.

3.2 Problems during implementation

At the beginning of the implementation everything went great, but then there came a few cases we needed to change: e.g. we needed to change database architecture few times because we realized we had forgotten things or there would have been a few contradictions. There came some situations were we had to stop and rethink how we progress.

Maybe the biggest problem/challenge was the when adding the autentication service. First we planned and tested it with Keycloak because it supports SAML2.0. We added Saml2.0 codes to backend but it was pretty difficult because there were few guides to do it with .Net Core. We tried to make Keycloak work with our backend, but after several attempts we did not progress. Then we changed Keycloak to Okta (developer). It made some progress. Authentication kind of worked but it still was somehow broken. We had spent a lot of time on this and because we did not reach a good solution and our working time was decreasing, we had to prioritize other things over this. But to test the flow of the service's usage, we added a textbox to frontend when you select a team member place: you add your student email and press send, and then that information goes to backend. So now we can test the usage flow and especially when team is full, we can see that our Power Automate flow works.

There were a few bugs we found when we tested the application by hand or with tests we made with Cypress. We fixed those bugs. There were some issues with frontend's scalability but after all our frontend developer Lassi found a solution to it.

We decided to do Admin-frontend after sprint 3. When we had done the plan (mockup) for the admin-frontend, we started coding it. We got conding help from Pengwin Media. Most of it was simple to code but there came some bigger implementation challenges when coding the form, especially when coding the "give the number of team members and then add roles for the team members". After a few days of deliberation and testing with new technologies or packages, admin-frontend programmers obtained it to work.

We had to add our frontends and backend containers on Kubernetes with working CI/CD pipeline (this was an extra thing to do when talking about the project, but to us as WIMMA Lab trainees it was kind of mandatory). Mysticons (one of the WIMMA Lab virtual company) instructed us, but when doing tgis there came many errors in different phases. They took a lot time, but we solved them, sometimes with help from Mysticons or from other teams teammembers who were resbonsible on Kubernetes.

4 SUMMARY

4.1 Self-evaluation

4.1.1 Group work

• Project management (not personalized, but on general level): There were one team leader and one technical leader when project management was a little bit divided: team leader took care of the big picture and technical leader was more knowledgeable about the project's technical sides. The team leading was kind of new for the leader mamber so there might been happened small project management errors.

• Utilizing diversity: When planning the product, everyone has been able to express their own ideas and views. The division of tasks has also been planned in such a way that we divided the tasks to those who had most knownledge for that topic. But also we gave us the opportunity to learn new things and get to try them.

• Problem solving (not limited to technical, other problems too, e.g. communication): When there came problems, first we tried to resolve the issue independently or with smaller group (2-3 members of our team) by retrieving the necessary information from the internet. If could not solve the problem, then whole team tried to figure it out. If the team didn’t come up with a solution or if we knew someone would know the solution, we asked help from other teams. Now, at the latest, the problems were solved.

• Division of workload and management of tasks: Due to the programming-oriented nature of the project, some team members had not much or none programming skills therefore there might have been more work to those who had skills on programming. So there have been moments when the work is unevenly distributed. Sometimes it was difficult to do the issues for the sprint so there might have been moments where there was not enough things to do or was too much things to do.

• Groups own work: The team has done a great job over the summer. Although there has been a change in the original plan due to challenges and problems, we were able to put together a good, working base for the software. There is a lot of evidence of good skills and technologies in the end result.

• Work by others (support group activities etc.): Communication between different virtual companies has played an important role in in making project. Other groups have provided very useful knowledge and skill. We got help with Mockup and frontend-admin coding from Pengwin Media, and from all teams we got help with our issues with the Kubernetes cluster.

• Utilization of resources (what are your resources?): Had no money to use (no budget). Human resources have been used.

• Guidance and its utilization (did you receive guidance from others than your own supervisor?): We received some guidance from our supervisor and coaches but also from other teams. But maybe there should have been a little more guidance. Because of the summer vacation it was more difficult to get help.

• Group process (from individuals to team, evolution): There were no problems on teaming up. We had a good team spirit from the very first weeks.

• Crisis and management: we managed to avoid the worst crises that could have prevented the project from progressing. Authentication case caused a small.

4.1.2 Planning the project work

Approximately the first three weeks from the start of Wimma Lab were used for planning the service. At first, we did requirement specifications, defined stakeholders and user profiles. For our main "target audience" we defined the students of the Future Factory course and the coaches/instructors. We made user stories and based on those we created different issues.

At the start of the sprints we held a sprint planning session, where we chose what features we would start working on. We tried to give time estimates to the issues we were going to work on, but this was rather difficult to estimate or we completely forgot to add estimates.

4.1.3 Interaction

With client

We communicated with Mikko Keskinen via email and teams. We have had three meeting calls in total. On one meeting there were also Satu Aksovaara from Future Factory team. We tried to reach her after meeting because we had a question for her but we were left without an answer.

We have had few meetings with Heli Vepsäläinen and got there some good informations. She also arranged the meetings with Keskinen on our behalf. Heli tried to reach Mikko for a meeting in July but she was left without an answer.

Acquisition of information

In the beginning, we communicated well with the client and received feedback and requirements, but towards the end the amount of communication has decreased to zero.

Interaction with Marko Rintamäki and Jarmo Nevala about authentication and GDPR

We had also meetings with Marko Rintamäki where he gave us some ideas about the project and the authentication solutions.

We also reached Jarmo Nevala about the GDPR and privacy policy: we asked him some info about these and what things to consider when making privacy policy.

We had planned to reach the Jamk's Tietosuojavastaava but we had no time to do that (we had to prioritize other things).

4.1.4 Attitude

The attitude towards the project was mostly good. The attitude towards the project was usually effected by the type of the task: technologies and work tasks were quite free to choose but some of the tasks may not have been so pleasant to do. Each team member had a desire to learn new things as well as to get to improve already existing skills.

The project's topic was very wide, and the two and half month was too little time to get the product to in such a condition that it could have been used as early as the fall. But we decided to try our best and try to do some kind of version 1 of the product.

There were many problems and challenges but not too much stress was taken from them. The attitude to solve them was optimistic.

At the beginning of the project, all team members were actively involved in planning. In the actual implementation phase (started coding) the attitude was really good and the work was done diligently. Towards the end, a slight decrease in motivation began to occur: there were so much to do and some of the planned things did not succeed or we did not have enough time so we had to leave them out. Motivation was varying in making the documentation.

Feedback: we did not ask feedback, only little in the beginning of the work when we had meetings with Mikko Keskinen. Perhaps it would have been worth of asking the feedback from other student, for example. We did not reach Mikko Keskinen in the end stages.

4.1.5 Result

We managed to make a good, development level FF Marketplace -software during the summer. Unfortunately, the service does not currently have the authentication but there is this textbox for giving an email when choosing a team spot which can be used for testing the flow of the service.

We have now - Backend running on Kubernetes & Gitlab CI/CD solution that automates code building, testing, and deployment. - Frontend running on Kubernetes & Gitlab CI/CD solution that automates code building, testing, and deployment. - Admin-frontend docker container running on virtual machine - Database running on virtual machine (on the same subnet with backend and frontend)

The functionalities/features we have now:

• Multilingual: FI/EN, need to add more text in english and also some information in finnish.
• Coaches can add projects: they fill a form on the admin-frontend.
• Assingment filtering by field, role and position works.
• Assignment sorting works.
• Coaches have own admin panel to FF Marketplace: they can add and delete assignments.
• The front page shows almost full teams.
• Power automate flow gets the team data after assignment teams are filled
• Textbox for email when choosing a team spot (used for testing the flow of the service).

What we did not manage make into version 1:

• Student identification when adding him/herself to assingment and its role: because there is no authentication, we cannot exactly identify the user.
• Admin panel have no authentication yet.
• Coaches cannot modify the assignment: we did not have enough time to do this.
• Registry description and other these things.

Our team learned new technologies as well as project and teamwork skills.

Here you can go check some captures from our end result: FF Marketplace - end result

Follow-ups

FF marketplace -service's development may be continued by another doers.