Project plan


Document	Project Plan
Author:	Leevi Kauranen
Version:	1.0
Date:	5.2.2024

1. Assignment

1.1 background and starting points

This projects goal is to create wanted features for Tukkos' traffic visualizer. making the service more secure and visually pleasing. This will make the service more user friendly and lower the risk of cyber threats to make it match the security standards. We are looking to create authentication for user accounts, automated security testing pipeline that runs scans, securing the API endpoints adding a https connection and configure rate that limits certain API endpoints and protecting the application with Web Application Firewall.

Projects visual side will focus on allowing the user to plan routes in the traffic visualizer that will enhance product usability and make it more flexible and adding a feature that lets user accounts save favourite LAM stations which drastically emproves navigating through the service and helps experienced users to plan faster and better. We are also creating the whole feature for user creation and logging in.

By adding these features mentioned we aim to improve the service as a whole making it more secure and user friendly. This project will contribute in making tukko traffic visualizer a future transportation analysis tool to help people plan their trips better than never before. While not having to worry about what happens with their information.

The following sections of this project plan will provide a detailed overview of the project trajectory, objectives, timeline, and resource allocation.

1.2 Goals and tasks

The main goal of the project is to develop features for open source service, Traffic Visualizer, that utilizes public traffic APIs, specifically the Digitraffic API. We will mostly focus on the security aspects of the application, as we are mostly a cyber security oriented team. The project aims to achieve the following features:

Secure API endpoins
Hardened containers
secure coding practices
Securely create and authenticate user accounts
Route planning from A to B
Automated security testing pipeline
Favourite LAM stations saving to account
Rate limiting on some API endpoints
Application protected with Web application firewall

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:

Time Constraints : The project is expected to be finished in a specified timeframe, wich can create challenges. These time issues are mainly caused because of team-member's other studies, other projects and job schedules.
Resource Limitations: Limited availability of resources, including human resources, software licenses, and hardware equipment, may impact the project's progress and execution. Allocation of resources needs to be carefully managed to ensure efficient utilization.
Technological Constraints: The project must adhere to technological constraints, such as the compatibility of web-based technologies, programming languages, and frameworks used for development.
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.

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 used in the project plan to ensure clear communication and avoid misunderstandings. It is important for the Client (Combitech Oy), the Product owner (Reima Parviainen), and the team (TeamMonkes) to have a common understanding of these terms.

Strengths: - The project team (CodeMonkes) has alot of motivation towards learning the needed technologies and to achieve our goals. Our team also has pretty good foundation on knowledge, and teamwork seems to work well.

Weaknesses: - If the project doesn't follow good documentation through the whole project, it will be difficult to keep track on timeline and milestones.

Opportunities: - The integration of security features can attract users concerned about privacy and network safety. It will also prevent the leak of user information, sensitive data. The planning of routes between A and B (FEA107), will help users to plan their trips more efficiently and will attract users.

Threats: - If there is a lack of a risk management plan could leave the project vulnerable to unforeseen issues and delays.

2. Project organization

2.1 Organization

Structure of Project Organization in MindMap form

2.2 Responsibilities and decision-making process

Project Group

Name	Description	Company/Community	Responsibility
Leevi Kauranen	Team Lead	Codemonkes	Leading the team
Emil Rekunen	Junior Developer (OPS)	Codemonkes	-
Janika Ruoranen	Junior Developer (Gen)	Codemonkes	-
Rasmus Vasara	Junior Developer (Test)	Codemonkes	-
Aapo Hölttä	Junior Developer (Sec)	Codemonkes	-
Juuso Sinikunnas	Junior Developer (Dev)	Codemonkes	-

The project includes team members from team Codemonkes, who are responsible for planning, developing and executing the tasks related to the project.

Board Members

Name	Responsibility	Company/Community
Board member 1	Desicion-making, project guidance	Combitech Oy
Board member 2	Desicion-making, project guidance	Combitech Oy
Board member 3	Desicion-making, project guidance	Reima Parviainen
Board member 4	Implementing the features	Codemonkes

Support Group

There are several stakeholders involved in the project, including the support group, which includes the customer (Combitech Oy), the product owner (Reima Parviainen) and outside mentors who will give guidance and assistance to the project group when needed.

2.3.Project Steps and Financial Objectives

The project will follow a plan and schedule, to ensure that the tasks are completed in timely manner, within the predetermined resources while continuously tracking progress.

2.4.Quality verification

To ensure a high enough quality in all parts of the project, a standard of quality will be implemented.

