Project plan for DataDynamo


Document	Project Plan
Author:	Joonas Kuokkanen
Version:	1.1
Date:	20.2.2024

1. Assignment

1.1 background and starting points

Our team DataDynamo was created in early 2024 for future projects by Jyväskylän ammattikorkeakoulu (JAMK) and now has been assigned to project which is called Tukko-Traffic Visualizer and it's founder is IoTitude. Our main customer Combitech Oy reached to us in the name of new and improved Tukko aplication and our team has responded to this request and has accepted this opportunity.

In this project plan we have listed the projects goals, estimations, stakeholders, personnel, features and their functionalities. Next topic we go through these new features we are planning to deliver on Tukko app.

1.2 Goals and tasks

Our goal is to deliver new features to Tukko-Traffic Visualizer and make it more user friendly and also help IoTitude in some certain areas.

Main features for the end users are different LAM stations comparison tool, able to create personal account and be able to save favorite LAM stations to users account. User will be able to search certain traffic data from certain time period.

Other features are more likely pointed to developers and maintainers of this application. These features are developers tool to scan codebase for vulnerabilities, platform engineers easy way to confifure and maintain Tukko application in cloud and finally we're going to deliver fully checked report about Tukko applications security and functionality to product owner.

1.3 Limitations and interfaces

In this section, we will define the limitations and interfaces of the Traffic Visualizer project. This includes specifying any external components or factors that may restrict or impact the implementation of the project. Additionally, we will identify any specific task cases that are not within the scope of this project but may be associated with the overall mission.

Limitations:

Data Availability: The Traffic Visualizer project relies on the availability and accessibility of public traffic APIs, particularly the Digitraffic API. The project is limited by the data provided by these APIs and any constraints or limitations imposed by the API providers.
Technological Constraints: The project must adhere to technological constraints, such as the compatibility of web-based technologies, programming languages, and frameworks used for development.
Time Constraints: The project is subject to time constraints, as it is intended to be completed within a specified timeframe. This may require prioritization of tasks and features to ensure timely delivery.
Resource Limitations: The availability of resources, including hardware, software, and human resources, may impose limitations on the project's scope and implementation.

Interfaces:

Digitraffic API: The Traffic Visualizer project will interface with the Digitraffic API to retrieve real-time traffic data. The project team will need to understand and integrate with the API endpoints, data structures, and authentication mechanisms provided by Digitraffic.
Map Visualization Libraries: The project will utilize map visualization libraries or APIs to display the traffic data on an interactive map interface. Integration with these libraries will be necessary to render the visualizations effectively.
User Interface: The Traffic Visualizer service will have a user interface through which users can interact with the data visualizations. The team will design and develop a user-friendly interface that allows users to select vehicle types, timescales, and other filters for data analysis.
Open-Source Community: The project will have interfaces with the open-source community, encouraging collaboration, feedback, and contributions from the community to enhance the service. Communication channels, version control systems, and collaboration platforms will facilitate this interaction.

1.4 Rights and IPR

"The rights of the various parties are defined in the project agreement."Unless a separate agreement has been told about the rights of the job, they must express, for example, in this project plan.

1.5 terms and definitions

This section presents the definitions, terms and abbreviations in the project plan to clear some projects internal terms and definitions. This is provided for the customer (Combitech Oy), Product Owner (Reima Parviainen) and project team (DataDynamo).

Here's a short list of the terms that's been uset on this document:

FEA_X_ = Feature, the function we're delivering to the application
GATE_X_ = Sprint, 2 week long milestone of the project with scheduled tasks in that time

2. Project organization

2.1 Organization

Structure of Project Organization in MindMap form

2.2 Responsibilities and decision-making process

Team leader/project manager constructs project schedule and organizes tasks for each individual on the team.
Development team responsibilities include coding new features and secure frontend functionality.
Test team provides documentation of the applications functionality and it's security.
Operations team makes sure the system is running and provides working grounds by virtual machines and cloud infrastructure.
Security team ensures the applications firewalls and it's sustainability for the future.
Genereal team provides support for above listed teams for the whole project.
Every monday and friday, the team gathers for daily scrum and goes through progress and plans for the next.

Project Group

