Skip to content

IoTitude's Project End Report
Document IoTitude's Project End Report
Author: Reima Parviainen
Version: 1.0
Date: 23.07.2023

1 INTRODUCTION

This is an end report for Tukko - Traffic Visualizer which was made by team IoTitude at WIMMA Lab 2023. WIMMA Lab took place between 15.05.-27.07.2023. During these 10 weeks, our team managed to build a web application called Tukko. This project was commissioned by IoTitude's customer Combitech Oy. The application was commissioned as a proof-of-concept so it didn't have a strict target group or use cases. On top of this IoTitude was commissioned another smaller project SKILL-db API from Marko Rintamäki.

Team IoTitude consists of seven Jyväskylä University of Applied Science's ICT students. Reima Parviainen was chosen to be the team leader but the other members had no specified role before the orientation week. During the team building process, the team discussed what each member knew the best and what they wanted to learn during WIMMA Lab. Along the discussions, everyone found their natural role in the team. Alan Ousi and Otto Nordling were assigned as testers for this project but they took part in the development too. The testers worked with multiple libraries like Robot Framework to mention one. Hai Nguyen and Ilia Chichkanov were assigned to the backend development of Tukko and worked with Docker, MongoDB and Redis. Olli Kainu was specifically chosen for frontend development. Justus Hänninen's role was to be a lead for the developers as he worked with both backend and frontend stuff and handled the Git management. Everyone got to do a bit of everything during this project.

There were a lot of new topics in the project the team had to either start learning from scratch or at least refresh their knowledge about the topic. Most importantly everyone had to learn to work in a team environment. A crucial part of this project proved to be good communication inside the team and good practices in repository management. On the technological side, there were a lot of new topics to learn. The tech stack included React, TypeScript, Docker, Node.js, Redis, MongoDB and Nginx. React was specifically asked by Combitech as it suits their needs as a company.

The team managed to deliver a well-documented and robust web application that fulfills most of the requirements specified in the Requirement Specification. This report will give an overview of the project and how it went through.

2 ASSIGNMENT, TARGET AND RESULTS

2.1 Overview of the Project

The team managed to deliver a complete containerized well-documented web application that can be easily deployed to production. Tukko - Traffic Visualizer commissioned by IoTitude's customer Combitech Oy. The application was commissioned as a proof-of-concept so it didn't have a strict target group or use cases. The target group and use cases were specified throughout the project with an open dialogue with Combitech.

2.2 Success of the project (plan versus result)

Gantt

The project was divided into five two-week sprints in which the first week was orientation and team formation and the last four-day sprint was dedicated to documentation and personal learning reports. The first "Gate" was the Open Doors -event at Turbiini offices on Friday 09.06.2023. There all the teams presented a wireframe version of their projects and met affiliates from different companies. IoTitude presented a working demo at the event and feedback was gathered from visitors.

At the beginning of the project, the developer resource was limited because the other assignment SKILL-db API took some workforce away from Tukko. But after SKILL-db API was delivered quite soon, the time resource returned to normal. Two-week sprints proved to be the most efficient solution for sprint length so there was enough time to achieve something and not constantly be sitting in retroes and plannings.

External resources were a lot of help during the project. Student coaches, members from other teams and other affiliates gave a lot of feedback and tips on how to improve the user experience, user interface or even technological solutions. Our members too were used for consultation in other teams.

3 PROBLEMS AND SOLUTIONS

3.1 Problems during planning

The first problems occurred when the team got the assignment and it was presented only as a proof-of-concept type of project. So there was a bit of confusion inside the team about what was the target group and is there even a use case for this kind of application. This problem luckily solved itself as the project advanced. With the correct technologies and a good mockup of the service, the team started forming a clearer picture of the possibilities. On top of this, the team started to get more and more information from Combitech and the requirement specification could be written with a clear concept in mind.

Daily Scrums were a bit unfamiliar for some of the team members. The first couple of weeks the dailies were not the most efficient and always went over the desired 15-minute duration. But with retroes and tips from professionals, the dailies improved and the duration stayed under 15 minutes with better outcomes.

3.2 Problems during implementation

At the beginning of the project, there were challenges of how to find the best workflow between seven team members. Nobody in the team had experience in working in a project group this size and version management in GitLab was quite challenging at first. Good practices were found along the sprints and external help improved the git-work and branching a lot. At the end of the project, everybody knew how to solve merge conflicts and most importantly how to avoid them.

Most team members were unfamiliar with the technologies that were requested for the project. To start with containerization and working with Docker was something that some members had fiddled with earlier but to make it clear for everyone, some learning had to be done. Docker became a crucial part of the workflow and deployment of the service quite soon.

Working with React framework was new to the whole team. The team suggested using just Next.js instead, but Combitech specifically requested React and so it was implemented. React is not the most intuitive framework to work with but has a lot of features that helped in the implementation of an application with this many features. All team members now know how to work with React.

