Project plan
| Document | Project Plan |
| Author: | Anni Mäki-Ventelä, Annemari Paulov-Halttunen, Minna Tapojärvi |
| Version: | 1.1 |
| Date: | 14.02.2024 |
1. Assignment
1.1 background and starting points
The aim of the project is to improve the Tukko application based on user stories. Various features have been created based on user stories, which make it possible to improve and develop the application. As a team, we had to make decisions about which features we would like to choose and start working.
1.2 Goals and tasks
We have decided to focus on the frontend side in this project. In our team we do not have a member designated as a developer, which is why we strive to produce a dev share by collaborating and dividing tasks according to skills and interests. We are also interested in individual features from several differens epics, which is why we decided to pick features here and there. Also, none of our team member has particular experience in any specific role that has been "assigned" in the project, but we are all in a group learning and getting to know different topics.
Features we are interested in developing are mostly based on the user interface and accessibility (Epic 1). The features related to the color scheme and securely authenticate user accouts were selected as the features to be worked on from Epic 1.
From Epic 2 (Data analysis and export) we would like to try to solve how to export data to csv from the database and from epic 3 (Nordic scalability) we would like to produce a localization for Swedish feature.
None of our team members has experience or knowledge of data security and authentication. In any case, we took on the challenge of working on the "Enforce secure coding practices" and "Harden all the containers" features.
From a testing perspective, we are interested in "Producing automate tests for frontend and backend" as well as "Manual testing" features.
Our goal is to produce a functioning features that will benefit Tukko in the future and that we as a team can manage, but which also have a bit challenge.
1.3 Limitations and interfaces
Our team is missing a designated person for the role of developer. For this reason, we as a team are manage to replace the missing member through cooperation. This also means we have a team of five members.
Based on the low starting level of IT skills of our members, we have to spend more time familiarizing ourselves with tools and equipment.
1.4 Rights and IPR
The ownership of this project belongs to Combitech and Reima Parviainen.
The ownership of intellectual property belongs to our team as long as we are working on in this project but also after that. However we work for Tukko, so our code and output also belong to Tukko.
1.5 terms and definitions
-
Tukko - Traffic Visualizer: An open-source service developed by IoTitude (team in WIMMA Lab 2023) and commissioned by Combitech Oy, which utilizes public traffic APIs, particularly Digitraffic. This service provides data visualizations on a map, allowing users to select vehicle types and various timescales.
-
SMART goals: Specific, Measurable, Achievable, Relevant, and Time-Bound. Defining these parameters as they pertain to our goal helps ensure that our objectives are attainable within a certain time frame.
-
User story: An informal, general explanation of a software feature written from the perspective of the end user. Its purpose is to articulate how a software feature will provide value to the customer. A user story is, simply put, software system requirement. User stories may be written by different stakeholders like client, user, manager, or development team. INVEST -Stories should be: Independent, Negotiable, Valuable, Estimable, Small and Testable.
-
Agile project management: An iterative approach to managing software development projects (planning and quiding project processes), that focuses on continuous releases and incorporating customer feedback with every iteration. It breaks the processes of the project down into smaller cycles (sprints). Software teams who are using agile project management methodologies will increase their development speed, expand collaboration, and foster the ability to better respond to market trends.
-
DoD: Definition of done, what it means for work to be complete. DoD protects the team agains scope creep. With a clear DoD the team knows when it is the time to stop. DoD applies to every issue in every sprint and creates transparency by providing everyone a shared understanding of what work was completed and what standards were met as part of the Increment. If a Product Backlog Item does not meet the DoD, it cannot be released. Different from Definition of Ready.
1.6 Challenges related to the project
Strengths
Our strengths in this project are clear goals, the support we receive from the teacher, product owner and mentors, as well as a good team spirit. We are aware of possible threats and the needs of individuals in terms of learning new skills. That's why our team has a good understanding of the issues and we know how to anticipate and prepare for things to come.
Weaknesses
During the project there could arise challenges related to technical complexities, resource constraints, scope creep, communcation issues, timeline pressures, risk management or quality assurance and testing.
Technical problems can be caused, for example, by dealing with new technologies and coordinating different servers. Resource constraints can affect working on the project as a challenge when using different software and programming languages. Familiarizing new environments takes time and requires our team to focus on the basics and be ready to internalize a lot of new things in a short time.
Scope creep can lead to schedule stretching, budget overruns and excessive use of resources. To avoid scope creep, clear requirements should be established at the beginning.
Communication issues can occur if the relationships between team members are not open and if disagreements arise in the group. The aim is to prevent communication problems with open communication among the team via Discord.
During sprints, there may be pressure to complete tasks on time. If, for example, a member of the group gets sick, the group's activities may slow down and thus cause pressure.
It is good to be prepared in advance against problems related to risk management by making a risk management plan. In this case, it is possible to prevent problems from arising and it is also easier to take on potential challenges when they have been thought about beforehand.
Possible challenges in quality assurance and testing are probably related to insufficient testing time, lack of test data or problems in the testing environment. To avoid this, it is good to define a comprehensive testing strategy to ensure the quality of the software.
Opportunities
Project's opportunities are to create good modifications and add features, that will increase the number of Tukko users. By creating suitable colors for the colorblind on the site and adding a Swedish translation to the service, the user base can also be increased.
Threats
There is a possibility of the lack of security, which may cause threats.
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 |
|---|---|---|
| Eetu Ihanus | Team Leader | JAMK |
| Minna Tapojärvi | Tester | JAMK |
| Annemari Paulov-Halttunen | Security | JAMK |
| Anni Mäki-Ventelä | OPS | JAMK |
| Ilari Jussinmäki | General | JAMK |
The project team performs the tasks set by the Product Owner for the project within the scope of the available resources.
Board Members
| Name | Responsibility | Company/Community |
|---|---|---|
| Marko Rintamäki | Scrum Master/Coach | JAMK |
| Reima Parviainen | Product Owner | JAMK |
Support Group
There are peer coaches and mentors available for support during the project.
2.3.Project Steps and Financial Objectives
The project has a predetermined schedule made by the Scrum Master, that the team is going to follow. The project is conducted by students, so there is no financial objective.
2.4.Quality verification
The features will be tested and require to pass acceptance criteria. All documentation is in Gitlab and that also serves as change management tool. Reviews are held at the end of each sprint.
2.5.Communication and tracking of project progress
Our project team communicates via Discord and Teams. We use Discord as our primary channel for all information. Our working environment is GitLab, CSC and ePouta software.
2.6.The end of the project
At the end of the project the results will be presented to the customer and other interested parties. The release event will be held on 22.04.2024. Team will also prepare end of the project report.
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).
- Setting up the team
- Project planning/ designing documentation/ creating communication practices
- Updating the Team's web pages/ familiarization with the assignment and developing tools
- Updating the project plan/ other documentation
- Offer ready for customer
- Project Plan ready for review
- Requirement Specification ready for review
- Preliminary testplan ready of review
- Review checkpoint known
- Project status check
- Used resources and progress checked
- Problems and achievement
The goal is to provide a developed software solution for the target audience selected for trial use. Also observations on the current implementation must be collected.
Produced solution ready for delivery!
- The team will draw up a project final report.
- Sustainable development course assingment must be executed.
- Personal learning diarty must be returned.
- Team project end report must be returned.
- "Competence Growth"-survey must be done as a last task after learning diary is written.
- Services at CSC must be shut down.
3.2 Project preliminary cost estimate
Presenting a cost estimate with a table:
4. Quality assurance
This project uses the practices listed below for quality assurance.
4.1 Approval of intermediate and results
- All the implementations will be tested.
- When an issue has been completed, other person from the team will check the result before is it considered done.
- At the end of each sprint the team will go through completed issues that are waiting review, and approve them to be closed.
4.2 Manage changes
The team will gather to discuss possible changes and to make decisions together.
4.3 Documentation
Documents are saved in Gitlab and are viewable in OPF. the team has a shared responsibility to complete and update documents depending who has the most time on their hands.
4.4 Risk management
Project's risk management details are listed to risk management table. There's a link below. * Risk management table
4.5 Reviewing Policy and plans for reviews
Our goal is to make sure that our project progresses according to the schedule. We have time to face problems and challenges without being reflected in the schedule.
In total, there are seven sprints in the project. At the end of each sprint, there is a review day, when the tasks achieved during the sprint are reviewed and what is still being worked on is determined.
Throughout the whole project there are five milestones, gates. Gates are like checkpoints where the customer or some external stakeholder conducts the review of the project.
After sprint5 there is a demo day when we present the features we have planned and created solutions in a mockup form. There also could be something concrete to show to stakeholders.
Schedule of milestones:
- GATE 0: Intro to the project - 30.1.2024
- GATE 1: Offer - 23.2.2024
- GATE 2: Status check - 22.3.2024
- GATE 3: Demo Day - 4.4.2024
- GATE 4: Release - 22.4.2024
4.6 Complementary plans for the project plan
5. Communication and tracking of project progression (communication plan)
5.1 Communication Plan
6. The end of the project
6.1 Delivery of the end product, introduction
The project ends 22.4.2024, when the final product of the project is documented as a brief PowerPoint presentation and ready to be introduced to the customer. The customer reviews the modified application and decides if it's something they would like to use.
6.2 Taxation of the project produced by the project, archiving and retention period
All of the files and documentations will be handed over to the customer.
6.3 Official termination of the project
The project ends on 22.4.2024, when the project schedule expires.
6.4 Termination
The project concludes with success in achieving its goals. All deliverables are completed and accepted. Lessons learned, including successful strategies and areas for improvement, are documented.
6.5 Project Final Report
The final report of the project will be written in the last management team meeting. This report summarizes the project's objectives, outcomes, challenges, lessons learned, and recommendations for future projects