Name	Responsibility	Company/Community
Joonas Kuokkanen	Team leader	DataDynamo
Arto Nieminen	Security	DataDynamo
Honar Abdi	Tester	DataDynamo
Hanna Rantakokko	Operations	DataDynamo
Santtu Lähderinne	General	DataDynamo
Teemu Lappi	Developer	DataDynamo

Board Members

Name	Responsibility	Company/Community
Sini Karvonen	Scrum Master	Combitech Oy
Jarmo Luostarinen	Scrum Master	Combitech Oy
Reima Parviainen	Product Owner	IoTitude
Marko Rintamäki	Scrum Master	JAMK
Joonas Kuokkanen	Team Leader	DataDynamo

Support Group

Name	Area	Role
Matti	Development	Mentor
Alena	Test	Peer Coach
Iftakhar	Development	Peer Coach
Iiro	Security	Mentor
Karri	Security	Peer Coach
Lauri	Development	Peer Coach
Marika	UI-UX	Peer Coach
Minttu	Agile	Mentor
Sami	Security	Mentor
Sleemon	-	Mentor
Taina	Development	Mentor
Teija	Tietoevry	Mentor
Veeti	-	Peer Coach/Mentor
Aarne	-	Peer Coach
Hanna	-	Peer Coach
Justus	Development	Peer Coach

2.3.Project Steps and Financial Objectives

The team is prepared to follow pre-planned schedule and is capable to stand minor setbacks. These "possible" setbacks would not effect financially to the project, because they have been listed on risk management and we can prepare for them. Main objective would ofcourse be and will be to ensure effortless work flow through out the project to the end without any delays and financial changes.

2.4.Quality verification

To maximize our products quality in the making, we are going to stick to these quality verification setups that are listed below

Everyone on the team keeps track of their doing through out the whole project and keep their own feature making plan 1 week ahead to ensure nonstop workflow.
Feature planning will stay simple, no need for overproducing, just strictly follow the user stories regarding the feature.
Everyone on the team knows and uses same producing tools as agreed to ensure applications effortless testing and production. Also to keep version handling clean.
If needed, the project member will be in touch to his/her mentor or peer coach from the list above (Support group) to get help if needed regarding to their problem.
Documentation is non stop procedure through out the project, it is mandatory to keep track of the process and update our project plan or schedule if needed.

2.5.Communication and tracking of project progress

For communication and tracking project progress:

Documentation: Every team member will be documenting their workflow to GitLab and there it is transfered to the OPF site where it is visible for all stakeholders to inspect.
Communication: Main communication platform to keep in touch to the team members, mentors, product owner and other teams will be DISCORD.
Reporting: Will be done every monday and friday through TEAMS-channel at 9:00 am to have 15 minute long scrum session with the whole team.
Storage: Team storages every data to GitLab repository and keep their own version on their workstations computer to ensure controlled version control.

Link to Communication Plan

2.6.The end of the project

When the project meets it's deadline and is ready to be delivered to the client, these are the parts that will be delivered:

Final product: The product with it's new features (presented in the offer) will be delivered to the client as agreed and will be there to support it's commissioning.
Documentation: Every document created through out the project will be delivered to the client for safe keeping and copies of these will be held by the project team for future.
End report: Every team member is obblicated to write their own end report from their own perspective to keep track of their learning and improvements. The team will also write shared end report about their progress as a team.

3. Project's temporal Gates

3.1 Partitioning and Phase

GANT using PlantUML

Sprints and GATES in our project

Sprint 00 - Gate 0

Team roles are selected
Project site is updated and team logo is produced
First documents such as. Team introduction and status is updated
Virtual machines are launched
Studying about the product and personal roles in the project

Sprint 01

Communication plan and master test plan is produced
Starting to write project plan and requirements specification plan
Record first features and creating mindmap and other documents related to selected features

Sprint 02 - GATE1

Finish writing of the project plan and requirements specification plan
Creating project budget
Feature use cases based on user stories
Offer for the client

Sprint 03

Feature planning
Starting to create features
Project plan update

Sprint 04 - GATE2

First features are done and ready for testing
Other feature are in production and tested all the time
Update of the project pland/schedule

Sprint 05

Last features should be done at the end of this sprint
Preparing documents for DEMO-DAY

Sprint 06 - GETE3