Clearly outline the projects operational protocols, to encompass the main focus point of the project team.
Selection of suitable tools for project control, documentation and issue tracking.
Adhere to client and industry standards and implementing them into the development process.
Cooperating with available tribes and mentors to ensure a seamless operation.
Thorough documentation throughout the project. Clearly indicate the key activities, plans and alterations.

2.5.Communication and tracking of project progress

Our main communication platform is Discord for team-, tribe- and mentor meetings. Documentation will be done in multiple GitLab repositories to ensure comprehensive outcome. Reporting will be done through Discord as well, project folder holding relevant information will be made in both Discord and GitLab, depending on the sensitivity of said files.

2.6.The end of the project

At the end of the project, we shall deliver the final product to the product owner, the project documentation will be filed appropriately in case they are needed. After this, the team will write a report going through the project and summarizing its plans, objectives, achievements and challenges.

3. Project's temporal Gates

3.1 Partitioning and Phase

GANT using PlantUML

The next step is each step, the time resources and results they require in briefly.The steps and their tasks are described in more detail in the phase plans.The ongoing phase of the current stage should be known precisely who is doing and how much work to perform this step.Later phases work estimates can be made at an early stage at a rough level, which is then refined to a detailed level of the project.This happens at the end of each phase to be designed in more detail the next step.

Note: The following are the startup and ending steps.Of all the phases of the project, their duration and workloads, the so-called Gantt chart (attached), which also shows the interdependencies between the steps and the main easses (e.g., the management team meeting date of the management team).

Milestone - Gate 0

The start of the project is essentially involving project planning and design documentation and creating communication practices with the contracting company.During the phase is made For example, the Group's web pages, will be more familiar with the assignment, starting to acquire the target area, and a project plan will be drawn up in cooperation with the commissioner's representatives.During the phase Establish a management team, held the 1st Executive Team meeting and signed a project agreement. "The phase results are the creation of a group image (name, logo et al.), Web pages, etc. and project agreement with attachments."

Milestone - Gate 1

Project plan is ready and offer is delivered to the client.

Milestone - Gate 2

implementing features:
Feature FEA404 - secure coding practices ( will be a part of every Gate ) Feature FEA402 - Configure rate limiting on certain API endpoints
Feature FEA401 - Secure API endpoints
Feature FEA406 - Harden all the containers

Milestone - Gate 3

implementing features:
Feature FEA404 - secure coding practices Feature FEA409 - Protect application with Web Application Firewall
Feature FEA405 - Configure rate limiting on certain API endpoints
Feature FEA102 - Securely authenticate user accounts

Milestone - Gate 4

implementing features:
Feature FEA404 - secure coding practices Feature FEA107 - Plan routes from place A to B
Feature FEA103 - Save favorite LAM stations to user account

Milestone - Gate 5

Testing phase, looking for possible faulties within the features and fixing them

Milestone - Gate 6

Reviewing the product with client and product owner. Last team meeting, finishing the project and final report

3.2 Project preliminary cost estimate

Presenting a cost estimate with a table:

4. Quality assurance

In order to maintain high standards throughout the development process of the Tukko Traffic Visualizer, it is imperative to adhere to established working methods, utilize appropriate instruments, follow prescribed instructions, and uphold relevant standards. This section outlines the essential elements to ensure quality assurance within the project.

Working Methods, Instruments, Instructions, and Standards

Methods and Tools Selection: The project team shall utilize industry-standard methods, tools, and practices, which are typically specified by the client. In the absence of client directives, the project team will adapt a model approved by the IT Institute, subject to client approval.

Project Monitoring and Reporting: The project shall adhere to specified requirements for project monitoring tools and reporting. While no specific tool usage is mandated, a comprehensive plan for tool utilization shall be established to ensure effective project monitoring.

Information and Version Management: Clear protocols for information and version management must be established to ensure accessibility and traceability of project documents. A centralized repository for storing the latest versions of documents shall be designated, with a documented history to track project evolution.

Critical Devices or Software: Identification of critical devices or software is essential for seamless project implementation. A designated individual with expertise in the identified critical components shall be assigned to ensure efficient utilization and troubleshooting.

Documentation Requirements

The following items should be meticulously designed and documented to facilitate effective project management and quality assurance:

Project Plan Technical Specifications Test Plans and Reports Change Requests and Logs Issue Tracking Reports Release Notes

Version Control

All project documents shall undergo version control to track changes and ensure consistency across iterations. Version control mechanisms shall be implemented to manage document revisions effectively.

Testing Procedures

Testing Strategy: A comprehensive testing strategy shall be developed to validate the functionality, performance, and reliability of the Tukko Traffic Visualizer. This strategy shall include unit testing, integration testing, system testing, and user acceptance testing (UAT).

