report:prm

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
report:prm [2026/04/16 15:57] – [Time] team3report:prm [2026/04/22 14:59] (current) – [Mapping the Plan to Iterative Sprints] team3
Line 3: Line 3:
  
 ==== Scope ==== ==== Scope ====
-The project scope is limited to developing a POC of the smart bottle. The technical focus will be on reading certain minerals from the water and enabling communication with the app. The prototype will be tested in a controlled environment and is not intended for full deployment in a real live operating environment. +The project scope is limited to developing a POC of the smart bottle. The technical focus will be on reading certain minerals from the water and enabling communication with the app. The prototype will be tested in a controlled environment and is not intended for full deployment in a real-life operating environment. 
  
  
-In addition, to the technical prototype, the project will include a full-scale report on how the bottle should look and act. The report will include recommendations for future development, deployment plans, dataset improvement, integration opportunities, and potential risks.+In addition to the technical prototype, the project will include a full-scale report on how the bottle should look and function. The report will include recommendations for future development, deployment plans, dataset improvement, integration opportunities, and potential risks.
  
 **Project Start: 6 of March 2026** **Project Start: 6 of March 2026**
  
-**Team Preparedness: ** The team members should have the required knowledge and skills in configuring ESP32, marketing, ethics, and all the chapters mentioned in the report. Preparatory training or upskilling may be necessary if he team lacks specific expertise.+**Team Preparedness: ** The team members should have the required knowledge and skills in configuring ESP32, marketing, ethics, and all the chapters mentioned in the report. Preparatory training or upskilling may be necessary if the team lacks specific expertise.
  
 **Stakeholder Communication:  ** Establishing effective communication channels with stakeholders, including the client and end-users, is a precondition. Clear communication protocols should be in place to gather feedback and requirements. **Stakeholder Communication:  ** Establishing effective communication channels with stakeholders, including the client and end-users, is a precondition. Clear communication protocols should be in place to gather feedback and requirements.
Line 16: Line 16:
 **Risk Assessment and Migration Plan :** The project needs to perform a risk assessment beforehand to pinpoint potential risks and create plans to manage them. This prepares the project to handle unexpected challenges effectively. **Risk Assessment and Migration Plan :** The project needs to perform a risk assessment beforehand to pinpoint potential risks and create plans to manage them. This prepares the project to handle unexpected challenges effectively.
  
-**Test Envoironment: ** It is crucial to have a testing environment for thorough application testing before deploying it. This testing environment needs to closely resemble the final deployment environment.+**Test Environment: ** It is crucial to have a testing environment for thorough application testing before deploying it. This testing environment needs to closely resemble the final deployment environment.
  
 <WRAP centeralign> <WRAP centeralign>
Line 27: Line 27:
  
 ==== Time ==== ==== Time ====
-This subchapter underlines the deadlines that must be met. Documenting key milestones and linking them to deadlines is crucial for clarity, accountability, and progress tracking. It ensures teams stay aligned, allows for early identification of potential risks, and enables timely adjustments. A well-structured timeline enhances efficiency and significantly increases the likelihood of project success.+This subchapter underlines the deadlines that must be met. Documenting key milestones and linking them to specific deadlines is crucial for clarity, accountability, and progress tracking. It ensures that teams stay aligned, allows for the early identification of potential risks, and enables timely adjustments. A well-structured timeline enhances efficiency and significantly increases the likelihood of project success.
  
 **Project Duration:** 2026-02-23 → 2026-06-25 (123 days / ~17.5 weeks) **Project Duration:** 2026-02-23 → 2026-06-25 (123 days / ~17.5 weeks)
Line 53: Line 53:
  
 **Risk legend:** **Risk legend:**
 +
 - **Low** — Well-defined task, short turnaround, low dependency on external factors. - **Low** — Well-defined task, short turnaround, low dependency on external factors.
 +
 - **Medium** — Moderate complexity or dependency on prior deliverables; recoverable if delayed. - **Medium** — Moderate complexity or dependency on prior deliverables; recoverable if delayed.
 +
 - **High** — Blocks downstream work, depends on external factors (suppliers, hardware, feedback), or has cascading consequences if missed. - **High** — Blocks downstream work, depends on external factors (suppliers, hardware, feedback), or has cascading consequences if missed.
  
Line 60: Line 63:
  
 **High-risk rationale:** **High-risk rationale:**
 +
 - **List of Components (2026-03-18)** — drives all sourcing and budgeting downstream. - **List of Components (2026-03-18)** — drives all sourcing and budgeting downstream.
 +
 - **System Schematics + scale model (2026-03-25)** — physical deliverable, hardware/material dependency. - **System Schematics + scale model (2026-03-25)** — physical deliverable, hardware/material dependency.
 +
 - **Final Materials List (2026-04-29)** — depends on supplier responses, pricing, VAT, shipping lead times. - **Final Materials List (2026-04-29)** — depends on supplier responses, pricing, VAT, shipping lead times.
 +
 - **Functional Tests (2026-05-27)** — prototype must be working; bugs/hardware failures can cascade. - **Functional Tests (2026-05-27)** — prototype must be working; bugs/hardware failures can cascade.
 +
 - **Final deliverables bundle (2026-06-13)** — largest single upload (report, presentation, video, paper, poster, manual); coordination-heavy. - **Final deliverables bundle (2026-06-13)** — largest single upload (report, presentation, video, paper, poster, manual); coordination-heavy.
 +
 - **Prototype demonstration (2026-06-25)** — final, non-recoverable; live hardware failure = project failure. - **Prototype demonstration (2026-06-25)** — final, non-recoverable; live hardware failure = project failure.
 ==== Costs ==== ==== Costs ====
Line 71: Line 80:
 == Project Budget and Cost Management == == Project Budget and Cost Management ==
  
-The project budget was defined specifically for the development of a single smart water bottle prototype, with the 100 € allocation covering only the material and component costs required for one unit. The largest expenses were associated with electronic components, sensors, and structural materials. Key elements included the microcontroller, TDS sensor (for water quality), FSR406 pressure sensor (for water level), and LIS3DHTR accelerometer (for motion detection). Additional components such as MOSFETs and supporting circuitry were also required to ensure safe and reliable operation.+The project budget was defined specifically for the development of a single smart water bottle prototype, with the €100 allocation covering only the material and component costs required for one unit. The largest expenses were associated with electronic components, sensors, and structural materials. Key elements included the microcontroller, TDS sensor (for water quality), FSR406 pressure sensor (for water level), and LIS3DHTR accelerometer (for motion detection). Additional components such as MOSFETs and supporting circuitry were also required to ensure safe and reliable operation.
  
 Mechanical elements included the bottle, UV-C protection materials, and mounting components. Smaller items such as wires, fuses, and prototyping boards were not included in the budget, as they were already available in the university laboratory. Mechanical elements included the bottle, UV-C protection materials, and mounting components. Smaller items such as wires, fuses, and prototyping boards were not included in the budget, as they were already available in the university laboratory.
Line 85: Line 94:
 == Cost Analysis == == Cost Analysis ==
  
-The final prototype cost reached € 155.25, exceeding the initial 100 € budget by 55.25 € (approximately 50 %). This variance was mainly due to shipping costs, VAT inclusion, and slight underestimations during the planning phase. Despite this, the deviation remained relatively small and acceptable for a prototype. These costs will be cut down once we go into mass production.  A reduction of at least 70 € can be expected+The final prototype cost reached € 155.25, exceeding the initial €100 budget by €55.25 (approximately 50 %). This variance was mainly due to shipping costs, VAT inclusion, and slight underestimations during the planning phase. Despite this, the deviation remained relatively small and acceptable for a prototype. These costs will be cut down once we go into mass production.  A reduction of at least €70 can be expected
  
  
 == Conclusion == == Conclusion ==
  