Last tests should be done before DEMO-DAY
Fixes should be done
Last documents will be written
DEMO-DAY presentation

Sprint 07 - GETE4

Final reports will be writteng
Product ready for release
Project closure

3.2 Project preliminary cost estimate

Presenting a cost estimate with a table:

Presenting feature price table:

4. Quality assurance

In order to guarantee the correct workflow and quality within the project, these methods are to be followed:

Hour records

It is necessary for all team members to record their working hours to separate excel form shared on DISCORD to ensure correct workfloaw for each sprint and to keep track their overwork hours.

Documentation

Every team member documents their workflow and progress through project for futher version control and learning diary to ensure learning progress.

Version control

All versions of application or document is needed to keep up-to-date on GitLab. All documents will be shared through GitLab to ensure files integrity.

Testing

Everytime changes are made to the application or platform, It is necessary to test it's correct functionality afterwards. Team members should contact test tribe if something unusual comes up.

Daily scrum

Every monday and friday are dedicated for team scrum-meeting to have chat about team members progress and problems. Team leader gets up-to-date situation report and can alternate project plan if necessary.

4.1 Approval of intermediate and results

Approval procedure for the project:

Project team (DataDynamo): Team is responsible to review the final product and ensure it holds the features that were promised on the offer.
Testers: Test team ensures product functionality and reports for needed fixes. testing documentation is delivered to team leader to approve the final product.
Team leader: Team leader will keep track of the progress and prepares the necessary documents for the end report. Before release day, team leader gathers project team and inspect the final product with development team and testers to make sure it's reached the expected results.
Product owner (Reima Parviainen): Reima ensures the applications functionality and will give feedback for possible fixes and approves the final product for the client.
Combitech Oy: The last one of the chain of approval will be Combitech Oy representative, who will inspect the product and documentation to approve it's correct functionality which were presented in the offer and requirement specification plan.

4.2 Manage changes

The process of change management entails the identification of proposed changes, evaluating their implications, decision-making, strategizing for implementation, disseminating information to stakeholders, and overseeing the execution of these changes.

4.3 Documentation

Documentation within the project involves utilizing GitLab and the OPF for test documentation, employing GitLab for managing the OPF project page, and maintaining a GitLab repository for version control and associated tasks.

4.4 Risk management

Risk management table

4.5 Reviewing Policy

Lishes and provisionally scheduled on the project's performance review on the basis of the drawn up implementation plan.The list of reviews is presented, the preliminary time, the issues, participants and practices for the delivery of the reviewing material (what, when, how).

4.6 Complementary plans for the project plan

4.7 Plans for review and updating

11.3.2024 * First plan review will be done in the middle of the first features

18.3.2024 * First two features should be done at this point and plan will be updated

25.3.2024 * Last features are nearly ready so we'll have a meeting for changes for the schedule if necessarily

1.4.2024 * No changes to schedule or plan should be done at this point

4.8 Project Suspension Criteria

The Right Project Plan also includes the project's suspension criteria.However, these are not used in student projects because projects use a certain number of hours to make a result and the result will be released as it is at the end of the course.However, the project team makes a further development plan that a potential new project continues.

5. Communication and tracking of project progression

5.1 Communication Plan

The purpose of the communication plan is to define the communication methods and channels used in the DataDynamo's project. With clear and consistent communication, it is ensured the passage of information and influence the implementation of the project quality objectives.

Communication plan

Here's a list for used communication platforms on the project:

DISCORD (MAIN), for discussion of the project progress and consulting with tribes and mentors.
TEAMS, for daily-scrum sessions.
ZOOM, for meetings with product owner and scrum master for mentoring.

6. The end of the project

6.1 Delivery of the end product, introduction

If necessary, operations team will guide the actications of the product to client's servers.

6.2 Taxation of the project produced by the project, archiving and retention period

Projects final reports and other documents are stored to DataDyanmo's archives for later use as team reference for future customers. Any sensitive documents will be destroyed for the safety of the client or other stakeholders regarding in this project.

6.3 Official termination of the project

The project ends in 26.4.2024, when the project contract expires.

6.4 Termination

Project team holds small seminar on the finest restaurant in town and eats well and drinks well.

6.5 Project Final Report

The final report of the project will be drawn up by the last management team meeting.