On the coding side, the team decided to choose TypeScript as the main programming language for this project. All the members had experience with JavaScript, but TypeScript was mostly unfamiliar. The hardships of writing TypeScript were a constant nuisance throughout the project but its benefits overruled the challenges in total. Now the team has a good understanding of the benefits of using TypeScript instead of just JavaScript.

Leaflet.js was the main visualization library for this project. Leaflet.js is a very popular JavaScript library but it being almost 10 years old it's not the most cutting-edge solution anymore. But because it has been so widely used, there are a lot of modules for it. On top of that, there were a lot of solutions online and it is well-documented.

Digitraffic's API that was used in the project had a lot of limitations. First, the team had to figure out a way how to circumvent the API request limit which was only 60 requests per minute. The request limit could be handled by creating a backend for the data that is being requested and serving the data from there. The solution was a two-part database system that consists of Redis and MongoDB. Redis is an in-memory database that can be used for quick data storing and fetching. Additionally, MongoDB was used to save historical data from the requests so it could be used on the data analytics feature. This way the request limit didn't affect the end user anymore and on top of that the performance of the application was improved a lot.

The structure of Digitraffic's API endpoints proved to be a total mess. A lot of requests had to be made just to form a single station's data frame. Many requested features were moved to the backlog because implementing them would need a lot of work in the backend. This is a problem that cannot be solved until Digitraffic updates all of its data sources in its API.

3.3 Other problems, realized risks and their processing

Time resource for the whole project was sufficient and insufficient at the same time. The vision the team had at the beginning of the project would have needed at least a couple of weeks more to implement all the features that were "nice to have". Our members were needed in other teams' projects as consultants so that ate a bit of IoTitude's resources. On top of these, there were a lot of lectures and visitors and other time-consuming activities during WIMMA Lab. Of course, these all carry a value in themselves and cannot be seen as hurtful to the project. WIMMA Lab in essence is learning from the affiliates and learning about other projects too.

4 SUMMARY

4.1 Most important learnings

  • Team dynamics: Communication and teamwork
    • The team learned to work autonomously and give valuable input in the daily scrums.
    • Team members learned to ask for help when obstacles occurred
    • Helping other team members and other teams
  • Containerization
    • Learning why to implement containerization in software project
    • Learning how to use Docker as a tool to build and run containers in various environments
  • Git
    • Using Git in a multiple developer project
    • Using a variety of git functionalities
  • GitLab
    • Understanding the benefits of good version management in a repository
    • Learning how to review your own and other developer's code
    • Learning how to solve conflicts when they occur
    • Creating small-enough tickets so tasks are easy to pick up by every member of the team
  • React
    • Understanding the benefits of using React in a software project
    • Learning how to use React as a framework
    • Getting to know the features of React and Next.js
  • TypeScript
    • Learning why TypeScript is used in professional development environments instead of just JavaScript
    • Learning the syntax of TypeScript
  • MongoDB
    • Utilizing MongoDB for big datasets
    • Making the most efficient algorithms for fetching data from it
  • Redis
    • Why in-memory data structures are beneficial
    • Implementation of Redis in a full-stack project

4.2 Self-evaluation

4.2.1 Group work

  • Project management (not personalized, but on general level)
    • The project was managed well and all the members were kept on the same page throughout the summer. Everyone knew their daily tasks and could openly discuss improvements in teamwork. Creating t
  • Utilizing diversity
    • The team had varying interests and skill levels in the technologies used. That helped form the team because everyone found their purpose and were able to put themselves in a position where they could learn new things without the fear of failure.
  • Problem solving (not limited to technical, other problems too, e.g. communication)
    • Members got to learn how to discuss their challenges or limitations and openly ask for help when needed. Huge improvements were made in this during WIMMA Lab.
  • Division of workload and management of tasks
    • Division of work is hard to compare between the team members because of the variety of roles. Some members focused on one task for multiple days but others might do a couple of tickets during the same time. Development for the frontend and backend consisted of many types of tasks and then we had testers too so it makes it even harder to compare. But the most important note here is that every member pulled their weight and felt purpose in the team.
  • Groups own work
    • In short, the group did a great job.
  • Work by others (support group activities etc.)
    • Other teams were helpful and favors were done without any expectations. Student coaches provided us with invaluable support throughout the project.
  • Utilization of resources (what are your resources?)
    • The team utilized the Turbiini offices and equipment to a high degree. All the available classrooms and lobby areas were put to good use when having meetings. Of course, Restaurant Cube and Fiilu were the team's go-to lunch places. Physical environment was one aspect but the mental support from affiliates was a crucial part of the team's success.
  • Guidance and its utilization (did you receive guidance from others than your own supervisor?)
    • Guidance was welcomed from all lecturers and visitors.
  • Group process (from individuals to team, evolution)
    • The team formed tight bonds during the project and work flow improved from day to day.
  • Crisis and management
    • Luckily we avoided all crises.
  • Critical development of own work
    • Great leaps were taken.

