Project End Report

1 INTRODUCTION

This page is the end report of Future 16's Tukko - Traffic Visualizer 1.1 project. Future 16 is a team of five second-year IT students working on Jamk's Future Factory IT 2024 project course. Future 16 along with 22 other teams were tasked to work on a traffic visualizer app called Tukko (created by IoTitude in 2023) and update the app with new features and improvements which was the main target of this project. This document covers the main areas of this project, what was done succesfully, what failed, how problems were overcome and what was learned.

2 ASSIGNMENT, TARGET AND RESULTS

2.1 Overview of the project

Outcome of the project based on the project objectives and assignments:

Goal of the project was to make a better version of Tukko app and learn more about managing a project in gitlab. Developing web application was also a huge part of the project and making a new features into it.
Our team made a couple features to enhance Tukko app. Most complex one was a authentication system which allowed to registering users to application and login with them. Users were saved to our mongo database. We made dark mode feature better and gave a new refresh to tukkos user interface. We also setup a gitlab ci-cd pipelines, security dashboards and audited that our code was secure.
We managed to implement features successfully into Tukko and learned a lot during that. Pipelines were also successfully setup, which saved us a lot of time.

2.2 Success of the project (plan versus result)

Structure: Projects structure had 4 phases and 7 sprints. First we had to plan and design our project. It involved making a communication plan, risk management plan, project plan and requirement specification. We had about 3 weeks to do that. Then we moved to Design/Implementation/Testing phases. That was when we worked with Tukko app and prepared to be presentated in demo day. 4 weeks was reserved for those phases.
Time management and resources: Sprint was 7 day span and we worked 2 days a week with team. Everyone had their own role and part in team. Tasks were given according to your role and everyone managed to their own part.
External resources: We had mentors which we could ask help and they also gave us a material.

3 PROBLEMS AND SOLUTIONS

Most of the problems faced by the team were technical or were related to the lack of knowledge on some topics. Most technical problems related to programming new features in Tukko.

3.1 Problems during planning

During planning there were a few problems with trying to figure out the size and needed work for the features. We weren't sure how many features we should pick. This was simply solved by taking a few features and seeing how much effort they took and seeing if we needed to take a few features later. The initial features were enough and we didn't take any extra.

Some of the topics of the course were a little bit foggy and at first created difficulties in planning. As the course went on these details became clearer.

3.2 Problems during implementation

Getting the Tukko application running locally was challenging as it required knowledge of Docker and some background info on setting up the app. This was solved by simply researching on the topic.

Getting the Tukko frontend to connect to the backend also gave some headache since it required the manipulation of the env-file. The solution was to change the backend url variable into the localhost ip and the 3001 port.

Robot framework gave some difficulties at first since it wouldn't run on the virtual machine.

Features also gave some headaches as they generally required a lot of fixing and trial and error.

3.3 Other problems, realized risks and their processing

One of our members wasn't active and didn't communicate a lot, but he later left. This didn't create much of a problem since he didn't have many responsibilites to begin with and the team was still five members strong.

4 SUMMARY

4.1 Most important learnings

Learned assets * Csc * Docker * React * TypeScript * Redis * Frontend & backend & docker compatibility * Robot framework * CI/CD configuration * Ci.yml

Also learned more about agile IT project management and practices, software testing, full stack development and security measurements.

4.2 Self-evaluation

Evaluate the following:

4.2.1 Group work

Project management was done on Gitlab's project repository that had all team members joined. Gitlab's issues, issue board and milestones were utilized as time management and tasks/task instructions on what to do. They were the main resources for tracking progress. Since most problems were technical, they were solved by communicating on the team's Discord channel and co-operating together to fix the problem. Future 16 was somewhat individualistic during implementation phase as most members did not ask for help on Discord's support section often and everyone seemed to work on the selected features on their own. But everyone was still on track on what others had achieved during the week. Future 16 did not face any type of crisis.

4.2.2 Planning the project work

Planning for the project was done mainly with the help of Gitlab issues and the issue board. The issue board made it easy to visualize the project's sprints and the steps each for each of the sprints. Most of the issues in the issue board were minor tasks, but we also included user stories and features in the issues. The OPF-framework was also used for easy access to documents. The team worked actively on the planning part of the project and the outcome was good. Estimating the workload of certain issues were never really touched on, but this didn't hinder the project. All of the planned features didn't end being implemented meaning that there was a slight over-estimation on the team's capabilities.

4.2.3 Interaction

Communication with stakeholders was mainly done through Future Factory IT 2024's Discord channel's support sections. The stakeholders present were mainly Gofore mentors, product owner, scrum master and coaches. Acquiring information from the client was done by our scrum master who presented it through regular meetings on Zoom and it was updated on Future Factory's site. At every sprint review a few randomly selected teams were always intervieved to present their progress and work, however Future 16 was never chosen for these interviews. Communication with other members was very effective on Discord as it was quick and handy.

4.2.4 Attitude

The general attitude towards the project's task was that it is all about learning and gaining project work experience. Future 16 always had team members who were aware of the project's state and could manage it under control at all times. On the other hand at times there was a lot of misunderstanding and confusion due to the unclear instructions on certain documents, tickets and by the scrum master. Feedback was non-existent because Future 16 was never chosen to be interviewed on sprint reviews and no one filled Future 16's demo day feedback form. But nonetheless Future 16 kept working and progressing on the project.

4.2.5 Result

Future 16 managed to deliver Tukko 1.1 that contains new features and general improvements as well as a few bug fixes. These are: - Secure user account authentication - Improved dark mode colors - Jamk and Future 16 branding - Secure coding practices for developers - Security issues migitated on GitLab dashboard - CI/CD pipeline for automatic testing (frontend and backend) - Fixed Leaflet map attribution links - Fixed clusters not changing color dynamically on dark mode toggle

And obviously Future 16 delivered a solid project documentation repository that contains all the information about the team and what they worked on. Future 16 also presented some of the work on their home web page which took time and effort to make.

4.3 Suggested grades

What grades do you think you earned based on the above criteria? You can suggest different grades to each team member based on achievements and activity, for example the key players should get better grades than those who barely worked at all.