Project plan
| Document | Project Plan |
| Author: | Byte Me |
| Version: | 1.0 |
| Date: | 21.2.2025 |
1. Assignment
1.1 background and starting points
This project focuses on the development of a PrestaShop-based e-commerce solution, implemented with CI/CD development and good project practices in mind
The goal is to provide store owners with a customizable, managed e-commerce platform, integrating key features such as secure authentication, automated testing, real-time analytics, customer feedback processing, and API integrations.
Currently, store owners face challenges in managing online sales, customer interactions, and business insights efficiently. This project aims to streamline these processes by enhancing the functionality and automation of the PrestaShop framework.
The requirement definition document provides detailed specifications for the system’s architecture, user roles, and functional capabilities. The solution is designed to be scalable, secure, and easy to use, ensuring that merchants can focus on their business without technical overhead.
1.2 Goals and tasks
The goal of this project is to develop a managed PrestaShop service that provides store owners with a secure, customizable, and automated e-commerce platform. This includes:
- Improving user experience with an intuitive registration, login, and feedback system.
- Enhancing security and compliance through role-based access, password recovery, and GDPR-compliant data handling.
- Automating business processes such as sales tracking, stock monitoring, and abandoned cart analysis.
- Providing developer-friendly API integrations for seamless third-party service connections.
- Ensuring reliability through automated CI/CD testing, acceptance test automation, and regression testing.
Tasks and priorities:
A more detailed description can be found in our requirements specification.
Stakeholders Involved
- Store Owners – Need a scalable, secure e-commerce solution.
- Customers – Expect seamless shopping and review systems.
- Developers – Require API access for third-party service integration.
- Administrators – Maintain platform security & compliance.
- Investors/Sponsors – Monitor business viability through analytics.
1.3 Limitations and interfaces
Scope of the Project:
- Secure user authentication (registration, login, password recovery).
- Automated business analytics (sales tracking, shopping cart analysis, stock monitoring).
- Customer feedback and review system integrated with PrestaShop UI.
- API access for third-party integrations (payment gateways, shipping providers, marketing tools).
- Automated testing and CI/CD pipeline to ensure system stability.
Key Restrictions Affecting the Project:
- Time constraints - students have limited time in the week to work on this project, aswell as the fact that the implementation has been shortened from last year
- Regulatory compliance – The system must follow GDPR & PCI DSS security standard
- User access control – Only store owners and administrators have full system access; customers have restricted access to feedback and purchases.
1.4 Rights and IPR
The ownership rights, licensing, and usage rights of this project are defined as follows:
- Third-Party Integrations: Any external APIs and libraries (e.g., payment gateways, analytics tools) retain their original licenses and usage restrictions.
- Source Code Ownership: The PrestaShop-based e-commerce solution developed in this project is owned by the project team/course manager
- Project Participants: All contributors (developers, testers, and document writers) retain the right to reference their work as part of their portfolio but cannot claim exclusive ownership over shared project components.
- Jyväskylä University of Applied Sciences (JAMK): JAMK reserves the right to use this project for educational and research purposes, including demos, case studies, and future development.
- Data Protection: Any data processed by the system must comply with GDPR regulations, meaning store owners own their customer data, but the platform must handle it securely.
1.5 terms and definitions
This section defines key terms, abbreviations, and concepts used in the project to ensure a common understanding among all stakeholders.
| Term | Definition |
|---|---|
| PrestaShop | An open-source e-commerce platform that allows merchants to create and manage online stores. |
| Store Owner | A user who sets up and manages an online store using the PrestaShop-based service. |
| Customer | An end-user who purchases products from a store hosted on the platform. |
| Administrator | A system maintainer responsible for managing security, compliance, and performance. |
| API (Application Programming Interface) | A set of tools that allow developers to integrate third-party services with the platform. |
| GDPR (General Data Protection Regulation) | European Union data privacy law governing the handling of customer data. |
| PCI DSS (Payment Card Industry Data Security Standard) | Security standards for handling credit card transactions securely. |
| CI/CD (Continuous Integration / Continuous Deployment) | A software development practice that automates testing and deployment of new features. |
| Regression Testing | Testing done after a bug fix to ensure that no new issues are introduced. |
| Shopping Cart Abandonment | When a customer adds items to their cart but does not complete the purchase. |
| Business Intelligence (BI) | Tools and systems that analyze business data to help store owners make informed decisions. |
| Managed Hosting | A hosting service where infrastructure, maintenance, and updates are handled by the provider. |
1.6 Challenges related to the project
| Category | Description |
|---|---|
| Strengths | Uses an established, open-source e-commerce platform (PrestaShop). |
| Provides automated testing and CI/CD integration for system reliability. | |
| Offers business intelligence tools for monitoring sales, stock, and customer activity. | |
| Secure authentication with role-based access control (RBAC). | |
| Scalable architecture with API integrations. | |
| Weaknesses | Initial learning curve for store owners unfamiliar with PrestaShop. |
| Dependence on third-party integrations (payment gateways, shipping providers). | |
| Limited customization options without additional development. | |
| Opportunities | High demand for user-friendly, managed e-commerce solutions. |
| Growth potential through multi-language and multi-currency support. | |
| Expansion into subscription-based SaaS models. | |
| Potential partnerships with payment providers and logistics companies. | |
| Threats | Security risks (data breaches, compliance issues with GDPR/PCI DSS). |
| Competition from other e-commerce platforms (Shopify, WooCommerce). | |
| Dependency on cloud hosting providers and potential downtime issues. | |
| User adoption challenges due to resistance to switching from existing solutions. |
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 | |
|---|---|---|---|
| Joni Parantainen | Project Manager - Oversees project execution, coordinates tasks, and makes high-level decisions. | Byte Me | |
| Valtteri Pohto | Developer - Implements features, manages requirement documentation, and ensures system integration. | Byte Me | |
| Vesa Löytölä | Developer - Works on system architecture, database management, and business logic implementation. | Byte Me | |
| Joni Halonen | Test Engineer - Designs and executes automated tests, ensures software quality. | Byte Me | |
| Niilo Hurme | Operations Engineer - Manages deployment, infrastructure, and cloud services. | Byte Me |
Board Members
The management team constitutes elected representatives of the project group, instructors and the client. Other persons, such as experts, may also be invited to meet the management team meetings.
| Name | Responsibility | Company/Community |
|---|---|---|
| Onni Santala | Investor | Self-Employed |
| Hanh Nguyen | Product Owner | Byte Me |
| Joni Parantainen | Team Leader | Byte Me |
| Niilo Hurme | Team Administrator | Byte Me |
Support Group
The task of the support group is to provide a project group for a content guidance to complete the task.The passage should> introduce the project's other stakeholders (customer, external consultants, etc.).The> persons involved in the customer must mention at least the name, contacts, work description and the role in the project.
2.3.Project Steps and Financial Objectives
The project will follow a clearly defined schedule and resource allocation plan, ensuring tasks are completed on time and within the designated resources. Progress will be continuously monitored and evaluated to detect any variances, allowing for timely adjustments to keep the project on track and achieve its objectives efficiently.
2.4.Quality verification
| Method | Description |
|---|---|
| Automated Testing | Continuous integration ensures unit, integration, and regression tests run before deployment. |
| Manual Testing | QA team conducts UI/UX tests, functionality tests, and security audits. |
| Code Reviews | Peer reviews ensure coding standards, security, and maintainability. |
| Performance Monitoring | Load testing and response time tracking ensure system reliability. |
| User Acceptance Testing (UAT) | Store owners and customers validate the system before final release. |
2.5.Communication and tracking of project progress
| Tool | Purpose | Usage Frequency |
|---|---|---|
| GitLab | Version control, issue tracking, CI/CD automation | Daily |
| GitLab Issues & Epics | Tracks development tasks, bugs, and milestones | Daily |
| Discord / Slack | Team communication, quick discussions, and troubleshooting | As needed |
| Zoom | Client meetings, stakeholder presentations, sprint reviews | Scheduled |
2.6.The end of the project
Once all tasks related to deployment, validation, and documentation are completed, the project will be officially closed. The final decision will be recorded, confirming that the deliverables meet stakeholder expectations, and all responsibilities will be transferred as needed.
3. Project's temporal Gates
3.1 Partitioning and Phase
- (Accessible only if signed into GitLab)
- Sprint 00
- Orientation 13.1 - 17.1.2025
- Sprint 01
- 20.1.- 31.1.2025
- Sprint 02
- 3.2 - 14.2.2025
- Sprint 03
- 17.2 - 28.2.2025
- Sprint 04
- 4.3 - 14.3.2025
- Sprint 05
- 18.3 - 28.3.2025
- Sprint 06
- 1.4 - 11.4.2025
- Sprint 07
- 15.4 - 22.4.2025
3.2 Project preliminary cost estimate
Presenting a cost estimate with a table:
| Gate | Description | Gate date | Price from previous gate |
|---|---|---|---|
| Gate 1 | Signing of the Agreement | February 28th, 2025 | 24,420.25€ |
| Gate 2 | Final testing plan | March 14th, 2025 | 10,260.07€ |
| Gate 3 | Approval testing | April 11th, 2025 | 21,290.10€ |
| Gate 4 | Commissioning | April 22nd, 2025 | 11,094.28€ |
| Final | 67,034.78€ |
4. Quality assurance
Quality assurance in the project is essential to ensure that the software meets the desired standards and functions as expected. This section outlines the working methods, tools, and standards that will be followed during the development process. The project team will adhere to the client's requirements or, if no specific guidelines are provided, will adopt best practices and methods approved by the IT Institute. A version control system will be in place to track the development of key documents and project deliverables, ensuring that all stakeholders have access to the most up-to-date versions. Regular monitoring, testing, and reporting will be conducted to maintain transparency and maintain the project's overall quality. Additionally, if any particular tool or software becomes critical to the project's success, the team will designate an expert responsible for managing and overseeing its use.
4.1 Approval of intermediate and results
The approval process ensures that deliverables meet agreed-upon standards before being accepted by stakeholders.
| Deliverable | Approval Criteria | Responsible Party |
|---|---|---|
| Requirement Specification | Must be reviewed and approved by the project manager and stakeholders. | Project Manager, Stakeholders |
| System Architecture & Design | Reviewed for scalability, security, and feasibility. | Development Team |
| CI/CD Pipeline & Automated Tests | Must pass predefined acceptance criteria before merging into production. | Test Engineer |
| Feature Implementations | Peer-reviewed, tested, and validated before integration. | Developers, Test Engineer |
| Final Deployment | Confirmed by QA, validated against system requirements. | Operations Engineer, Project Manager |
| Project Documentation | Completeness, clarity, and compliance with reporting standards. | Project Manager |
4.2 Manage changes
The change management procedure ensures that any changes to the project are thoroughly evaluated and properly implemented. When a change is proposed, the project team discusses the need for the change and evaluates its impact. A proposal is then presented to the management team for approval. Once the change is authorized, it is developed, tested, and integrated into production. All relevant documents are updated to reflect the change and maintain consistency across the project.
| Step | Description |
|---|---|
| Change Request Submission | The requestor submits a change proposal via GitLab issues. |
| Impact Assessment | The team evaluates the feasibility, risks, and resource impact of the change. |
| Approval/Rejection | The project manager and stakeholders approve or reject the proposed change. |
| Implementation & Testing | The change is developed, tested, and merged into production. |
| Documentation Update | All relevant documents are updated to reflect the change and maintain accuracy. |
4.3 Documentation
The documentation related to the project is stored in several places depending on the subject. Documentation locations are listed below:
| Document | Storage Location | Responsible Party |
|---|---|---|
| Project Plan | GitLab | Development Team |
| Requirement Specification | GitLab | Development Team |
| Technical Documentation | GitLab | Developers |
| Test Reports | GitLab /50-test-management folder |
Test Engineer |
| Meeting Notes | Discord | Project Manager |
| Risk Management Plan | Risk management table | Project Manager |
4.4 Risk management
Risk management is crucial for ensuring the success of the project. Risks should be listed, their severity and probability evaluated, and strategies developed for preventing the most serious and likely risks in advance. It is also important to have a plan in place for how to respond if a risk occurs. Risks are documented and maintained as needed throughout the project. Each risk is assigned a unique identifier, such as RIS007, to facilitate their management in various situations.
The risks can be further examined and managed in the risk management table, available through the link below:
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 section outlines the additional plans that will be developed or are already available within the project, including the communication plan, risk management plan, testing plan, and deployment plan. These plans support the main project plan by addressing specific areas such as effective communication, managing risks, ensuring quality through testing, and overseeing the deployment process. Each plan is designed to ensure the project's success and smooth execution.
- Project Agreement
- Requirement Specification
- Release Plan
- Master Test Plan
- Communication Plan
- Risk management plan
- Other Documentation
4.7 Plans for review and updating
The project plan will be reacted to deviations and environmental changes, so it is updated during the project.To this point, the dates are recorded in which the date of updating the plan at least must be checked.
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 purpose of the communication plan is to define the communication methods and channels used in the project. Clear and consistent communication ensures the effective flow of information, influencing the successful implementation of project quality objectives. This plan can be part of the project plan or referred to as one of the subpages.
In this project, we will utilize Discord and Zoom as our main communication tools. Zoom will be used for lecture-style meetings and discussions regarding essential project topics. Discord, on the other hand, will serve as the primary communication channel for team meetings, collaboration, and ongoing communication between team members and project supervisors.
| Tool | Purpose |
|---|---|
| Discord | Primary communication channel for team meetings, collaboration, and discussions with mentors. |
| Zoom | Used for lecture-style meetings and discussions of important project topics with the team. |
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."
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.