4.2.2 Planning the project work

  • Plans
    • The project was well-planned from the start, but of course, plans were made flexibly so the team didn't lock themselves into a strict roadmap. An agile approach proved to be the most efficient.
  • What’s been done?
    • A great web application.
  • Tools used for planning and controlling (how does it affect the everyday project work?)
    • The team tried multiple tools for planning. Mural and other interactive boards were tried at the beginning, but the most efficient tool came to be going outside for ice cream. That way the team got the most out of the sprint retrospective. GitLab was used for the whole of the project for documentation and issue tracking.
  • What’s been updated and why?
    • The team got rid of many hindering tools like Mural and external test management softwares. Roadmap got updated in every sprint planning.
  • How good were the plans?
    • The first plan had a lot of margins so the team would not be running out of tasks before the last sprint.
  • Resource management:
    • planning
      • There was enough time spent on planning so it would be easier to work autonomously.
    • controlling
      • Measures were taken so the team would not run out of working hours.
    • realization
  • Documentation of project process (for example memos from meetings)
    • Tickets were written even out of the most insignificant things so nothing was left unnoticed or undocumented.
  • Management of project process
    • The process was well-managed.

4.2.3 Interaction

  • Communication with stakeholders (who are they?)
    • Communication lines were held open with the client Combitech Oy. Their representative came to visit almost every two weeks or so.
  • Acquiring information (from the client)
    • Feedback was gathered in every meeting session with the client and by exchanging messages.
  • Interviews and preparations, implementation and processing the knowledge gained
    • Multiple members if not all were present at the interviews and the knowledge gathered from those sessions was processed as a team and written down into well-thought tickets.
  • Reporting
    • Every member did documentation about their work. In real-time to Discord and for long time preservation to this Documentation page.
  • With the client
    • Meetings and messaging were kept efficient and relaxed. The threshold was kept low so problems could be solved quickly.
  • With special target groups
    • This was easy because the target groups were imaginary.
  • With Jyväskylä University of Applied Sciences
    • Personnel helped a lot during the project. IT services borrowed hardware and other personnel borrowed their skills and knowledge. It was easy to go visit the IT services and affiliates were moslty available on Discord or LinkedIn.
  • With Other targets and media (if applicable)
    • The team was active on social media i.e. LinkedIn.
  • Developing and delimiting the task
    • How?
      • The scope was set so that it would be plausible to implement during the ten weeks. Features were divided into three categories based on their priority level. All the lowest priority features could be left for the backlog.
    • Who suggested it and with what information?
      • The team discussed this with the client.
  • Support group activities (sharing knowledge, utilizing experts)
    • Support was welcomed and utilized when needed. Messaged student coaches on Discord.
  • General mood and reasons behind it (if ‘down’, how was it improved?)
    • The general mood of the team was monitored daily and the mood was compared to the feeling of productiveness by the members. Motivation problems towards the end of the project were expected but were not significant enough to affect the outcome.
  • Use of communication tools (best tool for each case, for example meetings are very expensive use of time)
    • Best tool proved to be Discord. For data preservation GitLab was used but for quick communication Discord was the best. With the client, Teams was used when exchanging messages.
  • Effectiveness of communication (executive board, email, others)
    • Communication was honed throughout the project. Face-to-face meetings were the best with the client.

4.2.4 Attitude

  • Towards the task
    • The attitude was at first very neutral and confusing but when the scope of the task became more clear, the attitude changed to very positive.
  • Towards learning
    • Every member was very motivated to learn new things in this project.
  • Towards the problems
    • Problems were not insurmountable and the team focused on solutions rather than getting stuck.
  • Was the project under control during all the various stages?
    • Yes.
  • Asking for feedback
    • The team was open to feedback because it helped to better the workflow.

4.2.5 Result

  • What are the results of the project? ** The team produced a very robust web application that has a lot of potential to be useful to end users. The backend and frontend are both very useful by themselves and together they form a very nice package.
  • How good are they?
    • Even though the service did not have any clear use cases at the beginning, it ended up becoming something more than was expected from it. The results are very good.
  • Are there “intangible” results? (for example, change in attitude)
    • Members got a better view of what their place in the IT field in the future could be.
  • Value of the results to the organization and others
    • For the team members, the results are very valuable, as a part of their portfolios and as a learning process. Value for the client was delivered in the form of the product that was made by their requested technologies and the proof-of-concept was.. proven.
  • Further steps
    • The takeaways from this WIMMA Lab can be used in the future in actual work-life situations.

4.3 Suggested grades

5/5 for the whole team.

SOURCES

https://tukko.wimmalab.org

ATTACHMENTS

Requirement Specification