Test Plans: Detailed test plans shall be created for each phase of testing, outlining test objectives, test scenarios, test data, and expected results.

Test Automation: Where applicable, test automation tools shall be employed to streamline the testing process and improve efficiency. Automated tests shall be integrated into the continuous integration/continuous deployment (CI/CD) pipeline for regular regression testing.

Compliance and Review

Regular compliance checks and reviews shall be conducted to ensure adherence to established methods, instructions, and standards. Any deviations or discrepancies shall be addressed promptly to maintain quality standards.

By adhering to the outlined guidelines and documentation requirements, the project team can ensure robust quality assurance practices throughout the development lifecycle of the Tukko Traffic Visualizer.

4.1 Approval of intermediate and results

The chain of approval for intermediate results in the project is as follows:

Development Team: The development team is responsible for producing intermediate results, such as software components or features.
Testing: The designated tester verifies the quality and functionality of the intermediate results through various testing methodologies. They ensure that the results meet the required standards and specifications
Team Leader: The team leader oversees the progress of the project and evaluates the intermediate results. They review the work done by the development team and the tester, ensuring it aligns with the project goals and requirements.
Product Owner (Reima Parviainen): Reima Parviainen acts as the product owner, representing our organization's interests. As the primary stakeholder for the project, Reima reviews and approves the intermediate results to ensure they meet the expectations and align with the project objectives.
Combitech Oy: The representative from Combitech Oy, serving as the client, reviews and approves the intermediate results from their perspective. They ensure that the deliverables align with their requirements and expectations

4.2 Manage changes

The change management process entails identifying proposed changes, evaluating their effects, making decisions, planning and executing the changes, communicating them to stakeholders, and overseeing their implementation.

4.3 Documentation

Documentation in the project includes the use of GitLab and Open Project Framework for test documentation, GitLab for maintaining the OPF project page, and a GitLab repository for version control and related purposes.

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

This paragraph mentions what complementary plans are available or will be made within the project (e.g., a communication, risk management, testing and deployment plan).

4.7 Plans for review and updating

The project plan serves as a dynamic document that responds to deviations and environmental changes throughout the project lifecycle. Regular reviews and updates are essential to ensure that the plan remains relevant and aligned with project objectives. The following outlines the plans for reviewing and updating the project plan:

Scheduled Reviews:

The project plan will undergo scheduled reviews at predefined intervals to assess its alignment with project progress and objectives.
Reviews are conducted on a monthly basis, with the first review scheduled for [29.2]. Subsequent reviews occur at the end of each week thereafter.

Triggered Reviews:

In addition to scheduled reviews, the project plan will be subject to triggered reviews in response to significant deviations, changes in project scope, or environmental factors impacting project execution.

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 (communication plan)

5.1 Communication Plan

The communication plan for the Tukko 1.1 project serves as a foundational document defining the methods and channels to facilitate effective communication among project stakeholders. By establishing clear and consistent communication practices, we aim to ensure the seamless flow of information and influence the successful implementation of project quality objectives.

The detailed communication plan document can be accessed here, providing a comprehensive overview of our communication strategy and protocols. Communication plan

6. The end of the project

6.1 Delivery of the end product, introduction

The final product of the project will be documented and introduced to the customer, consisting of any necessary installation or commissioning services. If training is required for the customer, a training plan shall be made. Additionally, if needed installation plan and deployment plan can be formed.

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

The project produced by our team has several financial implications that need to be considered. These include the potential taxes associated with the revenue generated by the project’s output. It’s important to understand the tax laws and regulations in the jurisdictions where the project’s products or services will be offered.

In terms of archiving, our team has implemented a robust data management system. All project data and documentation, including code, databases, test results, and other project artifacts, are stored in the X system for future reference. This ensures that we maintain a historical record of the project, which can be useful for future projects, audits, or any legal issues.

The retention period for our project records is determined based on the type of data, the purpose of the data, and legal requirements. We have a policy in place to ensure that certain types of data are kept for a minimum number of years for legal or compliance reasons. With the help of our assistant, we are able to decide which documents can be left for the next projects. Typically, different plans and the final report are the most appropriate parts of such documents

6.3 Official termination of the project

It is important to define when or how to end the project.The project's decision may be a certain date, a particular product ready-made, a certain amount of work hours, a certain consumed sum of money when the customer takes the product, the warranty period has expired or when the customer accepts the product.

The project ends in 25.4.2024, when the project contract expires

6.4 Termination

A huge ending event ;)

6.5 Project Final Report

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