-Overall, the budget was effectively controlled, with only a modest increase from the original 100 € estimate. All critical system requirements were successfully achieved. The project highlights the importance of appropriate component selection, supplier management, order consolidation, and leveraging available resources to optimize costs.+Overall, the budget was effectively controlled, with only a modest increase from the original €100 estimate. All critical system requirements were successfully achieved. The project highlights the importance of appropriate component selection, supplier management, order consolidation, and leveraging available resources to optimize costs.
  
 ---- ----
Line 126: Line 135:
 | Microcontroller | ESP32 DEVKIT 1, central control unit | [Joom.pt](https://www.joom.com/pt/products/5f2b8040bc26dd01061b6c2b) | 1 | 7.30 | | Microcontroller | ESP32 DEVKIT 1, central control unit | [Joom.pt](https://www.joom.com/pt/products/5f2b8040bc26dd01061b6c2b) | 1 | 7.30 |
 | Charger | 3S 18650 charger, 12.6 V, 2 A | [Joom.pt](https://www.joom.com/en/products/62b2dc6e370a7f01c6ae2a81) | 1 | 2.50 | | Charger | 3S 18650 charger, 12.6 V, 2 A | [Joom.pt](https://www.joom.com/en/products/62b2dc6e370a7f01c6ae2a81) | 1 | 2.50 |
 +
 ---- ----
  
-== Total Estimated Cost per Prototyp ==+== Estimated Cost per Prototype ==
  
 | Category | Estimated Cost (€) | | Category | Estimated Cost (€) |
Line 135: Line 145:
 | Total Estimated Cost per Bottle | 155.25 | | Total Estimated Cost per Bottle | 155.25 |
 | Initial Budget | 100.00 | | Initial Budget | 100.00 |
-| Budget Difference | -55.25 |+| Budget Difference | +55.25 | 
 + 
 +----
  
 == Personnel Costs == == Personnel Costs ==
  
-In addition to the material cost per prototype, the development of the system involved personnel costs associated with a team of six engineers. Each engineer worked an average of six hours per day over a four-month period, excluding weekends. This corresponds to approximately 88 working days per engineer, or 528 hours per person, resulting in a total of 3 168 working hours for the entire team.+In addition to the material cost per prototype, the development of the system involved personnel costs associated with a team of six engineers. Each engineer worked an average of six hours per day over a four-month period, excluding weekends. This corresponds to approximately 88 working days per engineer, or 528 hours per person, resulting in a total of 3,168 working hours for the entire team. 
 + 
 +Assuming an average hourly salary of €14, the total personnel cost for the development phase is estimated at €44,352 . This value reflects the full design, development, integration, and testing process. While not included in the per-unit prototype cost, it represents a significant investment that would typically be amortized across units in a large-scale production scenario. 
 + 
 +---- 
 + 
 +== Total Estimated Cost ==
  
-Assuming an average hourly salary of 14 €, the total personnel cost for the development phase is estimated at 44 352 €. This value reflects the full design, development, integration, and testing process. While not included in the per-unit prototype cost, it represents a significant investment that would typically be distributed across units in a large-scale production scenario.+| Category | Value | 
 +| Team Size | 6 Engineers | 
 +| Working Period | 4 Months | 
 +| Average Working Days / Engineer | 88 Days | 
 +| Average Hours / Day | 6 Hours | 
 +| Total Hours / Engineer | 528 Hours | 
 +| Total Team Working Hours | 3 168 Hours | 
 +| Average Hourly Rate (€) | 14.00 | 
 +| Total Personnel Cost (€) | 44 352.00 | 
 +| Material Cost per Prototype (€) | 155.25 | 
 +| Total Development Cost incl. Prototype (€) | 44 507.25 |
 ==== Quality ==== ==== Quality ====
  
-== Quality Metrics and Review Process ==+== Quality Metrics & Requirements ==
  
-To ensure the smart water bottle system meets all functional, safety, and performance requirements, a set of quality metrics was defined. These metrics allow us to verify that each component and the complete system works as intended and safely.+To ensure the smart water bottle prototype meets all functional, safety, and performance requirements, a set of measurable quality metrics has been defined. These metrics are based on the intended design performance of the prototype and will be used during testing and validation.
  
-== Physical Specifications == +^ Metric ^ Description ^ Threshold ^ Review Method ^ 
-The prototype is built around a 0.5 L bottle with the following approximate dimensions and weights: +| Physical Dimensions | Bottle size must remain practical and portable for daily use | Height 25–27 cm, diameter 7–8 cm | Physical measurement | 
-  * Capacity: 0.5 L +| Weight & Ergonomics | Bottle should remain comfortable to carry when empty or full | Empty weight 300–380 g, full weight below 900 g | Scale measurement and user handling review | 
-  * Height: 25–27 cm +| Water Quality Monitoring | TDS sensor should provide useful and stable water quality readings | Within ±10 % of calibrated reference values | Sensor calibration and comparison testing | 
-  * Diameter: 7–8 cm +| Temperature Monitoring | Temperature sensor should provide reliable readings | Within ±2 °C of reference values | Reference thermometer comparison | 
-  * Empty weight (including electronics and battery pack): 300–380 g +| Water Level Detection | Pressure sensor should correctly identify fill level states | Empty, half-full, full states detected correctly | Controlled fill testing | 
-  * Full weight (with water): 800–880 g +| Motion & Orientation | Accelerometer should detect movement and bottle position | Correct detection of movement and upright state | Functional testing | 
-These values are verified during assembly to ensure the prototype remains comfortable to hold and carry, and that the added weight of the integrated electronics and battery pack does not significantly compromise usability compared to a standard reusable water bottle.+| Energy Efficiency | System should minimize unnecessary power consumption | Idle below 100 mW, normal use below 1 W | Power consumption measurement | 
 +| Battery Runtime | Battery should provide practical daily autonomy | Estimated 2–7 days per charge depending on use | Runtime testing | 
 +| Charging Performance | Charging system must safely recharge battery pack | Stable charging with no overheating | Charging cycle observation | 
 +| Water Resistance | Electronics housing must resist splashes and normal cleaning | No internal moisture ingress | Splash and sealing inspection | 
 +| UV-C Safety Control | UV-C may only activate in safe operating condition | Activation only when bottle is fully closed | Safety logic testing | 
 +| Electrical Protection | Internal electronics must be protected from faults | Fuse, BMS, and regulators function correctly | Electrical inspection | 
 +| Mechanical Durability | Bottle must withstand normal daily handling | No damage during normal use | Handling and inspection | 
 +| User Interface Visibility | LEDs should clearly communicate bottle status | Visible and understandable indicators | Functional review | 
 +| System Reliability | System should operate consistently without failure | Stable operation during extended use | Long-duration operation testing |
  
-== Sensors and Accuracy ==+== Review and Validation Process ==
  
-All sensors are tested for accuracy and reliability. The TDS sensor must measure water quality within ± 10 % of reference values. The temperature sensor should read within ± 2 °C.+As the final prototype is still under development, the table above defines the intended quality requirements and planned validation criteria. Once assembly is complete, each metric will be reviewed through practical testing, calibration, inspection, and functional verification.
  
-The pressure sensor (FSR406) is used to determine the water level in the bottle. It measures the force exerted by the water on the bottom of the bottle. The water height can then be calculated using the formula:+Any requirement that does not meet its defined threshold will be addressed through design improvements, software calibration, or component adjustment before final approval.
  
-h = F / (A · ρ · g)+== Acceptance Criteria ==
  
-Where: +The smart water bottle prototype will be considered acceptable when all defined quality thresholds are achieved and no functional or safety issues remain. 
-  * h = water height (m) +==== People & Stakeholder Management ==== 
-  * F = force measured by the sensor (N) +The stakeholder analysis is meant to assist the project group to understand who has interest and power over the project. It is a way to recognise who will be affected by the final product and to be able to categorize everyone involved in order to plan how the project group will interact with them throughout the project.
-  * A = area of the bottle base in contact with water (m²) +
-  * ρ = density of water (~1000 kg/m³) +
-  * g = gravitational acceleration (~9.81 m/s²)+
  
-This allows the system to detect empty, half-full, or full states accurately. The accelerometer (LIS3DHTR) is tested to ensure it correctly detects motion and orientation, allowing the system to respond appropriately to movement. Sensor outputs are compared against reference measurements, with calibration applied in software if necessary.+Stakeholders will be split into four separate groups: Key Figure, Influencer, Interested and lastly, Spectator. All the stakeholders would be placed against 2 axes, representing their interests and influence. As this is an internal project, the number of stakeholders is limited.
  
-== Power and Battery Performance ==+**Mendelow Matrix** 
 +- **Key Figures** (High Interest, High Influence): Clients, Lecturers / Coordinator, Project Group 
 +- **Influencers** (Low Interest, High Influence): ISEP Board, Competitors 
 +- **Interested** (High Interest, Low Influence): Material Providers, Future Investors 
 +- **Spectators** (Low Interest, Low Influence): Logistic Partners
  
-The system's power consumption is monitored in all operating modes. Idle power should stay below 100 mW and normal sensing should remain below 1 W. The battery pack consists of three Panasonic NCR18650B cells (3400 mAh each) in a 3S configuration, providing a nominal voltage of 11.1 V. Depending on usage intensity and the frequency of UV-C sterilisation cycles, the pack is expected to provide between two and seven days of autonomy on a single charge. Full charging is performed via the dedicated 3S 12.6 V / 2 A external charger, and cell balancing and thermal behaviour are verified during testing to ensure no overheating occurs under any operating condition.+Figure {{ref>fig:stakeholders}} shows the stakeholder analysis.
  
-== System Reliability and User Interface ==+<WRAP centeralign> 
 +<figure fig:stakeholders> 
 +{{ :report:traquscopev2.png |}} 
 +<caption>TRAQUA Stakeholder</caption> 
 +</figure> 
 +</WRAP>
  
-The system is expected to operate reliably, with uptime of at least 95 %, no unexpected resets, and consistent sensor readings over time. User feedback is provided through onboard status LEDs, which are tested for correct behavior and clear visibility in normal  lighting conditions.+__Analysis of Stakeholders__
  
-== Electrical Safety ==+**Spectators — Logistics Partners:** While not directly involved, they may eventually experience benefits from an improved inspection system. However, their role is passive, and they will not influence or interact with the project.
  
-All electrical components are designed and tested for safe operation. A 1 A 5×20 mm slow-blow glass fuse protects the system from overcurrent, and a dedicated 3S BMS continuously monitors the battery pack for over-voltage, under-voltage, over-current, and short-circuit conditions, while also balancing the cells during charging. A MOSFET (IRLZ44N) controls high-power components safely, and a step-down LM2596 buck converter provides a regulated 5 V rail for the microcontroller from the 12 V pack. Circuits are fully isolated to prevent short circuits.+**Interested:** 
 +- **Material Providers:** Supply components and materials; their pricing, availability, and lead times directly affect the project budget and timeline. 
 +- **Future Investors:** Will potentially invest money into the product, so a close eye must be kept on their expectations.
  
-The bottle incorporates a circuit-killer switch in the base, implemented as a magnetic reed switch (SPST-NO), which automatically disconnects power when the bottle is disassembled for cleaning. The geometrical design in the bottle cap ensures no UV light escapes when the bottle is closed.+**Influencers:** 
 +- **ISEP Board:** Though not actively participating, defines academic frameworks and grading guidelines. 
 +- **Competitors:** TRAQUA must keep a sharp eye on what competitors develop while keeping their product fresh and at a decent price.
  
-During assembly of the prototype, careful safety measures will be taken to minimise exposure to UV-C light, including proper handling, protective gear, and avoiding powering the LED unnecessarily.+**Key Figures:** 
 +- **Clients:** Central to the project's direction and success — they define the problem and validate the solution. 
 +- **Lecturers / Coordinator:** Advise the group, evaluate project quality, offer ongoing feedback, and determine part of the final grade. 
 +- **Project Group:** The student developers have the most motivation to succeed and interest in creating a functional system.
  
-== Review and Testing Process ==+__Communication Strategy__
  
-Quality is verified through functional testing, calibration, power measurements, long-term operation, and safety testing. Components are first tested individually, then as part of the complete system. Any metric that does not meet its threshold is documented, corrected, and retested until all standards are met.+Each stakeholder group requires a different communication approach based on their position in the Mendelow Matrix. The table below summarizes how the project group communicates with each party and what is expected in return.
  
-== Acceptance Criteria ==+| Stakeholder | Strategy | From us → them | From them → us | Channel | Frequency | 
 +|---|---|---|---|---|---| 
 +| **Clients** | Manage Closely | Progress updates, prototype demos, design decisions, clarification requests | Requirements, feedback, validation, priority changes | Meetings, email, demos | Bi-weekly + milestones | 
 +| **Lecturers / Coordinator** | Manage Closely | Deliverables, reports, presentations, questions | Feedback, grading criteria, guidance, corrections | Scheduled meetings, email, Moodle/wiki uploads | Weekly + each deliverable | 
 +| **Project Group** | Manage Closely | Task status, blockers, decisions, shared documents | Same — bidirectional | Daily standups, Discord/Teams, Git, shared drive | Daily | 
 +| **ISEP Board** | Keep Satisfied | Final deliverables, compliance with academic standards | Academic framework, regulations, grading rules | Formal submissions via coordinator | At defined academic checkpoints | 
 +| **Competitors** | Keep Satisfied (monitor) | No direct communication | Market info gathered via public sources (websites, patents, product releases) | Market research, web monitoring | Monthly scan | 
 +| **Material Providers** | Keep Informed | Quotes requests, orders, specifications | Pricing, availability, lead times, VAT, shipping | Email, web forms, phone | As needed during sourcing phases | 
 +| **Future Investors** | Keep Informed | Pitch, final presentation, poster, brochure, leaflet | Interest signals, questions, funding decisions | Final presentation, marketing materials | End of project | 
 +| **Logistic Partners** | Monitor (minimal effort) | No active communication | Passive — potential future end-users | N/A (indirect) | None during project |
  
-A deliverable is considered acceptable when all defined thresholds are met, the system operates reliably, and no safety issues are present.+**Communication principles:** 
 +- **Single point of contact:** each external stakeholder is handled by one designated team member to avoid mixed messages. 
 +- **Documentation:** all formal communication (client meetings, lecturer feedback, supplier quotes) is logged in the project wiki. 
 +- **Escalation:** blockers are raised in the next standup; client/lecturer issues are escalated within 24h. 
 +- **Feedback loop:** after each milestone, feedback received is reviewed in the following sprint planning. 
 +==== Communication ====
  
-==== People & Stakeholder Management ==== +TRAQUA uses a structured set of communication channels, each chosen for a specific purpose: fast internal coordination, formal documentation, stakeholder alignment, and customer engagement.
-The stakeholder analysis is meant to assist the project group to understand who has interest and power over the project. It is a way to recognise who will be affected by the final product +
-and to be able to categorize everyone involved in order to plan how the project group will interact with +
-them throughout the project. +
-Stakeholders will be split into four separate groups: Key Figure, Influencer, Interested and lastly, +
-Spectator. All the stakeholders would be placed against 2 axes, representing their interests and +
-influence. As this is an internal project, the number of stakeholders is limited.+
  
 +**Internal Team Communication**
  
-**Mendelow Matrix**+- **WhatsApp** — primary channel for day-to-day coordination, quick questions, and informal idea sharing. Fast and low-friction, ideal for immediate feedback. 
 +- **Microsoft Teams** — used to store documents, organize files, and hold formal online meetings when in-person is not possible. Channels are structured by workstream (e.g., Hardware, Software, Documentation, Marketing). 
 +- **Jira** — sprint backlog, task assignment, sprint retrospectives, and all sprint-related activities are documented and tracked here. Provides traceability from user story to delivered feature. 
 +- **Git (repository)** — source code, schematics, and technical drawings are version-controlled. Commit messages reference Jira tickets for traceability. 
 +- **Project Wiki** — central knowledge base for the report, meeting minutes, decisions, and deliverables.
  
-Key Figures: Clients, Lecturers / Coordinator and the Project Group+**Communication with Lecturers / Coordinators**
  
-Influencers (Low Interest, High Influence): ISEP BOARD+Meetings with teachers are organized every **Thursday**. The team is obliged to share an agenda by **Tuesday evening** at the latest so that teachers can prepare any necessary materials. These meetings are used to show the team's progress, ask questions, and share ideas.
  
-Interested (High Interest, Low Influence): Material Providers+After each teacher meeting, the team gathers to hold a **retrospective** and discuss the upcoming sprint. Outcomes are logged in Jira and the wiki.
  
-Spectators (Low interest, Low influence): Logistic Parteners+| Item | Detail | 
 +|---|---| 
 +| Frequency | Weekly (Thursday) | 
 +| Agenda deadline | Tuesday 23:59 | 
 +| Channel | In-person / Teams | 
 +| Output | Meeting minutes in wiki, action items in Jira | 
 +| Escalation | Email to coordinator for urgent issues |
  
-Figure {{ref>fig:stakeholders}} ... is a stakeholder Analaysis+**Communication with Clients**
  
 +Clients define the problem and validate the solution, so regular structured contact is essential.
  
-<WRAP centeralign> +- **Bi-weekly progress meetings** — demo current state, gather feedback, confirm direction. 
-<figure fig:stakeholders> +- **Milestone demos** — aligned with major deliverables (interim presentation, functional tests, final prototype). 
-{{ :report:traquscopev2.png |}} +- **Email** — for formal questions, requirement clarifications, and document sharing. 
-<caption> TRAQUA Stakeholder</caption> +- **Meeting minutes** shared within 24h of each meeting to confirm understanding.
-</figure> +
-</WRAP>+
  
 +**Communication with Suppliers**
  
 +To maintain good contact with suppliers, regular meetings are planned every **one to two months**. This allows both the supplier and TRAQUA to gather all their information and questions and discuss everything together, instead of sending scattered emails throughout the week or month. This batching saves everyone from dealing with many small tasks.
  
-__Analysis of Stakholders +- **Primary channel:** email for quotes, orders, and specifications. 
-____+- **Backup channel:** phone for urgent availability or lead-time issues. 
 +- **Single point of contact:** one team member owns each supplier relationship to avoid mixed messages. 
 +- **Documentation:** all quotes, confirmations, and delivery dates are archived in the Teams supplier folder.
  
 +**Communication with Customers**
  
-Spectator: Logistics Partners: While not directly involved, they may eventually experience benefits from +Customers will have the opportunity to subscribe to a **free newsletter** that will update them on the company's goals and provide additional composting tips. The application will also include **easy access to customer support**, ensuring that all customers can reach the company easily.
-an improved inspection system. However, their role is passive, and they will not influence or +
-interact with the project.+
  
-Interested: +- **Newsletter** — monthly, opt-in, covering company updates and composting tips. 
-Project Group: The student developers have the most motivation to succeed and interest in +- **In-app support** — chat / contact form for direct questions. 
-creating a functional system but have limited influence over scope once defined by +- **Social media** — for announcements, community engagement, and marketing. 
-stakeholders. +- **Response SLA** — customer support queries answered within 48h.
-Future investors: They will invest money into a product so a close look on them must be keept+
  
 +**Communication with Charities / Partners**
  
-Influencer:    +To keep charities involved, the company will organize regular meetings with them to discuss relevant topics. This helps maintain strong and high-quality partnerships.
-ISEP Board: though not actively participating in the project, defines +
-academic frameworks and grading guidelines. +
-Competiros: TRAQUA must keep an sharp eye on what the competitors develop and do while keeping their product fresh and at a decent price.+
  
-Key figures: Clients are central to the project's direction and success. They define the problems. +- **Frequency:** quarterly alignment meetings. 
 +- **Purpose:** discuss joint initiatives, impact reporting, and upcoming campaigns. 
 +- **Channel:** in-person or video call, minutes shared afterward.
  
 +**Communication Tools Summary**
  
-Lecturers: Advise the group and evaluate project quality. Offers ongoing feedback and +| Tool | Purpose | Audience | 
-determines part of the final grade. +|---|---|---| 
-==== Communications ==== +| WhatsApp | Fast internal chat | Project Group | 
-TRAQUA has several ways of communication. Firstly, the team uses WhatsApp to communicate. This makes communication easy and provides a fast way to share ideas and receive feedback. Microsoft Teams channels are used to store documents and organize files depending on the team’s needs.+| Microsoft Teams | File storage, formal meetings | Project Group, Lecturers | 
 +| Jira | Sprint management, task tracking | Project Group | 
 +| Git | Version control (code, schematics) | Project Group | 
 +| Wiki | Documentation, knowledge base | Project Group, Lecturers | 
 +| Email | Formal external communication | Lecturers, Clients, Suppliers | 
 +| Newsletter | Customer engagement | Customers | 
 +| In-app support | Customer service | Customers |
  
-Meetings with teachers are organized every Thursday. The team is obliged to share an agenda by Tuesday evening at the latest so that teachers can prepare any necessary materials. These meetings are used to show the team’s progress, ask questions, and share ideas. After these meetings, the team gathers to hold retrospectives and discuss the upcoming sprint.+**Communication Principles**
  
-These sprint retrospectives and all sprint-related activities are documented and kept in Jira.+- **Right channel for the right message:** urgent = WhatsApp; formal = email; technical = Jira/Git; knowledge = wiki. 
 +- **Asynchronous by default:** written communication preferred to respect everyone's schedule; meetings reserved for decisions and alignment. 
 +- **Document everything:** every meeting produces minutes; every decision is logged. 
 +- **Acknowledge receipt:** messages requiring action are acknowledged within 24h, even if the full answer comes later. 
 +- **No silent blockers:** any blocker is raised in the next standup or immediately via WhatsApp if critical.
  
-To maintain good contact with suppliers, it is important to keep each other informed. That’s why regular meetings are useful. Every one or two months, a meeting is planned. This allows both the supplier and TRAQUA to gather all their information and questions and discuss everything together, instead of sending multiple emails throughout the week or month. This saves everyone from dealing with many small tasks.+**Communication Risks & Mitigation**
  
-Customers will have the opportunity to subscribe to a free newsletter that will update them on the company’s goals and provide additional composting tips. The application will also include easy access to customer support, ensuring that all customers can reach the company easily.+| Risk | Impact | Mitigation | 
 +|---|---|---| 
 +| Message overload on WhatsApp | Important info gets lost | Use Teams/Jira for anything needing traceability; WhatsApp only for quick sync | 
 +| Supplier delays in response | Sourcing timeline slips | Contact multiple suppliers in parallel; escalate after 5 business days of silence | 
 +| Client unavailable for feedback | Design decisions blocked | Book meetings 2 weeks in advance; have a backup decision-maker identified | 
 +| Missed lecturer agenda deadline | Meeting less productive | Recurring Tuesday reminder in team calendar | 
 +| Meeting minutes not documented | Decisions forgotten / disputed | Rotating minute-taker role, published within 24h | 
 +| Single point of failure on a channel | Team member unreachable | Key info duplicated in wiki; no critical info lives only in chat | 
 +==== Risk Management ====
  
-To keep charities involved, the company will also organize meetings with them to discuss relevant topics. This helps maintain strong and high-quality partnerships. +This chapter identifies the risks that may arise during the TRAQUA project and defines how they will be prevented, monitored, and managed if they occur. Each risk is assessed on two dimensions: **likelihood** (how probable it is) and **severity** (how damaging the impact would be). The product of these two gives a **risk score**, which determines the priority for mitigation.
-==== Risk ==== +
-This chapter handles the possible risks that may be met during the project and ways to tackle them. This is shown in the table below.+
  
-Table {{ref>tab:riskmnagement}} ... +=== Risk Classification ===
-<table tab:riskmnagement> +
-^ Risk ^ Possibility ^ Outcome ^ Prevention ^ Measure taken ^   +
-| Common illness | Possible | The team will be set back for a moment | Good health care and communication properly with team | Assume tasks for ill members | +
-|Tasks not completed on time | Possible | Set back until tasks are completed | Proper planning and time management| Tasks require proper planning. The advice on a new plan | +
-| Lack of technical knowledge | Likely | The team might not be able to realize certain parts of the project | Research proper technical skills needed, practice these, and ask for help if needed | Research what skills the team is lacking. | +
-| The departure of a project member | Possible | The team will fall behind | Proper communication betwen members to be able to react to a sign of a member dropping out quickly and effectively | Work on the tasks of the dropped member | +
-| Loss of data | Unlikely | Loss of data  files | Frequent backup up | Restore files from backup | +
-| Insufficient testing | Unlikely | Product delivered with less quality | Test plan correctly Review test reports and run test again | Keep taps on testing | +
-| Lack of money to scale the project | Possible | Plan materials according to the budget | Proper planning | Do not go over budget | +
-</table>+
  
 +Risks are categorized by type to make it easier to assign ownership and response strategy:
  
-**Risk analaysis**+  * **Project risks** — affect schedule, scope, budget, or team capacity 
 +  * **Technical risks** — affect hardware, firmware, software, or integration 
 +  * **Operational risks** — affect day-to-day execution and infrastructure 
 +  * **Safety & environmental risks** — affect user safety, health, or the environment 
 +  * **Security & data risks** — affect confidentiality, integrity, and privacy
  
-<WRAP centeralign> +=== Likelihood and Severity Scales ===
-<figure fig:rismatrix> +
-{{ :report:riskmatrixtraqua.png |}} +
-<caption>Risk matrix</caption> +
-</figure> +
-</WRAP>+
  
 +<table tab:riskscales>
 +^ Level ^ Likelihood ^ Severity ^
 +| 1 | Improbable | Negligible |
 +| 2 | Remote | Marginal |
 +| 3 | Possible | Moderate |
 +| 4 | Likely | Critical |
 +| 5 | Frequent | Catastrophic |
 +</table>
  
 +**Risk score** = Likelihood × Severity. Scores are interpreted as:
  
-Data leaks (12) +  * **1–4 Low** — accept and monitor 
-The system will be processing sensitive business data, which could, in theory, be leaked to unauthorized parties. This security breach could affect all users of the application. Due to the reputational damage to the product, potential financial losses for the customers, and the legal liability this entails, this risk is classified as catastrophic. And, since the likelihood of malicious actors trying to exploit the system increases with the amount of users, this risk should be considered as probable.+  * **5–9 Medium** — actively mitigate 
 +  * **10–15 High** — mitigate before development milestones 
 +  * **16–25 Critical** — must be addressed before the project advances
  
 +=== Risk Register ===
  
-Battery exploding (8) +The table below lists all identified risks, their assessment, the prevention strategy (applied before the risk occurs), and the response plan (applied if it does occur). Each risk has an assigned **owner** responsible for monitoring it throughout the project.
-This risk refers to the physical hardware used to run or interact with the application particularly mobile or IoT devices experiencing battery failure or thermal runaway. Although rare in modern consumer hardware, the possibility cannot be entirely dismissed, especially if the application runs intensive background processes that cause sustained high CPU or GPU usage. The likelihood of this occurring is classified as remote, given the robustness of battery management systems in contemporary devices. However, the severity is catastrophic, as battery explosions can cause physical harm to users or damage to property, making this a high-priority risk despite its low probability.+
  
 +<table tab:riskregister>
 +^ ID ^ Risk ^ Category ^ Likelihood ^ Severity ^ Score ^ Prevention ^ Response ^ Owner ^
 +| R01 | Common illness | Project | Possible (3) | Marginal (2) | 6 | Good health practices; clear task documentation so work isn't siloed | Redistribute tasks temporarily; extend deadline if critical path affected | Project Manager |
 +| R02 | Tasks not completed on time | Project | Possible (3) | Moderate (3) | 9 | Realistic planning with buffer; weekly sprint reviews; early flagging of blockers | Replan sprint; reprioritize backlog; notify supervisor | Project Manager |
 +| R03 | Lack of technical knowledge | Project | Likely (4) | Moderate (3) | 12 | Skills gap analysis at kickoff; training time allocated; mentor/supervisor support | Pair programming; request expert help; simplify scope if blocker persists | Technical Lead |
 +| R04 | Team member departure | Project | Possible (3) | Critical (4) | 12 | Strong communication; documented processes; cross-training on key tasks | Reassign tasks; revise scope; escalate to supervisor | Project Manager |
 +| R05 | Loss of data / code | Operational | Remote (2) | Moderate (3) | 6 | Git version control; cloud backups (GitHub + Drive); weekly backup checks | Restore from most recent backup; document lost work | All members |
 +| R06 | Insufficient testing | Technical | Remote (2) | Critical (4) | 8 | Written test plan; automated tests where possible; peer review of test reports | Extend testing phase; add regression tests; document known issues | Technical Lead |
 +| R07 | Budget overrun | Project | Possible (3) | Moderate (3) | 9 | Component pricing confirmed before purchase; 15% contingency reserve | Substitute cheaper components; deprioritize non-essential features | Project Manager |
 +| R08 | Data leaks | Security & data | Likely (4) | Catastrophic (5) | 20 | Encrypted communication (TLS); secure credential storage; input validation; access control on BLE pairing | Revoke affected keys; notify users; patch vulnerability; post-mortem review | Technical Lead |
 +| R09 | Battery failure / thermal runaway | Safety | Remote (2) | Catastrophic (5) | 10 | Use certified Li-ion cells; include BMS protection circuit; thermal testing during prototype phase | Disconnect battery; trigger product recall procedure if shipped | Hardware Lead |
 +| R10 | Application downtime | Operational | Frequent (5) | Negligible (1) | 5 | Cloud auto-scaling; health checks; graceful degradation on frontend | Auto-recovery; manual restart if needed; status page notification | Technical Lead |
 +| R11 | API downtime (third-party) | Operational | Remote (2) | Marginal (2) | 4 | Retry logic with exponential backoff; fallback behaviour; cache recent responses | Switch to fallback; notify users of degraded service | Technical Lead |
 +| R12 | Battery chemical residue | Safety & environmental | Improbable (1) | Marginal (2) | 2 | Follow electronics safety protocols; use sealed battery compartments | Follow hazardous waste disposal procedure | Hardware Lead |
 +| R13 | UV-C radiation exposure | Safety | Improbable (1) | Negligible (1) | 1 | N/A for standard operation; enclosures if UV-C modules used | Stop use immediately; consult safety documentation | Hardware Lead |
 +| R14 | Short circuit | Technical | Improbable (1) | Negligible (1) | 1 | Circuit protection; certified components; PCB design review | Isolate affected unit; check for damage before reuse | Hardware Lead |
 +| R15 | Supply chain delays (components) | Operational | Possible (3) | Moderate (3) | 9 | Order components early; identify 2+ suppliers per critical part | Substitute equivalent part; adjust schedule; notify supervisor | Hardware Lead |
 +| R16 | Scope creep | Project | Likely (4) | Moderate (3) | 12 | Clearly defined backlog; change control for new requirements; supervisor sign-off | Push new requests to backlog; renegotiate scope if essential | Project Manager |
 +| R17 | Sensor calibration drift | Technical | Possible (3) | Moderate (3) | 9 | Use calibrated reference solutions; periodic recalibration; temperature compensation | Recalibrate; flag readings; document drift pattern | Technical Lead |
 +| R18 | Poor team communication | Project | Possible (3) | Moderate (3) | 9 | Weekly standup; shared tools (Slack/Discord, Trello); written meeting notes | Address in retrospective; adjust communication rhythm | Project Manager |
 +</table>
  
-Application downtime (4) +=== Risk Matrix ===
-Application downtime refers to periods during which the system becomes unavailable to users. This can occur due to infrastructure failures, deployment errors, resource exhaustion, or unexpected spikes in traffic. Given that the application is cloud-based and relies on several interconnected services, the probability of experiencing some form of downtime is frequent. However, its severity is classified as negligible, as modern deployment practices — such as rolling updates, health checks, and auto-recovery mechanisms ensure that any disruption is typically brief and affects only a limited number of users at any given time. Proper monitoring and alerting further mitigate the impact.+
  
 +The risk matrix below plots each risk by likelihood (y-axis) and severity (x-axis). Risks in the top-right corner are the highest priority.
 +
 +<WRAP centeralign>
 +<figure fig:riskmatrix>
 +{{ :report:riskmatrixtraqua.png |}}
 +<caption>Risk matrix — likelihood vs. severity</caption>
 +</figure>
 +</WRAP>
  
-API downtime (4) +=== Risk Monitoring and Review ===
-API downtime refers to the unavailability of third-party or internal APIs that the application depends on to function. This includes payment processors, authentication services, AI model endpoints, or data providers. Such outages can degrade or fully disable core application features. The likelihood of API downtime is classified as remote, since reputable providers maintain high availability SLAs; however, the severity is marginal, as only a subset of users or features will typically be affected during any given outage. Implementing retry logic, fallback mechanisms, and graceful error handling reduces the impact significantly.+
  
 +Identifying risks once is not enough — they must be tracked throughout the project. The following monitoring process will be applied:
  
-Battery residue in materials (2) +  * **Weekly risk check** during sprint reviews: the team reviews the register and flags any change in likelihood or impact. 
-This risk concerns the presence of hazardous chemical residues in the batteries of hardware components used in development or production environments. Battery residue such as lithium compounds or electrolyte leakage — can pose environmental and health hazards if not properly handled or disposed of. The likelihood of encountering this risk is improbable under normal operating conditions, and the severity is marginal, as exposure is limited to those directly handling physical hardware components. Following standard electronics disposal and safety protocols effectively mitigates this risk.+  * **Milestone reassessment**: before each major milestone (design review, prototype, interim report, final delivery), the full register is re-evaluated. 
 +  * **New risk intake**: any team member can propose a new risk at any time; the Project Manager assesses it and adds it to the register. 
 +  * **Closed risks**: once a risk is no longer relevant (e.g., a phase is completed), it is marked closed but kept in the register for traceability.
  
 +=== Detailed Risk Descriptions ===
  
-UV-C radiation (1) +== R08 — Data leaks (score 20, Critical) == 
-UV-C radiation refers to the potential exposure to ultraviolet light emitted by certain hardware components—such as UV-C sterilization modules that may be used in specialized deployment environments. This risk is improbable in the context of a typical software application, as UV-C sources are not standard components in consumer or enterprise hardware setups. The severity is classified as negligible, since even in environments where such components exist, safety enclosures and regulatory compliance requirements strictly limit human exposure. This risk is included for completeness but presents no meaningful threat to standard application development or deployment.+The system processes sensitive data — water-quality measurements tied to user accounts and potentially location information. Unauthorized access could affect all users, cause reputational damage, trigger legal liability under GDPR, and erode trust in the product. Likelihood is high because malicious actors routinely target IoT endpoints and mobile APIs, and attack surface grows with user count. Prevention focuses on encryption in transit and at rest, strict access control on BLE pairing, and input validation. If a breach occurs, the response is to revoke affected credentials immediately, notify affected users within the GDPR 72-hour window, patch the vulnerability, and conduct a post-mortem.
  
 +== R09 — Battery failure (score 10, High) ==
 +The TRAQUA device uses a rechargeable Li-ion battery. While rare in modern hardware, thermal runaway can cause physical harm or property damage — making severity catastrophic despite low likelihood. Prevention relies on certified cells with an integrated Battery Management System (BMS), thermal testing during prototyping, and sealed battery compartments. Response: immediate disconnection, and if shipped units are affected, a recall procedure in coordination with the supervisor.
  
-Short circuit (1) +== R03 — Lack of technical knowledge (score 12, High) == 
-A short circuit risk refers to electrical faults in the hardware infrastructure supporting the application, including servers, networking equipment, and end-user devices. While short circuits can cause equipment damage or data loss, their occurrence is improbable given the use of modern, certified hardware with built-in circuit protection. The severity is negligible, as affected equipment is typically isolated automatically by circuit breakers or surge protectors, and redundant infrastructure ensures service continuity. Routine hardware maintenance and compliance with electrical safety standards are sufficient to keep this risk at an acceptable level+The project combines electronics, firmware (ESP32), mobile app development, and sensor calibration — a broad stack that no single team member fully masters at the start. Prevention is done through a skills gap analysis at kickoff, allocated training time in the first sprints, and proactive use of the supervisor and external mentors. If a specific blocker arises during development, the response is pair programming, requesting expert help, or simplifying scope on the affected feature rather than letting it block the critical path.
  
 +== R16 — Scope creep (score 12, High) ==
 +As the project progresses, stakeholders or team members may propose new features that seem small individually but collectively derail the schedule. Prevention is a clearly defined backlog with supervisor-approved scope, and a change-control rule: any new requirement is added to the backlog, not to the current sprint. Response: if a new request is genuinely essential, an existing item is removed to make room, keeping total scope constant.
  
 +== R04 — Team member departure (score 12, High) ==
 +If a team member drops out mid-project, remaining members absorb their workload, which can cascade into further delays. Prevention relies on documentation (so no knowledge is locked in one person's head), cross-training on critical tasks, and early warning signs picked up in weekly retrospectives. Response: immediate task reassignment, scope revision if needed, and escalation to the supervisor.
 ==== Procurement ==== ==== Procurement ====
  
Line 355: Line 479:
 == Procurement Table == == Procurement Table ==
  
-^ Item ^ Supplier ^ Manufacturer ^ Quantity ^ Lead Time (Days) ^ Notes ^ +^ Item ^ Supplier ^ Backup Supplier ^ Manufacturer ^ Quantity ^ Lead Time (Days) ^ Notes ^ 
-| TDS Sensor (SEN0244) | Mauser | TPXCKZ | 1 | 2–4 | Water quality measurement | +| TDS Sensor (SEN0244) | Mauser | DigiKey | TPXCKZ | 1 | 2–4 | Water quality measurement | 
-| MOSFET (IRLZ44N) | Mauser | Infineon | 1 | 1–3 | Switching component | +| MOSFET (IRLZ44N) | Mauser | DigiKey | Infineon | 1 | 1–3 | Switching component | 
-| Battery (NCR18650B) | Mauser | Panasonic | 3 | 2–4 | 3S pack power supply | +| Battery (NCR18650B) | Mauser | Grandado | Panasonic | 3 | 2–4 | 3S pack power supply | 
-| BMS (3S) | Mauser | Generic | 1 | 2–4 | Battery protection and balancing | +| BMS (3S) | Mauser | DigiKey | Generic | 1 | 2–4 | Battery protection and balancing | 
-| Battery Holder (1×18650) | Mauser | Generic | 3 | 2–4 | Cell mounting | +| Battery Holder (1×18650) | Mauser | Farnell | Generic | 3 | 2–4 | Cell mounting | 
-| Charging Port (DC connector) | Mauser | Generic | 1 | 2–4 | External charger input | +| Charging Port (DC connector) | Mauser | DigiKey | Generic | 1 | 2–4 | External charger input | 
-| Buck Converter (LM2596) | Mauser | Generic | 1 | 2–4 | 12 V → 5 V regulation | +| Buck Converter (LM2596) | Mauser | Grandado | Generic | 1 | 2–4 | 12 V → 5 V regulation | 
-| Magnetic Reed Switch (SPST-NO) | Mauser | Generic | 1 | 2–4 | Circuit-killer at bottle base | +| Magnetic Reed Switch (SPST-NO) | Mauser | Farnell | Generic | 1 | 2–4 | Circuit-killer at bottle base | 
-| Fuse (1 A, 5×20 slow blow) | Mauser | Eska | 1 | 1–3 | Overcurrent protection | +| Fuse (1 A, 5×20 slow blow) | Mauser | DigiKey | Eska | 1 | 1–3 | Overcurrent protection | 
-| Fuse Holder (5×20) | Mauser | Generic | 1 | 1–3 | Fuse mounting | +| Fuse Holder (5×20) | Mauser | Farnell | Generic | 1 | 1–3 | Fuse mounting | 
-| Breadboard (Protoboard 50×70) | Mauser | Generic | 1 | 1–3 | Prototype circuit board | +| Breadboard (Protoboard 50×70) | Mauser | DigiKey | Generic | 1 | 1–3 | Prototype circuit board | 
-| 1.1 mm Wire (AWG26) | Mauser | Goobay | 1 | 1–3 | UV-C light wiring | +| 1.1 mm Wire (AWG26) | Mauser | DigiKey | Goobay | 1 | 1–3 | UV-C light wiring | 
-| Accelerometer (LIS3DHTR) | Kiwi Electronics | STMicroelectronics | 1 | 3–6 | Motion and orientation detection | +| Accelerometer (LIS3DHTR) | Kiwi Electronics | Farnell | STMicroelectronics | 1 | 3–6 | Motion and orientation detection | 
-| UV-C LED Module | Fruugo | Generic | 1 | 5–8 | Water sterilisation | +| UV-C LED Module | Fruugo | DigiKey | Generic | 1 | 5–8 | Water sterilisation | 
-| Pressure Sensor (FSR406) | Fruugo | JETTING | 1 | 5–8 | Water level measurement | +| Pressure Sensor (FSR406) | Fruugo | Fruugo | JETTING | 1 | 5–8 | Water level measurement | 
-| Temperature Sensor (KY-015 DHT) | Fruugo | AOKIN | 1 | 5–8 | Temperature and humidity sensing | +| Temperature Sensor (KY-015 DHT) | Fruugo | Fruugo | AOKIN | 1 | 5–8 | Temperature and humidity sensing | 
-| Breadboard Kit | Joom | Generic | 1 | 5–10 | Wires, resistors, LEDs, etc. | +| Breadboard Kit | Joom | Fruugo | Generic | 1 | 5–10 | Wires, resistors, LEDs, etc. | 
-| Activated Carbon Filter | Joom | Generic | 1 | 5–10 | Improves taste | +| Activated Carbon Filter | Joom | Fruugo | Generic | 1 | 5–10 | Improves taste | 
-| Microcontroller (ESP32 DevKit V1) | Joom | Espressif | 1 | 5–10 | Main controller | +| Microcontroller (ESP32 DevKit V1) | Joom | Fruugo | Espressif | 1 | 5–10 | Main controller | 
-| Charger (3S 12.6 V / 2 A) | Joom | Generic | 1 | 5–10 | External battery pack charger | +| Charger (3S 12.6 V / 2 A) | Joom | Worten | Generic | 1 | 5–10 | External battery pack charger | 
-| Total Components | - | - | 22 items | - | All required parts |+| Total Components | - | - | - | 22 items | - | All required parts |
 ==== Project Plan ==== ==== Project Plan ====
  
-The project was structured across eight sprints, preceded by a pre-work phase dedicated to topic selection and initial setup. Each sprint spans approximately one week, running from early March to late June 2026. +The project was structured across eight sprints, preceded by a pre-work phase dedicated to topic selection and initial setup. Each sprint spans approximately one week, running from early March to late June 2026. Project management was handled in Jira, where all tasks were tracked and assigned across the team. The Gantt chart provides a visual overview of the planned timeline, grouping activities by sprint and category.
-The project management was handled using Jira, where all tasks were tracked and assigned across the team. The Gantt chart above provides a visual overview of the planned timeline, grouping activities by sprint and category. +
-The pre-work phase covered foundational scrum activities such as stand-ups, retrospectives, and sprint demos, as well as general activities including assigning roles. Sprint 1 focused on initial research, documentation, and structural work. Subsequent sprints progressively addressed design, prototyping, coding, and testing. The final sprints are dedicated to the interim and final reports, functional tests, packaging solutions, and multimedia deliverables such as the video flyer and poster. +
-This iterative approach allowed the team to review progress regularly through retrospectives and adapt the backlog accordingly, ensuring continuous alignment with project goals.+
  
-Figure {{ref>fig:jiracalander}} shows a timeline/backlog with EPICS in JIRA. Some timeline start and end dates are not visible, as those user stories have either not started yet or have already been completed. The team aligned the dates in JIRA with the deliverable deadlines.+The pre-work phase covered foundational Scrum activities — stand-ups, retrospectives, and sprint demos — as well as general activities including role assignment. Sprint 1 focused on initial research, documentation, and structural work. Subsequent sprints progressively addressed design, prototyping, coding, and testing. The final sprints are dedicated to the interim and final reports, functional tests, packaging solutions, and multimedia deliverables such as the video, flyer, and poster. This iterative approach allowed the team to review progress regularly through retrospectives and adapt the backlog accordingly, ensuring continuous alignment with project goals. 
 + 
 +Figure {{ref>fig:jiracalander}} shows the timeline and backlog with epics in Jira. Some timeline start and end dates are not visible, as the corresponding user stories have either not started yet or have already been completed. Dates in Jira were aligned with the deliverable deadlines defined in the Time chapter.
  
  
Line 394: Line 517:
 </WRAP> </WRAP>
  
-Figure {{ref>fig:chart1}} and Figure {{ref>fig:chart2}} are the same concept but this is a Gantt chart done using Excel.+Figures {{ref>fig:chart1}} and {{ref>fig:chart2}} present the same schedule as a Gantt chart produced in Excel, offering an alternative view to the Jira timeline.
  
  
Line 413: Line 536:
 </WRAP> </WRAP>
  
-//Document the project schedule, and the key project phases, using a Gantt Chart. Highlight the key project phases and milestones.//+=== Gantt Chart and Key Project Phases ===
  
-Gantt Chart and Key Project Phases+The project timeline spans from late February 2026 to late June 2026, structured across eight iterative sprints plus a pre-work phase. The Gantt chart illustrates the full schedule, with tasks grouped by sprint and color-coded by category. The project was divided into five key phases: 
 + 
 +  - **Pre-work and Setup (Feb 23 – Mar 5):** project selection, initial Scrum setup, role assignment, and backlog definition. Milestone: top-3 project proposals submitted by February 28. 
 +  - **Research and Documentation (Sprint 1–2, Mar 5–19):** research on water quality and filtration, black box system diagram and structural drafts (milestone: March 11), and the initial list of components and materials (milestone: March 18). 
 +  - **Design and Intermediate Deliverables (Sprint 3–4, Mar 19 – Apr 16):** detailed system schematics, structural drawings, cardboard modelling (milestone: March 25), Gantt chart and sprint plan publication (milestone: March 21), Interim Report and Presentation submission (milestone: April 12), and the Interim Presentation event (milestone: April 16). 
 +  - **Prototyping and Development (Sprint 5–6, Apr 16 – May 27):** 3D model video (milestone: April 22), final materials list (milestone: April 29), refined interim report (milestone: May 2), backend and frontend coding, ESP32 integration, agent connectivity, and packaging solutions (milestone: May 13). Functional tests concluded and uploaded by May 27. 
 +  - **Final Deliverables and Presentation (Sprint 7–8, Jun 1–25):** final report, paper, video, poster, and manual (milestone: June 13), final presentation and individual assessment (milestone: June 18), corrected and refined deliverables (milestone: June 23), and prototype demonstration to the client (milestone: June 25).
  
-The project timeline spans from late February 2026 to late June 2026, structured across eight iterative sprints. The Gantt chart above illustrates the full schedule, with tasks grouped by sprint and color-coded by category to reflect their nature and status.The project was divided into five key phases: 
-  - Pre-work and Setup (Feb 28 – Mar 5): This phase covered project selection, initial scrum setup, role assignment, and backlog definition. The first milestone was submitting the top-3 project proposals by February 28. 
-  - Research and Documentation (Sprint 1–2, Mar 5–19): The team conducted research on water quality and filtration, produced the black box system diagram and structural drafts (milestone: March 11), and compiled the initial list of components and materials (milestone: March 18). 
-  - Design and Intermediate Deliverables (Sprint 3–4, Mar 19 – Apr 16): This phase focused on detailed system schematics, structural drawings, cardboard modelling (milestone: March 25), the Gantt chart and sprint plan publication (milestone: March 21), and culminated in the Interim Report and Presentation submission (milestone: April 12) and the Interim Presentation event (milestone: April 16). 
-  - Prototyping and Development (Sprint 5–6, Apr 16 – May 27): Following interim feedback, the team worked on the 3D model video (milestone: April 22), the final materials list (milestone: April 29), the refined interim report (milestone: May 2), backend and frontend coding, ESP32 integration, agent connectivity, and packaging solutions (milestone: May 13). Functional tests were concluded and uploaded by May 27. 
-  - Final Deliverables and Presentation (Sprint 7–8, Jun 1–25): The team produced the final report, paper, video, poster, and manual (milestone: June 13), delivered the final presentation and individual assessment (milestone: June 18), submitted all corrected and refined deliverables (milestone: June 23), and demonstrated the working prototype to the client (milestone: June 25).  
 === Mapping the Plan to Iterative Sprints === === Mapping the Plan to Iterative Sprints ===
  
-//Describe how your plan was mapped to multiple iterative sprints.// +The project was managed using an agile Scrum framework, with each week constituting a new sprint. Each sprint followed a consistent structure: a planning session at the start, daily stand-ups throughout, and a retrospective and sprint demo at the end. This iterative approach allowed the team to regularly assess progress, incorporate teacher and peer feedback, and adjust priorities accordingly.
  
-The project was managed using agile Sprint framewrok, with each week being a new sprint. Each sprint followed a consistent structure: a sprint planning session at the start, daily stand-ups throughout, and a retrospective and sprint demo at the end. This iterative approach allowed the team to regularly assess progress, incorporate feedback, and adjust priorities accordingly+The product backlog was defined during the pre-work phase and broken down into sprint backlogs at the start of each sprint. Each sprint had a clear goal aligned with the upcoming milestone deadlines.
  
-The backlog was defined during the pre-work phase and browking into each sprint. Each sprint had a clear goal and aligned millestones. +== Backlog Management ==
  
-//Document how the sprint backlog was planned and managed for each of the sprints you have created in Planner.// +The backlog was managed exclusively in Jira. At the beginning of each sprint, the team held a planning session to select tasks based on priority and the upcoming milestones. Each task was assigned to a team member and tagged with its parent epic (e.g., Research, Design, Documents, Code, Prototype, Tests, Interim Report).
  
-The backlog was managed using Jira only. At the beginning of each sprint, the team sits down and plans the tasks based on priority and the upcoming milestones. Each taks then gets assigned to a member and tagged with its epic. +During the sprint, tasks moved through four states: To Do, In Progress, In Review, and Done. Tasks not completed by the end of a sprint were reviewed in the retrospective and either carried over to the following sprint or re-prioritized in the backlog.
  
-Tasks then get moved to either In progress, InReview or done. Incomplete tasks at the end of a sprint were reviewed and either carried over or re-prioritized in the following sprint.+== Prioritization == 
 + 
 +Prioritization was driven primarily by milestone deadlines defined in the Time chapter. Tasks blocking an upcoming deliverable (e.g., the Interim Report on April 12) were assigned the highest priority, regardless of their epic. Within a single sprint, the team applied a simple MoSCoW-style logic: 
 + 
 +  * **Must have:** tasks on the critical path to the next milestone. 
 +  * **Should have:** tasks improving deliverable quality but not blocking submission. 
 +  * **Could have:** nice-to-have improvements deferred if capacity ran short. 
 +  * **Won't have (this sprint):** items pushed to a later sprint or the backlog. 
 + 
 +External dependencies (component delivery times, supplier responses, lecturer feedback) were also considered, with dependent tasks scheduled only after their inputs were confirmed available. 
 + 
 +== Estimation == 
 + 
 +Tasks were estimated in story points during sprint planning, with the team converging on a value through brief discussion rather than formal planning poker. The total points committed per sprint ranged from roughly 30 to 50, depending on team availability and the complexity of upcoming deliverables. 
 + 
 +Two main challenges emerged with estimation. First, the team's mixed academic backgrounds made it difficult to estimate cross-disciplinary tasks consistently — a task that seemed small to one member could be substantial for another. This was addressed by having the assigned member propose the initial estimate and the rest of the team challenge it only when there was strong reason to. 
 + 
 +Second, in early sprints the team noticed that story points were marked as burned down before all sub-tasks of a parent story were closed, which distorted burndown charts. Following Sprint 3, the Definition of Done was updated to require all sub-tasks to be closed before the parent story could be moved to Done, restoring burndown accuracy in subsequent sprints. 
 +=== Mapping the Plan to Iterative Sprints ===
  
-//Describe how prioritization was done.//+The project was managed using an agile Scrum framework, with each week constituting a new sprint. Each sprint followed a consistent structure: a planning session at the start, daily stand-ups throughout, and a retrospective and sprint demo at the end. This iterative approach allowed the team to regularly assess progress, incorporate feedback, and adjust priorities accordingly.
  
-//Document how the estimation process was implemented, and any underlying challenges.//+The product backlog was defined during the pre-work phase and broken down into sprint backlogs at the start of each sprint. Each sprint had a clear goal aligned with the upcoming milestone deadlines.
  
 +The backlog was managed exclusively in Jira. At the beginning of each sprint, the team held a planning session to select tasks based on priority and the upcoming milestones. Each task was assigned to a team member and tagged with its parent epic (e.g., Research, Design, Documents, Code, Prototype, Tests, Interim Report). During the sprint, tasks moved through four states: To Do, In Progress, In Review, and Done. Tasks not completed by the end of a sprint were reviewed in the retrospective and either carried over to the following sprint or re-prioritized in the backlog.
  
 +Prioritization and estimation are described in detail in the Project Plan section above.
 ===== Sprint Overviews ===== ===== Sprint Overviews =====
 === Sprint 1: Foundation & Research === === Sprint 1: Foundation & Research ===
  • report/prm.1776351474.txt.gz
  • Last modified: 2026/04/16 15:57
  • by team3