Project plan
| Document | Project Plan |
| Author: | Joona Tuikkala & Kosti Katainen |
| Version: | 1.0 |
| Date: | 2.2.2024 |
1. Assignment
1.1 Background and starting points
This document is a project plan for the project "Make Tukko Great Again". The project is a part of the Future Factory-course at JAMK and is implemented within the OPF framework TTOS2070 Guideline Institute of Jyväskylä University of Applied Sciences.
The project team Flying Hippos was made with six different roles for the purpose of simulating a real working life project environment and everyone getting the experience they want out of the project. The team members have very diverse skillsets from JAMK and working life so the capabilities for diverse project work are great. Scheduling is done in two week sprints and gates that are assigned to end of certain sprints and progress is kept track of by means of Gitlab's issue boards.
The assignment the team will be working on was given by Combitech Oy and it involves a previous assignment given in WIMMA Lab in 2023 by the same company. The WIMMA Lab team named IoTitude was tasked with making a traffic data visualizer that makes use of public traffic APIs. The product name is Tukko and now our team Flying Hippos will continue the journey that IoTitude started.
Starting point for project MTGA is a fully functional traffic visualizer that supports Finnish and English languages. Tukko is looking forwards to extend the service for the Nordic countries and increase its userbase. Hence our goal is to increase accessibility, make it more user-friendly and secure.
1.2 Goals and tasks
The goal of the project is to upgrade the already existing product "Tukko - Traffic Visualizer" with new features and improvements. The team decides the features they believe are achievable from a list and then slowly work to implement them into Tukko.
Our project team has chosen to implement 12 new features which are based around user interface, security and accessibility as well as enhancing the existing features of Tukko.
To get a grasp on the new features, here is a list of planned features.
User Interface and Accessibility:
Data Analysis and Export:
Security and Authentication:
Infrastructure and Performance:
Also writing and upkeeping solid documentation is crucial part of our project. It will help the project team as well as people interested in the project to get clearer insight for the decisions made during the project.
1.3 Limitations and interfaces
Limitations of the project: 1. Digitraffic API Project Tukko uses an external third party API to gather the traffic information. This API can change, have maintenance times which will cut off Tukko's functionality.
- Compatibility The project is planned to run on a web browser. This must run on "popular" browser such as chrome, microsoft edge, firefox and so on. This will require modern JavaScript and HTML programming because not all browsers support same languages versions.
Interfaces: 1. User Interface The user interface should be fully functional on all supported browsers. It should be easily accessible, easy on the eyes and more international by supporting other Nordic languages on top of Finnish and English. The map visualization is done with an external library, so utilizing and importing these libraries will be necessary for the project to run as intended.
- API Interface DigiTraffic API is being used for real-time traffic data to visualize it on a map. The communication should be well built to support all the required data formats that goes in between Tukko & DigiTraffic.
To gain more knowledge on the external libraries and important API's used in the project, you can visit the links below:
1.4 Rights and IPR
The project's rights and intellectual property rights (IPR) are regulated by the project agreement. Unless explicitly covered in a distinct agreement, the project's rights will adhere to the conditions outlined in the project plan.
1.5 terms and definitions
In this section we will explain meanings of technical or somewhat esoteric terms used in Flying Hippos project to prevent misunderstanding and confusion.
1.6 Challenges related to the project
In our ongoing project, we have identified several challenges that demand focused attention and strategic planning. The issues includes resource management, time scheduling, and the incorporation of the new tools in our project. To address these challenges head-on, our project plan outlines targeted solutions aimed at optimizing resource allocation, enhancing time management practices, and facilitating a smooth learning curve for adopting new tools. By proactively tackling these challenges, we aim to fortify the foundation of our project, ensuring efficiency, timely delivery, and the seamless integration of innovative technologies. Through collaborative efforts and adherence to the outlined strategies, we are confident in overcoming these obstacles and achieving successful project outcomes.
2. Project organization
2.1 Organization
Structure of Project Organization in MindMap form
2.2 Responsibilities and decision-making process
Project Group
| Name | Responsibility | Company/Community |
|---|---|---|
| Joona Tuikkala | Project management, leading team | Flying Hippos |
| Kosti Katainen | General support and project management | Flying Hippos |
| Jere Lähteenmäki | Issue management and deployment | Flying Hippos |
| Jarno Huusko | Full-stack development and feature implementation | Flying Hippos |
| Guan Xinyu | Testing and quality assurance | Flying Hippos |
| Markus Murtonen | Security and data protection | Flying Hippos |
The project group is made from members of Flying Hippos who are responsible for tasks relating the project development, testing and deployment.
Board Members
| Name | Responsibility | Company/Community |
|---|---|---|
| Reima Parviainen | Product owner | Combitech |
| Sini Karvonen | Scrum master | Combitech |
| Jarmo Luostarinen | Scrum master | Combitech |
Support Group
A support group plays a crucial role in providing assistance, guidance, and troubleshooting services to various stakeholders involved in the project. Typical tasks for support group are user assistance, technical support, communicating between users and developers as well as documenting and testing. Their role is extremely important which will ensure that the software meets user expectations.
2.3.Project Steps and Financial Objectives
The project is built with various steps resulting in a fully functional and tested product or a service. The project is time scheduled and resource limited therefore it requires in-depth planning and management to meet the criteria of the finished product.
2.4.Quality verification
Quality verification is the process of systematically assessing and confirming the standard, accuracy, and compliance of products, services, or processes with predetermined criteria or established standards. It involves thorough examination, testing, and analysis to ensure that the desired level of quality is achieved and maintained.
2.5.Communication and tracking of project progress
Flying Hippos uses multiple communication platforms to track the progression of the project:
-
Documentation Gitlab Open Project Framework will serve as the core of documentation. It stores all the main documents, reports and source codes.
-
Communication channels Microsoft Teams and Discord are used as our main communication platforms. Daily scrums take place in Microsoft Teams every monday and friday. Discord is used for primary text and voice communication.
2.6.The end of the project
The finished product will be handed to the product owner or stakeholders. All the relevant documents related to the product will be archived in a secure manner.
3. Project's temporal Gates
3.1 Partitioning and Phase
The projects schedule is presented with Gantt-chart, the stages of project are visualized and marked.
GANT using PlantUML
Project Milestones:
This is the initiation phase of the project, where the participants of the project are defined and forming the project team begins. Every team member familiarizes themselves to all relevant project related materials.
At the end of GATE0, the team should have a name, logo, web page.
The project team receives the assignment from product owner in GATE1.
The team studies about the documentation of the assignment, starts building a development environment and begins to write a project plan.
At the end of GATE1, the team will give cost estimation, has finished project plan and requirement specifications. Also attempting to make mockups for the product.
This stage contains the implementation and design of the service and features planned. Intense documentation will take place, and documenting the test results and achievements is critical.
At the end of GATE2, the team will show the progression and all the features implemented to the product owner. The product owner will give feedback and the team will work on it if needed.
This is the testing phase of the project. The team will put the finished service to great lengths in testing. All bugs will be documented and possibly fixed with overtime work.
At the end of GATE3, the product should be ready for the product owner, all the features are implemented and well tested. Also the documentation side of the project is flawless.
The service produces in the project is ready to be released.
At the end of GATE4, the team will come up with a final report of the project, and after this the termination of project will occur.
The project shuts down and the product gets released.
3.2 Project preliminary cost estimate
Presenting a cost estimate with a table:
Presenting a cost estimate of features:
4. Quality assurance
Quality Assurance Guidelines:
Tools for Version Control: Select a version control system (Git). Utilize GitLab as a test documentation platform to manage test cases, test plans, and test results.
Customer requirements: Customer requirements are the purpose of our work. Clarifying the specific requirements or standards of the customer is an important part of the team's work. The team needs to incorporate customer requirements into quality assurance. And ensure that the project team follows these requirements and adds them to the quality assurance process.
4.1 Approval of intermediate and results
Developer -> Tester -> Team leader -> Other stakeholders
a). Developer: The implementation of various features by developers in the project, etc.
b). Tester: Testers verify the quality and functionality of intermediate and results through various test methods. In order to ensure that the project ultimately conforms to the required standards and specifications.
c). Team leader: The Team Leader ensures that intermediate and results are consistent with program goals and requirements.
d). Other stakeholders: Continuous communication and feedback to ensure that deliverables match stakeholder requirements and expectations in their realization.
4.2 Manage changes
Change Request -> Impact Analysis -> Documentation -> Communication -> Version Control -> Testing and Validation -> Team Leader and Administrator Approval
Establish a formalized change management process. Team members are responsible for the corresponding section according to the division of labor. Once the change is completed, it needs to be approved by the team leader and administrator before the change can be officially submitted. Team member should write detailed information such as the reason for the change, impact analysis, potential risks and recommended measures. Ensure that all relevant stakeholders have access to the latest information regarding changes. If the change affects deliverables, conduct testing and validation to ensure that quality standards are maintained.
4.3 Documentation
All documentation involved in the project is stored on gitlab. With gitlab's features, the team can do version control and other operations on the documents. Each document is assigned according to the team members' roles.
4.4 Risk management
4.5 Reviewing Policy
Regular Review -> Stakeholder Involvement -> Effectiveness Evaluation -> Feedback Collection -> Risk Assessment -> Documentation of Changes -> Approval Process -> Continuous Improvement
4.6 Complementary plans for the project plan
- Project Agreement
- Requirement Specification
- Release Plan
- Master Test Plan
- Communication Plan
- Risk management plan
4.7 Plans for review and updating
Regularly check the project plan. Update the project plan based on the progress of the project work. Each update needs to be documented with an update date and version control.
5. Communication and tracking of project progression (communication plan)
5.1 Communication Plan
This is a summarization and the full plan can be found here
Flying Hippos team decided to use Discord and Microsoft Teams as their main communication platforms.
Teams is used for daily scrums; daily scrums are held to keep everyone up to date with the newest work done towards the project.
Discord serves as the main voice chat as well as text channel. Communicating between team as well as with coaches and mentors is effortless.
6. The end of the project
6.1 Delivery of the end product, introduction
The final product of the project should also be documented at a sensible level. As part of the final product may be the introduction to the customer and possibly installation or commissioning service. If the role of education for the project is considerable (for example, software users have not been involved in the project and do not know how the system works) will include a plan to attach a plan to the customer's training. In addition, if necessary, the project plan also includes an installation plan and a deployment plan.
6.2 Taxation of the project produced by the project, archiving and retention period
"The disadvantaged part of the document group documentation is stored in the X system" With the assistant, you may be able to agree on which documents can be left to the next projects. Typically, different plans and final report are in the most appropriate part 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 p.k.vvvv, when the project contract expires." The official project end date is the end of sprint 8 on the 17th of May or when the 250 maximum amount of work hours is reached.
6.4 Termination
Generally, the projects will be decided on a joint closure seminar.Participants and time are recorded.
- In Finland project team can arrange Sauna-event :)
6.5 Project Final Report
The final report of the project will be drawn up by the last management team meeting.